[PATCH v2 0/3] booti: Remove the SYS_BOOTM_LEN limit for booti

[PATCH v2 0/3] booti: Remove the SYS_BOOTM_LEN limit for booti

[Simon Glass]

This series restores the original behaviour of extlinux booting linux
'Image' files, which is to ignore CONFIG_SYS_BOOTM_LEN and instead uses
a limit of 10x the compressed size.

It also adds RISC-V support, since it uses a similar format to ARM64.

Future work should integrate the code in 'booti' into main 'bootm'
logic.

Changes in v2:
- Change the commit subject so it doesn't mention ignoring SYS_BOOTM_LEN

Simon Glass (3):
  boot: Add a function to check if a linux Image is supported
  bootm: Add RISC-V support in booti_is_supported()
  booti: Allow using 10x the uncompressed size with booti

 boot/bootm.c    | 31 +++++++++++++++++++++++++------
 cmd/booti.c     |  1 +
 include/bootm.h |  3 +++
 3 files changed, 29 insertions(+), 6 deletions(-)

-- 
2.43.0

base-commit: d755a928c802f9807abb5270d80c4b25aefefc1d
branch: fix-booti2

[PATCH v2 1/3] boot: Add a function to check if a linux Image is supported

[Simon Glass]

Move this logic into a function so we can give it a sensible name.

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

(no changes since v1)

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

diff --git a/boot/bootm.c b/boot/bootm.c
index 0e63dd4adf3..2ed78295ead 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -654,6 +654,21 @@ static int handle_decomp_error(int comp_type, size_t uncomp_size,
 #endif
 
 #ifndef USE_HOSTCC
+
+/**
+ * booti_is_supported() - Check whether a Linux 'Image' is supported
+ *
+ * @os: OS to check
+ * Return: true if CMD_BOOTI is enabled and the arch suports this format
+ */
+static bool booti_is_supported(struct image_info *os)
+{
+	if (!IS_ENABLED(CONFIG_CMD_BOOTI) || os->os != IH_OS_LINUX)
+		return false;
+
+	return os->arch == IH_ARCH_ARM64;
+}
+
 static int bootm_load_os(struct bootm_headers *images, int boot_progress)
 {
 	struct image_info os = images->os;
@@ -729,8 +744,7 @@ 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) {
+	if (booti_is_supported(&images->os)) {
 		ulong relocated_addr;
 		ulong image_size;
 		int ret;
-- 
2.43.0

Re: [PATCH v2 1/3] boot: Add a function to check if a linux Image is supported

[Tom Rini]

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

On Thu, May 01, 2025 at 07:18:33AM -0600, Simon Glass wrote:

> Move this logic into a function so we can give it a sensible name.
> 
> 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 --]

[PATCH v2 2/3] bootm: Add RISC-V support in booti_is_supported()

[Simon Glass]

RISC-V uses a similar linux 'Image' format to ARM64, so add support for
it in bootm_load_os()

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

(no changes since v1)

 boot/bootm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/boot/bootm.c b/boot/bootm.c
index 2ed78295ead..7be5ec796fc 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -666,7 +666,7 @@ static bool booti_is_supported(struct image_info *os)
 	if (!IS_ENABLED(CONFIG_CMD_BOOTI) || os->os != IH_OS_LINUX)
 		return false;
 
-	return os->arch == IH_ARCH_ARM64;
+	return os->arch == IH_ARCH_ARM64 || os->arch == IH_ARCH_RISCV;
 }
 
 static int bootm_load_os(struct bootm_headers *images, int boot_progress)
-- 
2.43.0

Re: [PATCH v2 2/3] bootm: Add RISC-V support in booti_is_supported()

[Tom Rini]

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

On Thu, May 01, 2025 at 07:18:34AM -0600, Simon Glass wrote:

> RISC-V uses a similar linux 'Image' format to ARM64, so add support for
> it in bootm_load_os()
> 
> 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 --]

[PATCH v2 3/3] booti: Allow using 10x the uncompressed size with booti

[Simon Glass]

The booti command does not use the CONFIG_SYS_BOOTM_LEN value and
instead sets a maximum decompression-buffer size of 10x the size of the
compressed data.

Add this as an option in bootm_load_os() so that booting without the
command-line works in the same way as the 'booti' command.

