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

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20231114/ade3454e/attachment.sig>