[coreboot] GSoC project(SCSI boot)__status report

[独败]

2008/6/18 Stefan Reinauer <stepan at coresystems.de>:


> 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.

It seems that the LegacyBIOS is a elf file after building.

So I think there may be two way:
1. Integrate LegacyBIOS (or parts) into coreboot.
2. Let LegacyBIOS be a payload of coreboot and let LegacyBIOS to run
other payload. (This needs us to init the option rom and install a
special handler in LegacyBIOS)


>
> 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.


So, we should choose the first way:
1. Integrate LegacyBIOS (or parts) into coreboot.



> 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.


here is my thought:
1. First we should take the codes from the elf of LegacyBIOS and copy
it to some memory like 0xf0000. Maybe we should analyze the elf format
of LegacyBIOS?
2. Then we should extend the post() method to init the memory and do
_not_ booting after post().
3. Call the modified post() method.
4. initialization of the controller and having the controller option rom
bios install a "handler" (int13).  This the job for SCSI booting.  And
then other tasks.

is it OK?


Zhang Rui