[U-Boot-Users] What do I do if fdt_setprop() returns -FDT_ERR_NOSPACE?

[U-Boot-Users] What do I do if fdt_setprop() returns -FDT_ERR_NOSPACE?

[Timur Tabi]

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
Linux kernel developer at Freescale

[U-Boot-Users] What do I do if fdt_setprop() returns -FDT_ERR_NOSPACE?

[Jerry Van Baren]

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

[U-Boot-Users] What do I do if fdt_setprop() returns -FDT_ERR_NOSPACE?

[Timur Tabi]

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 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?

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] What do I do if fdt_setprop() returns -FDT_ERR_NOSPACE?

[Kumar Gala]

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

[U-Boot-Users] What do I do if fdt_setprop() returns -FDT_ERR_NOSPACE?

[Timur Tabi]

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.

-- 
Timur Tabi
Linux kernel developer at Freescale