Pismo Aty128fb problem in 2.4.3-pre*?

Pismo Aty128fb problem in 2.4.3-pre*?

[Henry Worth]

I wasn't able to boot Kaoru-san's 2.4.3-pre1_0a binary
or kernels built from bitkeeper tar's of 2.4.3-pre1 and pre2.
This is on a Pismo and in all cases there's a sequence of
early boot messages ending in "open_pic exit" and then a few
seconds pause before the screen goes haywire (mostly blank,
but with a flashing fragments of a couple of the boot messages
and some other artifacts).

So, it finally dawned on me that I should try video=ofonly
and novideo bootparms instead of the usual aty128fb parms
and they both boot.

Is this a known problem? Or does 2.4.* require different
video bootparms for the Rage 128 than 2.2.*?

Haven't messed with 2.4 since the late 2.3 period, so I
don't have have anything to compare against to look for
changes. What's the last version of 2.4.* that aty128fb
is known to work, particularly for the Pismo, and are
the sources available somewhere to rsync or as a tarball?

Henry

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Pismo Aty128fb problem in 2.4.3-pre*?

[Henry Worth]

I've dug through the /var/log/messages, and the system
did continue booting in the video=aty128fb cases. In all cases
I'm seeing the following messages:

2.4.3-pre[12]

  kernel: PCI: Enabling device 00:10.0 (0086 -> 0087)
  kernel: aty128fb: Rage Mobility M3 (AGP) [chip rev 0x0] 8M 128-bit SDR SGRAM (1:1)
  kernel: Console: switching to colour frame buffer device 80x30
  kernel: Registered "ati" backlight controller, level: 10/15
  kernel: fb0: ATY Rage128 frame buffer device on PCI
  kernel: no framebuffer address found for
              /pci@f0000000/ATY,RageM3pParent@10/ATY,RageM3pB


With video=ofonly

  kernel: Using unsupported 1024x768 ATY,RageM3pA at a4008000, depth=8, pitch=1024
  kernel: Console: switching to colour frame buffer device 128x48
  kernel: fb0: Open Firmware frame buffer device
             on /pci@f0000000/ATY,RageM3pParent@10/ATY,RageM3pA
  kernel: no framebuffer address found for
             /pci@f0000000/ATY,RageM3pParent@10/ATY,RageM3pB


2.2.19pre13


  kernel: aty128fb: Rage Mobility M3 (AGP) [chip rev 0x0] 8M 128-bit SDR SGRAM (1:1)
  kernel: Console: switching to colour frame buffer device 128x48
  kernel: Registered "ati" backlight controller, level: 10/15
  kernel: fb0: ATY Rage128 frame buffer device on /pci@f0000000/ATY,RageM3pParent@10

The earlier PCI probe messages in all 2.4.* cases are:

  kernel: PCI: Probing PCI hardware
  kernel: Fixup IO res, dev: 0.10, res_start: 400->802400
  kernel: Can't get bus-range for /pci@f2000000/cardbus@1a
  kernel: PCI->OF bus map:
  kernel: 0 -> 0
  kernel: 1 -> 0
  kernel: 6 -> 0
  kernel: PCI:0:10:0: Resource a4000000-a7ffffff (f=1208)
  kernel: PCI:0:10:0: Resource a0000000-a0003fff (f=200)
  kernel: PCI:1:17:0: Resource 80000000-8007ffff (f=200)
  kernel: PCI:1:1a:0: Resource 80080000-80080fff (f=200)
  kernel: PCI:0:10:0: Resource 00802400-008024ff (f=101)
  kernel: PCI:1:18:0: Resource 80082000-80082fff (f=200)
  kernel: PCI:1:19:0: Resource 80081000-80081fff (f=200)
  kernel: PCI:6:e:0: Resource f5000000-f5000fff (f=200)


Is the current fb driver getting confused by the dual
framebuffers in the OF tree?

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Pismo Aty128fb problem in 2.4.3-pre*?

[Henry Worth]

Narrowed down the problem a bit more. Specifying
"video=aty128fb:mode:17" works; also without the mode.
But, adding a depth parm (8,16,24, or 32) causes the
fb init failure. It defaults to 8 and fbset works for
8,15,16,32 but 24 causes a blurry image.

Henry

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Pismo Aty128fb problem in 2.4.3-pre*?

[Michel Dänzer]

Henry Worth wrote:
>
> Narrowed down the problem a bit more. Specifying
> "video=aty128fb:mode:17" works; also without the mode.
> But, adding a depth parm (8,16,24, or 32) causes the
> fb init failure. It defaults to 8 and fbset works for
> 8,15,16,32 but 24 causes a blurry image.

The last is - *tadda* - an endianness error. aty128fb incorrectly enables byte
swapping for 24 bit, which can easily be fixed; look for CONFIG_CNTL .


--
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Pismo Aty128fb problem in 2.4.3-pre*?

[Henry Worth]

Michel Dänzer wrote:
>
> Henry Worth wrote:
> >
> > Narrowed down the problem a bit more. Specifying
> > "video=aty128fb:mode:17" works; also without the mode.
> > But, adding a depth parm (8,16,24, or 32) causes the
> > fb init failure. It defaults to 8 and fbset works for
> > 8,15,16,32 but 24 causes a blurry image.
>
> The last is - *tadda* - an endianness error. aty128fb incorrectly enables byte
> swapping for 24 bit, which can easily be fixed; look for CONFIG_CNTL .
>

Great, one more bug bites the dust. On the first I had picked
up the incorrect keyword somewhere ("depth" instead of "cmode"),
and had been using it from day one. On 2.2 it was ignored and
the display left at 8bpp, in 2.4 it now causes init to leave
the display in a strange state. If that doesn't help you
find it, I'll dig into the code in a couple of days. With cmode
all is fine.

Is there any hope that the ATI 128 DRI stuff is going to
get reenabled soon?

Henry

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Pismo Aty128fb problem in 2.4.3-pre*?

[Michel Dänzer]

Henry Worth wrote:

> Is there any hope that the ATI 128 DRI stuff is going to get reenabled soon?

Yes, the branch of the DRI CVS dedicated to adding PCI GART support (which is
needed for us since we don't have AGP GART support yet) is basically done and
its merge into the trunk is imminent. Unfortunately, it doesn't work right
now, but there is a freeze tag which might work.


--
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/