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

Kumar Gala
2010-05-20T13:34:06Z

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

> Dear Kumar Gala,
>
> In message <52E9D06A-E721-4907-9024-11BDC8D006E0@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