From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marian Balakowicz Date: Tue, 26 Feb 2008 10:11:47 +0100 Subject: [U-Boot-Users] [PATCH v2] [new uImage] ppc: Re-order ramdisk/fdt handling sequence In-Reply-To: <4B4442D1-A5EE-4B25-90C3-E57B1D71CCDC@kernel.crashing.org> References: <47B9C5BD.6030409@ge.com> <47B9D969.2080807@ge.com> <47B9E092.608@ge.com> <8B11A571-3BC2-42BD-9B66-DF22A736A3A7@kernel.crashing.org> <47BEEB06.7050405@semihalf.com> <47BEF33A.40506@ge.com> <47BF0194.8080501@semihalf.com> <4B4442D1-A5EE-4B25-90C3-E57B1D71CCDC@kernel.crashing.org> Message-ID: <47C3D7D3.7090107@semihalf.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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.