Hi,
The latest git version of legacybios now supports building an elf payload. I've successfully booted it using coreboot-v3 under qemu.
Note that the payload likely wont work on real hardware - see my previous email on legacybios and coreboot.
To build, pull the latest legacybios from git (see http://git.linuxtogo.org ) and run make. The resulting elf payload will be in out/bios.bin.elf. I've also placed a payload (with serial debugging) at:
http://linuxtogo.org/~kevin/legacybios/bios.bin.elf-20080510
Unfortunately, the payload will not boot on coreboot-v2. It seems v2 will not let one load a binary into the 0xf0000 area:
============================== New segment addr 0xf0000 size 0x10000 offset 0x1000 filesize 0x10000 (cleaned up) New segment addr 0xf0000 size 0x10000 offset 0x1000 filesize 0x10000 No matching ram area found for range: [0x00000000000f0000, 0x0000000000100000) Ram areas [0x0000000000000000, 0x0000000000001000) Reserved [0x0000000000001000, 0x00000000000f0000) RAM [0x00000000000f0000, 0x0000000000100000) Reserved [0x0000000000100000, 0x0000000008000000) RAM Can not load ELF Image. ==============================
Some sample v3 messages:
============================== LAR: CHECK normal/payload/segment0 @ 0xfffc3e30 start 0xfffc3e80 len 23167 reallen 65536 compression 1 entry 0x000f6c90 loadaddress 0 x000f0000 LAR: Compression algorithm #1 (lzma) used LAR: Attempting to open 'normal/payload/segment1'. LAR: Start 0xfffc0000 len 0x40000 LAR: seen member normal/option_table LAR: seen member normal/initram/segment0 LAR: seen member normal/stage2/segment0 LAR: seen member normal/stage2/segment1 LAR: seen member normal/stage2/segment2 LAR: seen member normal/payload/segment0 LAR: seen member bootblock LAR: File not found! LAR: load_file: No such file 'normal/payload/segment1' LAR: load_file_segments: All loaded, entry 0x000f6c90 Start bios BIOS - begin
Starting rombios32 ==============================
-Kevin
On Sat, May 10, 2008 at 04:04:47PM -0400, Kevin O'Connor wrote:
The latest git version of legacybios now supports building an elf payload. I've successfully booted it using coreboot-v3 under qemu.
Great news!
The resulting elf payload will be in out/bios.bin.elf.
Request changing that name to legacybios.bin.elf ?
//Peter
Hi Peter,
On Sun, May 11, 2008 at 12:59:02AM +0200, Peter Stuge wrote:
On Sat, May 10, 2008 at 04:04:47PM -0400, Kevin O'Connor wrote:
The latest git version of legacybios now supports building an elf payload. I've successfully booted it using coreboot-v3 under qemu.
Great news!
Thanks.
The resulting elf payload will be in out/bios.bin.elf.
Request changing that name to legacybios.bin.elf ?
I'm not very happy with the name "legacybios". I'm still trying to come up with a good name. Until then, I've resisted putting "legacybios" anywhere in the source code.
But yes, I agree the final target could be better labeled.
-Kevin
On 11.05.2008 08:32, Kevin O'Connor wrote:
Hi Peter,
On Sun, May 11, 2008 at 12:59:02AM +0200, Peter Stuge wrote:
On Sat, May 10, 2008 at 04:04:47PM -0400, Kevin O'Connor wrote:
The resulting elf payload will be in out/bios.bin.elf.
Request changing that name to legacybios.bin.elf ?
I'm not very happy with the name "legacybios". I'm still trying to come up with a good name. Until then, I've resisted putting "legacybios" anywhere in the source code.
What about "bios-services" or "bios-ints" or "compat-bios" or "bios16" or "bios-layer"?
Regards, Carl-Daniel
Hi Kevin,
wow, this is sooo awesome!
On 10.05.2008 22:04, Kevin O'Connor wrote:
The latest git version of legacybios now supports building an elf payload. I've successfully booted it using coreboot-v3 under qemu.
Note that the payload likely wont work on real hardware - see my previous email on legacybios and coreboot.
To build, pull the latest legacybios from git (see http://git.linuxtogo.org ) and run make. The resulting elf payload will be in out/bios.bin.elf. I've also placed a payload (with serial debugging) at:
http://linuxtogo.org/~kevin/legacybios/bios.bin.elf-20080510
Some sample v3 messages:
============================== LAR: CHECK normal/payload/segment0 @ 0xfffc3e30 start 0xfffc3e80 len 23167 reallen 65536 compression 1 entry 0x000f6c90 loadaddress 0 x000f0000 LAR: Compression algorithm #1 (lzma) used LAR: Attempting to open 'normal/payload/segment1'. LAR: Start 0xfffc0000 len 0x40000 LAR: seen member normal/option_table LAR: seen member normal/initram/segment0 LAR: seen member normal/stage2/segment0 LAR: seen member normal/stage2/segment1 LAR: seen member normal/stage2/segment2 LAR: seen member normal/payload/segment0 LAR: seen member bootblock LAR: File not found! LAR: load_file: No such file 'normal/payload/segment1' LAR: load_file_segments: All loaded, entry 0x000f6c90 Start bios BIOS - begin
Starting rombios32
Thanks for doing this work! I'm looking forward to the day when this works on real hardware.
Regards, Carl-Daniel
-----Original Message----- From: coreboot-bounces+mylesgw=gmail.com@coreboot.org [mailto:coreboot- bounces+mylesgw=gmail.com@coreboot.org] On Behalf Of Kevin O'Connor Sent: Saturday, May 10, 2008 2:05 PM To: Coreboot Subject: [coreboot] elf payload legacybios - boots on v3 in qemu
Hi,
The latest git version of legacybios now supports building an elf payload.
I like the simplicity of your approach. Very nice.
Note that the payload likely wont work on real hardware - see my previous email on legacybios and coreboot.
Should we make an option to build just the 16-bit version of the BIOS. It seemed more forgiving on real hardware. It seems like there is a lot more that is board-specific in the 32-bit version.
BTW, have you listed the board-specific components anywhere? I don't remember seeing one.
1. Memory map 2. ACPI tables 3. Boot configuration settings (CMOS settings in Bochs) ...
It seems like it would be nice to be able to separate the board-specific information into files that could be read in at build time. It would also be nice to be able to configure the boot order, etc.
Another way to go would be to go back to a loader/wrapper that would copy the BIOS to the correct locations, and copy a memory map to the right spot. This would fix the problem with the v2 build.
Thanks, Myles
To build, pull the latest legacybios from git (see http://git.linuxtogo.org ) and run make. The resulting elf payload will be in out/bios.bin.elf. I've also placed a payload (with serial debugging) at:
http://linuxtogo.org/~kevin/legacybios/bios.bin.elf-20080510
Unfortunately, the payload will not boot on coreboot-v2. It seems v2 will not let one load a binary into the 0xf0000 area:
============================== New segment addr 0xf0000 size 0x10000 offset 0x1000 filesize 0x10000 (cleaned up) New segment addr 0xf0000 size 0x10000 offset 0x1000 filesize 0x10000 No matching ram area found for range: [0x00000000000f0000, 0x0000000000100000) Ram areas [0x0000000000000000, 0x0000000000001000) Reserved [0x0000000000001000, 0x00000000000f0000) RAM [0x00000000000f0000, 0x0000000000100000) Reserved [0x0000000000100000, 0x0000000008000000) RAM Can not load ELF Image. ==============================
Some sample v3 messages:
============================== LAR: CHECK normal/payload/segment0 @ 0xfffc3e30 start 0xfffc3e80 len 23167 reallen 65536 compression 1 entry 0x000f6c90 loadaddress 0 x000f0000 LAR: Compression algorithm #1 (lzma) used LAR: Attempting to open 'normal/payload/segment1'. LAR: Start 0xfffc0000 len 0x40000 LAR: seen member normal/option_table LAR: seen member normal/initram/segment0 LAR: seen member normal/stage2/segment0 LAR: seen member normal/stage2/segment1 LAR: seen member normal/stage2/segment2 LAR: seen member normal/payload/segment0 LAR: seen member bootblock LAR: File not found! LAR: load_file: No such file 'normal/payload/segment1' LAR: load_file_segments: All loaded, entry 0x000f6c90 Start bios BIOS - begin
Starting rombios32
-Kevin
-- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Hi Myles,
On Mon, May 12, 2008 at 12:38:20PM -0600, Myles Watson wrote:
Note that the payload likely wont work on real hardware - see my previous email on legacybios and coreboot.
[...]
BTW, have you listed the board-specific components anywhere? I don't remember seeing one.
I was referring to the email at:
http://www.coreboot.org/pipermail/coreboot/2008-May/034254.html
[...]
Should we make an option to build just the 16-bit version of the BIOS. It seemed more forgiving on real hardware. It seems like there is a lot more that is board-specific in the 32-bit version.
Currently the "post" section is compiled in 32bit mode. This "post" stage includes initialization of the bios working storage area, so we can't entirely skip it.
Instead of moving more code to 16bit mode, I think we should just have options to leave out unwanted features. For example, disabling the call to rombios32_init() in post.c should stop the pcibios init, acpi table creation, and smbios table creation.
- Memory map
- ACPI tables
- Boot configuration settings (CMOS settings in Bochs)
...
It seems like it would be nice to be able to separate the board-specific information into files that could be read in at build time. It would also be nice to be able to configure the boot order, etc.
I'm looking for feedback on exactly the above. There are several ways to support per-board info in "legacybios":
* 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.
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.
-Kevin
-----Original Message----- From: Kevin O'Connor [mailto:kevin@koconnor.net] Sent: Monday, May 12, 2008 1:36 PM To: Myles Watson Cc: 'Coreboot' Subject: Re: [coreboot] elf payload legacybios - boots on v3 in qemu
Hi Myles,
On Mon, May 12, 2008 at 12:38:20PM -0600, Myles Watson wrote:
Note that the payload likely wont work on real hardware - see my previous email on legacybios and coreboot.
[...]
BTW, have you listed the board-specific components anywhere? I don't remember seeing one.
I was referring to the email at:
http://www.coreboot.org/pipermail/coreboot/2008-May/034254.html
[...]
Should we make an option to build just the 16-bit version of the BIOS.
It
seemed more forgiving on real hardware. It seems like there is a lot
more
that is board-specific in the 32-bit version.
Currently the "post" section is compiled in 32bit mode. This "post" stage includes initialization of the bios working storage area, so we can't entirely skip it.
Instead of moving more code to 16bit mode, I think we should just have options to leave out unwanted features. For example, disabling the call to rombios32_init() in post.c should stop the pcibios init, acpi table creation, and smbios table creation.
Sure. I wasn't suggesting that we move code to 16-bit. I was just noting that when I was trying to boot Windows XP on a real box, I got farther with the simpler BIOS because Windows didn't expect as much functionality from it.
I'm looking for feedback on exactly the above. There are several ways to support per-board info in "legacybios":
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:
I think this option is more flexible.
- and c) put them somewhere in memory where legacybios can then copy it to the 0xf0000 segment
I like this one better. It seems more robust.
- 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.
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 think there is enough space in the CMOS to just reserve a portion of it for "legacybios"
Myles
On Mon, May 12, 2008 at 02:46:44PM -0600, Myles Watson wrote:
I'm looking for feedback on exactly the above. There are several ways to support per-board info in "legacybios":
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:
I think this option is more flexible.
- and c) put them somewhere in memory where legacybios can then copy it to the 0xf0000 segment
I like this one better. It seems more robust.
Sounds good to me. The only catch with this method is that the "legacybios" code then needs to know where in memory the info is.
I'm not that familiar with coreboot - is there some way for info to get passed from coreboot to a payload? How can the payload know how much memory is in the system?
- 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.
Thanks. -Kevin
-----Original Message----- From: Kevin O'Connor [mailto:kevin@koconnor.net] Sent: Monday, May 12, 2008 4:14 PM To: Myles Watson Cc: 'Coreboot' Subject: Re: [coreboot] elf payload legacybios - boots on v3 in qemu
On Mon, May 12, 2008 at 02:46:44PM -0600, Myles Watson wrote:
I'm looking for feedback on exactly the above. There are several ways to support per-board info in "legacybios":
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:
I think this option is more flexible.
- and c) put them somewhere in memory where legacybios can then copy it to the 0xf0000 segment
I like this one better. It seems more robust.
Sounds good to me. The only catch with this method is that the "legacybios" code then needs to know where in memory the info is.
I'm not that familiar with coreboot - is there some way for info to get passed from coreboot to a payload? How can the payload know how much memory is in the system?
Peter suggested libpayload. There is a coreinfo browser that extracts this information from coreboot. We could repurpose some of that code to generate the correct tables, then load them and "legacybios" into memory.
An alternative would be to look at the Filo code and see how it generates its memory map to pass to the Linux kernel.
BTW: I think we should call "legacybios" pcbios, or something equally short and descriptive. We could also call it bochsbios, since Bochs will eventually switch :)
Thanks, Myles
On Mon, May 12, 2008 at 03:36:29PM -0400, Kevin O'Connor wrote:
There are several ways to support per-board info in "legacybios":
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.
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.
On a related note I would like to request that we try hard not to touch NVRAM at all unless it is absolutely neccessary.
coreboot needs zero negative impact on previously working systems. Currently v2 will overwrite the NVRAM, making it difficult to switch back and forth between factory BIOS and coreboot in an effortless manner. :\
//Peter
On 13.05.2008 02:59, Peter Stuge wrote:
On Mon, May 12, 2008 at 03:36:29PM -0400, Kevin O'Connor wrote:
There are several ways to support per-board info in "legacybios":
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.
We already have some (external, probably not committed) code to create per-board ACPI tables and other stuff. Having a payload generate this from e.g. the device tree needs a device tree parser in the payload, a thing I'd like to avoid for size reasons. Having a Kconfig option "Generate legacy tables" would be the way to go IMHO.
Regards, Carl-Daniel
On Tue, May 13, 2008 at 03:08:56AM +0200, Carl-Daniel Hailfinger wrote:
I specifically do not want coreboot to know about BIOS tables.
Having a payload generate this from e.g. the device tree needs a device tree parser in the payload, a thing I'd like to avoid for size reasons.
One reason we picked dt in Hamburg was that the binary packed form was very simple to parse. I don't think the size will be a problem.
Having a Kconfig option "Generate legacy tables" would be the way to go IMHO.
Please do not do this. :\ I would consider it a serious regression in coreboot.
The idea is to stay legacy free in order to avoid constraints and actively support and further evolution.
Adding (even optional) legacy support into coreboot feels quite counter-productive. :\
Short-term BIOS support is still needed to be a drop-in replacement.
Slightly-longer-term anything BIOS must be discouraged IMHO.
Kevin, please don't think I dislike your work - it is truly great! But I do hope that it will be a trampoline to better BIOSless boots in the near future.
//Peter
Yes, the goal of dts was that we could, one day, quickly generate anything we want from dts. The binary tree is pretty straightforward I agree with Peter here.
ron
Hi Peter,
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?
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.
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
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
Hi all,
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.
Hmm this is difficult. ACPI is very very complex and if we ever want Suspend to RAM etc then it is inevitable. ACPI is *NOT* legacy. It contains lot of info specific to board/chipset and also about *currently* installed CPU.
So I think legacybios should create the ACPI/MPTABLE/etc when in emulation mode. Otherwise coreboot should handle PIR, MPTABLE + ACPI. The memory map shall be transfered with the coreboot tables. The legacybios can do e820 map from those tables - like FILO does imho.
The trick would be to mark for legacy bios what parts of region 0xf0000-0xfffff are used with the tables already. Or lets say we can put all stuff in first 32kb. second 32kb for legacy bios. Certainly this solution is not cleanest but I think it will work. If coreboot needs more space it can steal some other memory. E.G start with ACPI tables on 0xe0000 and mark it reserved.
There is also problem with SMM code. I think coreboot should have at least handler which returns from SMM and increases some counter. Better then for example when HW monitoring chip triggers SMI because fans runs too slow and freezes the machine because the CPU jumps to nowhere. And also C1E cannot be implemented without SMM. So coreboot should place some SMM handler to some memory too - like ACPI and other tables.
Kevin, does the legacy bios work somehow with coreboot already? Does it have support for IDE on PCI bars :) ?
Thanks, Rudolf
On Fri, May 16, 2008 at 12:16:54AM +0200, Rudolf Marek wrote:
I strongly prefer b) above over anything else.
What you're proposing here is that the payload build all the standard bios tables - mptable, pir, e820 map, smbios, acpi.
So I think legacybios should create the ACPI/MPTABLE/etc when in emulation mode. Otherwise coreboot should handle PIR, MPTABLE + ACPI.
I can see benefits and disadvantages to both sides:
Moving the logic to the payload means coreboot can have one simple unified information passing mechanism. It need not know about all the various bios standards that have been introduced over the years; it need not track new standards as they arise. Unfortunately, it means the payloads may need to dig into the hardware details and this could result in board specific logic spread between coreboot and various payloads. With the tables produced in coreboot it may be possible to build a payload that can work on any x86 target.
The trick would be to mark for legacy bios what parts of region 0xf0000-0xfffff are used with the tables already. Or lets say we can put all stuff in first 32kb. second 32kb for legacy bios.
If you read back to my original email - you seem to be in favor of option "d".
Note that coreboot doesn't need 32KiB for the bios tables - 1KiB should be more than enough. The acpi and smbios stuff only need the initial table directories to exist in the 0xf0000 area. The rest of the info can exist anywhere in ram.
Kevin, does the legacy bios work somehow with coreboot already? Does it have support for IDE on PCI bars :) ?
One can launch the latest "legacybios" elf payload with coreboot-v3 under qemu. I haven't tested it on real hardware.
I'm not sure what "IDE on PCI bars" means. The code does attempt to access the IDE controller in PIO mode via IO ports (eg, 0x1f0, 0x3f0 for the first channel).
-Kevin
Kevin,
Could we do something simple like not use the CMOS for Coreboot, but use a place in the EBDA to be "CMOS"? I realize that we won't be able to set it permanently like real CMOS, but we could configure it from a libpayload payload. If we put the cmos section above the ata_s structure it would be in a fixed place, which would probably help.
Thanks, Myles
Hi Myles,
On Tue, May 13, 2008 at 08:48:59AM -0600, Myles Watson wrote:
Could we do something simple like not use the CMOS for Coreboot, but use a place in the EBDA to be "CMOS"? I realize that we won't be able to set it permanently like real CMOS, but we could configure it from a libpayload payload. If we put the cmos section above the ata_s structure it would be in a fixed place, which would probably help.
The inb/outb_cmos functions are used for other functions besides accessing nvram. Redirecting these functions would cause the clock functions to cease working.
Most of the uses of nvram in "legacybios" is as a mechanism to pass data from the emulator to the guest.
There are only two nvram variables that are read and written by "legacybios":
CMOS_RESET_CODE (0x0f) - this is used to implement some sort of "resume" functionality. However, since the bios doesn't implement the corresponding "suspend", I'm not sure it's really useful.
CMOS_CENTURY (0x32) - this stores part of the date that doesn't fit in the rtc - the '20' in 2008. I suppose we could hard code this if we really didn't want to store it in the nvram.
There are several nvram values that are only read by "legacybios":
CMOS_FLOPPY_DRIVE_TYPE (0x10) - this appears to be a standard - even linux uses it.
CMOS_EQUIPMENT_INFO (0x14) - I think we can remove this dependency - almost everything in it is already auto-detected.
CMOS_BIOS_DISKTRANSFLAG (0x39) - This controls how the bios maps disk CHS calls to LBA. I think this may be auto-detected - if not, it can be passed in via coreboot.
CMOS_DISK_DATA (0x12) hd geometry (0x19 - 0x2c) - These settings can and should be auto-detected from the ide drive.
CMOS_MEM_EXTMEM_LOW (0x30) CMOS_MEM_EXTMEM_HIGH (0x31) CMOS_MEM_EXTMEM2_LOW (0x34) CMOS_MEM_EXTMEM2_HIGH (0x35) - These are used as a mechanism for passing system memory size.
CMOS_BIOS_BOOTFLAG1 (0x38) CMOS_BIOS_BOOTFLAG2 (0x3d) - These are used to control boot flags and boot order.
So, I think "legacybios" should have a simple test at startup - when in bochs/qemu mode read the above nvram variables and store them in internal storage; when in coreboot mode gather the info from coreboot and store them in internal storage and avoid using nvram.
-Kevin
On Tue, May 13, 2008 at 08:48:59AM -0600, Myles Watson wrote:
Could we do something simple like not use the CMOS for Coreboot, but use a place in the EBDA to be "CMOS"? I realize that we won't be able to set it permanently like real CMOS, but we could configure it from a libpayload payload. If we put the cmos section above the ata_s structure it would be in a fixed place, which would probably help.
The inb/outb_cmos functions are used for other functions besides accessing nvram. Redirecting these functions would cause the clock functions to cease working.
I'm surprised. It seems like as long as we redirect them to storage that's initialized correctly the BIOS wouldn't care where it was stored.
Most of the uses of nvram in "legacybios" is as a mechanism to pass data from the emulator to the guest.
There are only two nvram variables that are read and written by "legacybios":
CMOS_RESET_CODE (0x0f) - this is used to implement some sort of "resume" functionality. However, since the bios doesn't implement the corresponding "suspend", I'm not sure it's really useful.
CMOS_CENTURY (0x32) - this stores part of the date that doesn't fit in the rtc - the '20' in 2008. I suppose we could hard code this if we really didn't want to store it in the nvram.
There are several nvram values that are only read by "legacybios":
CMOS_FLOPPY_DRIVE_TYPE (0x10) - this appears to be a standard - even linux uses it.
CMOS_EQUIPMENT_INFO (0x14) - I think we can remove this dependency - almost everything in it is already auto-detected.
CMOS_BIOS_DISKTRANSFLAG (0x39) - This controls how the bios maps disk CHS calls to LBA. I think this may be auto-detected - if not, it can be passed in via coreboot.
CMOS_DISK_DATA (0x12) hd geometry (0x19 - 0x2c) - These settings can and should be auto-detected from the ide drive.
CMOS_MEM_EXTMEM_LOW (0x30) CMOS_MEM_EXTMEM_HIGH (0x31) CMOS_MEM_EXTMEM2_LOW (0x34) CMOS_MEM_EXTMEM2_HIGH (0x35) - These are used as a mechanism for passing system memory size.
CMOS_BIOS_BOOTFLAG1 (0x38) CMOS_BIOS_BOOTFLAG2 (0x3d) - These are used to control boot flags and boot order.
Great summary, thanks.
So, I think "legacybios" should have a simple test at startup - when in bochs/qemu mode read the above nvram variables and store them in internal storage; when in coreboot mode gather the info from coreboot and store them in internal storage and avoid using nvram.
Yes.
Have you looked at libpayload at all? I was looking at coreinfo, and it seems to have access to all the information we need.
Thanks, Myles
-
Carl-Daniel Hailfinger -
Kevin O'Connor -
Myles Watson -
Peter Stuge -
ron minnich -
Rudolf Marek