Runtime: Arm6 Raspberry PI Zero - PI 1

No, there is no such effort. Probably the biggest problem that would need to be solved is that JIT doesn't support ARM6 Thumb instruction encoding.

So what should i expect ? Is there is any chance there will be commitment from the community or MS to bring Arm6 support or the only way is Mono ?

I would be fantastic if there is support for ARMv6 cpu like Pi Zero and Pi Zero W. For some use cases there is no need to use a more powerful ARMv7 like Pi 3.

Would love to see ARMv6 supported :)

I agree you should include support for ARMV6. I want to run dotnet core in the Pi Zero right now I'm stuck with mono.

Any word on armv6 support? I have two pi zeros just waiting for a purpose..

@janvorli If the JIT is the problem, could we expect .Net Core on CoreRT to enable this?

@dcuccia CoreRT uses the same JIT compiler as CoreCLR so the problem remains.

@dcuccia, @mikedn the corert has a mode in which it compiles into C++, so that could solve the problem. However, I have lost track on how much stuff actually works in that mode. @jkotas can you please provide some details on that?

CppCodeGen runs simple programs (hello world, etc.). From https://github.com/dotnet/corert#platform-support : The big missing features are reflection, garbage collection, and exception handling.

I agree that CoreRT + CppCodeGen would a good option for platform reach.

@jkotas Do i read this correct - following the example from corert -> https://github.com/dotnet/corert/tree/master/samples/WebApi i can compile that with cppCodeGen and it can run on my rasp pi zero?

Or will it still fail due to only having ARMv6 ?

CppCodeGen is too incomplete for WebApi sample. Reflection and garbage collection would have to work first.

thanks @jkotas - but then a hello world and some basic IO/httpclient stuff will work?

httpclient is a pretty complex piece of code. You can give it a try, but I doubt that it would work with CppCodeGen today.

Is there any intention of providing the support for ARMv6?

I'm also very interested in seeing ARMv6 support. It seems that core is getting close, however I'm not qualified to judge well.

Adding my +1 for ARMv6 support. The price gap between rPi0w and rPi3 is $25, making the Pi Zero W far more useful for IoT projects where a lot of devices are used. Is it possible for us to reuse some code from Mono for this?

And I am also inclined to agree. There is an even bigger community that wants to run a much better Linux on the Pi, including the Pi Zero then just their community supported releases.

This goes far beyond the Pi/Zero, for what it's worth. Supporting ARMv6 opens the doors to a vast array of microcontrollers. Having .NET available as a choice in that ecosystem would be of large significance, and would provide substantially more interest/coverage on the IoT aspects of CoreRT.

I would consider this step 1 in a sequence that would eventually see .NET as an option for programming in real-time operating systems. In other words, please don't simply equate ARMv6 support with Raspberry Pi Zero support, as it goes much farther than that in the immediate sense (many other MCU's that use that instruction set, and it's not going anywhere any time soon for low power/cost MCUs), and worlds beyond in the more abstract sense (e.g. seeing a CoreRT PAL target for FreeRTOS or similar).

