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

Geert Uytterhoeven geert at linux-m68k.org
Wed Feb 4 04:58:21 PST 2026


Hi Russell,

On Wed, 4 Feb 2026 at 13:48, Russell King (Oracle)
<linux at armlinux.org.uk> wrote:
> On Wed, Feb 04, 2026 at 11:54:59AM +0000, Russell King (Oracle) wrote:
> > On Wed, Feb 04, 2026 at 11:53:30AM +0100, Geert Uytterhoeven wrote:
> > > On Wed, 4 Feb 2026 at 02:27, Russell King (Oracle)
> > > <linux at armlinux.org.uk> wrote:
> > > > On Wed, Feb 04, 2026 at 01:36:29AM +0100, Linus Walleij wrote:
> > > > > However, I think it is a thick requirement to put on hobbyist
> > > > > contributors to go and write entite boot loaders from scratch,
> > > > > I think it's a fine requirement to put on Qualcomm or Renesas
> > > > > paid maintainers.
> > > >
> > > > If we're talking about older boards, then why have they only recently
> > > > became a problem, when, presumably, they've been working fine for a
> > > > decade or so?
> > >
> > > These boards may have been working fine, given the right "legacy"
> > > kernel config options were used.  However, some of these option make
> > > the resulting kernel limited to that platform or even to a specific
> > > board (e.g. when CONFIG_CMDLINE needs to be used).
> >
> > The 32-git ARM kernel has had a way to pass the command line to the
> > kernel from the boot loader since day one.
> >
> >       First it was the struct param_struct.
> >       Then it was the ATAGs that was introduced pre-git.
> >       Now it is DT.
> >
> > The kernel retains code to parse all three methods of passing data
> > from the boot loader to the kernel. The decompressor has support
> > for merging the ATAGs into the appended DTB, which includes merging
> > the command line into the DTB.
> >
> > Without an appended DTB, the pointer to one of the above will be
> > passed to the kernel, the kernel will figure out what it has and
> > parse one of the three ways, and use the command line there.
> >
> > The only case where CONFIG_CMDLINE should be used is when there is
> > no command line passed, no way to change it, etc. At that point
> > there are two options:
> >
> > 1. Augment the kernel's generated FDT with the command line node
> >    and load that modified FDT or append it to the compressed image.
> >
> > 2. Use CONFIG_CMDLINE, which means that the kernel _will_ become
> >    specific to the platform that needs those arguments. No getting
> >    away from that in this case.
> >
> > Maybe you haven't explained the problem very well, but I don't see
> > any issue with this.
> >
> > > The KZM-A9-GT I "need" this for never had upstream U-Boot (I don't
> > > think I ever had any U-Boot sources).  I can boot a shmobile_defconfig
> > > multi-platform kernel[*] fine, iff the first patch is applied.
> >
> > So, what have you been doing for the last 14 years to boot this
> > platform (merged in 2012) without this patch?
> >
> > Please explain:
> >
> > - how it worked before - I want to know how the DTB is passed to the
> >   kernel, what information is provided from the boot loader, whether
> >   that gets merged into the DTB, etc. All the fine nitty gritty of
> >   how it worked and what doesn't work, what the problems were etc.
> >
> > - what changed (it sounds like you want extra features)
> >
> > - why (in detail) it doesn't work now.
>
> I want to know:
>
> - Where RAM is located.
> - Where the kernel is being loaded.

tftp 0x43000000 kzm9g/zImage.dtb
bootz

> - Whether the platform reserves any RAM that may overlap with the kernel
>   or where the kernel wants to locate itself in RAM.
>
> From what I can see from arch/arm/boot/dts/renesas/sh73a0-kzm9g.dts,
> memory is at 0x4000000..0x5fffffff - 512MiB.

Correct.

> So, provided you load and execute the compressed kernel image within
> the first 128Mi of memory (0x40000000 - 0x48000000), then it will select
> 0x40008000 to decompress itself. I can find no mention of any reserved
> memory regions in the DT file, so this should be fine.
>
> If you're loading the compressed kernel at some wildly different
> address, then yes, it probably won't work.

It also works when loaded at e.g. 0x42000000 or 0x44000000,
but not at 0x41000000 (all with [PATCH 1/2] applied).

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds



More information about the linux-arm-kernel mailing list