Dropping support for Arm32 (.NET 9)

[richlander]

Update: Linux Arm32 will be supported with .NET 9+.

Hey folks -- A couple of us have been talking about the CoreCLR architecture support roadmap. We're hyper-focused on Arm64 and x64 (alpha order). They are both critical to us. As it relates to Arm, all of our effort has gone into Arm64/Armv8. There have been no substantial improvement in Arm32/Armv7. We're not focused on it. We've started to talk about dropping support for it.

Our current thinking is to support Arm32 through .NET 7 and 8 and then end support after that (with .NET 9). We dropped support for Windows Arm32 some time ago. This thinking is specific to CoreCLR, not Mono.

We encourage Arm32 users to migrate to Arm64 if that's a choice. Our best work on Arm is absolutely on the 64-bit side, and there is more coming. Also, we'd absolutely love more (functional or performance) issue reports on Arm64 to improve it further. This can be on Raspberry Pi class devices or on big servers in the cloud.

The IoT space is an important part of the .NET + Arm ecosystem. Raspberry Pi 3 Model B was the first 64-bit capable Pi and has been available since February 2016. We've been waiting since then for Raspberry Pi to announce their 64-bit OS. In fact, I've tested .NET on Raspberry Pi with Manjaro and also other distros while waiting. Yes, I use Raspberry Pi OS 64-bit now. It's great to see the Raspberry Pi Foundation focused on 64-bit enablement, particularly since most of their hardware lineup (including the latest Pi Zero) is Arm64-capable. We also appreciate that they adopt new Debian versions at a decent pace, but that's a separate topic.

Gosh! We've not even shipped .NET 7 and we're already talking about .NET 9? We plan to be shipping new .NET releases to/for you for a long time. This proposed architecture change (a removal of support) is perhaps the most important one we've considered. We're wanting to start a conversation about it and see if our read of your hardware needs is well-informed or not.

There is at least one party that we know has a hard dependency on Arm32. Assuming that Arm32 is still relevant at the start of the .NET 9 project, we won't delete Arm32 support from the codebase, but enable other parties to efficiently maintain it over time as an upstream project. This is similar to other open source projects.

Some folks might ask if we have similar plans for the other 32-bit platforms we support: Wasm and Windows x86. We also have a community supported port of Mono for Armv6. No changes are planned for those projects. For mobile platforms, we follow the requirements of Apple and Google/Android. As they drop support for 32-bit, so will we.

What are your thoughts on this proposed change?

[gfoidl]

won't delete Arm32 support from the codebase, but enable other parties to efficiently maintain it over time as an upstream project.

Can you shed some light on this?
(Or is that too early to be concrete at this time)

[richlander]

There isn't much light to shed.

Today, Samsung has a dependency on Arm32 with their .NET for Tizen offering. We expect that Samsung has a desire to maintain an Arm32 .NET offering for some time. We are aligned with that. We're happy to leave the Arm32 code in place as-is and for the community to maintain it, assuming that there is an active maintainer.

This is very similar to MIPS64. Loongson maintains the MIPS64 code in CoreCLR. Microsoft doesn't maintain it or produce a build for it.

Similarly, IBM maintains .NET for s390x.

We love .NET being supported on various hardware platforms and invest real time into making our partners successful.

[jkoritzinsky]

I'd also like to mention that Samsung also maintains the Linux x86 support in CoreCLR for their .NET for Tizen offering as well (which is quite different from the Windows x86 support maintained by the .NET team due to a variety of reasons).

[hez2010]

I'm fine with dropping arm32 support, but now that .NET is going to focus on x64/arm64, is there any plan to ship .NET to Android and iOS platforms? I'm talking about coreclr and nativeaot, not mono.

[richlander]

No plans toward that end. Fine question. We're currently very focused on CoreCLR for desktop and cloud on Mono for device (with a loose definition of "device"). As Native AOT gets more mature, it may open up new avenues, but that's not a near-term conversation.

[jkotas]

In the meantime, we are happy to accept community contributions that make CoreCLR or Native AOT work on more OSes or architectures.

[Ellerbach]

It feels very reasonable and give some time to be prepared. Yes, small CPU based on ARM are moving to 64 bits. All what is available for the last almost 2 years now is 64 bits. So if you look at the all up period, it's like 5 years to move from Arm32 to Arm64 which seems to be reasonable all up.

[michaldobrodenka]

Arm32 CPUs and devices are still being made.

[EgorBo]

I guess it's worth leaving these two recent updates around arm32:

• Paul Williamson, VP and GM of Client Business at Arm, announced that future Arm Cortex-A CPU cores — such as those powering future smartphones — will become 64-bit only come 2022. That means no hardware support for old 32-bit applications in the future
• Android doesn't currently warn users about running 32-bit apps on 64-bit systems, but this patch from an ARM engineer adds that functionality.

[richlander]

Interesting. Thanks for the share. Arm64 chips w/no 32-bit subsystem is nothing new. They get to use that die space for something else (probably AI)! It's interesting to hear that it may be becoming more mainstream, at least for mobile. More bits means more complex programs can be deployed to those devices.

The trend continues to repeat itself. 8-bit chips were replaced by 16-bit chips for mainline scenarios were replaced by ...

[JensNordenbro]

This is just related to new designs on consumer phones. This will of course lead the way and then trickle slowly down and 15 years later it is 64 bit only all over the place. I do not suggest supporting for 15 y but you guys are way to fast for industrial iot and embedded.

[davealvarado]

I think sunsetting 32-bit makes sense. The major issue I can think of with the timeline is whether the supply chain for Raspberry Pis clears up in the next 2.5 years. I'm not sure that's a clear "things should be back to normal by then".

My main thought is that .Net marketing as a cross-platform, long-term-stable, Arm-friendly development platform is still pretty new. As it gains traction, I would expect more developers in emerging markets to want to learn .Net as a path towards a long-term career. It feels a little like a rug-pull when the only cheap SBCs that would support .Net are the ones you can't get.

All of this is to say, I don't think dropping 32-bit is a problem. I just think that to have the best positive impact on the global developer community, dropping that support should be well-telegraphed (which is beginning with this issue) and given time for developers everywhere to transition (which is tied to the global chip shortage).

[davealvarado]

Nope, I didn't realize the 3B had 64-bit support. I may be conflating chip support and OS support also, I just didn't remember 64-bit being a thing on RPi until the 4 series. If I have that mistaken, I agree that any RPi made in the last 8 years having support is more than good enough.

[richlander]

Right. You can see I've been running .NET Arm64 on Raspberry Pi since .NET Core 3.0: https://gist.github.com/richlander/467813274cea8abc624553ee72b28213. Clearly, the Raspberry Pi folks have had their eye on 64-bit enablement for some time.

[ygoe]

It feels a little like a rug-pull when the only cheap SBCs that would support .Net are the ones you can't get.

You can't get any Raspberry Pi right now or in the foreseeable future. Not 2, not 3, not 4, not Zero. But Orange Pi, Banana Pi and NanoPi are still available. Some of their older (and cheaper) models have no 64-bit support. And their main OS is Armbian which doesn't even declare whether the bits you can download are 32 or 64 bit. Does anybody know that? Anyway, the older and from today's POV still totally sufficient hardware (with the "H3" CPU) will then become kind of obsolete. Newer .NET applications just cannot be used on them anymore, or the hardware cannot be used anymore for them.

How would that look like when you need some "community supported" tools to build an application for arm32 from a Windows develper machine with Visual Studio? Is it still fully integrated in the dotnet CLI or are totally different tools required? I've never used or seen such a community supported platform. Is Mono a fully source-compatible drop-in replacement for .NET? I haven't used Mono since .NET Core came out.

[ygoe]

Oh, I forgot to mention countless IoT devices or PLCs that come with custom CPUs or OS variants that cannot be freely changed. And these devices often have a long lifespan. If their manufacturer says they don't need 64-bit, then it will make those devices incompatible with .NET applications which would be a shame. Investments in .NET applications will then become less worth and maybe even re-implementations in other programming languages might become necessary. At least, it will hinder the adoption of newer .NET versions for the other supported platforms of an application.

[MichalPetryka]

