On Tue, May 10, 2011 at 11:15 AM, Peter Stuge peter@stuge.se wrote:
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?
a) High probablility of impacting on the U-Boot build process (you mention using lpgcc rather than gcc) b) Breaks the ethos of U-Boot being a self-contained binary image intended to be written directly to a boot Flash c) The U-Boot maintainer (Wolfgang Denk) won't allow patches that result in U-Boot relying on code external to the U-Boot git tree. All that should ever be required to build U-Boot is a pull from the U-Boot git tree and standard set of build tools (compiler and linker)
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 I need to understand what, exactly, libpayload is all about. I get the impression that, while not a link-back to coreboot, it does provide a set of low-level APIs (some of which provide access to data structures created by coreboot and some to access hardware features)
I guess this is getting a little confusing because both projects use the term payload to mean different things.
U-Boot does not have a 'payload' - It has a 'standalone application' which can be invoked with control returning back to U-Boot and an OS 'image' which, when invoked, typically results in U-Boot being 'blown away'
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.
Already exists - It is the very first byte of u-boot.bin (which is a dozen or so bytes before the entry point used by the x86 cold-reset vector code
I mentioned in an unrelated email that the U-Boot linker script needs to be adjusted to fix the ELF entry point
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.
The in-RAM location of U-Boot is dynamically determined after RAM is initialised so as to place U-Boot as high in memory as possible to allow for the maximum amount of contiuous RAM below U-Boot
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.
This is only viable if coreboot can: - Load U-Boot to an arbitrary memory address based on total available system RAM - Perform the relocation fixups (which are fairly trival to imeplement - Look in u-boot's arch/x86/lib/board.c for details) - Does not require U-Boot to be linked against libpayload (which is possibly negotiable ;)
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..
Hmm, can we wrap u-boot.bin in a 'payload' - In U-Boot, you create an 'image' using the mkimage tool. U-Boot images support a range of formats including compressed/uncompress, raw/ELF etc. I suppose it is as close to a coreboot 'payload' as you can get, but does not carry any API for the contents of the image to use. The image content is always stand-alone with U-Boot providing the API. Correct me if I am wrong, but it would seem with coreboot that once the 'payload' is launched, coreboot is gone and the only API available is what is in libpayload
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.
Which is only available via libpayload? - Can a link to cbtable be provided via a reserved register (perhaps a reseved segment even)
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. :)
But it does have more code for hardware that U-Boot :) Typically U-Boot drivers are derived from Linux, so maybe coreboot's codebase is not going to be as helpful as I might have thought. The question is, does coreboot knows about any hardware that Linux does not?
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.
OK, so I think there are three things to really look into: - Giving coreboot to ability to load a relocatable ELF image to an arbitrary RAM location and performing the necessary relocation fixups - libpayload - Console I/O in U-Boot (porting support available in libpayload into U-Boot?)
Regards,
Graeme