<br><br><div class="gmail_quote">On Tue, Nov 25, 2008 at 2:17 PM, Grant Likely <span dir="ltr"><<a href="mailto:grant.likely@secretlab.ca">grant.likely@secretlab.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Tue, Nov 25, 2008 at 1:07 PM, Matt Sealey <<a href="mailto:matt@genesi-usa.com">matt@genesi-usa.com</a>> wrote:<br>
<br>
> But here's the real question; why do you need an opensource implementation?<br>
> Curiosity?<br>
<br>
</div>Umm, so that it can be ported to new boards perhaps? So that<br>
developers can work with it?<br></blockquote><div><br>You can port closed-source firmwares to new boards just as easily as with open source ones. <br></div></div><br>For companies who have larger production requirements than Bill Gatliff, porting an open source firmware may not be a task they want to get into. Linux support is a big enough moving target without adding firmware development to it and tying up programmers implementing the same drivers twice (even if it is practically copy&paste in U-Boot).<br>
<br>In this case they may just buy one in. If everything had to be open source and freely downloadable there would be no industry at all. And if paying for someone else to write code for you is the issue, then we wouldn't have asked you for a quote last week, and you certainly wouldn't have given us a price :D<br clear="all">
<br>Bill, as for ARM etc. support, you can imagine that most of the guts of the firmware are fairly well abstracted. Vast portions of the same code work on most platforms with the same peripherals - USB, Ethernet controllers & PHYs, PCI, SDIO, etc. The device tree is how hardware designers (note; not OS designers) are meant to abstract the differences in hardware and programming model so that an OS can load the right drivers and Do The Right Thing. It doesn't matter if the device tree was generated as a flattened representation, or by an open-source firmware or closed-source firmware.<br>
<br>However the IEEE 1275 standard is not as big a moving target as U-Boot. It has an ABI and a client interface which hasn't been moved around or modified since 1994. And when your board doesn't provide a device tree entry for something, well, you just write some Forth and can edit entries in the device tree in-place (no recompiles required). If you're so inclined you can even write things like scsi host controller drivers in Forth and present them such that they are then working - no reboots or recompiles required, just load the script - and ready to use to boot the system. You can poke around in the FirmWorks code for how powerful this can be, or poke around <a href="http://www.powerdeveloper.org/platforms/efika/devicetree">http://www.powerdeveloper.org/platforms/efika/devicetree</a> for how mundane and simple it can be just fixing up some entries and making sure the chip is configured right..<br>
<br>-- <br>Matt Sealey <<a href="mailto:matt@genesi-usa.com">matt@genesi-usa.com</a>><br>Genesi, Manager, Developer Relations<br>