Link: https://lore.kernel.org/u-boot/2ad3b1c5-b6e7-47e2-b225-834b821cc5c4@kwiboo.se/

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Fixes: b13408021d3 ("boot: pxe: Use bootm_...() functions where possible")
---

Changes in v2:
- Change the commit subject so it doesn't mention ignoring SYS_BOOTM_LEN

 boot/bootm.c    | 13 +++++++++----
 cmd/booti.c     |  1 +
 include/bootm.h |  3 +++
 3 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/boot/bootm.c b/boot/bootm.c
index 7be5ec796fc..dae09060f0f 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -669,8 +669,9 @@ static bool booti_is_supported(struct image_info *os)
 	return os->arch == IH_ARCH_ARM64 || os->arch == IH_ARCH_RISCV;
 }
 
-static int bootm_load_os(struct bootm_headers *images, int boot_progress)
+static int bootm_load_os(struct bootm_info *bmi, int boot_progress)
 {
+	struct bootm_headers *images = bmi->images;
 	struct image_info os = images->os;
 	ulong load = os.load;
 	ulong load_end;
@@ -681,6 +682,7 @@ static int bootm_load_os(struct bootm_headers *images, int boot_progress)
 	ulong flush_start = ALIGN_DOWN(load, ARCH_DMA_MINALIGN);
 	bool no_overlap;
 	void *load_buf, *image_buf;
+	ulong decomp_len;
 	int err;
 
 	/*
@@ -706,11 +708,12 @@ static int bootm_load_os(struct bootm_headers *images, int boot_progress)
 
 	load_buf = map_sysmem(load, 0);
 	image_buf = map_sysmem(os.image_start, image_len);
+	decomp_len = bmi->ignore_bootm_len ? image_len * 10 : bootm_len();
 	err = image_decomp(os.comp, load, os.image_start, os.type,
-			   load_buf, image_buf, image_len, bootm_len(),
+			   load_buf, image_buf, image_len, decomp_len,
 			   &load_end);
 	if (err) {
-		err = handle_decomp_error(os.comp, load_end - load, bootm_len(),
+		err = handle_decomp_error(os.comp, load_end - load, decomp_len,
 					  err);
 		bootstage_error(BOOTSTAGE_ID_DECOMP_IMAGE);
 		return err;
@@ -1073,7 +1076,7 @@ int bootm_run_states(struct bootm_info *bmi, int states)
 	if (!ret && (states & BOOTM_STATE_LOADOS)) {
 		iflag = bootm_disable_interrupts();
 		board_fixup_os(&images->os);
-		ret = bootm_load_os(images, 0);
+		ret = bootm_load_os(bmi, 0);
 		if (ret && ret != BOOTM_ERR_OVERLAP)
 			goto err;
 		else if (ret == BOOTM_ERR_OVERLAP)
@@ -1237,6 +1240,8 @@ int bootz_run(struct bootm_info *bmi)
 
 int booti_run(struct bootm_info *bmi)
 {
+	bmi->ignore_bootm_len = true;
+
 	return boot_run(bmi, "booti", BOOTM_STATE_START | BOOTM_STATE_FINDOS |
 			BOOTM_STATE_PRE_LOAD | BOOTM_STATE_FINDOTHER |
 			BOOTM_STATE_LOADOS);
diff --git a/cmd/booti.c b/cmd/booti.c
index 43e79e87201..f4f782da056 100644
--- a/cmd/booti.c
+++ b/cmd/booti.c
@@ -118,6 +118,7 @@ int do_booti(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
 		bmi.conf_fdt = argv[2];
 	bmi.boot_progress = true;
 	bmi.cmd_name = "booti";
+	bmi.ignore_bootm_len = true;
 	/* do not set up argc and argv[] since nothing uses them */
 
 	if (booti_start(&bmi))
diff --git a/include/bootm.h b/include/bootm.h
index 82ab8e0e565..97f77bc1ded 100644
--- a/include/bootm.h
+++ b/include/bootm.h
@@ -44,6 +44,8 @@ struct cmd_tbl;
  * @argc: Number of arguments to the command (excluding the actual command).
  *	This is 0 if there are no arguments
  * @argv: NULL-terminated list of arguments, or NULL if there are no arguments
+ * @ignore_bootm_len: Ignore the value CONFIG_SYS_BOOTM_LEN and use 10x the
+ *	compressed length as the maximum uncompressed size
  *
  * For zboot:
  * @bzimage_addr: Address of the bzImage to boot, or 0 if the image has already
@@ -69,6 +71,7 @@ struct bootm_info {
 	const char *cmd_name;
 	int argc;
 	char *const *argv;
+	bool ignore_bootm_len;
 
 	/* zboot items */
 #ifdef CONFIG_X86
-- 
2.43.0

Re: [PATCH v2 0/3] booti: Remove the SYS_BOOTM_LEN limit for booti

[Tom Rini]

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

On Thu, May 01, 2025 at 07:18:32AM -0600, Simon Glass wrote:

> This series restores the original behaviour of extlinux booting linux
> 'Image' files, which is to ignore CONFIG_SYS_BOOTM_LEN and instead uses
> a limit of 10x the compressed size.
> 
> It also adds RISC-V support, since it uses a similar format to ARM64.
> 
> Future work should integrate the code in 'booti' into main 'bootm'
> logic.

I don't like "in the future we'll remove duplicated code". I also don't
like not seeing that what we really need to do, in all cases (not just
booti) handle decompression like we do for FIT images, and ask LMB to
give us a space to use. A problem is that CONFIG_SYS_BOOTM_LEN was never
intended to be the limit on *decompression* as it's the limit on what
we're loading to memory from disk. That's what getting me unhappy with
this part of the series.

-- 
Tom

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

Re: [PATCH v2 0/3] booti: Remove the SYS_BOOTM_LEN limit for booti

[Simon Glass]

Hi Tom,

On Mon, 5 May 2025 at 20:14, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, May 01, 2025 at 07:18:32AM -0600, Simon Glass wrote:
>
> > This series restores the original behaviour of extlinux booting linux
> > 'Image' files, which is to ignore CONFIG_SYS_BOOTM_LEN and instead uses
> > a limit of 10x the compressed size.
> >
> > It also adds RISC-V support, since it uses a similar format to ARM64.
> >
> > Future work should integrate the code in 'booti' into main 'bootm'
> > logic.
>
> I don't like "in the future we'll remove duplicated code".

Small series, fixes a problem, can be made larger but then it isn't a bug-fix.

> I also don't
> like not seeing that what we really need to do, in all cases (not just
> booti) handle decompression like we do for FIT images, and ask LMB to
> give us a space to use.

See bootm_load_os() which does already do this.

> A problem is that CONFIG_SYS_BOOTM_LEN was never
> intended to be the limit on *decompression* as it's the limit on what
> we're loading to memory from disk. That's what getting me unhappy with
> this part of the series.

From what I can tell, that was introduced 11 years ago by this commit:

081cc197472 (HEAD) bootm: Export bootm_decomp_image()

I suppose the idea is that BOOTM is supposed to be a limit on the
image being loaded, so it is compressed, then the limit needs to apply
to the size of the uncompressed image, to maintain parity. Otherwise
there would be no limit at all, since it is pretty easy to devise an
100-byte image which expands to fill all available memory.

Using 10x the uncompressed size doesn't fill me with the joys of spring, TBH.

Regards,
Simon

Re: [PATCH v2 0/3] booti: Remove the SYS_BOOTM_LEN limit for booti

[Tom Rini]

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

On Tue, May 06, 2025 at 03:24:21PM +0200, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, 5 May 2025 at 20:14, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, May 01, 2025 at 07:18:32AM -0600, Simon Glass wrote:
> >
> > > This series restores the original behaviour of extlinux booting linux
> > > 'Image' files, which is to ignore CONFIG_SYS_BOOTM_LEN and instead uses
> > > a limit of 10x the compressed size.
> > >
> > > It also adds RISC-V support, since it uses a similar format to ARM64.
> > >
> > > Future work should integrate the code in 'booti' into main 'bootm'
> > > logic.
> >
> > I don't like "in the future we'll remove duplicated code".
> 
> Small series, fixes a problem, can be made larger but then it isn't a bug-fix.

Which is why yes, this should have been instead of the however-many-part
"PXE" series, and then fixups on top, a series to address this problem.
Then other series to address other problems.

> > I also don't
> > like not seeing that what we really need to do, in all cases (not just
> > booti) handle decompression like we do for FIT images, and ask LMB to
> > give us a space to use.
> 
> See bootm_load_os() which does already do this.

Yes, that's what I was asking you to look at. I assume you're even
specifically pointing to commit 69544c4fd8b1 ("bootm: Support
kernel_noload with compression") which you and I did together.

> > A problem is that CONFIG_SYS_BOOTM_LEN was never
> > intended to be the limit on *decompression* as it's the limit on what
> > we're loading to memory from disk. That's what getting me unhappy with
> > this part of the series.
> 
> From what I can tell, that was introduced 11 years ago by this commit:
> 
> 081cc197472 (HEAD) bootm: Export bootm_decomp_image()
> 
> I suppose the idea is that BOOTM is supposed to be a limit on the
> image being loaded, so it is compressed, then the limit needs to apply
> to the size of the uncompressed image, to maintain parity. Otherwise
> there would be no limit at all, since it is pretty easy to devise an
> 100-byte image which expands to fill all available memory.
> 
> Using 10x the uncompressed size doesn't fill me with the joys of spring, TBH.

Yes, it's a matter of heuristics, and also why we have things like lmb
to check and make sure we don't overwrite ourselves. I do not recall if
the 10x used there, or the 4x we used for kernel_noload FIT
decompression, was based on checking what the compression factor the
available algorithms get on typical kernel images or not. That would be
another improvement area, sure.

-- 
Tom

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

Re: [PATCH v2 0/3] booti: Remove the SYS_BOOTM_LEN limit for booti

[Simon Glass]

Hi Tom,

On Tue, 6 May 2025 at 18:32, Tom Rini <trini@konsulko.com> wrote:
>
> On Tue, May 06, 2025 at 03:24:21PM +0200, Simon Glass wrote:
> > Hi Tom,
> >
> > On Mon, 5 May 2025 at 20:14, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, May 01, 2025 at 07:18:32AM -0600, Simon Glass wrote:
> > >
> > > > This series restores the original behaviour of extlinux booting linux
> > > > 'Image' files, which is to ignore CONFIG_SYS_BOOTM_LEN and instead uses
> > > > a limit of 10x the compressed size.
> > > >
> > > > It also adds RISC-V support, since it uses a similar format to ARM64.
> > > >
> > > > Future work should integrate the code in 'booti' into main 'bootm'
> > > > logic.
> > >
> > > I don't like "in the future we'll remove duplicated code".
> >
> > Small series, fixes a problem, can be made larger but then it isn't a bug-fix.
>
> Which is why yes, this should have been instead of the however-many-part
> "PXE" series, and then fixups on top, a series to address this problem.
> Then other series to address other problems.

The whole effort is addressing problems, although it depends on your
definition of 'problem'.

I'm quite happy with the approach I have taken here, incremental
improvement towards a long-term goal. It doesn't need to be constantly
rebased into out-of-tree code. People can only test what is in-tree.

>
> > > I also don't
> > > like not seeing that what we really need to do, in all cases (not just
> > > booti) handle decompression like we do for FIT images, and ask LMB to
> > > give us a space to use.
> >
> > See bootm_load_os() which does already do this.
>
> Yes, that's what I was asking you to look at. I assume you're even
> specifically pointing to commit 69544c4fd8b1 ("bootm: Support
> kernel_noload with compression") which you and I did together.

I seldom look at the commits that produced the code, but yes.

>
> > > A problem is that CONFIG_SYS_BOOTM_LEN was never
> > > intended to be the limit on *decompression* as it's the limit on what
> > > we're loading to memory from disk. That's what getting me unhappy with
> > > this part of the series.
> >
> > From what I can tell, that was introduced 11 years ago by this commit:
> >
> > 081cc197472 (HEAD) bootm: Export bootm_decomp_image()
> >
> > I suppose the idea is that BOOTM is supposed to be a limit on the
> > image being loaded, so it is compressed, then the limit needs to apply
> > to the size of the uncompressed image, to maintain parity. Otherwise
> > there would be no limit at all, since it is pretty easy to devise an
> > 100-byte image which expands to fill all available memory.
> >
> > Using 10x the uncompressed size doesn't fill me with the joys of spring, TBH.
>
> Yes, it's a matter of heuristics, and also why we have things like lmb
> to check and make sure we don't overwrite ourselves. I do not recall if
> the 10x used there, or the 4x we used for kernel_noload FIT
> decompression, was based on checking what the compression factor the
> available algorithms get on typical kernel images or not. That would be
> another improvement area, sure.

That commit you pointed to does not actually pass the lmb_alloced()'d
size to image_decomp(), so it isn't perfect.

I would much rather use the BOOTM limit everywhere, including as the
maximum uncompressed size of images. That is what it is for, as I
understand it. Users would be quite surprised if the limit were
ignored in certain circumstances.

Regards,
Simon

Re: [PATCH v2 0/3] booti: Remove the SYS_BOOTM_LEN limit for booti

[Tom Rini]

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

On Sat, May 10, 2025 at 01:25:57PM +0200, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, 6 May 2025 at 18:32, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Tue, May 06, 2025 at 03:24:21PM +0200, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Mon, 5 May 2025 at 20:14, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, May 01, 2025 at 07:18:32AM -0600, Simon Glass wrote:
> > > >
> > > > > This series restores the original behaviour of extlinux booting linux
> > > > > 'Image' files, which is to ignore CONFIG_SYS_BOOTM_LEN and instead uses
> > > > > a limit of 10x the compressed size.
> > > > >
> > > > > It also adds RISC-V support, since it uses a similar format to ARM64.
> > > > >
> > > > > Future work should integrate the code in 'booti' into main 'bootm'
> > > > > logic.
> > > >
> > > > I don't like "in the future we'll remove duplicated code".
> > >
> > > Small series, fixes a problem, can be made larger but then it isn't a bug-fix.
> >
> > Which is why yes, this should have been instead of the however-many-part
> > "PXE" series, and then fixups on top, a series to address this problem.
> > Then other series to address other problems.
> 
> The whole effort is addressing problems, although it depends on your
> definition of 'problem'.
> 
> I'm quite happy with the approach I have taken here, incremental
> improvement towards a long-term goal. It doesn't need to be constantly
> rebased into out-of-tree code. People can only test what is in-tree.
> 
> >
> > > > I also don't
> > > > like not seeing that what we really need to do, in all cases (not just
> > > > booti) handle decompression like we do for FIT images, and ask LMB to
> > > > give us a space to use.
> > >
> > > See bootm_load_os() which does already do this.
> >
> > Yes, that's what I was asking you to look at. I assume you're even
> > specifically pointing to commit 69544c4fd8b1 ("bootm: Support
> > kernel_noload with compression") which you and I did together.
> 
> I seldom look at the commits that produced the code, but yes.
> 
> >
> > > > A problem is that CONFIG_SYS_BOOTM_LEN was never
> > > > intended to be the limit on *decompression* as it's the limit on what
> > > > we're loading to memory from disk. That's what getting me unhappy with
> > > > this part of the series.
> > >
> > > From what I can tell, that was introduced 11 years ago by this commit:
> > >
> > > 081cc197472 (HEAD) bootm: Export bootm_decomp_image()
> > >
> > > I suppose the idea is that BOOTM is supposed to be a limit on the
> > > image being loaded, so it is compressed, then the limit needs to apply
> > > to the size of the uncompressed image, to maintain parity. Otherwise
> > > there would be no limit at all, since it is pretty easy to devise an
> > > 100-byte image which expands to fill all available memory.
> > >
> > > Using 10x the uncompressed size doesn't fill me with the joys of spring, TBH.
> >
> > Yes, it's a matter of heuristics, and also why we have things like lmb
> > to check and make sure we don't overwrite ourselves. I do not recall if
> > the 10x used there, or the 4x we used for kernel_noload FIT
> > decompression, was based on checking what the compression factor the
> > available algorithms get on typical kernel images or not. That would be
> > another improvement area, sure.
> 
> That commit you pointed to does not actually pass the lmb_alloced()'d
> size to image_decomp(), so it isn't perfect.
> 
> I would much rather use the BOOTM limit everywhere, including as the
> maximum uncompressed size of images. That is what it is for, as I
> understand it. Users would be quite surprised if the limit were
> ignored in certain circumstances.

Yes. I believe you misunderstand the limit, and the reports that we (and
distributions, etc) get when users have a problem would re-enforce that
too.

-- 
Tom

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

Re: [PATCH v2 0/3] booti: Remove the SYS_BOOTM_LEN limit for booti

[Simon Glass]

Hi Tom,

On Tue, 13 May 2025 at 00:31, Tom Rini <trini@konsulko.com> wrote:
>
> On Sat, May 10, 2025 at 01:25:57PM +0200, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, 6 May 2025 at 18:32, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Tue, May 06, 2025 at 03:24:21PM +0200, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Mon, 5 May 2025 at 20:14, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Thu, May 01, 2025 at 07:18:32AM -0600, Simon Glass wrote:
> > > > >
> > > > > > This series restores the original behaviour of extlinux booting linux
> > > > > > 'Image' files, which is to ignore CONFIG_SYS_BOOTM_LEN and instead uses
> > > > > > a limit of 10x the compressed size.
> > > > > >
> > > > > > It also adds RISC-V support, since it uses a similar format to ARM64.
> > > > > >
> > > > > > Future work should integrate the code in 'booti' into main 'bootm'
> > > > > > logic.
> > > > >
> > > > > I don't like "in the future we'll remove duplicated code".
> > > >
> > > > Small series, fixes a problem, can be made larger but then it isn't a bug-fix.
> > >
> > > Which is why yes, this should have been instead of the however-many-part
> > > "PXE" series, and then fixups on top, a series to address this problem.
> > > Then other series to address other problems.
> >
> > The whole effort is addressing problems, although it depends on your
> > definition of 'problem'.
> >
> > I'm quite happy with the approach I have taken here, incremental
> > improvement towards a long-term goal. It doesn't need to be constantly
> > rebased into out-of-tree code. People can only test what is in-tree.
> >
> > >
> > > > > I also don't
> > > > > like not seeing that what we really need to do, in all cases (not just
> > > > > booti) handle decompression like we do for FIT images, and ask LMB to
> > > > > give us a space to use.
> > > >
> > > > See bootm_load_os() which does already do this.
> > >
> > > Yes, that's what I was asking you to look at. I assume you're even
> > > specifically pointing to commit 69544c4fd8b1 ("bootm: Support
> > > kernel_noload with compression") which you and I did together.
> >
> > I seldom look at the commits that produced the code, but yes.
> >
> > >
> > > > > A problem is that CONFIG_SYS_BOOTM_LEN was never
> > > > > intended to be the limit on *decompression* as it's the limit on what
> > > > > we're loading to memory from disk. That's what getting me unhappy with
> > > > > this part of the series.
> > > >
> > > > From what I can tell, that was introduced 11 years ago by this commit:
> > > >
> > > > 081cc197472 (HEAD) bootm: Export bootm_decomp_image()
> > > >
> > > > I suppose the idea is that BOOTM is supposed to be a limit on the
> > > > image being loaded, so it is compressed, then the limit needs to apply
> > > > to the size of the uncompressed image, to maintain parity. Otherwise
> > > > there would be no limit at all, since it is pretty easy to devise an
> > > > 100-byte image which expands to fill all available memory.
> > > >
> > > > Using 10x the uncompressed size doesn't fill me with the joys of spring, TBH.
> > >
> > > Yes, it's a matter of heuristics, and also why we have things like lmb
> > > to check and make sure we don't overwrite ourselves. I do not recall if
> > > the 10x used there, or the 4x we used for kernel_noload FIT
> > > decompression, was based on checking what the compression factor the
> > > available algorithms get on typical kernel images or not. That would be
> > > another improvement area, sure.
> >
> > That commit you pointed to does not actually pass the lmb_alloced()'d
> > size to image_decomp(), so it isn't perfect.
> >
> > I would much rather use the BOOTM limit everywhere, including as the
> > maximum uncompressed size of images. That is what it is for, as I
> > understand it. Users would be quite surprised if the limit were
> > ignored in certain circumstances.
>
> Yes. I believe you misunderstand the limit, and the reports that we (and
> distributions, etc) get when users have a problem would re-enforce that
> too.

OK, perhaps a topic for a future call.

Regards,
Simon