[U-Boot] 4K padding of ARM DT blob

[U-Boot] 4K padding of ARM DT blob

[Yehuda Yitschak]

Hello

I was wondering why the default ARM device tree blob is padded by 4K bytes

Is this required to align to some storage medium ?
Is there a configuration that allows to eliminate this padding to save space ?

Thanks

________________________________
Yehuda Yitschak
Marvell Israel - SW Engineer
6 Hamada Street
Mordot HaCarmel Industrial Park
Yokneam, 20692, Israel
Email: yehuday at marvell.com<mailto:yehuday@marvell.com>
Office:  +972.4.9091717
Fax:      +972.4.9091501
Web site: http://www.marvell.com<http://www.marvell.com/>

This message may contain confidential, proprietary or legally privileged information. The information is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by telephone or by e-mail and delete the message from your computer.
________________________________

[U-Boot] 4K padding of ARM DT blob

[Tom Rini]

On Thu, Mar 05, 2015 at 08:02:50AM +0000, Yehuda Yitschak wrote:

> Hello
> 
> I was wondering why the default ARM device tree blob is padded by 4K bytes
> 
> Is this required to align to some storage medium ?
> Is there a configuration that allows to eliminate this padding to save space ?

Can you expand on what you're referring to / code in question?  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150305/bda26e94/attachment.sig>

[U-Boot] 4K padding of ARM DT blob

[Yehuda Yitschak]

Hey Tom 

In arch/arm/dts/Makfile: line 56 
"DTC_FLAGS += -R 4 -p 0x1000"

this tell the dtc tool to add a 4K padding to the device tree blob. 

i can't figure out why this is needed.
Its creating a 4KB penalty on the dtb file so i guess it has some justification. 

Thanks 

Yehuda 
________________________________________
From: Tom Rini <trini@konsulko.com>
Sent: Thursday, March 5, 2015 6:40 PM
To: Yehuda Yitschak
Cc: yamada.m at jp.panasonic.com; u-boot at lists.denx.de; Hanna Hawa
Subject: Re: [U-Boot] 4K padding of ARM DT blob

On Thu, Mar 05, 2015 at 08:02:50AM +0000, Yehuda Yitschak wrote:

> Hello
>
> I was wondering why the default ARM device tree blob is padded by 4K bytes
>
> Is this required to align to some storage medium ?
> Is there a configuration that allows to eliminate this padding to save space ?

Can you expand on what you're referring to / code in question?  Thanks!

--
Tom

[U-Boot] 4K padding of ARM DT blob

[Tom Rini]

On Thu, Mar 05, 2015 at 06:20:35PM +0000, Yehuda Yitschak wrote:
> Hey Tom 
> 
> In arch/arm/dts/Makfile: line 56 
> "DTC_FLAGS += -R 4 -p 0x1000"
> 
> this tell the dtc tool to add a 4K padding to the device tree blob. 
> 
> i can't figure out why this is needed.
> Its creating a 4KB penalty on the dtb file so i guess it has some justification. 

That's interesting and I don't see a corresponding thing in the kernel.
Masahiro?  This dates back to the introduction of the Makefile and
that's you in the git log, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150306/e9e2371c/attachment.sig>

[U-Boot] 4K padding of ARM DT blob

[Masahiro Yamada]

Hi Yehuda, Tom, Simon,



2015-03-07 0:12 GMT+09:00 Tom Rini <trini@konsulko.com>:
> On Thu, Mar 05, 2015 at 06:20:35PM +0000, Yehuda Yitschak wrote:
>> Hey Tom
>>
>> In arch/arm/dts/Makfile: line 56
>> "DTC_FLAGS += -R 4 -p 0x1000"
>>
>> this tell the dtc tool to add a 4K padding to the device tree blob.
>>
>> i can't figure out why this is needed.
>> Its creating a 4KB penalty on the dtb file so i guess it has some justification.
>
> That's interesting and I don't see a corresponding thing in the kernel.
> Masahiro?  This dates back to the introduction of the Makefile and
> that's you in the git log, thanks!

