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