headers
Kevin O'Connor | 14 Dec 2009 00:34

Welcome to SeaBIOS

Welcome to the SeaBIOS mailing list.
Permalink | Reply | 0 comments |
headers
Kevin O'Connor | 15 Dec 2009 05:34

Proper support for PCI-based option rom loading (was Re: [Qemu-devel] Re: qdev property bug?)

On Mon, Dec 14, 2009 at 08:37:44PM -0600, Anthony Liguori wrote:
> Okay, I think I've figured out how this is supposed to work.  With these  
> two patches to SeaBIOS and the patch to qemu, I can run:

I'm not sure why "Do not guard qemu shadow ram work around in
CONFIG_OPTIONROMS_DEPLOYED" patch is needed.  The code today is:

        if (CONFIG_OPTIONROMS_DEPLOYED) {
            int reg = pci_config_readb(bdf, 0x5a + i);
            if ((reg & 0x11) != 0x11) {
                // Need to copy optionroms to work around qemu implementation
                void *mem = (void*)(BUILD_ROM_START + i * 32*1024);
                memcpy((void*)BUILD_BIOS_TMP_ADDR, mem, 32*1024);
                pci_config_writeb(bdf, 0x5a + i, 0x33);
                memcpy(mem, (void*)BUILD_BIOS_TMP_ADDR, 32*1024);
                clear = 1;
            } else {
                pci_config_writeb(bdf, 0x5a + i, 0x33);
            }
        } else {
            pci_config_writeb(bdf, 0x5a + i, 0x33);
        }

So, in the non CONFIG_OPTIONROMS_DEPLOYED case, SeaBIOS will just do
the write enable call (pci_config_writeb(bdf, 0x5a + i, 0x33)).  The
CONFIG_OPTIONROMS_DEPLOYED case should just be to copy the roms qemu
has deployed.  If SeaBIOS is filling in the 0xc0000-0xf0000 space, it
shouldn't matter if the contents of that space is lost during the
write enable.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Anthony Liguori | 15 Dec 2009 15:20

Proper support for PCI-based option rom loading (was Re: [Qemu-devel] Re: qdev property bug?)

Anthony Liguori wrote: 
>
> The bios gets mapped in 0xe0000 .. 0x100000 so if SeaBIOS fills the 
> 0xc0000-0xf0000 space it will write over half of the bios.

I'm a little confused by this.  SeaBIOS seems to assume that it only has 
to deal with the 0xf0000 .. 0x100000 space as the bios which is 
certainly true (i don't think there's anything special about the 0xe0000 
.. 0xf0000 region).

I'm not sure why we load the 128K worth of bios instead of just loading 64K.

Regards,

Anthony Liguori

> Regards,
>
> Anthony Liguori
Permalink | Reply | 0 comments |
headers
Anthony Liguori | 15 Dec 2009 14:15

Proper support for PCI-based option rom loading (was Re: [Qemu-devel] Re: qdev property bug?)

Kevin O'Connor wrote:
> On Mon, Dec 14, 2009 at 08:37:44PM -0600, Anthony Liguori wrote:
>   
>> Okay, I think I've figured out how this is supposed to work.  With these  
>> two patches to SeaBIOS and the patch to qemu, I can run:
>>     
>
> I'm not sure why "Do not guard qemu shadow ram work around in
> CONFIG_OPTIONROMS_DEPLOYED" patch is needed.  The code today is:
>
>         if (CONFIG_OPTIONROMS_DEPLOYED) {
>             int reg = pci_config_readb(bdf, 0x5a + i);
>             if ((reg & 0x11) != 0x11) {
>                 // Need to copy optionroms to work around qemu implementation
>                 void *mem = (void*)(BUILD_ROM_START + i * 32*1024);
>                 memcpy((void*)BUILD_BIOS_TMP_ADDR, mem, 32*1024);
>                 pci_config_writeb(bdf, 0x5a + i, 0x33);
>                 memcpy(mem, (void*)BUILD_BIOS_TMP_ADDR, 32*1024);
>                 clear = 1;
>             } else {
>                 pci_config_writeb(bdf, 0x5a + i, 0x33);
>             }
>         } else {
>             pci_config_writeb(bdf, 0x5a + i, 0x33);
>         }
>
> So, in the non CONFIG_OPTIONROMS_DEPLOYED case, SeaBIOS will just do
> the write enable call (pci_config_writeb(bdf, 0x5a + i, 0x33)).  The
> CONFIG_OPTIONROMS_DEPLOYED case should just be to copy the roms qemu
> has deployed.  If SeaBIOS is filling in the 0xc0000-0xf0000 space, it
(Continue reading)

