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:
http://git.linuxtogo.org/?p=kevin/legacybios.git;a=blob;f=src/romlayout.S;h=...
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.
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 coreboot.
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:
http://git.linuxtogo.org/?p=kevin/legacybios.git;a=blob;f=src/post.c;h=766e8...
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.
Stefan
On Wed, 18 Jun 2008 01:04:49 +0200, Stefan Reinauer stepan@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?
On Tue, 17 Jun 2008 21:25:59 -0400, Joseph Smith joe@settoplinux.org wrote:
On Wed, 18 Jun 2008 01:04:49 +0200, Stefan Reinauer stepan@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
On Tue, Jun 17, 2008 at 09:25:59PM -0400, Joseph Smith wrote:
On Wed, 18 Jun 2008 01:04:49 +0200, Stefan Reinauer stepan@coresystems.de wrote:
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).
I recommend caution here.
I think it is important that LegacyBIOS support kvm, qemu, and bochs. Having the code support those environments will help increase the overall user base, which will help ensure the core code supports many different OSes and is thoroughly tested. So, I don't think we want to make LegacyBIOS coreboot specific.
I also don't think it would be a good idea to fork the code or copy large parts of it into multiple repositories.
So, I'm all for aligning coreboot and LegacyBIOS - it is after all the reason I started LegacyBIOS - but I think we need to come up with a boundary between the two. In my opinion, coreboot should (optionally) call out to LegacyBIOS and the two should work towards the same goal. But I don't think they should be tightly integrated at the source code level.
-Kevin
On Tue, 17 Jun 2008 22:58:00 -0400, Kevin O'Connor kevin@koconnor.net wrote:
On Tue, Jun 17, 2008 at 09:25:59PM -0400, Joseph Smith wrote:
On Wed, 18 Jun 2008 01:04:49 +0200, Stefan Reinauer
wrote:
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).
I recommend caution here.
I think it is important that LegacyBIOS support kvm, qemu, and bochs. Having the code support those environments will help increase the overall user base, which will help ensure the core code supports many different OSes and is thoroughly tested. So, I don't think we want to make LegacyBIOS coreboot specific.
I also don't think it would be a good idea to fork the code or copy large parts of it into multiple repositories.
So, I'm all for aligning coreboot and LegacyBIOS - it is after all the reason I started LegacyBIOS - but I think we need to come up with a boundary between the two. In my opinion, coreboot should (optionally) call out to LegacyBIOS and the two should work towards the same goal. But I don't think they should be tightly integrated at the source code level.
Hmm. Then how are we going to go about this? What do you suggest Kevin? Could we set up coreboot to call LegacyBIOS at a certain point, execute it, and then jump back to coreboot? Kind of like vm86/x86emu does for VGA? If so at what point in the coreboot process do we want this to happen?
Joseph Smith wrote:
Hmm. Then how are we going to go about this? What do you suggest Kevin? Could we set up coreboot to call LegacyBIOS at a certain point, execute it, and then jump back to coreboot? Kind of like vm86/x86emu does for VGA? If so at what point in the coreboot process do we want this to happen?
I think that it will have to do that if you want to run the VGA ROM (and other ROMs) as part of the normal PCI initialization. The interrupt code will need to be in place at that time.
Marc
What I am going to do is: 1. copy LegacyBIOS codes to 0xf0000, 2. call a modifid post() in LegacyBIOS to initialize the memory and return to coreboot. 3. initialize the SCSI controller and install a handler.
Is that OK?
2008/6/18 Marc Jones Marc.Jones@amd.com:
Joseph Smith wrote:
Hmm. Then how are we going to go about this? What do you suggest Kevin? Could we set up coreboot to call LegacyBIOS at a certain point, execute it, and then jump back to coreboot? Kind of like vm86/x86emu does for VGA? If so at what point in the coreboot process do we want this to happen?
I think that it will have to do that if you want to run the VGA ROM (and other ROMs) as part of the normal PCI initialization. The interrupt code will need to be in place at that time.
Marc
-- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones@amd.com http://www.amd.com/embeddedprocessors
-- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
-----Original Message----- From: Zhang Rui [mailto:zrfail@gmail.com] Sent: Wednesday, June 18, 2008 9:38 PM To: Marc Jones Cc: Joseph Smith; Stefan Reinauer; Kevin O'Connor; Coreboot Subject: Re: [coreboot] GSoC project(SCSI boot)__status report
What I am going to do is:
- copy LegacyBIOS codes to 0xf0000,
- call a modifid post() in LegacyBIOS to initialize the memory and
return to coreboot. 3. initialize the SCSI controller and install a handler.
Is that OK?
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.
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). 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. 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, Joseph Smith Set-Top-Linux www.settoplinux.org
2008/6/19 Joseph Smith joe@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:
- Start the coreboot initialization process as normal
- 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.
- (if option LegacyBIOS is selected) copy LegacyBIOS codes to 0xf0000.
- (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.
- Return to coreboot and continue as normal.
- 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@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=...
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=766e8...
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=766e8...
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
On Thu, 19 Jun 2008 16:24:10 +0800, "Zhang Rui" zrfail@gmail.com wrote:
2008/6/19 Joseph Smith joe@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:
- Start the coreboot initialization process as normal
- 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.
- (if option LegacyBIOS is selected) copy LegacyBIOS codes to 0xf0000.
- (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.
- Return to coreboot and continue as normal.
- 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?
I don't think so, I am excited to try it out once you are finished. Although I am using IDE instead of SCSI. Sorry if I sound like a broken record, the main thing to remember is we need to make all the LegacyBIOS code that is getting injected into the coreboot base code optional, hence the "if option LegacyBIOS is selected". There are alot of people sensative about this, and we need to keep coreboot flexible and make everyone happy, right?
2008/6/20 Joseph Smith joe@settoplinux.org:
I don't think so, I am excited to try it out once you are finished. Although I am using IDE instead of SCSI. Sorry if I sound like a broken record, the main thing to remember is we need to make all the LegacyBIOS code that is getting injected into the coreboot base code optional, hence the "if option LegacyBIOS is selected". There are alot of people sensative about this, and we need to keep coreboot flexible and make everyone happy, right?
OK, I will keep "making LegacyBIOS code optional" in my mind. May be a choice in the menuconfig is suitable? I will implement this option after I finished the SCSI booting functionality. Is this OK?
And another question, LegacyBIOS is not in the coreboot base code now and where should we put it? Maybe in the util/LegacyBIOS?
-----Original Message----- From: coreboot-bounces+joe=settoplinux.org@coreboot.org [mailto:coreboot- bounces+joe=settoplinux.org@coreboot.org] On Behalf Of Zhang Rui Sent: Thursday, June 19, 2008 11:22 PM To: Joseph Smith Cc: Stefan Reinauer; Kevin O'Connor; Marc Jones; Coreboot Subject: Re: [coreboot] GSoC project(SCSI boot)__status report
2008/6/20 Joseph Smith joe@settoplinux.org:
I don't think so, I am excited to try it out once you are finished. Although I am using IDE instead of SCSI. Sorry if I sound like a broken record, the main thing to remember is we need to make all the LegacyBIOS code that is getting injected into the coreboot base code optional, hence the "if option LegacyBIOS is
selected".
There are alot of people sensative about this, and we need to keep
coreboot
flexible and make everyone happy, right?
OK, I will keep "making LegacyBIOS code optional" in my mind. May be a choice in the menuconfig is suitable? I will implement this option after I finished the SCSI booting functionality. Is this OK?
And another question, LegacyBIOS is not in the coreboot base code now and where should we put it? Maybe in the util/LegacyBIOS?
For v3 you could probably just use the menuconfig. I haven't played around with v3 yet, so someone else would probably be better to answer that.
For v2 use a global option in Option.lb, something like:
uses USE_LEGACYBIOS ## ## Build code for LegacyBIOS support ## 0 = disabled, 1 = enabled ## default USE_LEGACYBIOS = 1
and then before and after your code use a preprocessing directive:
#if USE_LEGACYBIOS
Insert LegacyBIOS code here
#endif
Hope that helps:-)
Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
On Fri, 20 Jun 2008 11:21:50 +0800, "Zhang Rui" zrfail@gmail.com wrote:
2008/6/20 Joseph Smith joe@settoplinux.org:
I don't think so, I am excited to try it out once you are finished. Although I am using IDE instead of SCSI. Sorry if I sound like a broken record, the main thing to remember is we need to make all the LegacyBIOS code that is getting injected into the coreboot base code optional, hence the "if option LegacyBIOS is
selected".
There are alot of people sensative about this, and we need to keep
coreboot
flexible and make everyone happy, right?
OK, I will keep "making LegacyBIOS code optional" in my mind. May be a choice in the menuconfig is suitable? I will implement this option after I finished the SCSI booting functionality. Is this OK?
Sure
For v3 you could probably just use the menuconfig. I haven't played around with v3 yet, so someone else would probably be better to answer that.
For v2 use a global option in Option.lb, something like:
uses USE_LEGACYBIOS ## ## Build code for LegacyBIOS support ## 0 = disabled, 1 = enabled ## default USE_LEGACYBIOS = 1
and then before and after your code use a preprocessing directive:
#if USE_LEGACYBIOS
Insert LegacyBIOS code here
#endif
And another question, LegacyBIOS is not in the coreboot base code now and where should we put it? Maybe in the util/LegacyBIOS?
This would be a good question for Kevin
Hope that helps:-)
On Wed, Jun 18, 2008 at 01:04:49AM +0200, Stefan Reinauer wrote:
Kevin O'Connor wrote:
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.
How will this work? Is there a piece of 32bit code that will copy the rest of LegacyBIOS to 0xf0000?
The LegacyBIOS elf file expects to be loaded into the 0xf0000 area:
$ objdump -x out/bios.bin.elf [...] start address 0x000f66a0
Program Header: LOAD off 0x00001000 vaddr 0x000f0000 paddr 0x000f0000 align 2**12 filesz 0x00010000 memsz 0x00010000 flags rw-
Currently all of the 16bit and 32bit code fits in the 64K segment at 0xf0000. Just load the elf into that area and jump to it.
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?
The elf file (bios.bin.elf) is just a wrapper around a 64K blob (bios.bin) with a specified entry point. So, if one wants the blob and not the elf then the file bios.bin can be used.
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?
I wouldn't want to hardcode an address, but we can certainly create a returnable coreboot entry point and have the build process export the address somehow. Effectively, the build process today is exporting the current 32bit entry point by building an elf around bios.bin and setting the elf "start address".
To return to coreboot, however, one also needs to restore the stack, idt, and gdt..
Is there a particular reason you'd want to return to coreboot?
[...]
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.
So, why not have coreboot load all the option roms from the lar into ram and then launch LegacyBIOS?
But when jumping into LegacyBIOS, not all option roms may be visible in the address space at the same time.
This is surprising. If all the option roms don't fit, how would a normal BIOS boot the system? If one were to swap out an option rom, how could one be sure the option rom didn't "hook" a 16bit int handler?
I guess what I am suggesting is to split the bootmenu + OS loader (int19) part from the init part.
I have no issue with doing this - it's trivial to implement multiple entry points. One need only implement a "__start2" type function that called a subset of the init code.
I do think it is conceptually simpler if coreboot did its thing and then launched LegacyBIOS as a payload. Then LegacyBIOS could do its thing and then launch the OS.
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.
I think it would be cool to teach LegacyBIOS how to read the lar. That way one could boot floppy, cdrom, hard drive, or lar payload. Something like LegacyBIOS+Bayou.
I'm not tied to anything though - whatever works.
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.
I know of only PIR (generally 32-160 bytes), ACPI RSDP (20-36 bytes), SMBIOS Structure Table Entry Point (31 bytes), and mptable Floating Pointer Structure (16 bytes). (Note that SMBIOS is just a newer definition of DMI - DMI's equivalent entry point is 15 bytes.)
It's straight forward to relocate these tables. I changed coreboot-v2 code in write_tables() (arch/i386/boot/tables.c) to use a high memory location instead of 0xf0000. Coreboot-v2 automatically exported the new location in the coreboot table. I then had LegacyBIOS scan those memory areas marked as CB_MEM_TABLE for the standard bios table signatures. See:
http://git.linuxtogo.org/?p=kevin/legacybios.git;a=blob;f=src/coreboot.c;h=6...
-Kevin
2008/6/18 Kevin O'Connor kevin@koconnor.net:
Currently all of the 16bit and 32bit code fits in the 64K segment at 0xf0000. Just load the elf into that area and jump to it.
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?
The elf file (bios.bin.elf) is just a wrapper around a 64K blob (bios.bin) with a specified entry point. So, if one wants the blob and not the elf then the file bios.bin can be used.
"bios.bin" is also produced after building of LegacyBIOS? So we can just copy the "bios.bin" to 0xf0000? and then how can we call the post() function?
Is there a particular reason you'd want to return to coreboot?
[...]
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.
So, why not have coreboot load all the option roms from the lar into ram and then launch LegacyBIOS?
This is another choise?
But when jumping into LegacyBIOS, not all option roms may be visible in the address space at the same time.
This is surprising. If all the option roms don't fit, how would a normal BIOS boot the system? If one were to swap out an option rom, how could one be sure the option rom didn't "hook" a 16bit int handler?
I guess what I am suggesting is to split the bootmenu + OS loader (int19) part from the init part.
I have no issue with doing this - it's trivial to implement multiple entry points. One need only implement a "__start2" type function that called a subset of the init code.
I do think it is conceptually simpler if coreboot did its thing and then launched LegacyBIOS as a payload. Then LegacyBIOS could do its thing and then launch the OS.
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.
I think it would be cool to teach LegacyBIOS how to read the lar. That way one could boot floppy, cdrom, hard drive, or lar payload. Something like LegacyBIOS+Bayou.
I'm not tied to anything though - whatever works.
There is two method: 1. use LegacyBIOS code in coreboot. 2. coreboot --> LegacyBIOS --> other payload(OS or "bootloader")
Which one to choose? question: 1. use LegacyBIOS code in coreboot. we should figure out how to use LegacyBIOS code within coreboot.
2. coreboot --> LegacyBIOS --> other payload(OS or "bootloader") we should find a way to pass more information from coreboot to LegacyBIOS, such as the option rom in lar. Will the adding one more layer between coreboot and other payload cost more time in the booting process? Or maybe the it cost almost equally that one more layer and the copying of code in LegacyBIOS to 0xf0000?
I think both way will work in the end and both need time to solve some problem. So we should have a decision as early as possible and give more time to the thinking of how to solve the problem of the decision.
Any more suggestions?
Zhang Rui
Hi Zhang,
I don't think your mails are making it to the coreboot list.
On Wed, Jun 18, 2008 at 10:53:39AM +0800, 独败 wrote:
2008/6/18 Kevin O'Connor kevin@koconnor.net:
The elf file (bios.bin.elf) is just a wrapper around a 64K blob (bios.bin) with a specified entry point. So, if one wants the blob and not the elf then the file bios.bin can be used.
"bios.bin" is also produced after building of LegacyBIOS?
Yes.
So we can just copy the "bios.bin" to 0xf0000?
Yes.
and then how can we call the post() function?
Well, that will require some work. :-) Take a look at how the build exports the assembler stub "post32" (in post.c) - which calls _start() (also in post.c).
-Kevin
2008/6/18 Stefan Reinauer stepan@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
-
Joseph Smith -
Kevin O'Connor -
Marc Jones -
Stefan Reinauer -
Zhang Rui -
独败