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

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

On Sun, Apr 6, 2025 at 8:30 AM Julian Coleman <jdc%coris.org.uk@localhost> wrote:
>
> Hi,
>
> > > I looked at cgthree for a reference,
>
> although looking at the cgsix code would probably be better, as that also
> has the P4 attachment.
>
> > I think I understand the intent of the code now. The board actually
> > has 1.25MB of RAM, 128KB for the mono plane, 128KB for the enable
> > plane, and 1MB for the color plane. In order to work we need all the
> > planes so setting the size based on the resolution won't be enough. I
> > believe the code was trying to use the offsets to get all of the
> > memory, however the offsets are aligned to 1MB so there's large gaps
> > of empty space and that's where the 6MB came from. Since there's only
> > one type of cgfour that works on sparc with known memory sizes it may
> > be better to just hard code these values in.
>
> Agreed.  It is easier to do that.  A reason to check the resolution,
> however, is so that we can calculate the line lengths and number of
> lines, which we'll use for the console display.  When we get to running
> X, this will also be needed too.  Also, if the memory needed by the screen
> is less that the available memory, we can cache, for example, glyphs in
> the offscreen memory, so we should have both (not that there will be much,
> but it will give a small speedup).
>
> > Also in the bwtwo driver I found it used a for loop to limit memset()
> > to 4 bytes at a time to prevent write errors, copying that fixed my
> > panic on memset(). However it still hangs at wsdisplay_cnattach(). I
> > don't know if it's not being set up properly or if it's fighting the
> > bwtwo driver over who gets to be console. Attaching a work in progress
> > patch. It doesn't handle the overlay and enable planes yet. In the
> > sun3 driver it handles them separately instead of lumping them all
> > together like the sparc driver does. Not sure which is better.
>
> Interesting - good to find!  (I'm guessing that something in the older
> hardware can only handle 32bits at a time.)
>
> I'm not sure if we've tried having 2 devices claim to be the console,
> so it's possible that trying to have 2 console devices breaks some
> internal assumption.  One easy way to check would be to run a kernel
> with only bw2 compiled in to check that it boots OK, then with only cg4
> to check that it gets further.

Sorry for the delay but I've finally added some code to handle the
enable plane and tested this. When booting the framebuffer definitely
switches to the 8 bit plane as the kernel starts printing green text.
However wsdisplay claims the cgfour is not configured and a few
seconds later the kernel panics because of no console. I uploaded a
video of it in case anyone wants to see a few seconds of pretty
colors.

https://www.youtube.com/watch?v=3r_zqhH8Ehk

I've tested several different versions of generic kernels which only
have the bwtwo driver and they all successfully boot to the login
prompt but the keyboard doesn't work. The keyboard not working goes
all the way back to at least netbsd 6 so I think it's a different
problem.

> In the past, we always deferred the console handling to bw2, so we'll
> need to make sure that we have all the setup correct for cg4, rather
> than, for example, bw2 for the console and the X driver handling the
> cg4 planes for graphics.  Hunting around for how to configure the 3
> planes, I see a reference:
>
>   http://www.bitsavers.org/pdf/sun/sunos/4.1/800-3802-10A_SunOS_4.1_Release_Manual_199003.pdf
>
> where table 9-1 on page 86 notes the correct settings for the enable
> plane.  I think that we need to make sure that we either:
>
>   - set the enable plane to 1 everywhere and pass the overlay plane
>     parameters to wsdisplay_cnattach(), i.e. 1 bit colour with
>     cgfour_defaultscreen and ri referencing the overlay memory, or
>
>   - set the enable plane to 0 everywhere and pass the colour plane
>     parameters to wsdisplay_cnattach(), i.e. 8 bit colour with
>     cgfour_defaultscreen and ri referencing the colour memory
>
> If we don't set either of these explicitly, it could be that we're writing
> to one but displaying the other, which would result in nothing changing on
> the screen even though the kernel is running.  Of course, the former would
> duplicate what the bwtwo driver is doing, and is noted as faster for text
> output, hence why we went for that in the original code.  I would think
> that the power-on setting would have the enable plane set to 0 everywhere,
> but it's possible (likely?) that the PROM console output uses the overlay
> plane, so that the enable plane has been set to 1 by the firmware.

The PROM does set the enable plane to 1 and uses the overlay plane for
output. I had to add a memset() for the enable plane so I could see
the output on the color plane.

> After this, we'll need to get X running.  I see from xsrc/external/mit/
> that we don't have the xf86-video-suncg4 driver.  I wonder if it makes
> sense to update an old version of that, or to use wsfb because cg4 is
> basically unaccelerated colour.  Again, we would need to make sure that
> we have the enable plane and the mmaped regions matching up for that
> to work correctly.
>
> Regards,
>
> Julian
>
> --