[coreboot] GSoC project(SCSI boot)__status report
stepan at coresystems.de
Wed Jun 18 01:04:49 CEST 2008
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:
> 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
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
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:
> 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.
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the coreboot