On May 19, 2018, at 1:02 PM, Tarl Neustaedter tarl-b2@tarl.net wrote:
On 2018-May-19 11:53 , Jd Lyons wrote:
SLOF
assigned-addresses 82000830 00000000 83000000 00000000 00010000 82000810 00000000 81000000 00000000 01000000 c3000814 00002100 00000000 00000000 10000000 8200081c 00000000 82000000 00000000 01000000
That looks reasonable. It's somewhat unusual to have the ROMBAR be the first entry, but not prohibited. I'm a little startled by BAR 14; it's 64-bit memory space, starting at 2100.0000.0000 for length 10000000. Not out of question, but on SPARC I didn't see addresses assigned that high up (I recall we usually started at 2.0000.0000).
Thanks Tarl,
I think the reason SLOF has the ROM BAR as the first address is the way QEMU handles VGA ROM’s, you have to pass a rom you want to use from the Qemu command line when doing PCI Passthough of a VGA device, Qemu-x86 handles things a little better, however I still have trouble if I don’t pass Qemu a romfile if I reboot my Qemu-x86 system.
-device vfio-pci,host=24:00.0,multifunction=on,x-vga=on,romfile=./6600.rom \
I got the 6600 to display video using the pseries machine in qemu-system-ppc64 with the Power8 cpu and SLOF. The nouveau drivers complained that it couldn’t read the cards ROM until I passed the romfile= command argument.
However, any graphical display to the card resulted in display corruption. I had no trouble with the text display from the TTY in Fedora 27. I haven’t looked at the NVDA,BMP property to ensure that it is being calculated correctly, as this type of display corruption is normal for the wrong 32 bit words getting written to the graphics card registers.
I’m hoping I’m not running into guest to host endianness issues, but I don’t really think that I am.
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.
The ROMBAR absence might not be a problem - it has to be manually turned on (low order bit in the address, as I recall), so if you leave it turned off, you don't need to assign it an address. I'd generally have the framework assign it an address anyway, just so you didn't run into allocation problems at the time when you do need to turn it on.
I’ll see if I can get the ROM BAR to work first, as I have some idea how to hack that in, then I’ll see if I can address the “n” bit.
BAR 14 is listed as 64-bit memory, starting at 9000.0000 - way down in 32-bit address space. Some FCodes may get confused by that. It generally shouldn't be a problem, but it's something to worry about.
BAR 10 in the above is listed starting with 02 instead of 82... My recollection is that the "8" is the "n" (non-relocatable) bit in the descriptor... Ah, yes, seehttps://www.openfirmware.info/data/docs/bus.pci.pdf https://www.openfirmware.info/data/docs/bus.pci.pdf section 2.2.1.1 - I'd generally expect that to be set in the assigned-addresses specification (once the framework has assigned an address, the client isn't allowed to relocate it. The bit is more intended for a "reg" specification.)
So, Openbios is doing things a bit funky, but not entirely unreasonable. I"d keep in mind the potential confusion with 32/64 bit addressing in the FCode, but aside from that, the only thing I'd worry about is the missing "n" bit on BAR 10.