[coreboot] GSoC project(SCSI boot)__status report

Zhang Rui zrfail at gmail.com
Thu Jun 19 10:24:10 CEST 2008


2008/6/19 Joseph Smith <joe at settoplinux.org>:
>
>[...]
>
> Well,
> Sorry to say, to me that does not make very much sense.
> First of all, at the point where you "1. copy LegacyBIOS codes to 0xf0000"
> the memory should already be initialized by coreboot correct?? This is one
> of the first things coreboot does is initialize the memory. So, the second
> part of number 2. ("initialize the memory") may not be necessary if the
> memory is already initialized by coreboot.

Sorry for being unclear. According to Kevin, some LegacyBIOS interrupt
handlers need the Bios Data Area (BDA) and Extended Bios Data Area
(EBDA) setted by the post() function in LegacyBIOS.  So my meaning of
2. ("initialize the memory") is use modified post() to set up these
areas.
Here is some piece of Kevin's email, and I forword the full text at
the end of this email.
>> >> 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 an
>> >> AMI/Phoenix/Award 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 what I would suggest, I don't know if it is the right direction, but
> I think it logically makes sense:
>
> 1. Start the coreboot initialization process as normal
> 2. When coreboot gets to the memory allocation part; have it reserve a
> certain amount(Size of LegacyBIOS??) at 0xf0000 (if option LegacyBIOS is
> selected).
this should be taken to consideration.

> 3. (if option LegacyBIOS is selected) copy LegacyBIOS codes to 0xf0000.
> 4. (if option LegacyBIOS is selected) Jump to LegacyBIOS and setup any
> tables, INT's, etc.
According to Kevin's email, this will be done by calling post() in
LegacyBIOS. But post() will do the booting at the end, so we should
modify it to return to coreboot.

> 5. Return to coreboot and continue as normal.
> 6. in the payload part initialize the SCSI controller and install a handler
> and call LegacyBIOS INT19.
>
> Does this make any sense, or am I way off course???

Thanks to Joseph. You give a more detailed roadmap and I will try to
go on this direction.

And any questions?

Zhang Rui







Here is Kevin's email.

2008/6/17 Kevin O'Connor <kevin at koconnor.net>:
> On Mon, Jun 16, 2008 at 04:44:27PM +0200, Stefan Reinauer wrote:
>> Kevin: 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.
>
>> >> 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:
>
> http://git.linuxtogo.org/?p=kevin/legacybios.git;a=blob;f=src/romlayout.S;h=c8522612ab996533e6480dfe8ccc73e6af0f7c0d;hb=f54c150090ff38a73ef64a5d20fdfa0d9c403972#l363
>
> 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.
>
>> 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".
> 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.
>
> In the general case, to use the 16bit handlers you need to run the
> code contained in the "post" section.  See:
>
> http://git.linuxtogo.org/?p=kevin/legacybios.git;a=blob;f=src/post.c;h=766e8984e765634a99989fbbd5cec74c914586a2;hb=f54c150090ff38a73ef64a5d20fdfa0d9c403972#l207
>
> 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.
>
> Is there a particular reason you'd want to return to coreboot?
>
>>Is there some entry point in LegacyBIOS for doing this?
>
> To run "post" in LegacyBIOS, you should jump to the 32bit elf entry
> point.  See:
>
> http://git.linuxtogo.org/?p=kevin/legacybios.git;a=blob;f=src/post.c;h=766e8984e765634a99989fbbd5cec74c914586a2;hb=f54c150090ff38a73ef64a5d20fdfa0d9c403972#l324
>
> If you really wanted to, you could jump to f000:fff0 in 16bit mode,
> but all that will do with LegacyBIOS is cause it to jump back to 32bit
> mode and then call the same code as above.
>
>>Or should we use the hard coded addresses of the handlers? Is
>> there a hard coded address for every int handler? Or is there a better
>> way for doing this?
>
> No, no, and yes.  You really don't want to use the fixed addresses.
> You really want to rely on LegacyBIOS (or bochs bios) to do its job.
>
> [...]
>> >> 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 an
>> >> AMI/Phoenix/Award 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.
>
> [...]
>> > 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.
>
> Regards,
> -Kevin
>




More information about the coreboot mailing list