Re: [PATCH/RFC] ARM: boot: Relax kernel image alignment for RZ/A with CS3 SDRAM

From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: "Arnd Bergmann" <arnd@arndb.de>,
	"Nicolas Pitre" <nico@fluxnic.net>,
	"Eric Miao" <eric.miao@nvidia.com>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Chris Brandt" <chris.brandt@renesas.com>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>
Subject: Re: [PATCH/RFC] ARM: boot: Relax kernel image alignment for RZ/A with CS3 SDRAM
Date: Wed, 13 Nov 2019 14:32:19 +0100	[thread overview]
Message-ID: <CAMuHMdXWsUChMA+_6sdavo8nd-9icX6nsN7unSfMMViOQrUVMQ@mail.gmail.com> (raw)
In-Reply-To: <20191113103919.GM25745@shell.armlinux.org.uk>

Hi Russell,

On Wed, Nov 13, 2019 at 11:39 AM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
> On Wed, Nov 13, 2019 at 11:27:29AM +0100, Geert Uytterhoeven wrote:
> > The RZA2MEVB sub board has 64 MiB of SDRAM at 0x0C000000 (CS3 space).
> > Hence the mask for CONFIG_AUTO_ZRELADDR needs to be changed, otherwise
> > the system will crash because it will try to decompress a zImage or
> > uImage to a non-RAM garbage address.
> >
> > Based on a patch in the BSP by Chris Brandt <chris.brandt@renesas.com>.
> >
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > ---
> > No idea what to do with the rest of the comment, or if this breaks
> > existing platforms.
>
> We occasionally have discussions about this - the last one was a big
> one in Edinburgh, and the answer is we can't change this in mainline.
> They've also come up on the mailing lists as well.
>
> I'm not going to rehash this old argument yet again - the comment
> details the reason for it, and is there to prevent exactly this.

Sorry, I wasn't aware of that discussion.
I had a chat about this at ELC-E with Arnd, and he was open to this change.

> If someone is silly enough to come up with a platform that violates
> the documented 32-bit ARM booting protocol, then they can't expect
> the kernel to bend to their platform's requirements at the expense of
> already merged platforms.

Documentation/arm/booting.rst:
  1. The kernel should be placed in the first 128MiB of RAM: check.
  2. A safe location is just above the 128MiB boundary from start of RAM:
     oops. Not all platforms have more than 128 MiB of RAM...

An alternative is to fall to the builtin 4 MiB of SRAM, or the 8 MiB of
HyperRAM on RZA2MEVB, but doing that requires using XIP.
Which brings us to your response in the other email:

> Are we going back to non-multi-platform kernels? ;)

Good question! ;-)

  1. CONFIG_AUTO_ZRELADDR=n
  2. CONFIG_XIP_KERNEL=y

What do you suggest?
Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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