Runtime: Arm6 Framboise PI Zéro - PI 1

Non, il n'y a pas un tel effort. Le plus gros problème à résoudre est probablement que JIT ne prend pas en charge le codage des instructions ARM6 Thumb.

Alors à quoi dois-je m'attendre ? Y a-t-il une chance qu'il y ait un engagement de la part de la communauté ou de MS pour apporter le support Arm6 ou le seul moyen est Mono ?

Je serais fantastique s'il y avait un support pour les processeurs ARMv6 comme Pi Zero et Pi Zero W. Pour certains cas d'utilisation, il n'est pas nécessaire d'utiliser un ARMv7 plus puissant comme Pi 3.

J'adorerais voir ARMv6 pris en charge :)

Je suis d'accord que vous devriez inclure le support pour ARMV6. Je veux exécuter dotnet core dans le Pi Zero en ce moment, je suis coincé avec mono.

Un mot sur le support armv6 ? J'ai deux zéros pi qui n'attendent qu'un but..

@janvorli Si le JIT est le problème, pouvons-nous nous attendre à ce que .Net Core sur CoreRT le permette ?

@dcuccia CoreRT utilise le même compilateur JIT que CoreCLR, donc le problème persiste.

@dcuccia , @mikedn le corert a un mode dans lequel il se compile en C++, ce qui pourrait résoudre le problème. Cependant, j'ai perdu la trace de la quantité de choses qui fonctionnent réellement dans ce mode. @jkotas pouvez-vous s'il vous plaît fournir quelques détails à ce sujet ?

CppCodeGen exécute des programmes simples (hello world, etc.). De https://github.com/dotnet/corert#platform -support : Les grandes fonctionnalités manquantes sont la réflexion, la récupération de place et la gestion des exceptions.

Je suis d'accord que CoreRT + CppCodeGen serait une bonne option pour la portée de la plate-forme.

@jkotas Dois-je lire ceci correctement - en suivant l'exemple de corert -> https://github.com/dotnet/corert/tree/master/samples/WebApi je peux compiler cela avec cppCodeGen et il peut fonctionner sur ma râpe pi zéro?

Ou échouera-t-il toujours en raison du seul fait d'avoir ARMv6?

CppCodeGen est trop incomplet pour l'exemple WebApi. La réflexion et la collecte des ordures devraient d'abord fonctionner.

merci @jkotas - mais alors un bonjour tout le monde et quelques trucs de base IO/httpclient fonctionneront?

httpclient est un morceau de code assez complexe. Vous pouvez essayer, mais je doute que cela fonctionne avec CppCodeGen aujourd'hui.

Y a-t-il une intention de fournir le support pour ARMv6 ?

Je suis également très intéressé par le support ARMv6. Il semble que le noyau se rapproche, mais je ne suis pas qualifié pour bien juger.

Ajout de mon +1 pour le support ARMv6. L'écart de prix entre rPi0w et rPi3 est de 25 $, ce qui rend le Pi Zero W beaucoup plus utile pour les projets IoT où de nombreux appareils sont utilisés. Est-il possible pour nous de réutiliser du code de Mono pour cela ?

Et je suis aussi enclin à être d'accord. Il existe une communauté encore plus grande qui souhaite exécuter un bien meilleur Linux sur le Pi, y compris le Pi Zero, puis uniquement leurs versions prises en charge par la communauté.

Cela va bien au-delà du Pi/Zero, pour ce que ça vaut. La prise en charge d'ARMv6 ouvre les portes à une vaste gamme de microcontrôleurs. Avoir .NET disponible comme choix dans cet écosystème serait d'une grande importance et fournirait beaucoup plus d'intérêt/couverture sur les aspects IoT de CoreRT.

