Has anyone considered using Open Firmware [1] as a more capable bootloading system? It appears to have support for a wide range of devices. Due to the efforts of the OLPC developers, the whole software stack is now available under an open source license [2]<br>
<br>Pardon me if this is a silly question, but I have search the archive and found no mention of Open Firmware.<br><br>[1] <a href="http://en.wikipedia.org/wiki/Open_Firmware">http://en.wikipedia.org/wiki/Open_Firmware</a><br>
[2] <a href="http://wiki.laptop.org/go/Open_Firmware">http://wiki.laptop.org/go/Open_Firmware</a><br><br><div class="gmail_quote">On Fri, May 23, 2008 at 5:02 AM, <<a href="mailto:andy@openmoko.com">andy@openmoko.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Somebody in the thread at some point said:<br>
| Hi Rasmussen:<br>
| i think the kboot can do that.<br>
| <a href="http://kboot.sourceforge.net/" target="_blank">http://kboot.sourceforge.net/</a><br>
|<br>
| Peter Rasmussen wrote:<br>
|> Hi thomasg,<br>
|><br>
|> I can see that what I have been able to use is exactly what you<br>
|> intended in your wiki description.<br>
|><br>
|> So yes, I can boot a system residing on the SDHC card, however the<br>
|> kernel is taken from the NAND image, ie. "your" method :-)<br>
<br>
The way to solve that is to have a small, eg, 8MB FAT partition first,<br>
containing the kernel, with a second ext2 partition in the rest of the<br>
card containing the rootfs. U-boot can succeed to parse the FAT<br>
partition and pull out a kernel image file into memory, boot into that,<br>
rootfs is set for the second partition on kernel commandline.<br>
<br>
|> And that is why I in a different mail mentioned that I would like to<br>
|> have the SDHC-support in u-boot, to boot completely independent<br>
|> systems on a flash-card.<br>
|> With presently the size of max. 8GB for a micro-SDHC, one card is able<br>
|> to hold several systems, so I think such an option is a very good idea.<br>
<br>
SDHC is a disconnected issue, you can do the above on an old non-SDHC<br>
card. I added SDHC support to the U-boot Glamo SD driver, but I guess<br>
you are talking about GTA01. Because of the "flat" nature of U-Boot<br>
stuff, ie, there is no "mmc layer", the driver is responsible to issue<br>
his own MMC/SD commands at the driver layer, so that is where SDHC is<br>
implemented. If someone with GTA01 -- and a debug board ;-) -- wants to<br>
compare the Glamo SD driver in U-Boot and the existing driver, they will<br>
see it won't be a huge job to copy the SDHC support. The differences to<br>
take care about are that it counts blocks now not bytes, and there is a<br>
different canned sequence of SD commands, but the ones that worked here<br>
are in the Glamo driver already.<br>
<br>
|> This is what I have in my previous listing as well, but I would like<br>
|> to emphasize the following, too:<br>
|><br>
|> "And if u-boot had USB support implemented so that I could upload an<br>
|> image from my desktop Linux straight to the flash-card without having<br>
|> to boot the Neo all the way to a Linux system, that would be really<br>
|> helpful, too."<br>
|><br>
|> If I could boot up in u-boot and specify what target-partition on the<br>
|> flash-card I want to put a kernel and a rootfs, and then subsequently<br>
|> boot that image, that would be great!<br>
<br>
I think being able to quickly have write access to the SD Card is good,<br>
but I don't think U-Boot has to be or should be part of that picture.<br>
If you change init=/bin/sh and boot again, here you are at a Linux<br>
prompt a few seconds after Linux begins boot... boot to a script instead<br>
like "/etc/startup" that sets up ifconfig and so on and you are<br>
network-capable over the USB in a few seconds after Linux begins boot.<br>
<br>
U-Boot isn't the future.<br>
<br>
- -Andy<br></blockquote></div><br>