Uso de CIAA con ucLinux

[Sebastián Barillaro]

Buenas noches!

De la lectura de otros hilos (y de la web) me ha quedado claro que la mayoría prefiere usar un CortexM con un RTOS, y un CortexA con un full Linux.

Me pregunto si tener una CIAA con ucLinux tendría alguna utilidad para alguien. Quizás exista un lugar para tener las comodidades de un SO de propósito general, (vs RTOS) corriendo en un hardware modesto que pueda aprovecharse.

Es encontrar, si existe, un nuevo uso para la CIAA.

Desde ya, agradezco las opiniones de todos.

Saludos

Sebastián Barillaro

[Ezequiel Garcia]

Hola Sebastián,

Tengo que confesar que no entiendo muy bien cuál es el mercado de la CIAA
(no trabajo con clientes de Argentina, así que no conozco las necesidades del mercado local).

De todos modos, me engancho de tu hilo, para recomendarte FUERTEMENTE que evites usar
uCLinux para cualquier desarrollo serio. Hago hincapié en esto, porque recientemente me pidieron
una capacitación para un proyecto en el que usaban uCLinux, o sea que todavía se considera
un proyecto en uso. Quiero aclarar que no lo es.

uCLinux está MUERTO. No tiene soporte upstream, casi nadie lo usa, lo cuál quiere decir que ante
un problema estás en pampa y la vía. Lo cuál significa, peor calidad del producto, más dolores de
cabeza para los ingenieros, retrasos en los tiempos, etc. etc.

uCLinux nació específicamente para resolver un solo problema: Linux sin MMU.

Sin embargo, en la actualidad, no hay mucho movimiento MMUless, supongo porque ahora todos
quieren más prestaciones. A nivel de kernel Linux -y aunque algunos lo nieguen- la gama más baja
cada día se soporta menos. El kernel es cada día más grande y más pesado, e inclusive los parches
para sumarle opciones para sistemas livianos se han visto rechazados de plano.

Para usar Linux se necesita mucha RAM y CPU. Y para desarrollar un producto, lo mejor es basarse
en algo VIVO, que tenga soporte. El año pasado convencimos a un cliente de dejar uCLinux de lado,
y optar por Buildroot para Nios-II + MMU. Con Buildroot usás todos paquetes nuevos, está bien
mantenido, ante cualquier problema tenés respuesta rápida. Encima, hasta tiene su propio
autobuilder :-)

En mi experiencia, la CIAA actual no es para Linux. Claro, seguramente puedas martillar Linux al punto
de que te entre, o también podés usar un kernel v2.4. Todo eso está muy bien para los científicos
y para los estudiantes. Pero la industria es otra cosa :-) El costo de martillar un kernel puede ser
altísimo (por varias razones) y en todo caso, de tanto martillar podemos terminar por perder todas
las prestaciones que hacen a Linux interesante.

Saludos,
Ezequiel

[martin ribelotta]

Me interesa saber porque decís que uCLinux esta muerto.

La pagina de uCLinux en general no se mantiene porque la rama MMUless entró al mainstream desde hace bastante, pero hoy me bajo el kernel 3.14 (LTS) y tengo soporte para micros MMUless por el tiempo que lo mantengan, aunque, dudo que alguien le haga una actualización a un kernel fuertemente embebido.

En cuanto al volumen de desarrollo, es lógico que sea chico porque la cantidad de SoC mmuless es muy escasa, pero por lo que veo, los fabricantes que tienen micros para mmuless mantienen activamente sus correspondientes ramas.

También es cierto que linux (ya dejemos de llamarlo uCLinux porque es lo mismo) requiere mucha memoria, si consideramos mucho 8/16MB de RAM. Hoy con 32M de RAM podemos correr un sistema linux mmless tranquilamente.

Por supuesto, tenemos que entender que un linux mmless NO es un sistema operativo basado en linux como debian/ubuntu/lalaluntu, sino un sistema FUERTEMENTE embebido que requiere programación a bajo nivel. No se puede pensar en correr un LAMP en un sistema MMUless, pero es perfectamente factible usar toda la infraestructura de linux para nuestras necesidades.

De lo que veo, hay varias tendencias en deep-embedded:

* RTOS que suelen ser mentira lo de la R: Lease FreeRTOS, mbed-os y cosas similares con uso extensivo de memoria dinamica y poco cuidado en la calidad del codigo

* RTOS hard con certificación y heavytouch como RTEMS, eCos, VxWorks, QNX, *OSEK (pero no lo conozco mas que de la CIAA) que pueden ser de pago o no para desarrollos "serios" que requieren verificaciones exhaustivas, cierto control fino de los tiempos y confiabilidad demostrable.

* Embedded linux con o sin soporte MMU (lo que nos define que y como debemos utilizarlo) para manejo de stacks complejos que no requieran trazabilidad predictiva.

Realmente, si Linux en sistemas MMULess esta en abandono, me gustaría ver los indicios de eso mas allá del lógico bajo movimiento que tiene esta vertiente por ser un sector minoritario en el desarrollo del kernel linux, porque lo que veo es exactamente lo contrario, un vivo interés cada vez mayor por Linux como alternativa a frameworks con menos "masa critica" de desarrolladores.

Sobre la pregunta en que se usaria una CIAA-NXP con linux mmuless:

Bueno, en todo lo que se puede usar una CIAA-NXP hoy en día, ya que el control de tiempo real duro, recaería en el M0 asimétrico dejando la tarea de comunicación y gestión de recursos complejos al M4 (que no me vengan a decir nada del tiempo real sobre Ethernet porque eso es un mito como los unicornios rosa invisibles)

Eso existe a dia de hoy? No, de hecho es algo que propongo que se investigue, se trabaje, y si no es viable, se abandone, pero que no se descarte por meras sospechas de abandono de un proyecto que fue tan exitoso (uCLinux) como para terminar en el mainstream del kernel (yo puedo compilar el ultimo kernel que salga con soporte de mmuless si tengo el parche de mi BSP)

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Ezequiel Garcia]

Sospechas? :-)

Cuando hablo de uCLinux, me refiero a la distribución llamada uCLinux. No estoy hablando del kernel.
Aclaro, uCLinux no es un kernel. O al menos yo estoy hablando solamente de la distribución (y por eso
lo comparo con Buildroot).

Considero que está muerto, porque no tiene actividad, como ya expliqué. Ahora vamos a las pruebas:

1. El sitio dice:

""

What is uClinux?

The original uClinux was a derivative of Linux 2.0 kernel intended for microcontrollers without Memory Management Units (MMUs). However, the Linux/Microcontroller Project has grown both in brand recognition and coverage of processor architectures. Today's uClinux as an operating system includes Linux kernel releases for 2.0 2.4 and 2.6 as well as a collection of user applications, libraries and tool chains.
""

El sitio mismo habla de kernels prehistóricos, una señal de abandono del proyecto.

2. Veamos la actividad. 11 correos:

http://mailman.uclinux.org/pipermail/uclinux-dev/2014-September/thread.html

Y comparemos con la de Buildroot, 2117 correos el mes pasado.

http://lists.busybox.net/pipermail/buildroot/2014-September/thread.html

Claro, la mayoría son parches, pero el soporte es claramente excelente. Estas nos son sospechas, es la realidad.
Por supuesto, cada uno es libre de investigar lo que quiera, y de basar sus productos en lo que quiera. Yo simplemente
cuento mi experiencia.

