Linux Embebido - Toolchain o todo separado?

[Santiago Pérez]

Para los recién iniciados en el mundo de Embedded Linux, aparecen una gran cantidad de herramientas, para armar desde el bootloader, hasta el rootfs y el mismo kernel. Me refiero a:

• U-Boot/Barebox
• Busybox
• uClibc
• deboostrap? otro rootfs? rootfs propio?
  
• Kernel pre compilado? Kernel "a secas"?
• Otros?
  

También hay proyectos integradores que dan "todo" o "casi todo" resuelto. En este punto me refiero a:

• Buildroot
• Yocto project
• OpenEmbedded?
  
• Otros?
  

Alguien a usado alguno de estos o combinaciones que hayan funcionado bien? Recomendaciones?.

Y para incorporar GUI, como por ejemplo Qt?. Alguna experiencia/comentario?

Gracias!

--
Atentamente//With best Regards/Mit freundlichen Grüßen

Santiago Pérez
Ingeniero Electrónico

perez.sgo@gmail.com
Córdoba, Argentina.

[Ezequiel Garcia]

Santiago,

2013/7/11 Santiago Pérez <pere...@gmail.com>:

> Para los recién iniciados en el mundo de Embedded Linux, aparecen una gran
> cantidad de herramientas, para armar desde el bootloader, hasta el rootfs y
> el mismo kernel. Me refiero a:
>
> U-Boot/Barebox

Estos dos son bootloaders. U-Boot es el de-facto industrial y Barebox
es un bicho nuevo. No tenés opciones: estás atado al soporte que te
de el vendor del SoC, que es U-Boot en el 99.99 % de los casos.

> Busybox

Esto es un reemplazo monolítico de los "comandos" más comunes
como el shell, ps, top.. etc.. Reemplaza todos los binarios por un
unico binario.
Se usa *casi* siempre y se reemplazan aquellos que anden mal.

> uClibc

Esta es una implementación de la librería estándar de C. Las opciones
son glibc o uclibc. Hay otras como eglibc, muslibc, ... etc.

> deboostrap? otro rootfs? rootfs propio?

Yo uso Buildroot todos los días para armar mi rootfs. Cada uno tiene sus gustos.
Yocto está siendo muy fogoneado por intel, así que también tiene sus fans.

Inclusive lo estoy usando para armar el toolchain.

> Kernel pre compilado? Kernel "a secas"?

No. El kernel lo tenés que compilar desde los fuentes, configurado ad-hoc
para tu board.

Bah, en realidad TODO lo tenés que compilar desde los fuentes. Para desarrollar
un sistema estable se necesita un setup *reproducible*.

> Otros?
>

De este mail y de los otros mails parecidos me queda la sensación de que
hay mucha gente arrancando con embedded linux, un poco perdidos ante
tanta información.

Linux en general es "all about choices" así que hay mucho para investigar.

Lamentablemente entender el ecosistema no se logra en días, ni
siquiera en meses, lleva un par de añitos de romperse la cabeza y
morfarse mucho código
y mucha documentación.

** Esto no es ni PIC ni .NET **

Así que .... a poner las barbas en remojo! :-)
--
Ezequiel

[Santiago Pérez]

Muchas gracias Ezequiel!.

Saludos,

Santiago

--
Atentamente//With best Regards/Mit freundlichen Grüßen

Santiago Pérez
Ingeniero Electrónico

pere...@gmail.com
Córdoba, Argentina.

--
    Ezequiel

--
-- 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 correos electrónicos, envía un correo electrónico a embebidos32...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.

[Marce]

En mi caso he usado Yocto/poky/buildroot/openwrt  como build system y algunas distribuciones para linux embedded como Angstrom/Ubuntu.

