[U-Boot] libfdt: make fdt_increase_size() available to everyone

[Wolfgang Denk]

Dear Timur Tabi,

In message <4BF29FE9.1070305 at 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:
> 
> 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.

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If in any problem you find yourself doing an immense amount of  work,
the answer can be obtained by simple inspection.