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

Kevin O'Connor kevin at koconnor.net
Wed May 11 02:38:37 CEST 2011

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():


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

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


More information about the coreboot mailing list