Hi Arnd et al,
On Tue, Sep 27, 2022 at 2:31 PM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
> On Thu, Aug 18, 2022 at 4:56 PM Arnd Bergmann <arnd@xxxxxxxxxx> wrote:
> > From: Arnd Bergmann <arnd@xxxxxxxx>
> >
> > 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@xxxxxxxx>
>
> 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@xxxxxxxxx
> 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@xxxxxxxxx
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
