Re: Panic at boot on 4/330 with cgfour and cgsix

[foo bar <tokenalt%gmail.com@localhost>]

On Tue, Mar 4, 2025 at 8:00 AM Julian Coleman <jdc%coris.org.uk@localhost> wrote:
>
> Hi,
>
> > So I've been playing with this patch for a while but unfortunately
> > I've been unable to get it to work. This patch causes a panic at boot,
> > something like async memory error..timeout. I think it's just trying
> > to read an address that doesn't exist. Here's the code that caused it.
> >
> >        /* XXX: PFOUR_COLOR_OFF_CMAP assumes 32 bit wraparound */
> >        cmap_pa = (paddr_t)oba->oba_paddr + (paddr_t)PFOUR_COLOR_OFF_CMAP;
> >         if (bus_space_map(oba->oba_bustag,
> >                          cmap_pa,
> >
> > I think the root problem is that PFOUR_COLOR_OFF_CMAP claims to be an
> > offset but is actually the full address of the ramdac. I reverted
> > those lines and changed PFOUR_COLOR_OFF_CMAP to (-0x00100000) which is
> > what the actual offset is and it worked for a few more lines then I
> > got another panic. I wasn't able to capture the panic message but this
> > is the line that caused it.
>
> Sounds like it's easiest to just use (-0x00100000).

Yes that is what I think now as well. I checked cvs history and the
sun3 cgfour driver has been using a negative offset since 1998 and has
worked for many people including me. So if it's good enough for sun3 I
don't see why it can't be good enough for sparc.

> > memset(sc->sc_fb.fb_pixels, (defattr >> 16) & 0xff, sc->sc_stride *
> > sc->sc_height);
> >
> > I don't understand what's wrong with this line. Some other drivers use
> > something like this with no issues so I don't know why this doesn't
> > work but since it's just clearing the screen it's not really needed so
> > I commented it out. This allowed it to continue for a few more lines
> > then I got a watchdog timeout on this line. Not sure why this fails.
> >
> > wsdisplay_cnattach(&cgfour_defaultscreen, ri, 0, 0, defattr);
>
> I'm guessing that we have the location of the video ram wrong.  If I read
> correctly, everything should be relative to PFOUR_COLOR_OFF_COLOR.  What
> value do we calculate for that?

It seems like the start address is the pfour regesters actually.
PFOUR_COLOR_OFF_COLOR seems correct, at least it's the same offset
that sun3 calls CG4B_OFF_PIXMAP. But the bigger problem is that
fb_pixels is never assigned a value so there's no actual pointer to
the framebuffer and I assume that's why the memset() is failing. I
tried to add in a bus_space_map() for it but I keep getting a panic
for <WRITE,SZERR>  at the memset() so I assume I'm doing something
wrong.

Also I found this code which looks very wrong to me.

in pfourreg.h
#define PFOUR_COLOR_OFF_OVERLAY 0x00100000
...
#define PFOUR_COLOR_OFF_END 0x00700000


in cgfour.c
ramsize = PFOUR_COLOR_OFF_END - PFOUR_COLOR_OFF_OVERLAY;
...
fb->fb_type.fb_size = ramsize;

This comes out to 0x600000 or 6MB but the board only has 1MB. Am I
misunderstanding this?