linux-kernel - Re: [PATCH v2 0/2] ARM: decompressor: support AUTO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdWxA5Uq2m5sfiG8=WzqKiEmXA0sp4fYGWOvQwhzubDUXg@mail.gmail.com>
Date: Wed, 4 Feb 2026 13:58:21 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Linus Walleij <linusw@...nel.org>, Marc Zyngier <maz@...nel.org>, 
	"Christian Marangi (Ansuel)" <ansuelsmth@...il.com>, Linus Walleij <linus.walleij@...aro.org>, 
	Arnd Bergmann <arnd@...db.de>, Andrew Morton <akpm@...ux-foundation.org>, 
	Geert Uytterhoeven <geert+renesas@...der.be>, 
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>, Thomas Gleixner <tglx@...utronix.de>, 
	Jonathan Corbet <corbet@....net>, "Mike Rapoport (IBM)" <rppt@...nel.org>, 
	Eric DeVolder <eric.devolder@...cle.com>, Nathan Chancellor <nathan@...nel.org>, 
	Kees Cook <keescook@...omium.org>, linux-arm-kernel@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, Bjorn Andersson <andersson@...nel.org>, 
	Konrad Dybcio <konrad.dybcio@...ainline.org>, John Crispin <john@...ozen.org>
Subject: Re: [PATCH v2 0/2] ARM: decompressor: support AUTO_ZRELADDR and
 appended DTB

Hi Russell,

On Wed, 4 Feb 2026 at 13:48, Russell King (Oracle)
<linux@...linux.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@...linux.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@...ux-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