Como dice Ezequiel hay muchas herramientas que todos los buildsystems usan como busybox, uboot, o uLibc (te recomiendo en este ultimo mirar EGLIBC http://en.wikipedia.org/wiki/Embedded_GLIBC que esta pensada para embedded).

Como todo en open source, cada tema es un mundo en si, asi que en mi humilde opinion es primero tener una vista "aerea" del tema y profundizar en lo necesario, sino podes estar toda una vida...

Saludos

[Santiago Pérez]

Gracias Marcelo. Justamente estaba viendo que Yocto Project esta teniendo mucha difusión por todos lados, así que sería interesante probarlo.

Atmel ofrece bastante info al respecto y algunas soluciones bastantes simples con buena documentación y referencia a documentación externa, tanto para sus micros como en general. La página es:

http://www.at91.com/linux4sam/bin/view/Linux4SAM/

Por lo pronto estoy siguiendo esta documentación, que incluyen U-Boot para el Bootloader, un kernel Linux ya compilado para micros de Atmel y BuildRoot para generar el rootfs (en la página ya ofrece un rootfs para los micros de Atmel, pero necesito modificarlo para incorporar Qt), aunque cada paso individual se puede "customizar" y recompilar a gusto (para esto es muy útil las referencias que hacen a las páginas de los proyectos o herramientas).

Saludos!,

Santiago

--
Atentamente//With best Regards/Mit freundlichen Grüßen

Santiago Pérez
Ingeniero Electrónico

pere...@gmail.com
Córdoba, Argentina.

[Diego gonzalez Dondo]

Hola,
mi humilde experiencia hace unos años, con una placa que hice para tesis, fue con u-boot, kernel y Debian.
Descargue, cross-compile y grabe el u-boot en la flash. Probé comandos básico y funcionamiento en general de la placa.
Luego le toco al kernel. Luego de de descargar, configurar y cross-compilar lo grabe en la flash.
Por ultimo debian, la versión que tiene desde hace muchos años para arm. Lo instale en una maquina virtual, lo deje todo configurado y bastante livianito, luego lo descargue en un pen (la placa tenia usb).
El u-boot lanzaba el kernel y este al debian desde el usb o atraves de NFS (net file system).

Se aprende mucho metiendo manos en las configuraciones, ya sea del kernel o del u-boot. y por supuesto cuando algo no anda y hay que escribir un parchesito :D
Cuando se esta haciendo pruebas con el filesystem se vuelve practico levantarlo con NFS. Es decir tener el filesystem en tu maquina con un nfs-server y configurarlo hasta dejarlo como uno quiere.

La opción de buildroot esta muy buena.

Saludos
Diego

El 11 de julio de 2013 12:30, Marce <mlore...@gmail.com> escribió:

[matías perret cantoni]

Hola Santiado, cómo andas? Vi que te respondieron sobre las herramientas, bootloader, etc.. Mi experiencia en el tema no es mucha, pero para el tema de Qt puedo aportar algo. Te adjunto una guía que hicimos con un compañero de la facultad en nuestra práctica profesional. Tiene varias cosas; nosotros usamos LTIB para generarar la imagen del bootloader y del kernel y el sistema de archivos; y finalmente cross-compilamos las librerias de Qt y las metimos en el sistema de archivos. No sé si es lo que necesitaras, pero espero que te sirva.

Saludos, Matías.
Estudiante de Ingeniería en Computación.
FCEFyN - UNC.

[Mauricio Cáceres]

Hola matías
    Miré el mail y me llamo la atención tu trabajo asique lo estuve leyendo un poco, yo estoy empezando con los sistemas embebidos de a poco y me pareció muy bueno el trabajo. Estoy tratando de buscar alguna guía como para empezar no se bien cual serían los primeros pasos.

Saludos
Mauricio
Estudiante de Ingeniería en Mecatrónica

--

[Santiago Pérez]

Muy interesante Matías, muchas gracias por el aporte. Se lo ve muy completo al trabajo. Seguramente me será de gran utilidad. Los mantengo al tanto de los avances.

En este momento estaba tratando de probar Qemu, justamente para emular el funcionamiento del kernel y el filesystem cross compilado.

--
Atentamente//With best Regards/Mit freundlichen Grüßen

Santiago Pérez
Ingeniero Electrónico

pere...@gmail.com
Córdoba, Argentina.

[Santiago Pérez]

Alguien tiene alguna experiencia satisfactoria con Qemu?. Diego en un mail anterior comentó que le fue de gran utilidad para el desarrollo.

Saludos,

Santiago

--
Atentamente//With best Regards/Mit freundlichen Grüßen

Santiago Pérez
Ingeniero Electrónico

pere...@gmail.com
Córdoba, Argentina.

[martin ribelotta]

El día 15 de julio de 2013 08:42, Santiago Pérez <pere...@gmail.com> escribió:
> Alguien tiene alguna experiencia satisfactoria con Qemu?. Diego en un mail
> anterior comentó que le fue de gran utilidad para el desarrollo.
>

Si estás desarrollando un bootloader, un task switcher (cosas con el
core en si) o algo sobre un hardware que tenga soporte en QEMU (por
ejemplo, los perifericos de los PXA viejitos de intel) es una
herramienta invaluable.
En lo personal, me incomoda tener que modelar los perifericos
escribiendo codigo C que luego hay que integrar en QEMU, pero es
inherente a su arquitectura, no es un simulador de hardware
(Questa/Mentor) sino un emulador de plataformas.

>>>> pere...@gmail.com

[gerardo gimenez]

Hola,
Che Matias, hice el mismo laburo que vos pero para un IMX28 con el LTIB. Pudiste ver si con IMX53 compilaba el ALSA-lib (sonido) y QTOPIA 4.x.x?

Pudiste hacer andar el touchscreen del LDC?

Porque hace un par de semanas estoy con eso, he probado varias recetas y nada. Y por ahí está resuelto para IMX53 y me puedo copiar la receta.


Esto de no pisar hardware no es para electrónicos!!! Pero bueno "adaptate o te vas a la m....!!!"


Saludos atentos.

2013/7/15 martin ribelotta <martinr...@gmail.com>

--
Giménez Gerardo Daniel.

[matías perret cantoni]

Hola Gerardo... No trabajamos ni con ALSA-bin ni con el touchscreen(no tenemos uno jeje). A Qtopia no lo pudimos compilar directamente usando LTIB, además como está discontinuado pasamos a Qt embedded (en el documento que adjunte está explicado el proceso que seguimos).

Por lo general los paquetes que no se pueden compilar con LTIB es porque tienen problemas de dependecia, principalmente porque la herramienta está un poco desactualizada. Lo que podes hacer en esos casos es descargar paquetes nuevos, agregarlos a la lista de paquetes del LTIB y luego seleccionarlos y compilar nuevamente. Podes seguir los pasos en "How can I add a completely new package to the root filesystem" de la página de LTIB (http://ltib.org/documentation-LtibFaq). 

Espero que te sirva!
Saludos..

[gatom...@gmail.com]

Hola Matías.

He visto esta respuesta que diste hace unos meses y estoy intentando hacer lo que hiciste en este proyecto pero con QT5. En QT4 lo tengo funcionando (qt 4.8.5), pero para QT5 soy incapaz de hacer la configuración para hacer la compilación para ARM (estoy usando 5.1.1 o 5.2.0alpha). 

Me preguntaba si habías trabajado con QT5 y si se podía hacer lo mismo que hiciste para este proyecto con QT5. Imagino que ahora no se podrá usar -qws porque ha desaparecido. 

Llevo atascado un tiempo en esto y no lo consigo.

¿Se puede hacer esto para QT5? 

Agradecido de antemano.

Un saludo.

Roberto.

[martin ribelotta]

El día 11 de octubre de 2013 09:34, <gatom...@gmail.com> escribió:
> Hola Matías.
>
> He visto esta respuesta que diste hace unos meses y estoy intentando hacer
> lo que hiciste en este proyecto pero con QT5. En QT4 lo tengo funcionando
> (qt 4.8.5), pero para QT5 soy incapaz de hacer la configuración para hacer
> la compilación para ARM (estoy usando 5.1.1 o 5.2.0alpha).
>
> Me preguntaba si habías trabajado con QT5 y si se podía hacer lo mismo que
> hiciste para este proyecto con QT5. Imagino que ahora no se podrá usar -qws
> porque ha desaparecido.
>
> Llevo atascado un tiempo en esto y no lo consigo.
>
> ¿Se puede hacer esto para QT5?
>

Hola, como bien comentas, QWS ha muerto en Qt5 a favor de QtWayland y
Wayland en si.
http://qt-project.org/wiki/QtWayland
https://qt.gitorious.org/qt/qtwayland
http://wayland.freedesktop.org/
Ya que el protocolo QWS era espantoso y nada escalable aparte de estar
engordando como consumidor compulsivo de amburgesas McDonnal.

De todas formas, gracias a la nueva infraestructura grafica de Qt5
llamada QPA, el port a varios toolkit graficos es un tramite
relativamente simple.
http://qt-project.org/doc/qt-5.0/qtdoc/qpa.html
http://qforever.wordpress.com/2012/04/10/qt-platform-abstraction-starter-guide/
http://qt-project.org/videos/watch/qpa-the-qt-platform-abstraction
(NSFW, el tipo peliverde saca -2 puntos de cordura)
En el siguiente enlace, las plataformas que soporta Qt5 en estos
momentos (QtWayland en repo aparte)
https://qt.gitorious.org/qt/qtbase/source/src/plugins/platforms

De hecho, ya hay proyectos como la nueva distro de prueba de Rasberry
Pi, Tizen, o Jolla. Desde ya, todo muy nuevo, pero conociendo el
codigo, esta tranquilamente para producción.

Otra opción si no necesitas del soporte a multiples aplicaciones,
puedes usar los otros plugins de plataforma en Qt5, como directfb, raw
framebuffer, gles (si hay soporte en tu toolkit), KMS u openWFD (si
hay soporte en tu toolkit de GPU)

De todas formas, este es un tema bastante avanzado que requiere varias
horas de vuelo en este campo. Si estás empesando, recomendaria tener
solo Qt5/XCB + X11 para probar algunas cosas (normalmente, X consume
cualquier disparate con composición, pero si ella, es bastante nice)

Espero te sirva. Saludos.

> Agradecido de antemano.
>
> Un saludo.
>
> Roberto.
>
> El domingo, 14 de julio de 2013 01:26:53 UTC+2, matías perret cantoni
> escribió:
>>
>> Hola Santiado, cómo andas? Vi que te respondieron sobre las herramientas,
>> bootloader, etc.. Mi experiencia en el tema no es mucha, pero para el tema
>> de Qt puedo aportar algo. Te adjunto una guía que hicimos con un compañero
>> de la facultad en nuestra práctica profesional. Tiene varias cosas; nosotros
>> usamos LTIB para generarar la imagen del bootloader y del kernel y el
>> sistema de archivos; y finalmente cross-compilamos las librerias de Qt y las
>> metimos en el sistema de archivos. No sé si es lo que necesitaras, pero
>> espero que te sirva.
>>
>> Saludos, Matías.
>> Estudiante de Ingeniería en Computación.
>> FCEFyN - UNC.
>>

[big snip]

[Santiago Pérez]

Muy buena toda la info! Excelente resumen.

Quizás el problema para alquien que recién inicia en el tema, es que si te metés de lleno con Qt5, hay tanto conocimiento de background que necesitás, que terminás en un laberinto terrible si saber que significa cada término (QPA, Wayland, X11, KMS, XCB, etc.), que relación tiene con tu hardware, con la aplicación que queres desarrollar y encima que cada pequeña compilación o paso que querés dar (como es habitual en linux), tiene aparejado algun error que tenes que buscar en foros hasta que descubris que justo uno de los módulos de una de las partes de todo el conjunto, no es compatible con el ecosistema de host-target-compilador que tenés! (como para dar un ejemplo). No digo que sea imposible (lo sigo intentando), pero a veces se torna realmente estresante, invertís muchísimo tiempo (tiempo de tu empresa = tiempo de desarrollo = plazos de entregas = dinero = varias neuronas menos = surmenage en puerta) y no siempre lo sacás andando y no sabés si es pq te falto un guión en algún comando o porque toda tu base conceptual que desarrollaste está errada.

Estoy siendo un poco dramático, ja!, pero a veces desespera. Por eso quizás para el newbie, sea mejor arrancar con Qt4.8.5, tener algo andando (que no es poco!) y después intentar meterse en lo más nuevo. Lo último siempre es tentador, tanto porque intuímos que funcionará mejor como para no quedar obsoletos a corto/mediano plazo. Sin embargo el ritmo de desarrollo del mercado argentino lejos está del mercado mundial. Un ejemplo: el micro que estamos usando (SAMA5D31 de Atmel), salió a principios de año. Su placa de desarrollo tiene un transceiver HDMI (SIL9022). Atmel brinda un bsp para Linux y algunas herramientas. Cualquiera hubiera supuesta que un micro pensado para correr con OS y con soporte de la empresa que desarrolla y fabrica su placa de desarrolla, debería brindar drivers para todos sus periféricos. Pero no... resulta que Atmel no te brinda el driver para el HDMI, es más, no existe ese driver (solo una versión de Texas sin soporte de audio, que habría que reescribir para el micro propio). El soporte dice que lo tienen planeado, pero aún sin fecha. Por lo pronto.... lo lamento. O lo desarrollás, o esperás un año por lo menos... Es un ejemplo de q

--
Atentamente//With best Regards/Mit freundlichen Grüßen

Santiago Pérez
Ingeniero Electrónico

pere...@gmail.com
Córdoba, Argentina.

[Santiago Pérez]

perdón, metí mal el dedo y se envío.... continúo:

Es un ejemplo de q a veces lo más más nuevo, no es lo más conveniente para el mercado local. Quizás lo más conocido sin ser obsoleto (por ejemplo un imx6) te brinda mucho más soporte y algunos años de experiencias de usuarios.

Me fui un poco de tema, pero solo para decir que quizás conviene empezar con Qt4 y cuando esté más pulido Qt5 (o el usuario), evaluar de hacer el switch. Solo una opinión.

Saludos!

Santiago

--
Atentamente//With best Regards/Mit freundlichen Grüßen

Santiago Pérez
Ingeniero Electrónico

pere...@gmail.com
Córdoba, Argentina.

[gatom...@gmail.com]

Hola.

En primer lugar muchas gracias por tus ilustrativos comentarios me han servido para aclarar unas cuantas cosas (aunque no todas) y para darme cuenta de la envergadura del asunto (una documentación que no te la acabas).

Comparto el -2 de cordura en la tirada del tipo de pelo verde (es para que se lo haga mirar).

Como dice Santiago la tarea de hacer una compilación cruzada de QT5 parece una cosa de engranaje fino, si no tienes todas las piezas equilibradas en su justa medida no hay forma de hacerlo y acaba siendo muy agotador mentalmente para algo que debería ser más asequible de hacer. 

Me comprometo a hacer un tutorial paso a paso el día que lo consiga.

Siguiendo con el tema...

La compilación cruzada que estoy intentando realizar es para un Cortex A8 y posteriormente lo intentaré con una BeagleBoard xM que creo que tiene el mismo micro, así que inicialmente debería ser muy parecido.

Necesito las libs para opengl, egl y demás que suministra TI para este micro, el problema es como conseguirlas y sobretodo en que formato las consigo (codigo fuente o binarios para Ubuntu).

Aunque me surge una duda, si yo quiero hacer aplicaciones con entornos de ventanas (2D), es decir no voy a usar 3D, necesito tener openGL o puedo funcionar de otra manera?¿Que ventaja tiene usar OpenGL con respecto a no usarlo, en cuanto a 2D se refiere? ¿Que plugin debería emplear si no uso opengl? ¿Como se traduce eso en el configure? ¿necesito tener instalado algo previamente?

Comentas al final lo de empezar con Qt5/XCB + X11. Esto como se materializa en el configure (añadiendo -xcb -no-opengl simplemente?)

Estoy haciendo la compilación cruzada con lo siguiente:

Linux x86: Ubuntu 12.04 (desde vmWare)
QT5 Source: qt-everywhere-opensource-src-5.1.1 (o 5.2.0 alpha)
Toolchain: gcc-linaro-arm-linux-gnueabihf-4.7.
Linux ARM: Ubuntu

Platform: TI Cortex A8

Nuevamente gracias.

Un saludo.

Roberto Sánchez