DISEÑO DE PLATAFORMAS DE COMPUTO BASADAS EN FPGAS

1. DISEÑO DE PLATAFORMAS DE COMPUTO BASADAS EN FPGAS Oviedo Marcos <moviedo@gmail.com> Linux Embebido (1era Parte)

2. Agenda • Diseño embebido en una FPGA (SoC) • Estrategia de aprendizaje • Arquitectura de alto nivel del SW control • Linux Kernel • Versiones • Requerimientos para ejecutar el kernel • Proceso de booteo del kernel • Compilación del kernel • Root filesystem • Toolchain de crosscompilación • Herramientas • Practico

3. Diseño embebido en una FPGA (SoC) • Desarrollo del sistema embebido basado en microprocesador. • Desarrollo de software de control. • Desarrollo de arquitectura de hardware que soporte el sistema embebido • Desarrollo del componente acelerador/aplicación especifica implementado en hardware. • Desarrollo del canal de comunicación hardware/software.

4. Diseño embebido en una FPGA (SoC) (continuación) • El sistema embebido desarrollado esta compuesto por un microprocesador (hard-core/soft-core), un conjunto de componentes de hardware necesarios para el funcionamiento del mismo y el sw de control necesario. • Un sistema embebido es un sistema de computación diseñado para cumplir una o mas funciones dedicadas, en muchos casos con requerimientos de tiempo real. • Esto es una gran diferencia con una computadora de propósito general, la cual esta diseñada para satisfacer un gran rango de usuarios finales.

5. Diseño embebido en una FPGA (SoC) (continuación) • El Hardware de los sistemas embebido es generalmente diferente al hardware de los sistemas tradicionales • Diferentes Arquitecturas de CPUs: ARMS, MIPS, Powerpc, Microblaze, etc. • El almacenamiento permanente es en dispositivos FLASH con capacidad limitada. • El almacenamiento dinámico en RAM también tiene capacidad limitada. • Buses de interconexión generalmente no encontrados en las PCs de escritorio: Xilinx Crossconnect, I2C, CAN, SPI, etc. • Facilidades de debugging generalmente no disponibles en PCs de escritorio: JTAG, puerto serial, GPIOs, LEDs, etc. • El software de control del sistema operativo puede ser cualquier tipo de binario ejecutable por el procesador. • Una sabia eleccion es utilizar un sistema operativo

6. Estrategia de aprendizaje • Vamos ha abordar el tema en 3 secciones (1 o mas clases por sección) • GNU Linux generalidades • Linux kernel arquitectura – detalles • Kernel drivers • Asignaciones practicas • Individuales o en grupo • Entre semana y semana, comunicación por maillist. • Algunas a ver durante el horario del martes.

7. Arquitectura de alto nivel del SW control

8. Arquitectura de alto nivel del SW control (continuación) • Hardware • Soporte para el procesador que ejecuta el Sw del sistema embebido. • Booloader • Es el punto de ejecución inicial (reset vector) del hardware, responsable por la inicialización básica, carga y ejecucion del kernel. • Linux Kernel • Contiene las diversas funcionalidades del kernel y provee servicios a las aplicaciones de espacio de usuario (userspace) • Libreria estandard de C • Es la interface entre el kernel y las aplicaciones de userspace • Librerias y aplicaciones • Código desarrollado para implementar algoritmos en particular. Interactúan con el kernel a través de la librería standard de C.

9. Linux Kernel • Linux es un kernel utilizado por un sistema operativo • Maneja recursos del sistema y la comunicación entre los componentes del sistema. • Provee una capa de abstracción a la interacción de bajo nivel con los dispositivos del sistema (memoria, procesadores, dispositivos de I/O). • Provee mecanismos para la implementación de procesos de usuarios, llamadas a sistema, comunicaciones entre procesos, etc.

10. Linux Kernel (continuación) • Desarrollado por Linux Torvalds como un kernel open source para remplazar el kernel de Minix • Liberado en 1991 originalmente solo para x86 • Actualmente Linux corre en mas de 30 arquitecturas • Implementaciones de 32 y 644 bits • Licenciado como GPL v2 • GNU Linux se puede encontrar en todo tipo de dispositivos, desde teléfonos celulares hasta cluster de computadoras de alta performance • http://www.top500.org/stats

11. Linux Kernel (continuación) • Técnicamente Linux es solamente el kernel del sistema operativo. • Un sistema que utiliza herramientas del proyecto GNU y esta basado en Linux tiene que ser llamado un sistema GNU-Linux. • Una distribución de linux es básicamente un conjunto de kernel, librerías y código de soporte para bootear y correr un sistema GNU Linux en una plataforma determinada.

