[PATCH 5/5] ARM: make ARCH_MULTIPLATFORM user-visible

Geert Uytterhoeven geert at linux-m68k.org
Tue Sep 27 06:29:52 PDT 2022


Hi Arnd et al,

On Tue, Sep 27, 2022 at 2:31 PM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> On Thu, Aug 18, 2022 at 4:56 PM Arnd Bergmann <arnd at kernel.org> wrote:
> > From: Arnd Bergmann <arnd at arndb.de>
> >
> > Some options like CONFIG_DEBUG_UNCOMPRESS and CONFIG_CMDLINE_FORCE are
> > fundamentally incompatible with portable kernels but are currently allowed
> > in all configurations. Other options like XIP_KERNEL are essentially
> > useless after the completion of the multiplatform conversion.
> >
> > Repurpose the existing CONFIG_ARCH_MULTIPLATFORM option to decide
> > whether the resulting kernel image is meant to be portable or not,
> > and using this to guard all of the known incompatible options.
> >
> > This is similar to how the RISC-V kernel handles the CONFIG_NONPORTABLE
> > option (with the opposite polarity).
> >
> > A few references to CONFIG_ARCH_MULTIPLATFORM were left behind by
> > earlier clanups and have to be removed now up.
> >
> > Signed-off-by: Arnd Bergmann <arnd at arndb.de>
>
> Thanks for your patch, which is now commit 84fc863606239d8b ("ARM: make
> ARCH_MULTIPLATFORM user-visible") in soc/for-next.
>
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -320,7 +320,19 @@ config ARCH_MMAP_RND_BITS_MAX
> >         default 16
> >
> >  config ARCH_MULTIPLATFORM
> > -       def_bool MMU && !(ARCH_FOOTBRIDGE || ARCH_RPC || ARCH_SA1100)
> > +       bool "Require kernel to be portable to multiple machines" if EXPERT
> > +       depends on MMU && !(ARCH_FOOTBRIDGE || ARCH_RPC || ARCH_SA1100)
> > +       default y
> > +       help
> > +         In general, all Arm machines can be supported in a single
> > +         kernel image, covering either Armv4/v5 or Armv6/v7.
> > +
> > +         However, some configuration options require hardcoding machine
> > +         specific physical addresses or enable errata workarounds that may
> > +         break other machines.
> > +
> > +         Selecting N here allows using those options, including
> > +         DEBUG_UNCOMPRESS, XIP_KERNEL and ZBOOT_ROM. If unsure, say Y.
> >
> >  menu "Platform selection"
> >         depends on MMU
> > @@ -1609,6 +1621,7 @@ config CMDLINE_EXTEND
> >
> >  config CMDLINE_FORCE
> >         bool "Always use the default kernel command string"
> > +       depends on !ARCH_MULTIPLATFORM
>
> This change broke half of the boards in my collective.
> Dropping this dependency again fixes the issue for me.
>
> On older platforms that boot an image with an appended DTB, or where
> the boot loader has no support for updating chosen/bootargs, I rely on
> CMDLINE_FORCE.
>
> Note that the CMDLINE choice depends on CONFIG_ATAGS=y, although
> my systems do not use ATAGS at all.  Arm64, loongarch, microblaze,
> nios2, powerpc, and riscv do not have such a limitation, so perhaps
> that should be lifted on arm, too?

"[PATCH] ARM: Drop CMDLINE_* dependency on ATAGS"
https://lore.kernel.org/r/09f0619e8038654d01588d9ad3a023485b2bd77f.1664285209.git.geert+renesas@glider.be

> I do see the rationale behind this change, and agree that a fixed
> command line can make the kernel unbootable on other platforms.
> However, a common command line is not guaranteed to cause that.
> E.g. all Renesas boards use the same chosen/bootargs in upstream DTS,
> which works fine if your DHCP server hands out proper nfsroot
> parameters (note that mine, running on OpenWRT, doesn't, hence my use
> of CMDLINE_FORCE ;-).

"[PATCH] ARM: Drop CMDLINE_FORCE dependency on !ARCH_MULTIPLATFORM"
https://lore.kernel.org/r/c557b149780faa2299700585afc9d270ede7f78b.1664285062.git.geert+renesas@glider.be

Gr{oetje,eeting}s,

                        Geert

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



More information about the linux-arm-kernel mailing list