[U-Boot] 4K padding of ARM DT blob
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@marvell.commailto:yehuday@marvell.com Office: +972.4.9091717 Fax: +972.4.9091501 Web site: http://www.marvell.comhttp://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. ________________________________
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!
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@jp.panasonic.com; u-boot@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
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!
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
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
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:
As part of your start-on-rockchip series (Thanks, btw) :)
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@google.com [mailto:sjg@google.com] On Behalf Of Simon Glass Sent: Wednesday, March 11, 2015 21:01 To: Masahiro Yamada Cc: Tom Rini; Yehuda Yitschak; u-boot@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
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
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@socionext.com] Sent: Thursday, March 12, 2015 10:10 To: Yehuda Yitschak Cc: Simon Glass; Tom Rini; Hanna Hawa; u-boot@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
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?
Thanks a lot Masahiro
Yehuda
-----Original Message----- From: Masahiro Yamada [mailto:yamada.masahiro@socionext.com] Sent: Thursday, March 12, 2015 11:50 To: Yehuda Yitschak Cc: Tom Rini; Hanna Hawa; u-boot@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
participants (4)
-
Masahiro Yamada -
Simon Glass -
Tom Rini -
Yehuda Yitschak