[U-Boot] [U-boot] CONFIG_FIT and CONFIG_OF_LIBFDT
Hi, experts:
I have a question about supporting FDT in uboot.
1. If i want to provide FDT support function in uboot code, just need to :
Define CONFIG_OF_LIBFDT in vendor_config.h
If my uImage is still a single component image, not need to define CONFIG_FIT at the same time?
Best wishes,
On Fri, Aug 23, 2013 at 02:36:23PM +0800, TigerLiu@viatech.com.cn wrote:
Hi, experts:
I have a question about supporting FDT in uboot.
- If i want to provide FDT support function in uboot code, just need to
:
Define CONFIG_OF_LIBFDT in vendor_config.h
If my uImage is still a single component image, not need to define CONFIG_FIT at the same time?
CONFIG_FIT and CONFIG_OF_LIBFDT are indeed unrelated options. You can use DT files with legacy images and plain zImages as well.
Hi, Rini:
CONFIG_FIT and CONFIG_OF_LIBFDT are indeed unrelated options. You can use DT files with legacy images and plain zImages as well.
Thanks for your reply!
I also have a question about CONFIG_OF_CONTROL. If CONFIG_OF_CONTROL is defined, then Uboot will use FDT to configure device. But based on README, it said: This option is experimental and only available on a few boards.
So, most currently released u-boot binary still didn't use FDT to configure device during uboot posting phase? Just use FDT as kernel parameter passed to linux kernel's entry point?
Best wishes,
On Mon, Aug 26, 2013 at 10:40:27AM +0800, TigerLiu@viatech.com.cn wrote:
Hi, Rini:
CONFIG_FIT and CONFIG_OF_LIBFDT are indeed unrelated options. You can use DT files with legacy images and plain zImages as well.
Thanks for your reply!
I also have a question about CONFIG_OF_CONTROL. If CONFIG_OF_CONTROL is defined, then Uboot will use FDT to configure device. But based on README, it said: This option is experimental and only available on a few boards.
So, most currently released u-boot binary still didn't use FDT to configure device during uboot posting phase?
Correct. Only a few drivers have been converted at this time. Frankly, I would like to see things stabilize within the kernel a bit more, make sure people really are happy with the bindings they need for a particular thing, and then we can see about using them again in U-Boot.
Just use FDT as kernel parameter passed to linux kernel's entry point?
That is one use, yes. But that may or may not be a recommended way to store the FDT for a platform (based on some discussion on the devicetrees mailing list, while there's no formal recommendations yet, having the shipped with platform FDT be done in such a way that it can be updated is strongly encouraged, possibly without having to replace the rest of the firmware as that's seen as a possible way to brick the hardware).
If you're planning on shipping hardware soon, with a device tree embedded within it, I would strongly encourage talking with devicetrees@vger.kernel.org about how to best do it, for your platform.
Hi,Rini: Thanks for your reply!
Just use FDT as kernel parameter passed to linux kernel's entry
point?
That is one use, yes. But that may or may not be a recommended way to store the FDT for a platform (based on some discussion on the devicetrees mailing list, while there's no formal recommendations yet, having the shipped with platform FDT be done in such a way that it can be updated is strongly encouraged, possibly without having to replace the rest of the firmware as that's seen as a possible way to brick the hardware).
If you're planning on shipping hardware soon, with a device tree embedded within it, I would strongly encourage talking with devicetrees@vger.kernel.org about how to best do it, for your platform.
So, based on your experience: Do most ARM SOC production vendors adopt which way to store dtb binary?
I think storing dtb binary into a dedicated nv-storage(such as : some blocks in NAND chip) is a better way.
Best wishes,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/26/2013 09:32 PM, TigerLiu@viatech.com.cn wrote:
Hi,Rini: Thanks for your reply!
Just use FDT as kernel parameter passed to linux kernel's entry
point?
That is one use, yes. But that may or may not be a recommended way to store the FDT for a platform (based on some discussion on the devicetrees mailing list, while there's no formal recommendations yet, having the shipped with platform FDT be done in such a way that it can be updated is strongly encouraged, possibly without having to replace the rest of the firmware as that's seen as a possible way to brick the hardware).
If you're planning on shipping hardware soon, with a device tree embedded within it, I would strongly encourage talking with devicetrees@vger.kernel.org about how to best do it, for your platform.
So, based on your experience: Do most ARM SOC production vendors adopt which way to store dtb binary?
I think storing dtb binary into a dedicated nv-storage(such as : some blocks in NAND chip) is a better way.
The best way to do it is something being actively discussed as today not many vendors do but we're rapidly approaching the point where vendors ship hardware with kernels that use DT for most things so the problem needs to be solved, or at least recommendations made.
- -- Tom
participants (2)
-
TigerLiu＠viatech.com.cn -
Tom Rini