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]

[Mark Millard]

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= [&ofw_fd](auto ofw_nd) -> auto
    {
        std::string nd_id_text{};

        void* name_buf= nullptr;
        int   name_buf_len= 0;
        auto const name_len= ofw_getprop_alloc(ofw_fd,ofw_nd,"name",&name_buf,&name_buf_len,1);
        if (0<name_len)
            nd_id_text+= 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 = OF_child(node); node > 0; node = OF_peer(node)) {
               OF_package_to_path(node, name, sizeof(name));
               subname = strrchr(name, '/');
               subname++;
               child_offset = 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 –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.

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