Date: Mon, 08 Mar 2021 11:29:17 -0600 From: "Brandon Bergren" <bdragon@FreeBSD.org> To: "Mark Millard" <marklmi@yahoo.com> Cc: "FreeBSD PowerPC ML" <freebsd-ppc@freebsd.org> Subject: Re: Note: Fix committed to main for PPC32 SMP Message-ID: <f631014a-d014-465e-9aa5-dc1155c96409@www.fastmail.com> In-Reply-To: <7082DB3B-FA63-4D08-91CB-7B4A4FA1501A@yahoo.com> References: <95e4ea92-128b-4765-bdb1-4726b2573b4c@www.fastmail.com> <7082DB3B-FA63-4D08-91CB-7B4A4FA1501A@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Mar 6, 2021, at 9:58 PM, Mark Millard wrote: > > If I am to test any attempted timebase handling, I'll have > to unwind my code that only tries to get the timebases > close enough to avoid the problem, using a technique that > is not platform specific but not as accurate either. (If > the 32-bit code ever does support booting and operating > multi-cpu G5s again, it would get back into this issue, > just like the powerpc64 code for PowerMacs needs to.) I have been testing accurate timebase setting for G4 on my end. It still needs cleaned up a bit before I commit it, but I will have that sorted out sometime soon. G5 timebase handling is more complicated, especially because we don't have a platform interpreter so it will have to be a model-by-model fix for the newer ones that use platform funcs to handle turning the timebase clock on and off. I'm gonna need a hexdump of the contents of the platform-cpu-timebase property on /cpus to get G5 models fixed properly (along with the model property on /) PowerMac7,2 and PowerMac7,3 and RackMac3,1 should be able to be sorted out without this data, as those can be handled other ways (as per how the Linux code handles them.) -- Brandon Bergren bdragon@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f631014a-d014-465e-9aa5-dc1155c96409>