🚀 go-pugleaf

Well, I have finally managed to get my 3/60 to work again with the cg8 I
installed recently. I had quite a few problems, most of which I have
solved, some of which I haven't.

There were two major problems I encountered.

The first was that with the new frame buffer installed, it was causing the
+5 volt rail of the power supply to fold back to around 4.6 volts because
of the much larger current drawn by the cg8 (it *does* have to run three
pallette DAC's instead of just one!) compared to the cg6.

Here's the story for this particular problem....

This initially had me very stumped because I kept looking at the status
LED's (which were always freezing in the all-on state after a few seconds
of rapid action which indicated that the POST was running but the system
was hanging) and thought there was a problem with the hardware other than
the power supply. I did all sorts of wierd and wonderful things before one
day last week I decided to just leave the machine alone for a while and
see if anything happened after half an hour or so. I also flipped the diag
switch and cycled the power again before leaving the machine alone.

When I came back around 30 minutes later I noticed a very unusual thing
happening - from watching the status LED's, I could see that the machine
was trying to boot up into the ROM monitor, and failing every time. Upon
seeing this I remembered what happened once when I connected a tape drive
with a QIC to SCSI interface card up to a small switchmode power supply
that was slightly under-rated for running the tape drive. It tried to
start up, the power supply folded back, the interface card tried to start
up, etc.. ad infinitum until the power supply blew up!

So, I carefully measured the voltage of the +5 volt rail and found it way
below the spec, which is 5 +- 0.25 volts. Fortunately I had a large
capacity switchmode lying around so I made up a fancy cable and hooked it
up. Now I get around 4.87 volts on the +5 volt rail, which is better, but
not great. The machine now came up in the ROM monitor, except.....

when it's cold. If I power the machine up after being turned off for more
than 15 minutes or so it cannot always finish the POST and fails at the
point where the ROM monitor code starts to execute. Leaving the machine
on for 30 minutes or so cures this. I tentatively noticed this problem
initially but didn't think anything of it. Anyway, suffice to say that
since my machines run all the time once stable this won't be a huge problem.

So now I get the ROM monitor running happily once the machine is warmed
up (sounds like it runs off valves!), but then the next problem cropped
up....

Trying to start SunOS was continually failing. It would get to the point
of display the device and filesystem type of the root and swap
partitions, pass control over to the now-loaded and initialised kernel
code, and stop. Not dead though, since the status LED's would cycle very
slowly as though the kernel was under heavy load, but it wasn't.

I tried booting from the boot tapes, and the same thing happened all the
time. I found this to be very strange behaviour, since it suggests that
something which should be happening isn't and the reason for it must have
something to do with the only hardware change I've made which is to put in
a different type of frame buffer.

Fortunately I have a SunOS 4.0.1 manual set, which while not be really
appropriate for SunOS 4.1.1, is more than adequate since most of the stuff
is still correct for the later SunOS release. The most useful gem I have
found in this manual set is the PROM manual, which gives all the info
anyone would ever want to know about the PROM monitor and, importantly for
this exercise (more in a moment...), the EEPROM and what it's contents are
used for.

If ever I have a problem getting SunOS to start, I look first at the
EEPROM manual, since 9 times out of 10 the problems stem from something in
the EEPROM which isn't set correctly for what I want the machine to do. So
off I went, looking through the EEPROM manual, and the only reference I
could find that had anything to do with frame buffers was location 0x1F.
The value of this location determines what is used as the default console
device, and it lists the following possible values:


0x00 - use b&w monitor (mono on-board frame buffer)
0x10 - use serial port A
0x11 - use serial port B
0x12 - used colour monitor (cg2, cg3, cg5, or color daughter board)
0x20 - use single of first multiheaded P4 board


I'd always had this location set to 0x12 before since I've only ever used
8 bit framebuffers. Obviously there was the possibility that because of
this setting, for some reason when control was passed to the kernel it
could not locate the default display device (my cg8) and therefore just
sat in a tight loop, chewing up CPU time trying to get the mythical frame
buffer to respond.

The wording for the last possible valid setting made me think that there
might be some correlation to the use of the term 'multiheaded' with the
fact that a cg8 has three pallette DAC's, not one as found on 8-bit color
boards. So, I changed the contents of EEPROM location 0x1F to 0x20 and
cycled the power with fingers crossed...

Voila! Bon Apetite! Up came SunOS as though the machine had never been
shutdown. Control was passed to the kernel and it went off checking the
filesystems as it should have which told me that whatever had tripped up
the kernel before the part that starts off the rc files in /etc was now
not tripping up. For some reason the setting of that particular EEPROM
location affected how the kernel behaved with the cg8 installed.

Please note that apart from the mention of this in the EEPROM manual,
nothing else seems to recognise a setting of 0x20 in that location of the
EEPROM. If I type 'eeprom' at a shell prompt it will report the console
device as being set up for 'b&w', which is clearly not right, but that
only suggests that the 'eeprom' command doesn't know about the last
possible value for that location. The kernel works fine now using the cg8
as it should regardless of what the 'eeprom' command thinks.


After all of this, only one problem now remains - getting X11R6 to work
with the cg8. I have the 24 bit Xserver built and installed with the
Xservers file in /usr/X11R6/lib/X11/xdm set up to use this as the default
Xserver for the console, but the following appears in the xdm-errors file
when xdm tries to start up the Xserver at boot time:

xdm error (pid 160): IO Error in XOpenDisplay
xdm error (pid 146): Display :0 cannot be opened
xdm error (pid 163): IO Error in XOpenDisplay
xdm error (pid 146): Display :0 cannot be opened
xdm error (pid 168): IO Error in XOpenDisplay
xdm error (pid 146): Display :0 cannot be opened
xdm error (pid 146): Display :0 is being disabled

Does anyone have any suggestions as to what might be causing this to
occur? Is the fact that the 'eeprom' command reports the default display
device to be 'b&w' even though the location is set to 0x20 a true
indication that something is not quite as right as it should be?

I'd appreciate some pointers on how to solve this problem with getting X
to start up using the cg8.


Anyway, that's enough from me for today. Actually, could other people that
have cg8's installed in their 3/60's let me know what sorts of problems
they with them? If would be interesting to see if any of the problems I've
had correlate with other people's experiences.

Regards,

Craig.
--
 Craig Dewick (craig@orb.apana.org.au) - Passenger train driver, Sydney, Aust.
  Support *independent* media <--> Support your local community radio station
 Swimming in the MUSIQUARIUM of life <--> Monday 2 - 4pm, 2SER FM (107.3 MHz).
 Always striving for a secure long-term future in an insecure short-term world