Date: Wed, 10 Apr 2019 02:30:45 -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 *fully* identified] Message-ID: <DF388686-6D89-4F1A-B12E-1F5F5B4DF3B2@yahoo.com> In-Reply-To: <5A26E6F0-13FB-4177-B284-45DA6FBED78E@yahoo.com> References: <BD01C826-89A2-46A0-9157-022481E0DC88@yahoo.com> <98A19824-3C07-4ED6-A848-5A634F95E1CF@yahoo.com> <D473FC85-E895-48C0-A587-F52A4FB403AF@yahoo.com> <9A2F72B7-A25C-478C-B1AD-0661278F0B46@yahoo.com> <88C954A4-6D5A-4AB9-AA26-0ACD6D298605@yahoo.com> <5A26E6F0-13FB-4177-B284-45DA6FBED78E@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2019-Apr-9, at 19:44, Mark Millard <marklmi at yahoo.com> wrote:
> . . .
I discovered a specific PowerMac11,2 vs. PowerMac7,2/PowerMac3,6
difference that is involved:
The difference is where nulls are vs. are not . . .
I found a linux comment (after the later path evidence was
observed):
/* Fixup an Apple bug where they have bogus \0 chars in =
the
* middle of the path in some properties, and extract
* the unit name (everything after the last '/').
*/
This was in the context of package-to-path use.
I have evidence of this (though not from OF_package_to_path use but
ofw_getprop_alloc use) . . .
The PowerMac11,2 has, for example, in the notation of my
dumping tool for looking at diff's of the (sorted) dumps:
/device-tree/cpus/PowerPC,G5/cpu-version: hex_bytes_line# 0: 00 44 01 01
/device-tree/cpus/PowerPC,G5/cpu-version: txt_bytes_line# 0: \000D\^A\^A
/device-tree/cpus/PowerPC,G5/cpu-version: hex_bytes_line# 0: 00 44 01 01
/device-tree/cpus/PowerPC,G5/cpu-version: txt_bytes_line# 0: \000D\^A\^A
/device-tree/cpus/PowerPC,G5/cpu-version: hex_bytes_line# 0: 00 44 01 01
/device-tree/cpus/PowerPC,G5/cpu-version: txt_bytes_line# 0: \000D\^A\^A
/device-tree/cpus/PowerPC,G5/cpu-version: hex_bytes_line# 0: 00 44 01 01
/device-tree/cpus/PowerPC,G5/cpu-version: txt_bytes_line# 0: \000D\^A\^A
But the PowerMac7,2 and PowerMac3,6 have a null character in the =
analogous
prefix (produced by the same criteria), here shown with ^@:
/device-tree/cpus/PowerPC,970^@/cpu-version: hex_bytes_line# 0: 00 39 02 =
02
/device-tree/cpus/PowerPC,970^@/cpu-version: txt_bytes_line# 0: =
\0009\^B\^B
/device-tree/cpus/PowerPC,970^@/cpu-version: hex_bytes_line# 0: 00 39 02 =
02
/device-tree/cpus/PowerPC,970^@/cpu-version: txt_bytes_line# 0: =
\0009\^B\^B
/device-tree/cpus/PowerPC,G4^@/cpu-version: hex_bytes_line# 0: 80 01 03 =
03
/device-tree/cpus/PowerPC,G4^@/cpu-version: txt_bytes_line# 0: =
\M^@\^A\^C\^C
/device-tree/cpus/PowerPC,G4^@/cpu-version: hex_bytes_line# 0: 80 01 03 =
03
/device-tree/cpus/PowerPC,G4^@/cpu-version: txt_bytes_line# 0: =
\M^@\^A\^C\^C
The code that produces a name for a ofw node, as shown after a / above,
is (C++17 notation):
auto name_for_ofw_node=3D [&ofw_fd](auto ofw_nd) -> auto
{
std::string nd_id_text{};
void* name_buf=3D nullptr;
int name_buf_len=3D 0;
auto const name_len=3D =
ofw_getprop_alloc(ofw_fd,ofw_nd,"name",&name_buf,&name_buf_len,1);
if (0<name_len)
nd_id_text+=3D std::string{static_cast<char const =
*>(name_buf), static_cast<std::string::size_type>(name_len-1)};
else
{
. . . (does not happen) . . .
}
return nd_id_text;
};
[With name_len instead of name_len-1 there would be one more '\0'
character in each such name after a / (before the first ":"):
the terminating null character would be included.]
If such a before-the-end-of-path ^@ shows up in the likes of
add_node_to_fdt via its use of OF_package_to_path:
char name[255], *lastprop, *subname;
. . .
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;
}
then the strrchr will not work as intended and the error message
will result (as it does for PowerMac7,2/PowerMac3,6).
I'll note that the return value of OF_package_to_path is ignored
above but the description I find is:
QUOTE
package-to-path
IN: phandle, [address] buf, buflen OUT: length
Returns the fully qualified pathname corresponding to the node =
identifier phandle, storing, at most, buflen bytes as a null-terminated =
string in the memory buffer starting at the address buf. If the length =
of the null- terminated pathname is greater than buflen, the trailing =
characters and the null terminator are not stored. Length is the length =
of the fully qualified pathname excluding any null terminator, or =E2=80=93=
1 if phandle is invalid.
END QUOTE
The linux code does use the return value in order to not be fooled by
null characters in the middle of the path.
=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?DF388686-6D89-4F1A-B12E-1F5F5B4DF3B2>