libfdt queries · kernelthread

Varun Wadekar

author

2011-10-25 05:58 UTC #0 lore raw

Hi,

I am using libfdt v1.3.0 for modifying the dtb file from the bootloader (not U-Boot). I have a .dtb file whose bootargs have to be modified before passing over to the kernel. This is the sequence that I am following:

<snip>

newlen = fdt_totalsize(blob) + 512;
fdt_open_into(blob, blob, newlen)

node = fdt_path_offset(blob, "/chosen");
if (node < 0)
<error handling code>

fdt_setprop_string(blob, node, "bootargs", cmdline)

<snip>

Now with the above code the serial console on my board does not come up with the default bootargs that are present in the .dts file. If I manipulate the bootargs string in the .dts file with some additional garbage characters and then run the above code then I see that the serial console comes up. I suspect that the dtb is not getting updated properly with the above apis. Somehow the dtb contents are getting overwritten and the serial console info is getting overwritten I think.

If I add a partial command line to my dts, then modifying the bootargs from fastboot does not corrupt the dtb file and I can see the kernel console come up.

Any pointers or ideas where I might have screwed up?

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

David Gibson

2011-10-25 06:47 UTC #2 lore raw

Quoted 17 lines · Varun Wadekar

Hi,
I am using libfdt v1.3.0 for modifying the dtb file from the bootloader (not U-Boot). I have a .dtb file whose bootargs have to be modified before passing over to the kernel. This is the sequence that I am following:
<snip>
newlen = fdt_totalsize(blob) + 512;
fdt_open_into(blob, blob, newlen)
node = fdt_path_offset(blob, "/chosen");
if (node < 0)
<error handling code>
fdt_setprop_string(blob, node, "bootargs", cmdline)

Quoted 8 lines

<snip>
Now with the above code the serial console on my board does not come up with the default bootargs that are present in the .dts file. If I manipulate the bootargs string in the .dts file with some additional garbage characters and then run the above code then I see that the serial console comes up. I suspect that the dtb is not getting updated properly with the above apis.

That seems a bit unlikely, but maybe. Is there any way you can dump out the dtb after processing by your bootloader?

Quoted 8 lines

Somehow the dtb contents are getting
overwritten and the serial console info is getting overwritten I think.
If I add a partial command line to my dts, then modifying the bootargs from fastboot does not corrupt the dtb file and I can see the kernel console come up.
Any pointers or ideas where I might have screwed up?

First thing would be to check if fdt_setprop_string() is returning an error code.

Also, is that the only dtb manipulation you do, or do you make other changes to the dtb?

Signature · 4 lines

David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Varun Wadekar

author

2011-10-25 07:08 UTC #4 lore raw

Quoted 4 lines

That seems a bit unlikely, but maybe. Is there any way you can dump out the dtb after processing by your bootloader?

I will try to get a dump.

Quoted 2 lines

First thing would be to check if fdt_setprop_string() is returning an error code.

fdt_setprop_string() returns success.

Quoted 2 lines

Also, is that the only dtb manipulation you do, or do you make other changes to the dtb?

That's the only dtb manipulation I do.

I tried hacking vprintk() to use early_printk() instead and I see that the kernel boots up. So it seems that only the "serial@xxxxxxxx" node contents are getting messed up. (Incidentally it also lies after the "chosen" node. I am just saying.)

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

Varun Wadekar

author

2011-10-31 11:45 UTC #5 lore raw

In reply to a message not in the archive

Quoted 4 lines

That seems a bit unlikely, but maybe. Is there any way you can dump out the dtb after processing by your bootloader?

Found out the root cause. My bootloader was not manipulating the dtb blob size properly and hence the final dtb was messed up. This resulted in the kernel not finding proper fields inside the dtb.

Sorry for the false alarm. Issue closed.

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

David Gibson

2011-11-01 00:55 UTC #7 lore raw

Quoted 8 lines · Varun Wadekar

Quoted 4 lines
That seems a bit unlikely, but maybe. Is there any way you can dump out the dtb after processing by your bootloader?
Found out the root cause. My bootloader was not manipulating the dtb blob size properly and hence the final dtb was messed up. This resulted in the kernel not finding proper fields inside the dtb.

Ok. You mean you were truncating the blob? Or you were manually (without libfdt) manipulating the size property somehow and messing that up?

Signature · 4 lines

David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Varun Wadekar

author

2011-11-01 04:17 UTC #9 lore raw

Quoted 5 lines

Quoted 4 lines
Found out the root cause. My bootloader was not manipulating the dtb blob size properly and hence the final dtb was messed up. This resulted in the kernel not finding proper fields inside the dtb.
Ok. You mean you were truncating the blob?

There is an internal function which actually copies the .dtb from a partition on the eMMC to SDRAM before handing control to the kernel. I forgot to set the proper size to be used after manipulating the command line (since the command line size changed the copy routine should now copy the updated size and should discard the old size).

Quoted 4 lines

Or you were manually
(without libfdt) manipulating the size property somehow and messing that up?

libfdt was properly changing the size inside the blob, but I did not use the updated size while copying the blob from eMMC to SDRAM.

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------