From owner-freebsd-ppc@freebsd.org Tue Sep 13 17:32:18 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 A6A66BD91AC for ; Tue, 13 Sep 2016 17:32:18 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-183.reflexion.net [208.70.211.183]) (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 66813A1B for ; Tue, 13 Sep 2016 17:32:17 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 32208 invoked from network); 13 Sep 2016 17:32:07 -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:32:07 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.00.0) with SMTP; Tue, 13 Sep 2016 13:32:21 -0400 (EDT) Received: (qmail 1495 invoked from network); 13 Sep 2016 17:32:21 -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:32:21 -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 98404EC9026; Tue, 13 Sep 2016 10:32:15 -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: Date: Tue, 13 Sep 2016 10:32:14 -0700 Cc: FreeBSD PowerPC ML 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:32:18 -0000 A quick top post of a clarification: The "simple edit" was to the = official source for for whatever FreeBSD variant Jukka was using (not to = Nathan's patched source): none of Nathan's patch involved for the simple = edit result. The result does not have the #if __powerpc64__ sort of logic that would = be needed in official source but just serves as a test of the = alternative. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Sep-13, at 10:22 AM, Mark Millard = wrote: >=20 > On 2016-Sep-13, at 1:45 AM, Mark Millard = wrote: >=20 >> 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 >=20 > I had forgotten to say to deal with the Making the notation use %0, = %1, %2, %3 instead of %0, %2, %3, %4. >=20 > So we had an E-mail exchange about him manually applying a simple edit = to get my patch and he reports in the end. . . >=20 >> 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 >=20 > I have updated = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205458 with this = information. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20