From owner-freebsd-ppc@freebsd.org Tue Sep 13 17:23:01 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0CED0BD9E1C for ; Tue, 13 Sep 2016 17:23:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-177.reflexion.net [208.70.211.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C1D111AE for ; Tue, 13 Sep 2016 17:23:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26687 invoked from network); 13 Sep 2016 17:23:42 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 13 Sep 2016 17:23:42 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.00.0) with SMTP; Tue, 13 Sep 2016 13:22:57 -0400 (EDT) Received: (qmail 31560 invoked from network); 13 Sep 2016 17:22:57 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Sep 2016 17:22:57 -0000 Received: from [192.168.0.104] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 307EEEC9020; Tue, 13 Sep 2016 10:22:52 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) 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) From: Mark Millard In-Reply-To: <8A406E69-0C88-47B9-97BB-9E07561A8139@dsl-only.net> Date: Tue, 13 Sep 2016 10:22:51 -0700 Cc: FreeBSD PowerPC ML , jau789@gamil.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <8A406E69-0C88-47B9-97BB-9E07561A8139@dsl-only.net> To: Nathan Whitehorn X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 17:23:01 -0000 On 2016-Sep-13, at 1:45 AM, Mark Millard wrote: > Jukka A. Ukkonen jau789 at gmail.com wrote on Tue Sep 13 08:03:38 UTC = 2016 : >=20 >> 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 --- >>> 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 >> cpu0: HID0 511081 >>=20 >> which I think is a PowerMac7,3. It still panics right >> after it has reported VT(ofwfb). >>=20 >> --jau >=20 > [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.] >=20 > 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). >=20 > [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.] >=20 > 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. >=20 > 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. >=20 >=20 > 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 >=20 > "mtsprg0 %1\n\t" > and > "r"(ofmsr[1]), >=20 > from: >=20 >> __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])); >=20 > in sys/powerpc/ofw/ofw_machdep.c . >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net I had forgotten to say to deal with the Making the notation use %0, %1, = %2, %3 instead of %0, %2, %3, %4. So we had an E-mail exchange about him manually applying a simple edit = to get my patch and he reports in the end. . . > I rebooted the box only a few minutes ago, and this > time it booted just fine. > Well, the tmpfs has started failing as follows... >=20 > # mount /tmp > mount: tmpfs: Operation not supported by device >=20 > but supposedly this is an unrelated issue. At least I hope so. ;-) >=20 > Now the function reads as shown below, and I guess this is > exactly what you had in mind. >=20 > static __inline void > ofw_sprg_prepare(void) > { > if (ofw_real_mode) > return; >=20 > /* > * Assume that interrupt are disabled at this point, or > * SPRG1-3 could be trashed > */ > __asm __volatile("mfsprg0 %0\n\t" > "mtsprg1 %1\n\t" > "mtsprg2 %2\n\t" > "mtsprg3 %3\n\t" > : "=3D&r"(ofw_sprg0_save) > : > "r"(ofmsr[2]), > "r"(ofmsr[3]), > "r"(ofmsr[4])); > } >=20 > So, from my point of view the PowerMac7,3 seems to be back to > relative health with this change. I hope it works for all the > other G5s as well. >=20 > --jau I have updated https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205458 = with this information. =3D=3D=3D Mark Millard markmi at dsl-only.net