Dear Timur Tabi,
In message 4BF29FE9.1070305@freescale.com you wrote:
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.
Such an "ensure that there is enough room" is exactly what I'm asking for.
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.
Hm... it seems that not a single board uses this setting, which also happens to be completely undocumented.
So it appear to me that there are two ways the fdt is "allocated" in memory:
- It is copied to a location allocated via lmb_alloc_base() by
boot_relocate_fdt().
- 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.
For me lmb_alloc_base() is just another form of malloc()...
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'm not sure if we have the same intentions here.
I think, that for case #1 the available size is known, so we can check if we exceed the limits. And this is what we should do then.
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.
If we are talking about such substantial increments then it is all the more important to check for available room.
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.
No. We should check if the programmed value is sufficient.
Best regards,
Wolfgang Denk