Permalink | Reply | 0 comments |
headers
Avi Kivity | 15 Dec 2009 15:33
Picon
Favicon

Proper support for PCI-based option rom loading (was Re: [Qemu-devel] Re: qdev property bug?)

On 12/15/2009 04:20 PM, Anthony Liguori wrote:
> Anthony Liguori wrote:
>>
>> The bios gets mapped in 0xe0000 .. 0x100000 so if SeaBIOS fills the 
>> 0xc0000-0xf0000 space it will write over half of the bios.
>
> I'm a little confused by this.  SeaBIOS seems to assume that it only 
> has to deal with the 0xf0000 .. 0x100000 space as the bios which is 
> certainly true (i don't think there's anything special about the 
> 0xe0000 .. 0xf0000 region).
>
> I'm not sure why we load the 128K worth of bios instead of just 
> loading 64K.
>

bochs bios required all 128kB, so this is probably a leftover.

--

-- 
error compiling committee.c: too many arguments to function
Permalink | Reply | 0 comments |
headers
Anthony Liguori | 15 Dec 2009 18:35

Proper support for PCI-based option rom loading (was Re: [Qemu-devel] Re: qdev property bug?)

Avi Kivity wrote:
> On 12/15/2009 04:20 PM, Anthony Liguori wrote:
>> Anthony Liguori wrote:
>>>
>>> The bios gets mapped in 0xe0000 .. 0x100000 so if SeaBIOS fills the 
>>> 0xc0000-0xf0000 space it will write over half of the bios.
>>
>> I'm a little confused by this.  SeaBIOS seems to assume that it only 
>> has to deal with the 0xf0000 .. 0x100000 space as the bios which is 
>> certainly true (i don't think there's anything special about the 
>> 0xe0000 .. 0xf0000 region).
>>
>> I'm not sure why we load the 128K worth of bios instead of just 
>> loading 64K.
>>
>
> bochs bios required all 128kB, so this is probably a leftover.

This is apparently well defined in the PIIX spec.  There is a bit of a 
difference between the lower half and upper half of the BIOS region 
though and I expect this is part of what the problem is.  FYI, the 
following patch works.  Surprisingly, we only need to restore the 
0xe8000..0xe8fff region.  Still trying to understand what's happening.

diff --git a/src/shadow.c b/src/shadow.c
index f0f97c5..860f461 100644
--- a/src/shadow.c
+++ b/src/shadow.c
 <at>  <at>  -29,7 +29,8  <at>  <at>  __make_bios_writable(u16 bdf)
     int clear = 0;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Anthony Liguori | 15 Dec 2009 20:35

Proper support for PCI-based option rom loading (was Re: [Qemu-devel] Re: qdev property bug?)

Gerd Hoffmann wrote:
> -kernel didn't work on a quick test.

Thinking about how to fix this, we have two options.  The first would be 
to use the support in SeaBIOS for static roms but that would limit us to 
two user supplied option roms (including kernel/multiboot/extboot).  We 
could extend this to more than two roms but I think that's generally ugly.

Alternatively, we could introduce a special rom-only PCI device.  
Besides getting support for a much greater number of option roms, it 
also gives us a much nicer way to integrate multiboot/linux boot support 
via qdev (instead of the ugly machine hack we have now).

We could make them multifunction devices so that we don't unnecessarily 
burn PCI slots to support roms.

Regards,

