Re: G5 powermacs

[Michael <macallan%netbsd.org@localhost>]

Hello,

On Sat, 10 Jun 2017 14:27:50 +0200 (CEST)
Havard Eidnes <he%NetBSD.org@localhost> wrote:

> >> > I see the "OF_Quiesce finished" printout and the first few lines
> >> > of the kernel messages, but once it has printed the line which
> >> > starts with "genfb0", the screen blanks for me and (apparently)
> >> > never unblanks.  I should perhaps note that the G5 I use has
> >> > nvidia graphics.  Hmm, what happens if I comment out "genfb" from
> >> > the kernel config? (It'll probably bomb later when it finds it
> >> > has no wsdisplay?)    
> >>
> >> "Not exactly."  What did happen was however that after the
> >> "OF_QUIESCE finished" message was that no output was printed on
> >> the screen.
> >>
> >> So ... what's the magic to make this machine not turn off video
> >> after genfb0 is probed?  
> >
> > Huh, this is weird genfb can't really turn off the video, it's got no
> > knowledge of the hardware beyond scribbling into the framebuffer.
> > So:
> > - did it actually turn the screen off or just draw everything in black?  
> 
> Well, it printed some 20-30 kernel message lines using white-on-black,
> scrolling up from the bottom of the screen, scrolling the black-on-
> white OpenFirmware screen up.  I just re-tested, and the screen
> doesn't actually lose the video signal (does not enter "energy save
> mode" which it does when there's no more signal from the machine), it
> just all (including the white OpenFirmware part of the screen) very
> suddenly goes all-black.  Therefore, any printouts done after the
> "genfb0" printout is (if there is any) invisible.

Ok, so it's likely the palette bug.

> > I dimly remember a firmware bug I encountered with a geforce 2mx
> > (which ultimately prompted me to write gffb) - OpenFirmware's color!
> > method would not work properly, and only write colour registers for one
> > output, not necessarily the one you plugged your monitor in (IIRC it
> > only worked for the analog output, not the DVI one). Genfb depends on
> > firmware commands like this to access palette registers. If this
> > doesn't work it may end up with a mostly black palette.
> >
> > Some things to try:
> > - plug the monitor into the other port, see if that helps  
> 
> The video card in this machine has two outputs, both DVI.  The output
> I have not been using does in fact not output a video signal either
> while in OpenFirmware or after the other output goes all-black.  So
> that suggestion didn't work.

Did you plug something into the other port while powering up or after booting?

> > - in genfb.c, comment out the RI_8BIT_IS_RGB and RI_ENABLE_ALPHA flags.
> >   This will prompt genfb to setup a traditional 16 colour ANSI palette
> >   instead of an R3G3B2 one suitable for anti-aliased fonts. The colours
> >   may look wrong ( since we inherit whatever OF set up ), but should be
> >   readable.  
> 
> OK, I'll take a stab at that, but I think only after having tried ofb.

OFB doesn't try to setup an R3G3B2 palette, it should have the same
effect ( using an ANSI colour map )

> If the above is a fix, it does sound a little counter-intuitive when
> matched up with the described symptom.

Not really. If OF sets up the traditional 16 ANSI colours and leaves
the rest of the palette registers at black, then wsdisplay trying to
use R3G3B2 will end up as most if not all black. Black would remain
black and white ( being at 255 ) would also be black.

> >> > A few tens of seconds later, the fans in the machine appear to
> >> > spin up to full speed.  Since the screen is still blank, I have
> >> > at this point no way to interact with the system, so I had to
> >> > turn it off again with a long press on the power button.    
> >>
> >> This behaviour continued, of course.  
> >
> > That's the SMU thinking we crashed, which we may or may not have. The
> > OF_Quiesce command mentioned above is supposed to tell it that the
> > operating system is up and running, but never worked for me either. No
> > idea why.  
> 
> Mind you, the fans stayed low between the OF_Quiesce printout and only
> increased after the output on the console has gone, so I'm not sure we
> can conclude whether we've crashed or whether OF_Quiesce has made a
> difference.

The SMU ( and most PMUs ) has a timer, if it isn't told that the OS is
up <timeout> after powering up ( or attempting to boot ) it will assume
we crashed and as a safety measure cramk up the fans.

have fun
Michael