Date: Sun, 18 Sep 2016 05:39:36 -0700 From: Mark Millard <markmi@dsl-only.net> To: "Jukka A. Ukkonen" <jau789@gmail.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: <A0EEC60D-03B7-44E3-8EB2-73720C1294EA@dsl-only.net> In-Reply-To: <20095902-e09a-1a02-c2d1-b402a7eec79d@gmail.com> References: <0F078304-8E8F-4EB1-B721-B6C4B885F118@dsl-only.net> <20095902-e09a-1a02-c2d1-b402a7eec79d@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2016-Sep-18, at 4:46 AM, Jukka A. Ukkonen <jau789 at gmail.com> =
wrote:
> On 09/17/16 00:41, Mark Millard wrote:
>> Jukka A. Ukkonen jau789 at gmail.com wrote on Fri Sep 16 15:36:05 UTC =
2016 :
>>=20
>>> it seems my PowerMac G5 is perfectly happy with this...
>>>=20
>>> __asm __volatile("mfsprg0 %0\n\t"
>>> : "=3D&r"(ofw_sprg0_save)
>>> :
>>> );
>>=20
>> for the content in ofw_sprg_prepare(void).
>>=20
>> Interestingly ofw_sprg0_save's use to save and restore requires that =
the same processor be in use in the restore side, =
ofw_sprg_restore(void): SPRG0 content is processor specific.
>>=20
>> If the sprg0 save-restore is even required is not obvious to me: =
being required would imply that that something else is adjusting it =
between the save and restore code executions.
>>=20
>> The following is just in the form of another simplest-local-changes =
experiment/analysis pass, not a "how it should be coded for general =
FreeBSD use" form for __powerpc64__ or at least for for =
PowerMac/iMac/Xserve G5's specifically. . .
>>=20
>> Given what is reported above by Jukka it would appear that the above =
__asm lines possibly could be removed/disabled if ofw_sprg_restore(void) =
also had its __asm line removed/disabled: i.e.,
>>=20
>> __asm __volatile("mtsprg0 %0" :: "r"(ofw_sprg0_save));
>>=20
>> would no log be in use to access ofw_sprg0_save.
>>=20
>> Effectively overall for the intended __powerpc64__ =
PowerMac(/iMac?/Xserver?) experimental context ofw_sprg_prepare and =
ofw_sprg_restore are then no-ops.
>>=20
>> In effect ofw_sprg0_save and ofmsr[1] to ofmsr[4] would not be in =
significant use. But. . .
>>=20
>> OF_initial_setup(void *fdt_ptr, void *junk, int (*openfirm)(void *))
>>=20
>> still would have __asm references to ofmsr[1] through ofmsr[4] where =
they are initialized.
>>=20
>>=20
>> You might want to try deleting/disabling the __asm statements in =
ofw_sprg_prepare(void) and in ofw_sprg_restore(void) at the same time to =
see if it makes any difference. If it does make a difference that would =
be interesting and important. Otherwise it helps identify some more =
(PowerMac/. . . context specific) unnecessary code.
>=20
>=20
> You asked it and I tested it. I must admit, though, that
> I had a kind of an Arthur Dent moment during the test.
> Remember the red button on the wall with the sign on
> the side telling: "Do not press this button!", and
> then Arthur being himself happily presses the button
> anyway just to see the warning sign to be illuminated.
> I was not quite so lucky.
> It seems touching the current sprg0 treatment is a
> guaranteed method to panic the system right at the
> beginning of autoconfigure.
>=20
> --jau
Thanks for doing the experiment. In my view the result was interesting =
and good to know for sure.
The results suggest that Apple's Open Firmware changes sprg0 --at least =
sometimes-- so, then, after the Open Firmware call FreeBSD needs to =
re-establish its own sprg0 value from before the Open Firmware call.
An implication would be that it is possibly a matter of luck that the =
FreeBSD SLB fault handler is sometimes (only?) invoked while the FreeBSD =
sprg0 value is still in place when variations on my hack are in place. =
If it is only sometimes instead of always that the SLB handler has the =
FreeBSD sprg0 value to use, then register and memory trashing likely =
would still be possible, just less frequent (fewer types of contexts).
So it seems that the use of the mode:
usefdt=3D1
(currently "from the loader prompt") in order to avoid any calls into =
Open Firmware may be required to get full reliability. (See below.)
After checking in https://svnweb.freebsd.org/changeset/base/302214 back =
on 2016-Jun-26 Nathan had written:
> One thing it would be great to have some testing on after this change =
is=20
> the FDT layer in loader. If you set usefdt=3D1 from the loader prompt,=20=
> loader will distill the OF device tree into an FDT and then stop Open=20=
> Firmware completely before transferring control to FreeBSD. This =
should=20
> avoid any possible problems accessing Open Firmware from the kernel, =
as=20
> well as making boot a little faster.
But I'd already temporarily lost access to the PowerMacs before he sent =
that note.
I intend to experiment with this once I have access again. (But I can =
not beat 11.0-RELEASE's schedule.) You have already suffered enough.
Your results suggest that I do such testing with the configuration that =
failed above.
Normally I'd only have subjected myself to the sprg0 testing activity =
that I asked you for --but I do not have access to the PowerMac G5s yet. =
Hopefully your information is useful to Nathan. But it may be too late =
for 11.0-RELEASE to get a matching patch from Nathan up front.
Sorry the testing lead to needing to recover from the bad build.
=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?A0EEC60D-03B7-44E3-8EB2-73720C1294EA>