[U-Boot] [RFC][PATCH 00/21] [x86] 'Comming of Age'

[Graeme Russ <graeme.russ@gmail.com>]

Peter Tyser wrote:
> < snip>
> 
>> Once this patchset is applied I believe the x86 port of U-Boot will be
>> ready for more mainstream use
>>
>> Wolfgang - If there is any other renewed interest in the x86 port, I would
>> be more than happy to be an official custodian
> 
> Hi Graeme,
> Is there a quick summary about what is supported, how its used, etc?  Eg
> could x86 U-Boot replace the BIOS on on chipset X, similar to coreboot?
> Or is it a 2nd stage bootloader like GRUB?  Or a bootloader that is run
> from GRUB?  How hard would it be to port to other x86 platform?

The x86 U-Boot port, like all other U-Boot ports, is a primary boot loader
for embedded systems. As such, it is designed to bring a board up from
power-on/cold reset to a state where Linux (or other OS) can execute (e.g
load FPGAs, configure hardware address and I/O structures etc). The closest
'in-the-wild' comparative software would be RedBoot.

The current implementation is designed around the AMD SC520 ELAN CPU, but
porting to other x86 CPUs and boards should be fairly simple. Porting is
made easier if the target is PC/AT centric. That said, the modular design
should allow for very easy diversion from PC/AT.

It does not (and will not) replace the BIOS of a regular PC (Coreboot) nor
will it be a second stage bootloader (GRUB). However, at a pinch, I imagine
you could use it to boot a VIA mini-ITX board for example.

> It seems like cool stuff, I'm just trying to wrap my head around the
> high-level concept of U-Boot on x86 and where/why it'd be used instead
> of the "standard" alternatives.

x86 is a poor second cousin to PPC and ARM in the embedded world. The
reasons for this are many and varied, but generally speaking ARM and PPC
are better suited to the embedded world due to lower power consumption and
integrated peripherals. x86 has its advantages (no need for cross
compiling, easier to simulate and a PC without using QEMU etc).

x86 U-Boot does do a few things though that I think are very special:
 - It fully relocates itself to the highest available RAM (including
Read-Only data and special data structures like the GDT and IDT which are
sometimes overlooked)
 - It can be fail-safe boot-strapped from RAM (i.e. boot an old version
from power-up, tftp a new version, jump to the new version)

In the near future, I intend to make it 100% relocatable (i.e. does not
need to be loaded at TEXT_BASE) and maybe even add the ability to specify
the relocation address.

> 
> Thanks,
> Peter
> 

Your welcome :)
Graeme