[PATCH 1/4] bootm: Allow ignoring the load address with kernel_noload

[Simon Glass]

Hi Tom,

On Mon, 6 Nov 2023 at 13:15, Tom Rini <trini at konsulko.com> wrote:
>
> On Mon, Nov 06, 2023 at 12:58:46PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> >
> > On Mon, 6 Nov 2023 at 11:30, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Mon, Nov 06, 2023 at 10:25:00AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Sun, 5 Nov 2023 at 14:19, Tom Rini <trini at konsulko.com> wrote:
> > > > >
> > > > > On Sun, Nov 05, 2023 at 01:03:51PM -0700, Simon Glass wrote:
> > > > >
> > > > > > This image type is supposed to ignore the load address. But at present
> > > > > > it fails if the load address is missing. If it is zero, the image is
> > > > > > loaded at address 0, which may not work on all boards.
> > > > > >
> > > > > > Make use of the kernel_addr_r environment variable, instead, since this
> > > > > > seems to be a more reliable final address for the kernel.
> > > > > >
> > > > > > Another option would be to create a new Kconfig for this, or to use a
> > > > > > region of memory known to be free, e.g. calculated from the DRAM banks.
> > > > > > But in any case we should try to avoid conflicting with the
> > > > > > kernel_addr_r variable. So the approach in this patch seems reasonable
> > > > > > to me.
> > > > > >
> > > > > > Signed-off-by: Simon Glass <sjg at chromium.org>
> > > > >
> > > > > How are you creating the image in question here? A noload FIT is
> > > > > supposed to just supposed to go from where it is. Where do things fall
> > > > > down later?
> > > >
> > > > The image is Image.gz built by Linux, for example. So compression =
> > > > "gzip" which means that it has to be decompressed.
> > > >
> > > > Things fall down as soon as U-Boot looks at the image, since it
> > > > doesn't have the ARM64 magic.
> > >
> > > Can you provide logs and env? "booti" is supposed to handle this case
> > > already, and if it's not we should figure out when / why it broke.
> >
> > Do you mean booti handles compression? Yes, I can see that in the code.
>
> Yes, you use "booti" with an Image.gz.
>
> > But in my case I am using bootm, since it is a FIT.
>
> Shouldn't this be handled by the normal compression = "foo" logic? And in
> turn is that what's not working? If so, the commit messages aren't
> clear.

We are on the wrong commit here. See this one:

https://patchwork.ozlabs.org/project/uboot/patch/20231105130351.2.Ie34b75c75347a1c04bffa780220afe9011b0e2bb@changeid/

Perhaps this is supposed to work some other way, but to me it seems
quite broken at present.

Regards,
Simon