Nouveau - Jan 2015 - [Bug 88868] New: PowerPC e5500, kernel crash, GT520, GT610

https://bugs.freedesktop.org/show_bug.cgi?id=88868

            Bug ID: 88868
           Summary: PowerPC e5500, kernel crash, GT520, GT610
           Product: xorg
           Version: unspecified
          Hardware: PowerPC
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Driver/nouveau
          Assignee: nouveau at lists.freedesktop.org
          Reporter: oboturoff at gmail.com
        QA Contact: xorg-team at lists.x.org

Created attachment 112941
  --> https://bugs.freedesktop.org/attachment.cgi?id=112941&action=edit
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150129/94575466/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88868

--- Comment #1 from Dmitriy <oboturoff at gmail.com> ---
Created attachment 112944
  --> https://bugs.freedesktop.org/attachment.cgi?id=112944&action=edit
log by nvagetbios -s PRAMIN >vbios_pramin.rom

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150129/caeeacae/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88868

--- Comment #2 from Dmitriy <oboturoff at gmail.com> ---
Created attachment 112945
  --> https://bugs.freedesktop.org/attachment.cgi?id=112945&action=edit
nvagetbios -s PROM >vbios_prom.rom

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150129/3ccbbefb/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88868

--- Comment #3 from Dmitriy <oboturoff at gmail.com> ---
Created attachment 112946
  --> https://bugs.freedesktop.org/attachment.cgi?id=112946&action=edit
nvagetbios_gt610

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150129/84f30042/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88868

Dmitriy <oboturoff at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #112946|0                           |1
        is obsolete|                            |

--- Comment #4 from Dmitriy <oboturoff at gmail.com> ---
Created attachment 112947
  --> https://bugs.freedesktop.org/attachment.cgi?id=112947&action=edit
nvagetbios_gt610

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150129/433d5d60/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88868

Dmitriy <oboturoff at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #112947|0                           |1
        is obsolete|                            |

--- Comment #5 from Dmitriy <oboturoff at gmail.com> ---
Created attachment 112948
  --> https://bugs.freedesktop.org/attachment.cgi?id=112948&action=edit
nvagetbios_gt610

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150129/364e55eb/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88868

--- Comment #6 from Dmitriy <oboturoff at gmail.com> ---
"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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150129/ce98707e/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88868

--- Comment #7 from Ilia Mirkin <imirkin at alum.mit.edu> ---
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).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150129/9281995c/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88868

--- Comment #8 from Dmitriy <oboturoff at gmail.com> ---
) 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!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150129/0f736349/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88868

--- Comment #9 from Ben Skeggs <skeggsb at gmail.com> ---
Created attachment 112952
  --> https://bugs.freedesktop.org/attachment.cgi?id=112952&action=edit
post write to NV_PMC_BOOT_1

Give this a try.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150129/deac5667/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88868

--- Comment #10 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150130/cfede981/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88868

--- Comment #11 from Ben Skeggs <skeggsb at gmail.com> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150130/de0ad103/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88868

--- Comment #12 from Dmitriy <oboturoff at gmail.com> ---
Created attachment 112968
  --> https://bugs.freedesktop.org/attachment.cgi?id=112968&action=edit
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);

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150130/60c12eac/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88868

--- Comment #13 from Dmitriy <oboturoff at gmail.com> ---
Created attachment 112969
  --> https://bugs.freedesktop.org/attachment.cgi?id=112969&action=edit
log for x86

same kernel on x86 machine

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150130/1033f4a5/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88868

--- Comment #14 from Ben Skeggs <skeggsb at gmail.com> ---
(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);
-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150130/78861793/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88868

--- Comment #15 from Dmitriy <oboturoff at gmail.com> ---
Created attachment 112971
  --> https://bugs.freedesktop.org/attachment.cgi?id=112971&action=edit
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!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150130/af84fa82/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88868

--- Comment #16 from Dmitriy <oboturoff at gmail.com> ---
Created attachment 113026
  --> https://bugs.freedesktop.org/attachment.cgi?id=113026&action=edit
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150201/81f181cd/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88868

--- Comment #17 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(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).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150201/17176e55/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88868

--- Comment #18 from Dmitriy <oboturoff at gmail.com> ---
Created attachment 113050
  --> https://bugs.freedesktop.org/attachment.cgi?id=113050&action=edit
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" (((

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150202/b9730496/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88868

--- Comment #19 from Ben Skeggs <skeggsb at gmail.com> ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150202/8c0e3b93/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88868

--- Comment #20 from Dmitriy <oboturoff at gmail.com> ---
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?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150202/19dd37d3/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88868

--- Comment #21 from Dmitriy <oboturoff at gmail.com> ---
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?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150203/0951325a/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88868

--- Comment #22 from Emil Velikov <emil.l.velikov at gmail.com> ---
(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 :)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150203/5fcf683c/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88868

--- Comment #23 from Dmitriy <oboturoff at gmail.com> ---
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!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150204/60d8ec4e/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88868

--- Comment #24 from Dmitriy <oboturoff at gmail.com> ---
Created attachment 113202
  --> https://bugs.freedesktop.org/attachment.cgi?id=113202&action=edit
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150205/09ada021/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88868

--- Comment #25 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(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!)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150205/43ac2531/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88868

--- Comment #26 from Dmitriy <oboturoff at gmail.com> ---
блин какой-то треш,

один пишет проинициализирована, другой не проинициализирована. (((

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150205/e459fe9a/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88868

--- Comment #27 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150205/38bbc355/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88868

Martin Peres <martin.peres at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |MOVED
             Status|NEW                         |RESOLVED

--- Comment #28 from Martin Peres <martin.peres at free.fr> ---
-- 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20191204/6bc4347d/attachment.html>