[coreboot] CoreBIOS: a viable option for me?

[Carl-Daniel Hailfinger]

Hi,

On 28.01.2008 21:04, 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.
>   

A forked version of Elfboot would be a good way to achieve that. You'd
have to port that fork to newer coreboot versions, though. Or adopt my
suggestion below and use Linux.

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

Exactly. That's why you don't want the eternal interface guarantee from
coreboot, but from a payload which serves as abstraction layer and can
be modified according to your liking.

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

Depends on the coreboot version, on how much memory was clobbered,
whether the payload reconfigured the chipset, etc.

> Which arguments are passed to the
> payload's main function?
>   

None, mostly.

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

We don't guarantee any interface stability. Doing that would be insane.
We don't actively try to break the interface, but...
There are many new and exciting developments in the area of passing
information from firmware to operating systems. The field is not mature
enough for painless standardization.

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

Such a specification is only appropriate once the majority of boards on
the market are supported, possibly including boards for architectures
besides x86. I do NOT expect any formally binding specification at least
for the next two years.

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

There is one very easy way out:
Linux.
The Linux kernel guarantees most of its userspace interfaces to be
stable for years, if not decades.
Coreboot will be able to launch Linux as a payload for the foreseeable
future. Implement your code as Linux userspace software and be happy.


Regards,
Carl-Daniel