What do I do if fdt_setprop() returns -FDT_ERR_NOSPACE?
I have this code:
static int fdt_set_qe_firmware(void *blob, int nodeoffset, const char *name, bd_t *bd)
{
struct qe_firmware_info *qe_fw_info;
int ret;
qe_fw_info = qe_get_firmware_info();
if (qe_fw_info) {
/* We assume the node doesn't exist yet */
nodeoffset = fdt_add_subnode(blob, nodeoffset, name);
if (nodeoffset < 0)
return nodeoffset;
ret = fdt_setprop_string(blob, nodeoffset, "id", qe_fw_info->id);
if (ret < 0)
return ret;
ret = fdt_setprop_typed(blob, nodeoffset, "extended_modes",
qe_fw_info->extended_modes);
if (ret < 0)
return ret;
return fdt_setprop(blob, nodeoffset, "virtual_traps",
qe_fw_info->vtraps, sizeof(qe_fw_info->vtraps));
}
return 0;
}The call to fdt_setprop_string() returns -FDT_ERR_NOSPACE. I created the DTB with this command:
dtc -I dts -O dtb -b 0 -R 8 -S 0x3000
What am I missing? Why is there no space left to add a string?
Signature · 2 lines
Timur Tabi Linux kernel developer at Freescale
Quoted 4 lines · Timur Tabi
I have this code:
static int
fdt_set_qe_firmware(void *blob, int nodeoffset, const char *name, bd_t *bd)
[snip]
Quoted 8 lines
}
The call to
fdt_setprop_string()returns -FDT_ERR_NOSPACE. I created the DTB with this command:dtc -I dts -O dtb -b 0 -R 8 -S
0x3000What am I missing? Why is there no space left to add a string?
Hi Timur,
How big is your blob? The -S 0x3000 creates a 12K blob, but the contents from your source can take up a substantial amount of that (at least mine do ;-). If you have the deprecated (and, hopefully, soon to be removed) CONFIG_OF_HAS_UBOOT_ENV and/or CONFIG_OF_HAS_BD_T defined, it will put more (useless) stuff in the blob, that will chew through more of your blob space.
I would try 0x4000 and see if it works. :-)
IIRC, Jon/David/someone posted (and Jon applied) a patch to the dtc that allows you to specify how much extra space to pad the blob with, as opposed to the -S flag that sets the blob up with a specific size. That may be a better match to what you want for your blob.
Best regards,
gvb
Quoted 1 line · Jerry Van Baren
I would try
0x4000and see if it works. :-)
I increased it to 0x8000 and it still didn't work. Something else must be wrong. I noticed that no one else calls fdt_setprop_string(). Could you please try using it yourself and see if you can get it to work?
Another possibility is that I'm creating the 'firmware' node wrong. I'm tryin to create a new node called 'firmware' under the 'qe' node, and put some new properties in it. I think my call to fdt_add_subnode() is right, because /proc/device_tree shows it:
/proc/device-tree/qe at e0100000 # ls -l firmware/
-r--r--r-- 1 root root 9 Nov 12 20:34 name
I'm using the return value from fdt_add_subnode() as the second parameter to fdt_setprop_string(). Is that right?
Signature · 2 lines
Timur Tabi Linux Kernel Developer @ Freescale
Quoted 9 lines · Timur Tabi
Quoted 1 line · Jerry Van Baren
I would try
0x4000and see if it works. :-)I increased it to
0x8000and it still didn't work. Something else must be
wrong. I noticed that no one else callsfdt_setprop_string(). Could you
please try using it yourself and see if you can get it to work?
Depending on your dtc version there was a short window where I broke the -S option.
- k
Quoted 5 lines · Timur Tabi
Quoted 1 line · Jerry Van Baren
I would try
0x4000and see if it works. :-)I increased it to
0x8000and it still didn't work.
Ok, it turns out this is another symptom of the relocation bug. If I call fdt_set_qe_firmware() directly instead of via a function pointer, everything works. I guess I need to find a work-around.
Signature · 2 lines
Timur Tabi Linux kernel developer at Freescale