Hi All,

You may have noticed a distinct lack of activity related to x86 code lately. There are a number of reasons for this, but none of them signify an end to x86 U-Boot.

I've fielded a number of questions lately (mostly off list) and I want to bring the outcome of those discussions to some form of unified consensus. There are two predominant architectural decisions which I think are important to get out of the way: 1) Getting rid of 16-bit 'Real Mode' code (i.e. BIOS stub) and how to boot Linux as a result 2) Chain-loading U-Boot (from coreboot or GRUB for example)

My position on #1 is pretty straightforward - I want to get rid of the 16-bit 'Real Mode' code (and, ergo, the BIOS code) entirely and forever. For me personally this is a bit of a pity as I had done a lot of hacking off-list learning how to seamlessly add 16-bit C code into U-Boot (including interrupt handling etc.) which would have allowed the BIOS code to be re-written in C. However, I think the better direction for U-Boot is for it to be as small and tight as possible with no unnecessary 'fluff'. I have proven to myself that a Linux kernel (with a little coercion of the bzImage) can be booted by U-Boot without the 'Real Mode' code. This greatly simplifies (and speeds up) the overall boot process.

For reference, this may be a helpful link for the following discourse:

http://lists.kernelnewbies.org/pipermail/kernelnewbies/2011-November/003906....

The main stumbling block with booting without a BIOS is how booting the x86 kernel relies on data in the 'Real Mode' stub (struct setup_header and struct boot_params) - The x86 kernel boot process has evolved into (IMHO) a monstrosity that make it nigh on impossible to deal with cleanly in a purely 32-bit protected mode environment (i.e. the Linux kernel pretty much assumes as a matter of course that it is being booted on a machine with a BIOS). So what has ended up happening is that the x86 bzImage contains three intrinsically interrelated components - A 'Real Mode' stub to probe BIOS, a 'Protected Mode' decompresser and the actual (compressed) kernel itself. One piece of information in particular that is in the setup header that is not (readily available?) in the compressed kernel image is the kernel version string.

What I would ultimately like to do is have U-Boot do the kernel decompression itself (this would allow the x86 kernel image to be stored in the U-Boot image container). This could potentially save some unnecessary coping of the kernel. At the moment, bzImage needs to be copied 'low' in memory and then it is decompressed elsewhere into memory. By not using the Linux real-mode 'fluff', it is feasible to decompress the image directly from storage (NOR flash in particular) to it's final location in RAM. It may even be feasible to decompress straight from SD/MMC, HDD, NAND flash, etc. by utilising DMA (DMA block 'n' to RAM, start DMA'ing block 'n+1', decompress block 'n' while the DMA of block 'n + 1' is happening)

In order for U-Boot to successfully boot an x86 kernel directly from protected mode would be vmlinux.bin and the matching setup header - something the current kernel build process does not readily give us. I have written a script that can strip the required data out of a bzImage, but this is a bit clunky.

Right now I am open to suggestions on how to best achieve the end-goal of a BIOS-less U-Boot direct-booting a Linux kernel.

Issue #2 follows on somewhat - Once all the 'Real Mode' code is removed, we are left with a pretty clean U-Boot.bin apart from the reset vector stub which, as recent patches have shown, is trivial to exclude from the build. U-Boot already supports direct execution from RAM by simply loading U-Boot.bin to CONFIG_SYS_TEXT_BASE and jump to CONFIG_SYS_TEXT_BASE. U-Boot will even relocate itself. But I think that there is some improvements that could be made. For example:

- How to tell U-Boot the amount of memory available (or even the complete E820 memory map to be passed to Linux) - How to load U-Boot into upper-memory and perform the relocation adjustments directly (like the relocatable Linux kernel) - Passing hardware information (PCI interrupt routing etc) to U-Boot so U-Boot does not have to re-probe hardware

The approach to chain loading U-Boot is still very open-ended to me, but we still need to keep in mind that U-Boot must remain capable of being the 'primary' bootloader for x86 platforms

So in summary, I'm 'all ears' on suggestions - not only on the above, but on anything relating to the direction(s) x86 U-Boot should head. Any input is greatly appreciated

Regards,

Graeme