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

[Anthony Liguori <anthony@codemonkey.ws>]

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
> shouldn't matter if the contents of that space is lost during the
> write enable.
>   

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

Regards,

Anthony Liguori