[coreboot] CoreBIOS: a viable option for me?

Brendan Trotter btrotter at gmail.com
Mon Jan 28 21:04:28 CET 2008


On 1/27/08, Peter Stuge <peter at stuge.se> wrote:
> What, specifically, do you need?

For long-term viability, I need something (e.g. a formal
specification) that gives guarantees on the (past, present and future)
behaviour that a payload can expect from Coreboot, which includes
considerations for both forward and backward compatability.

> So far there is the coreboot table with some information about the
> system, and payloads are 32-bit elf binaries.

Yes, and the structure used by entries in the coreboot table is a good
start (e.g. "type + length + data", where unrecognised entries defined
in later versions of coreboot can easily be skipped by older payloads
that don't recognise these entries). But this alone isn't enough, as
nothing says which entries are optional and which entries are
required, nothing says which data values are permitted for each entry
type, and nothing guarantees that "coreboot version N+1" won't use
entirely different entries or an entirely different structure.

Payloads are 32-bit (and maybe 64-bit, and possibly compressed?) elf
binaries, but does coreboot support relocations? If the payload is
linked to be loaded at the fixed address 0x40000000 will it work if
the computer only has 128 MB of RAM? What happens if the payload's
main function returns to coreboot? Which arguments are passed to the
payload's main function?

> Perhaps the best solution for you is to write a special loader
> payload that abstracts away coreboot and then hands over to your
> main application?

That is what I'd like to do. However, there's a difference between
writing one special loader payload for all versions of
coreboot/LinuxBIOS, and writing many seperate payloads (one for each
different version of coreboot/LinuxBIOS) while also monitoring the
coreboot mailing list and contantly maintaining my code to keep up
with changes.

On 1/27/08, Peter Stuge <peter at stuge.se> also wrote:
> It would be great if you would help create this.

I wouldn't consider it appropriate for a relative stranger who has no
intention of becoming a project member/developer (ie. me) to create a
specification that all future versions of coreboot must comply with.
This sort of specification is something the project leader should
write (or IMHO, should have written).

There is a compromise here though: I'm willing to write a *draft*
specification (in HTML format), that coreboot project members could
use as a reference or as the basis for their own specification. The
draft specification would be mostly a work of fiction - something that
specifies how I would do things if I was doing things, rather than
something that specifies how coreboot members will do things or how
coreboot members have done things...



More information about the coreboot mailing list