I've never used or seen such a community supported platform.

Linux x86 and FreeBSD are examples of that.

[highwingers]

I activity develop mini projects for raspberry pi zero w...which is arm32. I would hate to drop arm32 support. This would force all my users to upgrade to raspberry pi zero w 2 or something newer.

[highwingers]

I develop Linix services using .net core and then deploy them to pi zero w or older. I love pi4 latest and greatest..but many customers refuse to upgrade.

[vanbukin]

3B, 3B+, 3A+, 4, 400, CM3, CM3+, CM4 and Zero 2 W can run 64bits OS

[richlander]

Sorry, but I'm confused. I'm unaware that .NET Core works on "pi zero w or older". Do you have it working on them?

[highwingers]

Sorry. I meant mono.

https://medium.com/@jwmartinez/how-to-writing-c-on-a-raspberry-pi-zero-w-bda22f7e78de

[richlander]

Right. That isn't going away. That's called out in the issue. This is about CoreCLR.

[highwingers]

I absolutely agree with you. However the issue is people are still using 32 bit version. My build is 32 bit for arm v6 processors. I had many issues building with x64.

[richlander]

Sure, but CoreCLR doesn't support Armv6. It never has. This discussion is about CoreCLR and Armv7. Mono supports Armv6 as a community project. That isn't changing. I tried to clarify those things in the original post.

Does that help?

[highwingers]

Yes. Thank you for clearficaton.

[richlander]

Great.

[scalablecory]

Many apps running on ARM today don't need a large address space, but might want to reduce their working set size.

[richlander]

This is true. Same thing could be said about cloud apps in containers. Many container apps set memory constraints much lower than 1GB, even <100MB. Those apps, however, get the benefit of larger/more registers and address-space randomization (among other things). We think that's a good tradeoff. It also applies to IoT/embedded apps.

The real message is that the team is 64-bit focussed. That's where the value of our work is. This approach is about aligning our offering with where our effort is.

[michaldobrodenka]

@richlander I think Arm32 CoreCLR doesn't need performance optimizations - its performance is OK, but I think it is widely used in embedded world where performance is not the first thing to worry about. But would be nice to have it as a supported platform for some time - as long as big players like NXP manufacture CPUs.

[ygoe]

I'd confirm that. I'd be very happy if arm32 support would simply stay where it is and not go away. Much more happy than seeing any performance improvements, I don't "need" those, the platform availability is much more important.

What's the problem with just leaving arm32 support where it is, without further investments? Does it prevent anything? Does it consume time to keep it in place? Windows still ships with the old .NET Framework that isn't receiving any improvements anymore, yet it's still there, for compatibility.

[PathogenDavid]

I'm on the fence with this one. I personally would like to see all 32-bit things go the way of the dodo, but I do have some reservations about how this affects the people using these devices.

I might feel differently come 2024, but currently I do wonder if it'll still be a little too early to drop it completely. The Pi Foundation is still recommending the 32-bit distribution of Raspberry Pi OS, and my impression has been that they are in no rush to recommend 64-bit as a default. (The 64-bit option is semi-hidden in the imager tool under "Raspberry Pi OS (other)".)

It'd be one thing if there was a path to upgrade an existing 32-bit installation to 64-bit, but as far as I am aware there is not.

A lot of these Raspberry Pis are set up by non-technical people or fledgling student developers who cobbled together their systems through much sweat, tears, and copy+pasting of commands. Their systems aren't documented, asking them to reinstall the OS isn't very far from just asking them to get another Pi.

That being said I definitely don't lament the lack of improvements to Armv7 codegen and such, I would not blame the .NET team for putting Armv7 on bare-minium maintenance-only mode (or even dropping the paid support and letting it be community-supported like Armv6.)

[richlander]

It's more like (EOY) 2026. .NET 8 will ship in November 2023 and be supported for 3 years.

[PathogenDavid]

Ah yeah good point, I was looking at the wrong end.

[shadow-cs]

