Benjamin Herrenschmidt wrote: >> So to accommodate future boards where more padding is needed, we make the >> option for the -p parameter configurable. > > Can't u-boot just allocate more space ?
Yes and no. U-Boot has functions to increase the size of an fdt, but these functions can't be sure that the fdt will grow beyond its allocated space. So if U-Boot calls fdt_setprop() or fdt_add_subnode(), and there isn't enough space in the fdt, those functions will return with an error. The problem with growing the fdt is that the function which does this (fdt_open_into) cannot guarantee that the fdt will grow too large and overwrite the end of whatever allocated memory it's in. I had a long argument with Wolfgang on this (see "libfdt: make fdt_increase_size() available to everyone"), and he says he'll reject any patch that can't guarantee that fdt_open_into() won't grow too large. He'll also reject any patch that uses a macro constant to reserve this space, even if I use that constant to ensure that fdt_open_into() won't do anything bad. So in other words, U-Boot could allocate more space, but Wolfgang won't let it. -- Timur Tabi Linux kernel developer at Freescale _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev