Wolfgang Denk wrote:
Assume the case that the DTB is stored in NOR flash, and I pass the NOR flash address to the bootm command...
I'm not sure if there is any guarantee for free room behind the DTB in this case.
We can never guarantee this. The code that calls fdt_increase_size() will just have to ensure that there is enough room.
If the fdt is in NOR flash, then boot_relocate_fdt() will copy it to RAM via lmb_alloc_base(), which uses CONFIG_SYS_FDT_PAD to determine how much extra room is needed.
So it appear to me that there are two ways the fdt is "allocated" in memory:
1) It is copied to a location allocated via lmb_alloc_base() by boot_relocate_fdt().
2) It is simply placed somewhere in memory (via tftp) and left there.
I don't believe we ever use malloc() to allocate the memory for the fdt, so these two should cover 100% of all cases.
So for case #1, we can use CONFIG_SYS_FDT_PAD. For case #2, we just have to assume that when the user did "tftp c0000 my.dtb", that he knows what he's doing.
I assume that fdt_increase_size() will only be used to increase the available space by a significant amount. One example of this (and the reason I posted this patch in the first place), is to embed firmware inside the device tree. A new binding for Freescale QE firmware allows for this, and I have code in-house which implements this.
So I say that a particular board will know whether it needs to significantly expand the available amount of RAM beyond the default CONFIG_SYS_FDT_PAD. Therefore, we can define a new value of CONFIG_SYS_FDT_PAD in the board header files for those boards that need it.
I believe that this should cover everything, and that my patch is okay and should be merged in.