[PATCH v2 0/5] bootm: Handle compressed arm64 images with bootm

[PATCH v2 0/5] bootm: Handle compressed arm64 images with bootm

[Simon Glass]

This little series corrects a problem I noticed with arm64 images,
where the kernel is not recognised if compression is used:

   U-Boot> tftp image.fit
   Using ethernet@7d580000 device
   TFTP from server 192.168.4.7; our IP address is 192.168.4.147
   Filename 'image.fit'.
   Load address: 0x1000000
   Loading: ##################################################  23 MiB
   	 20.5 MiB/s
   done
   Bytes transferred = 24118272 (1700400 hex)
   U-Boot> bootm
   ## Loading kernel from FIT Image at 01000000 ...
      Using 'conf-768' configuration
      Trying 'kernel' kernel subimage
        Description:  Linux
        Type:         Kernel Image (no loading done)
        Compression:  gzip compressed
        Data Start:   0x01000120
        Data Size:    13662338 Bytes = 13 MiB
      Verifying Hash Integrity ... OK
   Bad Linux ARM64 Image magic!

With this series:

   U-Boot> tftp 20000000 image.fit
   Using ethernet@7d580000 device
   TFTP from server 192.168.4.7; our IP address is 192.168.4.147
   Filename 'image.fit'.
   Load address: 0x20000000
   Loading: ##################################################  23.5 MiB
   	 20.8 MiB/s
   done
   Bytes transferred = 24642560 (1780400 hex)
   U-Boot> bootm 0x20000000
   ## Loading kernel from FIT Image at 20000000 ...
      Using 'conf-768' configuration
      Trying 'kernel' kernel subimage
        Description:  Linux
        Type:         Kernel Image (no loading done)
        Compression:  zstd compressed
        Data Start:   0x20000120
        Data Size:    14333475 Bytes = 13.7 MiB
      Verifying Hash Integrity ... OK
   Using kernel load address 80000
   ## Loading fdt from FIT Image at 20000000 ...
      Using 'conf-768' configuration
      Trying 'fdt-768' fdt subimage
        Description:  Raspberry Pi 4 Model B
        Type:         Flat Device Tree
        Compression:  zstd compressed
        Data Start:   0x215f820c
        Data Size:    9137 Bytes = 8.9 KiB
        Architecture: AArch64
      Verifying Hash Integrity ... OK
      Uncompressing Flat Device Tree to 3aff3010
      Booting using the fdt blob at 0x3aff3010
   Working FDT set to 3aff3010
      Uncompressing Kernel Image (no loading done) to 80000
   Moving Image from 0x80000 to 0x200000, end=2b00000
      Using Device Tree in place at 000000003aff3010, end 000000003afff4c4
   Working FDT set to 3aff3010

   Starting kernel ...

   [    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd083]

The problem is that the arm64 magic is checked before the image is
decompressed. However this is only part of it. The kernel_noload image
type should not be permitted with compression, so this series adds a
check for that.

Another issue is that the arm64 handling is done too early, before the
image is loaded. This series moves it to after loading, so that
compression can be handled.

This series also adjusts the 'load' address to be optional, since it is
often not possible to select a load address which can work with all
boards. We can use the kernel_addr_r environment variable instead.

A patch is included to show the kernel load-address, so it is easy to
see what is going on.

One annoying feature of arm64 is that the image is often copied to
another address. It might be possible for U-Boot to figure that out
earlier and decompress it to the right place, but perhaps not.

With all of this it should be possible to boot a compressed kernel on
any of the 990 arm64 boards supported by Linux, although I have only
tested two.

Changes in v2:
- Allow omitting the load address rather than messing with kernel_noload
- Rework the patch based on a better understanding of events
- Add a 'success' case to the cover letter
- Redo how the arm64 support is implemented

Simon Glass (5):
  image: Correct load_bug typo
  image: Show the load address when decompressing
  bootm: Allow omitting the load address
  bootm: Move arm64-image processing later
  boot: Don't allow kernel_noload with compression

 boot/bootm.c                         | 67 ++++++++++++++++++----------
 boot/image.c                         | 13 ++++--
 doc/usage/fit/source_file_format.rst |  7 ++-
 include/image.h                      |  2 +-
 4 files changed, 60 insertions(+), 29 deletions(-)

