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

Christian Marangi (Ansuel) ansuelsmth at gmail.com
Mon Feb 2 03:03:24 PST 2026


Il giorno lun 2 feb 2026 alle ore 11:58 Russell King (Oracle)
<linux at 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.



More information about the linux-arm-kernel mailing list