[coreboot] Hackaton in Prague 2011
peter at stuge.se
Tue May 10 03:15:42 CEST 2011
Graeme Russ wrote:
> >> My point being that U-Boot needs to know about the arrangement of
> >> memory of the target board.
> > Yes. The information is published by coreboot in the "coreboot table"
> > AKA cbtable. libpayload already has code to find it.
> Hmm - I don't think linking U-Boot against libpayload is the right
> U-Boot is designed to be the primary bootloader much like coreboot
> is - It is not a 'payload'.
If coreboot is participating then yes, U-Boot is the (coreboot)
payload. The idea is to leverage the shell and bootloading features
of U-Boot, after the platform initialization in coreboot has run.
> There is a rather special case with NAND booting where a bootstrap
> loader loads U-Boot into RAM, but even in this case U-Boot is
> treated like a binary blob exectuted in RAM with no real concept of
> how it got there (i.e. no link-backs to the 'loader')
Make no mistake, coreboot payloads have no link-back to the 'loader'.
I guess this is getting a little confusing because both projects use
the term payload to mean different things.
> U-Boot is build with the target address in Flash. It initialises memory
> and copies itself into RAM at an address calculated by the RAM init code.
Here there should probably be a second possible entry point, for when
U-Boot is a coreboot payload.
> It then processes the ELF symbol table (embedded in the raw binary image)
> to adjust memory addresses in the in-RAM copy before jumping out of flash
> and into RAM
I guess this processing would remain, but the bytes it operates on
would already be in RAM.
> So what would be really neat is if coreboot calculated where the final
> in-RAM location of U-Boot needs to be,
This is decided at (coreboot payload) build time.
> copy U-Boot there,
> do the relocation fixups
But possibly not this one.
> and jumps into the in-RAM copy of U-Boot.
> U-Boot would then skip all it's own relocation code.
ELF is the way to happiness in coreboot land. coreboot would like a
U-Boot ELF binary and will copy it to given address in RAM and run
> The other option is to not use coreboot's ELF loader and simply
> have coreboot jump to the U-Boot binary image in Flash.
Does not fit the coreboot model so well. Something could be hacked of
course, but that's not so nice..
> This is a far simpler method, and all the code already exists in
> U-Boot anyway - all we need to do is tell U-Boot the highest
> available memory address.
That can be read from the cbtable.
> > coreboot does not generally have drivers. coreboot knows how to do
> > the init, but the payload is responsible for driving any hardware
> > that needs to be driven.
> > One could argue that coreboot is only a collection of CPU and chipset
> > drivers, which so far have very few if any knobs.
> U-Boot is similar, but having a command line and shell which can
> run scripts means that it can do a bit more with the hardware (set
> Ethernet MAC addresses, intialise devices on I2C busses, display a
> bitmap splash screen, toggle LEDs etc)
My point was that coreboot has no drivers of that sort. :)
> > Besides using libpayload, U-Boot would also use libflashrom, to take
> > advantage of the rich boot flash writing code that is flashrom also
> > at boot time.
> As I said earlier, I don't want to tie U-Boot to libpayload.
Again, why not? For the particular U-Boot build that runs as coreboot
payload it should save a lot of development time.
> With regard to VGA and keyboard support, how can we make them
> usable in U-Boot (i.e. so the command prompt is displayed on a
> monitor and the user can use the keyboard to enter commands?)
If U-Boot will require SeaBIOS then some VGA option ROM will likely
have been executed and all the standard BIOS services for console are
When U-Boot is the coreboot payload there are no BIOS services, and
U-Boot needs to implement everything on it's own. Or it can use
libpayload, which already has console support for a few hardware
More information about the coreboot