I think this may make a lot of sense from the platform point of view (reducing the number of targets) including mobile (in the future). But I'm worried about the impact on IoT, I'm not talking about hobbyists now (myself included) when you can always say "buy a newer Pi". But if your considering industry level IoT where you need to support your products for a long time (maybe a decade), this move may discourage people to start even considering .NET in this scenario. This is sort of a shame if you ask me. And you're saying there are other maintainers to do this job for the time being, which may sound reasonable but for smaller companies the risk of depending on someone else than MS, the risk may simply be too high which in the end will move them away from the .NET (an possibly other MS) ecosystem(s).

[richlander]

The underlying statement is that if you rely on 32-bit hardware, you are probably better served by another developer platform. Industrial folks should be happy I'm giving them so much notice for planning.

If you rely on 64-bit hardware (or can reasonably migrate to it), then .NET is a great choice. We're very invested in it, for both Arm and Intel/AMD. We also have direct relationships with all those folks. I don't see this as a "can I trust .NET for the long haul" type topic. We will be supporting 64-bit processors for a long time. No one has to be worried that we're going to drop support for 64-bit processors because we think that 128-bit processors are better.

Let's also be clear that Arm is reducing the scope of their 32-bit business. There are still scenarios were 32-bit is the right choice, but I assume that 32-bit Arm CPU volumes have peaked.

[michaldobrodenka]

We are using dotnet in embedded devices and working with ARMv7 (Arm32) HW (not R Pi based) We are still producing new ARM32 devices in thousands.

[hez2010]

we won't delete Arm32 support from the codebase, but enable other parties to efficiently maintain it over time as an upstream project

@michaldobrodenka The Arm32 support codebase won't be deleted, just the maintainer will be changed to the community driven one so you can still deploy your .NET apps on Arm32 platforms.

[michaldobrodenka]

Btw there was ARMv8/64bit drop-in/pin compatible replacement for CPU we use - but manufacturer dropped it due to lack of interest. Most of users use 32bit version

[ygoe]

The underlying statement is that if you rely on 32-bit hardware, you are probably better served by another developer platform.

Oh, that's new to me. I've always thought that .NET is a good choice also for ARM (not excluding 32-bit). We're already invested in it and would be extremely unhappy to move away from .NET.

The Arm32 support codebase won't be deleted, just the maintainer will be changed to the community driven one so you can still deploy your .NET apps on Arm32 platforms.

That means I can still use dotnet publish -r linux-arm like before?

[marekdovjak]

I also use linux Arm32 in IoT. Someone from MS said that linux ARM32 will be supported as long as there will be Raspbian OS 32bit version available. I'm not sure, but that's I think till 2025 at least. (So .NET 10)

[teo-tsirpanis]

.NET 8 will be supported until December 2025 so it will get you covered.

[Marcus-CM]

.net core + Uno is an attractive alternative to Qt.

Dropping support for a
Arm32 is dropping support for the I.MX6 series application processor that still have a 10year availablity committment from NXP. This is vildly used in industry.

I love to have an good alternative to Qt!

[Werner-Prbk]

Regarding the NXP Product Longevity Program, some of the i.MX6 processors with ARMv7 architecture should be available until December 2035.

[michaldobrodenka]

Regarding the NXP Product Longevity Program, some of the i.MX6 processors with ARMv7 architecture should be available until December 2035.

Also i.MX 7 are based on ARMv7

[AustinWise]

I worked for a company that has a lot of these i.MX6 chips deployed in industrial robots, running Linux. It would be nice if they could continue to use the latest .NET on them. They also have a lot of WindowsCE 6 devices running .NET Compact Framework 3.5, so either way they will manage 🙃 .

[WenceyWang]

