Message-ID: <CAMuHMdX3eO2P=vGEe2LmPgVa90ZSxP8fxqmW+J-cLPQqwgW0pA@mail.gmail.com>
Date: Wed, 4 Feb 2026 14:52:14 +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 14:29, Russell King (Oracle)
<linux@...linux.org.uk> wrote:
> On Wed, Feb 04, 2026 at 01:58:21PM +0100, Geert Uytterhoeven wrote:
> > 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).
>
> So let's assume the kernel is loaded at 0x43000000.
>
>                 mov     r0, pc
>                 and     r0, r0, #0xf8000000
>
> This will result in r0 being 0x40000000. This becomes the mem_start
> argument in fdt_check_mem_start().
>
> We look for an appended DTB, and skip the validation that
> fdt_check_mem_start() does. If this were to go ahead, then this would
> find that 0x40000000 is within the memory@...00000 node, and thus this
> would return "mem_start".
>
> Then:
>
>                 /* Determine final kernel image address. */
>                 add     r4, r0, #TEXT_OFFSET
>
> will place the decompressed kernel at 0x40008000.
>
> However, as placing the kernel at 0x41000000 doesn't boot, that
> suggests some memory is being removed from the kernel. If adding a
> call to fdt_check_mem_start() after the ATAG-to-FDT parsing has
> been performed fixes this, it suggests the ATAGs change this.
>
> So, with a booted kernel, what does:
>
> $ hexdump -e '"%8.8_ax  " 8/4 "%08x " "\n"' /sys/firmware/devicetree/base/memory\@40000000/reg
>
> say? Has this been modified from 00000040 00000020 ? I think it
> will be.

Thank you. Output is:

    00000000  00000041 0000001f

So the first 16 MiB was indeed removed.

> That means there's a simple fix: as there is likely reserved memory
> at the start of RAM, reflecting that in this platform's .dts would
> fix this issue without needing to change the decompressor.

Unfortunately that does not seem to work.

> If you don't want to change the reg in the memory@ node, then there's
> /chosen/linux,usable-memory-range which can be used to specify the
> usable memory base and size (same format as reg).

Neither does this...

> Another option would be to add linux,usable-memory to the memory@
> node that specifies the range of usable memory while still specifying
> the full memory range in the reg property.

... or this.

Don't all of these methods rely on fdt_check_mem_start() operating on
the appended DTB, i.e. on what [PATCH v2 1/2] does?

Thanks!

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

Powered by blists - more mailing lists