[PATCH v2 3/5] bootm: Allow omitting the load address

[Simon Glass]

Hi Tom,

On Tue, 14 Nov 2023 at 11:04, Tom Rini <trini at konsulko.com> wrote:
>
> On Tue, Nov 14, 2023 at 11:38:46AM -0500, Tom Rini wrote:
> > On Sat, Nov 11, 2023 at 08:49:55PM -0700, Simon Glass wrote:
> >
> > > The kernel_noload image type indicates that no loading is to be done by
> > > U-Boot. This works well when the image is uncompressed.
> > >
> > > When the image is compressed, loading is of course required. The load
> > > address in the FIT is used for loading.
> > >
> > > However a FIT built from Linux v6.6 supports about 990 boards. Each has
> > > a different memory arrangement, so no one load address is suitable.
> > > Therefore the 'load' address in the kernel node is not useful.
> > >
> > > It would be better in this case to be able to omit the load address and
> > > have U-Boot choose something suitable. The kernel_addr_r environment
> > > variable seems to be a more reliable final address for the kernel. Use
> > > that as a backup when the load address is missing.
> > >
> > > Similarly, use the load address as the entry address when the latter is
> > > omitted.
> > >
> > > Update the FIT documentation accordingly.
> > >
> > > Note that mkimage still requires each image in a FIT to have a load
> > > address, at least for now.
> > >
> > > 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.
> > >
> > > It might perhaps be useful to introduce an 'entry-offset' property
> > > which allows the entry to be set as an offset from the load address,
> > > whether that is explicit or calculated.
> > >
> > > Signed-off-by: Simon Glass <sjg at chromium.org>
> >
> > OK, so I dug out what I was trying to determine before, and while I
> > might see if I can bisect down to when this regressed, it might be a
> > little hard given that my previously functional image is from 2013.
> >
> > What should happen in the case of kernel_noload, and why the later patch
> > to fail on kernel_noload + compression, is that we don't move the kernel
> > contents of the FIT. We don't need the load address to be set because
> > we're using it where it is. What happened before in the case of the
> > ramdisk, and more importantly device tree, is what I why I want to
> > bisect down to when my image stopped working. But:
>
> Well, it seems I was wrong. I was able to (with only minor difficulty)
> go back to v2013.04, which was just after I made the fitImage I was
> trying to test and it doesn't bootm as-is. So whereas I had thought we
> had a defined and working case for kernel_noload and FIT images as you
> describe them, that does not seem to be the case. So please disregard
> this and I will review the patch again in light of what I've confirmed
> now, sorry for the incorrect feedback here and in the other thread.

OK good. I was surprised too.

Regards,
Simon