This is an interesting writeup (see link). I think they think coreboot does lots of BIOS stuff.
ron
---------- Forwarded message ---------- From: Andy Green andy@openmoko.com Date: Wed, Dec 3, 2008 at 8:08 AM Subject: Re: Merging Qi with coreboot? To: Troy Benjegerdes hozer@hozed.org Cc: devel@lists.openmoko.org, rminnich@gmail.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Somebody in the thread at some point said:
| I'd like to understand the motivation for Qi.. it really seems like it's | just a "YABL" (yet another boot loader). Why can't U-boot be made to
There's some explanation of why we moved off U-Boot here
http://git.openmoko.org/?p=qi.git;a=blob;f=README;h=198507c717cc8b5f8f72250f...
| boot "really fast", or if speed is the primary motivation, wouldn't it | make more sense to leverage the work begin done on Coreboot for x86? | (cold boot to linux console in 3 seconds on x86 hardware)
x86 and s3c device boot are very different, and we don't need to take care about a lot of PC-centric BIOS business.
- -Andy
On Wed, 3 Dec 2008 08:41:09 -0800, "ron minnich" rminnich@gmail.com wrote:
This is an interesting writeup (see link). I think they think coreboot does lots of BIOS stuff.
That's funny. If we had ARM support in coreboot there wouldn't be a need for all the sillyness :-)
Sorry about the crossposting. Please let me know if you should be excluded.
ron minnich wrote:
This is an interesting writeup (see link). I think they think coreboot does lots of BIOS stuff.
Andy Green wrote:
| wouldn't it make more sense to leverage the work begin done on | Coreboot for x86?
x86 and s3c device boot are very different, and we don't need to take care about a lot of PC-centric BIOS business.
Note that coreboot is not about being a BIOS, by design. The idea with coreboot since day 1 was to get Linux running as soon as possible and to let Linux handle as much as it could. This design goal seems to be shared by coreboot and Qi.
coreboot does not implement BIOS services, coreboot only does hardware initialization and then it hands over to another program, called the payload, which never returns.
Linux can be used as payload, if you really do want a BIOS you can use the SeaBIOS payload, there are several lightweight bootloaders that can be payloads (FILO, GRUB 2, gPXE, 9load..) and simple applications can be built into payloads using libpayload.
While coreboot worked mostly for x86 small and large in the past, it has supported both alpha and power. In coreboot v3 we make an effort to keep everything arch clean to make support also for non-x86 easy.
What steps does Qi need to take before it can hand over to Linux?
//Peter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Somebody in the thread at some point said: | Sorry about the crossposting. Please let me know if you should be | excluded. | | | ron minnich wrote: |> This is an interesting writeup (see link). I think they think |> coreboot does lots of BIOS stuff. | | Andy Green wrote: |> | wouldn't it make more sense to leverage the work begin done on |> | Coreboot for x86? |> |> x86 and s3c device boot are very different, and we don't need to |> take care about a lot of PC-centric BIOS business. | | Note that coreboot is not about being a BIOS, by design. The idea | with coreboot since day 1 was to get Linux running as soon as | possible and to let Linux handle as much as it could. This design | goal seems to be shared by coreboot and Qi.
That sounds like it is the case.
| coreboot does not implement BIOS services, coreboot only does | hardware initialization and then it hands over to another program, | called the payload, which never returns. | | Linux can be used as payload, if you really do want a BIOS you can | use the SeaBIOS payload, there are several lightweight bootloaders | that can be payloads (FILO, GRUB 2, gPXE, 9load..) and simple | applications can be built into payloads using libpayload.
The philosophy I plan to follow is the OS is the only payload we are interested in. Any applications would then be normal Linux apps in a normal Linux rootfs. We saw plenty of U-Boot specific code rot whereas there are nice living libs for UI or applications in Linux, many users can imagine to contribute normal Python apps, etc.
| While coreboot worked mostly for x86 small and large in the past, it | has supported both alpha and power. In coreboot v3 we make an effort | to keep everything arch clean to make support also for non-x86 easy. | | What steps does Qi need to take before it can hand over to Linux?
s3c processors from Samsung have a piece of magic SRAM, either 4K or 8K bytes which gets filled from NAND or SD Card by magic at reset, then jumped into. This chunk of SRAM is called "steppingstone" by Samsung. The task of the code in there is to init the SDRAM and pull the rest of the bootloader (Qi binary is around 24KBytes currently), then jump into that. imx31 from Freescale is also using a similar scheme.
The mandates a specific architecture for the bootloader that you have to cram a highly capable "first phase" code into the 4 or 8 K, for 6410 ours not only has SD driver but memory test and other bringup in there. ~ Then in the second phase, situation is more relaxed and we have ext2/3 filesystem support and other goodies in the rest of it.
If you want to extend coreboot to work with ARM go for it by all means... Qi code is all GPL'd and in git
http://git.openmoko.org/?p=qi.git;a=summary
Take a look at src/phase2.c to see the flow into Linux. I think you'll find it's not only lean in the sources but quite tight as a binary.
- -Andy
On Wed, Dec 3, 2008 at 2:37 PM, Andy Green andy@openmoko.com wrote:
The philosophy I plan to follow is the OS is the only payload we are interested in. Any applications would then be normal Linux apps in a normal Linux rootfs. We saw plenty of U-Boot specific code rot whereas there are nice living libs for UI or applications in Linux, many users can imagine to contribute normal Python apps, etc.
yep, that is pretty much what the original plan with linuxbios was in 1999, so I love the plan :-)
It makes sense to do this as opposed to make the boot loader complicated. Every boot loader that tries anything fancy inevitably turns into its own little OS, as witness OFW, U-boot, EFI, Alpha boot loader, and so on.
I have to get an open moko now!
s3c processors from Samsung have a piece of magic SRAM, either 4K or 8K bytes which gets filled from NAND or SD Card by magic at reset, then jumped into. This chunk of SRAM is called "steppingstone" by Samsung. The task of the code in there is to init the SDRAM and pull the rest of the bootloader (Qi binary is around 24KBytes currently), then jump into that. imx31 from Freescale is also using a similar scheme.
neat.
If you want to extend coreboot to work with ARM go for it by all means... Qi code is all GPL'd and in git
http://git.openmoko.org/?p=qi.git;a=summary
Take a look at src/phase2.c to see the flow into Linux. I think you'll find it's not only lean in the sources but quite tight as a binary.
we'll see if anyone jumps on this. Thanks for the link troy.
Somehow this thread has gotten dropped across two lists, so we should probably close it down before people not on each list get annoyed.
Thanks again
ron
-
Andy Green -
Joseph Smith -
Peter Stuge -
ron minnich