On Wed, Apr 29, 2015 at 09:30:17AM -0500, Rob Herring wrote: > On Wed, Apr 29, 2015 at 9:25 AM, Tom Rini <tr...@konsulko.com> 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
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