Respecto del kernel y de la viabilidad de MMUless: desde luego que el soporte existe, pero la *realidad* muestra que
cada día el kernel se hace más pesado, se aleja de la gama más baja y los paliativos son *rechazados*.

[martin ribelotta]

Haaaahora siiii!!!!

Ok, lo tomo, LA DISTRO uCLinux no existe en ese sentido.... nada justifica el uso de lo que salga en esa página.

Sin embargo, yo no entiendo uCLinux como una distro, sino como el soporte de linux a sistemas sin mmu.

Por eso la confusión.

Por supuesto, ahi coincido con vos, y aconsejo el uso de un Kernel mainstream parcheado con un BSP/Drivers propios y un mecanismo de construcción, o bien manual, o basado en busybox como sugerís mas arriba.

Y por supuesto, el Kernel se hace cada vez mas grande y con mayor consumo de recursos, es logico al tener a disposición del usuario medio (ya sea embebido o no) procesadores mas potentes.

También hay que notar que el hardware acompaña este crecimiento:

Cuando uCLinux empezó, usaban un modulo con un 68K llamado DragonBallMZ (todavía se pueden ver fotos en la pagina) que tenia como mucho 8M de RAM y corria a 20MHz.

Hoy disponemos con procesadores que tienen controladores de memoria con soporte de mas de 64M y velocidades de 200MHz con buses altamente eficientes y caches de instrucciones y datos (El de la CIAA-NXP por ejemplo)

Supongo que dentro de 10 años, el kernel estará adaptado a los procesadores embebidos que existan en el mercado.

En este sentido, comparto la linea de Torvals de rechazar parches que bajen el consumo de recursos porque pueden introducir vulnerabilidades indeseadas que perjudiquen el target ppal de linux.

[Ezequiel Garcia]

Me acabo de acordar de algo.

On Friday, October 31, 2014 2:06:13 PM UTC-3, El Ruso wrote:

Realmente, si Linux en sistemas MMULess esta en abandono, me gustaría ver los indicios de eso mas allá del lógico bajo movimiento que tiene esta vertiente por ser un sector minoritario en el desarrollo del kernel linux, porque lo que veo es exactamente lo contrario, un vivo interés cada vez mayor por Linux como alternativa a frameworks con menos "masa critica" de desarrolladores.

 
De verdad? Creo que estás poniendo el caballo delante del carro.

No es que haya poco movimiento porque es un sector minoritario del desarrollo (no digamos del kernel, sino de todo el stack Embedded Linux en general). Es al revés, dado que el mercado tira para otro
lado (más y más prestaciones), los desarrolladores son cada vez menos, simplemente porque no hay plata en esa punta. Los desarrolladores kernel no trabajamos en lo que tenemos ganas: viene un SoC
vendor, nos contrata y nos dice que hacer. El rumbo lo fija el mercado, no nuestros deseos :-)

Asimismo, corrigiendo tu correo anterior. No es que haya menos desarrollo porque hay menos SoCs. Hay menos SoCs porque hay menos mercado.

Otra prueba más de como está cayendo el MMUless. El título del mail lo dice todo: "Removal of Nios II NOMMU support in 3.13":

http://lists.rocketboards.org/pipermail/nios2-dev/2014-February/007002.html

Aclaro, yo no tengo nada contra MMUless. A mi me encanta el low end y los bichos chiquitos. Pero tampoco me voy a poner
a negar la realidad.

[martin ribelotta]

El 31 de octubre de 2014, 15:40, martin ribelotta <martinr...@gmail.com> escribió:

Haaaahora siiii!!!!

Ok, lo tomo, LA DISTRO uCLinux no existe en ese sentido.... nada justifica el uso de lo que salga en esa página.

Sin embargo, yo no entiendo uCLinux como una distro, sino como el soporte de linux a sistemas sin mmu.

Por eso la confusión.

Por supuesto, ahi coincido con vos, y aconsejo el uso de un Kernel mainstream parcheado con un BSP/Drivers propios y un mecanismo de construcción, o bien manual, o basado en buildroot como sugerís mas arriba.

Desde ya, todo esto entra tranquilamente en un procesador sin MMU pero con la correcta dimensión de RAM

[martin ribelotta]

Suponiendo una bandono general de todo lo que es linux mmuless a corto plazo, veo un problema porque no hay stacks de software de tan buena calidad como los de Linux en el resto del mercado, dejando al sector de procesadores sin MMU a merced de implementaciones del fabricante, o bien de proyectos bastante vidriosos como LwIP que puede ser una roca si lo configuramos bien, pero tambien es facilisimo transformarlo en un dragon come-memoria.

Con respecto a la cantidad de correos, es lógico (y comparto que es un buen marcador de la salud de un proyecto) ya que buildroot aglomera TODO tipo de arquitecturas (sean o no mmuless) mientras que uCLinux (como distro) es un reducto de chips que originalmente no estaban diseñados para usarse con linux (68k, NIOS, SPARC, principalmente)

Tal vez el problema venga desde el punto de vista en que no hay una "distro" para mmuless. En lo personal, nunca fue un problema para mi, porque en estos sistemas no uso el kernel como un sistema operativo, sino mas bien como un stack de librerías.

Como decía mas arriba, jamas esperaría correr un LAMP en estos aparatos (ya hay SoC suficientemente baratos para no tener que molestarnos en esto)

Pero si el hardware está, no veo ningún daño en usarlo, de hecho, considero que no tiene porque ser un desarrollo mayoritario ni tener que estar en el mainstream (hay infinidad de proyectos que se mantienen fuera del mainstream de linux por propia decisión)

Ya que me pongo a comentar, también veo, revisando la lista de uCLinux, que nunca paso de los 1000 correos al mes, cosa que si lo comparamos con mas del doble de buildroot, claramente nunca existió ese proyecto como tal, sin embargo ha tenido movimiento desde 1999.

De todas formas, recalco que tomamos dos cosas distintas como uCLinux, vos hablabas de la distro que originó el proyecto linux-mmuless y yo hablo de lo que dejó esa distro en el mainstream.

--

[Sebastián Barillaro]

Buenos días!

Interesantísima la discusión. Agradezco y valoro el comentario de todos.

Desconocía BuildRoot. Lo investigaré!

Ya sea BuildRoot, uCLinux (u otro), mi intención es brindar una plataforma operativa sobre la CIAA. Así, aquel que viene usando el
DragonBallMZ con 8MB y quiere actualizar el hardware, puede optar por una CIAA sin tener que enfrentarse a un micro pelado. También, que sirva para el que quiera adaptar su aplicación a la CIAA, y quisiera contar con un SO. Obviamente, no quiero malgastar la energía en algo que tenga tantos martillazos que pierda la forma original y sirva sólo de trofeo. No me interesa ser el Dimitry criollo.

No quiero ir por un linux entero, porque CIAA no lo soporta. No quiero cambiar el chip de la CIAA por uno con MMU.

[Ezequiel Garcia]

Hola Sebastián,

A que te referís con "No quiero ir por un linux entero" ?

[Sebastián Barillaro]

Hola Ezequiel!

Me refiero a que mi objetivo no es poner Linux (entero, con memoria virtual, etc) y empezar a buscar qué micro se lo banca, sino al revés: Teniendo el hardware de la CIAA, qué linux le calza mejor, aunque sepa que sin tener MMU, no podré poner un Linux entero, ni mucho menos ubuntu. Seguramente, algún martillazo le tendré que dar.

