[U-Boot] fastboot boot base address behaviour

[Tom Rini <trini@konsulko.com>]

On Wed, Apr 29, 2015 at 09:30:17AM -0500, Rob Herring wrote:
> On Wed, Apr 29, 2015 at 9:25 AM, Tom Rini <trini@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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150429/5f9d814e/attachment.sig>