It's very strange to use Raspberry Pi as an example of IoT devices. Realworld IoT devices run on SoC much lower-end with much less memory. There's nothing good for these devices to use 64 bits platforms.
Furthermore, these SoCs have a much longer lifecycle than dotnet 7 or 8 or even 10.
(https://www.xilinx.com/about/blogs/xilinx-xclusive-blog/category-2022/amd-extends-product-lifecycle-for-all-7-series-devices-through-at-least-2035.html)
(https://www.st.com/content/st_com/en/about/quality-and-reliability/product-longevity.html)
And since 64 bits platform doesn't make any good for their usage, There are still new silicons designed targeting armhf.
Since there's no hope for the industry to stop producing new arm32 SoCs. Dropping its supports will stop an embedded developer to consider dotnet as a possible choice.

[michaldobrodenka]

Well said, I also don't get the reference to Raspberry Pi, it has very low significance in embedded segment. Beside some minor market share of compute modules it's used almost solely by hobbyists.

[OliverNET]

Please, reconsider your decision and align your support timeline with other non-raspberry-pi arm32-linux distributions and hardware/SoC suppliers. .NET was promoted to support IoT scenarios and the expectation is that you follow the market rules of that market segment (which are those "industry folks" as you named them). Please respect those industry folks using IoT with .NET as eraly-adopters and don't cut them off from their tools many years before hardware/SoC vendors or OS-suppliers do. Reducing your arm32-investment is understandable, but give them more time for migration.

Dropping support for ARM32 in .NET will most probably result in dropping support for arm32 in SDKs like the Azure IoT Hub SDK. We are using arm32 in an Azure IoT project.

So what are alternatives for "industry folks"?

1. Re-Engineer the hardware to use arm64 cpu instead of arm32 cpu, including all external hardware compliance testing. Migrate to an 64-bit OS including build- and testing-environments. Port all self-implemented low-level services from arm32 to arm64. Replace all in-field-devices and have existing customers pay for that. And new customers pay a higher price, because the hardware components are more expensive.

2. Re-Implement the .NET part in some other non-.NET ecosystem and distribute live-updates.

Given the efforts of 1) and 2), i suspect the second one will be the choice in most cases. None the less, this will be substantial impact on projects and arguing to use .NET in the next IoT projects will be very hard (if not impossible). Even if the product will be migrated to arm64 in future because arm32 chips are not available any more or OS support is cancelled, the new chosen ecosystem might be kept.

I loved using .NET on arm32 projects and until reading this announcement, i was convinced that it was a good decision to use .NET. Good developer productivity, no buffer-overflows and memleaks, good and easy to use ecosystem etc.

[ChrML]

There are a fair number of PLCs that still use Arm32, still produced, where no 64-bit support has yet been announced. And since those are long-lived hardware, I think it will be bad to cut support for Arm32 at this time.

[michaldobrodenka]

Can you give examples? Do you expect such hardware to still be prevalent enough by the time .NET 8 goes out of support in Nov 2026?

In IoT & Automation business hardware is expected to be supported much longed than in Home PC or servers. 8 years after last sold is expected & considered minimal.

We switched to dotnet in 2020, this year we will release new version of our central unit based on ARMv7.

[Joe4evr]

An example is Zynq 7000, which will be produced at least until 2035

8 years after last sold is expected & considered minimal.

So that comes down to 2043 in this example. 🤔

[michaldobrodenka]

So that comes down to 2043 in this example. 🤔

We will produce ARMv7 devices for at least 2 years from now - so we should support these devices for at least until 2033. Or migrate to rust or something, but that's a a huge codebase, sharing lot of code with mobile apps+wpf. Not an easy task.

[hez2010]

Or migrate to rust or something, but that's a a huge codebase, sharing lot of code with mobile apps+wpf. Not an easy task.

No worry IMO. This is only a discussion and it is not being committed yet. The decision of whether to drop arm32 support or not is based on user feedbacks and use cases.

[michaldobrodenka]

Or migrate to rust or something, but that's a a huge codebase, sharing lot of code with mobile apps+wpf. Not an easy task.

No worry IMO. This is only a discussion and it is not being committed yet. The decision of whether to drop arm32 support or not is based on user feedbacks and use cases.

From my point o view linux-arm dotnet is stable and performance is great. It doesn't need new performance optimizations. For top performance I would choose different CPU. I just need to stay supported for a while.

[hez2010]

Maybe instead of dropping the support for arm32, we can keep arm32 codebase and move the major work to the community, and let the community to continuously contribute necessary fixes and improvements to the arm32 support in the future (eg. after .NET 10)? Just like the situation of x86 today.

[WenceyWang]

Dropping mainstream support will cause a large number of necessary tools to drop their support on the platform, there's an example of FreeBSD.

