Date: Thu, 11 Apr 2019 23:54:05 -0700 From: Mark Millard <marklmi@yahoo.com> To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, Justin Hibbits <chmeeedalf@gmail.com> Subject: Re: head -r345758 32-bit powerpc FreeBSD (used on a PowerMac G5): usefdt mode breaks cpufreq (and so powerd) [more such] Message-ID: <BBCEED11-2066-4668-A7C3-B75AAA94D609@yahoo.com> In-Reply-To: <4110295C-FB5B-4197-B573-DF57D19C9103@yahoo.com> References: <4110295C-FB5B-4197-B573-DF57D19C9103@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[I give details of some of the code vs. the fdt mismatch.]
On 2019-Apr-9, at 23:27, Mark Millard <marklmi at yahoo.com> wrote:
> 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.
>=20
> But with usefdt cpufreq ends up only existing for cpu3:
>=20
> # 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:=20
> dev.cpufreq.0.%location:=20
> dev.cpufreq.0.%driver: cpufreq
> dev.cpufreq.0.%desc:=20
> dev.cpufreq.%parent:=20
> 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
>=20
> powerpd ends up reporting "no cpufreq(4) support -- aborting".
>=20
> (Note: non-usefdt boots list dev.cpufreq material for all 4
> cpus, not just cpu3, and powerd works in that context.)
>=20
> Part of this *may* be an ordering issue:
>=20
> usefdt mode has the traversal order (just showing cpu# examples):
>=20
> /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
>=20
> but non-usefdt mode (the historical order) has the order:
>=20
> /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
>=20
> If some code expects the sequence to be increasing, it might
> only pick up the first one (cpu3) for usefdt mode.
>=20
> (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.)
>=20
> This is far from the only type of thing that ends up reversed from the
> historical order in usefdt mode.
>=20
> Another possible contribution to lack of some froms of control is the
> notice that usefdt mode gives out:
>=20
> Error -2 adding node /ht@0,f2000000/pci@8/mac-io@7/i2c@18000/i2c-bus@0 =
(i2c-bus@0), skipping
>=20
> (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.)
Only one cpu gets a power-mode-data property from open firmware
(prior to fdt generation). For example (from a PowerMac11,2
booted with 32-bit FreeBSD), note the ordering of @), @1, @2,
and finally @3. This will later be contrasted with fdt and with
fdt order with the pcr_attach processing.
Node 0xff89d680: PowerPC,G5
name:
50 6f 77 65 72 50 43 2c 47 35 00=20
'PowerPC,G5'
device_type:
63 70 75 00=20
'cpu'
reg:
00 00 00 00=20
cpu#:
00 00 00 00=20
. . .
power-mode-data:
80 01 56 6b 80 03 54 69=20
. . .
Node 0xff89eb70: PowerPC,G5
cpu#:
00 00 00 01=20
cpu-info:
00 00 00 00 00 00 01 10 00 00 00 00 ff f0 32 8c 10 00 00 00=20
02 00 90 00 00 41 10 01 00 00 00 00 00 00 00 00 00 02 00 01=20
00 44 01 01 00 00 00 01 de ad be ef=20
name:
50 6f 77 65 72 50 43 2c 47 35 00=20
'PowerPC,G5'
device_type:
63 70 75 00=20
'cpu'
reg:
00 00 00 01=20
. . .
Node 0xff89f248: PowerPC,G5
cpu#:
00 00 00 02=20
cpu-info:
00 00 00 00 00 00 01 10 00 00 00 00 ff f0 32 8c 10 00 00 00=20
02 00 90 00 00 41 10 01 00 00 00 00 00 00 00 00 00 03 00 02=20
00 44 01 01 00 00 00 02 de ad be ef=20
name:
50 6f 77 65 72 50 43 2c 47 35 00=20
'PowerPC,G5'
device_type:
63 70 75 00=20
'cpu'
reg:
00 00 00 02=20
. . .
Node 0xff89f920: PowerPC,G5
cpu#:
00 00 00 03=20
cpu-info:
00 00 00 00 00 00 01 10 00 00 00 00 ff f0 32 8c 10 00 00 00=20
02 00 90 00 00 41 10 01 00 00 00 00 00 00 00 00 00 00 00 03=20
00 44 01 01 00 00 00 03 de ad be ef=20
name:
50 6f 77 65 72 50 43 2c 47 35 00=20
'PowerPC,G5'
device_type:
63 70 75 00=20
'cpu'
reg:
00 00 00 03=20
. . .
But when booted with usefdt mode that list is in a different order
(that will mater for the pcr_attach routine). Note the difference
in ordering of the PowerPCG5@3e:
Node 0xc864: PowerPC,G5
. . .
reg:
00 00 00 03=20
device_type:
63 70 75 00=20
'cpu'
name:
50 6f 77 65 72 50 43 2c 47 35 00=20
'PowerPC,G5'
cpu-info:
00 00 00 00 00 00 01 10 00 00 00 00 ff f0 32 8c 10 00 00 00=20
02 00 90 00 00 41 10 01 00 00 00 00 00 00 00 00 00 00 00 03=20
00 44 01 01 00 00 00 03 de ad be ef=20
cpu#:
00 00 00 03=20
. . .
Node 0xcb4c: PowerPC,G5
. . .
reg:
00 00 00 02=20
device_type:
63 70 75 00=20
'cpu'
name:
50 6f 77 65 72 50 43 2c 47 35 00=20
'PowerPC,G5'
cpu-info:
00 00 00 00 00 00 01 10 00 00 00 00 ff f0 32 8c 10 00 00 00=20
02 00 90 00 00 41 10 01 00 00 00 00 00 00 00 00 00 03 00 02=20
00 44 01 01 00 00 00 02 de ad be ef=20
cpu#:
00 00 00 02=20
. . .
Node 0xce34: PowerPC,G5
. . .
reg:
00 00 00 01=20
device_type:
63 70 75 00=20
'cpu'
name:
50 6f 77 65 72 50 43 2c 47 35 00=20
'PowerPC,G5'
cpu-info:
00 00 00 00 00 00 01 10 00 00 00 00 ff f0 32 8c 10 00 00 00=20
02 00 90 00 00 41 10 01 00 00 00 00 00 00 00 00 00 02 00 01=20
00 44 01 01 00 00 00 01 de ad be ef=20
cpu#:
00 00 00 01=20
. . .
Node 0xd11c: PowerPC,G5
. . .
power-mode-data:
80 01 56 6b 80 03 54 69=20
. . .
cpu#:
00 00 00 00=20
reg:
00 00 00 00=20
device_type:
63 70 75 00=20
'cpu'
name:
50 6f 77 65 72 50 43 2c 47 35 00=20
'PowerPC,G5'
Note that the pcr_attach routine uses code like:
cpu =3D ofw_bus_get_node(device_get_parent(dev));
. . .
if (OF_getproplen(cpu, "power-mode-data") <=3D 0) {
/* Use the first CPU's node */
cpu =3D OF_child(OF_parent(cpu));
}
. . .
sc->nmodes =3D OF_getproplen(cpu, "power-mode-data");
if (sc->nmodes <=3D 0 || sc->nmodes > sizeof(sc->pcr_vals)) {
device_printf(dev,"No power mode data in device =
tree!\n");
return (ENXIO);
}
But for usefdt mode: cpu =3D OF_child(OF_parent(cpu)) finds
cpu 3, which does not have a power-mode-data property.
In other words: the "first" cpu is cpu 3 instead of the historical
openfirmware result of being cpu 0 (that has the power-mode-data
proprty).
There is also:
static int
powermac_smp_first_cpu(platform_t plat, struct cpuref *cpuref)
{
. . .
cpu =3D OF_child(dev);
while (cpu !=3D 0) {
res =3D OF_getprop(cpu, "device_type", buf, =
sizeof(buf));
if (res > 0 && strcmp(buf, "cpu") =3D=3D 0)
break;
cpu =3D OF_peer(cpu);
}
. . .
which will find cpu 3 instead of cpu 0 when usefdt mode is
in use. The cpu# or reg properties are not checked. (I
do not know if cpu 3 being the "smp first cpu" is a
problem vs. okay.)
i2s_probe seems to make similar assumptions:
name =3D ofw_bus_get_name(self);
if (!name)
return (ENXIO);
if (strcmp(name, "i2s") !=3D 0)
return (ENXIO);
subchild =3D OF_child(OF_child(ofw_bus_get_node(self)));
"First child of first child" is likely only preserved in
fdt if there is only one child at each stage. Otherwise
the subchild will likely be something different than for
direct use of openfirmware.
I've not tried to find all code with assumptions of
relative positions of nodes being invariant despite
them not being so for openfirmware -> fdt. But it does
look like a round of updates would be required, to
either the openfirmware->fdt translation or to the code
that uses relative path traversals instead of searches
that check content to find the desired matching node.
=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?BBCEED11-2066-4668-A7C3-B75AAA94D609>