libfdt queries

libfdt queries

[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)

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

Re: libfdt queries

[David Gibson]

On Tue, Oct 25, 2011 at 11:28:51AM +0530, Varun Wadekar wrote:
> 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.

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

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

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

Re: libfdt queries

[Varun Wadekar]

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

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

fdt_setprop_string() returns success.
> 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.
-----------------------------------------------------------------------------------

Re: libfdt queries

[Varun Wadekar]

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

Re: libfdt queries

[David Gibson]

On Mon, Oct 31, 2011 at 05:15:56PM +0530, Varun Wadekar wrote:
> 
> > 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?

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

Re: libfdt queries

[Varun Wadekar]

>> 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).
>   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.
-----------------------------------------------------------------------------------