Runtime: Arm6 Raspberry PI Zero - PI 1

Nein, es gibt keinen solchen Aufwand. Das wahrscheinlich größte Problem, das gelöst werden müsste, ist, dass JIT die ARM6-Thumb-Befehlscodierung nicht unterstützt.

Was sollte ich also erwarten? Gibt es eine Chance, dass sich die Community oder MS verpflichten, Arm6-Unterstützung zu bringen, oder ist der einzige Weg Mono?

Ich wäre fantastisch, wenn es Unterstützung für ARMv6-CPUs wie Pi Zero und Pi Zero W geben würde. Für einige Anwendungsfälle besteht keine Notwendigkeit, einen leistungsfähigeren ARMv7 wie Pi 3 zu verwenden.

Würde gerne sehen, dass ARMv6 unterstützt wird :)

Ich stimme zu, dass Sie Unterstützung für ARMV6 einschließen sollten. Ich möchte jetzt dotnet core im Pi Zero ausführen, ich stecke bei Mono fest.

Gibt es Informationen zur Unterstützung von armv6? Ich habe zwei Pi-Nullen, die nur auf einen Zweck warten.

@janvorli Wenn JIT das Problem ist, können wir erwarten, dass .Net Core auf CoreRT dies ermöglicht?

@dcuccia CoreRT verwendet denselben JIT-Compiler wie CoreCLR, sodass das Problem weiterhin besteht.

@dcuccia , @mikedn der Corrt hat einen Modus, in dem er in C ++ kompiliert wird, sodass das Problem gelöst werden könnte. Ich habe jedoch den Überblick darüber verloren, wie viel Zeug in diesem Modus tatsächlich funktioniert. @jkotas kannst du bitte ein paar Details dazu geben?

CppCodeGen führt einfache Programme aus (hello world usw.). Von https://github.com/dotnet/corert#platform -support : Die großen fehlenden Funktionen sind Reflektion, Garbage Collection und Ausnahmebehandlung.

Ich stimme zu, dass CoreRT + CppCodeGen eine gute Option für die Plattformreichweite wäre.

@jkotas Habe ich das richtig gelesen - nach dem Beispiel von corert -> https://github.com/dotnet/corert/tree/master/samples/WebApi kann ich das mit cppCodeGen kompilieren und es kann auf meinem RasPi Zero laufen?

Oder wird es immer noch fehlschlagen, weil nur ARMv6 vorhanden ist?

CppCodeGen ist für das WebApi-Beispiel zu unvollständig. Reflection und Garbage Collection müssten erst funktionieren.

danke @jkotas - aber dann funktionieren ein Hallo Welt und einige grundlegende IO/httpclient-Sachen?

httpclient ist ein ziemlich komplexer Code. Sie können es versuchen, aber ich bezweifle, dass es heute mit CppCodeGen funktionieren würde.

Besteht die Absicht, die Unterstützung für ARMv6 bereitzustellen?

Ich bin auch sehr daran interessiert, ARMv6-Unterstützung zu sehen. Es scheint, dass der Kern näher kommt, aber ich bin nicht qualifiziert, das gut zu beurteilen.

Hinzufügen meiner +1 für ARMv6-Unterstützung. Der Preisunterschied zwischen rPi0w und rPi3 beträgt 25 US-Dollar, was den Pi Zero W für IoT-Projekte, bei denen viele Geräte verwendet werden, weitaus nützlicher macht. Können wir dafür Code von Mono wiederverwenden?

Und ich bin auch geneigt, dem zuzustimmen. Es gibt eine noch größere Community, die ein viel besseres Linux auf dem Pi ausführen möchte, einschließlich des Pi Zero, als nur ihre von der Community unterstützten Versionen.

Dies geht weit über den Pi / Zero hinaus, für das, was es wert ist. Die Unterstützung von ARMv6 öffnet die Türen zu einer Vielzahl von Mikrocontrollern. .NET als Option in diesem Ökosystem verfügbar zu haben, wäre von großer Bedeutung und würde wesentlich mehr Interesse/Berichterstattung über die IoT-Aspekte von CoreRT bieten.