Not me!
I just converted the Makefile into Kbuild style.


The option "-R 4 -p 0x1000" was introduced by:

commit bbb0b128c3956ac549471addc314702fbe0ace63
Author: Simon Glass <sjg@chromium.org>
Date:   Sat Oct 15 05:48:21 2011 +0000

    fdt: Add support for embedded device tree (CONFIG_OF_EMBED)


Simon,
Looks like the 4K padding was introduced by you.
Can you explain why?

Best Regards
Masahiro Yamada

[U-Boot] 4K padding of ARM DT blob

[Simon Glass]

Hi,

On 10 March 2015 at 23:48, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
> Hi Yehuda, Tom, Simon,
>
>
>
> 2015-03-07 0:12 GMT+09:00 Tom Rini <trini@konsulko.com>:
>> On Thu, Mar 05, 2015 at 06:20:35PM +0000, Yehuda Yitschak wrote:
>>> Hey Tom
>>>
>>> In arch/arm/dts/Makfile: line 56
>>> "DTC_FLAGS += -R 4 -p 0x1000"
>>>
>>> this tell the dtc tool to add a 4K padding to the device tree blob.
>>>
>>> i can't figure out why this is needed.
>>> Its creating a 4KB penalty on the dtb file so i guess it has some justification.
>>
>> That's interesting and I don't see a corresponding thing in the kernel.
>> Masahiro?  This dates back to the introduction of the Makefile and
>> that's you in the git log, thanks!
>
> Not me!
> I just converted the Makefile into Kbuild style.
>
>
> The option "-R 4 -p 0x1000" was introduced by:
>
> commit bbb0b128c3956ac549471addc314702fbe0ace63
> Author: Simon Glass <sjg@chromium.org>
> Date:   Sat Oct 15 05:48:21 2011 +0000
>
>     fdt: Add support for embedded device tree (CONFIG_OF_EMBED)
>
>
> Simon,
> Looks like the 4K padding was introduced by you.
> Can you explain why?

I think at the time perhaps we were thinking of modifying the FDT in
early U-Boot init, but that did not happen. I think it can be dropped.
Using my time machine I just sent a patch to do this a few weeks ago:

http://patchwork.ozlabs.org/patch/444847/

Regards,
Simon

[U-Boot] 4K padding of ARM DT blob

[Tom Rini]

On Wed, Mar 11, 2015 at 01:01:12PM -0600, Simon Glass wrote:
> Hi,
> 
> On 10 March 2015 at 23:48, Masahiro Yamada
> <yamada.masahiro@socionext.com> wrote:
> > Hi Yehuda, Tom, Simon,
> >
> >
> >
> > 2015-03-07 0:12 GMT+09:00 Tom Rini <trini@konsulko.com>:
> >> On Thu, Mar 05, 2015 at 06:20:35PM +0000, Yehuda Yitschak wrote:
> >>> Hey Tom
> >>>
> >>> In arch/arm/dts/Makfile: line 56
> >>> "DTC_FLAGS += -R 4 -p 0x1000"
> >>>
> >>> this tell the dtc tool to add a 4K padding to the device tree blob.
> >>>
> >>> i can't figure out why this is needed.
> >>> Its creating a 4KB penalty on the dtb file so i guess it has some justification.
> >>
> >> That's interesting and I don't see a corresponding thing in the kernel.
> >> Masahiro?  This dates back to the introduction of the Makefile and
> >> that's you in the git log, thanks!
> >
> > Not me!
> > I just converted the Makefile into Kbuild style.
> >
> >
> > The option "-R 4 -p 0x1000" was introduced by:
> >
> > commit bbb0b128c3956ac549471addc314702fbe0ace63
> > Author: Simon Glass <sjg@chromium.org>
> > Date:   Sat Oct 15 05:48:21 2011 +0000
> >
> >     fdt: Add support for embedded device tree (CONFIG_OF_EMBED)
> >
> >
> > Simon,
> > Looks like the 4K padding was introduced by you.
> > Can you explain why?
> 
> I think at the time perhaps we were thinking of modifying the FDT in
> early U-Boot init, but that did not happen. I think it can be dropped.
> Using my time machine I just sent a patch to do this a few weeks ago:
> 
> http://patchwork.ozlabs.org/patch/444847/