[Fernando Lichtschein]

Creo que la necesidad de usar algo como Linux surge cuando hay que pensar en una interfaz humano-máquina donde los embebidos en general y los RTOS no se destacan.

 

Acá hay dos problemas, uno el del tiempo real y otro es el de la memoria, aunque están relacionados. El tiempo real como lo vemos los ingenieros implica que el sistema tiene que responder a eventos externos en un tiempo acotado, si no lo hace falla catastróficamente (a esto le llaman "hard real time"). Está la visión de los bancarios y administrativos que no es tan restrictiva. Los algoritmos de planificación de CPU (o "scheduling") de Linux no son de tiempo real, es decir que no garantizan un tiempo de respuesta acotado. Hay algunas implementaciones que sí lo son pero no las que sacamos de la caja como RedHat, Suse, Debian o Ubuntu. Los RTOS sí los implementan, como por ejemplo EDF.

 

El otro tema es la memoria. Linux usa memoria paginada e implementa memoria virtual por paginado por demanda. El mapeo de direcciones lógicas, es decir las que ven los programas, a físicas las hace el hardware en forma transparente. Por otro lado, las páginas que forman el espacio de memoria de un programa pueden estar o no en memoria, y se traen solamente cuando éstas son referenciadas. En el caso de que un programa haga referencia a una página que no está en memoria se genera una interrupción ("page fault") y el programa queda suspendido hasta que el sistema operativo trae la página de disco y la carga en memoria, una vez que ocurre esto el proceso puede seguir ejecutándose. Esto claramente no es compatible con los requerimientos del tiempo real. Todo esto se debe hacer con apoyo de hardware y parte de esto lo hace la CPU o la MMU (no sé qué funciones tienen las MMU de los microcontroladores, tendría que verlo).

 

Entonces hay que recurrir a otros esquemas de administración de memoria, como el particionado, tanto las particiones fijas como las variables tienen sus problemas, la última se fragmenta y puede necesitar reorganización, lo que lleva tiempo y otra vez interfiere con el Tiempo Real.

 

Capaz que la solución es hermanar un micro con RTOS para la parte de tiempo real con un Linux para lo administrativo como se propuso en este grupo, o buscar alguna alternativa tipo QNX.

 

Saludos,

[Ezequiel Garcia]

Sebastián,

Tu problema no parece ser de MMU o no MMU, sino de RAM. Por lo que veo, las opciones de CIAA tienen mucho menos de 4 MiB de SDRAM. Diría que ese el límite inferior para usar Linux.
Pensá que hoy por hoy un kernel PELADO (sin nada de nada) pesa mucho más de 1 MiB. Imagináte que a eso tenés que sumarle drivers y rootfs. Por eso se habla de 4 MiB como mínimo.

La CIAA actual y Linux están claramente orientados a dos segmentos de la industrial mutuamente excluyentes. Una CIAA para Linux sería básicamente un SOM con un SoC tipo un ARM Cortex-A
(aunque puede ser MIPS o cualquier otra cosa), y como 512 MiB de SDRAM.

PS: Olvidáte de las distribuciones tradicionales como Ubuntu, eso no tiene absolutamente nada que ver con la clase de Linux Embebido que se discute en esta lista.
Pensá más bien en "kernel + rootfs".

On Tuesday, November 4, 2014 2:31:13 PM UTC-3, Sebastián Barillaro wrote:

[Fernando Lichtschein]

Estimados,

Encontré esta página http://www.linux-arm.org/Main/WebHome, aparentemente es "LA" referencia.

Por otro lado confirmé que los Cortex-M no tienen MMU, tienen MPU (Memory Protection Unit) con la que se pueden definir regiones de memoria protegida (eso es bueno).

Por lo poco que pude ver, las implementaciones de Linux en micros chicos son bastante limitadas y con interfaces no gráficas (por ejemplo busybox).

Saludos,

[martin ribelotta]

El 6 de noviembre de 2014, 12:06, Ezequiel Garcia <eleze...@gmail.com> escribió:

Sebastián,

Tu problema no parece ser de MMU o no MMU, sino de RAM. Por lo que veo, las opciones de CIAA tienen mucho menos de 4 MiB de SDRAM. Diría que ese el límite inferior para usar Linux.

Totalmente correcto.

 

Pensá que hoy por hoy un kernel PELADO (sin nada de nada) pesa mucho más de 1 MiB. Imagináte que a eso tenés que sumarle drivers y rootfs. Por eso se habla de 4 MiB como mínimo.

La CIAA-NXP tiene 8MB de RAM externa cambiables a 16MB usando otro chip. Eso es al menos suficiente para correr un kernel+busybox(usando uCLibc). Creo que a eso ya se lo puede considerar un Linux embebido.

 

La CIAA actual y Linux están claramente orientados a dos segmentos de la industrial mutuamente excluyentes. Una CIAA para Linux sería básicamente un SOM con un SoC tipo un ARM Cortex-A
(aunque puede ser MIPS o cualquier otra cosa), y como 512 MiB de SDRAM.

Aclaro que CIAA como proyecto es algo que no depende de ningún hardware en particular.

Dicho esto, la CIAA-NXP, tiene la posibilidad de correr un kernel linux MMUless (y actualmente es el único que podría hacerlo, CIAA-FSL no puede si no la rediseñamos con un K70, CIAA-ST todavía está en prediseño hasta donde se aunque bien planteada podría correr un linux MMUless, CIAA-PIC ni pensarlo, CIAA-Atmel tampoco y no se si exista alguna otra versión de la que no estoy enterado)

El planteamiento de todos estos correros (para resumir) seria:

¿Que problemas resolvería algo así?

¿Que tan útil seria?

¿Que ventajas/desventajas tendría?

El hardware que planteas, seria un Linux entero y completo (con X11, o LAMP o interpretes varios, incluso podría correr una JVM) y está muy lejos de cualquier hardware actual en el proyecto CIAA (aunque me gustaría que se encare por ese lado en futuras versiones)
Eso ya es una computadora industrial propiamente dicha, cosa que estaría buenísimo que se encarara en el marco de la CIAA, pero actualmente, esta solo en las diagramaciones iniciales.

Mas bien, el planteamiento es un Linux mínimo (actuando mas como soporte y librería que como SO) que permita controlar hardware y protocolos complejos como Ethernet/USB/CAN de forma simple y delegue el control de tiempo real al cortex-M0 asimétrico que tiene el SoC (con permiso de los demás SoC) de la CIAA-NXP

 

PS: Olvidáte de las distribuciones tradicionales como Ubuntu, eso no tiene absolutamente nada que ver con la clase de Linux Embebido que se discute en esta lista.
Pensá más bien en "kernel + rootfs".

Creo que nadie en su sano juicio pensaria en un sistema MMUless usando distribuciones como esas, igual ahi nos escapamos totalmente de lo embebido (y no, un celular no es ya un embebido, salvo que hablemos de mi querido nokia 1100)

 

On Tuesday, November 4, 2014 2:31:13 PM UTC-3, Sebastián Barillaro wrote:

Hola Ezequiel!

Me refiero a que mi objetivo no es poner Linux (entero, con memoria virtual, etc) y empezar a buscar qué micro se lo banca, sino al revés: Teniendo el hardware de la CIAA, qué linux le calza mejor, aunque sepa que sin tener MMU, no podré poner un Linux entero, ni mucho menos ubuntu. Seguramente, algún martillazo le tendré que dar.


