[coreboot] Fwd: Merging Qi with coreboot?

Andy Green andy at openmoko.com
Wed Dec 3 23:37:34 CET 2008


-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkk3Ci0ACgkQOjLpvpq7dMpJKgCbBSaq4HdPoNxkBokFvcsvfHRx
yJ4AoJBS3q85jV26RgZ4oshkpTSf2ByW
=SRej
-----END PGP SIGNATURE-----




More information about the coreboot mailing list