Note: Fix committed to main for PPC32 SMP

[Mark Millard]

On 2021-Mar-8, at 09:29, Brandon Bergren <bdragon at FreeBSD.org> wrote:
> 
> 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 /)

ofwdump -ap on the G5 2-socket/2-cores-each reports:

    platform-cpu-timebase:
      ff 99 1d 78 

(This may be one of the G5's last acts. Sitting basically
idle is keeping the fan busy.)


> 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.)
> 

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)