add_node_to_fdt 's "Detect and correct for errors and strangeness" vs. PowerMac7,2 example's 2 huge driver,AAPL,MacOS,PowerPC properties

Mark Millard via freebsd-ppc <[email protected]>
Newsgroups gmane.os.freebsd.devel.ppc
Message-ID <[email protected]>
What is unique to the PowerMac7,2 (2 socket, 1 core each) that
might contribute to usefdt mode crashing?

One point is that its OpenFirmware content is 4 times+
larger compared to some others as viewed view ofwdump -ap
outputs:

# ls -lTdt ~/ofwdump_*_[og]*.txt
-rw-r--r--  1 root  wheel  192603 Apr  7 17:48:15 2019 /root/ofwdump_11,2_old.txt
-rw-r--r--  1 root  wheel  162390 Apr  7 15:40:23 2019 /root/ofwdump_3,6_good.txt
-rw-r--r--  1 root  wheel  818400 Apr  7 15:15:03 2019 /root/ofwdump_7,2_good.txt

It turns out that much of the size is for ATY,Rocket* content:

  Node 0xff96c1d8: pci
    Node 0xff9d1708: ATY,RocketParent
      Node 0xff9f4890: ATY,Rocket_A
      Node 0xff9f5848: ATY,Rocket_B

Specifically:

      Node 0xff9f4890: ATY,Rocket_A
. . .
        driver,AAPL,MacOS,PowerPC:
. . .   (thousands of lines, each describing 20 bytes) . . .
. . .
      Node 0xff9f5848: ATY,Rocket_B
. . .
        driver,AAPL,MacOS,PowerPC:
. . .   (thousands of lines, each describing 20 bytes) . . .

This may not mix well with the add_node_to_fdt "Detect and
correct for errors and strangeness" handling in:

static void
add_node_to_fdt(void *buffer, phandle_t node, int fdt_offset)
{
        int i, child_offset, error;
        char name[255+1], *lastprop, *subname; // +1 added for always having a trailing '\0' position.
        void *propbuf;
        ssize_t proplen;

        lastprop = NULL;
        while (OF_nextprop(node, lastprop, name) > 0) {
                proplen = OF_getproplen(node, name);

                /* Detect and correct for errors and strangeness */
                if (proplen < 0)
                        proplen = 0;
                if (proplen > 1024)
                        proplen = 1024;

                propbuf = malloc(proplen);
                if (propbuf == NULL) {
                        printf("Cannot allocate memory for prop %s\n", name);
                        return;
                }
                OF_getprop(node, name, propbuf, proplen);
                error = fdt_setprop(buffer, fdt_offset, name, propbuf, proplen);
                free(propbuf);
                lastprop = name;
                if (error)
                        printf("Error %d adding property %s to "
                            "node %d\n", error, name, fdt_offset);
        }
. . .

If either driver,AAPL,MacOS,PowerPC would ever be used,
it would be corrupted by the truncation to 1024 bytes.

There is also the overall size of the "buffer" if the
drives were to be handled:

int
fdt_platform_load_dtb(void)
{
        void *buffer;
        size_t buflen = 409600;
                
        buffer = malloc(buflen);
        fdt_create_empty_tree(buffer, buflen);
        add_node_to_fdt(buffer, OF_peer(0), fdt_path_offset(buffer, "/"));
        ofwfdt_fixups(buffer);
        fdt_pack(buffer);
                
        fdt_load_dtb_addr(buffer);
        free(buffer);
                        
        return (0);
}

I'm not sure how to tell what buflen would be
sufficient, including the status of the 409600
figure currently in use.


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

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "[email protected]"
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.