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