Hi Tom, On Tue, 14 Nov 2023 at 11:04, Tom Rini <tr...@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 <s...@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
