[U-Boot] [coreboot] U-Boot-x86 / coreboot Integration

[Peter Stuge]

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!


> OK, enough with the warm and fuzzies. Lets look first at a few facts
> (as I understand them - please feel free to correct me):
>  - U-Boot is a bootloader for embedded systems - A market segment
>    dominated by ARM, PPC et al - i.e. NOT x86
>  - coreboot is a 'BIOS' replacement for mainstream PC's - A market segment
>    dominated by x86
>  - Both are principally designed as 'primary bootloaders' - i.e. intended
>    to be executed at CPU reset and responsible for low level hardware
>    initialisation
>  - U-Boot has no support for modern x86 PC hardware (North and South
>    bridges, Dual-Core x86 CPUs, microcode, ACPI, APM etc)
>  - coreboot is 'dumb' (No command line, scripting etc) As I understand it
>    you build a 'payload' into the coreboot image which coreboot simply runs
>    after it has performed necessary low-level hardware initialisation
>  - U-Boot is 'smart' (command line, scripting, network support, environment
>    variables etc) but currently lacks the ability to perform low level
>    hardware initialisation of x86 PC hardware
>  - coreboot launches a 'payload' which is (typically) an ELF executable
>    linked to 'libpayload'. libpayload provides access to some primitive
>    libc functionality, I/O and coreboot generated data structures
>  - Our primary target OS is GNU/Linux (of course!)
>  - 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.


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

Well ok.. (why though?)


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


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


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


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


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


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


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

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


>    Do other U-Boot boards implement console on anything other than
>    serial?

U-Boot? Can't say.


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


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


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


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


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


//Peter