On Tue, May 10, 2011 at 2:22 PM, Stefan Reinauer <[email protected]> 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 -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
