Download experiencias del trabajo con xeos en plataformas de hardware

EXPERIENCIAS DEL TRABAJO CON XEOS EN PLATAFORMAS
DE HARDWARE
WORKING EXPERIENCES WITH XEOS ON HARDWARE PLATFORMS
Alexy Gallardo-Segura1, Reinier Millo-Sánchez2, Humberto López-León3, Waldo Paz-Rodríguez4
1 Empresa de Tecnologías de la Información para la Defensa, Cuba, [email protected], Central Hermanos Ameijeiras,
Placetas, Villa Clara, Cuba
2 Universidad Central “Marta Abreu” de las Villas, Cuba, [email protected]
3 Empresa de Tecnologías de la Información para la Defensa, Cuba, [email protected]
4 Universidad Central “Marta Abreu” de las Villas, Cuba, [email protected]
RESUMEN: El auge de los sistemas embebidos ha tenido un impacto en el desarrollo de nuevas plataformas
de hardware. El empleo de estas nuevas plataformas en sistemas operativos existentes representa un problema
ya que es necesario invertir tiempo en darle soporte a estas plataformas así como a los controladores de dispositivos que empleen. El soporte de nuevas plataformas de hardware en un sistema operativo es un proceso largo
y difícil. Para lograrlo en un tiempo reducido es necesario acumular experiencias de soporte y un alto conocimiento sobre las tecnologías. Este problema afecta en mayor grado a sistemas operativos de propósito específico no basados en kernel de Linux. En este trabajo se presentan un conjunto de pasos que se deben tener en
cuenta para dar soporte a nuevas plataformas de hardware y controladores de dispositivos en XEOS, una alternativa cubana para el desarrollo de sistemas embebidos basado en el enfoque de desarrollo de microkernel. Los
pasos propuestos se basan en las experiencias del trabajo adquiridas con XEOS en las plataformas de hardware RaspberryPI y Odroid-X2.
Palabras Clave: XEOS, Fiasco.OC, GenodeOS, plataformas de hardware, RaspberryPI, Odroid-X2.
ABSTRACT: The rise of embedded systems has impacted positively on the development of new hardware platforms. The use of these new platforms into existing operating systems is a problem because one need to invest
time in porting it to them as well as device drivers they employ. The support for new hardware platforms in an
operating system is a long and difficult process. To achieve this in short time is necessary to accumulate experiences of porting and a high knowledge of technologies. This problem affects in more degree to special purpose
operating systems not based on Linux kernel. This work presents a set of steps that must be taken into account
to support new hardware platforms and device drivers in XEOS, a Cuban alternative for the development of embedded systems based on the microkernel approach. The proposed steps are based on the experiences acquired with XEOS work on hardware platforms RaspberryPI and Odroid-X2.
KeyWords: XEOS, Fiasco.OC, GenodeOS, hardware platforms, RaspberryPI, Odroid-X2.
“VI Taller Internacional de Tecnologías de Software Libre y Código Abierto”
Gallardo-Segura, A.; Millo-Sánchez, R., López-León, H., Paz-Rodríguez, W. | “EXPERIENCIAS DEL TRABAJO CON XEOS EN PLATAFORMAS DE HARDWARE”
1. INTRODUCCIÓN
En la actualidad el empleo de dispositivos embebidos ha ido en aumento. El uso de estos dispositivos
comenzó dentro de las grandes industrias como
parte del control automático de los procesos de
producción, y actualmente los podemos encontrar
dentro de nuestros hogares en lavadoras de control
automático, en sistemas decodificadores para la
televisión, en hornos, ventiladores, sistemas de
alumbrado automático, reproductores DVD, entre
otros muchos dispositivos. También se encuentran
en dispositivos un poco más personales como pueden ser los conocidos como Smartphone o teléfonos inteligentes.
Los sistemas embebidos son sistemas de computación que encapsula en un dispositivo todo el
hardware y software, normalmente en un solo dispositivo, que están específicamente diseñados y
optimizados para resolver un problema concreto de
forma eficiente [1]. El término embebido o empotrado hace referencia al hecho que la electrónica o el
sistema electrónico de control es una parte fundamental del sistema donde se emplea. La característica principal que diferencia a los embebidos de los
demás sistemas electrónicos, es que, por estar insertados dentro del dispositivo que controlan, están
sujetos en mayor medida a cumplir requisitos de
tamaño, fiabilidad, consumo y coste, y su existencia
puede no ser aparente [2], [3].
Con el auge de los sistemas embebidos ha venido
aparejado un auge de nuevas plataformas de hardware, con más prestaciones de hardware o más
específicas para determinadas tareas. Para poder
usar un sistema operativo sobre estas nuevas plataforma primero es necesario darle soporte al sistema
sobre estas. Cada vez que se da soporte o se porta
el sistema hacia nuevas plataformas de hardware
se amplía la gama de dispositivos donde se pueden
utilizar las aplicaciones desarrolladas para este sistema. El soporte de las tecnologías incluye desde el
soporte a los componentes básicos del sistema
hasta la implementación de los controladores de
dispositivos o drivers de la plataforma.
Un driver proporciona una interfaz de software para
interactuar con dispositivos de hardware. Estos
simplifican la programación, actuando como un traductor entre un dispositivo de hardware y las aplicaciones o el sistema operativo que lo utiliza [4]. Los
programadores pueden escribir el código de aplicación de nivel superior de manera independiente de
cualquier hardware específico que el usuario final
está utilizando.
Para dar soporte a un sistema operativo sobre una
plataforma de hardware se debe tener un amplio
conocimiento sobre las características y funcionamiento de la plataforma de hardware. Esto se puede
conseguir con el estudio de la hoja de especificación de datos o datasheet, así como el esquema
electrónico de la plataforma o schematic. También
es necesario tener dominio sobre los estándares o
protocolos de los device drivers que se van a implementar.
El soporte básico de un sistema operativo y la implementación de los drivers para determinada plataforma de hardware es un problema muy común en
sistemas basados en tecnologías de kernel diferentes al kernel de Linux. La experiencia acumulada en
el desarrollo de este proceso es muy útil para garantizar posteriormente que el soporte de una nueva
plataforma de hardware se realice de forma eficiente en el menor tiempo posible.
En este trabajo se presentan las experiencias adquiridas en el soporte de XEOS, un sistema operativo basado en tecnologías de microkernel, a las plataformas de hardware RaspberryPI y Odroid-X2. En
el trabajo se describen las herramientas de software
utilizadas, así como las plataformas de hardware
empleadas. Con la experiencia adquirida se definen
un conjunto de pasos que se deben tener en cuenta
para dar soporte a nuevas plataformas de hardware
en XEOS y agregar nuevos drivers.
2. HERRAMIENTAS EMPLEADAS
El soporte de las tecnologías se va a realizar específicamente para el sistema operativo XEOS (XETID
Embedded Operating System). Este es un sistema
operativo que se presenta como una alternativa cubana ante el kernel de Linux para el desarrollo de
sistemas embebidos.
Su desarrollo está basado en el enfoque de microkernel. Esto permite reducir el tamaño del TCB
(Trusted Computing Base) del sistema y de las aplicaciones que se van a ejecutar. Presenta una mejor
tolerancia ante los fallos porque como plantea el
enfoque de microkernel en el espacio del kernel
solo se implementan los elementos mínimos indispensables propuestos en [5].
XEOS emplea un grupo de tecnologías con funciones determinadas en el sistema. Para la carga del
sistema operativo se utiliza el U-boot [6]. El microkernel empleado en XEOS es Fiasco.OC [7]. Para
el desarrollo de aplicaciones y otros componentes
del sistema se utiliza el framework GenodeOS [8].
También es necesario el uso de toolchains para la
compilación. A continuación se describen con más
detalles estas tecnologías.
2.1 U-boot
U-Boot (Universal Bootloader) [6] es un cargador de
sistema operativo que se puede utilizar en varias
arquitecturas de hardware, incluyendo PPC, ARM,
AVR32, MIPS, Intel y MicroBlaze. Está liberado bajo
la licencia GNU/GPL v2 (GNU/General Public License).
El U-Boot tiene soporte para un gran número de
plataformas de hardware que pueden ser utilizadas
“VI Taller Internacional de Tecnologías de Software Libre y Código Abierto”
Gallardo-Segura, A.; Millo-Sánchez, R., López-León, H., Paz-Rodríguez, W. | “EXPERIENCIAS DEL TRABAJO CON XEOS EN PLATAFORMAS DE HARDWARE”
en aplicativos de sistemas embebidos. Se puede
configurar para que la imagen del sistema operativo
sea cargada desde un servidor TFTP (Trivial file
transfer Protocol), similar al funcionamiento de los
clientes ligeros, desde dispositivos MMC (MultiMedia Card) y dispositivos USB. También es necesario señalar que cuenta con una comunidad de
desarrollo activa.
La simplicidad de su implementación puede ser útil
para identificar procesos de configuración e inicialización de las plataformas de hardware. También se
puede tomar como guía para la implementación de
algunos componentes del sistema como pueden ser
los drivers.
2.2 Fiasco.OC
El microkernel Fiasco.OC pertenece a la familia de
microkernels L4, desarrollado por la Universidad
TU Dresden en Alemania [7]. Está enmarcado en la
3ra generación de microkernels y se encuentra liberado bajo la licencia GNU/GPL v2.
Este microkernel puede ser empleado para la construcción de sistemas de propósito general o sistemas de propósito específico como los embebidos.
Tiene soporte para la ejecución y planificación de
tareas de tiempo real y tiempo compartido. Tiene
soporte para la multiprogramación y la virtualización
por hardware.
Este implementa la seguridad del sistema basado
en capacidades de objetos. Para ello todos los
componentes internos del microkernel son considerados un objeto, por lo que toda su API se encuentra orientada al trabajo con estos objetos.
dificación y documentación, lo que permite una mayor comprensión del código y facilita el mantenimiento y soporte del mismo de manera uniforme [9].
Detrás del desarrollo de este framework existe una
amplia comunidad de desarrollo internacional, la
cual permite la identificación y corrección de bugs
del sistema.
2.3 Toolchains
Los toolchains o herramientas de compilación, no
son más que el conjunto de aplicaciones que se
emplean para desarrollar aplicaciones. Por lo general estas herramientas incluyen un compilador, un
enlazador y un depurador, así como un conjunto de
bibliotecas que sirven de interfaz al sistema operativo [10].
Los toolchains brindan el conjunto de herramientas
necesarias para la compilación del código fuente de
la aplicación, pero cuando se quiere compilar para
una arquitectura de máquina diferente entonces es
necesario utilizar un cross-toolchains o herramientas de compilación cruzada. Este conjunto de herramientas permite desarrollar aplicaciones para
una arquitectura de hardware diferente a la arquitectura sobre la cual se desarrolla.
Para el trabajo en particular con las tecnologías de
software que componen a XEOS se debe emplear
el toolchains distribuido por la compañía GenodeLabs [11]. Este toolchain fue diseñado específicamente para la compilación del framework GenodeOS, incorporando algunas optimizaciones en la
generación de código binario de GenodeOS.
3. Plataformas de Hardware
2.3 GenodeOS
El framework GenodeOS [8] es un conjunto de herramientas para la construcción de sistemas operativos de propósito específico, aunque el proyecto
pretende convertirse en un sistema operativo de
propósito general [9]. Este framework contiene un
gran número de componentes tales como controladores de dispositivo, protocolos, soporte para varios
kernels y aplicaciones de terceros.
Está compuesto por un conjunto de componentes
que se organizan siguiendo varios principios arquitectónicos. Esto le permite al sistema estar compuesto por una amplia gama de sistemas diferentes
y aumentar el aislamiento entre los componentes.
Una de las principales ventajas de este framework
es que permite al desarrollador abstraerse y tener
una independencia completa del kernel del sistema
que se esté empleando, así como la arquitectura y
la plataforma de hardware. Actualmente GenodeOS
tiene soporte para varias tecnologías de kernel del
sistema, entre los que se encuentran: Fiasco.OC,
seL4, OKL4, NOVA y GNU/Linux.
El framework cuenta con su propio estándar de co-
El término plataforma es ampliamente usado en
diversas áreas de la ciencia y la técnica. En el caso
del hardware, se refiere a los dispositivos físicos, o
sea, al conjunto de componentes de hardware que
se utilizan como base para la ejecución de determinado software, con el cual es compatible.
Existe una gran variedad de estas plataformas de
hardware. Las principales diferencias entre las plataformas están dadas en cuanto a su diseño y prestaciones. A continuación se describen las plataformas empleadas en el desarrollo de este trabajo.
3.1 RaspberryPI
La RaspberryPI es una plataforma de hardware de
bajo costo. Fue lanzada al mercado en el 2012, es
desarrollada y comercializada por la RaspberryPI
Foundation.
El principal objetivo de esta plataforma es estimular
la enseñanza de la computación en todas las edades, aunque también es capaz de realizar las tareas
comunes que realiza un ordenador de escritorio
[12].
“VI Taller Internacional de Tecnologías de Software Libre y Código Abierto”
Gallardo-Segura, A.; Millo-Sánchez, R., López-León, H., Paz-Rodríguez, W. | “EXPERIENCIAS DEL TRABAJO CON XEOS EN PLATAFORMAS DE HARDWARE”
Aunque por defecto no posee facilidades de tiempo
real, y comparada con otras plataformas sus prestaciones son inferiores, su bajo consumo de energía
y su reducido tamaño hacen que la RaspberryPI sea
una plataforma de hardware que se pueda emplear
en sistemas embebidos que requieran pocas prestaciones [13]. Varios son los sistemas operativos
que han dado soporte para la RaspberryPI, entre los
que se encuentran: Debian, Fedora, ArchLinux, Slackware Linux y RISC OS.
Hasta el momento se han desarrollado cinco versiones de esta plataforma: Modelo 1 A, Modelo 1
A+, Modelo 1 B, Modelo 1 B+ y Modelo 2 B. Para el
desarrollo de este trabajo se empleó una RaspberryPI Modelo 1 B. En la tabla I se muestran las características principales de esta plataforma.
Componente
Característica
SoC
Exynos4412 Prime
Procesador
Quad core Cortex-A9 @ 1.7
Ghz
GPU
ARM Mali-400 Quad Core @
440MHz
Memoria
DDR2 2GB
Soporte E/S
Ethernet 10/100 Mbps, USB,
GPIO de 50 pines, Micro
HDMI, conector entrada/salida
audio jack 3.5 mm
Almacenamiento
SDHC/eMMC
Tabla I: Características de la plataforma RaspberryPI
Componente
Característica
SoC
Broadcom BCM2835
Procesador
ARM1176JZF-S @ 700 MHz
GPU
Dual core VideoCore IV Multimedia Co-Processor
Memoria
SDRAM 512 MB
Soporte E/S
Ethernet 10/100 Mbps, USB,
GPIO de 40 pines, HDMI,
RCA, conector audio jack 3.5
mm, puerto para cámara (CSI2), puerto para LCD (DSI)
Almacenamiento
SD/MMC/SDIO
3.2 Odroid-X2
El nombre Odroid es resultado de la combinación
entre Open y anDROID y representa una serie de
plataformas creadas por la compañía Hardkernel.
Las plataformas Odroid comenzaron a comercializarse en el año 2009. La primera versión se llamó
Odroid, luego llegaron Odroid-T, Odroid-S, Odroid7, Odroid-A, Odroid-PC, Odroid-A4, Odroid-Q,
Odroid-X, Odroid-X2, Odroid-U, Odroid-U2, OdroidXU, Odroid-U3, Odroid-XU3 y Odroid-C1 [14].
Aunque estas plataformas están creadas para el
sistema operativo Android, también soportan algunas versiones de Linux. Estas plataformas están
consideradas entre las más potentes del mercado.
Aunque son consideradas como hardware libre y los
esquemas del circuito son libres, otras partes del
diseño se retienen.
En la tabla II se muestran las características principales de la plataforma Odroid-X2 empleada para la
realización de este trabajo:
Tabla II: Características de la plataforma Odroid-X2
4. RESULTADOS OBTENIDOS
Una vez familiarizados con las tecnologías utilizadas se presentan los resultados y las experiencias
obtenidas durante el proceso de soporte a las plataformas de hardware en XEOS.
Durante el proceso de soporte de XEOS en las plataformas de hardware RaspberryPI y Odroid-X2 fue
necesario revisar los manuales técnicos de ambas
plataformas así como las especificaciones de cada
uno de los SoC (System on Chip) empleados
BCM2835 y Exynos4412 respectivamente. En ambos casos también fue necesario revisar el esquema electrónico de la plataforma, pues en ocasiones
la información que proveen los manuales técnicos
es muy reducida.
Estos documentos pueden ser descargados desde
el sitio oficial de cada plataforma. El estudio de los
mismos es un requisito indispensable para el correcto soporte de las plataformas de hardware.
Estos permiten la familiarización con cada uno de
los componentes que componen la plataforma. De
ellos se extrae toda la especificación de cada uno
de los componentes, como puede ser, las zonas de
memoria asociadas, los registros de memoria y la
distribución de los bits de cada uno de estos registros. En algunos casos, no en todos, los fabricantes
explican el modo de funcionamiento de los dispositivos. Producto de esto fue necesario adquirir un
dominio sobre el funcionamiento del hardware en
general. También fue necesario inferir el funcionamiento y el proceso de configuración e inicialización
de algunos componentes del sistema, a partir del
código fuente de otros sistemas, como son el kernel
de Linux y el cargador de arranque U-Boot.
En el estudio de las tecnologías de software empleadas en XEOS así como sus manuales técnicos,
y la información técnica de las plataformas de
hardware se identificaron un conjunto de componentes básicos que se deben implementar para el
correcto funcionamiento de XEOS sobre las plata-
“VI Taller Internacional de Tecnologías de Software Libre y Código Abierto”
Gallardo-Segura, A.; Millo-Sánchez, R., López-León, H., Paz-Rodríguez, W. | “EXPERIENCIAS DEL TRABAJO CON XEOS EN PLATAFORMAS DE HARDWARE”
formas de hardware.
A nivel de microkernel Fiasco.OC se identificó que
se debe implementar el BSP (Board Support Package) de la plataforma. Este está compuesto por
los elementos mínimos e indispensables para garantizar el correcto funcionamiento del kernel. El
BSP en todos los casos está compuesto por los
componentes básicos del SoC: el mecanismo de
interrupciones IRQ, los temporizadores así como el
mapa de memoria de la plataforma. También se
incluye el proceso de configuración e inicialización
de la plataforma.
En ambos casos se detectó que Fiasco.OC tiene
soporte para los SoC BCM2835 y Exynos4. En este
último fue necesario realizar una revisión específica
de los mecanismos básicos del Exynos4412 y reconfigurar el mecanismo de interrupciones para el
correcto funcionamiento sobre el Odroid-X2.
Una vez revisado el soporte a nivel de kernel para la
plataforma, el siguiente paso fue brindar el soporte
básico a nivel de framework. Este soporte básico
fue definido tomando en consideración los elementos mínimos e indispensables para poder ejecutar
una aplicación básica sobre las plataformas de
hardware empleando las tecnologías. Los elementos básicos para el funcionamiento de XEOS son
las interrupciones IRQ y los temporizadores o timers. Por lo general se incluye una terminal serial
UART
(Universal
Asynchronous
ReceiverTransmitter), que es utilizada con propósitos de depuración.
El soporte de las tecnologías de XEOS en las plataformas de hardware RaspberryPI y Odroid-X2 nos
permitió definir un conjunto de pasos que deben ser
seguidos para dar soporte a nuevas plataformas de
hardware:
1. En caso de ser necesario, dar soporte a la
plataforma en el kernel del sistema.
2. Generar la configuración para la compilación del kernel del sistema.
3. Agregar soporte a la plataforma en el mecanismo de compilación de GenodeOS.
4. Configurar el enlace entre Fiasco.OC y GenodeOS.
5. Configurar las opciones de compilación y
ejecución.
Después de realizar el soporte básico de la plataforma se deben aplicar varias pruebas para comprobar su correcta implementación. El framework
GenodeOS provee un conjunto de aplicaciones elaboradas con el objetivo de probar elementos específicos del sistema. En la tabla III se muestra un
conjunto de estos ejemplos ejecutados sobre ambas plataformas hardware para verificar el soporte
realizado.
Tabla III: Pruebas realizadas para verificar el soporte básico en la plataforma.
Prueba
printf
Descripción
Permite probar el funcionamiento
básico del sistema. Es la prueba
más básica que se puede realizar.
Esta imprime un mensaje por la
terminal serial. Con este también
se puede verificar el funcionamiento del UART.
cap_integrity
Permite verificar la correcta integración entre Fiasco.OC y GenodeOS.
signal
Permite comprobar el funcionamiento de las interrupciones.
timer
Permite comprobar el funcionamiento de los timers.
tiPermite comprobar el funcionamed_semapho miento de los timers y los semáfore
ros para problemas de concurrencia.
thread
Permite comprobar la correcta
creación de múltiples hilos de ejecución.
thread_join
Permite comprobar la sincronización entre diferentes hilos de ejecución.
config_args
Permite probar el paso de parámetros a las aplicaciones a través
de la configuración de GenodeOS.
dynaPermite probar la configuración
mic_config
dinámica de un sistema.
xml_generator Permite comprobar el correcto
funcionamiento del generador de
configuraciones Xml.
fault_detection Permite verificar que la detección
de fallos funcione correctamente,
induciendo fallos en el sistema.
rm_fault
Permite comprobar el funcionamiento del manejador de memoria, induciendo fallos de página
por software.
uart
Permite verificar el correcto funcionamiento del UART.
En la mayoría de los aplicativos de sistemas embebidos no es suficiente con el soporte básico. Algunas aplicaciones requieren utilizar otros dispositivos
como por ejemplo, dispositivos de almacenamiento
o comunicarse a través de la red. Para lograr esto
es necesario la implementación de los drivers requeridos.
En XEOS los drivers se ejecutan como aplicaciones
en el espacio de usuario. El desarrollo de los drivers
es muy parecido al de las aplicaciones, solo que los
drivers deben acceder a ciertas regiones de memoria del dispositivo y controlar las operaciones de
entrada/salida del dispositivo, así como las interrup-
“VI Taller Internacional de Tecnologías de Software Libre y Código Abierto”
Gallardo-Segura, A.; Millo-Sánchez, R., López-León, H., Paz-Rodríguez, W. | “EXPERIENCIAS DEL TRABAJO CON XEOS EN PLATAFORMAS DE HARDWARE”
ciones del mismo.
Los drivers más comunes de estas plataformas de
hardware deben ser implementados en XEOS para
determinados aplicativos. En las plataformas analizadas los drivers con los cuales se ha trabajado son
listados a continuación:

