From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Wed, 29 Apr 2015 11:46:05 -0400 Subject: [U-Boot] fastboot boot base address behaviour In-Reply-To: References: <20150422130447.GA16865@lukather> <20150429081208.GB6062@lukather> <20150429142534.GX16702@bill-the-cat> Message-ID: <20150429154605.GD16702@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Wed, Apr 29, 2015 at 09:30:17AM -0500, Rob Herring wrote: > On Wed, Apr 29, 2015 at 9:25 AM, Tom Rini wrote: > > On Wed, Apr 29, 2015 at 09:11:03AM -0500, Rob Herring wrote: > > > > [snip] > >> >> For arm64 Image, the image header defines the offset and u-boot must > >> >> load it to that offset or you won't boot. There's only 1 correct > >> >> address and 2^32 - 1 wrong addresses the boot.img could have. > >> > > >> > Ok, so the simplest thing to do would be to always relocate the kernel > >> > then. > >> > >> Probably so as it is likely smaller than the ramdisk and needing > >> decompression also (once we support arm64 Image.gz). > > > > Not to side-track things much but we "support" Image.gz today but yes as > > a two-step thing. I think there was some talk about trying to be clever > > enough to decompress the first page so we could peek at the Image > > header, see where things needed to end up, and then decompress to that > > location but it either wasn't feasible or more likely didn't get too > > high in priority. > > Is that documented how somewhere? Presumably it is load, gunzip, > booti? This would not work if contained within a boot.img. We'd need > the auto detect as you mention. That we have 'unzip' as a command? No, that's a little "hidden" I suppose, but it's enabled for Juno and the Xilinx ARMv8 platforms. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: