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 -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
