| Summary: | Nouveau driver cannot extract FCODE ROM / DCB Block from OpenFirmware Device tree | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Peter Saisanas <psaisanas> |
| Component: | Driver/nouveau | Assignee: | Nouveau Project <nouveau> |
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | normal | ||
| Priority: | medium | CC: | psaisanas, reeskm |
| Version: | unspecified | ||
| Hardware: | PowerPC | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | |||
Created attachment 117085 [details]
dmesg log with "nouveau.debug=debug,VBIOS=trace"
booting kernel 4.1.2 with "nouveau.debug=debug,VBIOS=trace" appended on kernel command line.
Aha, looks like the issue is that your VBIOS in OF does not have a PCIR section, and the nouveau VBIOS parser has come to expect that. Going to have to read more code to work out a proper solution to that. Hi, I have managed to extract the actual Open Firmware nVidia Quadro FX4500 PCI expansion ROM which i have attached. The actual ROM itself seems to have a PCIR header located @ offset 0x20. Could it be that nouveau is actually trying to read the PCIR header directly off the XROM (which is how i assume it would be done in x86) and not via the OF device tree for ppc arch in the newer versions of nouveau by any chance? Regards, Peter Created attachment 117271 [details]
OF Powermac Quadro FX4500 ROM
Actually that's not from OF, it's from the PROM. And while it has a PCIR header, it doesn't contain the various other tables we expect. However the one in OF (i.e. the NVDA,BMP thing) does. But it's missing the PCIR header so the nouveau vbios reader logic throws it out, and falls back on the PROM one, which, in turn, fails. You can try this patch, in Ben's tree which is ~4.3-rcN : http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=5b5cc342d3154120f9bb5ca7839ab556e728c786 This worked for me, but could use more testing. Created attachment 118662 [details]
4.3-rc4 dmesg with "nouveau.debug=debug,VBIOS=trace"
Hi, I assume the patch is within 4.3-rc4? If so, it still doesn't seem to extract the VBIOS via the OpenFirmware. I have compiled and booted the 4.3-rc4 kernel and booted with "nouveau.debug=debug,VBIOS=trace" which is attached. (In reply to Peter Saisanas from comment #8) > Hi, > I assume the patch is within 4.3-rc4? > > If so, it still doesn't seem to extract the VBIOS via the OpenFirmware. > > I have compiled and booted the 4.3-rc4 kernel and booted with > "nouveau.debug=debug,VBIOS=trace" which is attached. Odd. [ 10.214404] nouveau 0000:0a:00.0: bios: trying OpenFirmware... [ 10.214499] nouveau 0000:0a:00.0: bios: image 0 invalid With my patch it's pretty much rigged to always accept the OF vbios. Are you sure you were able to apply it properly? (In reply to Ilia Mirkin from comment #9) > (In reply to Peter Saisanas from comment #8) > > Hi, > > I assume the patch is within 4.3-rc4? > > > > If so, it still doesn't seem to extract the VBIOS via the OpenFirmware. > > > > I have compiled and booted the 4.3-rc4 kernel and booted with > > "nouveau.debug=debug,VBIOS=trace" which is attached. > > Odd. > > [ 10.214404] nouveau 0000:0a:00.0: bios: trying OpenFirmware... > [ 10.214499] nouveau 0000:0a:00.0: bios: image 0 invalid > > With my patch it's pretty much rigged to always accept the OF vbios. Are you > sure you were able to apply it properly? In fact, after my patch, nvkm_debug(subdev, "image %d invalid\n", idx); is in a section that should never get hit by the OF logic (since it will specify no_pcir=true, which in turn skips the whole image validation thing). No i didn't apply the patch, i assumed that it was already in vanilla 4.3-rc4. Sorry, my misunderstanding. I have tried to patch vanilla 4.3-rc4 but the patch will not apply cleanly. Ill try to patch it manually when i get a chance. (In reply to Peter Saisanas from comment #11) > No i didn't apply the patch, i assumed that it was already in vanilla > 4.3-rc4. > > Sorry, my misunderstanding. > > I have tried to patch vanilla 4.3-rc4 but the patch will not apply cleanly. > > Ill try to patch it manually when i get a chance. Try it from the drivers/gpu directory. I can confirm that the patch works with my config which is great news. However, the patch does not apply cleanly to vanilla 4.3-rc4, it seems to reject parts of the patch to shadowof.c. After manually changing shadowof.c, i.e. the parts of the patch that was rejected, compiled and hooray, it works! Awesome, thanks imirkin! Do you require any more info? (In reply to Peter Saisanas from comment #13) > Do you require any more info? Nope. Will leave this open until the fix hits mainline. This patch is in 4.3-rc6. I'm having this exact same problem on kernel 4.9.49 on ppc 32-bit. I see that this was previously fixed. Should this be re-opened or should I file a new bug report? (In reply to reeskm from comment #16) > I'm having this exact same problem on kernel 4.9.49 on ppc 32-bit. > I see that this was previously fixed. Should this be re-opened or should I > file a new bug report? When in doubt, file a new bug report. When not in doubt, file a new bug report. Reports are trivial to merge but impossible to tease apart. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 117079 [details] kernel dmesg log & NVDA,BMP FCODE ROM Hi, When running a Powermac 11.2, (G5 Quad - powerpc64) with a Quadro FX4500 (NV47), previous kernels had no issue extracting the FCODE ROM / DCB block via the OpenFirmware device tree. Last vanilla kernel that i have compiled that seemed to work fine was kernel 3.18.16. Normally, it will find the "BIT SIGNATURE" via OpenFirmware method. However, when compiling a newer vanilla kernel 4.1.2, nouveau seems to have an issue reading the FCODE ROM / DCB block / from the OpenFirmware device tree. Also, interestingly, this time around it attempts to use the PROM method and attempts to find the "BIT SIGNATURE" via this method. Apparently it found a signature, but looks like garbage and seems like it cant extract the DCB BLOCK. As instructed, i have attached a dmesg.log along with a dump of the NVDA,BMP image out of the following folder: /sys/firmware/devicetree/base/pci@0,f0000000/NVDA,Parent@0/. Not sure if this is correct, but i have passed the following nouveau module options as i understood: options nouveau config="NvMSI=0,debug=debug,VBIOS=trace" I have placed the kernel dmesg log along with the NVDA,BMP dump in the attached nouveau_powerpc64_pmac11.2.tar.xz archive. Please let me know if there is any more info required. Thanks for your help! Best Regards, Peter