El martes, 4 de noviembre de 2014 09:53:16 UTC-3, Ezequiel Garcia escribió:

Hola Sebastián,

A que te referís con "No quiero ir por un linux entero" ?

On Monday, November 3, 2014 11:28:55 AM UTC-3, Sebastián Barillaro wrote:

Buenos días!

Interesantísima la discusión. Agradezco y valoro el comentario de todos.

Desconocía BuildRoot. Lo investigaré!

Ya sea BuildRoot, uCLinux (u otro), mi intención es brindar una plataforma operativa sobre la CIAA. Así, aquel que viene usando el
DragonBallMZ con 8MB y quiere actualizar el hardware, puede optar por una CIAA sin tener que enfrentarse a un micro pelado. También, que sirva para el que quiera adaptar su aplicación a la CIAA, y quisiera contar con un SO. Obviamente, no quiero malgastar la energía en algo que tenga tantos martillazos que pierda la forma original y sirva sólo de trofeo. No me interesa ser el Dimitry criollo.

No quiero ir por un linux entero, porque CIAA no lo soporta. No quiero cambiar el chip de la CIAA por uno con MMU.

[martin ribelotta]

El 6 de noviembre de 2014, 12:28, Fernando Lichtschein <flicht...@gmail.com> escribió:

Estimados,

Encontré esta página http://www.linux-arm.org/Main/WebHome, aparentemente es "LA" referencia.

Por otro lado confirmé que los Cortex-M no tienen MMU, tienen MPU (Memory Protection Unit) con la que se pueden definir regiones de memoria protegida (eso es bueno).

El mantener las tablas de MPU degrada muchísimo el rendimiento del sistema en el cambio de contexto.

No tengo los números exactos, pero un planteamiento en el aire me dice que hacer un multiload de 8 registros y otro multistore de 8 registros (optimizado en ensamblador y todo) es bastante mas costoso que solo cambiar el SP.

Por lo que sé, la MPU solo se activa al momento de debuggin. Luego, se mantienen dos regiones de MPU muy basicas que son:

* Kernelspace para el modo supervisor con acceso irrestricto a los 4G de direccionamiento

* Userpsace con acceso RWX al área destinada a aplicaciones

Esto también es un área de investigación:

¿Se puede acelerar el cambio de contexto?

¿Ayuda al sistema?

¿Cuanto degrada la performance en un CPU especifico?

¿Realmente puede prevenir desastres en accesos inválidos?

Todo esto, si bien tiene algun tipo de respuesta teorica, hay que verlo andando para cerrar el caso de forma concisa.

 

Por lo poco que pude ver, las implementaciones de Linux en micros chicos son bastante limitadas y con interfaces no gráficas (por ejemplo busybox).

Es mi idea original.

Creo que el hablar de Linux a secas, dio la mala idea de un sistema con X11 y toda la parafernalia de una distro LSB-compliance, cuando mi planteamiento era mucho mas embebido, al punto de considerar Linux el Kernel+init propio o busybox pelado. (lo cual es TOTALMENTE correcto desde el punto de vista técnico)

 

Saludos,

On Thursday, November 6, 2014 12:06:57 PM UTC-3, Ezequiel Garcia wrote:

Sebastián,

Tu problema no parece ser de MMU o no MMU, sino de RAM. Por lo que veo, las opciones de CIAA tienen mucho menos de 4 MiB de SDRAM. Diría que ese el límite inferior para usar Linux.
Pensá que hoy por hoy un kernel PELADO (sin nada de nada) pesa mucho más de 1 MiB. Imagináte que a eso tenés que sumarle drivers y rootfs. Por eso se habla de 4 MiB como mínimo.

La CIAA actual y Linux están claramente orientados a dos segmentos de la industrial mutuamente excluyentes. Una CIAA para Linux sería básicamente un SOM con un SoC tipo un ARM Cortex-A
(aunque puede ser MIPS o cualquier otra cosa), y como 512 MiB de SDRAM.

PS: Olvidáte de las distribuciones tradicionales como Ubuntu, eso no tiene absolutamente nada que ver con la clase de Linux Embebido que se discute en esta lista.
Pensá más bien en "kernel + rootfs".

On Tuesday, November 4, 2014 2:31:13 PM UTC-3, Sebastián Barillaro wrote:

Hola Ezequiel!

Me refiero a que mi objetivo no es poner Linux (entero, con memoria virtual, etc) y empezar a buscar qué micro se lo banca, sino al revés: Teniendo el hardware de la CIAA, qué linux le calza mejor, aunque sepa que sin tener MMU, no podré poner un Linux entero, ni mucho menos ubuntu. Seguramente, algún martillazo le tendré que dar.


El martes, 4 de noviembre de 2014 09:53:16 UTC-3, Ezequiel Garcia escribió:

Hola Sebastián,

A que te referís con "No quiero ir por un linux entero" ?

On Monday, November 3, 2014 11:28:55 AM UTC-3, Sebastián Barillaro wrote:

Buenos días!

Interesantísima la discusión. Agradezco y valoro el comentario de todos.

Desconocía BuildRoot. Lo investigaré!

Ya sea BuildRoot, uCLinux (u otro), mi intención es brindar una plataforma operativa sobre la CIAA. Así, aquel que viene usando el
DragonBallMZ con 8MB y quiere actualizar el hardware, puede optar por una CIAA sin tener que enfrentarse a un micro pelado. También, que sirva para el que quiera adaptar su aplicación a la CIAA, y quisiera contar con un SO. Obviamente, no quiero malgastar la energía en algo que tenga tantos martillazos que pierda la forma original y sirva sólo de trofeo. No me interesa ser el Dimitry criollo.

No quiero ir por un linux entero, porque CIAA no lo soporta. No quiero cambiar el chip de la CIAA por uno con MMU.

[Diego H Turconi]

Comparto otro link sacado del que publico Fernando …

 

http://opensrc.sec.samsung.com/

 

Saludos cordiales, Diego

 

 

---

[Gustavo Ramoscelli]

Otra página sobre el tema: 

http://www.cnx-software.com/2012/09/26/uclinux-on-cortex-m3m4-mcu-the-costs-performance-and-power-consumption/

  De todas formas, me parece que primero hay que preguntar si hace falta o si sirve un kernel de Linux para un cierto desarrollo particular. En mi opinión, para el hardware actual de la CIAA, FreeOSEK alcanza y sobra en la mayoría de las aplicaciones industriales. Si se requiere un mayor procesamiento, habría que diseñar una CIAA con otro micro (ARM V9 o V11) con velocidad de reloj de 1GHz o mayor.

  Hoy por hoy, me parece que un desarrollador interesado en usar la CIAA en ambientes industriales con requerimientos de tareas de temporización crítica, necesita un RTOS más bien el kernel de Linux (con BusBox, es decir, los comandos y recursos externos), por más que sea una versión del kernel modificada para aplicaciones en tiempo real. 

  Para el desarrollador, es más productivo conocer conceptos básicos de tiempo real como por ejemplo: que es una tarea, cuales son los requerimientos de memoria, tiempos de ejecución, como se diagraman las tareas, que es un programador de tareas, que es una interrupción, mecanismos de comunican entre tareas, etc. A eso le tenemos que agregar los "buses" de comunicación industriales, sistemas Scada, etc. Este enfoque es perpendicular al uso uCLinux y es lo que realmente enriquece el proyecto de la CIAA.

  Todo esto es por supuesto es mi opinión...

