[coreboot] coreboot BIOSisms
Kevin O'Connor
kevin at koconnor.net
Tue Jun 10 04:18:35 CEST 2008
On Mon, Jun 09, 2008 at 07:03:46PM +0200, Peter Stuge wrote:
> On Sun, Jun 08, 2008 at 11:37:40PM -0400, Kevin O'Connor wrote:
> > http://www.coreboot.org/pipermail/coreboot/2008-May/034688.html
> >
> > I'm basically advocating option (c).
>
> Do we really want these BIOS tables to be created by coreboot?
>
> If yes, why shouldn't LegacyBIOS simply be included in coreboot?
>
> If no, how can we fix that?
Hi Peter,
I'm torn on this question myself. I can see both sides of the issue.
I do think there are some high-level requirements:
* These tables (PIR, mptable, acpi, smbios) need to be generated one
way or another. All the major OSs in use today need them - a
machine that can not run all the major OSs is at a distinct
disadvantage in the market place.
* It is a bad idea to force legacybios (or any payload) to be board
specific. Doing so would require vendors to commit code to multiple
repos. It would fragment the development efforts and lead to
confusion.
* Most of the info in the tables can not be reasonably auto-detected
by the payload. Thus, one way or another, the info needs to be
passed into them.
* It makes no sense to have coreboot export info in a coreboot
specific format if that info is used purely by the payload to export
it in a different format. For example, consider the smbios "system
enclosure" table - neither coreboot nor legacybios have any need to
know how many power cords are attached to the machine. Making a
coreboot "num power cords" field just so legacybios can translate
that to the smbios field is a waste. (There are plenty of these
information fields - take a look at the acpi and smbios specs.)
Given the above, I see two possibilities.
The first involves having coreboot build the standard tables. As was
discussed, this exposes coreboot to some ugliness.
The second would involve passing a few key pieces of info to the
payload and then have the payload build the tables with just the bare
minimum amount of data. This is what bochs/qemu do today, and it
seems to work reasonably well. Most of the fields seem pointless
anyway - for example, I can't imagine why an app would care how many
power cords the machine had - and if it did care, I can't imagine it
would trust the bios.
Unfortunately, one big issue with option two is that there is no good
way to pass these ad-hoc values to the payload today. Some of the
larger blobs (eg, the AML code) could be put into a lar segment.
However, v2 doesn't support LAR. Many of the smaller fields (eg, num
cpus, uuid, apic address) are too ad-hoc and numerous to pass via
coreboot tables. (And again, why define a new coreboot table if we can
reuse an already defined acpi/mptable table?)
I'm open to ideas.
-Kevin
More information about the coreboot
mailing list