Je considérerais cette étape 1 dans une séquence qui finirait par voir .NET comme une option pour la programmation dans les systèmes d'exploitation en temps réel. En d'autres termes, veuillez ne pas simplement assimiler le support ARMv6 au support Raspberry Pi Zero , car il va beaucoup plus loin que cela dans le sens immédiat (de nombreux autres MCU qui utilisent ce jeu d'instructions, et il ne va nulle part de si tôt pour une faible puissance /cost MCUs), et des mondes au-delà dans un sens plus abstrait (par exemple, voir une cible CoreRT PAL pour FreeRTOS ou similaire).

@metanoic Je suis entièrement d'accord avec vous. Et cela aiderait également le portage d'IoT Edge (https://github.com/Azure/iotedge/issues/12)

On devrait avoir une plateforme IoT entre les mains pour moins de 10$ !

+1

Accepter. En fait, je suis coincé avec Mono :)

Construire des éléments IoT sur armv6. Je suis venu ici triste. Je veux ajouter mon +1 à ce problème.

Quelqu'un a-t-il une mise à jour sur les progrès réalisés à ce sujet ? J'ai juste essayé de penser que cela fonctionnerait comme sur le pi3b +. J'ai oublié que ce sont deux processeurs différents :(

J'ai un vieux Raspberry Pi modèle B (processeur armv6l) et j'aimerais exécuter des projets de base dotnet dessus

J'ai de nombreux mini serveurs basés sur le processeur ARMv6 avec Linux & Mono. J'aimerais les passer au noyau .NET.

Je voterais également pour le support armv6 ! +1

+1 pour le support armv6 !

+1 serait bien d'avoir

OUI!

S'il te plaît!

Ce serait vraiment super !

Juste curieux, y a-t-il une raison technique pour laquelle, par exemple, le runtime Go peut se compiler sur de nombreuses architectures en utilisant le même compilateur, mais pour CoreCLR, il semble un processus beaucoup plus long d'ajouter la prise en charge d'arch ? https://gist.github.com/asukakenji/f15ba7e588ac42795f421b48b8aede63

@mms- oui, il y a une raison technique. Go est précompilé. Il a deux compilateurs - gc qui ne prend en charge que x86 (32 et 64 bits) et arm et gccgo que GCC est son backend. Ainsi, quelles que soient les architectures prises en charge par GCC, ils les obtiennent gratuitement.
CoreCLR utilise JIT, nous sommes donc seuls pour ajouter la prise en charge de nouvelles architectures.

C'est parfaitement logique. Ce serait intéressant si .Net Native pouvait être étendu pour permettre cette même voie pour .Net Core sur ces autres architectures où JIT n'existe pas encore.

Ajout de mon vote pour ARMv6

Nous en avons besoin!

ARMv6 a une tonne d'attrait au-delà de Raspberry Pi Zero. Le module de calcul Raspberry Pi 1, par exemple, exécute ARMv6 et il est beaucoup plus sûr de s'appuyer sur dotnet. Actuellement, le runtime Mono doit être utilisé, ce qui est bien, mais un support dotnet approprié est quelque chose que j'aimerais vraiment.

@richlander

Le support ARMv6 serait génial.

Quelqu'un peut-il expliquer pourquoi Core a besoin de JIT et ne peut donc pas fonctionner sur Armv6, mais Mono peut le faire ? Mono a sûrement JIT car il n'a besoin que du code IL pour s'exécuter - cela doit être JIT sur le CPU local?

Quelqu'un peut-il expliquer pourquoi Core a besoin de JIT et ne peut donc pas fonctionner sur Armv6, mais Mono peut le faire ?

Mono a un JIT différent qui prend en charge Armv6. CoreCLR JIT ne le prend pas en charge. ARM a deux jeux d'instructions - ARM et THUMB. ARM v6 a THUMB, ARM v7 a THUMB2.
Mono JIT compile tout dans le jeu d'instructions ARM, il fonctionne donc à la fois sur Armv6 et v7, mais cela se traduit par une empreinte mémoire du code environ 30 % plus importante.
Les différences entre Armv7 THUMB2 et Armv6 THUMB sont assez importantes et l'ajout de la prise en charge d'Armv6 nécessitera de nombreuses modifications du CoreCLR JIT.

.NET Core 3.0 est sorti, 3.1 est juste au coin de la rue, 5.0 est prévu et il est annoncé comme une plate-forme unifiée .
Blazor utilise Mono, ne peut pas être choisi JIT lors de la création d'un nouveau projet (sélection de la cible), si ARMv7 est sélectionné, alors CoreCLR doit être utilisé si ARMv6 puis Mono-like JIT.

Raspberry Pi 4 coûte au moins 35 $, Pi Zero coûte 5 $, Pi Zero W coûte 10 $. Donc, pour le prix d'un seul Pi 4, vous obtenez 7 Pi Zeros !

Et comme beaucoup d'autres l'ont écrit auparavant, il ne s'agit pas seulement de Raspberry Pi Zero, tous les appareils ARMv6 peuvent exécuter des applications .NET Core.

2,5 ans plus tard on attend toujours 🙂

+1

Il existe un PR appelé support armv6 dans le projet d'exécution : https://github.com/dotnet/runtime/pull/657

Veuillez ajouter ce support

J'attends aussi ce soutien...

La prise en charge d'Armv6 pour le noyau du réseau serait géniale...

Un mot sur le support armv6 ? J'ai deux zéros pi qui n'attendent qu'un but..

Remercier

Veuillez ajouter le support pour armv6

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

Nous sommes ravis de partager qu'à l'avenir, il existe une version de système d'exploitation pour Windows pour l'IoT, Windows 10 IoT Entreprise qui peut répondre à ces besoins.

J'interprète peut-être mal cela, mais cela me fait craindre qu'il n'y ait plus d'IoT Core pour RPi à moins qu'il ne s'agisse d'ARM64.

@miloush Je ne pense pas que ce problème ait quoi que ce soit avec Windows IoT. Le sujet ici est l'ajout de la prise en charge de dotnet au processeur armv6 afin que nous puissions exécuter dotnet sur Raspberry Pi Zero.

@realivanjx en effet mon mauvais

D'après la lecture ci-dessus, il semble que la prise en charge d'ARM6 soit peu probable en raison du travail nécessaire pour le jeu d'instructions du pouce. Quelqu'un d'autre a-t-il de l'expérience dans l'exécution de dotnet core sur d'autres matériels à faible coût comme Orange Pi Zero ?

Le PR #657 pour ajouter ARMv6 a été fermé...

Nous sommes venus ici à cause d'un projet .NET Core dont nous avons besoin pour fonctionner sur un RPi Zeros à l'école car nous avons environ 25x RPi Zeros achetés pour ce projet. Nous n'avons pas et nous n'allons pas acheter 25 nouveaux RPi 3 car .NET Core ne prend pas en charge ARMv6.

Je suppose que je vais réécrire le projet en Golang...

@ eduncan911 Essayez d'emprunter la voie mono. Voici quelques détails.

Net6 devrait prendre en charge plusieurs architectures de processeur via une exécution mono. peut être.

J'utilise plus d'un millier de processeurs ARMv6 via mono. Il y a 3 ans, nous avons introduit le matériel ARMv7, toujours sur mono, mais maintenant nous refactorisons et migrons vers Net core/net standard, donc seuls les petits exécutables seront différents et les bibliothèques sont réutilisées entre mono et net core.

Pareil ici. Je dirige les tableaux de bord au terrain de cricket de Lord à partir de pi 1
et Pi B+ en Mono. Le nouveau kit fonctionne sur Pi 3 en utilisant Net Core. Même
fichiers source, avec un objet principal qui fait le travail. Dans le cadre
et les applications principales, il crée simplement l'objet de service et charge l'application
config dedans.

Bryan Crotaz
Courbe d'argentE

Malheureusement mono est plein de bugs. Des bogues que personne ne corrigera probablement jamais. La plupart d'entre eux sont liés au réseau. Par exemple, sur certains réseaux lorsque le DNS est disponible mais que le trafic normal a un problème - les flux https/ssl ont une fuite de mémoire qui pourrait consommer toute la mémoire. Ou mono ne pouvait pas communiquer sur certains réseaux sans jouer avec la taille MTU. Mais python ou NET Core n'ont pas de problèmes de communication.

Étonnamment, mono est parfois plus rapide que net core, du moins sur ARMv7. Pas toujours, mais je m'attendais à ce que le noyau net gagne la course aux performances avec une énorme marge.

J'ai du mal à croire que Mono regorge de bugs, mais cela peut dépendre de l'application. Blazor WASM est implémenté dans Mono et s'il y avait des problèmes liés au réseau, ce serait un problème majeur.

Mono : de Xamarin à WebAssembly, Blazor et .NET 5

cc @ marek-safar

Je cours en mono sur plusieurs milliers de machines et de nombreuses configurations réseau. Ces bogues ne se produisent pas sur toutes les configurations de machine et de réseau. Ils ont la même image Linux.

Le problème de taille de MTU - 0,3% des installations - sur ces réseaux est reproductible à 100%. Je n'ai absolument aucune idée pourquoi. Mais ssh fonctionne sur ces réseaux et le fait que je doive changer la taille du mtu n'a été découvert que par accident.

Fuite de mémoire SSL Stream - 2% des installations. C'était très difficile à reproduire, au final nous réussissons à le reproduire avec un routeur 4G avec des données consommées, donc seul le dns fonctionne, les autres requêtes ne fonctionnent pas. Mais nous ne pouvions pas le simuler avec le simulateur d'erreur TCP sur un réseau LAN normal. Nous utilisons un routeur 4G et une carte SIM spécifique pour simuler cette fuite. Se produit généralement lors d'une installation avec 4G ou d'autres réseaux sans fil. Il semble que si, en cas d'établissement d'une connexion TCP et HTTPS, la poignée de main TCP ne se termine pas, cela crée une fuite.

De temps en temps, nous rencontrons un bug, parfois il est corrigé en peu de temps, parfois nous le contournons et une fois que je l'ai corrigé en mono et que la pull request a été acceptée (également liée au réseau) :) Mais pour être juste, cette semaine j'ai trouvé (et signalé) un bogue dans NET5 RC1. Pour moi, mono est un excellent logiciel (je travaille avec lui depuis 9 ans) mais il a quelques problèmes dans le code réseau.

Assez juste, mais qualifier Mono de plein de bugs est un peu injuste. Le combo routeur 4G / carte SIM semble certainement être un cas limite, je vous encourage à créer un problème sur Mono repo et à fournir autant d'informations que possible. Même s'il n'est pas résolu, au moins d'autres personnes ayant le même problème peuvent découvrir le bogue. Merci pour vos contributions précédentes aux dépôts Mono/NET5.

Ok, désolé, c'est injuste.

Mais nous venons de perdre plusieurs centaines d'heures de travail à trouver pourquoi certaines installations ont ces problèmes. Mono est particulièrement utilisable pour les applications de courte durée - comme le mobile. Nous avons certaines installations où nous avons plus d'un an de disponibilité, mais parfois c'est problématique.

@michaldobrodenka d' ailleurs ton témoignage est très intéressant !

La prise en charge d'ARMv6 sera-t-elle incluse dans .NET 6.0 ?

Richard Lander a mentionné quelque chose à ce sujet dans les commentaires de l'annonce de .NET 5 Preview 4
https://devblogs.microsoft.com/dotnet/announcing-net-5-preview-4-and-our-journey-to-one-net/#comment -5958

Ma pensée avec cela est que nous utiliserions Mono pour Armv6 dans le cadre de .NET 5.0. Nous avons presque tous les projets liés Mono/Xamarin à 6.0. J'espère que nous pourrons financer une version Mono Armv6 en 6.0.