Re: [PATCH 0/4] bootm: Handle compressed arm64 images with bootm

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 2768 bytes --]

On Tue, Nov 07, 2023 at 05:23:05AM -0700, Simon Glass wrote:
> Hi Rasmus,
> 
> On Tue, 7 Nov 2023 at 02:56, Rasmus Villemoes
> <rasmus.villemoes@prevas.dk> wrote:
> >
> > On 05/11/2023 21.03, Simon Glass wrote:
> > > This little series corrects a problem I noticed with arm64 images,
> > > where the kernel is not recognised:
> >
> > The $subject is misleading, bootm works just fine with compressed arm64
> > images, with the type set to "kernel".
> >
> > >         Type:         Kernel Image (no loading done)
> > >         Compression:  gzip compressed
> >
> > Isn't that a non-sensical combination to begin with? Decompressing the
> > Image.gz kernel image to any location (however you determine that
> > destination) _is_ loading it.
> 
> Yes, I agree.
> 
> >
> > If you want XIP, obviously the image must be uncompressed in the FIT. I
> > don't understand what you're trying to do here.
> 
> Hmmm, I think I have just got confused about all of this, perhaps
> because ChromeOS uses kernel_noload with compression. Is that an
> invalid combination?

Yes, that sounds like an invalid combination.

> But then how does loading actually work? We don't want to put the load
> address in the FIT, since we don't know what it is...we want to use
> the address provided by the board. Which is kernel_noload...so how
> should this be implemented?

What do you mean, provided by the board? With kernel_noload we XIP the
payload, because the board provided (by loading us to) a safe place to
execute whatevers in there. In the olden days, that would mean (almost
certainly) the zImage which in turn was already compressed and
self-relocating. I know technically one could use the raw vmlinux
instead. With the Linux Kernel and ARCH=arm64 (and a few other arches
now too), they dropped the self-decompression part and the whole payload
must be decompressed. We handle this case in "booti" today by having to
have the board (via environment) say where to decompress to (and how
much space is available). Then we move it back to where we started from,
which is likely not necessary.

Looking at
https://www.kernel.org/doc/html/latest/arch/arm64/booting.html and
https://www.kernel.org/doc/html/latest/riscv/boot-image-header.html
stating "we're just like arm64" we can do better than we do today for
this format of OS image. If aren't compressed, we only need to ensure
that we are correctly aligned and move (and tell the user) if not. We
can even put the 2MB check under some legacy kernel CONFIG option (3.17
is over 9 years old). With respect to automatic decompression, if we
don't have something telling us where a buffer is and we can't pull from
the environment, we should tell the user and stop?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]