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

[Graeme Russ]

Hi All,

I figured it might be best to start a new, clean thread dealing with the
technical design aspects of bootstrapping U-Boot from coreboot.

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

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'

So coreboot and U-Boot are a good complement to each other so bringing
U-Boot to x86 PC mainboards via coreboot looks like a good idea - Now the
politics ;)
 - The U-Boot source 'must' be self contained - No external libraries.
   Incorporating license compatible source is OK
 - coreboot payloads should be in ELF (linked to 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
 - Everything should 'just work' with a recent GNU toolchain (gcc,
   binutils etc)
 - 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
 - Do we care about legacy BIOS support (SeaBIOS) for now (I think not)?

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.
 - How do we get VGA and USB keyboard support working? Do other U-Boot
   boards implement console on anything other than serial?
 - Can we add relocation support to the coreboot ELF loader?
 - Does coreboot relocate into RAM? If so, what is the target address? What
   guarantee is there that the target address is valid?
 - Could coreboot benefit from U-Boot's 'load to top of RAM' philosophy?
 - Is it worth playing around with segment registers to 'relocate' U-Boot
 - What hardware should be initialised in coreboot and what should be
   initialised in U-Boot? (political question ;)
 - What about Chipset Microcode (CMC)
 - What about System Management Mode (SMM)

I think a good start would be to create a new U-Boot target which includes
a stripped down libpayload in the U-Boot source. This target can exclude
most of the assembler startup code (resetvec.S, start16.S, start.S). I
assume the coreboot ELF loader (or libpayload) takes care of setting up the
C environment (stack etc).

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