12. Versiones del kernel del Linux • Existe un solo repositorio para mantener el código del kernel (git.kernel.org). • Las versiones de kernel tomadas de kernel.org se conoces como vainilla kernels. • 2.6.<par>: Kernel estable • 2.6.<impar>: Menos estable que el anterior • 2.<par>.x: NuevoRelease. Grandes cambios. • 2.<impar>.x: Release inestable.

13. Versiones de GNU-Linux • Existe un solo kernel pero muchos usuarios. • Algunos de estos usuarios desarrollan ramas alternativas del kernel destinados a distintos sectores de la industria • Enterprise, Embedded y Carrier-Grade linux • La rama enterprise esta destinada a usuarios de escritorio o empresas • Compuesto por empresas como Red hat, Novell, Ubuntu, etc.

14. Versiones de GNU-Linux (continuación) • La rama carrier-grade (CGL) es otro sabor de linux destinado a equipos de telecomunicaciones y de servicio critico. • Compuesto por empresas como Montavista, WindRiver, etc. • La rama de embedded esta destinada a usuarios de sistemas embebidos. • Compuesto por empresas/grupos como LynuxWorks, Openmoko, OpenWrt, etc.

15. Requerimientos para ejecutar el kernel • Los requerimientos para volver funcional un kernel Linux es utilizar una arquitectura soportada y tener un file system con las aplicaciones necesarias para utilizarlo. • En Linux los sistemas de archivos están dispuestos de tal forma que forman un sistema jerárquico. • En los sistemas embebidos el sistema de archivo raíz (root filesystem) contiene las librerías, aplicaciones y datos necesarios para que bootee el sistema. • Construir el root file system es una de las tareas principales del sistema embebido

16. Proceso de booteo del kernel • Encendido o reset del hardware • El CPU del sistema embebido salta al vector de reset • En este vector/dirección reside el firmware de inicialización (bootloader, bios, etc). • El firmware coloca la imagen comprimida del kernel de Linux en RAM, apunta el IP/PC al inicio de la seccion ejecutable de la imagen y la ejecuta • Hay muchas maneras a través de las cuales se puede obtener una imagen de Linux

17. Proceso de booteo del kernel (continuación) • El kernel de linux se autodescomprime en RAM (vmlinuz a vmlinux), se realoca y salta al código boot-strap especifico de cada arquitectura (head.S). • Este código parsea y utiliza un conjunto de parámetros de inicialización pasados a través del bootloader. • Las secciones arquitectura-especifica del kernel se ejecutan primero y preparan el contexto de ejecución del resto del kernel. • Luego de algunos procesos de inicialización genéricos se llama a start_kernel() ubicada en init/main.c.

18. Proceso de booteo del kernel (continuación) • Dentro de start_kernel() se desencadenan la inicializacion y configuracion de todos los subsistemas • - Inicialización de dispositivos. • - Configuración de interrupciones • - Inicialización de múltiples CPUs • - Inicialización del manejo virtual de memoria • - Inicialización del subsistema del scheduler • - Se inicializan todos los drivers compilados como built-in en el kernel. • - Inicialización de subsistema de red • - Se inicializa el subsistema de archivos • - Se monta el root filesystem • - Se inicializa el scheduler • - Se crean dos threads del kernel: idle e init.

19. Proceso de booteo del kernel (continuación) • El thread idle se ejecuta cada vez que el scheduler no tiene trabajo para asignarle al procesador/procesadores. • En algunas arquitecturas este thread tiene el codigo necesario para "apagar" cpus o ponerlos en modo bajo consumo • Con el root filesystem montado, EI thread init tiene el código necesario para buscar y ejecutar alguno de estos binarios • <path_configurable> = pasado como parámetro del kernel • /sbin/init • /etc/init • /bin/init • /bin/sh

20. Proceso de booteo del kernel (continuación) • El binario init realiza el resto de la inicialización • Ejecuta los scripts de inicialización del filesystem. • Configura red, monta filesystems adicionales, etc. • Ejecuta los scripts de runlevel. • Ejecuta getty para futura interaccion con el usuario

21. Compilación del kernel • Para compilar el kernel necesitamos tener un toolchain para la arquitectura de destino. • Lo primero es obtener las fuentes • Release oficiales de Kernel.org • SVN proyecto googlecode • Git kernel.org • Luego hay que ubicar los crosscompiladores de C/C++ en el toolchain y determinar si están en el path • El prefix de los compiladores se pasara como argumento al makefile de compilación. • Es necesario determinar cual sera la arquitectura de destino.

