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?
/* 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.
Best regards,
Wolfgang Denk