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

[Timur Tabi]

Scott Wood wrote:

> 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.

We have something like that already:

#ifndef CONFIG_SYS_FDT_PAD
#define CONFIG_SYS_FDT_PAD 0x3000
#endif

And Wolfgang doesn't like it.

I was going to do this in my board header file:

#define CONFIG_SYS_MAX_QE_FW_SIZE	0x4000

#define CONFIG_SYS_FDT_PAD (0x3000 + CONFIG_SYS_MAX_QE_FW_SIZE)

And I was even going to add code to the QE firmware functions to verify that
the firmware is not larger than CONFIG_SYS_MAX_QE_FW_SIZE.

>> 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.

Actually, that would be *during* relocation because we relocate and resize
the fdt in the same function: fdt_open_into().

Depending on the nature of the firmware, we may not know anything about the
firmware until we try to boot Linux, so we need to decide where this
arbitrary code is supposed to exist.

>> 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).

We could have feature-specific functions that do the work of handling the
fdt size for a specific feature.  So qe_firmware_size(void *) would tell you
the size of the QE firmware, and your board's fdt_board_size() would just be
a front-end to qe_firmware_size().

Are you suggesting that we implement some user interface where the user, on
the command line, can specify any number and type of firmware binaries to
get embedded in the device tree?

-- 
Timur Tabi
Linux kernel developer at Freescale