[coreboot] CoreBIOS: a viable option for me?

Peter Stuge peter at stuge.se
Tue Jan 29 00:38:08 CET 2008

Hi again Brendan,

On Mon, Jan 28, 2008 at 08:04:28PM +0000, Brendan Trotter wrote:
> 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.

This is not very specific, quite the contrary this is completely
generic. I asked so you can tell us what you would like.

> 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,

Very true.

> 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?

Is this functionality that you need?

> What happens if the payload's main function returns to coreboot?
> Which arguments are passed to the payload's main function?

The payload can not return. Coreboot does not leave a return address
on the stack. When the payload is started, Coreboot is history.

> 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

I disagree. This is one great thing about open source.

Specifically because noone else has created what you need, it is not
only appropriate but also encouraged if you, however strange you are,
would contribute on the matter. With that contribution (and actually
with this discussion) I already consider you a member of the project.
All is not code.

> that all future versions of coreboot must comply with.

I think this is a separate discussion. I realize it is crucial to
you, but perhaps the discussion can lead to new innovations which
can loosen requirements.

> This sort of specification is something the project leader should
> write (or IMHO, should have written).

That's not really a community development model, is it? That sounds
like a very hiearchichal model, which is not too common in small
projects like our own.

Open source for me is all about anyone and everyone contributing
whatever they can when they can and want to.

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

As you may have noticed from following the list, this is exactly how
we work - someone makes a suggestion, people iterate on it and
discuss, eventually arriving at code, or the trashcan. :)

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

I think it would be awesome if you could do that! No need to make it
fancy, a plain text email to the list is perfectly fine. (And may
actually be prefered over HTML for some project members.)


More information about the coreboot mailing list