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

[Julian Coleman <jdc%coris.org.uk@localhost>]

Hi,

[had a chance to look at this again]

> > 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.

Agreed.  Let's just use:

#define PFOUR_COLOR_OFF_CMAP	0x00100000
 
> > > 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.

I looked at cgthree for a reference, and there fb_pixels is mapped in
the front end attach (cgthree_sbus.c [1]).  I see that the old mmap is
#if 0 so not used, with the comment "We don't do any of the console
handling here."  I'm not 100% sure why the BW2 isn't console, but for
CG4 as console, can you remove the #if 0 around line 328 [2] and replace
the mapiodev() call with:

	if (fb->fb_pixels = bus_space_map(oba->oba_bustag,
	    (paddr_t)oba->oba_paddr + PFOUR_COLOR_OFF_COLOR,
	    ramsize,
	    BUS_SPACE_MAP_LINEAR, &bh) != 0) {
		aprint_error_dev(self, "cannot map pixels\n");
		return;
	    }
	fb->fb_pixels = (char *)bh;

PFOUR_COLOR_OFF_COLOR should be the correct offset.  I based the above
on the code just below where we "Map the Brooktree".

> 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?

I'm assuming that PFOUR_COLOR_OFF_END is the maximum address for any of
the P4 colour framebuffers.  However, as you point out, this doesn't make
sense for a CG4.  Also based on the CG3 code [3], I think that we need to
calculate width/height from the EEPROM values with fb_setsize_pfour() [4],
or maybe just start with hardcoding 1152 x 900 x 8 to see if we have the
rest of the code correct.

Looking at the mmap routines (cgfourmmap and cgfour_mmap) I*m not sure if
we have the mapping correct for the framebuffer, overlap and enable planes
and also this looks strange in cgfour_mmap:

	if (offset >= 0 && offset >= sc->sc_fb.fb_type.fb_size) {

I'm guessing that the second should be <= .  However, we don't need these
to get the text console working, so something for later.

Regards,

Julian

[1] https://nxr.netbsd.org/xref/src/sys/dev/sbus/cgthree_sbus.c#174
[2] https://nxr.netbsd.org/xref/src/sys/arch/sparc/dev/cgfour.c#266
[3] https://nxr.netbsd.org/xref/src/sys/dev/sbus/cgthree_sbus.c#152
[4] https://nxr.netbsd.org/xref/src/sys/dev/sun/pfour_subr.c#fb_setsize_pfour