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

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

[Geert Uytterhoeven]

Hi Arnd,

On Thu, Aug 18, 2022 at 4:56 PM Arnd Bergmann <arnd@kernel.org> wrote:
> From: Arnd Bergmann <arnd@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@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?

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 ;-).

>         help
>           Always use the default kernel command string, even if the boot
>           loader passes other arguments to the kernel.

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

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

[Geert Uytterhoeven]

Hi Arnd et al,

On Tue, Sep 27, 2022 at 2:31 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Thu, Aug 18, 2022 at 4:56 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > From: Arnd Bergmann <arnd@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@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@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