[coreboot] GSoC project(SCSI boot)__status report

[Joseph Smith]

On Tue, 17 Jun 2008 21:25:59 -0400, Joseph Smith <joe at settoplinux.org>
wrote:
> 
> 
> 
> On Wed, 18 Jun 2008 01:04:49 +0200, Stefan Reinauer
> <stepan at 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

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org