As part of your start-on-rockchip series (Thanks, btw) :)

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150311/bb1aeae9/attachment.sig>

[U-Boot] 4K padding of ARM DT blob

[Yehuda Yitschak]

Hey Simon 

Thanks for the clarification 

Just out of curiosity, how can the padding help modify the FDT in u-boot ?

Yehuda 

> -----Original Message-----
> From: sjg at google.com [mailto:sjg at google.com] On Behalf Of Simon Glass
> Sent: Wednesday, March 11, 2015 21:01
> To: Masahiro Yamada
> Cc: Tom Rini; Yehuda Yitschak; u-boot at lists.denx.de; Hanna Hawa
> Subject: Re: [U-Boot] 4K padding of ARM DT blob
> 
> Hi,
> 
> On 10 March 2015 at 23:48, Masahiro Yamada
> <yamada.masahiro@socionext.com> wrote:
> > Hi Yehuda, Tom, Simon,
> >
> >
> >
> > 2015-03-07 0:12 GMT+09:00 Tom Rini <trini@konsulko.com>:
> >> On Thu, Mar 05, 2015 at 06:20:35PM +0000, Yehuda Yitschak wrote:
> >>> Hey Tom
> >>>
> >>> In arch/arm/dts/Makfile: line 56
> >>> "DTC_FLAGS += -R 4 -p 0x1000"
> >>>
> >>> this tell the dtc tool to add a 4K padding to the device tree blob.
> >>>
> >>> i can't figure out why this is needed.
> >>> Its creating a 4KB penalty on the dtb file so i guess it has some
> justification.
> >>
> >> That's interesting and I don't see a corresponding thing in the kernel.
> >> Masahiro?  This dates back to the introduction of the Makefile and
> >> that's you in the git log, thanks!
> >
> > Not me!
> > I just converted the Makefile into Kbuild style.
> >
> >
> > The option "-R 4 -p 0x1000" was introduced by:
> >
> > commit bbb0b128c3956ac549471addc314702fbe0ace63
> > Author: Simon Glass <sjg@chromium.org>
> > Date:   Sat Oct 15 05:48:21 2011 +0000
> >
> >     fdt: Add support for embedded device tree (CONFIG_OF_EMBED)
> >
> >
> > Simon,
> > Looks like the 4K padding was introduced by you.
> > Can you explain why?
> 
> I think at the time perhaps we were thinking of modifying the FDT in early U-
> Boot init, but that did not happen. I think it can be dropped.
> Using my time machine I just sent a patch to do this a few weeks ago:
> 
> http://patchwork.ozlabs.org/patch/444847/
> 
> Regards,
> Simon

[U-Boot] 4K padding of ARM DT blob

[Masahiro Yamada]

Hi.

2015-03-12 15:46 GMT+09:00 Yehuda Yitschak <yehuday@marvell.com>:
> Hey Simon
>
> Thanks for the clarification
>
> Just out of curiosity, how can the padding help modify the FDT in u-boot ?

If you insert a new node/property, or change a property for a longer value,
the FDT blob will get longer.
So, you need some extra space for modification.
Otherwise, the U-Boot image will be overritten in case of CONFIG_OF_EMBED.

But, as Simon said, U-Boot never modifies a FDT that is used
to configure U-Boot itself.


Just in case, let me add a little more explanation:
What is confusing is, U-Boot can modify a FDT that is passed to the kernel.
U-Boot can have two different instances of FDTs: one for configuring
U-Boot and the other
for configuring Linux.
We are talking about the former in this thread.



Best Regards
Masahiro Yamada

[U-Boot] 4K padding of ARM DT blob

[Yehuda Yitschak]

Thanks Masahiro 

Actually, I am considering to modify u-boot's own FDT to reflect changes in configurable boards like development boards.
So maybe the padding is good for my needs after all  :)