Ich würde diesen Schritt 1 in einer Sequenz betrachten, die .NET schließlich als Option für die Programmierung in Echtzeitbetriebssystemen sehen würde. Mit anderen Worten, bitte setzen Sie die ARMv6-Unterstützung nicht einfach mit der Raspberry Pi Zero-Unterstützung gleich , da sie im unmittelbaren Sinne viel weiter geht (viele andere MCUs verwenden diesen Befehlssatz, und es wird in absehbarer Zeit nirgendwo hingehen, um einen geringen Stromverbrauch zu erzielen /cost MCUs) und Welten darüber hinaus im abstrakteren Sinne (z. B. das Sehen eines CoreRT PAL-Ziels für FreeRTOS oder ähnliches).

@metanoic Ich stimme dir voll und ganz zu. Und das würde auch der Portierung von IoT Edge helfen (https://github.com/Azure/iotedge/issues/12)

Wir sollten eine IoT-Plattform für weniger als 10 $ in unseren Händen haben!

+1

Zustimmen. Eigentlich stecke ich bei Mono fest :)

Ein paar IoT-Sachen auf armv6 bauen. Kam traurig hierher. Ich möchte diesem Problem meine +1 hinzufügen.

Hat jemand ein Update, ob es diesbezüglich Fortschritte gibt? Ich habe nur versucht zu denken, dass es so funktionieren würde wie auf dem pi3b +. Ich habe vergessen, dass es sich um zwei verschiedene Prozessoren handelt :(

Ich habe ein altes Raspberry Pi Modell B (armv6l-CPU) und würde gerne einige dotnet-Core-Projekte darauf ausführen

Ich habe viele Miniserver basierend auf ARMv6-CPU mit Linux & Mono. Möchte sie auf .NET Core umstellen.

Würde auch für die Unterstützung von armv6 stimmen! +1

+1 für armv6-Unterstützung!

+1 wäre schön zu haben

JA!

Bitte!

Es wäre wirklich toll!

Nur neugierig, gibt es einen technischen Grund, warum zum Beispiel die Go-Laufzeit mit demselben Compiler für viele Architekturen kompiliert werden kann, aber für CoreCLR scheint es ein viel längerer Prozess zu sein, Arch-Unterstützung hinzuzufügen? https://gist.github.com/asukakenji/f15ba7e588ac42795f421b48b8aede63

@mms- ja, es gibt einen technischen Grund. Go ist vorkompiliert. Es hat zwei Compiler - gc, der nur x86 (32 und 64 Bit) unterstützt, und arm und gccgo, dass GCC als Backend dient. Welche Architekturen auch immer von GCC unterstützt werden, sie erhalten sie kostenlos.
CoreCLR verwendet JIT, daher müssen wir Unterstützung für neue Architekturen hinzufügen.

Macht perfekt Sinn. Es wäre interessant, wenn .Net Native erweitert werden könnte, um denselben Weg für .Net Core auf diesen anderen Architekturen zu ermöglichen, auf denen JIT noch nicht existiert.

Hinzufügen meiner Stimme für ARMv6

Wir brauchen das!

ARMv6 hat eine Menge Anziehungskraft über Raspberry Pi Zero hinaus. Raspberry Pi Compute Module 1 zum Beispiel führt ARMv6 aus und macht es viel sicherer, sich auf dotnet zu verlassen. Derzeit muss die Mono-Laufzeit verwendet werden, was in Ordnung ist, aber eine ordnungsgemäße Dotnet-Unterstützung wäre etwas, das ich wirklich gerne hätte.

@Richlander

ARMv6-Unterstützung wäre genial.

Kann jemand erklären, warum Core JIT benötigt und daher nicht auf Armv6 ausgeführt werden kann, Mono jedoch? Sicherlich verfügt Mono über JIT, da zum Ausführen nur IL-Code benötigt wird - der an die lokale CPU per JIT übertragen werden muss?

Kann jemand erklären, warum Core JIT benötigt und daher nicht auf Armv6 ausgeführt werden kann, Mono jedoch?

Mono hat ein anderes JIT, das Armv6 unterstützt. CoreCLR JIT unterstützt es nicht. ARM hat zwei Befehlssätze - ARM und THUMB. ARM v6 hat THUMB, ARM v7 hat THUMB2.
Mono JIT kompiliert alles in den ARM-Befehlssatz, sodass es sowohl auf Armv6 als auch auf v7 funktioniert, aber das führt zu einem etwa 30 % größeren Speicherbedarf des Codes.
Die Unterschiede zwischen Armv7 THUMB2 und Armv6 THUMB sind ziemlich groß, und das Hinzufügen von Unterstützung für Armv6 erfordert ziemlich viele Änderungen an CoreCLR JIT.

.NET Core 3.0 ist out, 3.1 steht vor der Tür, 5.0 ist geplant und wird als einheitliche Plattform beworben.
Blazor verwendet Mono, JIT kann beim Erstellen eines neuen Projekts (Auswahl des Ziels) nicht ausgewählt werden. Wenn ARMv7 ausgewählt ist, sollte CoreCLR verwendet werden, wenn ARMv6, dann Mono-ähnliches JIT.

Raspberry Pi 4 kostet mindestens 35 $, Pi Zero kostet 5 $, Pi Zero W kostet 10 $. Für den Preis eines einzelnen Pi 4 erhalten Sie also 7 Pi Zeros!

Und wie viele andere bereits geschrieben haben, geht es hier nicht nur um Raspberry Pi Zero, alle ARMv6-Geräte könnten .NET Core-Apps ausführen.

2,5 Jahre später warten wir immer noch 🙂

+1

Es gibt einen PR namens armv6 support im Laufzeitprojekt: https://github.com/dotnet/runtime/pull/657

Bitte fügen Sie diese Unterstützung hinzu

Auf diese Unterstützung warte ich auch...

Armv6-Unterstützung für Net Core wäre großartig ...

Gibt es Informationen zur Unterstützung von armv6? Ich habe zwei Pi-Nullen, die nur auf einen Zweck warten.

Dank

Bitte fügen Sie Unterstützung für armv6 hinzu

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

Wir freuen uns, Ihnen mitteilen zu können, dass es in Zukunft eine Betriebssystemversion für Windows für IoT, Windows 10 IoT Enterprise, gibt, die diese Anforderungen erfüllen kann.

Ich interpretiere das vielleicht falsch, aber es macht mir Sorgen, dass es keinen IoT Core für RPi mehr geben wird, es sei denn, es ist ARM64.

@miloush Ich glaube nicht, dass dieses Problem etwas mit Windows IoT zu tun hat. Das Thema hier ist das Hinzufügen von dotnet-Unterstützung zum armv6-Prozessor, damit wir dotnet auf Raspberry Pi Zero ausführen können.

@realivanjx in der Tat mein schlechtes

Nach dem Lesen oben scheint es unwahrscheinlich, dass die Unterstützung von ARM6 aufgrund der für den Thumb-Befehlssatz erforderlichen Arbeit unwahrscheinlich ist. Hat noch jemand Erfahrung mit dem Ausführen von dotnet core auf anderer kostengünstiger Hardware wie Orange Pi Zero?

Der PR #657 zum Hinzufügen von ARMv6 wurde geschlossen ...

Kam wegen eines .NET Core-Projekts hierher, das wir auf einem RPi Zeros in der Schule ausführen müssen, da wir etwa 25 x RPi Zeros für dieses Projekt gekauft haben. Wir haben keine 25 neuen RPi 3s und werden sie auch nicht kaufen, weil .NET Core ARMv6 nicht unterstützt.

Schätze, ich werde das Projekt in Golang neu schreiben ...

@eduncan911 Versuche es mit der Mono-Route. Hier sind einige Einzelheiten.

Net6 sollte mehrere CPU-Architekturen über die Mono-Laufzeit unterstützen. könnte sein.

Ich betreibe mehr als tausend ARMv6-CPU-Geräte über Mono. Vor 3 Jahren haben wir ARMv7-Hardware eingeführt, immer noch auf Mono, aber jetzt refaktorisieren und migrieren wir auf Net Core/Net Standard, sodass nur kleine ausführbare Dateien unterschiedlich sein werden und Bibliotheken zwischen Mono und Net Core wiederverwendet werden.

Hier gilt das gleiche. Ich betreibe die Anzeigetafeln bei Lord's Cricket Ground von Pi 1
und Pi B+ mit Mono. Das neuere Kit läuft auf Pi 3 mit Net Core. Dasselbe
Quelldateien, mit einem Kernobjekt, das die Arbeit erledigt. Im Rahmen
und Kern-Apps erstellt es einfach das Dienstobjekt und lädt die App
config hinein.

Bryan Crotaz
Silberne KurveE

Leider ist Mono voller Bugs. Fehler, die niemand jemals beheben wird. Die meisten von ihnen sind netzwerkbezogen. Zum Beispiel in einigen Netzwerken, wenn DNS verfügbar ist, aber normaler Datenverkehr ein Problem hat - https/ssl-Streams haben ein Speicherleck, das den gesamten Speicher verbrauchen könnte. Oder Mono konnte in einem Netzwerk nicht kommunizieren, ohne mit der MTU-Größe zu spielen. Aber Python oder NET Core haben keine Kommunikationsprobleme.

Überraschenderweise ist Mono manchmal schneller als Net Core, zumindest auf ARMv7. Nicht immer, aber ich erwartete, dass der Netzkern das Leistungsrennen mit großem Vorsprung gewinnen würde.

Ich finde es schwer zu glauben, dass Mono voller Fehler ist, aber es könnte von der Anwendung abhängen. Blazor WASM ist in Mono implementiert und wenn es netzwerkbezogene Probleme gäbe, wäre das ein großes Problem.

Mono: von Xamarin bis WebAssembly, Blazor und .NET 5

cc @marek-safar

Ich betreibe Mono auf mehreren tausend Maschinen und vielen Netzwerkkonfigurationen. Diese Fehler treten nicht auf jeder Maschine und Netzwerkkonfiguration auf. Sie haben das gleiche Linux-Image.

MTU-Größenproblem - 0,3 % der Installationen - in diesem Netzwerk ist zu 100 % reproduzierbar. Ich habe absolut keine Ahnung warum. Aber ssh funktioniert in diesen Netzwerken und die Tatsache, dass ich die mtu-Größe ändern muss, wurde nur zufällig entdeckt.

SSL-Stream-Speicherleck – 2 % der Installationen. Es war sehr schwer zu reproduzieren, am Ende gelingt es uns, es mit einem 4G-Router mit verbrauchten Daten zu reproduzieren, also funktioniert nur DNS, andere Anfragen funktionieren nicht. Aber wir konnten es nicht mit dem TCP-Fehlersimulator in einem normalen LAN-Netzwerk simulieren. Wir verwenden einen 4G-Router und eine spezielle SIM-Karte, um dieses Leck zu simulieren. Dies geschieht normalerweise bei der Installation mit 4G oder anderen drahtlosen Netzwerken. Es scheint, dass, wenn beim Herstellen einer TCP- und HTTPS-Verbindung der TCP-Handshake nicht abgeschlossen wird, ein Leck entsteht.

Von Zeit zu Zeit stoßen wir auf einen Fehler, manchmal wird er in kurzer Zeit behoben, manchmal umgehen wir ihn und sobald ich ihn in Mono behoben habe und Pull-Request akzeptiert wurde (auch im Zusammenhang mit Netzwerk) :) Aber um fair zu sein, diese Woche habe ich einen Fehler in NET5 RC1 gefunden (und gemeldet). Für mich ist Mono eine hervorragende Software (ich arbeite seit 9 Jahren damit), hat aber einige Störungen im Netzwerkcode.

