[coreboot] Hackaton in Prague 2011

[Peter Stuge]

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

Why not?


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

Sure thing.


> do the relocation fixups

But possibly not this one.


> and jumps into the in-RAM copy of U-Boot.

Yep.


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


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

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


//Peter