Date: Mon, 28 Jan 2019 13:42:36 -0800 From: Mark Millard <marklmi@yahoo.com> To: Curtis Hamilton <clhamilto@gmail.com> Cc: freebsd-ppc@freebsd.org Subject: Re: Booting and Installing Release 12 on PowerMac G5 "Quad Core" Message-ID: <30652AD4-E660-4888-BAA9-22082A059DB1@yahoo.com> In-Reply-To: <A64FD607-1688-4672-985F-CC41861D5B14@yahoo.com> References: <283c5d11-7363-f9e3-48cc-42bd6d036236@gmail.com> <A64FD607-1688-4672-985F-CC41861D5B14@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[ For head usefdt=3D1 does work by itself without reverting = VM_MAX_KERNEL_ADDRESS .] On 2019-Jan-27, at 21:57, Mark Millard <marklmi@yahoo.com> wrote: > On 2019-Jan-27, at 16:05, Curtis Hamilton <clhamilto at gmail.com> = wrote: >=20 >> Is there a recommended solution to booting/installing Release 12 on = the PowerMac G5 "Quad Core"? >>=20 >> I've read through all the threads in this mailing list, but have yet = to find a solution that works on my Mac. Many of the referenced = snapshot kernels could not be located. Building from source yielded the = same results as down loaded pre-built images. >>=20 >> Any tips or hits would be appreciated. >=20 > A specific change was made for powerpc64 that lead to this G5 boot = problem. > However, it appears to just have exposed some previously unknown = problem rather > than the change itself being wrong. I'm not aware of anyone having = figured > out the underlying problem --or even of having figured out a way to = figure > it out. I know I've not come up with any ideas so far. So far as I = know, only > old PowerMacs show such odd behavior with the change. >=20 > So for now I base my builds on reverting the change in question. (I = normally > use head, including 12 back when it was head.) >=20 > . . ./sys/powerpc/include/vmparam.h has a definition of = VM_MAX_KERNEL_ADDRESS . > I reverted the: >=20 > #define VM_MAX_KERNEL_ADDRESS 0xe0000007ffffffffUL >=20 > to be: >=20 > #define VM_MAX_KERNEL_ADDRESS 0xe0000001c7ffffffUL >=20 > instead. But, again, I expect that this is a way of sidestepping = another > problem that has not been found: a hack/workaround instead of a valid, > general fix. >=20 > Disabling smp via the following at the loader prompt seems to avoid > the problem without such a change to to VM_MAX_KERNEL_ADDRESS : >=20 > set kern.smp.disabled=3D1 >=20 > Nothing else has to be set to my knowledge. But using a single = CPU/core > has other consequences that may be of note depending on what one wants > to do with the G5. >=20 >=20 >=20 > [For the following: I believe it only applies to head , not even > stable/12: The fix so that usefdt would work at all ( -r341614 ) > is for . . ./sys/powerpc/powermac/macgpio.c and has not been > merged to stable/12 ( and, so, not to release/12.0.0 ).] >=20 > As far as I know the following by itself at the loader prompt does not > side step the VM_MAX_KERNEL_ADDRESS related problem: >=20 > set usefdt=3D1 I realized that I'd not tried usefdt=3D1 by itself after it was fixed. So I built and installed a kernel without reverting = VM_MAX_KERNEL_ADDRESS and tried it using "set usefdt=3D1" and it worked just fine. (It did = swap the 0 vs. 1 of the ethernet ports.) So I'll probably modify my loader to be a variant that does not require the explicit set usefdt=3D1 for powermacs and see how that goes. >=20 > However, usefdt should avoid other issues with mixing use of Apple's > OpenFirmware with FreeBSD execution. (It does swap which Ethernet > port is 0 vs. 1 as seen in FreeBSD.) >=20 > So once stable/12 has the update to sys/powerpc/powermac/macgpio.c > then usefdt=3D1 would likely be recommended for stable/12 as well. > (It will be a while before it shows up in a release/12.?.? .) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?30652AD4-E660-4888-BAA9-22082A059DB1>