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