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?