Kevin O'Connor wrote:
On Mon, Jun 16, 2008 Stefan Reinauer wrote:
Zhang Rui is working for Google Summer of Code on booting off SCSI using option roms with coreboot; He will be cleaning up the legacy bios infrastructure parts in coreboot and make sure LegacyBIOS can easily be used. It would be great if you could help him in case we are in need of someone who knows Legacy BIOS really well!
Sure. I'd prefer to cc a mailing list though - it increases overall awareness. Either coreboot or bochs lists would be fine.
Ok, let's CC coreboot.org on this one.
The code in util/x86emu/ should then be modified to
- look for that file in the "lar"
- copy it to 0xf0000
- use it instead of the current handlers
I have a question, what is the exact address of each handler function in the legacybios of Qemu/Bochs? Does the legacybios bin begin with the int0 call so the address of intXX call can be calculated from the beginning of legacybios bin?
Look for the ".org" strings in rombios.c of bochs bios. Or, with LegacyBIOS, look for all the "entry_xxx" functions in src/romlayout.S. See:
http://git.linuxtogo.org/?p=kevin/legacybios.git;a=blob;f=src/romlayout.S;h=...
These define the entry points of the bios. You definitely do _not_ want to use the fixed addresses. The one exception is f000:fff0 - which is the standard 16bit entry point for the "post" code of the bios.
Ok, this is good.
Here's the first question to Kevin: How can we install the LegacyBIOS interrupt handlers in order to call a single option rom and return back to coreboot scope?
I'm slightly confused by your use of "legacy bios" and "LegacyBIOS".
:-) sorry, i will try to be more clear ..
The latest code I've written (I'll call in LegacyBIOS) produces an elf file with a 32bit entry point. It works as a standard payload with coreboot.
How will this work? Is there a piece of 32bit code that will copy the rest of LegacyBIOS to 0xf0000?
Is there a way to produce a "bios.bin" image that can be copied to 0xe0000 or 0xf0000 and still has all the coreboot stuff in it?
In the general case, to use the 16bit handlers you need to run the code contained in the "post" section. See:
http://git.linuxtogo.org/?p=kevin/legacybios.git;a=blob;f=src/post.c;h=766e8...
This code initializes the BDA and EBDA memory areas - including the idt table. However, the last part of "post" will attempt to boot the system (by calling int19). If you want to "post" without booting, you'd need to extend LegacyBIOS to return to coreboot somehow.
Ok. what would be the best way to do this? create a well known entry point, similar to the reset vector?
Is there a particular reason you'd want to return to coreboot?
Yes: Currently VGA initialization in coreboot is done with a mix of [vm86|x86emu] and half a intXX callback layer good enough to cope with most graphics cards.
To make this really good, we'd need to heavily extend that intXX callback code in coreboot. Which means it has to grow and grow and it will eventually become a reduced version of LegacyBIOS. That is bad. If we know LegacyBIOS does a pretty good job and it is reasonably small (even qemu's current bios.bin is under 30k with , I would really prefer using it for that task instead of yet another half-baked solution.
But when LegacyBIOS is supposed to replace the current intXX layer, it has to return after doing its initialization, possibly it has to do everything in _start() up and including the call to post().
The current option rom handling in post() may not be sufficient to initialize all option roms in a system, as the current coreboot v3 code is able to load an option rom for a given device from the "lar" archive, copy it to the option rom area and execute it from there. This way we can easily support an arbitrary number of onboard devices with option roms. But when jumping into LegacyBIOS, not all option roms may be visible in the address space at the same time.
I guess what I am suggesting is to split the bootmenu + OS loader (int19) part from the init part.
This way we can still provide the option rom initialization via LegacyBIOS' intXX callbacks but do not force the user to also use its int19 boot code, but can instead jump into another payload - for example UEFI or GRUB2 in flash.
What we have to find out is: Do we have to preserve much at all? Maybe it is enough to install legacybios to 0xf0000 and let it live there, then the payloads could just use intXX calls, as they can with a non-free bios installed. But maybe it is not that trivial.
As above, some of the interrupt handlers may run okay without "post" running. However, several of them want to access the Bios Data Area (BDA) and Extended Bios Data Area (EBDA). Basically, these are the working storage areas of the bios. The "post" code is what initializes these memory areas.
[...]
Ok, I think this is much clearer now.
Could we preserve 0xf0000 for the legacybios? If we can put coreboot table and ACPI tables and something else in the low 1M of RAM, it will be a good job. How much space will these tables take? I mean coreboot table and ACPI tables.
What I'm currently doing is having coreboot build the tables somewhere high in memory, and then having LegacyBIOS move the tables that need to be in 0xf0000 down to that area.
Do you have a list of tables that need to live at 0xf0000? I know at least a lot of ACPI can live pretty high up. coreboot table currently resides at 0x530 or 0x500 but it is not very well placed there.
Stefan