-- 
2.42.0.869.gea05f2083d-goog

[PATCH v2 1/5] image: Correct load_bug typo

[Simon Glass]

Correct a typo in the function comment for image_decomp().

Signed-off-by: Simon Glass <sjg@chromium.org>
---

(no changes since v1)

 include/image.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/image.h b/include/image.h
index 2e3cf839ee36..0fe67852c563 100644
--- a/include/image.h
+++ b/include/image.h
@@ -936,7 +936,7 @@ int image_decomp_type(const unsigned char *buf, ulong len);
  * @load:	Destination load address in U-Boot memory
  * @image_start Image start address (where we are decompressing from)
  * @type:	OS type (IH_OS_...)
- * @load_bug:	Place to decompress to
+ * @load_buf:	Place to decompress to
  * @image_buf:	Address to decompress from
  * @image_len:	Number of bytes in @image_buf to decompress
  * @unc_len:	Available space for decompression
-- 
2.42.0.869.gea05f2083d-goog

[PATCH v2 2/5] image: Show the load address when decompressing

[Simon Glass]

The destination address for decompression (or copying) is useful
information. Show this to the user while booting, e.g.:

   Uncompressing Kernel Image (no loading done) to 2080000

Signed-off-by: Simon Glass <sjg@chromium.org>
---

(no changes since v1)

 boot/image.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/boot/image.c b/boot/image.c
index 88b67bc3a199..675b5dd77f94 100644
--- a/boot/image.c
+++ b/boot/image.c
@@ -415,15 +415,20 @@ void image_print_contents(const void *ptr)
  * @type:	OS type (IH_OS_...)
  * @comp_type:	Compression type being used (IH_COMP_...)
  * @is_xip:	true if the load address matches the image start
+ * @load:	Load address for printing
  */
-static void print_decomp_msg(int comp_type, int type, bool is_xip)
+static void print_decomp_msg(int comp_type, int type, bool is_xip,
+			     ulong load)
 {
 	const char *name = genimg_get_type_name(type);
 
+	/* Shows "Loading Kernel Image" for example */
 	if (comp_type == IH_COMP_NONE)
-		printf("   %s %s\n", is_xip ? "XIP" : "Loading", name);
+		printf("   %s %s", is_xip ? "XIP" : "Loading", name);
 	else
-		printf("   Uncompressing %s\n", name);
+		printf("   Uncompressing %s", name);
+
+	printf(" to %lx\n", load);
 }
 
 int image_decomp_type(const unsigned char *buf, ulong len)
