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

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

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.

The combination has always been a bit odd, and aside from the
problems with atomics and barriers, there was also the odd
ARM11MPcore cache handling that got removed in 2560cffd2134
("ARM: Delete ARM11MPCore (ARM11 ARMv6K SMP) support")

> These tablets are not very attractive for hobbyists anymore as the display
> support got broken and eventually deleted due to bitrot. There has been
> some out-of-tree patches/interest to regain display and other features,
> but no major progress really in 10 years or so. The last major mainline
> feature was adding Retu watchdog support that allowed the device to stay
> on longer than 30 seconds after the boot (the hardware watchdog cannot
> be disabled).
>
> I guess in OMAP-land N8x0 is one of the least used/active boards, so if
> it causes "a lot of pain" then maybe could be a candidate for deprecation.
> But with custom kernel config, the board has been pretty stable overall
> between the releases for limited use cases.

Yes, I think it would help a lot to deprecate it, at least this
would save me the work of moving ARMv6 into an ARMv5 compatible
option (I have done the patches, but they are entirely untested
on real hardware and probably incorrect).

Would the timing make any difference to you? I.e. does it help
to keep another year or two, or would dropping it in early 2025
be the same?

We'd also want to coordinate this with the i.MX31 maintainers,
since dropping both together is the only way to remove
ARM1136r0 support.

>> === OMAP1 ===
>> 
>> This is now the only ARMv4T/ARMv5 platform with no
>> DT support, making it a target for removal at some
>> point. Unlike PXA, there are still users, but it seems
>> there are no current plans for a DT conversion.
>> 
>> I would suggest going through the five boards
>> individually to see which ones we can remove in 2025
>> and keep the remaining ones for the moment.
>
> Here situation hasn't changed - all of the boards are equally
> important/useful, at least from a maintainer point of view. The routine
> I use to test/debug kernel releases relies on all of them.

Ok, noted. Since you are doing the testing, that at least means
we have a chance of cleaning up the code gradually towards using
DT. Dmitry has started a migration of platform_data towards
DT compatible device properties, which can be done gradually
for the 22 platform drivers you use. This unfortunately still
leaves the nonstandard dmaengine interface (for UDC), but we
can deal with that later.

     Arnd