From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3AD50C52D6F for ; Fri, 2 Aug 2024 14:53:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:Subject:References:In-Reply-To:Message-Id:Cc:To:From:Date: MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=NeqiCTewY5OK6dnUxXzSah7Pl6i0DLqRmBrqL9BR/TE=; b=MiqoQyYoE+e/+N8AgP0dhBFHaS fsXeuYnIgvdp73vSvH96MsR5CJ8DO94Y5+YwS1hrpb4r8xTZ0nA5FrE2EIoP1kCF05lNfsq5BF+wM CzqRBEMMrEzbqCO4Q7DFKNhtMuZ5q+bvfeZ1oGjnQimzzVEy0ic6gXZtzgY8twpTAVg3Wtr0hQXN6 KEnsUHXUx3u5OA2B2BUUV914jdC2lg5WM7wyV3baJrmW7jQW07vazkvDYLfay3n+hJc4nM809jk/s OXiRqTcSN9LWgVLJsJCAfzPC9B6guDpD/3utY62XEEJiUu7tDlnyR/qwN6UwTaIbVk3R8BZwBeQem g+CIhgDQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sZtev-000000098se-3QZ3; Fri, 02 Aug 2024 14:53:33 +0000 Received: from fhigh4-smtp.messagingengine.com ([103.168.172.155]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sZteQ-000000098mk-0hwL for linux-arm-kernel@lists.infradead.org; Fri, 02 Aug 2024 14:53:04 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 809911151A7E; Fri, 2 Aug 2024 10:53:00 -0400 (EDT) Received: from imap51 ([10.202.2.101]) by compute4.internal (MEProxy); Fri, 02 Aug 2024 10:53:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1722610380; x=1722696780; bh=NeqiCTewY5OK6dnUxXzSah7Pl6i0DLqRmBrqL9BR/TE=; b= CwMh6/X2U6PT6fkyX1FBT1JsfIjVZ3kgAfkO2yLBlMb9bn9bHv2QwryYb/YpDcaS yiQ+bf8CtG5VAVn6XgCrT2KI4pidNdCGea+Zf99m0Jyne01bmfSRkVp6wuA4Mahr qDlQrF1SIvlrn5H9E3Q2c1nJZo33mA+CT8IsM8iI4n3zNwF/VzzKi7BOkIUODsiA OOL0jEU8n57kuActqQQsVFswYj5Dd1gPP9FSWbCrcJZKFTcEhCtsKIH195FCc8OA S5iqGyqvAtJTuxrFoF0r74kS0ZRbPPCYkxd5IvBnCqayCtc+/RvXUeO8+rqs/pfV ptF4FVQ2PDDUOWCuZIISHw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1722610380; x= 1722696780; bh=NeqiCTewY5OK6dnUxXzSah7Pl6i0DLqRmBrqL9BR/TE=; b=C Frr7VJUNiuuibLcfn5UYmV9swWudEvOGck9Gs7tn91dBTIdRoQOWOKfHrSaBbmJI GuYaSMWuYYfXBHkaU+X/vUppF97mIPlZUmTI9LMlzbR51mWZFDLGr99F1uS8LzaS KWefimHe0QCJ96KH3RwzrTAMpTDdzQenfzNbBQdUsTj8Y76Fp11nfBrQc5XJVocc kR1xiSXSwCtW5EAqMOqpVlXQHimMOc42+bWu2/niN/y8dSB/ipljIMKjfLDNUx+q hea81+BoCzkWO+FTth3thuWRcFe4EsoXp0kzeEyDBy127odM+XMDnD57FOBhA10q dra4TXi2Cp8G4AlLKon9g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrkedtgdekudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefoggffhffvvefkjghfufgtgfesthhqredtredtjeenucfhrhhomhepfdetrhhn ugcuuegvrhhgmhgrnhhnfdcuoegrrhhnugesrghrnhgusgdruggvqeenucggtffrrghtth gvrhhnpefggedutdekfedufeetgfejteevheekueduffdtueeftedvfeeftdffvddtgfev hfenucffohhmrghinhepkhgvrhhnvghlrdhorhhgpdhophgvnhifrhhtrdhorhhgnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghrnhgusegr rhhnuggsrdguvgdpnhgspghrtghpthhtoheptd X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 20907B6008D; Fri, 2 Aug 2024 10:52:58 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface MIME-Version: 1.0 Date: Fri, 02 Aug 2024 16:52:28 +0200 From: "Arnd Bergmann" To: "Linus Walleij" Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, "Russell King" , "Richard Earnshaw" , "Richard Sandiford" , "Ramana Radhakrishnan" , "Nicolas Pitre" , "Krzysztof Kozlowski" , "Mark Brown" , "Kristoffer Ericson" , "Robert Jarzmik" , "Aaro Koskinen" , "Janusz Krzysztofik" , "Tony Lindgren" , Linux-OMAP , "Nikita Shubin" , linux-samsung-soc@vger.kernel.org, "Andrew Lunn" , "Sebastian Hesselbarth" , "Gregory Clement" , "Jeremy J. Peper" , debian-arm@lists.debian.org, "Dmitry Torokhov" , "Alexandre Torgue" Message-Id: In-Reply-To: References: <2831c5a6-cfbf-4fe0-b51c-0396e5b0aeb7@app.fastmail.com> Subject: Re: [RFC} arm architecture board/feature deprecation timeline Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240802_075302_435361_92A0181D X-CRM114-Status: GOOD ( 43.48 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Aug 1, 2024, at 21:53, Linus Walleij wrote: > On Wed, Jul 31, 2024 at 7:29=E2=80=AFPM Arnd Bergmann = wrote: >> >> This is used for both StrongARM and FA526 CPUs, which are still >> used on a small number of boards. Even the newest chips (moxa >> art, ) are close to 20 years olds but were still in use a few years >> ago. The last Debian release for these was Lenny (5.0). >> >> Dropping compiler support now would be appropriate IMHO, and >> we can drop kernel support in a few years. > > I am actively using the Gemini as my NAS with OpenWrt and there > are several users of it in the OpenWrt community. > > I don't know if there are enough of us to keep ARMv4 support in > GCC, but ARMv4 support has been added to CLANG (along > with ARMv4t), and I have tested to compile kernels for these > devices with CLANG (for testing CFI!) and they work fine, so if > GCC drops it, we can still build them with CLANG where it apparently > isn't a maintenance burden given that it was recently added. > > Maybe CLANG has a more adaptive backend? It's certainly good to have a backup plan, but I also think that if we expect ARMv4 support to be required past gcc-15, we should ask the gcc developers to keep it for a bit longer. Ultimately I think it is best to remove it from gcc, we just need to optimize the timing. More on that below. >> =3D=3D=3D Highmem =3D=3D=3D >> >> Most Arm machines are fine without highmem support and can >> use something like CONFIG_VMSPLIT_2GB to address up to 2GB >> of physical memory. Machines larger than only popped up >> around the time of the Cortex-A15 in 2012 and for the most >> part got replaced by 64-bit chips within a short time. >> In addition, there are also a handful of Cortex-A9 and >> Marvell CPU based machines that have either more than 2GB >> of RAM or a very sparse memory map that requires highmem >> support. >> >> Linus Walleij has done some work towards being able to use >> up to 4GB of RAM with LPAE (Cortex-A7/A15 and later) >> machines, which I think still needs to be finished before >> we can remove support for highmem. > > This is either really hard, or I'm a bad developer. But I keep > churning it. I do feel a little bad about this as well, because much of this was my original idea and I'm just offloading it to you. On the other hand, the continued existence of highmem keeps coming up as an issue and I feel we have to do something about it, see this week's https://lore.kernel.org/lkml/CAHk-=3DwjhQ-TTg40xSP5dP0a1_90LMbxhvX0bsVBd= v3wpQN2xQQ@mail.gmail.com/ >> =3D=3D=3D Gemini, Moxart =3D=3D=3D >> >> These both use the Faraday FA526 CPU core that like >> StrongARM implements ARMv4 rather than ARMv4T with thumb. >> >> The chips are also over 20 years old, but the kernel >> code has been updated and is not a maintenance burden >> by itself, so there is no value in removing these >> machines until StrongARM is also gone. >> >> On the other hand, removing both FA526 and StrongARM >> platforms means we can probably remove ARMv4 (non-T), >> OABI and NWFPE support more quickly if we want, or >> we can wait until a few years after gcc drops ARMv4. >> >> OpenWRT lists the gemini platform as supported in >> https://openwrt.org/docs/techref/targets/gemini, but >> none of the individual machines have builds for the >> current release. >> >> Need input from Linus Walleij. > > Yeah we use these devices. I don't know what counts as big > enough community to be considered, it's at least not just > me. > > Gemini builds are in the official OpenWrt repos: > https://downloads.openwrt.org/releases/23.05.4/targets/gemini/generic/ Ok. From the kernel perspective, there is no benefit in dropping support for gemini specifically as long as there are any users left and we can build it with a version of gcc or clang that has ARMv4 support. Here are my current assumptions for the timeline of when that will happen, please let me know about anything you disagree with: - Gemini will be the last ARMv4 we want to support, all StrongARM and FA536 are already less useful and can be dropped earlier or together with Gemini when it gets to that. - Gemini has no dependency on OABI or NWFPE, since all users with new kernels are on EABI softfloat userland. - There are no remaining users on new kernels with anything other than OpenWRT. - The most recent OpenWRT release is supported for two or more years and uses a one year old kernel at the time of release, as well as the four latest gcc releases. - OpenWRT minimum recommended RAM historically doubles every five or six years and will go up from 128MB to 256MB in one of the next four releases. Marking ARMv4 as deprecated in gcc-15, and removing it gcc-16 would make Openwrt-29.x the last release to have an ARMv4 compiler, using the late-2027 kernel release. The last security updates for that release would be in 2031, +/- 2 years if OpenWRT policies change in the meantime. If you think there will still be enough users upgrading OpenWRT on these in 2030, we can recommend that gcc drops ARMv4 support later, but my feeling is that anything past OpenWRT-29.x is already limited by both the memory bloat problem and the half-life of 20 year old consumer hardware. Arnd