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

[Kumar Gala]

On May 19, 2010, at 5:06 PM, Wolfgang Denk wrote:

> Dear Kumar Gala,
> 
> In message <52E9D06A-E721-4907-9024-11BDC8D006E0 at kernel.crashing.org> you wrote:
>> So I tried to read this whole thread and got lost in the discussion.
>> I'm wondering of something along the following lines would address your
>> concerns:
> 
> My concerns are simple: if we need to increase the size of the FDT
> because we pull in some random amountof data, we should make sure to
> have enough room for this, or fail with a clear error message. 
> 
> And we should not try to use fixed sized buffers, but instead adapt
> to the actual amount required by the end user.
> 
> Timur assumes that all such code and it's sizess will be known in
> advance, and I disagree - other users will have other ideas what they
> can do with this, and his assumptions will break.
> 
>> #define CONFIG_SYS_FDT_PAD 0x3000
> 
> Where exactly is this 0x3000 coming from?

I think this was done to manage some growth of the dtb based on board fix ups.  However, not sure where the number came from.


>> /* Allow for arch specific config before we boot */
>> int __fdt_board_size(void)
>> {
>> 	return CONFIG_SYS_FDT_PAD;
>> }
>> int fdt_board_size(void) __attribute__((weak, alias("__
>> fdt_board_size")));
>> 
>> 
>> int boot_relocate_fdt (struct lmb *lmb, ulong bootmap_base,
>>                char **of_flat_tree, ulong *of_size)
>> {
>> ...
>> 
>>        if ((fdt_blob + *of_size + fdt_board_size()) >=
>>                        ((char *)CONFIG_SYS_BOOTMAPSZ + bootmap_base))
>>                relocate = 1;
>> 
>> ...
>> }
>> 
>> Than board specific code knows what fix ups might happen and can
>> implement dynamic behavior and do something like:
> 
> If any board specific code can determine the needed sizes, then how
> would such code differ from one board to another?
> 
> Why would this in any way be a board specific implementation? This
> makes no sense to me. The feature to include some binary data into the
> DTB is IMO in no way dependent on or specific to a certain board.

I agree this isn't 100% board specific, but my intent was to leave it under the board control.  One assumes the board knows if it needs firmware blob A in dtb or not.

It follows the same logic as why we have ft_board_setup.

- k