On Tue, 17 Jun 2008 21:25:59 -0400, Joseph Smith joe@settoplinux.org wrote:
On Wed, 18 Jun 2008 01:04:49 +0200, Stefan Reinauer stepan@coresystems.de wrote:
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!
That's sweet, great work:-)
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.
I think we all came to an agreement that the only "real" way to do this
is
integrate legacybios (or parts) into coreboot (as an option of course).
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.
How would one go about this? You lost me here?
(off topic) Speaking of INT19 I found this neat little article on INT19 and the
master
boot record. Maybe it helps in some way?
Oops here it is: http://www.dewassoc.com/kbase/hard_drives/master_boot_record.htm