Re: [PATCH/RFC] ARM: dts: rza2mevb: Upstream Linux requires SDRAM

From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Nicolas Pitre <nico@fluxnic.net>
Cc: Chris Brandt <Chris.Brandt@renesas.com>,
	Magnus Damm <magnus.damm@gmail.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Russell King <linux@armlinux.org.uk>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH/RFC] ARM: dts: rza2mevb: Upstream Linux requires SDRAM
Date: Fri, 8 May 2020 17:56:22 +0200	[thread overview]
Message-ID: <CAMuHMdX11aLVE8tNNzuawKZqg21mOEnmTv=RkdOPZmMjMzWRMw@mail.gmail.com> (raw)
In-Reply-To: <nycvar.YSQ.7.77.849.2005081023180.5637@knanqh.ubzr>

Hi Nicolas,

On Fri, May 8, 2020 at 4:41 PM Nicolas Pitre <nico@fluxnic.net> wrote:
> On Fri, 8 May 2020, Chris Brandt wrote:
> > The big argument was always that "XIP cannot be multi-platform by
> > definition because RAM/ROM always resides at different addresses in different
> > devices". And as you know, the physical address for RAM and ROM have to
> > be hard coded in the kernel binary.
>
> Exact.  So what is the problem?

Ah, you've fallen for the "multi-platform" fallacy! I have no desire to
enable support for multiple platforms in a single kernel that supports
XIP on all platforms.
I merely want it to be possible to build a XIP kernel for one platform.
As ARM v7m systems must be part of the ARCH_MULTI_V7 gang, they cannot
enable the XIP_KERNEL config symbol.

[PATCH] [RFC] arm: Replace "multiple platforms" by "common platform"
http://lore.kernel.org/r/20180621155906.12821-1-geert+renesas@glider.be

> > At an ELC a while back, I talked to Arnd and his suggestion was to put
> > the base addresses for RAM and ROM at a fixed location in the kernel
> > binary. Then for each SoC, you manually modify those values in the each
> > binary to match your board. This means there is 'technically' a single build
> > that will support all boards.

Interesting. I didn't know that suggestion.
Sounds doable (but see below).

> The very reason for using XIP in the first place is to maximize resource
> savings on constrained platforms. Any notion of a multi-platform kernel
> is completely contrary to this goal. This is even more true for no-MMU
> platforms where you can't abstract physical address differences behind a
> page table.
>
> Multi-platform kernel supporting all boards make sense for generic
> distros and/or build coverage tests. But a multi-platform XIP kernel is
> a nonsense. Trying to make XIP multi-platform might be a nice
> intellectual challenge but that has zero value for actual deployment and
> usage.

Agreed.

> Given that there isn't a lot of such platforms anyway, it should be
> possible to carry a few kconfig entries outside of the multi-platform
> menu for XIP targets and live with possible kconfig duplicates. That
> shouldn't be such a maintenance burden.

Still, it's duplication, which could be avoided using a single "know
what you're doing" Kconfig option.
And it will grow, as XIP could be used on lots of platforms.

I believe this is exactly what Chris' last attempt did?

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