Date: Sun, 7 Apr 2019 15:46:11 -0700 From: Mark Millard <marklmi@yahoo.com> To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, Justin Hibbits <chmeeedalf@gmail.com> Subject: Re: head -r345758: usefdt=1 style boot fails on PowerMac7,2 G5 (1 core per socket): Error -2 adding node /cpus/PowerpC,970 [G4 failures too, problem identified] Message-ID: <D473FC85-E895-48C0-A587-F52A4FB403AF@yahoo.com> In-Reply-To: <98A19824-3C07-4ED6-A848-5A634F95E1CF@yahoo.com> References: <BD01C826-89A2-46A0-9157-022481E0DC88@yahoo.com> <98A19824-3C07-4ED6-A848-5A634F95E1CF@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[I found old 2016 boot media to use to boot the
PowerMac7,2 and PowerMac3,6 (as 32-bit). This lets
me look around. PowerMac7,2 has some distinctions
from the PowerMac3,6 differences to PowerMac11,2 . So
my interpretation was incomplete.]
On 2019-Apr-7, at 14:36, Mark Millard <marklmi@yahoo.com> wrote:
> [The problem also exists on 32-bit powerpc, at least for
> a PowerMac3,6 example. In this context I was able to gather
> evidence for the problem, unlike for the PowerMac7,2 .]
>=20
> On 2019-Apr-7, at 05:14, Mark Millard <marklmi at yahoo.com> wrote:
>=20
>> [The same SSDs boot the 2 PowerMac11,2 G5 =
(2-socket/2-core-per-socket)
>> just fine. I temporarily have access to the PowerMac7,2 and a
>> different 11,2 G5 that has only 12 GiBytes of RAM --but not the
>> 16 GiByte one. ]
>>=20
>> Both powerpc64 FreeBSD (built via system-clang) and 32-bit powerpc
>> FreeBSD (built via gcc 4.2.1) fail the same way.
>>=20
>> The failure looks like (from a picture of a powerpc64
>> attempt):
>>=20
>> Booting [/boot/kernel/kernel]. . .
>> Error -2 adding node /cpus/PowerPC,970 (PowerPC,970), skipping
>> Kernel entry at 0x100100 . . .
>>=20
>> (and that is the end of the output).
>>=20
>> Note: I had modified the kernel to not require an explicit usefdt=3D1
>> --in fact giving not control in the other direction either. So,
>> always using usefdt=3D1 mode. I had intended to stick with testing
>> usefdt=3D1 mode.
>>=20
>> Result: As stands I do not have media set up that can boot the
>> 7,2 . This means that I've not checked any contrasting cases
>> that do not involve usefdt=3D1 style behavior.
>>=20
>> Thus my attribution of the problem to usefdt=3D1 style behavior is
>> not validated.
>=20
> I have temporary access to some old PowerMac G4s. So I tried
> booting a PowerMac3,6 1.42 GHz Dual Processor FW800 as an initial
> experiment. This note reports the failed results
>=20
> While it does not stop booting . . .
>=20
> It boots as a single CPU machine with no ethernet device (for
> an example of something else that is missing).
>=20
> It does briefly show messages like:
>=20
> Error -2 adding node /cpus/PowerPC,G4 (PowerPC,G4), skipping
> Error -2 adding node /pci@f2000000//mac-io@17/gpio@50/gpio5@6f =
(gpio5@6f), skipping
> Error -2 adding node /pci@f2000000//mac-io@17/gpio@50/gpio6@70 =
(gpio6@70), skipping
> Error -2 adding node /pci@f2000000//mac-io@17/gpio@50/gpio11@75 =
(gpio11@75), skipping
> Error -2 adding node /pci@f2000000//mac-io@17/extint-gpio@15@67 =
(extint-gpio@15@67), skipping
>=20
> It appears that -2 is: -FDT_ERR_EXISTS
>=20
> #define FDT_ERR_EXISTS 2
> /* FDT_ERR_EXISTS: Attempted to create a node or property which
> * already exists */
>=20
> The below shows my evidence that for the PowerMac3,6 in
> question "/cpus/PowerPC,G4" is apparently not a unique
> textual identification --and that needs to be handled but
> is not. (The PowerMac7,2 may be similar but did not boot
> to where I could easily explore.) [I've not gone through
> the details for the gpio "skipping" reports.]
>=20
> [On the PowerMac3.6 I did: ofwdump -ap > /root/ofwdump_bad.txt
> Later I looked at the drive in another machine.]
>=20
> ofwdump -ap reports for cpus on the PowerMac3,6:
>=20
> # grep -i cpus /mnt/root/ofwdump_bad.txt=20
> Node 0x73d0: cpus
> #cpus:
> 'cpus'
>=20
> (later this will be contrasted with the PowerMac11,2 context).
>=20
> Looking:
>=20
> Node 0x73d0: cpus
> phandle:
> ff 88 34 00=20
> '\M^?\M^H4'
> core-temp:
> 00 00 00 41=20
> core-voltage:
> 00 00 00 9b=20
> #cpus:
> 00 00 00 02=20
> #size-cells:
> 00 00 00 00=20
> #address-cells:
> 00 00 00 01=20
> name:
> 63 70 75 73 00=20
> 'cpus'
> Node 0x7450: PowerPC,G4
> phandle:
> ff 88 36 d8=20
> gpio-parent:
> ff 96 41 d0=20
> . . .
>=20
> But:
>=20
> # grep -i powerpc /mnt/root/ofwdump_bad.txt
> driver,AAPL,MacOS,PowerPC:
> Node 0x7450: PowerPC,G4
>=20
> (There is only the one PowerPC,G4 Node present in the dump
> output --because the 2nd was treated as in error at boot.)
>=20
> My interpretation is that there are 2:
>=20
> /cpus/PowerPC,G4
> /cpus/PowerPC,G4
>=20
> with no textual differentiation. The Node 0x???? figures
> seem to be the differentiation.
>=20
> This looks different than on the PowerMac11,2 :
>=20
> # ofwdump -ap | grep -i cpus
> '/cpus/@3'
> '/cpus/@2'
> '/cpus/@1'
> '/cpus/@0'
> Node 0xc7f4: cpus
> 'cpus'
>=20
> # ofwdump -ap | grep -i powerpc
> Node 0xc864: PowerPC,G5
> 'PowerPC,G5'
> Node 0xcb4c: PowerPC,G5
> 'PowerPC,G5'
> Node 0xce34: PowerPC,G5
> 'PowerPC,G5'
> Node 0xd11c: PowerPC,G5
> 'PowerPC,G5'
>=20
> In this context /cpus/@N/PowerMacPC,G5 is unique textually
> without needing the 0x???? figures for the Node's.
>=20
>=20
> This matches up with what I see in the code: it is
> checking for a textual differentiation and only the
> PowerMac11,2 appears to have such (of what I've
> seen). The details of tracing the code down follow.
>=20
> The code that reports the failures is:
>=20
> static void
> add_node_to_fdt(void *buffer, phandle_t node, int fdt_offset)
> {
> int i, child_offset, error;
> char name[255], *lastprop, *subname;
> void *propbuf;
> ssize_t proplen;
> . . .
> for (node =3D OF_child(node); node > 0; node =3D OF_peer(node)) =
{
> OF_package_to_path(node, name, sizeof(name));
> subname =3D strrchr(name, '/');
> subname++;
> child_offset =3D fdt_add_subnode(buffer, fdt_offset, =
subname);
> if (child_offset < 0) {
> printf("Error %d adding node %s (%s), =
skipping\n",
> child_offset, name, subname);
> continue;
> }
>=20
> add_node_to_fdt(buffer, node, child_offset);
> }
> }
>=20
> where:
>=20
> int fdt_add_subnode(void *fdt, int parentoffset, const char *name)
> {
> return fdt_add_subnode_namelen(fdt, parentoffset, name, =
strlen(name));
> }
>=20
> and:
>=20
> int fdt_add_subnode_namelen(void *fdt, int parentoffset,
> const char *name, int namelen)
> {
> struct fdt_node_header *nh;
> int offset, nextoffset;
> int nodelen;
> int err;
> uint32_t tag;
> fdt32_t *endtag;
>=20
> FDT_RW_CHECK_HEADER(fdt);
>=20
> offset =3D fdt_subnode_offset_namelen(fdt, parentoffset, name, =
namelen);
> if (offset >=3D 0)
> return -FDT_ERR_EXISTS;
> . . .
>=20
> and:
>=20
> int fdt_subnode_offset_namelen(const void *fdt, int offset,
> const char *name, int namelen)
> {
> int depth;
>=20
> FDT_CHECK_HEADER(fdt);
>=20
> for (depth =3D 0;
> (offset >=3D 0) && (depth >=3D 0);
> offset =3D fdt_next_node(fdt, offset, &depth))
> if ((depth =3D=3D 1)
> && fdt_nodename_eq_(fdt, offset, name, namelen))
> return offset;
>=20
> if (depth < 0)
> return -FDT_ERR_NOTFOUND;
> return offset; /* error */
> }
>=20
> where:
>=20
> static int fdt_nodename_eq_(const void *fdt, int offset,
> const char *s, int len)
> {
> int olen;
> const char *p =3D fdt_get_name(fdt, offset, &olen);
>=20
> if (!p || olen < len)
> /* short match */
> return 0;
>=20
> if (memcmp(p, s, len) !=3D 0)
> return 0;
>=20
> if (p[len] =3D=3D '\0')
> return 1;
> else if (!memchr(s, '@', len) && (p[len] =3D=3D '@'))
> return 1;
> else
> return 0;
> }
>=20
> No consideration of distinct 0x???? figures for
> Node are made by fdt_subnode_offset_namelen .
> At least for the PowerMac3,6 such a differentiation
> is required if usefdt=3D1 style is to work.
>=20
PowerMac7,2 quick look:
# ofwdump -ap | egrep -i '(cpus|powerpc|aliases)' | more
Node 0xff887b40: cpus
'cpus'
Node 0xff887e10: PowerPC,970
Node 0xff889150: PowerPC,970
driver,AAPL,MacOS,PowerPC:
driver,AAPL,MacOS,PowerPC:
Node 0xff985cc8: aliases
'aliases'
'/cpus/@0'
'/cpus/@1'
So the PowerPC,970 are not under any /cpus/@N .
But there are /cpus/@N aliases, unlike for=20
owerMac3,6 .
Doing similarly for PowerMac11,2 for comparison:
# ofwdump -ap | egrep -i '(cpus|powerpc|aliases)' | more
Node 0x238: aliases
'/cpus/@3'
'/cpus/@2'
'/cpus/@1'
'/cpus/@0'
'aliases'
Node 0xc7f4: cpus
'cpus'
Node 0xc864: PowerPC,G5
'PowerPC,G5'
Node 0xcb4c: PowerPC,G5
'PowerPC,G5'
Node 0xce34: PowerPC,G5
'PowerPC,G5'
Node 0xd11c: PowerPC,G5
'PowerPC,G5'
Note the PowerMac11,2 has unique to it for each: 'PowerPC,G5'
These are:
name:
50 6f 77 65 72 50 43 2c 47 35 00=20
'PowerPC,G5'
Such is missing for PowerMac7,2 and for PowerMac3,6 .
(The PowerPC,G5 's are not under /cpus/@N/ here either.)
Checking PowerMac3,6 by looking the same way:
# ofwdump -ap | egrep -i '(cpus|powerpc|aliases)' | more
Node 0xff883400: cpus
'cpus'
#cpus:
Node 0xff8836d8: PowerPC,G4
Node 0xff884b08: PowerPC,G4
Node 0xff887650: aliases
'aliases'
driver,AAPL,MacOS,PowerPC:
So it too does not have such subordinate: name:
but is also missing /cpus/@N 's.
Looks like lack of the subordinate: name:
means that the text from the Node line should be
used as the name?
Looks like one can not depend on there being
/cpus/@N 's, even when multiple CPUs are present
for the G4's.
I'll see about diff'ing the good vs. bad PowerMac3,6
ofwdump -ap output when I have a chance.
=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?D473FC85-E895-48C0-A587-F52A4FB403AF>