From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [78.32.30.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2321119C566 for ; Wed, 4 Feb 2026 12:48:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=78.32.30.218 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770209303; cv=none; b=JG9uur2EGDnkV/b60sGv9MYqqZ+BrzIX4snD1aOIJxTeGduOmounSS4V3ooEJD6Ry3Wi9e0BxQf+kLqTSxvYM5aBwBcv69zktvvcRm3YgDGrBteLYmqXcCpOyEiyH1JyfKVW/IGAYno/ohS19zqlG+Kf0S11M8WKC3hgUAGx3gE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770209303; c=relaxed/simple; bh=lrcdrO2ncXQ1tlXlSYVduiX6Z3rUhZI7XogETUFYce0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=svESZ7e/OSvFAaXJQAXAkBiTxKowCP0OYsGVnFSWF+JYomd7WbZV3jSGpMACOjZnyh1aWWfM7mGCfmKg5USzlRAKNp2pPk2VAJuReJ1S+A4WMj0mBL9CfaoWmTqfbp0oANEx3A5Tdav8HVMKcdZ5yoJnk2CCJq958cUvnSwyalI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=armlinux.org.uk; spf=none smtp.mailfrom=armlinux.org.uk; dkim=pass (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b=Rem122p7; arc=none smtp.client-ip=78.32.30.218 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=armlinux.org.uk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="Rem122p7" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=OE3Y7fLeZPRewo7EBhh65kVu2li8CGC4bTrvBrJ/zrc=; b=Rem122p7lChgfwBXwf4hbVCmpF zB6lj5hzsYaobmcgi9Z7hHQQ8bElojxgFsEstJc9/2DFpzoAgb/hpWsLGsx2UUxgVx5O6W7OskvFf cxIDREBnYRqCbJnRowgSFsqHwT2ae/OTV2pgTXKLwGn3i1TSKkqIaeMbn/2B1r6J7WUfTsBS5Xc6j sWrzqiAV6dv4RQGJrLu4/9NZGpnV1h1DtH/KNHtVfLvYabsGfRQHDRA7WBWcIz28bcacTYSNdvnlM qGVH5vs/2mdRnM+8edSbt9DrVux/za4OOz8/B2tnFH+isYkiuw24AM20uTLUobiBRhBEgyIMub5NZ +K6drk4A==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:52140) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vncIg-000000006Kn-1ubA; Wed, 04 Feb 2026 12:48:06 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.98.2) (envelope-from ) id 1vncIc-000000005ND-2GCi; Wed, 04 Feb 2026 12:48:02 +0000 Date: Wed, 4 Feb 2026 12:48:02 +0000 From: "Russell King (Oracle)" To: Geert Uytterhoeven Cc: Linus Walleij , Marc Zyngier , "Christian Marangi (Ansuel)" , Linus Walleij , Arnd Bergmann , Andrew Morton , Geert Uytterhoeven , "Kirill A. Shutemov" , Thomas Gleixner , Jonathan Corbet , "Mike Rapoport (IBM)" , Eric DeVolder , Nathan Chancellor , Kees Cook , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Bjorn Andersson , Konrad Dybcio , John Crispin Subject: Re: [PATCH v2 0/2] ARM: decompressor: support AUTO_ZRELADDR and appended DTB Message-ID: References: <666b2379.5d0a0220.c7eec.8b6f@mx.google.com> <86v7gf9z92.wl-maz@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Russell King (Oracle) 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: > > Hi Russell, > > > > On Wed, 4 Feb 2026 at 02:27, Russell King (Oracle) > > 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. - 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. 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. This is documented in Documentation/arch/arm/booting.rst: The zImage may also be placed in system RAM and called there. The kernel should be placed in the first 128MiB of RAM. It is recommended that it is loaded above 32MiB in order to avoid the need to relocate prior to decompression, which will make the boot process slightly faster. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!