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