USB

GPIO (General Purpose Input/Output)

HDMI (High-Definition Multimedia Interface)
 SD/MMC
En la implementación de los drivers, tanto para el
Odroid-X2 como para la RaspberryPI, se han implementado algunos de los drivers mencionados
anteriormente. Para la plataforma Odroid-X2 se implementaron los drivers del USB y HDMI. En el caso
de la plataforma RaspberryPI se implementó el driver del GPIO.
Para la implementación del driver USB en el OdroidX2 fue necesario analizar y comprender la implementación de este driver en el kernel de Linux. GenodeOS tiene un soporte para drivers USB basado
en el kernel de Linux, donde se implementan los
protocolos empleados por el USB.
Se identificó que el soporte de drivers USB que tiene GenodeOS cubre el driver USB requerido para la
Odroid-X2. Una vez identificado esto, fue necesario
implementar la inicialización y las configuraciones
iniciales del driver USB en GenodeOS, haciendo
uso de los drivers del kernel de Linux.
Hay que señalar que en esta plataforma el adaptador de red Ethernet internamente está conectado
por el bus USB. La implementación del driver USB
realizada también incluye el soporte para la red. En
la tabla IV se muestra el conjunto de pruebas realizadas para comprobar el correcto funcionamiento
del USB.
Todas las pruebas fueron ejecutadas satisfactoriamente sobre la plataforma Odroid-X2. Es necesario
destacar que en la prueba del netperf, XEOS alcanzó un rendimiento de 85 Mbits/sec, mientras que si
se emplea la misma herramienta para medir el rendimiento en el kernel de Linux, se obtiene un rendimiento de 84 Mbits/sec.
Para la implementación del driver HDMI del OdroidX2 se comenzó por la revisión de una implementación existente en GenodeOS para el Exynos5. Luego de la revisión de esta implementación y la comparación de los manuales de ambos SoC, se determinó que el HDMI del Exynos 5 es compatible
con el HDMI del Exynos4412.
Tabla IV: Pruebas realizadas para verificar el funcionamiento del driver USB.
Prueba
usb_hid
Descripción
Permite probar el funcionamiento
del USB con dispositivos de interfaz humana (mouse y teclado) y la
identificación de dispositivos USB.
usb_storage
Permite probar el funcionamiento
de dispositivos de almacenamiento USB.
qt5_tetrix
Permite probar la integración de
GenodeOS con Qt 5.1.0. En este
caso se emplea un juego de tetrix,
que nos permite probar también la
integración con el driver USB para
el control del juego.
netPermite probar el funcionamiento
work_test_lwip de la interfaz de red, a través de
un sencillo servidor local.
netperf
Permite medir el rendimiento de la
interfaz de red.
Al ser compatibles ambos drivers, el proceso de
implementación estuvo centrado en la generalización de este driver para ser utilizado por ambas plataformas. En la tabla V se muestra una relación de
pruebas que se ejecutaron satisfactoriamente para
probar el correcto funcionamiento del driver HDMI.
Tabla V: Pruebas realizadas para verificar el funcionamiento del driver HDMI.
Pruebas
framebuffer
Descripción
Permite probar la integración del
framebuffer de GenodeOS con el
driver de video, en este caso el
HDMI.
demo
Permite probar todos los elementos básicos de GenodeOS a través de un lanzado de aplicaciones
demostrativo de GenodeOS.
qt5_tetrix
Permite probar la integración de
GenodeOS con Qt 5.1.0. En este
caso se emplea un juego de tetrix,
que nos permite probar también la
integración con el driver HDMI.
Para la implementación del driver GPIO en la RaspberryPI fue necesario realizar un estudio sobre los
drivers de GPIO implementados en GenodeOS para
otras plataformas. De este estudio se obtuvieron las
interfaces que se debían implementar en el nuevo
driver.
Una vez conocida las interfaces a implementar, con
ayuda del manual de SoC BCM2835 se implementó
el controlador para GPIO. La implementación se
desarrolló teniendo en cuenta que cada pin de
GPIO de la RaspberryPI puede ser configurado para
cinco funcionalidades. Este proceso de configuración se realiza de forma dinámica en el momento de
inicialización de XEOS.
Para probar la implementación del driver GPIO GenodeOS no provee pruebas generales, solo existe
una prueba específica para el driver GPIO de la plataforma Omap4. Por esto fue necesario diseñar
nuevas pruebas que permitan probar el funcionamiento del driver. En la tabla VI se muestran las
“VI Taller Internacional de Tecnologías de Software Libre y Código Abierto”
Gallardo-Segura, A.; Millo-Sánchez, R., López-León, H., Paz-Rodríguez, W. | “EXPERIENCIAS DEL TRABAJO CON XEOS EN PLATAFORMAS DE HARDWARE”
pruebas diseñadas y ejecutadas satisfactoriamente
para probar el correcto funcionamiento del driver
GPIO.
Tabla VI: Pruebas realizadas para verificar el funcionamiento del driver GPIO
Pruebas
gpio_led
Descripción
Permite probar la implementación
del driver GPIO interactuando con
el pin asociado al LED.
gpio_signal
Permite probar la integración del
controlador de GPIO al mecanismo de señales de GenodeOS, a
través del empleo de un push button, haciendo uso del LED y las
interrupciones asociadas al GPIO.
El soporte de los drivers en XEOS para las plataformas de hardware RaspberryPI y Odroid-X2 nos
permitió definir un conjunto de pasos para la implementación de nuevos controladores:
1. Identificar el driver a implementar.
2. Intercambiar con la comunidad para conocer si alguien está trabajando en la implementación del driver.
3. Verificar si el driver está implementado ya
en el framework para la plataforma que se
emplea. En caso de estar implementado ir
al paso 13.
4. Localizar la documentación técnica del driver: manuales técnicos y protocolos de funcionamiento.
5. Verificar si el driver está implementado para
otra plataforma de hardware. En caso de
estar implementado para otra plataforma ir
al paso 8.
6. Identificar un driver similar en cuanto a funcionamiento, para identificar las posibles interfaces necesarias a implementar en GenodeOS. En caso de existir un driver similar
ir al paso 8.
7. Definir una nueva interfaz en GenodeOS
para definir el funcionamiento del driver. Ir
al paso 11.
8. Revisar la compatibilidad con el driver implementado. En caso de no ser compatible,
ir al paso 11.
9. Definir la estructura básica del driver, (aplicación principal + mecanismo de compilación)
10. Implementar los métodos de la interfaz del
driver. Ir al paso 13.
11. Verificar si el esquema o protocolo de funcionamiento del driver no se encuentra ya
implementado parcial o totalmente, de forma que se pueda reusar.
12. Implementar la interfaz asociada al driver,
tomando como base uno de las siguientes
fuentes para obtener el funcionamiento del
driver. Ir al paso 9.
1. Documentación técnica del driver.
2. Driver con igual esquema de funcionamiento, implementado en GenodeOS.
3. Implementación del driver en el kernel
de Linux, Uboot u otra API de tercero
con soporte para el driver.
13. Generar pruebas (run script) para probar la
implementación del driver.
5. CONCLUSIONES
El trabajo de soporte de las plataformas de hardware RaspberryPI y Odroid-X2 en las tecnologías de
XEOS permitió adquirir una gran experiencia por
parte del equipo de desarrollo. La experiencia adquirida permitió definir un conjunto de pasos que
pueden ser empleados para dar soporte a nuevas
plataformas de hardware en XEOS. Estos pasos
pueden ser refinados con el soporte de nuevas plataformas de hardware, lo cual también ayudará a la
revalidación de los mismos.
Durante el proceso de soporte de las plataformas
de hardware fue necesario dar soporte a controladores de dispositivos de hardware. Se implementaron controladores para el USB, HDMI y GPIO. Esto
permitió ver que existe una gran variedad de formas
de afrontar la implementación de los drivers. Con la
experiencia adquirida se enumeraron un conjunto
de pasos que se pueden seguir para agregar nuevos drivers en XEOS. Este conjunto de pasos también debe ser refinado con la implementación de
nuevos drivers.
Todos los resultados obtenidos de la experiencia
con las tecnologías de XEOS en las plataformas de
hardware, han sido compartidos con las comunidades de desarrollo. Estos resultados han sido publicados en la versión oficial del framework GenodeOS a partir de su versión 15.08 y algunas correcciones en el microkernel Fiasco.OC. El intercambio con las comunidades de desarrollo ha permitido la obtención de estos resultados así como la
validación de los mismos.
6. REFERENCIAS BIBLIOGRÁFICAS
1. Dams, R. D.: Controlador Lógico Programable: Una mirada interna., Editorial Universitaria de la
Costa. EDUCOSTA., 2009.
2. Tanenbaum, A. S.: Sistemas Operativos Modernos., Prentice-Hall, 3rd ed., 2009.
3. Silberschatz, A., P. B. Galvin, y G. Gagne:
Operating System Concepts, John Wiley & Sons,
2013.
4. PCGesund: “What is a device driver?, The
purpose of device drivers”, (En : http://www.pcgesund.de/it-wissen/what-is-a-device-driver).
“VI Taller Internacional de Tecnologías de Software Libre y Código Abierto”
Gallardo-Segura, A.; Millo-Sánchez, R., López-León, H., Paz-Rodríguez, W. | “EXPERIENCIAS DEL TRABAJO CON XEOS EN PLATAFORMAS DE HARDWARE”
5. Liedtke, J.: “On μ-kernel construction”, 15th
ACM Symposium on Operating System Principles
(SOSP), pp. 237–250, 1995.
6. Das, U.: “Boot–the Universal Boot Loader”,(En
: http://www.denx.de/wiki/U-Boot), 2002.
7. TU-DresdenOSGroup: “Fiasco.OC Microkernel”, (En: http://os.inf.tu- dresden.de/fiasco), .
8. Feske, N.: “Introducing Genode”, Talk at the
Free and Open Source Software Developers’ European Meeting, 2012.
9. Feske, N.: “Genode as General-Purpose OS Progress Report and Demonstration”, Free and
Open Source Software Developers’ European Meeting, 2014.
10. Holt, A. y C.-Y. Huang: “Compiler Toolchains”, Embedded Operating Systems, Springer,
pp. 115–136, 2014.
11. GenodeLabs: “GenodeLabs”, (En :
http://www.genode-labs.com/), 2015.
12. Richardson, M. y S. Wallace: Getting started with raspberry PI, O’Reilly Media, Inc., 2012.
13. Brahmbhatt, S.: “Embedded Computer Vision: Running OpenCV Programs on the Raspberry
Pi”, Practical OpenCV, Springer, pp. 201–218, 2013.
14.
Hardkernel:
“ODROID”,
(En
:
http://www.hardkernel.com/main/main.php), 2015.
Humberto López León recibió la Licenciatura en
Ciencia de la Computación en la Universidad
Central “Marta Abreu” de Las Villas (UCLV), Santa
Clara, Cuba, en el 2014. Actualmente trabaja en la
Empresa de Tecnologías de la Información para la
Defensa (XETID), como parte del grupo de investigación y
desarrollo “Sistema Operativo Embebido”. Es miembro de la
comunidad de desarrollo de GenodeOS. Sus intereses de
investigación incluyen: desarrollo de microkernel, sistemas
operativos, emuladores de hardware, plataformas de hardware,
testing automático. La dirección postal actual es Martí # 85A,
Santo Domingo, Villa Clara, Cuba. Dirección electrónica:
[email protected].
Waldo Paz Rodríguez recibió el título de Ingeniería
Informática en la Universidad Central “Marta
Abreu” de Las Villas (UCLV), Santa Clara, Cuba,
en el 2013. Actualmente se desempeña como
Reserva Científica de la Facultad de MatemáticaFísica-Computación en la UCLV y está optando para la
categoría de Máster en Ciencia de la Computación. Actualmente
trabaja en el centro de producción de la XETID-UCLV del Centro
de Estudios de Informática, como parte del grupo de
investigación y desarrollo “Sistema Operativo Embebido”. Es
miembro de la comunidad de desarrollo de GenodeOS. Sus
intereses de investigación incluyen: desarrollo de microkernel,
sistemas operativos, emuladores de hardware, plataformas de
hardware, testing automático, bioinformática, reconocimiento de
patrones. La dirección postal actual es Camilo Cienfuegos 48, e/
Sta Teresa y Luz Caballero, Camajuani, Villa Clara, Cuba, CP.
7. SÍNTESIS CURRICULARES DE LOS AUTORES
Alexy Gallardo Segura recibió la Licenciatura en
Ciencia de la Computación en la Universidad
Central “Marta Abreu” de Las Villas (UCLV), Santa
Clara, Cuba, en el 2014. Actualmente trabaja en la
Empresa de Tecnologías de la Información para la
Defensa (XETID), como parte del grupo de investigación y
desarrollo “Sistema Operativo Embebido”. Está optando para la
categoría de Máster en Ciencia de la Computación. Es miembro
de la comunidad de desarrollo de GenodeOS. Sus intereses de
investigación incluyen: desarrollo de microkernel, sistemas
operativos y plataformas de hardware. La dirección postal actual
es Central Hermanos Ameijeiras, Placetas, Villa Clara, Cuba y la
dirección de correo electrónico [email protected].
Reinier Millo Sánchez recibió la Licenciatura en
Ciencia de la Computación en la Universidad
Central “Marta Abreu” de Las Villas (UCLV), Santa
Clara, Cuba, en el 2012. Es Reserva Científica de
la Facultad de Matemática-Física-Computación en
la UCLV y está optando para la categoría de Máster en Ciencia
de la Computación. Actualmente trabaja en el centro de
producción de la XETID-UCLV del Centro de Estudios de
Informática, como parte del grupo de investigación y desarrollo
“Sistema Operativo Embebido”. Es miembro de la comunidad de
desarrollo de GenodeOS. Sus intereses de investigación
incluyen: desarrollo de microkernel, sistemas operativos,
emuladores de hardware, plataformas de hardware, testing
automático, bioinformática, reconocimiento de patrones. La
dirección postal actual es Edificio 15, Apartamento 1, Buena
Vista, Cienfuegos, Cienfuegos, Cuba, CP. 55100 y la dirección
de correo electrónico [email protected].
“VI Taller Internacional de Tecnologías de Software Libre y Código Abierto”