head -r345758 32-bit powerpc FreeBSD (used on a PowerMac G5): usefdt mode breaks cpufreq (and so powerd)

[Mark Millard]

When I boot the PowerMac11,2 G5 (2 sockets, 2 cores each) via 32-bit
powerpc FreeBSD without usefdt mode, cpufreq and powerpd work normally.

But with usefdt cpufreq ends up only existing for cpu3:

# sysctl -a | grep freq
kern.timecounter.tc.timebase.frequency: 33333333
device	cpufreq
kern.eventtimer.et.decrementer.frequency: 33333333
kern.acct_chkfreq: 15
net.inet.sctp.sack_freq: 2
debug.cpufreq.lowest: 0
debug.cpufreq.verbose: 0
debug.uart_poll_freq: 50
dev.cpufreq.0.%parent: cpu3
dev.cpufreq.0.%pnpinfo: 
dev.cpufreq.0.%location: 
dev.cpufreq.0.%driver: cpufreq
dev.cpufreq.0.%desc: 
dev.cpufreq.%parent: 
dev.pcr.3.freq_settings: 10000/-1 5000/-1
dev.cpu.3.freq_levels: 2500/-1 1250/-1
dev.cpu.3.freq: 1250
dev.iicbus.3.frequency: 100000
dev.iicbus.2.frequency: 100000
dev.iicbus.1.frequency: 100000
dev.iicbus.0.frequency: 100000

powerpd ends up reporting "no cpufreq(4) support -- aborting".

(Note: non-usefdt boots list dev.cpufreq material for all 4
cpus, not just cpu3, and powerd works in that context.)

Part of this *may* be an ordering issue:

usefdt mode has the traversal order (just showing cpu# examples):

/device-tree/cpus/PowerPC,G5/cpu#: hex_bytes_line# 0: 00 00 00 03
/device-tree/cpus/PowerPC,G5/cpu#: txt_bytes_line# 0: \000\000\000\^C
/device-tree/cpus/PowerPC,G5/cpu#: hex_bytes_line# 0: 00 00 00 02
/device-tree/cpus/PowerPC,G5/cpu#: txt_bytes_line# 0: \000\000\000\^B
/device-tree/cpus/PowerPC,G5/cpu#: hex_bytes_line# 0: 00 00 00 01
/device-tree/cpus/PowerPC,G5/cpu#: txt_bytes_line# 0: \000\000\000\^A
/device-tree/cpus/PowerPC,G5/cpu#: hex_bytes_line# 0: 00 00 00 00
/device-tree/cpus/PowerPC,G5/cpu#: txt_bytes_line# 0: \000\000\000\000

but non-usefdt mode (the historical order) has the order:

/device-tree/cpus/PowerPC,G5/cpu#: hex_bytes_line# 0: 00 00 00 00
/device-tree/cpus/PowerPC,G5/cpu#: txt_bytes_line# 0: \000\000\000\000
/device-tree/cpus/PowerPC,G5/cpu#: hex_bytes_line# 0: 00 00 00 01
/device-tree/cpus/PowerPC,G5/cpu#: txt_bytes_line# 0: \000\000\000\^A
/device-tree/cpus/PowerPC,G5/cpu#: hex_bytes_line# 0: 00 00 00 02
/device-tree/cpus/PowerPC,G5/cpu#: txt_bytes_line# 0: \000\000\000\^B
/device-tree/cpus/PowerPC,G5/cpu#: hex_bytes_line# 0: 00 00 00 03
/device-tree/cpus/PowerPC,G5/cpu#: txt_bytes_line# 0: \000\000\000\^C

If some code expects the sequence to be increasing, it might
only pick up the first one (cpu3) for usefdt mode.

(The outputs are from my own tool that I run its output
through sort -s -k1,1 . Thus, the common prefix text is
grouped together, but in the original relative ordering.
The tool in turn uses code from ofwdump.)

This is far from the only type of thing that ends up reversed from the
historical order in usefdt mode.

Another possible contribution to lack of some froms of control is the
notice that usefdt mode gives out:

Error -2 adding node /ht at 0,f2000000/pci at 8/mac-io at 7/i2c at 18000/i2c-bus at 0 (i2c-bus at 0), skipping

(I'm using 32-bit powerpc FreeBSD because there are more problems
for powerpc64 FreeBSD: in non-usefdt mode ofwdump or tools like it
get system crashes for "timeout stopping cpus" or other such. This
goes back to at least -r333596 (but not to -r302214). ofwdump
works in 32-bit powerpc FreeBSD, no system crash.)

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