-----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