[U-Boot] Future direction of the x86 architecture in U-Boot

[Graeme Russ]

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.html

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