@@ -448,7 +453,7 @@ int image_decomp(int comp, ulong load, ulong image_start, int type,
 	int ret = -ENOSYS;
 
 	*load_end = load;
-	print_decomp_msg(comp, type, load == image_start);
+	print_decomp_msg(comp, type, load == image_start, load);
 
 	/*
 	 * Load the image to the right place, decompressing if needed. After
-- 
2.42.0.869.gea05f2083d-goog

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

[Simon Glass]

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

Changes in v2:
- Allow omitting the load address rather than messing with kernel_noload

 boot/bootm.c                         | 20 ++++++++++++++------
 doc/usage/fit/source_file_format.rst |  7 ++++++-
 2 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/boot/bootm.c b/boot/bootm.c
index cb61485c226c..aef9fad8ca13 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -177,10 +177,17 @@ static int bootm_find_os(struct cmd_tbl *cmdtp, int flag, int argc,
 		images.os.end = fit_get_end(images.fit_hdr_os);
 
 		if (fit_image_get_load(images.fit_hdr_os, images.fit_noffset_os,
-				       &images.os.load)) {
-			puts("Can't get image load address!\n");
-			bootstage_error(BOOTSTAGE_ID_FIT_LOADADDR);
-			return 1;
+				&images.os.load)) {
+			ulong load;
+
+			load = env_get_hex("kernel_addr_r", -1UL);
+			if (load == -1UL) {
+				puts("Can't get image load address!\n");
+				bootstage_error(BOOTSTAGE_ID_FIT_LOADADDR);
+				return 1;
+			}
+			printf("Using kernel load address %lx\n", load);
+			images.os.load = load;
 		}
 		break;
 #endif
@@ -230,8 +237,9 @@ static int bootm_find_os(struct cmd_tbl *cmdtp, int flag, int argc,
 		ret = fit_image_get_entry(images.fit_hdr_os,
 					  images.fit_noffset_os, &images.ep);
 		if (ret) {
-			puts("Can't get entry point property!\n");
-			return 1;
+			printf("Can't get entry point property, using load address %lx\n",
+			       images.os.load);
+			images.ep = images.os.load;
 		}
 #endif
 	} else if (!ep_found) {
diff --git a/doc/usage/fit/source_file_format.rst b/doc/usage/fit/source_file_format.rst
index b2b1e42bd730..f92738a9480a 100644
--- a/doc/usage/fit/source_file_format.rst
+++ b/doc/usage/fit/source_file_format.rst
@@ -234,6 +234,10 @@ type
     zynqmpimage           Xilinx ZynqMP Boot Image }
     ====================  ==================
 
+    The kernel_noload type indicates that the image is a kernel but that it
+    does not need to be loaded and can be executed in-place from the FIT. This
+    type cannot be used if compression is not "none".
+
 compression
     Compression used by included data. If no compression is used, the
     compression property should be set to "none". If the data is compressed but
@@ -353,7 +357,8 @@ entry
 load
     load address, address size is determined by '#address-cells'
     property of the root node.
-    Mandatory for types: "firmware", and "kernel".
+    This is normally mandatory for types: "firmware", and "kernel". However if
+    it omitted the bootloader may chose a suitable address.
 
 compatible
     compatible method for loading image.
-- 
2.42.0.869.gea05f2083d-goog

[PATCH v2 4/5] bootm: Move arm64-image processing later

[Simon Glass]

If the image is compressed, then the existing check fails, since the
header is wrong.

Move the check later in the boot process, after the kernel is
decompressed. This allows use of bootm with compressed kernels, while
still permitting an uncompressed kernel to be used.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

Changes in v2:
- Rework the patch based on a better understanding of events

 boot/bootm.c | 45 +++++++++++++++++++++++++++------------------
 1 file changed, 27 insertions(+), 18 deletions(-)

diff --git a/boot/bootm.c b/boot/bootm.c
index aef9fad8ca13..4c150e895f2f 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -248,24 +248,8 @@ static int bootm_find_os(struct cmd_tbl *cmdtp, int flag, int argc,
 	}
 
 	if (images.os.type == IH_TYPE_KERNEL_NOLOAD) {
-		if (IS_ENABLED(CONFIG_CMD_BOOTI) &&
-		    images.os.arch == IH_ARCH_ARM64 &&
-		    images.os.os == IH_OS_LINUX) {
-			ulong image_addr;
-			ulong image_size;
-
-			ret = booti_setup(images.os.image_start, &image_addr,
-					  &image_size, true);
-			if (ret != 0)
-				return 1;
-
-			images.os.type = IH_TYPE_KERNEL;
-			images.os.load = image_addr;
-			images.ep = image_addr;
-		} else {
-			images.os.load = images.os.image_start;
-			images.ep += images.os.image_start;
-		}
+		images.os.load = images.os.image_start;
+		images.ep += images.os.image_start;
 	}
 
 	images.os.start = map_to_sysmem(os_hdr);
@@ -474,6 +458,31 @@ static int bootm_load_os(struct bootm_headers *images, int boot_progress)
 		}
 	}
 
+	if (IS_ENABLED(CONFIG_CMD_BOOTI) && images->os.arch == IH_ARCH_ARM64 &&
+	    images->os.os == IH_OS_LINUX) {
+		ulong relocated_addr;
+		ulong image_size;
+		int ret;
+
+		ret = booti_setup(load, &relocated_addr, &image_size, false);
+		if (ret) {
+			printf("Failed to prep arm64 kernel (err=%d)\n", ret);
+			return BOOTM_ERR_RESET;
+		}
+
+		/* Handle BOOTM_STATE_LOADOS */
+		if (relocated_addr != load) {
+			printf("Moving Image from 0x%lx to 0x%lx, end=%lx\n",
+			       load, relocated_addr,
+			       relocated_addr + image_size);
+			memmove((void *)relocated_addr, load_buf, image_size);
+		}
+
+		images->ep = relocated_addr;
+		images->os.start = relocated_addr;
+		images->os.end = relocated_addr + image_size;
+	}
+
 	lmb_reserve(&images->lmb, images->os.load, (load_end -
 						    images->os.load));
 	return 0;
