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

[Scott Wood <scottwood@freescale.com>]

On 05/26/2010 12:56 PM, Timur Tabi wrote:
> Scott Wood wrote:
>> On Wed, May 26, 2010 at 11:38:27AM -0500, Timur Tabi wrote:
>>> I believe we should have a board-specific function that figures out how much
>>> extra space is needed, and just returns a single integer that the
>>> boot_relocate_fdt() uses to pad the FDT when it relocates it.
>>
>> Why don't we just grow the FDT on demand, after we make sure that it always
>> lives someplace that is safely growable?
>
> We use lmb regions to allocate space for the fdt in the bootmap, so we need
> to know how big the lmb region should be before we allocate it.

But you can reasonably allocate significantly more than you'll need 
without actually causing the fdt to get that big.  The actual cap could 
be a board specific magic number (like CONFIG_SYS_MALLOC_LEN), or we 
could cap it at something based on the amount of RAM.

> Resizing an
> lmb region will probably require moving it, and that might confuse the
> upper-level functions that expect the fdt pointer to remain constant.
>
>> Or if we absolutely must resize it all at once, have a variable that
>> contains the size required, which gets increased by whatever init code
>> determines a reason for it (whether it be QE firmware in this environment
>> variable, some other firmware in that environment variable, just a bunch of
>> nodes that u-boot creates on this platform, etc).
>
> The issue is that how those functions will look.

What functions?  I'm just talking about arbitrary code that runs before 
the fdt is resized, and after relocation (or even before if we make it a 
gd_t variable), and adds a certain amount to a variable.

> Kumar and I are advocating
> a board-specific weak function that figures it all out at once and returns a
> single number.

That seems an awkward combination of centralization (you need to combine 
every fdt-expanding feature found on a board into the board file) and 
decentralization (if such a feature is added or changed you may need to 
update a bunch of board files).

-Scott