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

[Julian Coleman <jdc%coris.org.uk@localhost>]

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.

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.

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

--