Kumar Gala wrote: > > On Feb 22, 2008, at 11:08 AM, Marian Balakowicz wrote: ... >> >> If we add LMB and rework bootm memory allocation, putting things >> (kernel, cmdline, kdb, initrd (optionally), fdt) in sequence starting >> from bootm_low then we may want to always relocate fdt to avoid >> overlapping. And, in case of new uImage FDT blob will be embedded in a >> new uImage shell which is a blob itself. So, in this case in-place >> resizing is not really a clean option, we would need to resize the >> embedding new uImage blob first, and this one may have significant size, >> so I suspect it may impact performance. > > I felt the sequence (on PPC) is either: > kernel, cmdline, kdb, initrd > > or > > kernel, fdt, initrd > > The reason being is that initrd doesn't need to be constrained to > BOOTMAPSZ but cmdline, kdb, and fdt would/should be.
That's right. My point was just to have two steps: 1) Move all the stuff to the final locations (whatever the sequence) - kernel - fdt - *always* relocate to within BOOTMAPSZ, increase size dynamically. fdt blob can be delivered using of the three different methods: (1) raw fdt blob, (2) fdt blob embedded in legacy format uImage, (3) fdt blob embedded in new uImage format. To simplify things always relocate it to a allocated spot within BOOTMAPSZ. - initrd - within or outside of the BOOTMAPSZ boundaries 2) Update fdt blob, knowing we have enough free blob space: set initrd params, other fixups, etc. With such approach we don't need special treatment for initrd,start/initrd,end (and other fixups). We assure that there is enough free space in fdt blob when we relocate it. m. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