22. Compilación del kernel (continuación) • Luego hay que exportar la variable INSTALL_MOD_PATH con un destino para los modulos a compilar. • mkdir modules && cd modules && export INSTALL_MOD_PATH=`pwd` • Se configura el kernel para soportar los dispositivos del sistema embebido. Para configurar el kernel se ejecuta el target menuconfig • make ARCH=ppc CROSS_COMPILE=powerpc-linux-uclibc menuconfig

23. Compilación del kernel (continuación) • Para limpiar una compilación anterior • make ARCH=ppc CROSS_COMPILE=powerpc-linux-uclibc clean • Para compilar una configuración • make ARCH=ppc CROSS_COMPILE=powerpc-linux-uclibc • Para compilar he instalar los módulos en el directorio especificado • make ARCH=ppc CROSS_COMPILE=powerpc-linux-uclibc modules_install • Una vez compilado, el binario que será utilizado para bootear el kernel se encuentra en alguno de los directorios de arch/<arquitectura>/boot • Para PPC en: arch/ppc/boot/images/zImage.elf • Para X86 en: arch/x86/boot/bzImage

24. Root filesystem • El conjunto de archivos a partir del directorio / • Todos los programas de userspace, los archivos, los devices nodes y otros archivos especiales se encuentran en el root filesystem. • Los filesystem extras se pueden montar a partir del root filesystem. • Algunos pueden ser temporarios como /tmp • Otros generados en tiempo de ejecucion (Virtual filesystems): /proc, /dev, /sys.

25. Toolchain de crosscompilación • Suite de compilación que se ejecuta en el entorno de desarrollo pero que genera código para la arquitectura del sistema embebido • Si el sistema embebido tiene los recursos de procesamiento, es posible generar un suite de compilación nativa • Para generar un toolchain de crosscompilación necesitamos: • Generar los compiladores • Generar las librerías de soporte (libc, openssl, etc) • Generar el rootfilesystem acorde al escenario que querramos

26. Creación del root filesystem • Existen algunas distribuciones comerciales para sistemas embebidos que traen herramientas para crear/customizar el filesystem. • Existe herramientas desarrolladas y soportadas por la comunidad como OpenEmbedded y Buildroot. • Se puede crear el filesystem a mano • dd para crear el filesystem • mount para montarlo • crear estructura de directorios y copiar binarios/archivos necesarios adentro • configurar scripts de inicializacion

27. Crosscompiladores • Se utiliza GCC compilado para otra arquitectura. • Puede ser nativamente (corre en la procesador de destino) o en modo crosscompilación (corre en x86 y genera código para procesador de destino) • GCC es una suite de compilación desarrollada por Richard Stallman. • Por estos días incluye compiladores ylinkers para C, C++, JAVA, Fortran, ADA, etc. • Incluye herramientas de debugging como gdb.

28. Buildroot • Buildroot es una herramienta que permite generar crosccompiladores, librerías de soporte, aplicaciones y root file systems para diferentes arquitecturas. • http://buildroot.uclibc.org/ • Provee un entorno de configuración parecido al del kernel. • Permite generar imágenes con el contenido del filesystem • Permite trabajar con versiones actuales de las aplicaciones

29. Arquitectura de alto nivel del SW control

30. Libreria Glibc • Libreria de C estandar del proyecto GNU • http://www.gnu.org/software/libc/ • Diseñada para performance, cumplimiento del estandar y portabilidad • Se pueden encontrar en todo sistema GNU • Por lo general, demasiado grande para sistemas embebidos • Por ejemplo, un hello world ocupa 12 KB linkeado dinamicamente y 350KB linkeado estaticamente

31. Libreria uClibc • Libreria estandar de C diseñada para sistemas embebidos. • http://www.uclibc.org/ • Soporta toda las features de la Glibc. • Debian woody la usa. • En algunas funcionalidades el espacio reducido se obtiene sacrificando performance, en otro casos se reduce código duplicado, duplicación de datos, etc. • Por ejemplo, el hello world anterior ocupa 2 KB linkeado dinámicamente y 18KB linkeado estaticamente

32. Busybox • La mayoría de los comandos de Linux y servicios en un solo ejecutable. • http://www.busybox.net/ • Footprint reducido: Menos de 1MB compilado estáticamente con glibc y menos de 500 KB compilado estáticamente con uClibc. • Funcionalidades configurables. • Ampliamente utilizado en la industria.

33. Arquitectura de alto nivel del SW control

34. Gracias! Preguntas?

35. Practico