On Tue, May 10, 2011 at 2:22 PM, Stefan Reinauer stefan.reinauer@coreboot.org wrote:
On 5/9/11 5:53 PM, Graeme Russ wrote:
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. U-Boot is designed to be the primary bootloader much like coreboot is - It is not a 'payload'. 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')
That's not the case for all platforms. On Nvidia Tegra2 there is a boot rom loading uboot. I remember on the Dbox uboot was piggybacked on the original firmware, too. At the least, uboot should play nice in such scenarios (which I think it does)
Yes, there are other bootstrap loaders, but U-Boot is still a raw binary image without any kind of payload wrapper as far as I am aware
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. 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
We should add a configuration option to avoid this copying with respect to boot time.
Nope - U-Boot is specifically designed to move itself into RAM - A primary reason for moving into RAM is so the ROM can be re-flashed. This is particularly neccessary when the U-Boot environment variables are embedded in the U-Boot image
So what would be really neat is if coreboot calculated where the final in-RAM location of U-Boot needs to be, copy U-Boot there, do the relocation fixups and jumps into the in-RAM copy of U-Boot.
Another option would be to have uboot do a virtual/physical mapping that allows us to skip the run time linking. As the copying, it's a (small but measurable) waste of time, and it makes the code unnecessarily complex. I'm not suggesting to remove this feature, but I think it should be configurable (and disabled for coreboot and anyone else who aims at booting quickly)
U-Boot would then skip all it's own relocation code. The other option is to not use coreboot's ELF loader and simply have coreboot jump to the U-Boot binary image in Flash. 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.
coreboot does its ELF parsing at build time, not at runtime. This way we save yet another copy while preserving the option of compressing the payload (e.g. uboot) in flash.
The sequence would then be coreboot->SeaBIOS->U-Boot. Note that coreboot is not a BIOS and does not want to be a BIOS.
Neither is (or does) U-Boot. But in order to load many OSs, there needs (unfortunately) to be some BIOS functionality.
Piggybacking coreboot->seabios->uboot should not be a big deal, but the most common use case for uboot is booting Linux, not Windows or other bios prone OSes. Let's do one step after another.
- Can we move more hardware init and drivers from coreboot into u-boot and provide more commands in u-boot for coreboot supported boards
Code duplication? *shudder*
The point being that U-Boot provides a shell and command line with diagnostic features. These require hooks into the hardware drivers.
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)
Those things are often not available or required on the systems coreboot runs on.
au contraire - PC's have lots of little bits and pieces (like thermal monitoring, fan speed monitoring/setting etc) - It may be very useful to have access to these from the U-Boot command line / script.
- VGA& Keyboard support - U-Boot splash screen support
libpayload
- Flash updates from u-boot
libflashrom (work in progress)
I don't think we want to plug flashrom into uboot (not in the beginning anyways) nor libpayload. Let's keep this minimal and then see what's actually missing. A clean design is more important right now than overplugging uboot with foreign libraries.
We can always run flashrom as a standalone app from U-Boot
As I said earlier, I don't want to tie U-Boot to libpayload. 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?)
Does uboot provide a USB stack on PCs (e.g. UHCI/OHCI/EHCI/XHCI)... those might be interesting parts of libpayload in the longer run.
There are USB drivers in U-Boot - It's all a question of hardware support
For now, just adding a simple keyboard and vga driver should be fairly simple. It would be nice to also have an option for running on a linear framebuffer (with the framebuffer specs read from the coreboot table)
Regards,
Graeme