[coreboot] Hackaton in Prague 2011

[Graeme Russ]

On Tue, May 10, 2011 at 2:22 PM, Stefan Reinauer
<stefan.reinauer at 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