Re: Panic at boot on 4/330 with cgfour and cgsix
foo bar <[email protected]>
| Newsgroups | gmane.os.netbsd.ports.sparc |
|---|---|
| Message-ID | <CAOddDr4-+QrpJiKpk6AUNsPK_YQ2Qh=EOu2oGhtf=62jE34ivQ@mail.gmail.com> |
On Sat, Feb 15, 2025 at 6:52 AM Izumi Tsutsui <[email protected]> wrote: > > tokenalt@ wrote: > > > So bad news. After getting the video to work I have found the keyboard > > doesn't work. At least not for the console, it does work for the > > kernel debugger however each character is echoed twice. You can > > actually see that in the video I linked in my first email. I tested > > the 10.0 kernel which only has the bwtwo driver and the keyboard > > doesn't work on it either. I will try older kernels later but in the > > meantime here is a dmesg with a working cgfour and not working > > keyboard. > > The problem is currently there is no MI wsdisplay(9) support > for cgfour(4), as commented in sparc/conf/GENERIC. > > IIRC the Sun PROM uses the overlay bwtwo plane for putchar on console > even if cgfour is selected as a console (at least seen on my sun3x). > > On NetBSD, currently bwtwo(4) has wsdisplay support but cgfour(4) > doesn't, so console settings are not handled properly, as seen > in your dmesg that only "wsdisplay1 at bwtwo" is attached. > > AFAIK cgfour(4) is a simple 8 bpp dumb framebuffer, so it should > be trivial to add wsdisplay(9) support with MI rasops(9). > > How about the following changes, mostly just taken from cgthree(4)? > [patch] 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. 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);