Gustavo

[Ezequiel Garcia]

On Thursday, November 6, 2014 12:32:11 PM UTC-3, El Ruso wrote:

Creo que nadie en su sano juicio pensaria en un sistema MMUless usando distribuciones como esas, igual ahi nos escapamos totalmente de lo embebido (y no, un celular no es ya un embebido, salvo que hablemos de mi querido nokia 1100)

 

Me parece que estamos hablando de cosas distintas. Los sistemas "Linux Embebido" es una categoría muy difusa. Diría que los celulares aún están considerados sistemas embebidos dentro de la comunidad de Linux Embebido.
Podés mirar el sitio de la conferencia de Linux Embebido y ver qué tipo de charlas se plantean. El tema es que "embebido" ya no pasa más por la capacidad de procesamiento (un sistema embebido hoy puede tener 2 o 4 cores y un par de gigas de RAM), sino por otras cuestiones.

[martin ribelotta]

El 6 de noviembre de 2014, 13:46, Ezequiel Garcia <eleze...@gmail.com> escribió:

On Thursday, November 6, 2014 12:32:11 PM UTC-3, El Ruso wrote:

Creo que nadie en su sano juicio pensaria en un sistema MMUless usando distribuciones como esas, igual ahi nos escapamos totalmente de lo embebido (y no, un celular no es ya un embebido, salvo que hablemos de mi querido nokia 1100)

 

Me parece que estamos hablando de cosas distintas. Los sistemas "Linux Embebido" es una categoría muy difusa. Diría que los celulares aún están considerados sistemas embebidos dentro de la comunidad de Linux Embebido.

Tal cual, por lo que decís, en tu trabajo los embebidos que tenes a mano son equivalentes a una PC high-end de hace unos cuantos años (no muchos tampoco)

Personalmente coincido en que, los costos de procesadores ahora son irrisorios como para dedicarle horas/hombre al desarrollo de software resource-constraint, pero hay una realidad que es que hoy, las capacidades tecnológicas medias de la fabricación local, están lejos de cubrir los requerimientos de la electrónica requerida por un SoC.

Me explico: En algún momento, se planteó en hecho la CIAA de entrada, como una PC industrial basada en un SoC (masomenos) endurecido (como los automotrices de TI, o los industriales de Freescale) pero se vio que la mayoria de fabricantes argentinos de placas tienen problemas mas allá de los 8 mils de vías y cuatro capas (ya 6 son pocos los que hacen y un diseño con SoCs requiere entre 8 y 12 capas normalmente, con anchos que rondan los 4/5 mils como normal)

Esto es una situación lamentable pero que, eventualmente, confiamos en que mejore (soy optimista al respecto) pero en estos momentos, algo viable es un diseño de no mas de cuatro capas, con un micro que no sea BGA y restricciones de ese estilo.

Creo que igual se pueden hacer muchas cosas con lo que tenemos, y también creo que Linux puede aportar una gran cantidad de código en campos como las comunicaciones y los protocolos, pero que hay que manejarlo con cuidado porque, en definitiva, es un experimento de poner un sistema pensado para una cosa en otra totalmente distinta (recordemos que Linux embebido es exactamente eso, partiendo del lado de las PC)

De todas formas, estos planteamientos, son simplemente aire hasta que no tengamos un linux mmu-less corriendo sobre un Cortex-M4 y hagamos las pruebas correspondientes de si sirve o no...

 

Podés mirar el sitio de la conferencia de Linux Embebido y ver qué tipo de charlas se plantean. El tema es que "embebido" ya no pasa más por la capacidad de procesamiento (un sistema embebido hoy puede tener 2 o 4 cores y un par de gigas de RAM), sino por otras cuestiones.

Jeje, nada que decir, hoy un sistema embebido es tranquilamente un súper ordenador de hace diez años. Tal vez, debamos definir sistema embebido como "el hardware ¿programable? que está diseñado para hacer una tarea especifica" (con todos los inconvenientes que eso podría traer )

También podríamos considerar "sistemas embebidos" a los procesadores de la GPU en una PC (poniéndolos a la par del MCU que controla, por ejemplo, el almacenamiento masivo)

Pero, mas allá del consenso general, sigo planteándome la duda: ¿Los sistemas embebidos no tienden hoy a ser cada vez as "programables", "customizables" y "maleables"? ¿Donde queda la linea divisoria entre embebido y "todo lo otro"? Y de ultima, contradiciéndome totalmente con mi otro mail: ¿Hay realmente una linea divisoria?

Lo que si es seguro, que las necesidades de un tipo de sistema embebido, pueden ser totalmente distintos a los de otros...

También tenemos el mercado, cada vez mas emergente, de sistemas críticos que requieren interfaces HMI complejas y protocolos de comunicación típicos de los servidores y las granjas de procesamiento, aunado al control *extremadamente preciso* de tiempos.

Ejemplo de esta tendencia son los procesadores híbridos como los Vybrid (A5+M4) o los nuevos A15+M4x4 de TI..,

Sobre esa linea (pero varios ordenes de magnitud menor) está el micro de la CIAA-NXP con un M4+M0. Por eso insisto, que mas allá de ser un producto final, es Know-How que sirve y mucho en vista de un desarrollo futuro.

Saludos!

[Ezequiel Garcia]

On Thursday, November 6, 2014 3:02:38 PM UTC-3, El Ruso wrote:

El 6 de noviembre de 2014, 13:46, Ezequiel Garcia <eleze...@gmail.com> escribió:

On Thursday, November 6, 2014 12:32:11 PM UTC-3, El Ruso wrote:

Creo que nadie en su sano juicio pensaria en un sistema MMUless usando distribuciones como esas, igual ahi nos escapamos totalmente de lo embebido (y no, un celular no es ya un embebido, salvo que hablemos de mi querido nokia 1100)

 

Me parece que estamos hablando de cosas distintas. Los sistemas "Linux Embebido" es una categoría muy difusa. Diría que los celulares aún están considerados sistemas embebidos dentro de la comunidad de Linux Embebido.

Tal cual, por lo que decís, en tu trabajo los embebidos que tenes a mano son equivalentes a una PC high-end de hace unos cuantos años (no muchos tampoco)

Personalmente coincido en que, los costos de procesadores ahora son irrisorios como para dedicarle horas/hombre al desarrollo de software resource-constraint, pero hay una realidad que es que hoy, las capacidades tecnológicas medias de la fabricación local, están lejos de cubrir los requerimientos de la electrónica requerida por un SoC.

Me explico: En algún momento, se planteó en hecho la CIAA de entrada, como una PC industrial basada en un SoC (masomenos) endurecido (como los automotrices de TI, o los industriales de Freescale) pero se vio que la mayoria de fabricantes argentinos de placas tienen problemas mas allá de los 8 mils de vías y cuatro capas (ya 6 son pocos los que hacen y un diseño con SoCs requiere entre 8 y 12 capas normalmente, con anchos que rondan los 4/5 mils como normal)

Esto es una situación lamentable pero que, eventualmente, confiamos en que mejore (soy optimista al respecto) pero en estos momentos, algo viable es un diseño de no mas de cuatro capas, con un micro que no sea BGA y restricciones de ese estilo.

Creo que igual se pueden hacer muchas cosas con lo que tenemos, y también creo que Linux puede aportar una gran cantidad de código en campos como las comunicaciones y los protocolos, pero que hay que manejarlo con cuidado porque, en definitiva, es un experimento de poner un sistema pensado para una cosa en otra totalmente distinta (recordemos que Linux embebido es exactamente eso, partiendo del lado de las PC)

De todas formas, estos planteamientos, son simplemente aire hasta que no tengamos un linux mmu-less corriendo sobre un Cortex-M4 y hagamos las pruebas correspondientes de si sirve o no...

 

Podríamos preguntarle a Uwe Kleine-König, que implementó el soporte para los Cortex-M4 de Energy Micro (EFM32), si lo hizo por diversión, o si tenía algún requerimiento específico. Creo haber escuchado que la aplicación sería ultra bajo consumo, pero es una cosa super específica. Puede ser interesante como experimento. Tener un shell pelado no creo que sea muy complicado. Alguien con idea de kernel puede hacerlo en unos días de trabajo.De ahí a tener algo usable...

Me interesa como curiosidad... pero por otro lado, le veo tan poca aplicación, que no estoy seguro que valga la pena invertir tiempo. Si la razón es aprender, creo que es más práctico comprar un par de Beaglebones y ponerse a meter mano.

[martin ribelotta]

El 7 de noviembre de 2014, 19:51, Ezequiel Garcia <eleze...@gmail.com> escribió:

[snip] 

De todas formas, estos planteamientos, son simplemente aire hasta que no tengamos un linux mmu-less corriendo sobre un Cortex-M4 y hagamos las pruebas correspondientes de si sirve o no...

 

Podríamos preguntarle a Uwe Kleine-König, que implementó el soporte para los Cortex-M4 de Energy Micro (EFM32), si lo hizo por diversión, o si tenía algún requerimiento específico. Creo haber escuchado que la aplicación sería ultra bajo consumo, pero es una cosa super específica. Puede ser interesante como experimento. Tener un shell pelado no creo que sea muy complicado. Alguien con idea de kernel puede hacerlo en unos días de trabajo.De ahí a tener algo usable...

Casualmente la semana pasada tuve que revisar el código del Kernel por otras cosas y veo el port a EMF32 en el fucking mainstream del 3.17!!!!! Mi cara de WTF no tuvo comparación...

O sea, EMF32!!!!! Ni siquiera esta el port para LPC43 o el del K70 y tenemos el de EMF32!!!! Que ni siquiera tiene controlador DDR o SDRAM y hay que meterle o una PSRAM incomprable en ningún lado, o una SRAM que te cuesta un ojo de la cara...

Ok, cada día entiendo menos este mundo... jajajajajaja ¿Alguien puede explicarme que criterios hay para meter código en el mainstream?

 

Me interesa como curiosidad... pero por otro lado, le veo tan poca aplicación, que no estoy seguro que valga la pena invertir tiempo. Si la razón es aprender, creo que es más práctico comprar un par de Beaglebones y ponerse a meter mano.

Jeje, yo en un Cortex-A iría en el sentido inverso... investigar como operar en bare-metal de forma mas eficiente, con el objetivo de mejorar los hypervisores o los RTOS que corren sobre ellos.

También está la parte de entender hasta donde se le puede dar predictibilidad a la arquitectura ARMv7 con ejecución especulativa, cache de dos o tres niveles y TLB con entradas no bloqueables.

En ese sentido, Cortex-M3/M4 son ideales siempre y cuando los IP-core acompañen, como un buen controlador DDR/SDRAM, un bus "pulenta" (Preferiblemente AXI) y sin despreciar que tenga cache, pero con capacidad de locking...

En ese sentido ARMv8-R es la panacea a los dos mundos, con capacidades para correr SSOO complejos, pero con adiciones al subsistema de MMU+PMU para que pueda manejar un hypervisor real time.

Si a eso le sumamos los mecanismos TCM (Tightly-coupled memory) para correr el hypervisor y el RTOS, tenemos un sistema hard-rt gestionando un SO complejo como linux con un solo CPU.

Ahora falta que alguien haga silicio de eso... :-(

Saludos!

 

PD: Aclaro que al momento de hacer cosas que tienen que funcionar me decanto por soluciones probadas sobre hardware probado (no va a ser la primera vez que tengo que poner a andar un kernel 2.6.23 sobre un MIPS del año del culo solo porque es lo probado y soportado por el fabricante)

[Ezequiel Garcia]

On Friday, November 7, 2014 10:09:20 PM UTC-3, El Ruso wrote:

El 7 de noviembre de 2014, 19:51, Ezequiel Garcia <eleze...@gmail.com> escribió:

[snip] 

De todas formas, estos planteamientos, son simplemente aire hasta que no tengamos un linux mmu-less corriendo sobre un Cortex-M4 y hagamos las pruebas correspondientes de si sirve o no...

 

Podríamos preguntarle a Uwe Kleine-König, que implementó el soporte para los Cortex-M4 de Energy Micro (EFM32), si lo hizo por diversión, o si tenía algún requerimiento específico. Creo haber escuchado que la aplicación sería ultra bajo consumo, pero es una cosa super específica. Puede ser interesante como experimento. Tener un shell pelado no creo que sea muy complicado. Alguien con idea de kernel puede hacerlo en unos días de trabajo.De ahí a tener algo usable...

Casualmente la semana pasada tuve que revisar el código del Kernel por otras cosas y veo el port a EMF32 en el fucking mainstream del 3.17!!!!! Mi cara de WTF no tuvo comparación...

O sea, EMF32!!!!! Ni siquiera esta el port para LPC43 o el del K70 y tenemos el de EMF32!!!! Que ni siquiera tiene controlador DDR o SDRAM y hay que meterle o una PSRAM incomprable en ningún lado, o una SRAM que te cuesta un ojo de la cara...

Ok, cada día entiendo menos este mundo... jajajajajaja ¿Alguien puede explicarme que criterios hay para meter código en el mainstream?

 

Te lo simplifico un poco, pero básicamente es así: No hay ninguna restricción para agregar soporte para un nuevo device, un nuevo SoC, una nueva arch. En este caso, soportar el EFM32 probablemente no tuvo impacto negativo sobre el resto, y por eso no hay ninguna razón para no hacerlo. Siempre que podemos, tratamos de incrementar el universo de "cosas" soportadas. Si mirás el commit, es relativamente simple. Las modificaciones controversiales, tienen mucha más discusión.

Como te dije, deberíamos preguntarle al developer qué motivaciones tenía. Quizás simplemente le donaron un board y se puso a jugar. Muchas veces se hacen cosas de onda nomás.

[Ezequiel Garcia]

Hola a todos,

Estuve hablando con Uwe Kleine-König de Pengutronix, qué estuvo a cargo de implementar el soporte de los MCU Cortex-M4 de Energy Micro 32 en el Kernel. Dado que él ya hizo una buena parte del trabajo necesario para soportar ARMv7-M, solamente quedaría implementar los drivers: UART y timer son los fundamentales (y son muy fáciles). El irqchip para el NVIC ya está hecho (creo).

Eso es por el lado del kernel. Por el lado de userspace yo no conozco demasiado. Uwe me comentó que ellos usaron la infra de ptxdist con los paquetes de uclinux. Acá está el BSP que hicieron ellos:

http://git-public.pengutronix.de/?p=OSELAS.BSP-EnergyMicro-Gecko.git;a=summary

Respecto de la motivación, como sospechábamos tiene que ver un el consumo de energía. Acá hay un spot publicitario sobre el uCLinux para EFM32:

https://www.youtube.com/watch?v=3WS3pvsOmp4

El video dice que en idle consume 1.6 uA. Esa es la razón (supongo) por la cuál las placas llevan SRAM.

Por otro lado, la CIAA NXP tendría SDRAM, con lo cuál no estoy seguro que sea comparable. Por eso, sigo sin saber si trabajar en portar el kernel para la CIAA NXP es viable desde el punto de vista comercial, pero al menos tenemos un roadmap :-)

Espero que sirva!
Ezequiel

[martin ribelotta]

Gran aporte! Algunos comentarios abajo:

El 10 de noviembre de 2014, 10:04, Ezequiel Garcia <eleze...@gmail.com> escribió:

Hola a todos,

Estuve hablando con Uwe Kleine-König de Pengutronix, qué estuvo a cargo de implementar el soporte de los MCU Cortex-M4 de Energy Micro 32 en el Kernel. Dado que él ya hizo una buena parte del trabajo necesario para soportar ARMv7-M, solamente quedaría implementar los drivers: UART y timer son los fundamentales (y son muy fáciles). El irqchip para el NVIC ya está hecho (creo).

Confirmo:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/irqchip/irq-nvic.c

Con esto, cualquier port de ARMv7M es factible con la misma facilidad que con EMF32.

OT: ¿Desde cuando movieron el subsistema de irq de ARM a los drivers? No me quejo, todo lo contrario, es mas ordenado y facil de agregar arquitecturas, pero me descoloco un poco ver el directorio arm tan... ¿limpio? ¿ordenado?

 

Eso es por el lado del kernel. Por el lado de userspace yo no conozco demasiado. Uwe me comentó que ellos usaron la infra de ptxdist con los paquetes de uclinux. Acá está el BSP que hicieron ellos:

http://git-public.pengutronix.de/?p=OSELAS.BSP-EnergyMicro-Gecko.git;a=summary

Parece que hay commits bastante nuevos. De pengutronix use mucho barebox (dos ordenes de magnitud mejor que u-boot pero con menos desarrollo que este).

 

Respecto de la motivación, como sospechábamos tiene que ver un el consumo de energía. Acá hay un spot publicitario sobre el uCLinux para EFM32:

https://www.youtube.com/watch?v=3WS3pvsOmp4

El video dice que en idle consume 1.6 uA. Esa es la razón (supongo) por la cuál las placas llevan SRAM.

Ok, es es una buena razón, que para muchas aplicaciones hace irrelevante el uso de memoria estática en grandes cantidades (y por lo tanto muy caro)

En el caso de los micros de la CIAA, dudo que se pueda justificar tal costo, pero es bueno tenerlo en mente.

Estoy ciego o en ese video free muestra que tiene ocupados 700k???? De por si, eso es un logro inmenso.. pero supongo que no tiene ni red ni drivers de nada mas que el serial y el timer ;-)

 

Por otro lado, la CIAA NXP tendría SDRAM, con lo cuál no estoy seguro que sea comparable. Por eso, sigo sin saber si trabajar en portar el kernel para la CIAA NXP es viable desde el punto de vista comercial, pero al menos tenemos un roadmap :-)

Ni por lejos, la SDRam de por si solo, consume mas que el CPU en idle, pero ninguna CIAA esta orientada al bajo consumo.

Por lo pronto, esperamos que la CIAA-NXP entre en producción masiba para poder acceder al hardware y ponernos a trabajar en este aspecto.

 

Espero que sirva!
Ezequiel

Un saludo!

 

On Wednesday, October 29, 2014 8:36:32 PM UTC-3, Sebastián Barillaro wrote:

Buenas noches!

De la lectura de otros hilos (y de la web) me ha quedado claro que la mayoría prefiere usar un CortexM con un RTOS, y un CortexA con un full Linux.

Me pregunto si tener una CIAA con ucLinux tendría alguna utilidad para alguien. Quizás exista un lugar para tener las comodidades de un SO de propósito general, (vs RTOS) corriendo en un hardware modesto que pueda aprovecharse.

Es encontrar, si existe, un nuevo uso para la CIAA.

Desde ya, agradezco las opiniones de todos.

Saludos

Sebastián Barillaro

[Ezequiel Garcia]

On Monday, November 10, 2014 11:19:17 AM UTC-3, El Ruso wrote:

Gran aporte! Algunos comentarios abajo:

El 10 de noviembre de 2014, 10:04, Ezequiel Garcia <eleze...@gmail.com> escribió:

Hola a todos,

Estuve hablando con Uwe Kleine-König de Pengutronix, qué estuvo a cargo de implementar el soporte de los MCU Cortex-M4 de Energy Micro 32 en el Kernel. Dado que él ya hizo una buena parte del trabajo necesario para soportar ARMv7-M, solamente quedaría implementar los drivers: UART y timer son los fundamentales (y son muy fáciles). El irqchip para el NVIC ya está hecho (creo).

Confirmo:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/irqchip/irq-nvic.c

Con esto, cualquier port de ARMv7M es factible con la misma facilidad que con EMF32.

OT: ¿Desde cuando movieron el subsistema de irq de ARM a los drivers? No me quejo, todo lo contrario, es mas ordenado y facil de agregar arquitecturas, pero me descoloco un poco ver el directorio arm tan... ¿limpio? ¿ordenado?

 

Hace un par de años ya que no es posible agregar un SoC ARM nuevo y poner el IRQ, el timer y demás en arch/arm/mach-xxx. Se hizo por varias razones, como parte de los esfuerzo devicetree, multiplatform y para evitar conflictos en arch/arm (mucha gente tocando en el mismo lugar).

Las slides de FreeElectrons lo explican en detalle: http://elinux.org/images/a/ad/Arm-soc-checklist.pdf

[gerardo gimenez]

Me tuve que poner a estudiar y los mails me pasaron por arriba, así que contesto el ultimo.

Obviamente que cuando decimos uCLinux estamos hablando de linux sin mmu, y no de la distro.

Está claro que la solución a todas nuestras plegarias es el cortexA5, más el Vybrid con su 176 LQFP, pero bueno, ya me quejé bastante.

Me parece que las premisas a tener en cuanta son:

1º. Tratar de sacar periféricos no estándar de un procesador como el Sitara AM3703 de TI, es complicado, porque son uP pensados para bajo consumo y alta performance. Por eso el IMX28 está tan vigente, te permite laburar con 3V3 y eso te hace toda la electrónica mas robusta y manejable. Sacar electrónica de una BB es un parto.

2º. Los PCB son mas sencillos, si tenés algo LQFP, es un golazo. Punto en contra del K70, solo es BGA256. Pero no es lo mismo que un FCBGA423 de un Sitara AM3703.

3º Los costos de sobredimencionar el procesador son altos, y si salís a competir a mercados donde el costo del equipo es muy relevante como electromedicina, publicidad o industria local, la opción de sobredimencionar el micro no es viable. Por ahí en mercados dónde los precios no son tan relevantes como agro, petróleo o minería; Pero ahí tenés cuestiones más complicadas como ambientes ruidosos, temperaturas y esas cosas que habría que analizar bien si un micro como el AM3703 es la mejor opción.

4º Necesitas manejar varias capas de soft, y un RTOS no se si le da la nafta, o por lo menos no es tan confiable.

Por estas cosas miré el K70 de Freescale, que tiene todos estos chiches, por eso me parece mejor un uClinux que supervitaminar un RTOS.

Memories and memory interfaces
– Up to 1024 KB program flash memory on non-
FlexMemory devices
– Up to 512 KB program flash memory on
FlexMemory devices
– Up to 512 KB FlexNVM on FlexMemory devices
– 16 KB FlexRAM on FlexMemory devices
– Up to 128 KB RAM
– Serial programming interface (EzPort)
– FlexBus external bus interface
– DDR controller interface
– NAND flash controller interface

Human-machine interface
– Graphic LCD controller
– Low-power hardware touch sensor interface (TSI)
– General-purpose input/output

Communication interfaces
– Ethernet controller with MII and RMII interface to external PHY and hardware IEEE 1588 capability
– USB high-/full-/low-speed On-the-Go controller with ULPI interface
– USB high-/full-/low-speed On-the-Go controller with on-chip high speed transceiver
– USB full-/low-speed On-the-Go controller with on-chip transceiver
– USB Device Charger detect
– Two Controller Area Network (CAN) modules
– Three SPI modules
– Two I2C modules
– Six UART modules
– Secure Digital host controller (SDHC)
– Two I2S modules

Saludos!!

--

Giménez Gerardo Daniel.

[Ezequiel Garcia]

On Tuesday, November 11, 2014 12:59:45 AM UTC-3, gerardo wrote:

Me tuve que poner a estudiar y los mails me pasaron por arriba, así que contesto el ultimo.

Obviamente que cuando decimos uCLinux estamos hablando de linux sin mmu, y no de la distro.

Con todo respeto, esto no es "obvio". El resto del mundo le dice Linux a Linux (Kernel) y uCLinux a uCLinux (www.uclinux.org). Linux Kernel funciona con MMU y sin MMU desde hace mucho tiempo.

Cambiando de tema, miren esto:

http://www.spinics.net/lists/u-boot-v2/msg21116.html

Quizás sea *justo* el momento para trabajar en LPC43xx.

[martin ribelotta]

Siiiii!!!! Barebox es 1e128 veces mejor que busybox!!! Puedo atestiguarlo jajajajaja.

[gerardo gimenez]

Ezequiel,

Lo que decís no es tan así, por ejemplo en la pagina de EmCraft, le dicen Linux, a secas, y usan el kernel de uClinux 2.6.33. Solo aclaran entre paréntesis una vez y después hablan siempre de linux. Pero todo esto es anecdótico.

Lo importante es esto:
Nadie piensa en bajar la distro de la pagina de uCLinux, compilar todo con un gcc de hace 10 años, con las app de hace 10 años. Sino usar solo el kernel uCLinux. Ahora bien, llegado a este punto podés usar el kernel uCLinux o bajarte el Kernel Linux y en la configuración del kernel deshabilitar la MMU.

Entiendo que son dos cosas diferentes, lo que pasa es que no lo veo relevante para la discusión. Lo que quiero decir es que lo relevante de la discusión es si tiene sentido la CIAA con uCLinux (o linux-MMUless o linux) o un RTOS al cual sumarle stacks, LCD, HMI, etc!  

Si querés podemos llamarlo simplemente Linux como propuso Martín. 

 

En topología matemática se diría que para que en este espacio estos dos elementos sean distintos faltan definiciones, por ahora son congruentes. Y me parece que estamos en ese punto.

Espero que podamos seguir la discusión y zanjar este escollo, y no te quedes con solo un párrafo de mi email, ya que me interesa tu punto de vista.

Saludos

--

Giménez Gerardo Daniel.

[Ezequiel Garcia]

Mejor no hablemos más de uCLinux :-)

On Tuesday, November 11, 2014 6:01:06 PM UTC-3, gerardo wrote:

Entiendo que son dos cosas diferentes, lo que pasa es que no lo veo relevante para la discusión. Lo que quiero decir es que lo relevante de la discusión es si tiene sentido la CIAA con uCLinux (o linux-MMUless o linux) o un RTOS al cual sumarle stacks, LCD, HMI, etc!  

Eso no lo puedo saber yo, sino los clientes y usuarios de la CIAA. Además, jamás vi un RTOS de cerca, así que no puedo opinar al respecto. Es más, soy yo quién pregunta ¿ "es viable la CIAA con Linux" ? O mejor dicho: ¿alguie va a poner Linux en la CIAA  y usarlo para un desarrollo comercial?

Mi humilde aporte es:

1) La tendencia del Kernel Linux es alejarse del low-end del hardware. Esta tendencia está empujada por el mercado, no por la comunidad.
2) Para correr un Kernel Linux y un rootfs necesitamos mucha RAM. Qué tenga on no tenga MMU no viene al caso.

La CIAA NXP cumple escuetamente, porque tiene 8 MiB de RAM y por esa razón en mi empresa estamos pensando en el tema.

[Gustavo Ramoscelli]

Miraron en openwrt.org? Por ejemplo, el router de mi casa tiene 4 años y no tiene mmu (http://wiki.openwrt.org/toh/d-link/dir-320_revb1). La distro openwrt esta muy completa.

Gustavo

--

[martin ribelotta]

El 11 de noviembre de 2014, 19:14, Ezequiel Garcia <eleze...@gmail.com> escribió:

Con el layout actual de la CIAA-NXP podemos usar una memoria de 4Mx16 (8MBytes) como tiene ahora, o montar una de 8Mx16 (16MBytes) lo que sigue siendo poco pero es mas aceptable.

Si ruteamos una linea mas (A12) (lo que requiere un poco de laburo porque está todo MUY apretando) podemos meterle una de 16Mx16 (32MBytes) o 32Mx16 (se eleva bastante el costo) que ya es mas "normal" para un linux embebido con un buildroot básico, y quizá algunos servicios como un servidor web ligero, o algo ad-hock en C.

Personalmente no estoy del todo contento con la falta de esa linea A12, porque perdemos mucho mas de lo que ganamos, pero en su momento, el diseño priorizaba otras cosas, como E/S y comunicaciones.

Básicamente, tenemos memoria RAM (aparte de porque el micro lo permite) porque en algún momento, yo puse sobre la mesa el argumento de que para comunicaciones y un QoS aceptable, con alta disponibilidad, requeríamos RAM, MUCHA RAM. El micro tiene capacidad para direccionar cuatro chips de 32Mx16 pero es imposible meter eso en el espacio de la placa planteada y mantener todo lo demás (otra vez, para que sea industrial, había que tener E/S confiables o al menos E/S jajajaja)

El punto de mi sugerencia de experimentar con linux en la CIAA-NXP viene por el lado de que, LwIP o cualquier otro stack bare-metal, masomenos-baremetal, o rtos-compliance no tiene ni la décima parte de las pruebas que tiene el stack de linux en campo... Si apuntamos a algo confiable y solido como una roca, pienso que usar el M4 como un vehículo de linux para comunicaciones es lo ideal (el stack de CAN o los mecanismos de buffer serial están al mismo nivel, ni hablar de las implemetaciones de cosas como MODBUS)

Obviamente, si hacemos eso, DEBEMOS dejarle el control de tiempo real al Cortex-M0 que está en la misma pastilla, usando todas las posibilidades de este multicore asimétrico.

Ahora la parte NO tan linda:

La SDRAM no se ha probado todavía hasta donde tengo noticias (si no es así, corrijanme). Estoy bastante seguro que el coneccionado es el correcto, pero queda por probar cual es la frecuencia maxima de operación (84MHz teorico).