On Tue, May 13, 2008 at 02:59:46AM +0200, Peter Stuge wrote:
On Mon, May 12, 2008 at 03:36:29PM -0400, Kevin O'Connor wrote:
Have legacybios populate the information:
By a) compiling legacybios on a board by board basis with info for each board merged into the compile process
or b) have the info passed to legacybios from corebios in some raw format, and then have legacybios build the PC specific tables from it
or, have coreboot build the PC specific tables:
and c) put them somewhere in memory where legacybios can then copy it to the 0xf0000 segment
or d) work out some arrangement where coreboot puts them into 0xf0000 in such a way that legacybios doesn't overwrite those areas when it is also loaded into that segment.
I strongly prefer b) above over anything else. I specifically do not want coreboot to know about BIOS tables. coreboot already exports some information. If legacybios needs more information, let's add that to the coreboot tables.
What you're proposing here is that the payload build all the standard bios tables - mptable, pir, e820 map, smbios, acpi. I'm okay with this - it makes sense to me. However, I didn't get the feeling there was a general consensus that this logic should move from coreboot to the payloads.
In any case, there is a catch with doing this - some info is unlikely to be found in the dts (eg, the acpi aml code). This would require we build it into the payload (or somehow get it into a segment for lar to extract).
An alternative would be to have the payload callback into the lar functions to extract and uncompress a segment with the info. Is this okay for a payload to do?
I don't think we want to call coreboot's lar functions. Using libpayload for that would be a lot cleaner.
As you also mention, there are some useful configuration items (eg, boot order and floppy drive type). We can either:
a) have coreboot select and configure this and pass the info to legacybios in some way
or b) have legacybios set it in the cmos and present a menu during boot where the user can change the options (eg, "Press [DEL] to enter bios setup".
I'm looking for feedback from the coreboot developers on what the best answers to the above questions are.
Likewise I prefer a) here.
Okay. These are configurable items though, so it naturally means that users need to be able to change them. This will require a payload (or OS app) be capable of writing parts of the flash chip to change the configuration items.
Is there anything that needs to be configurable after build time?
Thanks, Myles
On a related note I would like to request that we try hard not to touch NVRAM at all unless it is absolutely neccessary.
Bochs bios and "legacybios" don't really use the nvram that much. I'll follow up in a separate email.
-Kevin
-- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot