From owner-freebsd-ppc@freebsd.org Tue Sep 13 08:45:31 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 127CFBD62B8 for ; Tue, 13 Sep 2016 08:45:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-178.reflexion.net [208.70.211.178]) (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 A9B93E4D for ; Tue, 13 Sep 2016 08:45:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17255 invoked from network); 13 Sep 2016 08:46:17 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 13 Sep 2016 08:46:17 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.00.0) with SMTP; Tue, 13 Sep 2016 04:45:33 -0400 (EDT) Received: (qmail 12709 invoked from network); 13 Sep 2016 08:45:33 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Sep 2016 08:45:33 -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 652A7EC8073; Tue, 13 Sep 2016 01:45:27 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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) Date: Tue, 13 Sep 2016 01:45:26 -0700 Message-Id: <8A406E69-0C88-47B9-97BB-9E07561A8139@dsl-only.net> Cc: FreeBSD PowerPC ML , Nathan Whitehorn To: jau789@gamil.com Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) 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 08:45:31 -0000 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 --- > > 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 [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