From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Nicolas Pitre <nico@fluxnic.net>
Cc: Arnd Bergmann <arnd@arndb.de>,
Magnus Damm <magnus.damm@gmail.com>,
Russell King <linux@armlinux.org.uk>,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
Chris Brandt <Chris.Brandt@renesas.com>,
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-05-08 15:56 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-07 8:05 [PATCH/RFC] ARM: dts: rza2mevb: Upstream Linux requires SDRAM Geert Uytterhoeven
2020-05-07 14:58 ` Nicolas Pitre
2020-05-07 16:08 ` Geert Uytterhoeven
2020-05-07 17:06 ` Nicolas Pitre
2020-05-08 13:38 ` Geert Uytterhoeven
2020-05-08 14:05 ` Chris Brandt
2020-05-08 14:41 ` Nicolas Pitre
2020-05-08 15:56 ` Geert Uytterhoeven [this message]
2020-05-08 16:15 ` Nicolas Pitre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMuHMdX11aLVE8tNNzuawKZqg21mOEnmTv=RkdOPZmMjMzWRMw@mail.gmail.com' \
--to=geert@linux-m68k.org \
--cc=Chris.Brandt@renesas.com \
--cc=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=magnus.damm@gmail.com \
--cc=nico@fluxnic.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).