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@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.