Do you see any issue with such an approach ?

Thanks

Yehuda 

> -----Original Message-----
> From: Masahiro Yamada [mailto:yamada.masahiro at socionext.com]
> Sent: Thursday, March 12, 2015 10:10
> To: Yehuda Yitschak
> Cc: Simon Glass; Tom Rini; Hanna Hawa; u-boot at lists.denx.de
> Subject: Re: [U-Boot] 4K padding of ARM DT blob
> 
> Hi.
> 
> 2015-03-12 15:46 GMT+09:00 Yehuda Yitschak <yehuday@marvell.com>:
> > Hey Simon
> >
> > Thanks for the clarification
> >
> > Just out of curiosity, how can the padding help modify the FDT in u-boot ?
> 
> If you insert a new node/property, or change a property for a longer value,
> the FDT blob will get longer.
> So, you need some extra space for modification.
> Otherwise, the U-Boot image will be overritten in case of
> CONFIG_OF_EMBED.
> 
> But, as Simon said, U-Boot never modifies a FDT that is used to configure U-
> Boot itself.
> 
> 
> Just in case, let me add a little more explanation:
> What is confusing is, U-Boot can modify a FDT that is passed to the kernel.
> U-Boot can have two different instances of FDTs: one for configuring U-Boot
> and the other for configuring Linux.
> We are talking about the former in this thread.
> 
> 
> 
> Best Regards
> Masahiro Yamada

[U-Boot] 4K padding of ARM DT blob

[Masahiro Yamada]

Hi.


2015-03-12 17:58 GMT+09:00 Yehuda Yitschak <yehuday@marvell.com>:
> Thanks Masahiro
>
> Actually, I am considering to modify u-boot's own FDT to reflect changes in configurable boards like development boards.
> So maybe the padding is good for my needs after all  :)
>
> Do you see any issue with such an approach ?

Yes, depending on when you modify the FDT.

In Driver Model, most of drivers refer to the FDT when probing.
(The offset address is stored in the "of_offset" member of struct udevice.)

The scenario of our trouble is like this:

[1] Devices are bound by dm_init_and_scan().
    (udevice->of_offset is set)

[2] The FDT is modified.
    (The offset address to each node changes.)

[3] Some devices are probed
    (udevice->of_offset is referred, but the expected node is not there!)


I guess you can modify the FDT before [1] or after[3].

Simon,
What do you think?




-- 
Best Regards
Masahiro Yamada

[U-Boot] 4K padding of ARM DT blob

[Yehuda Yitschak]

Thanks a lot Masahiro

Yehuda

> -----Original Message-----
> From: Masahiro Yamada [mailto:yamada.masahiro at socionext.com]
> Sent: Thursday, March 12, 2015 11:50
> To: Yehuda Yitschak
> Cc: Tom Rini; Hanna Hawa; u-boot at lists.denx.de
> Subject: Re: [U-Boot] 4K padding of ARM DT blob
> 
> Hi.
> 
> 
> 2015-03-12 17:58 GMT+09:00 Yehuda Yitschak <yehuday@marvell.com>:
> > Thanks Masahiro
> >
> > Actually, I am considering to modify u-boot's own FDT to reflect changes in
> configurable boards like development boards.
> > So maybe the padding is good for my needs after all  :)
> >
> > Do you see any issue with such an approach ?
> 
> Yes, depending on when you modify the FDT.
> 
> In Driver Model, most of drivers refer to the FDT when probing.
> (The offset address is stored in the "of_offset" member of struct udevice.)
> 
> The scenario of our trouble is like this:
> 
> [1] Devices are bound by dm_init_and_scan().
>     (udevice->of_offset is set)
> 
> [2] The FDT is modified.
>     (The offset address to each node changes.)
> 
> [3] Some devices are probed
>     (udevice->of_offset is referred, but the expected node is not there!)
> 
> 
> I guess you can modify the FDT before [1] or after[3].
> 
> Simon,
> What do you think?
> 
> 
> 
> 
> --
> Best Regards
> Masahiro Yamada