Message-ID: <aYNJzbSxfpRza4no@shell.armlinux.org.uk>
Date: Wed, 4 Feb 2026 13:29:49 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
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

On Wed, Feb 04, 2026 at 01:58:21PM +0100, Geert Uytterhoeven wrote:
> 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).

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.

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.

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).

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.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Powered by blists - more mailing lists