[U-Boot] FDT: Question about embedded fdt enable

[Stephen Warren <swarren@wwwdotorg.org>]

On 05/30/2012 08:26 AM, Simon Glass wrote:
> Hi Donghwa,
> 
> On Wed, May 30, 2012 at 12:37 AM, Donghwa Lee <dh09.lee@samsung.com> wrote:
...
>> And I have one more question about passing *.dtb to kernel.
>> I had make a .dtb binary by using CONFIG_OF_SEPARATE and confirmed
>> normally working in u-boot.
>> When kernel is booting, how could kernel access .dtb binary?
>> Could kernel access dtb binary by setting /memreserve/ in u-boot .dts file
>> or by using "fdtaddrcontrol"
>> environment variable in u-boot board file?
>> But, by my result, dt_phys address in setup_machine_fdt() in
>> arch/arm/devtree.c had always indicated only
>> one point regardless of /memreserve/ or fdtcontroladdr.
>>
> 
> Please be very careful - this is a completely separate FDT. The use of
> CONFIG_OF_CONTROL is for U-Boot's internal configuration only. The same FDT
> should not be passed to Linux in the normal case. Please continue to use
> the existing FDT support for passing a .dtb file to the kernel.
> 
> So you have an FDT for U-Boot which is available via CONFIG_OF_SEPARATE,
> and an FDT which U-Boot passes to the kernel, which is read using the
> normal uImage/Fit image method.

I echo this sentiment.

There is a very strong desire in the kernel community that the .dtb file
and the kernel image be stored in similar ways - e.g. they both be
stored as files in a /boot filesystem, or both be stored as specific
partitions in some flash. The reason for this is so that both the kernel
and .dtb image can be updated in the exact same way at the same time,
and without changing the bootloader/firmware/... in any way at all. This
allows kernel upgrades that rely on .dtb upgrades, and furthermore, it
allows that without updating the firmware/bootloader, which may be risky
in some cases.