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 >From there, we can start to add device support (USB, video, PCI, IDE/SATA etc) It's getting late, so I'll stop now. Hopefully this gives a good design platform to start from Regards, Graeme P.S. Please keep both U-Boot and coreboot mailing lists Cc'd - Note: If you are not on the coreboot ml, you emails will get bounced to a moderator :( _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
