Created attachment 112941 [details] kernel_log for GT610 with debug info Hi, We use devices on the base of PowerPC series e5500 and try to use the driver nouveau. But by starting of nouveau driver we get kernel crash. We used several kernels ver. 3.x but on all kernels we have same error. And try to test several nvidia card GT520, GT610 and other. I tryed to solve the problem by myself and added some debug codes: 1. I added the following debug codes into the file base.c /* read boot0 and strapping information */ boot0 = ioread32_native(map + 0x000000); strap = ioread32_native(map + 0x101000); iounmap(map); printk ("##boot0=%x\n",boot0); printk ("##strap=%x\n",strap); The result you can see in the log_gt610 attachment file. The value of the variable "boot0" for this video card is to be of the value 0x0d90a0a1, in the log it is value in the reverse order. The value of the variable "strap" is to be of the value 0x80406892, in the log it isn't reversed but there is no msd. What does the fact depend on that 2 registers are readed and one of them is reversed, but the other are not in the same time? 2. kernel crash happens by running of the code from the file base.c if (nv_rd08(bios, 0x700000) != 0x55 || nv_rd08(bios, 0x700001) != 0xaa) { It means that the address reading of 0x700000 results the kernel crash. Why does it happen? The result of the address reading of 0x619f04 is shown for the information. static void nouveau_bios_shadow_pramin(struct nouveau_bios *bios) { struct nouveau_device *device = nv_device(bios); u32 bar0 = 0; int i; unsigned int tmp_val; if (device->card_type >= NV_50) { u64 addr = (u64)(nv_rd32(bios, 0x619f04) & 0xffffff00) << 8; if (!addr) { addr = (u64)nv_rd32(bios, 0x001700) << 16; addr += 0xf0000; } bar0 = nv_mask(bios, 0x001700, 0xffffffff, addr >> 16); } tmp_val = nv_rd32(bios, 0x619f04); printk ("##val=%x\n", tmp_val); In the log we can see the variable value of tmp_val. It is evident that it isn't correct too. Why is the address 0x619f04 not readed correctly and what happens with kernel crash by reading of the addresses of 0x700000 and of 0x700001.
Created attachment 112944 [details] log by nvagetbios -s PRAMIN >vbios_pramin.rom
Created attachment 112945 [details] nvagetbios -s PROM >vbios_prom.rom
Created attachment 112946 [details] nvagetbios_gt610
Created attachment 112947 [details] nvagetbios_gt610
Created attachment 112948 [details] nvagetbios_gt610
"log by nvagetbios -s PRAMIN >vbios_pramin.rom" - for nvidia card with "boot"=0x43100a4 "nvagetbios -s PROM >vbios_prom.rom" - for nvidia card with "boot"=0x43100a4 "nvagetbios_gt610" - for nvidia card gt610
OK, so this is (part of) your problem: nouveau [ DEVICE][0000:01:00.0] BOOT0 : 0xa1a0900d nouveau [ DEVICE][0000:01:00.0] Chipset: nForce (NV1A) nouveau [ DEVICE][0000:01:00.0] Family : NV10 Once this happens, nothing will work. The boot0 seems swapped, it should read back 0x0d90a0a1, which would be a NVD9 (GF119) which is a very reasonable chipset for a GT610 or GT520 to report. [Unlike NV1A which is a GeForce2 IGP from ~2003 or so.] Normally we kick the card into the proper LE/BE mode (which byteswaps all the register reads/writes at the hw level), but perhaps that's not working for some reason? I assume this is a BE box, and there's not a whole lot of testing that goes on (esp for newer cards) on BE. Another thing to note is that nouveau requires 4K pages (not for any great reason, but there's a lot of confusion inside the driver regarding whether system or gpu pages are being used, and PAGE_SHIFT/SIZE aren't universally used in the right places).
) Thank you very much for your answer. I spent a lot of time to get out how the driver works. Yes, powerpc e5500 it is BE arch. Of course byteswaps can be the reason of error but I think it isn't in this case. Could you please clearify two moments. And I'll try to find the problem by myself. 1.Why does the variable "boot" have byteswap but the variable "strap" has the correct value? 2.Why can't the driver read on the address 0x700000 and 0x700001? Please tell me what first steps should I take to find out how to correct the error. Thank!
Created attachment 112952 [details] [review] post write to NV_PMC_BOOT_1 Give this a try.
(In reply to Dmitriy from comment #8) > ) Thank you very much for your answer. > > I spent a lot of time to get out how the driver works. Yes, powerpc e5500 it > is BE arch. Of course byteswaps can be the reason of error but I think it > isn't in this case. [fwiw, ppc le is becoming a thing] > > Could you please clearify two moments. And I'll try to find the problem by > myself. > 1.Why does the variable "boot" have byteswap but the variable "strap" has > the correct value? I don't see anywhere in your kernel log where boot0 is correct. (boot0 is mmio register 0) > 2.Why can't the driver read on the address 0x700000 and 0x700001? Probably because it doesn't do the if (device->card_type >= NV_50) bits which set up instmem to point to the right place. 0x700000 isn't some magical thing... it's a view into vram, and it doesn't get set up because the card gets detected as a NV1A which is *considerably* different from NVD9. (pre-nv50 I think vram always fit into the 0x700000 range so the prefix wasn't a thing... or something.) > > Please tell me what first steps should I take to find out how to correct the > error. In case Ben's patch doesn't fix it, try to figure out what's going on. Until boot0 is read out properly, you can ignore any of the later failures.
There's also a *very* high chance other stuff is going to go wrong. To my knowledge nothing above NV4x has ever been tested on BE. There's likely other endian switches that need flipping (there's a couple on earlier chips), and we don't know where those are.
Created attachment 112968 [details] Gt610_log_patch Thank you. magic patch. "boot" value is now correct. What this command "ioread32_native(map);" do ? but kernel anyway crash on operation read 0x700000. Value bar0 and value from addr.0x619f04 is not correct read. It is show in debug in file bios/base.c file base.c /* switch mmio to cpu's native endianness */ #ifndef __BIG_ENDIAN if (ioread32_native(map + 0x000004) != 0x00000000){ #else if (ioread32_native(map + 0x000004) == 0x00000000){ #endif iowrite32_native(0x01000001, map + 0x000004); ioread32_native(map); } /* read boot0 and strapping information */ boot0 = ioread32_native(map + 0x000000); strap = ioread32_native(map + 0x101000); printk ("##boot0=%x\n",boot0); printk ("##strap=%x\n",strap); file bios/base.c unsigned int tmp_val; if (device->card_type >= NV_50) { u64 addr = (u64)(nv_rd32(bios, 0x619f04) & 0xffffff00) << 8; if (!addr) { addr = (u64)nv_rd32(bios, 0x001700) << 16; addr += 0xf0000; } bar0 = nv_mask(bios, 0x001700, 0xffffffff, addr >> 16); printk ("##%s(%d) bar0=%x\n",__FUNCTION__,__LINE__,bar0); } tmp_val = nv_rd32(bios, 0x619f04); printk ("##val=%x\n", tmp_val);
Created attachment 112969 [details] log for x86 same kernel on x86 machine
(In reply to Dmitriy from comment #12) > Created attachment 112968 [details] > Gt610_log_patch > > Thank you. > > magic patch. > "boot" value is now correct. > What this command "ioread32_native(map);" do ? It does a read of mmio space to make sure the previous write has fully taken effect. > but kernel anyway crash on operation read 0x700000. > > Value bar0 and value from addr.0x619f04 is not correct read. It is show in > debug in file bios/base.c You still need to use a newer kernel. Later kernels have code to detect that there's no VBIOS area setup in VRAM before trying to access it. What's likely happening is your board hasn't been POSTed (likely, because you're not on x86 to have the vbios set stuff up for you), and using the uninitialised memory controllers is making the card very unhappy. Ben. > > file base.c > /* switch mmio to cpu's native endianness */ > #ifndef __BIG_ENDIAN > if (ioread32_native(map + 0x000004) != 0x00000000){ > #else > if (ioread32_native(map + 0x000004) == 0x00000000){ > #endif > iowrite32_native(0x01000001, map + 0x000004); > ioread32_native(map); > } > > /* read boot0 and strapping information */ > boot0 = ioread32_native(map + 0x000000); > strap = ioread32_native(map + 0x101000); > > printk ("##boot0=%x\n",boot0); > printk ("##strap=%x\n",strap); > > file bios/base.c > unsigned int tmp_val; > > if (device->card_type >= NV_50) { > u64 addr = (u64)(nv_rd32(bios, 0x619f04) & 0xffffff00) << 8; > if (!addr) { > addr = (u64)nv_rd32(bios, 0x001700) << 16; > addr += 0xf0000; > } > > bar0 = nv_mask(bios, 0x001700, 0xffffffff, addr >> 16); > printk ("##%s(%d) bar0=%x\n",__FUNCTION__,__LINE__,bar0); > } > > tmp_val = nv_rd32(bios, 0x619f04); > printk ("##val=%x\n", tmp_val);
Created attachment 112971 [details] kernel_3.18.5_log & corenet64_smp_defconfig for powerpc e5500 you're right. Our device has no BIOS. Your magic patch and kernel version 3.18.5 booting ok. /dev/fb0 was created. but I need more time for testing this version After test I will make note about result. Thank you!
Created attachment 113026 [details] incorrect image Dear Ben and Ilia. Thank you for your answers. There is no BIOS on our device. We have u-boot instead of it. But that patch from Ben is necessary even in kernel of the version 3.18.5. The result of the monitor connection is in attach picture. The image is incorrect. I tested both video cards GT520 and GT610, the result is the same. There are some errors in the initialisation log. nouveau E[ PFIFO][0000:01:00.0] PBDMA0: (unknown bits 0x00004000) nouveau E[ PFIFO][0000:01:00.0] PBDMA0: ch 1 [DRM] subc 0 mthd 0x0000 data 0x00000000 ....... nouveau 0000:01:00.0: fb0: nouveaufb frame buffer device nouveau 0000:01:00.0: registered panic notifier Could the wrong work of video card be the reason of these errors? Or what else is to be tested to find out the cause of wrong function.
(In reply to Dmitriy from comment #16) > Created attachment 113026 [details] > incorrect image > > Dear Ben and Ilia. Thank you for your answers. > > There is no BIOS on our device. We have u-boot instead of it. But that patch > from Ben is necessary even in kernel of the version 3.18.5. Yeah, that's expected. The write needs to be posted to the card (not related to BIOS POST), and the extra read forces that to happen. > > The result of the monitor connection is in attach picture. The image is > incorrect. I tested both video cards GT520 and GT610, the result is the same. Welcome to the 1960's :) Neat picture... > > There are some errors in the initialisation log. > nouveau E[ PFIFO][0000:01:00.0] PBDMA0: (unknown bits 0x00004000) > nouveau E[ PFIFO][0000:01:00.0] PBDMA0: ch 1 [DRM] subc 0 mthd 0x0000 data > 0x00000000 > ....... > nouveau 0000:01:00.0: fb0: nouveaufb frame buffer device > nouveau 0000:01:00.0: registered panic notifier The full errors would be useful, esp after userspace starts up. > > Could the wrong work of video card be the reason of these errors? Or what > else is to be tested to find out the cause of wrong function. I suspect there are a few issues here. I'd start with turning acceleration off, that may magically "fix" things (but obviously also lose any sort of accel). You can use Option "NoAccel" "true" in xorg.conf or boot with nouveau.noaccel=1. I guess we may have to tell the card to byteswap stuff and/or use the proper reversed formats (e.g. A2BGR10 vs RGB10A2) when reading from "GART" space... and/or when uploading textures... that'd be annoying. Oh also I'd advise against using mesa's 3d acceleration, at least initially -- there are some well-known byteswap issues there (which may or may not have been fixed, the number of people using BE machines is vanishingly small).
Created attachment 113050 [details] correct image (BOOT0 : 0x043100a4) log with error, I attach to "Comment 15" if use param nouveau.noaccel=1 then log view like this and no error, but the image anyway incorrect: [drm] Initialized drm 1.1.0 20060810 nouveau [ DEVICE][0000:01:00.0] BOOT0 : 0x0d90a0a1 nouveau [ DEVICE][0000:01:00.0] Chipset: GF119 (NVD9) nouveau [ DEVICE][0000:01:00.0] Family : NVC0 nouveau [ VBIOS][0000:01:00.0] checking OpenFirmware for image... nouveau [ VBIOS][0000:01:00.0] Unable to get the OF node nouveau [ VBIOS][0000:01:00.0] ... signature not found nouveau [ VBIOS][0000:01:00.0] checking PRAMIN for image... nouveau [ VBIOS][0000:01:00.0] ... signature not found nouveau [ VBIOS][0000:01:00.0] checking PROM for image... nouveau [ VBIOS][0000:01:00.0] ... appears to be valid nouveau [ VBIOS][0000:01:00.0] using image from PROM nouveau [ VBIOS][0000:01:00.0] BIT signature found nouveau [ VBIOS][0000:01:00.0] version 75.19.55.00.02 nouveau [ DEVINIT][0000:01:00.0] adaptor not initialised nouveau [ VBIOS][0000:01:00.0] running init tables nouveau [ PMC][0000:01:00.0] MSI interrupts enabled nouveau W[ PFB][0000:01:00.0][0x00000000][c0000001fe2c6800] reclocking of this ram type unsupported nouveau [ PFB][0000:01:00.0] RAM type: DDR3 nouveau [ PFB][0000:01:00.0] RAM size: 1024 MiB nouveau [ PFB][0000:01:00.0] ZCOMP: 0 tags nouveau [ VOLT][0000:01:00.0] GPU voltage: 900000uv nouveau [ PTHERM][0000:01:00.0] FAN control: PWM nouveau [ PTHERM][0000:01:00.0] fan management: automatic nouveau [ PTHERM][0000:01:00.0] internal sensor: yes nouveau [ CLK][0000:01:00.0] 07: core 270 MHz memory 405 MHz nouveau [ CLK][0000:01:00.0] 0f: core 810 MHz memory 500 MHz nouveau [ CLK][0000:01:00.0] --: core 270 MHz memory 405 MHz [TTM] Zone kernel: Available graphics memory: 4091134 kiB [TTM] Zone dma32: Available graphics memory: 2097152 kiB [TTM] Initializing pool allocator [TTM] Initializing DMA pool allocator nouveau [ DRM] VRAM: 1024 MiB nouveau [ DRM] GART: 1048576 MiB nouveau [ DRM] TMDS table version 2.0 nouveau [ DRM] DCB version 4.0 nouveau [ DRM] DCB outp 00: 02000300 00000000 nouveau [ DRM] DCB outp 01: 01000302 00020030 nouveau [ DRM] DCB outp 02: 02011362 00020010 nouveau [ DRM] DCB outp 03: 04022310 00000000 nouveau [ DRM] DCB conn 00: 00001030 nouveau [ DRM] DCB conn 01: 00002161 nouveau [ DRM] DCB conn 02: 00000200 [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] Driver supports precise vblank timestamp query. nouveau [ DRM] allocated 1024x768 fb: 0x60000, bo c00000007e2d7400 nouveau 0000:01:00.0: fb0: nouveaufb frame buffer device nouveau 0000:01:00.0: registered panic notifier [drm] Initialized nouveau 1.2.1 20120801 for 0000:01:00.0 on minor 0 And I have video card with "boot=0x043100a4". For this video card no need patch and no need new kernel and bootId always read correct. [drm] Initialized drm 1.1.0 20060810 nouveau [ DEVICE][0000:01:00.0] BOOT0 : 0x043100a4 nouveau [ DEVICE][0000:01:00.0] Chipset: NV43 (NV43) nouveau [ DEVICE][0000:01:00.0] Family : NV40 nouveau [ VBIOS][0000:01:00.0] checking OpenFirmware for image... nouveau [ VBIOS][0000:01:00.0] Unable to get the OF node nouveau [ VBIOS][0000:01:00.0] ... signature not found nouveau [ VBIOS][0000:01:00.0] checking PRAMIN for image... nouveau [ VBIOS][0000:01:00.0] ... signature not found nouveau [ VBIOS][0000:01:00.0] checking PROM for image... nouveau [ VBIOS][0000:01:00.0] ... appears to be valid nouveau [ VBIOS][0000:01:00.0] using image from PROM nouveau [ VBIOS][0000:01:00.0] BIT signature found nouveau [ VBIOS][0000:01:00.0] version 05.43.02.88.00 nouveau [ DEVINIT][0000:01:00.0] adaptor not initialised nouveau [ VBIOS][0000:01:00.0] running init tables nouveau [ PFB][0000:01:00.0] RAM type: DDR2 nouveau [ PFB][0000:01:00.0] RAM size: 512 MiB for this video card early I attach log by nvagetbios for info log by nvagetbios -s PRAMIN >vbios_pramin.rom (64.00 KB, text/plain) 2015-01-29 15:12 nvagetbios -s PROM >vbios_prom.rom (1.00 MB, text/plain) 2015-01-29 15:13 and screen view is correct. Why does GT520 or GT610 not work like video card with "BOOT0: 0x043100a4" (((
(In reply to Dmitriy from comment #18) > Created attachment 113050 [details] > correct image (BOOT0 : 0x043100a4) > > log with error, I attach to "Comment 15" > > if use param nouveau.noaccel=1 then log view like this and no error, but the > image anyway incorrect: > [drm] Initialized drm 1.1.0 20060810 > nouveau [ DEVICE][0000:01:00.0] BOOT0 : 0x0d90a0a1 > nouveau [ DEVICE][0000:01:00.0] Chipset: GF119 (NVD9) > nouveau [ DEVICE][0000:01:00.0] Family : NVC0 > nouveau [ VBIOS][0000:01:00.0] checking OpenFirmware for image... > nouveau [ VBIOS][0000:01:00.0] Unable to get the OF node > nouveau [ VBIOS][0000:01:00.0] ... signature not found > nouveau [ VBIOS][0000:01:00.0] checking PRAMIN for image... > nouveau [ VBIOS][0000:01:00.0] ... signature not found > nouveau [ VBIOS][0000:01:00.0] checking PROM for image... > nouveau [ VBIOS][0000:01:00.0] ... appears to be valid > nouveau [ VBIOS][0000:01:00.0] using image from PROM > nouveau [ VBIOS][0000:01:00.0] BIT signature found > nouveau [ VBIOS][0000:01:00.0] version 75.19.55.00.02 > nouveau [ DEVINIT][0000:01:00.0] adaptor not initialised > nouveau [ VBIOS][0000:01:00.0] running init tables > nouveau [ PMC][0000:01:00.0] MSI interrupts enabled > nouveau W[ PFB][0000:01:00.0][0x00000000][c0000001fe2c6800] reclocking > of this ram type unsupported > nouveau [ PFB][0000:01:00.0] RAM type: DDR3 > nouveau [ PFB][0000:01:00.0] RAM size: 1024 MiB > nouveau [ PFB][0000:01:00.0] ZCOMP: 0 tags > nouveau [ VOLT][0000:01:00.0] GPU voltage: 900000uv > nouveau [ PTHERM][0000:01:00.0] FAN control: PWM > nouveau [ PTHERM][0000:01:00.0] fan management: automatic > nouveau [ PTHERM][0000:01:00.0] internal sensor: yes > nouveau [ CLK][0000:01:00.0] 07: core 270 MHz memory 405 MHz > nouveau [ CLK][0000:01:00.0] 0f: core 810 MHz memory 500 MHz > nouveau [ CLK][0000:01:00.0] --: core 270 MHz memory 405 MHz > [TTM] Zone kernel: Available graphics memory: 4091134 kiB > [TTM] Zone dma32: Available graphics memory: 2097152 kiB > [TTM] Initializing pool allocator > [TTM] Initializing DMA pool allocator > nouveau [ DRM] VRAM: 1024 MiB > nouveau [ DRM] GART: 1048576 MiB > nouveau [ DRM] TMDS table version 2.0 > nouveau [ DRM] DCB version 4.0 > nouveau [ DRM] DCB outp 00: 02000300 00000000 > nouveau [ DRM] DCB outp 01: 01000302 00020030 > nouveau [ DRM] DCB outp 02: 02011362 00020010 > nouveau [ DRM] DCB outp 03: 04022310 00000000 > nouveau [ DRM] DCB conn 00: 00001030 > nouveau [ DRM] DCB conn 01: 00002161 > nouveau [ DRM] DCB conn 02: 00000200 > [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [drm] Driver supports precise vblank timestamp query. > nouveau [ DRM] allocated 1024x768 fb: 0x60000, bo c00000007e2d7400 > nouveau 0000:01:00.0: fb0: nouveaufb frame buffer device > nouveau 0000:01:00.0: registered panic notifier > [drm] Initialized nouveau 1.2.1 20120801 for 0000:01:00.0 on minor 0 > > > > And I have video card with "boot=0x043100a4". For this video card no need > patch and no need new kernel and bootId always read correct. > [drm] Initialized drm 1.1.0 20060810 > nouveau [ DEVICE][0000:01:00.0] BOOT0 : 0x043100a4 > nouveau [ DEVICE][0000:01:00.0] Chipset: NV43 (NV43) > nouveau [ DEVICE][0000:01:00.0] Family : NV40 > nouveau [ VBIOS][0000:01:00.0] checking OpenFirmware for image... > nouveau [ VBIOS][0000:01:00.0] Unable to get the OF node > nouveau [ VBIOS][0000:01:00.0] ... signature not found > nouveau [ VBIOS][0000:01:00.0] checking PRAMIN for image... > nouveau [ VBIOS][0000:01:00.0] ... signature not found > nouveau [ VBIOS][0000:01:00.0] checking PROM for image... > nouveau [ VBIOS][0000:01:00.0] ... appears to be valid > nouveau [ VBIOS][0000:01:00.0] using image from PROM > nouveau [ VBIOS][0000:01:00.0] BIT signature found > nouveau [ VBIOS][0000:01:00.0] version 05.43.02.88.00 > nouveau [ DEVINIT][0000:01:00.0] adaptor not initialised > nouveau [ VBIOS][0000:01:00.0] running init tables > nouveau [ PFB][0000:01:00.0] RAM type: DDR2 > nouveau [ PFB][0000:01:00.0] RAM size: 512 MiB > > > for this video card early I attach log by nvagetbios for info > log by nvagetbios -s PRAMIN >vbios_pramin.rom (64.00 KB, text/plain) > 2015-01-29 15:12 > > nvagetbios -s PROM >vbios_prom.rom (1.00 MB, text/plain) > 2015-01-29 15:13 > > and screen view is correct. > > Why does GT520 or GT610 not work like video card with "BOOT0: 0x043100a4" ((( Because those boards are about 5 generations newer, and almost *completely* different. As I already told you, nothing newer has ever been tested on big-endian to my knowledge. I have access to a G5, and planned to look into it today, but technical difficulties and more pressing issues got in the way.
Ben, I understand all of this and I can't demand anything from you. May I ask you 2 questions: 1. Is there any possibility that you will create a new patch which will support GT610 or GT520? 2. What do you think, is it possible that I will solve the problem by myself and create the patch by myself?
for example some debug in function "nouveau_bios_shadow_pramin" in kernel 3.18.5: if (device->card_type >= NV_50) { if (device->card_type >= NV_C0 && device->card_type < GM100) { printk ("%s(%d)\n",__FUNCTION__,__LINE__); if (nv_rd32(bios, 0x022500) & 0x00000001) return; } else if (device->card_type >= GM100) { printk ("##%s(%d)\n",__FUNCTION__,__LINE__); if (nv_rd32(bios, 0x021c04) & 0x00000001) return; } addr = nv_rd32(bios, 0x619f04); printk ("addr0=%x\n",addr); ..... bar0 = nv_mask(bios, 0x001700, 0xffffffff, addr >> 16); printk ("bar0=%x\n",bar0); log from x86_64: [ 0.279595] [drm] Initialized drm 1.1.0 20060810 [ 0.280027] nouveau [ DEVICE][0000:01:00.0] BOOT0 : 0x0d90a0a1 [ 0.280196] nouveau [ DEVICE][0000:01:00.0] Chipset: GF119 (NVD9) [ 0.280361] nouveau [ DEVICE][0000:01:00.0] Family : NVC0 [ 0.280533] nouveau [ VBIOS][0000:01:00.0] checking PRAMIN for image... [ 0.280723] nouveau_bios_shadow_pramin(94) [ 0.280881] addr=3ffe09 [ 0.281032] bar0=3ff0 [ 0.358740] nouveau [ VBIOS][0000:01:00.0] ... appears to be valid [ 0.358913] nouveau [ VBIOS][0000:01:00.0] using image from PRAMIN [ 0.359161] nouveau [ VBIOS][0000:01:00.0] BIT signature found [ 0.359333] nouveau [ VBIOS][0000:01:00.0] version 75.19.55.00.02 [ 0.359705] nouveau 0000:01:00.0: irq 25 for MSI/MSI-X [ 0.359712] nouveau [ PMC][0000:01:00.0] MSI interrupts enabled [ 0.359974] nouveau W[ PFB][0000:01:00.0][0x00000000][ffff88021385e800] reclocking of this ram type unsupported [ 0.360322] nouveau [ PFB][0000:01:00.0] RAM type: DDR3 [ 0.360542] nouveau [ PFB][0000:01:00.0] RAM size: 1024 MiB [ 0.360794] nouveau [ PFB][0000:01:00.0] ZCOMP: 0 tags [ 0.362663] nouveau [ VOLT][0000:01:00.0] GPU voltage: 900000uv [ 0.412297] nouveau [ PTHERM][0000:01:00.0] FAN control: PWM [ 0.412543] nouveau [ PTHERM][0000:01:00.0] fan management: automatic [ 0.412822] nouveau [ PTHERM][0000:01:00.0] internal sensor: yes [ 0.413119] nouveau [ CLK][0000:01:00.0] 07: core 270 MHz memory 405 MHz [ 0.413454] nouveau [ CLK][0000:01:00.0] 0f: core 810 MHz memory 500 MHz [ 0.413951] nouveau [ CLK][0000:01:00.0] --: core 270 MHz memory 405 MHz log from powerpc e5500 64bit: [drm] Initialized drm 1.1.0 20060810 nouveau [ DEVICE][0000:01:00.0] BOOT0 : 0x0d90a0a1 nouveau [ DEVICE][0000:01:00.0] Chipset: GF119 (NVD9) nouveau [ DEVICE][0000:01:00.0] Family : NVC0 nouveau [ VBIOS][0000:01:00.0] checking OpenFirmware for image... nouveau [ VBIOS][0000:01:00.0] Unable to get the OF node nouveau [ VBIOS][0000:01:00.0] ... signature not found nouveau [ VBIOS][0000:01:00.0] checking PRAMIN for image... nouveau_bios_shadow_pramin(94) addr0=1 nouveau [ VBIOS][0000:01:00.0] ... signature not found nouveau [ VBIOS][0000:01:00.0] checking PROM for image... nouveau [ VBIOS][0000:01:00.0] ... appears to be valid nouveau [ VBIOS][0000:01:00.0] using image from PROM nouveau [ VBIOS][0000:01:00.0] BIT signature found nouveau [ VBIOS][0000:01:00.0] version 75.19.55.00.02 nouveau [ DEVINIT][0000:01:00.0] adaptor not initialised nouveau [ VBIOS][0000:01:00.0] running init tables nouveau [ PMC][0000:01:00.0] MSI interrupts enabled nouveau W[ PFB][0000:01:00.0][0x00000000][c0000001fe53c000] reclocking of this ram type unsupported nouveau [ PFB][0000:01:00.0] RAM type: DDR3 nouveau [ PFB][0000:01:00.0] RAM size: 1024 MiB nouveau [ PFB][0000:01:00.0] ZCOMP: 0 tags nouveau [ VOLT][0000:01:00.0] GPU voltage: 900000uv nouveau [ PTHERM][0000:01:00.0] FAN control: PWM nouveau [ PTHERM][0000:01:00.0] fan management: automatic nouveau [ PTHERM][0000:01:00.0] internal sensor: yes nouveau [ CLK][0000:01:00.0] 07: core 270 MHz memory 405 MHz nouveau [ CLK][0000:01:00.0] 0f: core 810 MHz memory 500 MHz nouveau [ CLK][0000:01:00.0] --: core 270 MHz memory 405 MHz result of operation: addr = nv_rd32(bios, 0x619f04); for x86: addr=3ffe09 for ppc: addr0=1 Why do the results of reading operation differ from each other?
(In reply to Dmitriy from comment #21) > [...] > > result of operation: > addr = nv_rd32(bios, 0x619f04); > > for x86: addr=3ffe09 > for ppc: addr0=1 > > Why do the results of reading operation differ from each other? I believe Ben already answered that one, but perhaps it's not that obvious if one does not have experience with nouveau. The PRAMIN region (in this context) is the last 1MiB or VRAM. As the card is POSTed/initialised the VBIOS is copied in that region. As you can see on x86 your card is initialised, unlike on PPC. Regarding your earlier question(s) (despite that I'm not Ben) > 1. Is there any possibility that you will create a new patch which will support > GT610 or GT520? I doubt that only a single patch will do the job. Afaict there as need (close to) 0 work done understanding what needs to be done, let alone writing the patch(es). > 2. What do you think, is it possible that I will solve the problem by myself > and create the patch by myself? No offence/disrespect, but I think you are underestimating how deep the waters are(could be). Even if on the nouveau side everything is fixed, there has been a few issues in mesa (as pointed by Ilia) wrt big endian machines, which afaict are not resolved. Maybe you can take a look and fix (if needed) the software rendering on BE machines. That should cover some of the mesa bits :)
As I understand we have 2 problems: 1. No Bios. 2. BE The driver is not working on this stage because there is no bios but not of the plattform BE we have. Is it right? If it is, we have the same problem for all of the ARM platforms. Could you please give me the link to the theoretic part of this problem. Is there any information source about driver working and about card initialisation. Thank you for your answers!
Created attachment 113202 [details] fragment of my fdt Ben, help me please with the code. I don't ask you to create the patch. Please give me only comments to your code. There is the following line in your code (bios/base.c): data = of_get_property(dn, "NVDA,BMP", &size); As I understand there is the operation for "NVDA" searching on flat device tree file. I haven't this field in my fdt. Tell me please how should it look like? I can' t find any example in internet. As I understand my card cannot be initialized because of the missing of this field.
(In reply to Dmitriy from comment #24) > As I understand my card cannot be initialized because of the missing of this > field. Huh? Your card comes up fine now. NVDA,BMP is how macs passed in their vbios. Your vbios is read out using PROM just fine. Your current issue is something minor, like the color LUT being written in wrong, or a missing byteswap on a texture (or one too many!)
блин какой-то треш, один пишет проинициализирована, другой не проинициализирована. (((
(In reply to Dmitriy from comment #26) > блин какой-то треш, > > один пишет проинициализирована, другой не проинициализирована. ((( You're misunderstanding what is written. Your questions are being answered, but you're not asking the questions you think you are, and you're not understanding the answers in the way they're intended. You do not have a BIOS, so the VBIOS does not get initialized into the PRAMIN area of the video card (which would happen when the BIOS executes the 16-bit x86 code in the option rom supplied by the video card). This is why the x86 boot is different from the PPC boot. But that's OK -- the VBIOS can come from many places, one of which is the PROM. As you can see in your logs, the VBIOS is successfully read out from there. And you're getting graphics (albeit with messed up coloring), which is a pretty good indicator that the card is mostly coming up OK.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/167.
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.