[coreboot] GSoC project(SCSI boot)__status report

Joseph Smith joe at settoplinux.org
Wed Jun 18 03:25:59 CEST 2008

On Wed, 18 Jun 2008 01:04:49 +0200, Stefan Reinauer <stepan at coresystems.de>
> 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?

Joseph Smith

More information about the coreboot mailing list