Anthony Liguori
> cheers,
>   Gerd
Permalink | Reply | 0 comments |
headers
Anthony Liguori | 15 Dec 2009 22:41

Proper support for PCI-based option rom loading (was Re: [Qemu-devel] Re: qdev property bug?)

Michael S. Tsirkin wrote:
> On Tue, Dec 15, 2009 at 01:35:52PM -0600, Anthony Liguori wrote:
>   
>> Gerd Hoffmann wrote:
>>     
>>> -kernel didn't work on a quick test.
>>>       
>> Thinking about how to fix this, we have two options.
>>     
>
> Hmm, can you pls explain why it stops working?
>   

Sure.  SeaBIOS loads roms in a few ways.

If CONFIG_OPTIONROMS_DEPLOYED, then SeaBIOS scans the 0xc0000..0xf0000 
region for anything that looks like a rom.  This is how Bochs did it and 
is what qemu supports.  This is not how modern systems work though.

Modern systems (SeaBIOS with !CONFIG_OPTIONROMS_DEPLOYED), walk the PCI 
bus and look for any device with a PCI_ROM_ADDRESS that maps a valid 
option rom.  It will map the rom in PCI memory and run it's init 
function.  The rom can use PMM to allocate temporary memory to 
reorganize itself.  During this time, the rom area is writable.  The rom 
will create a stub that's usually pretty small that gets loaded by the 
BIOS after init into the 0xc0000..0xf0000 region.

So when !CONFIG_OPTIONROMS_DEPLOYED, SeaBIOS does look in this region 
for roms because it maps them all from the actual PCI devices.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael S. Tsirkin | 15 Dec 2009 22:17
Picon
Favicon

Proper support for PCI-based option rom loading (was Re: [Qemu-devel] Re: qdev property bug?)

On Tue, Dec 15, 2009 at 01:35:52PM -0600, Anthony Liguori wrote:
> Gerd Hoffmann wrote:
>> -kernel didn't work on a quick test.
>
> Thinking about how to fix this, we have two options.

Hmm, can you pls explain why it stops working?

> The first would be  
> to use the support in SeaBIOS for static roms but that would limit us to  
> two user supplied option roms (including kernel/multiboot/extboot).  We  
> could extend this to more than two roms but I think that's generally 
> ugly.
>
> Alternatively, we could introduce a special rom-only PCI device.   
> Besides getting support for a much greater number of option roms, it  
> also gives us a much nicer way to integrate multiboot/linux boot support  
> via qdev (instead of the ugly machine hack we have now).
>
> We could make them multifunction devices so that we don't unnecessarily  
> burn PCI slots to support roms.
>
> Regards,
>
> Anthony Liguori
>> cheers,
>>   Gerd

Will be a problem for non-PCI systems?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kevin OConnor | 16 Dec 2009 00:54

Proper support for PCI-based option rom loading (was Re: [Qemu-devel] Re: qdev property bug?)

On Tue, Dec 15, 2009 at 12:35 PM, Anthony Liguori <anthony at codemonkey.ws>wrote:

> Avi Kivity wrote:
>
>> bochs bios required all 128kB, so this is probably a leftover.
>>
>
> This is apparently well defined in the PIIX spec.  There is a bit of a
> difference between the lower half and upper half of the BIOS region though
> and I expect this is part of what the problem is.  FYI, the following patch
> works.  Surprisingly, we only need to restore the 0xe8000..0xe8fff region.
>  Still trying to understand what's happening.
>
>
SeaBIOS is currently using over 64K of space.  So, it is extending into the
e-segment
and thus needs to have the e-segment copied properly (I missed that in my
earlier email).

SeaBIOS is only extending a few K into the e-segment, so only that part
needs to
be saved and restored.

Should SeaBIOS options be trimmed so that it fit under 64K, then the build
would
create only a 64K rom.  However, since it is larger than 64K, it pads itself
to 128K.  As
mentioned before, SeaBIOS can still copy roms into the unused parts of the
e-segment,
as it knows which parts of the e-segment it is using.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane