Runtime: Arm6 Raspberry PI Cero - PI 1

No, no hay tal esfuerzo. Probablemente el mayor problema que debería resolverse es que JIT no es compatible con la codificación de instrucciones ARM6 Thumb.

Entonces, ¿qué debo esperar? ¿Hay alguna posibilidad de que la comunidad o MS se comprometan a brindar soporte para Arm6 o la única forma es Mono?

Sería fantástico si hubiera soporte para CPU ARMv6 como Pi Zero y Pi Zero W. Para algunos casos de uso, no es necesario usar un ARMv7 más potente como Pi 3.

Me encantaría ver compatible con ARMv6 :)

Acepto que debe incluir soporte para ARMV6. Quiero ejecutar dotnet core en Pi Zero ahora mismo, estoy atascado con mono.

¿Alguna palabra sobre el soporte de armv6? Tengo dos ceros pi esperando un propósito..

@janvorli Si el JIT es el problema, ¿podríamos esperar que .Net Core en CoreRT lo habilite?

@dcuccia CoreRT usa el mismo compilador JIT que CoreCLR, por lo que el problema persiste.

@dcuccia , @mikedn the corert tiene un modo en el que se compila en C++, por lo que podría resolver el problema. Sin embargo, he perdido la cuenta de cuántas cosas funcionan realmente en ese modo. @jkotas , ¿puede proporcionar algunos detalles al respecto?

CppCodeGen ejecuta programas simples (hola mundo, etc.). De https://github.com/dotnet/corert#platform -support: Las principales funciones que faltan son la reflexión, la recolección de elementos no utilizados y el manejo de excepciones.

Estoy de acuerdo en que CoreRT + CppCodeGen sería una buena opción para el alcance de la plataforma.

@jkotas ¿Leo esto correctamente? Siguiendo el ejemplo de corert -> https://github.com/dotnet/corert/tree/master/samples/WebApi , ¿puedo compilarlo con cppCodeGen y puede ejecutarse en mi rasp pi zero?

¿O seguirá fallando debido a que solo tiene ARMv6?

CppCodeGen está demasiado incompleto para la muestra de WebApi. La reflexión y la recolección de basura tendrían que funcionar primero.

gracias @jkotas , pero entonces, ¿un hola mundo y algunas cosas básicas de IO/httpclient funcionarán?

httpclient es una pieza de código bastante compleja. Puede intentarlo, pero dudo que funcione con CppCodeGen hoy.

¿Hay alguna intención de brindar soporte para ARMv6?

También estoy muy interesado en ver la compatibilidad con ARMv6. Parece que el núcleo se está acercando, sin embargo, no estoy calificado para juzgar bien.

Agregando mi +1 para soporte ARMv6. La diferencia de precio entre rPi0w y rPi3 es de $25, lo que hace que Pi Zero W sea mucho más útil para proyectos de IoT en los que se utilizan muchos dispositivos. ¿Es posible que reutilicemos algún código de Mono para esto?

Y también me inclino a estar de acuerdo. Hay una comunidad aún más grande que quiere ejecutar un Linux mucho mejor en el Pi, incluido el Pi Zero y luego solo los lanzamientos compatibles con la comunidad.

Esto va mucho más allá del Pi/Zero, por lo que vale. La compatibilidad con ARMv6 abre las puertas a una amplia gama de microcontroladores. Tener .NET disponible como una opción en ese ecosistema sería de gran importancia y proporcionaría mucho más interés/cobertura en los aspectos de IoT de CoreRT.

Consideraría este paso 1 en una secuencia que eventualmente vería a .NET como una opción para programar en sistemas operativos en tiempo real. En otras palabras, no se limite a equiparar la compatibilidad con ARMv6 con la compatibilidad con Raspberry Pi Zero , ya que va mucho más allá de eso en el sentido inmediato (muchas otras MCU que usan ese conjunto de instrucciones, y no irá a ningún lado en el corto plazo por bajo consumo). /cost MCU) y mundos más allá en el sentido más abstracto (por ejemplo, ver un objetivo CoreRT PAL para FreeRTOS o similar).

@metanoic Estoy totalmente de acuerdo contigo. Y esto también ayudaría a la portabilidad de IoT Edge (https://github.com/Azure/iotedge/issues/12)

¡Deberíamos tener una plataforma IoT en nuestras manos por menos de 10 $!

+1

Estar de acuerdo. En realidad estoy atascado con Mono :)

Construyendo algunas cosas de IoT en armv6. Vine aquí triste. Quiero agregar mi +1 a este problema.

¿Alguien tiene alguna actualización sobre si hay progreso en esto? Intenté pensar que funcionaría como lo hace en el pi3b+. Olvidé que son dos procesadores diferentes :(

Tengo una Raspberry Pi modelo B antigua (CPU armv6l) y me encantaría ejecutar algunos proyectos dotnet core en ella.

Tengo muchos mini servidores basados ​​en CPU ARMv6 con Linux y Mono. Me gustaría cambiarlos a .NET core.

¡También votaría por el soporte de armv6! +1

¡+1 para soporte armv6!

+1 sería bueno tener

¡SÍ!

¡Por favor!

¡Sería realmente genial!

Solo por curiosidad, ¿hay alguna razón técnica por la cual, por ejemplo, el tiempo de ejecución de Go puede compilar en muchas arquitecturas usando el mismo compilador, pero para CoreCLR parece un proceso mucho más largo agregar soporte de arquitectura? https://gist.github.com/asukakenji/f15ba7e588ac42795f421b48b8aede63

@mms- sí, hay una razón técnica. Go está precompilado. Tiene dos compiladores: gc que admite solo x86 (32 y 64 bits) y arm y gccgo que GCC como backend. Entonces, independientemente de las arquitecturas compatibles con GCC, las obtienen de forma gratuita.
CoreCLR usa JIT, por lo que estamos solos para agregar soporte para nuevas arquitecturas.

Tiene mucho sentido. Sería interesante si .Net Native pudiera expandirse para habilitar este mismo camino para .Net Core en estas otras arquitecturas donde JIT aún no existe.

Agregar mi voto para ARMv6

¡Necesitamos esto!

ARMv6 tiene mucho atractivo más allá de Raspberry Pi Zero. Raspberry Pi Compute Module 1, por ejemplo, ejecuta ARMv6 y hace que sea mucho más seguro confiar en dotnet. Actualmente, se debe usar el tiempo de ejecución Mono, lo cual está bien, pero el soporte adecuado de dotnet es algo que realmente me gustaría.

@richlander

La compatibilidad con ARMv6 sería increíble.

¿Alguien puede explicar por qué Core necesita JIT y, por lo tanto, no puede ejecutarse en Armv6, pero Mono sí? Seguramente Mono tiene JIT, ya que solo necesita el código IL para ejecutarse, ¿eso tiene que ser JIT en la CPU local?

¿Alguien puede explicar por qué Core necesita JIT y, por lo tanto, no puede ejecutarse en Armv6, pero Mono sí?

Mono tiene un JIT diferente que admite Armv6. CoreCLR JIT no lo admite. ARM tiene dos conjuntos de instrucciones: ARM y THUMB. ARM v6 tiene THUMB, ARM v7 tiene THUMB2.
Mono JIT compila todo en un conjunto de instrucciones ARM, por lo que funciona tanto en Armv6 como en v7, pero eso da como resultado una huella de memoria del código aproximadamente un 30 % mayor.
Las diferencias entre Armv7 THUMB2 y Armv6 THUMB son bastante grandes y agregar soporte para Armv6 requerirá muchos cambios en CoreCLR JIT.

.NET Core 3.0 está disponible, 3.1 está a la vuelta de la esquina, 5.0 está planeado y se anuncia como una plataforma unificada .
Blazor está usando Mono, no se puede elegir JIT al crear un nuevo proyecto (seleccionar destino), si se selecciona ARMv7, entonces se debe usar CoreCLR si ARMv6 entonces JIT similar a Mono.

Raspberry Pi 4 cuesta al menos $35, Pi Zero cuesta $5, Pi Zero W cuesta $10. Entonces, por el precio de un solo Pi 4, ¡obtienes 7 Pi Zeros!

Y como muchos otros escribieron antes, no se trata solo de Raspberry Pi Zero, todos los dispositivos ARMv6 pueden ejecutar aplicaciones .NET Core.

2,5 años después seguimos esperando 🙂

+1

Hay un PR llamado soporte armv6 en el proyecto de tiempo de ejecución: https://github.com/dotnet/runtime/pull/657

Por favor agregue este soporte

Yo también estoy esperando este apoyo...

El soporte de Armv6 para net core sería increíble...

¿Alguna palabra sobre el soporte de armv6? Tengo dos ceros pi esperando un propósito..

Gracias

Agregue soporte para armv6

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

Nos complace compartir que, en el futuro, hay una versión del sistema operativo para Windows para IoT, Windows 10 IoT Enterprise, que puede abordar estas necesidades.

Podría estar interpretando esto mal, pero me preocupa que no haya más IoT Core para RPi a menos que sea ARM64.

@miloush No creo que este problema tenga nada que ver con Windows IoT. El tema aquí es agregar compatibilidad con dotnet al procesador armv6 para que podamos ejecutar dotnet en Raspberry Pi Zero.

@realivanjx de hecho mi error

De la lectura anterior, parece que es poco probable que sea compatible con ARM6 debido al trabajo necesario para el conjunto de instrucciones del pulgar. ¿Alguien más tiene experiencia ejecutando dotnet core en otro hardware de bajo costo como Orange Pi Zero?

Se cerró el PR #657 para agregar ARMv6...

Vine aquí debido a un proyecto de .NET Core que necesitamos ejecutar en un RPi Zeros en la escuela, ya que hemos comprado alrededor de 25x RPi Zeros para este proyecto. No tenemos ni vamos a comprar 25 nuevos RPi 3 porque .NET Core no es compatible con ARMv6.

Supongo que volveré a escribir el proyecto en Golang...

@ eduncan911 Intenta ir por la ruta mono. Aquí hay algunos detalles.

Net6 debería admitir varias arquitecturas de CPU a través del tiempo de ejecución mono. quizás.

Estoy ejecutando más de mil dispositivos de CPU ARMv6 a través de mono. Hace 3 años introdujimos el hardware ARMv7, todavía en mono, pero ahora estamos refactorizando y migrando a Net core/net estándar, por lo que solo los ejecutables pequeños serán diferentes y las bibliotecas se reutilizarán entre mono y net core.

Aquí igual. Corro los marcadores en el campo de cricket de Lord desde pi 1
y Pi B+ usando Mono. El kit más nuevo funciona con Pi 3 usando Net Core. Mismo
archivos fuente, con un objeto central que hace el trabajo. en el marco
y aplicaciones principales, simplemente crea el objeto de servicio y carga la aplicación
config en él.

Bryan Crotaz
Curva plateada

Desafortunadamente, mono está lleno de errores. Errores que nadie probablemente arreglará nunca. La mayoría de ellos relacionados con la red. Por ejemplo, en algunas redes cuando dns está disponible pero el tráfico normal tiene un problema: las transmisiones https/ssl tienen una pérdida de memoria que podría consumir toda la memoria. O mono no podía comunicarse en alguna red sin jugar con el tamaño de MTU. Pero Python o NET Core no tienen problemas para comunicarse.

Sorprendentemente, mono a veces es más rápido que net core, al menos en ARMv7. No siempre, pero esperaba que el núcleo neto ganara la carrera de rendimiento por un amplio margen.

Me cuesta creer que Mono esté lleno de errores, pero podría depender de la aplicación. Blazor WASM está implementado en Mono y si hubiera problemas relacionados con la red, sería un problema importante.

Mono: de Xamarin a WebAssembly, Blazor y .NET 5

cc @ marek-safar

Ejecuto mono en varios miles de máquinas y muchas configuraciones de red. Estos errores no ocurren en todas las máquinas y configuraciones de red. Tienen la misma imagen de Linux.

El problema del tamaño de la MTU (0,3 % de las instalaciones) en esta red es 100 % reproducible. No tengo ni idea de por qué. Pero ssh funciona en estas redes y el hecho de que tengo que cambiar el tamaño de mtu se descubrió solo por accidente.

Fuga de memoria SSL Stream: 2 % de las instalaciones. Fue muy difícil de reproducir, al final logramos reproducirlo con un enrutador 4G con datos consumidos, por lo que solo funciona dns, otras solicitudes no funcionan. Pero no pudimos simularlo con el simulador de errores tcp en una red LAN normal. Usamos un enrutador 4G y una tarjeta SIM específica para simular esa fuga. Suele ocurrir en la instalación con 4G u otras redes inalámbricas. Parece que si en el caso de establecer la conexión TCP y HTTPS, el protocolo de enlace TCP no se completa, crea una fuga.

De vez en cuando encontramos un error, a veces se soluciona en poco tiempo, a veces lo solucionamos y una vez que lo arreglé en mono y se aceptó la solicitud de extracción (también relacionada con la red) :) Pero para ser justos, esta semana encontró (e informó) un error en NET5 RC1. Para mí, mono es una excelente pieza de software (trabajé con él durante 9 años), pero tiene algunas fallas en el código de red.

Está bien, pero caracterizar a Mono como lleno de errores es un poco injusto. La combinación de enrutador 4G/tarjeta SIM ciertamente parece un caso extremo, lo animo a que cree un problema en Mono repo y brinde la mayor cantidad de información posible. Incluso si no se resuelve, al menos otras personas con el mismo problema pueden descubrir el error. Gracias por sus contribuciones anteriores a los repositorios Mono/NET5.

Vale, lo siento, es injusto.

Pero acabamos de perder varios cientos de horas de trabajo para descubrir por qué algunas instalaciones tienen estos problemas. Mono es especialmente útil para aplicaciones de corta duración, como dispositivos móviles. Tenemos algunas instalaciones en las que tenemos más de un año de actividad, pero a veces es problemático.

@michaldobrodenka por cierto, ¡tu testimonio es muy interesante!

¿Se incluirá compatibilidad con ARMv6 en .NET 6.0?

Richard Lander mencionó algo al respecto en los comentarios del anuncio de .NET 5 Preview 4
https://devblogs.microsoft.com/dotnet/annunciando-net-5-preview-4-and-our-journey-to-one-net/#comment -5958

Mi idea es que usaríamos Mono para Armv6 como parte de .NET 5.0. Tenemos la mayoría de los proyectos relacionados con Mono/Xamarin para 6.0. Espero que podamos financiar una compilación Mono Armv6 en 6.0.