Fair genug, aber Mono als voller Bugs zu bezeichnen, ist ein wenig unfair. Die Kombination aus 4G-Router und SIM-Karte scheint sicherlich ein Grenzfall zu sein. Ich möchte Sie ermutigen, ein Problem mit Mono Repo zu erstellen und so viele Informationen wie möglich bereitzustellen. Selbst wenn es nicht behoben wird, können zumindest andere mit dem gleichen Problem den Fehler entdecken. Vielen Dank für Ihre bisherigen Beiträge zu den Mono/NET5 Repos.

Okay, tut mir leid, es ist unfair.

Aber wir haben gerade mehrere hundert Arbeitsstunden verloren, um herauszufinden, warum einige Installationen diese Probleme haben. Mono eignet sich besonders für kurzlebige Apps - wie Handys. Wir haben einige Installationen, bei denen wir mehr als ein Jahr Betriebszeit haben, aber manchmal ist es problematisch.

@michaldobrodenka Übrigens, dein Testimonial ist sehr interessant!

Wird ARMv6-Unterstützung in .NET 6.0 enthalten sein?

Richard Lander hat in den Kommentaren zur Ankündigung von .NET 5 Preview 4 etwas darüber erwähnt
https://devblogs.microsoft.com/dotnet/announcing-net-5-preview-4-and-our-journey-to-one-net/#comment -5958

Meine Überlegung dabei ist, dass wir Mono für Armv6 als Teil von .NET 5.0 verwenden würden. Wir haben fast alle Projekte im Zusammenhang mit Mono/Xamarin mit 6.0. Ich hoffe, dass wir einen Mono Armv6-Build in 6.0 finanzieren können.