[U-Boot] libfdt: make fdt_increase_size() available to everyone
Timur Tabi
timur at freescale.com
Tue May 18 16:10:49 CEST 2010
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.
--
Timur Tabi
Linux kernel developer at Freescale
More information about the U-Boot
mailing list