[coreboot] U-Boot-x86 / coreboot Integration

[Graeme Russ]

On Wed, May 11, 2011 at 2:08 AM, Peter Stuge <peter at stuge.se> wrote:
> Graeme Russ wrote:
>> I am extremely excited about this as the x86 U-Boot maintainer, but
>> even more so by the idea of two very mature and respected FLOSS
>> projects potentially becoming greater than the sum of their parts :)
>
> Yes good fun!
>
>

[snip]

>>  - The majority of U-Boot and coreboot is licensed under the 'GPLv2 or (at
>>    your option) any later version'
>
> coreboot is GPLv2 only, otherwise the facts are accurate.

>From http://www.coreboot.org/Development_Guidelines#License_Issues

    Contributed code must be GPL'd (preferably 'GPLv2 or any later
    version', but 'GPLv2' is fine, too). At the very minimum the code
    must have a GPL-compatible license.

But yes, I image a lot of the code predates this preference, much like
a lot of U-Boot code does

>> Now the politics ;)
>>  - The U-Boot source 'must' be self contained - No external libraries.
>>    Incorporating license compatible source is OK
>
> Well ok.. (why though?)

Because that's the way Wolfgang likes it ;)

>>  - coreboot payloads should be in ELF (linked to libpayload)
>
> They do not neccessarily have to link to libpayload, but if they
> don't they have to replicate some of what libpayload does. That code
> duplication is pretty silly, so most payloads do use libpayload.

I think what will end up happening is porting enough of libpayload
across to U-Boot in order to get access to coreboot data structures.
Everything else either already exists in U-Boot (libc functionality) or
can be added using existing U-Boot architectural principals (USB keyboard,
VGA support etc)

>>  - There should be minimal intrusion into the core U-Boot build scripts
>>    (Makefiles, mk.configs etc) - I would assume the same applies to
>>    coreboot build files as well. Hacking the U-Boot x86 specific build
>>    files should be fine
>
> coreboot uses Kconfig for build time configuration and I think it
> would be no problem (maybe even desirable) to add a few special
> commands in order to grab a U-Boot from git, build it, and include it
> as payload in the output coreboot.rom. This is done for SeaBIOS
> already.

That's an issue for the coreboot team - sounds sensible enough

>>  - Everything should 'just work' with a recent GNU toolchain (gcc,
>>    binutils etc)
>
> coreboot has significant experiences from distribution toolchains
> being patched to the point where they are unable to correctly build
> coreboot itself and/or payloads. If the distribution toolchain works
> for you that's good, but most of the big name distributions have
> messed up their toolchains. The coreboot source includes a script to
> build known good versions of the toolchain, and the coreboot build
> system will automatically pick up such a toolchain if it is found
> during build.

I tend to use a pure breed toolchain (I build GCC and binutils from
scratch and don't use the disto's toolchain)

>>  - U-Boot relocates to 'Top of RAM' - This is a fundamental architectural
>>    design and not x86 specific. This feature should be retained for
>>    consistency with other U-Boot arches
>
> IMO this might be a little misguided. Retaining behavior, especially
> across architecture, shouldn't be an end in itself. If U-Boot was the
> primary bootloader in this situation it would matter less. In the
> context of coreboot however U-Boot would be much easier to integrate
> with if this policy was not enforced. Maybe U-Boot wants to stay
> resident however, then there's not much choice except top of memory.

As Wolfgang has commented on in another post in this thread, there are
some pretty solid reasons behind this rationale. These reasons may be
more applicable to ARM/PPC embedded environments and possibly irrelevant
in the x86/PC world. Although this 'feature' is currently implemented on a
per-CPU architecture basis, this may change in the future - It's worth
keeping in mind so nobody gets blindsided

>>  - Do we care about legacy BIOS support (SeaBIOS) for now (I think
>>    not)?
>
> IMO it is not relevant to the integration of coreboot and U-Boot. If
> a BIOS is needed by U-Boot itself or whatever it loads, then SeaBIOS
> must be used as payload for coreboot, and SeaBIOS will then start
> U-Boot after setting up the BIOS environment.

