Date: Tue, 13 Sep 2016 01:45:26 -0700 From: Mark Millard <markmi@dsl-only.net> To: jau789@gamil.com Cc: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, Nathan Whitehorn <nwhitehorn@freebsd.org> Subject: Re: [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) Message-ID: <8A406E69-0C88-47B9-97BB-9E07561A8139@dsl-only.net>
next in thread | raw e-mail | index | archive | help
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=3D205458 > >=20 > > --- 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: > >=20 > > = https://lists.freebsd.org/pipermail/freebsd-ppc/2016-September/008413.html= > >=20 > > The patch is not just using __powerpc64__ instead of = POWERMAC_G5_SPECIFIC_BUILD > > in my presentation of my hack. > >=20 > > Nathan has already tested a PowerMac11,2. > >=20 > > 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. > >=20 > > 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. > >=20 > >=20 > > As for me. . . > >=20 > > 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. > >=20 >=20 > I just tried the patch on a PowerMac G5 early 2005 > model ... >=20 > 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> >=20 > which I think is a PowerMac7,3. It still panics right > after it has reported VT(ofwfb). >=20 > --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" > : "=3D&r"(ofw_sprg0_save) > : "r"(ofmsr[1]), > "r"(ofmsr[2]), > "r"(ofmsr[3]), > "r"(ofmsr[4])); in sys/powerpc/ofw/ofw_machdep.c . =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8A406E69-0C88-47B9-97BB-9E07561A8139>