[coreboot] Hackaton in Prague 2011

[Graeme Russ]

On Tue, May 10, 2011 at 10:30 AM, Peter Stuge <peter at stuge.se> wrote:
> Graeme Russ wrote:
>> Well, I do not know the semantic architecture of coreboot :)
>
> Welcome to the list.

Thanks

>
>
>> In addition to 'boot OS and die', U-Boot has a 'standalone
>> application' API which allows a 'payload' to be run with control
>> returning to U-Boot. If coreboot does not have any such concept
>> then you are right, no need to worry about returning back to
>> coreboot
>
> coreboot does not.
>

OK - No need to worry about re-entering coreboot then :)

>
>> > memory size is in cbtable, payloads are ELF by convention
> ..
>>
>> 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. 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')

>
>> The idea of adding support for relocatable ELF images to libpayload is
>> interesting. If coreboot can load U-Boot at an appropriate target
>> address than we can skip a memcpy and relocation fixup loop in U-Boot.
>
> I think the coreboot loader does this already. If U-Boot is built as
> an ELF located at the appropriate target address then that's where
> coreboot will run it from.
>

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

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. 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.

>
>> >>  - Can u-boot piggy-back on SeaBIOS loaded by coreboot?
>> > In the context of coreboot: why?
>>
>> Again, probably a missunderstanding of coreboot on my behalf -
>> U-Boot has a REALLY primative BIOS implementation (just enough to
>> trick Linux into booting in an embedded environment). It is
>> basically just some empty VGA stubs and simple e820 support. If
>> coreboot can load SeaBIOS, U-Boot could transition to it and I
>> could ditch all of the real-mode support from U-Boot.
>
> coreboot starts one payload and one payload only. SeaBIOS when built
> as payload for coreboot can actually start other files in the boot
> flash that are identical to the coreboot payload.
>
> 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.

>
>> This could allow U-Boot to support booting of OSs that require a BIOS.
>
> That should work fine if SeaBIOS is inserted before U-Boot and can
> set up the complete BIOS environment.
>

Sounds good

>
>> For Linux, I can implement a protected mode transition from U-Boot
>> for which we would not need to load SeaBIOS at all.
>
> This would be something similar to what FILO, GRUB 2 and gPXE do I
> guess. Even mkelfImage.
>
>
>> >>  - 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)

>
>
>> >>  - VGA & Keyboard support
>> >>  - U-Boot splash screen support
>> > libpayload
>> >
>> >>  - Flash updates from u-boot
>> > libflashrom (work in progress)
>>
>> How will these work in practice? Where are they initiated from?
>
> coreboot starts one payload.
>
> The payload can be very easily created with libpayload, a C library
> that we have created in order to make it easy to create payloads. Run
> lpgcc instead of gcc to link against libpayload. Some
> coreboot-specific functions like accessing the coreboot tables are
> available, and a good deal of libc compatibility.
>
> 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. 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?)

Regards,

Graeme