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

foo bar <[email protected]>
Newsgroups gmane.os.netbsd.ports.sparc
Message-ID <CAOddDr6D1UrMxAZV3VM28ejNhj6FcmbtHODjpRJpk0tZtkvunw@mail.gmail.com>
On Tue, Mar 4, 2025 at 8:00 AM Julian Coleman <[email protected]> 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?
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.