On Sun, Dec 17, 2017 at 11:59:04AM -0500, Tarl Neustaedter wrote:
On 2017-Dec-17 11:47 , Jd Lyons wrote:
Yes, trying to get PCI Passthough working for an Apple OEM nVidia 6600 PCI-E card, on a x86 host in Qemu-PPC.
Oh, crud. It's likely you're tripping over some code created specifically for the Apple due to Apple's implementation being defective. I remember this caused many pci card vendors to create vendor-specific FCodes for their cards, when Apple decided to not fix the bug in their FCode interpretation. That made it incompatible with other vendors. I don't remember what the bug was, I retired a couple of years ago, but we'd periodically run into someone with a PCI card that didn't work, find out it was supposed to be for an Apple, and they'd have to get new FCode for their card.
Nvidia considered their FCode highly proprietary, so you won't be able to get ahold of the source for it. At Sun/Oracle, we had a copy of their source under a protected tree, which was only available to a limited number of engineers who had signed non-disclosure agreements with them. So unfortunately, you aren't likely to be able to get a copy of their source to debug this.
It looks like it got far enough to create the basic properties in the tree where it's going to start mapping the card into your virtual address space (that's what usually follows creating the reg and address-cells properties). It's worth dumping out the device tree to see what got created - I see multiple creations of the "#address-cells" property, which suggests it might have created multiple nodes (you generally don't want to create the same property twice).
Apple has a bunch of extra FCodes for local variables, etc. The really big thing though is that quite a lot of FCode drivers were only tested on one implementation, and depends on peculiarities of that implementation.
But, in this case it looks like the loader code itself is crashing, so there is hope left.
Segher