[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