<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Kevin O'Connor wrote:
<blockquote cite="mid:20080616223806.GA5103@morn.localdomain"
type="cite">
<pre wrap="">On Mon, Jun 16, 2008 Stefan Reinauer wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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!
</pre>
</blockquote>
<pre wrap=""><!---->
Sure. I'd prefer to cc a mailing list though - it increases overall
awareness. Either coreboot or bochs lists would be fine.
</pre>
</blockquote>
Ok, let's CC coreboot.org on this one.<br>
<br>
<blockquote cite="mid:20080616223806.GA5103@morn.localdomain"
type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">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?
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
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:
<a class="moz-txt-link-freetext" href="http://git.linuxtogo.org/?p=kevin/legacybios.git;a=blob;f=src/romlayout.S;h=c8522612ab996533e6480dfe8ccc73e6af0f7c0d;hb=f54c150090ff38a73ef64a5d20fdfa0d9c403972#l363">http://git.linuxtogo.org/?p=kevin/legacybios.git;a=blob;f=src/romlayout.S;h=c8522612ab996533e6480dfe8ccc73e6af0f7c0d;hb=f54c150090ff38a73ef64a5d20fdfa0d9c403972#l363</a>
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
bios.
</pre>
</blockquote>
Ok, this is good.<br>
<br>
<blockquote cite="mid:20080616223806.GA5103@morn.localdomain"
type="cite">
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap=""><!---->
I'm slightly confused by your use of "legacy bios" and "LegacyBIOS".
</pre>
</blockquote>
:-) sorry, i will try to be more clear ..<br>
<br>
<blockquote cite="mid:20080616223806.GA5103@morn.localdomain"
type="cite">
<pre wrap="">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.
</pre>
</blockquote>
How will this work? Is there a piece of 32bit code that will copy the
rest of LegacyBIOS to 0xf0000?<br>
<br>
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?<br>
<br>
<blockquote cite="mid:20080616223806.GA5103@morn.localdomain"
type="cite">
<pre wrap="">In the general case, to use the 16bit handlers you need to run the
code contained in the "post" section. See:
<a class="moz-txt-link-freetext" href="http://git.linuxtogo.org/?p=kevin/legacybios.git;a=blob;f=src/post.c;h=766e8984e765634a99989fbbd5cec74c914586a2;hb=f54c150090ff38a73ef64a5d20fdfa0d9c403972#l207">http://git.linuxtogo.org/?p=kevin/legacybios.git;a=blob;f=src/post.c;h=766e8984e765634a99989fbbd5cec74c914586a2;hb=f54c150090ff38a73ef64a5d20fdfa0d9c403972#l207</a>
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.
</pre>
</blockquote>
Ok. what would be the best way to do this? create a well known entry
point, similar to the reset vector?<br>
<br>
<blockquote cite="mid:20080616223806.GA5103@morn.localdomain"
type="cite">
<pre wrap="">Is there a particular reason you'd want to return to coreboot?
</pre>
</blockquote>
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.<br>
<br>
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.<br>
<br>
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().<br>
<br>
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.<br>
<br>
I guess what I am suggesting is to split the bootmenu + OS loader
(int19) part from the init part. <br>
<br>
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.<br>
<br>
<blockquote cite="mid:20080616223806.GA5103@morn.localdomain"
type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><!---->
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.
[...]
</pre>
</blockquote>
Ok, I think this is much clearer now. <br>
<blockquote cite="mid:20080616223806.GA5103@morn.localdomain"
type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
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.<br>
coreboot table currently resides at 0x530 or 0x500 but it is not very
well placed there.<br>
<br>
Stefan<br>
<br>
<br>
<pre class="moz-signature" cols="72">--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: <a class="moz-txt-link-abbreviated" href="mailto:info@coresystems.de">info@coresystems.de</a> • <a class="moz-txt-link-freetext" href="http://www.coresystems.de/">http://www.coresystems.de/</a>
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
</pre>
</body>
</html>