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