[coreboot] [U-Boot] U-Boot-x86 / coreboot Integration

[Kevin O'Connor]

On Wed, May 11, 2011 at 10:11:41AM +1000, Graeme Russ wrote:
> On Wed, May 11, 2011 at 4:03 AM, Wolfgang Denk <wd at denx.de> wrote:
> > In message <4DC94CD4.2050904 at gmail.com> you wrote:
> >>  - coreboot payloads should be in ELF (linked to libpayload)
> >
> > Is this really necessary, assuming we have a self-contained payload
> > that does not request any services from the tool that was used to
> > start it?
> 
> Question for the coreboot guys. I think the linkage to libpayload can be
> omitted, but include enough of libpayload to get to the coreboot data
> structures which can tell U-Boot vital information regarding the hardware.
> 
> Also see below - If it's loading an ELF image, can't it just pass a
> parameter which points to the tables?

Finding and parsing the coreboot tables is trivial - SeaBIOS does it
in ~170 lines of code.  See coreboot_fill_map():

http://code.coreboot.org/p/seabios/source/tree/master/src/coreboot.c#L126

Note, SeaBIOS is deployed as a coreboot payload, but it does not use
libpayload.

[...]
> >>  - Can we add relocation support to the coreboot ELF loader?
> >
> > Do we have to?
> 
> If we want U-Boot at top-of RAM and avoid a second memcpy then yes,
> but as we know, it is not as simple as that. U-Boot relocates after it
> has determined how much upper memory to reserve which isn't known until
> U-Boot has enumerated it's hardware environment. Hence the reason U-Boot
> will always have to suffer the penalty of the extra memcpy (the bootstrap
> loader does not have enough information to reserve this memory for U-Boot)

If U-Boot can already relocate itself to top-of-ram, then I'd reuse
that - it can always be optimized later.

Note, SeaBIOS can also relocate part of itself to high memory.
(Though, SeaBIOS is pretty small, so the memcpy costs are trivial.)

-Kevin