[Bug 205458] 11.0-CURRENT/10-STABLE powerpc64: a PowerMac G5 specific sys/powerpc/ofw/ofw_machdep.c change for reliable PowerMac G5 booting (with lots of RAM)

[Mark Millard]

Jukka A. Ukkonen jau789 at gmail.com  wrote on Tue Sep 13 08:03:38 UTC 2016 :

> On 09/13/16 09:31, bugzilla-noreply at freebsd.org wrote:
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205458
> > 
> > --- Comment #5 from Mark Millard <markmi at dsl-only.net> ---
> > Nathan Whitehorn has put out a kernel patch that he is asking for help with
> > testing on PowerMac/iMac G5 variations. See:
> > 
> > https://lists.freebsd.org/pipermail/freebsd-ppc/2016-September/008413.html
> > 
> > The patch is not just using __powerpc64__ instead of POWERMAC_G5_SPECIFIC_BUILD
> > in my presentation of my hack.
> > 
> > Nathan has already tested a PowerMac11,2.
> > 
> > If anyone reading this has any other type(s) of Apple G5's and is willing/able
> > it would be good to get in some testing before the change is made to the
> > kernel.
> > 
> > I expect that it does not mater much which version/variation of 10.x, 11.0, or
> > 12 is used if the original boot problems can sometimes be observed before the
> > change. Although I'm not sure of the patch automatically applies nicely to all
> > possible vintages of those.
> > 
> > 
> > As for me. . .
> > 
> > It will be a few weeks before I'll again have access in order to test a
> > PowerMac7,2 (or to independently repeat PowerMac11,2 testing). I'll not have
> > access to other Apple G5's. So my range of testing will be rather limited and
> > will not be soon.
> > 
> 
> I just tried the patch on a PowerMac G5 early 2005
> model ...
> 
> cpu0: IBM PowerPC 970 revision 2.2, 2000.19 MHz
> cpu0: Features dc000000<PPC32,PPC64,ALTIVEC,FPU,MMU>
> cpu0: HID0 511081<NAP,DPM,NHR,TBEN,ENATTN>
> 
> which I think is a PowerMac7,3. It still panics right
> after it has reported VT(ofwfb).
> 
> --jau

[Be warned that it has been since early June since I've done any on-powerpc activity. My memory need not be correct or complete enough and I do not have the context to cross-check myself at this time.]

I build world and kernel from source and build the kernel to have sc and vt present (and PS3 disabled in order to allow that) but I only use sc for the larger display that I sometimes use (2560x1440 as I remember).

[Note: I've only used console mode for a long time. I've no clue if X11 is even still possible via the ports. Although that also might get into which video card is present. Someday I'll probably try that again.]

If I remember right this sc-only use is because things did not work well for vt with that large of display (last that I tried). But I do not remember just where/how it stopped/failed. (I could be confusing an older memory with more modern behavior to some extent.) At one time there was an unchecked memory buffer overrun for console use for such large screens, at least in some 10.x variant for at least one of vt vs. sc.

That background information means that "after it has reported VT(ofwfb)" leads me to wonder if a vt/screen-size related issue might be involved.


Another testing option (other than screen size variations) would be to try my hack instead of Nathan's code. (I expect the same result. But if not then that result would be interesting.) That change from original/offcial source would be the deletion of

     "mtsprg0 %1\n\t"
and
     "r"(ofmsr[1]),

from:

> 	__asm __volatile("mfsprg0 %0\n\t"
> 			 "mtsprg0 %1\n\t"
> 			 "mtsprg1 %2\n\t"
> 			 "mtsprg2 %3\n\t"
> 			 "mtsprg3 %4\n\t"
> 			 : "=&r"(ofw_sprg0_save)
> 			 : "r"(ofmsr[1]),
> 			 "r"(ofmsr[2]),
> 			 "r"(ofmsr[3]),
> 			 "r"(ofmsr[4]));

in sys/powerpc/ofw/ofw_machdep.c .



===
Mark Millard
markmi at dsl-only.net