[coreboot] coreboot BIOSisms

[Peter Stuge]

On Wed, Jun 11, 2008 at 12:22:32AM -0400, Kevin O'Connor wrote:
> On Wed, Jun 11, 2008 at 04:17:49AM +0200, Peter Stuge wrote:
> > By creating a good intermediate format, we will eventually be able to
> > replace many if not all BIOSisms with something better documented,
> > maybe even something simpler and certainly something nicer.
> 
> This is why I'm "torn" on the issue.  I can see the value in a good
> intermediate format - one that would allow coreboot to easily
> export a wide variety of static and dynamic data.
> 
> Unfortunately, I don't believe there is a good intermediate format
> available today.

That's right. It doesn't exist yet.


> LAR looks nice, but it only seems useful for large blobs and it
> isn't supported by v2.

And LAR has been heavily optimized for flash, so is probably not the
best candidate.


> The coreboot table is effectively the same technology as the binary
> ACPI/pir/mptable/smbios tables.  I don't see a compelling advantage
> to defining new coreboot tables over using existing standard
> tables.

For one thing, there would be a single table instead of many.


> > Staying true to the design that coreboot is not a BIOS, but
> > something better.
> 
> I'm not really sure what that means.  Coreboot doing something
> different from a "BIOS" does not inherently mean that coreboot is
> better.

I think it does, just because "BIOS" is so old and implies many other
things. I consider doing even almost the same thing but with a new
name and more together to be a big improvement.
(Basically what coreboot is all about.)


> So, if there is an intermediate format with compelling features -
> then I'm all for it.

Would you be interested in helping with development of that format,
or do you only wish to use it when it becomes available?


> But, if a new intermediate format is just different or only
> slightly better - then I'd recommend using the existing standards.

The container format can't be very different - it will still be one
data structure in RAM.

But could the contents be improved upon?

Of course, as mere producers we don't care too much, it would be
interesting to discuss also with the consumers.

One consumer opinion is "why change what works" which is
understandable, but is it really the only one?


//Peter