PB2000 (pismo) install feedback

PB2000 (pismo) install feedback

[Chris Leishman]

Hi all,

(I finally got yaboot configured (using a 100M bootstrap partition, hd:9), on
my pismo so I could test the pismo kernel.)

I compiled the kernel on a Lombard I have here, then moved the kernel
(vmlinux) onto my pismo bootstrap partition.  Initially yaboot.conf contained:

image=hd:9,vmlinux
	label=install
	initrd=hd:9,ramdisk.image.gz
	initrd-size=8192
	novideo

However, on booting the kernel, I had some very pretty errors with the video
(very, very surreal - looked like a CRT next to a big magnet).  However, when
I removed "novideo" flag it booted straight up!

Any ideas Ben & co?  Is this a known issue?

Regards,

Chris


--
----------------------------------------------------------------------
            Linux, because I'd like to *get there* today
----------------------------------------------------------------------
Reply with subject 'request key' for GPG public key.  KeyID 0xB4E24219

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

Re: PB2000 (pismo) install feedback

[Michael Schmitz]

> >There's been a patch by Geert on this list to fix this - basically
> >subtract GUI_RESERVE from the determined vram size in atyfb.c for all 8 MB
> >Rage Pro (and possibly other) chips to prevent the screen clear from
> >stepping on the card registers.
>
> It's a different issue. This machine has a r128 and aty128fb works fine
> with the few fixes we added for the M3. The problem is with offb and seem
> to be related to some timing issues when accessing the DAC palette
> registers. Henry found a fix for this, I'll add this to my kernel asap.

OK, I didn't catch the point that the new PB has a rage128. You're lucky,
then.

	Michael


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

Re: PB2000 (pismo) install feedback

[Henry Worth]

This is the old RAMDAC problem of trying to write to the pallete
registers
too soon after setting the index, complicated by an integrated chipset
and
probably PCI I/O write posting as well. It results in the display having
about 8 vertical bands and a big bright spot alternating between them.
It also makes the bubbles in the layers of film making up the LCD show
through so that it looks a bit like when a frame of motion picture film
burns in the projector.

It's very timing sensitive, a slight rearrangment of the code eliminated
the "burnout", but didn't fix the ongoing offb colormap problems. Adding
a small delay between writing the index and the palette value fixed the
colomap problem. I rearranged the code to just set the index once and
then use the palette index register's auto-incrementing to avoid the
index write and delay in the loop, and that worked as well. I think
Ben is planning to use a read back of the index register to ensure the
write is posted and and give enough of a delay.

Does anyone know if any of the ATI chips don't have autoincrementing of
the palette index? That's been a fairly standard feature of RAMDAC's
for a long time. So I was a bit surprised to see the frame buffers
explicitly setting the index on every iteration, especially since
the race between writing the palette index and the data has been
a common problem for a long time.

Henry

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

Re: PB2000 (pismo) install feedback

[Benjamin Herrenschmidt]

On Thu, Mar 23, 2000, Henry Worth <haworth@ncal.verio.com> wrote:

>It's very timing sensitive, a slight rearrangment of the code eliminated
>the "burnout", but didn't fix the ongoing offb colormap problems. Adding
>a small delay between writing the index and the palette value fixed the
>colomap problem. I rearranged the code to just set the index once and
>then use the palette index register's auto-incrementing to avoid the
>index write and delay in the loop, and that worked as well. I think
>Ben is planning to use a read back of the index register to ensure the
>write is posted and and give enough of a delay.
>
>Does anyone know if any of the ATI chips don't have autoincrementing of
>the palette index? That's been a fairly standard feature of RAMDAC's
>for a long time. So I was a bit surprised to see the frame buffers
>explicitly setting the index on every iteration, especially since
>the race between writing the palette index and the data has been
>a common problem for a long time.

What bugs me is that we have no such delay in aty128fb.c and you didn't
see the problem occur. Looks like a 1 instruction timing (one eieio) is
enough, so I beleive reading back the index is enough. We didn't have
this problem with older r128, so this may be a side effect of the
swadowing of the 2 sets of palette registers in the M3.


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

Re: PB2000 (pismo) install feedback

[Henry Worth]

Benjamin Herrenschmidt wrote:
>
> On Thu, Mar 23, 2000, Henry Worth <haworth@ncal.verio.com> wrote:
>
> >It's very timing sensitive, a slight rearrangment of the code eliminated
> >the "burnout", but didn't fix the ongoing offb colormap problems. Adding
> >a small delay between writing the index and the palette value fixed the
> >colomap problem. I rearranged the code to just set the index once and
> >then use the palette index register's auto-incrementing to avoid the
> >index write and delay in the loop, and that worked as well. I think
> >Ben is planning to use a read back of the index register to ensure the
> >write is posted and and give enough of a delay.
> >
> >Does anyone know if any of the ATI chips don't have autoincrementing of
> >the palette index? That's been a fairly standard feature of RAMDAC's
> >for a long time. So I was a bit surprised to see the frame buffers
> >explicitly setting the index on every iteration, especially since
> >the race between writing the palette index and the data has been
> >a common problem for a long time.
>
> What bugs me is that we have no such delay in aty128fb.c and you didn't
> see the problem occur. Looks like a 1 instruction timing (one eieio) is
> enough, so I beleive reading back the index is enough. We didn't have
> this problem with older r128, so this may be a side effect of the
> swadowing of the 2 sets of palette registers in the M3

Possibly, with the extra control logic and the need to minimize the
gate count and power consumption for a mobile use, the control
logic may be somewhat slower than most modern chips. And with
all the integration and duplication, timing errors may send data
off to some very nasty places. Then again the Pismo and Sawmill
are cranking both CPU and I/O bus speeds up another notch, so
perhaps some of these classic timing issues will start cropping
up again.

The code in aty128fb.c isn't quite as tight as the offb.c
cases. In both aty128fb.c cases there is a statement between the
index out and the data out that does a couple of shifts to form
the palette data value, and there would be no advantage for the
compiler to schedule it before the first out. A quick grep didn't
find the definition for aty_st_8, is it completely identical to
out_8, particularly with the macros used to form the address?

The change from the case fall through to completely seperate
case blocks, which stopped the "burnout" effect in offb, would
have removed a barrier for optimization and register use between
setting the DAC select control and the palette index write.
So the code that didn't create the 'burnout' should have had
even less delay between out's. Which is really puzzling, yet
it was completely recreatable.

Henry

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

offb.c fix (Re: PB2000 (pismo) install feedback

[Henry Worth]

Ben,

I've found the real problem with the linux-pmac_benh offb.c.
Simple pointer arithmetic problem. This fixes both the
"burnout" effect and the colormap problems.

Henry

*** offb.c.orig4        Sat Mar 25 00:20:05 2000
--- offb.c      Sat Mar 25 00:20:44 2000
***************
*** 914,920 ****
      case cmap_r128:
        /* Set palette index & data */
        out_8(info2->cmap_adr + 0xb0, regno);
!       out_le32((unsigned *)(info2->cmap_adr) + 0xb4,
                (red << 16 | green << 8 | blue));
        break;
      case cmap_M3B:
--- 914,920 ----
      case cmap_r128:
        /* Set palette index & data */
        out_8(info2->cmap_adr + 0xb0, regno);
!       out_le32((unsigned *)(info2->cmap_adr + 0xb4),
                (red << 16 | green << 8 | blue));
        break;
      case cmap_M3B:

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