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

[Geert Uytterhoeven]

Hi Russell,

On Wed, 4 Feb 2026 at 12:55, Russell King (Oracle)
<linux at armlinux.org.uk> 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.

I am fully aware I didn't explain it sufficiently, but I don't remember
all the details.  The important part is that I never got the kernel
commandline passing from U-Boot env to the kernel to work on KZM-A9-GT,
until after I had applied "[PATCH v2 1/2] ARM: decompressor: support
memory start validation for appended DTB".
And without that patch, my current .config no longer boots.

> > 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'll add this investigation to my (too long) list of TODOs (so I may
or may not get to it this decade ;-)

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