Date: Wed, 21 Sep 2016 14:08:46 -0700 From: Mark Millard <markmi@dsl-only.net> To: "Jukka A. Ukkonen" <jau789@gmail.com> Cc: freebsd-ppc@freebsd.org, chmeeedalf@gmail.com Subject: Re: svn commit: r306065 - in head/sys vs. PowerMacs: Nathan's trail patch included but inappropriate? Message-ID: <465041D5-C1A2-48F4-9CA7-DD03B094FAE4@dsl-only.net> In-Reply-To: <4bb1046a-225d-66b2-7b00-067f0d6f6c60@gmail.com> References: <C48933C3-DB22-4D94-B22D-B51822197E4E@dsl-only.net> <917EFF5A-D054-4424-9D7D-4E4BEF6072EF@gmail.com> <4bb1046a-225d-66b2-7b00-067f0d6f6c60@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2016-Sep-21, at 11:15 AM, Jukka A. Ukkonen <jau789 at gmail.com> = wrote: > On 09/21/16 20:28, Justin Hibbits wrote: >> On Sep 21, 2016, at 1:46 AM, Mark Millard wrote: >>=20 >>> The following from >>>=20 >>> = https://lists.freebsd.org/pipermail/svn-src-head/2016-September/091934.htm= l >>>=20 >>>=20 >>> seems in include a patch that Nathan made for testing on >>> PowerMac/iMac/Xserve G5's that failed the PowerMac7,3 test that was >>> tried by Jukka A. Ukkonen. >>>=20 >>> . . . >>=20 >> Crap, I got extra stuff in my diff. Going to revert this part = tonight, >> until everything is known good. >>=20 >> - Justin >> _______________________________________________ >> freebsd-ppc@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-ppc >> To unsubscribe, send any mail to = "freebsd-ppc-unsubscribe@freebsd.org" >=20 >=20 > The least that will have to be changed to make the code boot on > PowerMac G5 is to change the following ... >=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 function ofw_sprg_prepare() in sys/powerpc/ofw/ofw_machdep.c > to this ... >=20 > __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 > This only removes "mtsprg0" and its corresponding parameter. >=20 > Alternatively one could use the absolutely minimalistic ... >=20 > __asm __volatile("mfsprg0 %0\n\t" > : "=3D&r"(ofw_sprg0_save) > : > ); >=20 > on a G5. I have been running exactly this since my testing sessions > with no ill effects at all. The downside is that nobody has tested > this minimalistic approach on any other ppc variant but my G5. > I have had a pending plan to test the same approach on my 32-bit G4, > but the task being somewhat time consuming it is still pending. ;-) >=20 > Anyhow the old code will not boot on a G5 without a change, neither > will it boot with Nathan's patch included. Releasing 11.0-stable in > a state that will not actually boot on one of the supported platforms > will not look awfully bright either. I guess this is an issue for > the re team to decide. >=20 > --jau Nathan Whitehorn at one point wrote: > I believe that OF's SPRG0 is maintained only for compatibility with = some G4 > Apple hardware, the eMac in particular, but will check . . . I've never had my hands on an eMac. I'm not sure if it has the same = SPRGx requirements as other G4's or not. Your testing has shown that the PowerMac7,3 G5 you have has some SPRG0 = value save/restore activity that is required: the activity associated = with ofw_sprg0_save but not the other SPRG0 activity. My prior G5 = activity and your recent testing both showed that the "other" SPRG0 = activity associated with ofmsr[1] actually causes observable problems = for at least a range of PowerMac G5 contexts. Your testing also showed = that the PowerMac7,3 G5 did not require SPRG1, SPRG2, or SPRG3 to be = saved and restored. My powerpc/powerpc64 examples have only been: PowerMac11,3 G5 ["Quad Core": 2 dual-core processors] (2 of these) PowerMac7,2 G5 [dual-processor, each single core] PowerMac3,6 G4 FW800 [dual-processor, each single core) (2 of = these) PowerMac3,5 G4 Dual Drive Door [dual-processor, each single core] PowerMac3,4 G4 [single-processor, single core] (multiple speeds) PowerMac4,1 iMac G3 [single-processor, single core] I only put my mtsprg0 removal hack (so: leaving the FreeBSD SPRG0 value = in place) in my G5 builds. I've never tested any G4's or the G3 with = such changes that I remember: I left the working context alone. No = amount of testing by me would cover contexts I never had access to. I've never had access to a non-Apple example of a powerpc/powerpc64 = context or Open Firmware context. So I have no evidence of what that = brings to the compatibility issues for the powerpc or powerpc64 Open = Firmware related code in the FreeBSD kernel versions. I'm not sure of the current status but for a long time the G4-capable = FreeBSD builds also worked in the G5's (but ignored "extra" memory). No = hack/change needed. FreeBSD stopped booting the iMac G3 a long time ago (2015-Mar or before, = at least for 11.0). Last I tried and recorded the result it got: > [Thread pid 0 tid 100037] > Stopped at pmap_activate+0x7c lwz r11,r1,0x0 Later attempts were similar as I remember. But I've never tried hard to = track down why it was failing or what changed that made the difference. One PowerMac3,4 G4 FreeBSD has never managed to boot for any FreeBSD = version that I tried. It was a 733 MHz model. (Mac OS X 10.4 and lubuntu = 14.04 had no such problem in the same system --and they operate fine = after booting as well.) But I've never tried hard to track down why or = where it was failing. So that is the scope of my relevant testing. [I have various experiments to do with the above systems once I have = access again.] =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?465041D5-C1A2-48F4-9CA7-DD03B094FAE4>