@metanoic I fully agree with you. And this would help the porting of IoT Edge as well (https://github.com/Azure/iotedge/issues/12)

We should have an IoT Platform in our hands for less than 10$ !

+1

Agree. Actually i'm stuck with Mono :)

Building some IoT stuff on armv6. Came here sad. Want to add my +1 to this issue.

Anyone have any update on if there's progress being made on this? I just tried thinking it would work as it does on the pi3b+. I forgot that they're two different processors :(

I have an old Raspberry Pi model B (armv6l CPU) and would love to run some dotnet core projects on it

I have many mini servers based on ARMv6 CPU with Linux & Mono. Would like to switch them to .NET core.

Would also vote for armv6 support! +1

+1 for armv6 support!

+1 would be nice to have

YES!

Please!

It would be really great!

Just curious, is there a technical reason why for example the Go runtime can compile to many architectures using the same compiler, yet for CoreCLR it seems a much longer process to add arch support? https://gist.github.com/asukakenji/f15ba7e588ac42795f421b48b8aede63

@mms- yes, there is a technical reason. Go is precompiled. It has two compilers - gc that supports only x86 (32 and 64 bit) and arm and gccgo that GCC as its backend. So whatever architectures are supported by GCC, they get them for free.
CoreCLR uses JIT, so we are on our own to add support for new architectures.

Makes perfect sense. Would be interesting if .Net Native could be expanded to enable this same pathway for .Net Core on these other architectures where JIT doesn't exist yet.

Adding my vote for ARMv6

We need this!

ARMv6 has a ton of appeal beyond Raspberry Pi Zero. Raspberry Pi Compute Module 1, for example, runs ARMv6 and it makes it much safer to rely on dotnet. Currently the Mono runtime has to be used which is fine, but proper dotnet support is something I really would like.

@richlander

ARMv6 support would be awesome.

Can anyone explain why Core needs JIT and so can't run on Armv6, but Mono can? Surely Mono has JIT as it only needs IL code to run - that has to be JITted to the local CPU?

Can anyone explain why Core needs JIT and so can't run on Armv6, but Mono can?

Mono has a different JIT that supports Armv6. CoreCLR JIT doesn't support it. ARM has two instruction sets - ARM and THUMB. ARM v6 has THUMB, ARM v7 has THUMB2.
Mono JIT compiles everything into ARM instruction set, so it works on both Armv6 and v7, but that results in approximately 30% larger memory footprint of the code.
The differences between Armv7 THUMB2 and Armv6 THUMB are quite large and adding support for Armv6 will require quite a lot of changes to the CoreCLR JIT.

.NET Core 3.0 is out, 3.1 is just around the corner, 5.0 is planned and it is advertised as a unified platform.
Blazor is using Mono, can't JIT be chosen when creating a new project (selecting target), if ARMv7 is selected then CoreCLR should be used if ARMv6 then Mono-like JIT.

Raspberry Pi 4 is at least $35, Pi Zero costs $5, Pi Zero W is $10. So for the price of a single Pi 4 You get 7 Pi Zeros!

And as many others wrote before, this isn't just about Raspberry Pi Zero, all ARMv6 devices could run .NET Core apps.

2.5 years later we are still waiting 🙂

+1

There is a PR called armv6 support in the runtime project: https://github.com/dotnet/runtime/pull/657

Please add this support

I'm waiting for this support too...

Armv6 support for net core would be awesome...

Any word on armv6 support? I have two pi zeros just waiting for a purpose..

Thank

Please add support for armv6

https://blogs.windows.com/windowsdeveloper/2020/05/26/build-your-iot-devices-with-windows-for-iot-a-comprehensive-platform-for-every-device-developer/

We are excited to share that going forward, there is one OS release for Windows for IoT, Windows 10 IoT Enterprise that can address these needs.

I might be interpreting this wrong but it makes me worry there will be no more IoT Core for RPi unless it's ARM64.

@miloush I dont think that this issue has anything with Windows IoT. The topic here is adding dotnet support to armv6 processor so we can run dotnet on Raspberry Pi Zero.

@realivanjx indeed my bad

From reading above it seems ARM6 support is unlikely due to work needed for thumb instruction set. Anyone else have experience running dotnet core on other low cost hardware like Orange Pi Zero?

The PR #657 to add ARMv6 was closed...

Came here because of a .NET Core project we need running on a RPi Zeros at the school as we have about 25x RPi Zeros purchased for this project. We don't have, nor are we going to buy 25 new RPi 3s because .NET Core doesn't support ARMv6.

Guess I'll re-write the project in Golang...

@eduncan911 Try going the mono route. Here's some details.

Net6 should support multiple cpu architectures via mono runtime. maybe.

I'm running more than thousand ARMv6 cpu devices via mono. 3 years ago we introduced ARMv7 hardware, still on mono, but now we are refactoring and migrating to Net core/ net standard, so only small executable will be different and libraries are reused between mono and net core.

Same here. I run the scoreboards at Lord’s cricket ground from pi 1
and Pi B+ using Mono. The newer kit runs off Pi 3 using Net Core. Same
source files, with a core object that does the work. In the framework
and core apps it just creates the service object and loads the app
config into it.

Bryan Crotaz
Silver CurvE

Unfortunately mono is full of bugs. Bugs no one will ever probably fix. Most of them network related. For example on some networks when dns is available but normal traffic has a problem - https/ssl streams has a memory leak which could eat whole memory. Or mono could not communicate on some network without playing with MTU size. But python or NET Core doesn't have problems communicating.

Surprisingly, mono is sometimes faster than net core, at least on ARMv7. Not always, but I expected that net core would win performance race by a huge margin.

I find it hard to believe that Mono is full of bugs, but it could depend upon application. Blazor WASM is implemented in Mono and if there were network related issues that would be a major problem.

Mono: from Xamarin to WebAssembly, Blazor, and .NET 5

cc @marek-safar

I run mono on several thousand machines and many network configurations. These bugs does not occur on every machine and network configuration. They have the same linux image.

MTU size problem - 0.3% of installations - on these network is 100% reproducible. I have completely no idea why. But ssh works on these networks and the fact that I have to change mtu size was discovered only by accident.

SSL Stream memory leak - 2% of installations. It was very hard to reproduce, in the end we succeed to reproduce it with 4G router with consumed data, so only dns is working, other request doesn't work. But we couldn't simulate it with tcp error simulator on normal lan network. We use 4G router and specific SIM card to simulate that leak. Usually happens on installation with 4G or other wireless networks. It seems that if in case of establishing TCP & HTTPS connection TCP handshake doesn't complete, it creates a leak.

From time to time we encounter a bug, sometimes it's fixed in short time, sometimes we workaround them and once I've fixed it in mono and pull request was accepted (also related to network) :) But to be fair, this week I found (and reported) a bug in NET5 RC1. To me mono is excellent piece of software (I work with it for 9 years) but has some glitches in network code.

Fair enough, but to characterize Mono as full of bugs is a little unfair. The 4G router/SIM card combo certainly seems like an edge case, I'd encourage you to create an issue on Mono repo and provide as much info as possible. Even if it doesn't get resolved at least others with the same issue can discover the bug. Thanks for your previous contributions to the Mono/NET5 repos.

Ok, sorry, it's unfair.

But we just lost several hundreds man hours finding why some installations have these problems. Mono is especially usable for short lived apps - like mobile. We have some installations where we have more than a year uptime, but sometimes it's problematic.

@michaldobrodenka btw your testimonial is very interesting !

Will ARMv6 support be included in .NET 6.0 ?

Richard Lander mentioned something about it in the comments of .NET 5 Preview 4 announcement
https://devblogs.microsoft.com/dotnet/announcing-net-5-preview-4-and-our-journey-to-one-net/#comment-5958

My thinking with that is that we'd use Mono for Armv6 as part of .NET 5.0. We most all the Mono/Xamarin related projects to 6.0. I'm hoping that we can fund a Mono Armv6 build in 6.0.