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

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

On Sat, Feb 15, 2025 at 6:52 AM Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost> 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);