-- 
2.42.0.869.gea05f2083d-goog

[PATCH v2 5/5] boot: Don't allow kernel_noload with compression

[Simon Glass]

It is not possible to execute the kernel in-place without loading it.
Detect this and show an error, to avoid a crash.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

Changes in v2:
- Add a 'success' case to the cover letter
- Redo how the arm64 support is implemented

 boot/bootm.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/boot/bootm.c b/boot/bootm.c
index 4c150e895f2f..e3f5f81becd7 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -248,6 +248,10 @@ static int bootm_find_os(struct cmd_tbl *cmdtp, int flag, int argc,
 	}
 
 	if (images.os.type == IH_TYPE_KERNEL_NOLOAD) {
+		if (images.os.comp != IH_COMP_NONE) {
+			puts("Cannot use kernel_noload with compression\n");
+			return 1;
+		}
 		images.os.load = images.os.image_start;
 		images.ep += images.os.image_start;
 	}
-- 
2.42.0.869.gea05f2083d-goog

Re: [PATCH v2 5/5] boot: Don't allow kernel_noload with compression

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 300 bytes --]

On Sat, Nov 11, 2023 at 08:49:57PM -0700, Simon Glass wrote:

> It is not possible to execute the kernel in-place without loading it.
> Detect this and show an error, to avoid a crash.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

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

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3683 bytes --]

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:

> @@ -177,10 +177,17 @@ static int bootm_find_os(struct cmd_tbl *cmdtp, int flag, int argc,
>  		images.os.end = fit_get_end(images.fit_hdr_os);
>  
>  		if (fit_image_get_load(images.fit_hdr_os, images.fit_noffset_os,
> -				       &images.os.load)) {
> -			puts("Can't get image load address!\n");
> -			bootstage_error(BOOTSTAGE_ID_FIT_LOADADDR);
> -			return 1;
> +				&images.os.load)) {
> +			ulong load;
> +
> +			load = env_get_hex("kernel_addr_r", -1UL);
> +			if (load == -1UL) {
> +				puts("Can't get image load address!\n");
> +				bootstage_error(BOOTSTAGE_ID_FIT_LOADADDR);
> +				return 1;
> +			}
> +			printf("Using kernel load address %lx\n", load);
> +			images.os.load = load;

The load address shouldn't be what kernel_addr_r is set to, it should be
where exactly the kernel portion is in memory, right now. We don't move
it, it XIPs. That's what used to happen, and how we could avoid having
to put in a load address. And so long as we then later ensure it's
properly aligned for the underlying image, it should be fine.  _That_
however might be the harder case to deal with and then we need to
perhaps note-and-move (not warn, it'll be scary sounding for just a
memmove) as it's probably not the case that we've got the Image itself,
for aarch64, at a 2MiB aligned boundary. The FIT was probably loaded
there rather than 2MiB-sizeof(FIT header). And we need to not overwrite
other contents too.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH v2 1/5] image: Correct load_bug typo

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 237 bytes --]

On Sat, Nov 11, 2023 at 08:49:53PM -0700, Simon Glass wrote:

> Correct a typo in the function comment for image_decomp().
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

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

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2883 bytes --]

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.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH v2 2/5] image: Show the load address when decompressing

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 368 bytes --]

On Sat, Nov 11, 2023 at 08:49:54PM -0700, Simon Glass wrote:

> The destination address for decompression (or copying) is useful
> information. Show this to the user while booting, e.g.:
> 
>    Uncompressing Kernel Image (no loading done) to 2080000
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [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@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@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