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>
index | next in thread | previous in thread | raw e-mail
[ For head usefdt=1 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: > >> Is there a recommended solution to booting/installing Release 12 on the PowerMac G5 "Quad Core"? >> >> 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. >> >> Any tips or hits would be appreciated. > > 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. > > So for now I base my builds on reverting the change in question. (I normally > use head, including 12 back when it was head.) > > . . ./sys/powerpc/include/vmparam.h has a definition of VM_MAX_KERNEL_ADDRESS . > I reverted the: > > #define VM_MAX_KERNEL_ADDRESS 0xe0000007ffffffffUL > > to be: > > #define VM_MAX_KERNEL_ADDRESS 0xe0000001c7ffffffUL > > 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. > > Disabling smp via the following at the loader prompt seems to avoid > the problem without such a change to to VM_MAX_KERNEL_ADDRESS : > > set kern.smp.disabled=1 > > 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. > > > > [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 ).] > > As far as I know the following by itself at the loader prompt does not > side step the VM_MAX_KERNEL_ADDRESS related problem: > > set usefdt=1 I realized that I'd not tried usefdt=1 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=1" 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=1 for powermacs and see how that goes. > > 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.) > > So once stable/12 has the update to sys/powerpc/powermac/macgpio.c > then usefdt=1 would likely be recommended for stable/12 as well. > (It will be a while before it shows up in a release/12.?.? .) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?30652AD4-E660-4888-BAA9-22082A059DB1>