On 2018-May-19 11:53 , Jd Lyons wrote:
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).
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.
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, see
- 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
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.