Scott Wood wrote: > David Gibson wrote: >>> How hard would it be to get libfdt to dynamically allocate any extra space >>> it needs? This is a regression from the current flat device tree code... >> Uh.. it already does. Or rather, the shims in libfdt-wrapper.c do so, >> when libfdt functions which can expand the tree report that they've >> run out of room. > > Ah, good -- I was looking in libfdt itself, not the wrapper. Now if > only we could get something similar into u-boot... maybe libfdt proper > could accept an optional realloc() function pointer in fdt_init(), and > eliminate the need for the caller to provide such a wrapper? > > -Scott
Hi Scott, My concern from the u-boot side is that u-boot has to know exactly *where* to put the expanded blob because it has to pass it to linux and keep it out of linux' way so it doesn't get "stepped on." Linux has an advantage in that it "owns" all of memory and can allocate and deallocate whatever and wherever and it won't step on itself (hopefully). I'm assuming your boot wedge has the advantage of being able to use linux's malloc() and thus don't have to worry about coordinating with linux on memory allocation. With the current u-boot fdt command, you can resize the blob, and this can be done in a script with all the (somewhat limited) capabilities of the u-boot shell (an adaptation of hush). In the u-boot world, we fixate on memory maps and putting things in specific places. Maybe I'm making a problem where one doesn't exist, but an arbitrary malloc() in u-boot (as opposed to linux's malloc) seems like a Bad Thing[tm] because it is uncontrolled and may end up in a very bad place when linux starts (e.g. the linux start up script expands linux on top of the blob). Best regards, gvb _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
