Hi Nicolas, On Fri, May 8, 2020 at 4:41 PM Nicolas Pitre <nico@xxxxxxxxxxx> 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@xxxxxxxxx > > 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@xxxxxxxxxxxxxx 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
