Hi Tom, On Thu, 1 May 2025 at 08:59, Tom Rini <tr...@konsulko.com> wrote: > > On Thu, May 01, 2025 at 07:06:03AM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Fri, 18 Apr 2025 at 08:08, Tom Rini <tr...@konsulko.com> wrote: > > > > > > On Fri, Apr 18, 2025 at 07:46:59AM -0600, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Fri, 18 Apr 2025 at 07:33, Tom Rini <tr...@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? > > > > > > With: > > > https://patchwork.ozlabs.org/project/uboot/patch/20250409155723.431102-1-...@chromium.org/ > > > You moved the functionality from cmd/bootz.c and over to boot/bootm.c > > > > > > You need to do the same thing here. > > > > That code is already there. Here is the code you are talking about, in > > cmd/booti.c (which is a hack, BTW) > > Hey, thanks for insulting my code, BTW. Best way to make sure I really want > to take your way of refactoring the code, rather than the way I asked > you to. > > I'll look at this again tomorrow.
Oops, I didn't know it was your code, sorry. Regards, Simon