[U-Boot-Users] 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?
Timur Tabi wrote:
I have this code:
static int fdt_set_qe_firmware(void *blob, int nodeoffset, const char *name, bd_t *bd)
[snip]
}
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?
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
Jerry Van Baren wrote:
I would try 0x4000 and 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@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?
On Dec 7, 2007, at 8:44 PM, Timur Tabi wrote:
Jerry Van Baren wrote:
I would try 0x4000 and 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?
Depending on your dtc version there was a short window where I broke the -S option.
- k
Timur Tabi wrote:
Jerry Van Baren wrote:
I would try 0x4000 and see if it works. :-)
I increased it to 0x8000 and 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.
participants (3)
-
Jerry Van Baren -
Kumar Gala -
Timur Tabi