Or U-Boot could load a SeaBIOS image and initialise it if needed. So
in a U-Boot script:
  - If the target OS is GNU/Linux the load the Linux kernel image and go
  - If the target OS is Windows (or any other OS which needs a BIOS) then
    U-Boot first loads a SeaBIOS image and then loads the image for the
    target OS (this may even be a 'GRUB' image for example)

>> So, a few questions
>>  - How much of libpayload would we need to bring into U-Boot to provide
>>    bare minimal payload delivery? U-Boot already contains it's own
>>    minimal libc routines.
>
> Not much at all. You basically just have to look up the coreboot
> table.

Thought so - So we just port this bit

>>  - How do we get VGA and USB keyboard support working?
>
> Write VGA and USB drivers. Or use the ones that are available in
> libpayload. Estimate 5-6 months of development effort to write from
> scratch. But you could also copy it all from libpayload of course.

U-Boot already has USB support framework - just a matter of writing device
drivers for the chipset hardware

>
> One thing to keep in mind here is that VGA will only be available if
> coreboot or SeaBIOS has set it up. coreboot only knows how to do this

Or if U-Boot does

> for two or three graphics chipsets. SeaBIOS can initialize any VGA
> option ROM, but then you need SeaBIOS in the loop.
> Option ROMs are ageold technology and stupid, but they are still
> firmly entrenched in PC hardware. A BIOS was always there so everyone
> assumes it will always stay there, not very many question if
> something better could be done.

Would be interesting to investigate implementing a stub in U-Boot to
initialise and use VGA option ROMs

>>    Do other U-Boot boards implement console on anything other than
>>    serial?
>
> U-Boot? Can't say.

>From Wolfgang : Yes

>>  - Can we add relocation support to the coreboot ELF loader?
>
> ELF payloads are parsed at build time, simplified into a
> coreboot-internal format. Run time relocation is not so attractive.
>
>
>>  - Does coreboot relocate into RAM? If so, what is the target address?
>
> Determined at build time.
>
>>    What guarantee is there that the target address is valid?
>
> It's low enough in RAM.
>
>
>>  - Could coreboot benefit from U-Boot's 'load to top of RAM' philosophy?
>
> I doubt it, but maybe?
>
>
>>  - Is it worth playing around with segment registers to 'relocate' U-Boot
>
> Maybe?

On further though, probably not. The Linux protected mode entry point
requires a very specific segment setup - Using segments to 'relocate'
U-Boot is only going to make things very ugly, very quickly

>>  - What hardware should be initialised in coreboot and what should be
>>    initialised in U-Boot? (political question ;)
>
> Actually this is well defined. coreboot in general does not touch
> peripherals with VGA being the exception.

Agree - Have coreboot do the bare minimum to launch an arbitrary payload
and leave the rest up to U-Boot

>>  - What about Chipset Microcode (CMC)
>>  - What about System Management Mode (SMM)
>
> coreboot does provide the bare minimum for chipsets which need it,
> but preference is to not go beyond the busses.

Yes, I think CMC and SMM should be loaded by U-Boot. It may be
necessary for some boards to have CMC loaded by coreboot in order to
bring SDRAM controllers up

>> We can start with U-Boot linked to a fixed location in RAM and skip
>> relocations then work on either extending coreboot to perform
>> relocation fixups or have U-Boot perform the fixups based on RAM
>> information read from cbtable
>
> The latter sounds better to me. :)

But involves a double memcpy - A decision for later

>> From there, we can start to add device support (USB, video, PCI,
>> IDE/SATA etc)
>
> libpayload covers most of these. :) Take a look at a couple different
> libpayload users. FILO would probably be the closest to what U-Boot
> does.

Hmm, I'm thinking these should be implemented in U-Boot. I'm keeping
embedded x86 solutions in mind - I want to maintain the idea of U-Boot
being a primary bootloader for these systems and not rely on coreboot /
libpayload / SeaBIOS etc

Regards,

Graeme