[OpenBIOS] Back at it again( PCI Passthrough )

Jd Lyons lyons_dj at yahoo.com
Sat May 19 17:53:57 CEST 2018



> On May 19, 2018, at 11:26 AM, Jd Lyons via OpenBIOS <openbios at openbios.org> wrote:
> 
> 
> 
>> On May 19, 2018, at 5:16 AM, Tarl Neustaedter <tarl-b2 at tarl.net> wrote:
>> 
>> On 2018-May-19 04:25 , Mark Cave-Ayland wrote:
>>> 
>>> From what I can see in the provided output it is just the config-*@, config-*! and map-out words missing from OpenBIOS which shouldn't be too difficult to fix. There also seems to be an assumption that the "assigned-addresses" property is present, or at least I can see FCode that tries to read it but nothing to write it?
>> 
>> That's a reasonable/required assumption. "assigned-addresses" should be produced by the framework during the probe before the FCode runs. In a PCI device, it should have an "assigned-addresses" entry for each BAR. Something like:
>> 
>> assigned-addresses       81090110 00000000 00002100 00000000 00000100 
>>                         82090114 00000000 00604000 00000000 00004000 
>>                         82090130 00000000 00680000 00000000 00040000 
>> 
>> In the above, the first cell of each entry describes the space for each BAR. The first set is IO space for BAR 10, at location 2100 size 100 bytes. The second is memory space for BAR 14 at 604000 (in PCI space), size 4000 bytes. The third entry is for the ROMBAR, BAR 30, assigned to 680000 size 40000.
>> 
>> -- 
>> OpenBIOS                 http://openbios.org/
>> Mailinglist:  http://lists.openbios.org/mailman/listinfo
>> Free your System - May the Forth be with you
> 
> 
> Hmmm…..
> 
> Here are the assigned-addresses for both SLOF and Openbios before the Fcode is run:
> 
> 
> SLOF
> 
> assigned-addresses               82000830  00000000  83000000  00000000
>                                 00010000  82000810  00000000  81000000
>                                 00000000  01000000  c3000814  00002100
>                                 00000000  00000000  10000000  8200081c
>                                 00000000  82000000  00000000  01000000
> 
> Openbios:
> 
> 
> assigned-addresses        -- 3c : 02 00 78 10 00 00 00 00 81 00 00 00 00 00 00 00 01 00 00 00 c3 00 78 14 00 00 00 00 90 00 00 00 00 00 00 00 10 00 00 00 83 00 78 1c 00 00 00 00 a0 00 00 00 00 00 00 00 01 00 00 00 
> 
> Not real sure what to make of them, Tarl?
> -- 
> OpenBIOS                 http://openbios.org/
> Mailinglist:  http://lists.openbios.org/mailman/listinfo
> Free your System - May the Forth be with you


Here it is again in a format that makes it a little easier to read:

SLOF

assigned-addresses 82000830 00000000 83000000 00000000 00010000  
                                 82000810 00000000 81000000 00000000 01000000  
                                 c3000814 00002100 00000000 00000000 10000000  
                                 8200081c 00000000 82000000 00000000 01000000

Openbios:

assigned-addresses-- 3c : 02007810 00000000 81000000 00000000 01000000 
                                          c3007814 00000000 90000000 00000000 10000000 
                                          8300781c 00000000 a0000000 00000000 01000000 

Obviously Openbios isn’t getting the ROM bar 0x30.

I did some hacking a few years back to work on 3dfx Voodoo emulation, I hacked together some code using Qemu’s secondary-vga device as a Voodoo2 and Qemu’s VGA device as a Voodoo5. One thing I noted was that I could only read the ROM offset 0x30 in PCI Peak under OS 9 if I enabled the secondary-vga device. So a little hacking will likely be necessary to get Qeum/Openbios to property assign the ROM BAR.




More information about the OpenBIOS mailing list