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

Simon Glass sjg at chromium.org
Fri Apr 18 15:46:59 CEST 2025


Hi Tom,

On Fri, 18 Apr 2025 at 07:33, Tom Rini <trini at konsulko.com> wrote:
>
> On Fri, Apr 18, 2025 at 06:50:59AM -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.
> >
> >
> > 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 ignoring SYS_BOOTM_LEN with the booti command
> >
> >  boot/bootm.c    | 31 +++++++++++++++++++++++++------
> >  cmd/booti.c     |  1 +
> >  include/bootm.h |  3 +++
> >  3 files changed, 29 insertions(+), 6 deletions(-)
>
> This is like pulling teeth. We aren't ignoring SYS_BOOTM_LEN so much as
> it was never relevant here to start with. The documentation
> (doc/usage/cmd/booti.rst) has explained that we use 10 x
> kernel_comp_size for the limit. The "bootm" namespace has largely been
> about uImage (and then FIT images when not using it's own namespace)
> images and not applied elsewhere, which is why bootz/booti handled
> things outside that namespace. And then, still, this series doesn't
> unify cmd/booti.c with your changes, it just introduces duplicated
> functionality, which is generally understood to be a bad thing.
>
> So again, please do similar to what you did for cmd/bootz.c and that
> report and move the existing functionality over. We can then look at
> cleaning it up (which should look like / abstract what we do for
> compressed FIT images) as a follow up, in order to make bisecting any
> regressions here easier down the line. Thanks.

Well, I still don't understand what you are getting at here.

The existing functionality for booti is already there. Marek added it
a few years back. Can you please be more specific as to what
functionality you think is missing?

Yes, the bootm implementation is separate from the booti command at
present. They both call booti_setup(). But the booti command uses
kernel_comp_addr_r which we shouldn't be using in bootm. In fact I'd
like to get rid of those vars, not proliferate them. There is
certainly some more common code which can be teased apart, but it's
not the subject of this bugfix. I have to stop somewhere.

Perhaps you should let me do this refactoring in the way that I
believe it should be done?

Regards,
Simon


More information about the U-Boot mailing list