Re: [RFC} arm architecture board/feature deprecation timeline

["Arnd Bergmann" <arnd@arndb.de>]

On Thu, Aug 1, 2024, at 10:59, Arnd Bergmann wrote:
> On Wed, Jul 31, 2024, at 21:13, Aaro Koskinen wrote:
>> On Wed, Jul 31, 2024 at 07:29:29PM +0200, Arnd Bergmann wrote:
>>> === early ARMv6 ===
>>> 
>>> This is the ARM1136r0p in NXP i.MX31 and OMAP24xx, which in
>>> practice means just the Nokia N8xx tablet.
>>> It causes a lot of pain to support in the kernel since it
>>> requires special hacks to support in SMP-enabled kernels.
>>
>> FWIW, I have been never able to boot N8x0 unless CONFIG_SMP was disabled
>> (but haven't tested recently if the situation has changed). And probably
>> nobody else is anymore even booting these with modern kernels. Common
>> distro kernel support for N8x0 would be unlikely anyway due to bootloader
>> and memory limitations.
>
> Thanks for your quick reply!
>
> I don't think there were ever any distro kernels with support for
> N8x0 and other hardware in the same binary, but I do recall Tony
> testing the omap2plus_defconfig across omap2 through omap5
> successfully in the past, which is the main reason we kept this
> as a Kconfig option.

Thinking about this some more, I wonder if we should just
change the Kconfig dependencies now (for 6.12, possibly backported)
and forbid ARM1136r0, i.e. OMAP2 and i.MX31, from being enabled
in combination with SMP.

This would immediately prevent the bug you are seeing and
allow the cleanups we've been wanting to do for a while,
and it would avoid the larger-scale rework that I had
planned (moving armv6 into an armv5 kernel).

The main reason we didn't do this in the past was that it broke
Tony's workflow of testing omap2plus_defconfig across all
platforms, but I assume this all changed with the new group
maintainership anyway.

The effect here would be that imx_v6_v7_defconfig would
only inlucde imx35 but not imx31, and that omap2plus_defconfig
would turn into effectively omap3plus.

I would still tentatively schedule both for removal in early
2026, but if we add the !SMP dependency it's not a big deal to
keep them around after that either. We can make that decision
next year.

       Arnd