Re: [PATCH v2 0/2] ARM: decompressor: support AUTO_ZRELADDR and appended DTB

[Marc Zyngier <maz@kernel.org>]

On Mon, 02 Feb 2026 11:03:24 +0000,
"Christian Marangi (Ansuel)" <ansuelsmth@gmail.com> wrote:
> 
> Il giorno lun 2 feb 2026 alle ore 11:58 Russell King (Oracle)
> <linux@armlinux.org.uk> ha scritto:
> >
> > On Mon, Feb 02, 2026 at 11:26:49AM +0100, Geert Uytterhoeven wrote:
> > > FTR, I did provide my Tested-by for the first patch in [1].
> > > I still have this series in my local tree, which I test regularly on
> > > a variety of Renesas ARM32 platforms and on BeagleBone Black.
> > >
> > > In fact, I had completely forgotten about this series, to the point
> > > that I bisected a failure in booting mainline on one of my boards
> > > using my current .config to the absence of the first patch ;-)
> > > Apparently during the past years, I had modified my .config to make it
> > > more generic, and make better use of the DTB (incl. chosen/bootargs),
> > > which has a dependency on the first patch...
> >
> > What I would like to know is why anyone is using appended DTBs in this
> > day and age, when surely by now, Arm based boot loaders have realised
> > that Arm moved to use device trees ages ago, and the kernel requires
> > a DTB in addition to the kernel image itself.
> >
> > Appended DTB support was only there as a stop-gap for those boot
> > loaders that were around before DTB support was added, and have no
> > capability of dealing with a separate DTB.
> >
> > Come on. It's 2026. DTB has been supported on 32-bit ARM for fifteen
> > years. Surely everyone's now got modern boot loaders.
> >
> > If not, it's time to say this: fix the boot loader.
> >
> 
> The main problem is that sometimes it's not possible to update the bootloader
> at all. Either they never provided the source or Uboot is not even used.
> 
> And on some device updating the bootloader is risky as you would end up
> in a brick. (no way to recover it)
> 
> Also other case usually sign the bootloader and permit to load whatever
> image you want so also problematic to update the bootloader.
> 
> Sadly for these device, it's full of corner situation where the Vendor used
> a badly configured SDK and made a single bootloader on it.
> 
> For example QCOM Uboot SDK still target ancient 2012 version if I'm not
> wrong.

If you can boot the kernel, you can also boot a secondary bootloader
that will do the right thing by exposing a DT. Fixing the boot flow
should be the priority, rather than adding more band-aids to the
kernel.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.