microsoft/azure-pipelines-agent#1906 (comment)
also
microsoft/azure-pipelines-agent#3266

It's easy to say "we can let the community do everything". But the result is MS itself won't even accept a community-built PR without an officially supported .Net.

[hez2010]

It's easy to say "we can let the community do everything". But the result is MS itself won't even accept a community-built PR without an officially supported .Net.

It is not quite right when it comes to dotnet runtime. Just see how LoongArch port is being accepted into the mainstream dotnet. It is a completely community driven as well as huge change.

[WenceyWang]

Yep, but it's true for azure-pipelines-agent as they currently support ARM on Linux and they refused the PR to support FreeBSD as there's no official support dotnet on it.

[snikeguo]

It's easy to say "we can let the community do everything". But the result is MS itself won't even accept a community-built PR without an officially supported .Net.

It is not quite right when it comes to dotnet runtime. Just see how LoongArch port is being accepted into the mainstream dotnet. It is a completely community driven as well as huge change.

LoongArch可不是由社区推动的。。。背后后商业支持。

[michaldobrodenka]

rust, python, c, c++, java, go ... none of them has a problem with 32 bit ARM. GO has AOT support for ARMv6 & ARMv7.

Only c# added arm support recently and now there is a discussion about dropping it.

Even obscurity (on linux) as dart can be compiled on linux-arm.

Poor guys who built their hardware on 32 bit ARM and bet on c#, thinking that dotnet is really becoming multiplatform.

[tannergooding]

Several of these that you've listed do not have official arm32 distributions/tooling.

For those that support running on arm32, they often achieve this by virtue of LLVM supporting it. But, not all LLVM support is created equal and the quality of the codegen can often significantly differ from platforms such as x64 or Arm64.

That isn't necessarily a reason to drop arm32 support either, but it is a consideration around what other tooling officially provides vs which is provided via non-standard or community support and the overal quality of what is provided compared to the more broadly used platforms.

[JensNordenbro]

@tannergooding. You are probably right but since dotnet miss this middle ground support from the community it is not the same as with the other platforms.
Please keep it, patch cve:s, and then in net11 let wasm, wasi be the adviced path for legacy.

[ivan-lapitski]

This would be a big blow for industrial embedded iot devices. NXP’s I.mx6 is widely popular in low power/low cost industrial devices.

[AartBluestoke]

There should be a middle ground; something like "like Framework, expect minimal future arm32 improvements - future improvements will be focused on Core and arm64", rather than "lol, arm32 is now borked as it is now unsupported territory on future versions".

In general the community appears "ok" in using components that are still included, and supported in as much as existing functionally is guaranteed, even if certain features are a little behind the times (looking at you Expressions).

A simple "this is no longer a development focus, community patches for feature extensions are welcome" might be able to split the difference between being a timesink for parallel 64/32 work, and leaving legacy users unsupported.

[NCLnclNCL]

support x86 for native aot bro??

[JensNordenbro]

Too early for professional IoT / embedded scenarios.
It is true that also this segment moves to 64-bit but much slower. Keeping it around and included in net10, would help alot. No improvements, just keeping it for cve fix purposes. If wasm, wasi becomes a mature target this can also be the replacement!

[dubnica290]

During recent chip crisis many companies designed IoT devices using old chips due to shortages. Many upgrades were postponed. It would be nice if dropping support for arm32 could be postponed.

[martinkalis]

We have IoT customers with embedded control unit, that is running on Arm 32.
Is .NET platform focused on servers and not for embedded world? Do you suggest we should migrate to Rust asap?

[richlander]

Official answer:

We are NOT dropping Linux Arm32 with .NET 9. It will be supported. There are no plans to revisit this decision.

I apologize for not offering clarity sooner. A number of customers have asked about this and we are happy to support them.

[snikeguo]

However, AOT does not support ARM32,now

[michaldobrodenka]

It would be great, but at least 'Ready to run' is still available

[0xStuart]

RISC-V is growing rapidly and are becoming a serious competitor in the SOC and MCU sector. Maybe the work being done on RISC-V can get rolled into .NET 9 ?