On Wed, May 11, 2011 at 2:08 AM, Peter Stuge peter@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