Embedded Linux system development

Embedded Linux system development DSI

Embedded Linux Free Electrons Developers

© Copyright 2004-2018, Free Electrons. Creative Commons BY-SA 3.0 license. Latest update: March 14, 2018. Document updates and sources: http://free-electrons.com/doc/training/embedded-linux Corrections, suggestions, contributions and translations are welcome!

DSI - FCEIA http://dsi.fceia.unr.edu.ar 1/263 Derechos de copia

© Copyright 2018, Luciano Diamand Licencia: Creative Commons Attribution - Share Alike 3.0 http://creativecommons.org/licenses/by-sa/3.0/legalcode Ud es libre de: I copiar, distribuir, mostrar y realizar el trabajo I hacer trabajos derivados I hacer uso comercial del trabajo Bajo las siguientes condiciones: I Atribuci´on. Debes darle el cr´editoal autor original. I Compartir por igual. Si altera, transforma o construye sobre este trabajo, usted puede distribuir el trabajo resultante solamente bajo una licencia id´enticaa ´esta. I Para cualquier reutilizaci´ono distribuci´on,debe dejar claro a otros los t´erminos de la licencia de este trabajo. I Se puede renunciar a cualquiera de estas condiciones si usted consigue el permiso del titular de los derechos de autor.

El uso justo y otros derechos no se ven afectados por lo anterior.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 2/263 Hiperv´ınculosen el documento

Hay muchos hiperv´ınculosen el documento

I Hiperv´ıncluosregulares: http://kernel.org/

I Enlaces a la documentaci´ondel Kernel: Documentation/kmemcheck.txt

I Enlaces a los archivos fuente y directorios del kernel: drivers/input include/linux/fb.h

I Enlaces a declaraciones, definiciones e instancias de los simbolos del kernel (funciones, tipos, datos, estructuras): platform_get_irq() GFP_KERNEL struct file_operations

DSI - FCEIA http://dsi.fceia.unr.edu.ar 3/263 Introducci´ona Linux Embebido

Introducci´ona DSI

Embedded Linux Linux Embebido Developers

Free Electrons

© Copyright 2004-2018, Free Electrons. Creative Commons BY-SA 3.0 license. Corrections, suggestions, contributions and translations are welcome!

DSI - FCEIA http://dsi.fceia.unr.edu.ar 4/263 Nacimiento del software libre

I 1983, Richard Stallman, proyecto GNU y el concepto de software libre. Comienza el desarrollo de gcc, gdb, glibc y otras herramientas importantes

I 1991, Linus Torvalds, proyecto Linux kernel, un nucleo de sistema operativo similar a Unix. Junto con el software GNU y otros componentes de c´odigoabierto: forman un sistema operativo completo GNU/Linux

I 1995, Linux es m´aspopular en sistemas servidor

I 2000, Linux es m´aspopular en sistemas embebidos

I 2008, Linux es m´aspopular en dispositivos m´oviles

I 2010, Linux es m´aspopular en tel´efonos

DSI - FCEIA http://dsi.fceia.unr.edu.ar 5/263 ¿Software libre?

I Un programa es considerado libre cuando su licencia ofrece a todos sus usuarios las siguientes cuatro libertades

I Libertad de ejecutar el Sofrware para cualquier prop´osito I Libertad de estudiar el Software y modificarlo I Liberatd de redistribuir copias I Libertad de distribuir copias de versiones modificadas

I Estas libertades estan concedidas para uso tanto comercial como no-comercial

I Implican la disponibilidad del c´odigofuente, el Software puede ser modificado y distribuido a los clientes

I Una opci´oninteresante para los sistemas embebidos!

DSI - FCEIA http://dsi.fceia.unr.edu.ar 6/263 ¿Qu´ees Linux embebido?

Linux embebido es el uso del kernel de Linux y varios componentes open-source en sistemas embebidos

DSI - FCEIA http://dsi.fceia.unr.edu.ar 7/263 Introducci´ona Linux Embebido

Ventajas de Linux y open-source para sistemas embebidos

DSI - FCEIA http://dsi.fceia.unr.edu.ar 8/263 Reutilizaci´onde componentes

I La principal ventaja de Linux y open-source en sistemas embebidos es la habilidad de reutilizar componentes

I El ecosistema de open-source ya provee de varios componentes para caracter´ısticasestandares, desde soporte de Hardware hasta protocolos, pasando por multimedia, gr´aficos, bibliotecas criptogr´aficas,etc.

I Tan pronto como un dispositivo Hardware, o un protocolo, o una caracter´ısticase torna conocida, existen varias chances de tener un componente open-source que lo soporte.

I Permite dise˜nar de forma r´apiday desarrollar productos complejos, basados en componentes existentes.

I No es necesario redesarrollar otro kernel de sistema operativo, una pila TCP/IP, una pila USB u otra biblioteca gr´afica.

I Permite enfocarce en el valor agregado del producto.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 9/263 Bajo costo

I El Software libre puede ser duplicado en la cantidad de dispositivos que se quiera, libre de cargos.

I Si su sistema embebido utiliza solo Software libre, se puede reducir los costos de licencias de Software a cero. Incluso, las herramients de desarrollo son libres, a menos que se elija una versi´onde Linux embebido comercial.

I Permite tener un mayor presupuesto para el Hardware o para incrementar las habilidades y conocimiento de la compan´ıa

DSI - FCEIA http://dsi.fceia.unr.edu.ar 10/263 Control total

I Con c´odigoabierto, disponemos del c´odigofuente de todos los componentes del sistema

I Permite modificaciones ilimitadas, cambios, ajustes, depuraci´on,optimizaci´on,por un per´ıodo de tiempo ilimitado I Sin una dependencia ”bloqueante” de un vendedor externo

I Componentes que no sean de c´odigoabierto se deben evitar cuando el sistema se dise˜na y desarrolla

I Permite tener un control total sobre el Software que forma parte del sistema

DSI - FCEIA http://dsi.fceia.unr.edu.ar 11/263 Calidad

I Varios componentes de c´odigoabierto son ampliamente utilizados en millones de sistemas

I Generalmente son de mayor calidad que los desarrollos in-house o incluso de los vendedores propietarios

I Por supuesto, no todos los componentes de c´odigoabierto son de buena calidad, pero los m´asampliamente utilizados los son.

I Permite dise˜nar su sistema con componentes fundacionales de alta calidad

DSI - FCEIA http://dsi.fceia.unr.edu.ar 12/263 Facilita la prueba de nuevas caracteristicas

I Dado la disponibilidad del c´odigoabierto, es simple obtener una copia del Software para evaluarlo

I Permite de forma simple estudiar las opciones mientras se est´a decidiendo

I Mucho m´assimple que la compra y procesos de demostraci´on necesitan con la mayor´ıade los productos propietarios

I Permiten explorar de forma simple nuevas posibilidades y soluciones

DSI - FCEIA http://dsi.fceia.unr.edu.ar 13/263 Soporte de la comunidad

I Los componentes de Software de c´odigoabierto son desarrollados por comunidades de desarrolladores y usuarios

I Esta comunidad puede proveer soporte de alta calidad: se puede contactar directamente a los desarrolladores principales del componente que se est´ausando. La probabilidad de obtener una respuesta no depende de la compan´ıapara la que trabajemos.

I En general mejor que el soporte tradicional, pero es necesario entender como funciona la comunidad para hacer un uso correcto de las posibilidades de soporte

I Permite acelerar la resoluci´onde problemas cuando se est´edesarrollando el sistema

DSI - FCEIA http://dsi.fceia.unr.edu.ar 14/263 Formando parte de la comunidad

I La posibilidad de formar parte de la comunidad de desarrollo de algunos de los componentes utilizados en sistemas embebidos: reporte de fallas, prueba de nuevas versiones y caracter´ısticas,parches que corrigen errores o agregan nuevas caracter´ısticas,etc. I La mayor´ıadel tiempo, los componentes de c´odigoabierto no son el n´ucleode valor del producto: es interes de todos contribuir al mismo I Para los ingenieros: una forma muy motivante de ser reconocido fuera de la compan´ıa,comunicarse con otros en el mismo campo, la oportunidad de nuevas posibilidades, etc. I Para los gerentes: factor de motivaci´on para los ingenieros, permite a la compan´ıaser reconocida en la comunidad de c´odigoabierto y por lo tanto obtener soporte de forma m´as simple y ser m´asatractivo para los desarrolladores de c´odigo abierto

DSI - FCEIA http://dsi.fceia.unr.edu.ar 15/263 Introducci´ona Linux Embebido

Algunos ejemplos de sistemas embebidos ejecutando Linux

DSI - FCEIA http://dsi.fceia.unr.edu.ar 16/263 Ruters personales

DSI - FCEIA http://dsi.fceia.unr.edu.ar 17/263 Televisi´on

DSI - FCEIA http://dsi.fceia.unr.edu.ar 18/263 Terminales de punto de venta

DSI - FCEIA http://dsi.fceia.unr.edu.ar 19/263 Maquinas de corte Laser

DSI - FCEIA http://dsi.fceia.unr.edu.ar 20/263 Maquina de Viticultura

DSI - FCEIA http://dsi.fceia.unr.edu.ar 21/263 Introducci´ona Linux Embebido

Hardware para sistemas embebidos en Linux

DSI - FCEIA http://dsi.fceia.unr.edu.ar 22/263 Procesador y arquitectura (1)

I El kernel de Linux y la mayor´ıade otros componentes dependientes de la arquitectura soportan un amplio rango de arquitecturas de 32 y 64 bits

I x86 y x86-64, como se encuentran en plataformas PC, pero tambi´ensistemas embebidos (multimedia, industrial) I ARM, con miles de diferentes SoC (multimedia, industrial) I PowerPC (principalmente aplicaciones en tiempo real e industriales) I MIPS (principalmente para aplicaciones de red) I SuperH (principalmente aplicaciones multimedia) I Blackfin (arquitectura DSP) I Microblaze (soft-core para FGPA de Xilinx) I Coldfire, SCore, Tile, Xtensa, Cris, FRV, AVR32, M32R

DSI - FCEIA http://dsi.fceia.unr.edu.ar 23/263 Procesador y arquitectura (2)

I Ambas arquitecturas, MMU y no-MMU son soportadas, aunque la arquitectura no-MMU tiene algunas limitaciones.

I Linux no est´adise˜nadopara microcontroladores peque˜nos.

I Salvo el juego de herraminetas, el cargador de inicio y el kernel, todos los otros componentes generalmente son independientes de la arquitectura

DSI - FCEIA http://dsi.fceia.unr.edu.ar 24/263 RAM y almacenamiento

I RAM: un sistema b´asicocon Linux puede funcionar con 8 MB de RAM, pero un sistema m´asrealista usualmente requiere 32 MB de RAM. Depende del tipo y tama˜node la aplicaci´on. I Almacenamiento: un sistema b´asicocon Linux puede trabajar con 4 MB de almacenamiento, pero usualmente se requiere una mayor cantidad.

I El almacenamiento en Flash est´asoportado, tanto flash NAND como NOR, con sistemas de archivos espec´ıficos I Almacenamiento en bloque incluyendo tarjetas SD/MMC y eMMC son soportadas

I Es preferible no tener muchas restricciones en la cantidad de RAM/almacenamiento: tener una cierta flexibilidad en este nivel nos permite reutilizar tantas aplicaciones como sea posible.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 25/263 Comunicaci´on

I El kernel de Linux tiene soporte para varios protocolos de comunicaciones comunes

I I2C I SPI I CAN I 1-wire I SDIO I USB I Y tambi´ensoporte para redes extensivo

I Ethernet, Wifi, Bluetooth, CAN, etc. I IPv4, IPv6, TCP, UDP, SCTP, DCCP, etc. I Firewalling, ruteo avanzado, multicast

DSI - FCEIA http://dsi.fceia.unr.edu.ar 26/263 Tipos de Hardware y plataformas 1/2

I Plataformas de evaluaci´on del proveedor de SoC. Usualmente costosas, pero con muchos perifericos incluidos. Generalmente no recomendable para productos reales.

I Componente en M´odulo, una peque˜naplaca solamente con CPU/RAM/flash y algunos otros componentes, con conectores para acceder a todos los perif´ericos.Puede ser utilizado para construir productos finales en peque˜naso medianas cantidades.

I Plataformas de desarrollo comunitario, una nueva tendencia para hacer un SoC particular popular y facilmente disponible. Estas est´anlistas para utilizar y a un bajo costo, pero generalmente tienen menos perif´ericosque las plataformas de evaluaci´on.En algunos casos pueden ser utilizadas para productos reales.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 27/263 Tipos de Hardware y plataformas 1/2

I Plataforma personalizada. Los esquem´aticospara placas de evaluaci´ono plataformas de desarrollo est´andisponibles m´as comunmente de forma libre, haciendo mas simple el desarrollo de plataformas personalizadas.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 28/263 Criterios para la elecci´ondel Hardware

I Asegures´eque el Hardware que planea utilizar est´a actualmente soportado por el kernel de Linux, y posee un cargador de inicio de c´ogioabierto, especialmente para el SoC destino.

I Teniendo soporte en las versiones oficiales de los proyectos (kernel, cargador de inicio): la calidad es mejor, y nuevas versiones est´andisponibles.

I Algunos proveedores de SoC y/o proveedores de placas no contribuyen sus cambios hacia la linea principal del kernel de Linux. Recomiende que lo hagan, o utilice otro producto de ser posible. Una buena m´etricaes ver las diferencias entre su kernel y el oficial.

I Entre un hardware correctamente soportado en el kernel oficial de Linux y un hardware mal soportado, existiran enormes diferencias en tiempo de desarrollo y costo.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 29/263 Introducci´ona Linux Embebido

Arquitectura de sistemas embebidos en Linux

DSI - FCEIA http://dsi.fceia.unr.edu.ar 30/263 Arquitectura global

DSI - FCEIA http://dsi.fceia.unr.edu.ar 31/263 Componentes Software

I Juego de herramientas de compilaci´oncruzada

I Compilador que corre en la m´aquinade desarrollo, pero genera c´odigopara el destino I Cargador de inicio

I Ejecutado por el Hardware, responsable de la inicializaci´on b´asica,cargao y ejecuta el kernel I Kernel de Linux

I Contiene los proceso y el manejo de memoria, red, controladores de dispositivos y provee servicios para la aplicaci´onen el espacio de usuario I Biblioteca C

I La interfaz entre el kernel y las aplicaciones en el espacio de usuario I Bibliotecas y aplicaciones

I De terceros (Third-party or in-house)

DSI - FCEIA http://dsi.fceia.unr.edu.ar 32/263 Trabajo sobre Linux embebido

Varias tareas de distinto tipo se necesitan al momento de desplegar un Linux embebido en un producto:

I Board Support Package development (BSP)

I Un BSP contiene un bootloader y un kernel con los device drivers adecuados para el Hardware destino I Es el prop´ositodel entrenamiento en desarrollo del Kernel I Integraci´ondel sistema

I Integrar todos los componentes, bootloader, kernel, y bibliotecas de terceros y aplicaciones y aplicaciones in-house en un sistema funcional I Es el prop´ositode este entrenamiento I Desarrollo de aplicaciones

I Aplicaciones Linux normales, pero utilizando bibliotecas especialmente elegidas

DSI - FCEIA http://dsi.fceia.unr.edu.ar 33/263 Embedded Linux development environment

Embedded Linux development DSI

Embedded Linux environment Developers

Free Electrons

© Copyright 2004-2018, Free Electrons. Creative Commons BY-SA 3.0 license. Corrections, suggestions, contributions and translations are welcome!

DSI - FCEIA http://dsi.fceia.unr.edu.ar 34/263 Soluciones de Linux Embebidas

I Dos formas de cambiar a Linux embebido

I Utilice soluciones proporcionadas y apoyadas por vendedores como MontaVista, Wind River o TimeSys. Estas soluciones vienen con sus propias herramientas de desarrollo y entorno. Utilizan una mezcla de componentes de c´odigo abierto y herramientas propietarias. I Utilice soluciones comunitarias. Est´an completamente abiertas, soportado por la comunidad. I En estas sesiones de formaci´on,no promovemos un Proveedor y, por lo tanto, utilizamos soluciones comunitarias

I Sin embargo, conociendo los conceptos, cambiar a otro proveedor es simple

DSI - FCEIA http://dsi.fceia.unr.edu.ar 35/263 SO para el desarrollo de Linux

I Recomendamos encarecidamente el uso de Linux como sistema para incorporar a los desarrolladores de Linux, por m´ultiplesrazones. I Todas las herramientas de la comunidad est´andesarrolladas y dise˜nadaspara funcionar Linux. Intentar utilizarlos en otros sistemas operativos (Windows, Mac OS X) conducir´aa problemas, y su uso en estos sistemas generalmente no son apoyados por los desarrolladores de la comunidad. I Como Linux tambi´ense ejecuta en el dispositivo embebido, todo el conocimiento ganado por el uso de Linux en el escritorio se aplicar´ade manera directa al dispositivo embebido.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 36/263 Distribuci´onde Linux de escritorio

I Cualquier distribuci´onde Linux de escritorio suficientemente reciente se puede utilizar para la estaci´onde trabajo de desarrollo

I Ubuntu, Debian, Fedora, openSUSE, Red Hat, etc.

I Hemos elegido Ubuntu, ya que es una distribuci´onde Linux de escritorio ampliamente utilizado y f´acilde usar

I La configuraci´onde Ubuntu en las computadoras port´atilesde formaci´onha quedado intacta despu´es del proceso de instalaci´onnormal. Aprender Linux embebido tambi´enconsiste en aprender las herramientas necesarias en la estaci´on de trabajo de desarrollo!

DSI - FCEIA http://dsi.fceia.unr.edu.ar 37/263 Usuarios root y no root de Linux

I Linux es un sistema operativo multiusuario

I El usuario root es el administrador, y puede realizar operaciones privilegiadas como: montar sistemas de archivos, configurar la red, crear archivos de dispositivos, cambiar la configuraci´ondel sistema, instalar o eliminar software I Todos los otros usuarios no tienen privilegios, y no pueden realizar estas operaciones a nivel de administrador

I En un sistema Ubuntu, no es posible iniciar sesi´oncomo root, s´olocomo usuario normal.

I El sistema se ha configurado para que la primer cuenta de usuario creada pueda ejecutar operaciones privilegiadas a trav´esde un programa llamado sudo.

I Ejemplo: sudo mount /dev/sda2 /mnt/disk

DSI - FCEIA http://dsi.fceia.unr.edu.ar 38/263 Paquetes de Software

I El mecanismo de distribuci´onpara el software en GNU / Linux es diferente de la de Windows

I Las distribuciones de Linux proporcionan una forma central y coherente de instalar, actualizar y eliminar aplicaciones y bibliotecas: paquetes I Packages contains the application or library files, and associated meta-information, such as the version and the dependencies

I .deb en Debian y Ubuntu, .rpm en Red Hat, Fedora, openSUSE

I Los paquetes se almacenan en repositorios, usualmente en servidores HTTP o FTP

I S´olodebe utilizar paquetes de repositorios oficiales para su distribuci´on,a menos que sea estrictamente necesario.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 39/263 Gesti´onde paquetes de software (1)

Instrucciones para los sistemas GNU / Linux basados en Debian (Debian, Ubuntu...)

I Los repositorios de paquetes se especifican en /etc/apt/sources.list

I Para actualizar la lista de paquetes del repositorio: sudo apt-get update

I Para encontrar el nombre de un paquete a instalar, lo mejor es usar el motor de b´usquedaen http://packages.debian.org o en http://packages.ubuntu.com. Tambi´enpuede usar: apt-cache search

DSI - FCEIA http://dsi.fceia.unr.edu.ar 40/263 Gesti´onde paquetes de Software (2)

I Para instalar un paquete dado: sudo apt-get install

I Para eliminar un parquete dado: sudo apt-get remove

I Para instalar todas las actualizaciones de paquetes disponibles: sudo apt-get dist-upgrade

I Para obtener informaci´onacerca de un paquete: apt-cache show I Interfaces gr´aficas

I Para GNOME Synaptic I Para KDE KPackageKit M´asdetalles sobre la gesti´onde paquetes: http://www.debian.org/doc/manuals/apt-howto/

DSI - FCEIA http://dsi.fceia.unr.edu.ar 41/263 Host vs. destino

I Al hacer el desarrollo embebido, siempre hay una divisi´on entre

I El host, la estaci´onde trabajo de desarrollo, que es t´ıpicamenteuna PC potente I El destino, que es el sistema embebido bajo desarrollo

I Est´anconectados por diversos medios: casi siempre una l´ınea serie para fines de depuraci´on,con frecuencia una conexi´on Ethernet, a veces una interfaz JTAG para la depuraci´ona bajo nivel

DSI - FCEIA http://dsi.fceia.unr.edu.ar 42/263 Programa de comunicaci´onpor l´ıneaserie

I Una herramienta esencial para el desarrollo embebido es un programa de comunicaci´onpor l´ıneaserie, como HyperTerminal en Windows

I Hay m´ultiples opciones disponibles en Linux: Minicom, Picocom, Gtkterm, Putty, etc. I En estos sesiones de entrenamiento, recomendamos utilizar el m´assimple de ellos: picocom

I Se instala con sudo apt-get install picocom I Se ejecuta con picocom -b BAUD_RATE /dev/SERIAL_DEVICE I Se termina con Control-A Control-X I Donde SERIAL_DEVICE generalmente es

I ttyUSBx para conversores USB a serie I ttySx para puertos series reales

DSI - FCEIA http://dsi.fceia.unr.edu.ar 43/263 Consejos sobre la l´ıneade comandos

I El uso de la l´ıneade comandos es obligatorio para muchas operaciones necesarias para el desarrollo de Linux

I Es una manera muy poderosa de interactuar con el sistema, con la cual usted puede ahorrar mucho tiempo. I Algunos consejos ´utiles

I Puede utilizar varias pesta˜nasen el Gnome Terminal I Recuerde que puede utilizar rutas de acceso relativas (por ejemplo: ../../ linux) adem´asde rutas absolutas (por ejemplo: /home/user) I En un shell, pulse [Control] [r] y, a continuaci´on,una palabra clave, esto buscar´aa trav´esdel historial de comandos. Presione [Control] [r] de nuevo para buscar hacia atr´asen la historia I Puede copiar y pegar rutas directamente desde el el terminal con arrastrar y soltar.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 44/263 Juego de herramientas de compilaci´oncruzada

Juego de herramientas de compilaci´on DSI

Embedded Linux cruzada Developers

Free Electrons

© Copyright 2004-2018, Free Electrons. Creative Commons BY-SA 3.0 license. Corrections, suggestions, contributions and translations are welcome!

DSI - FCEIA http://dsi.fceia.unr.edu.ar 45/263 Juego de herramientas de compilaci´oncruzada

Definiciones y Componentes

DSI - FCEIA http://dsi.fceia.unr.edu.ar 46/263 Definiciones 1/2

I Las herramientas de desarrollo usualmente disponibles en una estaci´onde trabajo GNU/Linux son un juego de herramientas nativo I Este juego de herramientas corre en la estaci´onde trabajo y genera c´odigopara la propia estaci´onde trabajo (generalmente x86) I Para el desarrollo de sistemas embebidos, es generalmente imposible o no tiene interes el utilizar un juego de herramientas nativo

I El destino es muy restrictivo en terminos de almacenamiento y/o memoria I El destino es muy lento comparado con la estaci´onde trabajo I Puede que no interese instalar todas las herraminetas de desarrollo en el destino. I Por lo tanto, se utilizan generalmente los juegos de herramientas de compilaci´oncruzada. Ellos corren en la estaci´onde trabajo, pero generan c´odigopara el destino.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 47/263 Definiciones 2/2

DSI - FCEIA http://dsi.fceia.unr.edu.ar 48/263 M´aquinas en el proceso de construcci´on

I Se deben distinguir entre tres m´aquinascuando se discute la creaci´ondel juego de herramientas

I La m´aquinade construcci´ono build, donde se construye el juego de herraminetas. I La m´aquina host, donde se ejecuta el juego de herraminetas. I La m´aquinadestino o target, donde los binarios creados por el juego de herraminetas son ejecutados.

I Cuatro formas de construcci´onson posibles para los juegos de herraminetas

DSI - FCEIA http://dsi.fceia.unr.edu.ar 49/263 Construcci´ondel juego de herramientas

DSI - FCEIA http://dsi.fceia.unr.edu.ar 50/263 Componentes

DSI - FCEIA http://dsi.fceia.unr.edu.ar 51/263 Binutils

I Binutils es un juego de herraminetas para generar y manipular binarios para una arquitectura CPU dada

I as, el ensamblador, que genera c´odigobinario desde el c´odigo fuente ensamblador I ld, el enlazador I ar, ranlib, para generar los archivos .a, utilizados por las bibliotecas I objdump, readelf, size, nm, strings, para inspeccionar binarios. Herramientas de an´alisismuy ´utiles! I strip, para cortar partes de binarios in´utilesy de esa forma reducir su tama˜no

I http://www.gnu.org/software/binutils/

I Licencia GPL

DSI - FCEIA http://dsi.fceia.unr.edu.ar 52/263 Cabeceras del Kernel (1)

I La bibilioteca C y los programas compilados necesitan interactuar con el Kernel

I Llamadas al sistema disponibles y sus correspondiente numeraci´on I Definici´onde constantes I Estructuras de datos, etc.

I Por lo tanto, compilar la biblioteca C requiere de las cabeceras del Kernel, y varias aplicaciones tambi´enlas requieren.

I Disponibles en los directorios y y en otros directorios correspondientes a los del directorio include/ en los fuentes del Kernel

DSI - FCEIA http://dsi.fceia.unr.edu.ar 53/263 Cabeceras del Kernel (2)

I N´umerosde llamadas al sistema, en #define __NR_exit 1 #define __NR_fork 2 #define __NR_read 3

I Definiciones de constantes, en , incluidos desde , incluidos desde #define O_RDWR 00000002

I Estructuras de datos, en struct stat { unsigned long st_dev; unsigned long st_ino; [...] };

DSI - FCEIA http://dsi.fceia.unr.edu.ar 54/263 Cabeceras del Kernel (3)

I El ABI del Kernel al espacio de usuario es compatible hacia atras

I Binarios generados con un juego de herramientas utilizando cabeceras del Kernel mas viejas que las del Kernel en ejecuci´on van a funcionar sin problemas, pero no se van a poder llamar a las nuevas llamadas al sistema, estructuras de datos, etc. I Binarios generados con un juego de herramientas utilizando cabeceras del Kernel m´asnuevas que las del Kernel en ejecuc´ıonpueden funcionar si no utilizan las caracter´ısticas recientes, de otra manera van a fallar I Utilizar las ´ultimascabeceras del Kernel no es necesario, salvo que se necesiten las nuevas caracter´ısticasdel Kernel

I Las cabeceras del Kernel se extraen del los fuentes del Kernel utilizando como destino del Makefile headers_install.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 55/263 GCC

I GNU Compiler Collection, el famoso compilador de software libre

I Puede compilar C, C++, Ada, Fortran, Java, Objective-C, Objective-C++, y generar c´odigo para un gran n´umerode arquitecturas de CPU, incluyendo ARM, AVR, Blackfin, CRIS, FRV, M32, MIPS, MN10300, PowerPC, SH, v850, i386, x86 64, IA64, Xtensa, etc.

I http://gcc.gnu.org/

I Disponible bajo la licencia GPL, bibliotecas bajo LGPL.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 56/263 Bibioteca C

I La bibiloteca C es un componente escencial de un sistema GNU/Linux

I Interactua entre la aplicaci´ony el Kernel I Provee una API estandard de C bien conocida para facilitar el desarrollo de aplicaciones

I Hay disponibles varias bibliotecas de C: glibc, uClibc, eglibc, dietlibc, newlib, etc.

I La elecci´onde la biblioteca C se debe realizar en el momento de la generaci´on del juego de herramientas de compilaci´on cruzada, dado que el compilador GCC se compila contra una biblioteca C espec´ıfica.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 57/263 Juego de herramientas de compilaci´oncruzada

Bibliotecas C

DSI - FCEIA http://dsi.fceia.unr.edu.ar 58/263 glibc

I Licencia: LGPL

I Biblioteca C del proyecto GNU

I Dise˜nadopara el rendimiento, el cumplimiento de las normas y la portabilidad

I Se encuentra en todos los sistemas GNU/Linux

I Por supuesto, mantenido activamente

I Muy grande para los sistemas embebidos peque˜nos:aprox 2.5 MB en ARM (versi´on 2.9 - libc: 1.5 MB, libm: 750 KB)

I http://www.gnu.org/software/libc/

DSI - FCEIA http://dsi.fceia.unr.edu.ar 59/263 uClibc

I Licencia: LGPL I Biblioteca de C liviana para sistemas embebidos peque˜nos

I Alta configurabilidad: se pueden activar o deshabilitar muchas funciones a trav´esde una interfaz menuconfig I Funciona s´olocon Linux/uClinux, funciona en la mayor´ıade arquitecturas I No hay compatibilidad binaria garantizada. Puede necesitar recompilar las aplicaciones cuando cambie la configuraci´onde la biblioteca. I Enfocada en el tama˜nom´asque en el rendimiento I Tiempo de compilaci´on corto

I http://www.uclibc.org/

DSI - FCEIA http://dsi.fceia.unr.edu.ar 60/263 uClibc (2)

I Most of the applications compile with uClibc. This applies to all applications used in embedded systems. I Size (arm): 4 times smaller than glibc!

I uClibc 0.9.30.1: approx. 600 KB (libuClibc: 460 KB, libm: 96KB) I glibc 2.9: approx 2.5 MB I Some features not available or limited: priority-inheritance mutexes, NPTL support is very new, fixed Name Service Switch functionality, etc. I Used on a large number of production embedded products, including consumer electronic devices I Supported by all commercial embedded Linux providers (proof of maturity). I Warning: though some development is still happening, the maintainers have stopped making releases since May 2012. The project is in trouble.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 61/263 eglibc

I Embedded glibc, tambi´enlicencia LGPL

I Era una variante de glibc, mejor adaptada a las necesidades de los sistemas embebidos, por un desacuerdo con los mantenedores de la glibc.

I Los objetivos de eglibc incluyeron un menor consumo de memoria, componentes configurables, un mejor soporte para la compilaci´oncruzada y pruebas cruzadas

I Se podr´ıaconstruir sin soporte para NIS, locales, IPv6 y muchos otras caracter´ısticas

I Afortunadamente para eglibc, el mantenedor de glibc ha cambiado y sus caracter´ısticasy ahora se incluyen en glibc. La ´ultimaversi´onfua la 2.19 (Febrero de 2014).

I http:

DSI - FCEIA http://dsi.fceia.unr.edu.ar//en.wikipedia.org/wiki/Embedded_GLIBC 62/263 Cari˜no,encog´ılos programas!

I Comparaci´ondel tama˜noejecutable en ARM, probado con eglibc 2.15 y uClibc 0.9.33.2

I Programa “hello world” (stripped): helloworld estatico din´amico uClibc 18kB 2.5kB uClibc con Thumb-2 14kB 2.4kB eglibc con Thumb-2 361kB 2.7kB

I Busybox (stripped): busybox static dynamic uClibc 750kB 603kB uClibc con Thumb-2 533kB 439kB eglibc con Thumb-2 934kB 444kB

DSI - FCEIA http://dsi.fceia.unr.edu.ar 63/263 Otras bibliotecas de C peque˜nas

I Varias bibliotecas C m´aspeque˜nashan sido desarrolladas, pero ninguna de ellas tiene como objetivo de permitir la compilaci´onde grandes aplicaciones ya existentes

I Necesitan programas y aplicaciones especialmente escritas I Opciones:

I Dietlibc, http://www.fefe.de/dietlibc/. Aproximadamente 70 KB. I Newlib, http://sourceware.org/newlib/ I Klibc, http://www.kernel.org/pub/linux/libs/klibc/, dise˜nadopara ser utilizado con initramfs o initrd en el momento del arranque.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 64/263 Juego de herramientas de compilaci´oncruzada

Opciones del Juego de herramientas

DSI - FCEIA http://dsi.fceia.unr.edu.ar 65/263 ABI (Application Binay Interface)

I Cuando se construye un juego de herramientas, el ABI utilizado para generar los binarios debe ser definido

I ABI define la convenci´onde llamadas (como se pasan los argumentos a una funci´on,como se retorna el valor, como se realizan las llamadas al sistema) y la organizaci´onde las estructuras (alineamiento, etc.)

I Todos los binarios en un sistema deben ser compilados con el mismo ABI, y el kernel debe entender dicho ABI. I En ARM, existen dos ABIs: OABI and EABI

I Actualmente se utiliza EABI

I En MIPS, existen varios ABIs: o32, o64, n32, n64

I http://en.wikipedia.org/wiki/Application_Binary_ Interface

DSI - FCEIA http://dsi.fceia.unr.edu.ar 66/263 Soporte para punto flotante

I Algunos procesadores poseen una unidad de punto flotante, y otros no. I Por ejemplo, muchas CPUs ARMv4 y ARMv5 no tienen una unidad de punto flotante. Desde ARMv7, la unidad VFP (Vector Floating Point) es obligatoria. I Para los procesadores que cuentan con una unidad de punto flotante, el juego de herramientas debe generar c´odigo hard float, y as´ıpoder utilizar las instrucciones de punto flotante directamente I Para procesadores sin unidad de punto flotante, existen dos soluciones I Generar hard float code y dejar que el kernel emule las instrucciones de punto flotante (esto es muy lento). I Generar soft float code, para que en lugar de generar instrucciones de punto flotante, se generen llamadas a librerias en el espacio de usuario I Esta decisi´ondebe ser tomada en el momento de configuraci´ondel juego de herramientas DSI - FCEIA http://dsi.fceia.unr.edu.arI Tambi´enes posible configurar que unidad de punto flotante va 67/263 a ser utilizada Banderas de optimizaci´onde CPU

I Un juego de herramientas para compilaci´oncruzada es espec´ıficopara una arquitectuda de CPU (ARM, x86, MIPS, PowerPC) I Sin embargo, con la opci´on -march=, -mcpu=, -mtune=, se puede seleccionar de forma m´asprecisa el tipo de CPU destino

I Por ejemplo, -march=armv7 -mcpu=cortex-a8 I En el momento de compilar el juego de herramientas, se pueden elegir estos valores, los cuales ser´anutilizados:

I Como valores por defecto para las herramientas de compilaci´on cruzada, cuando ninguna otra opci´on -march, -mcpu, -mtune es utilizada I Para compilar la biblioteca C

I Incluso si la biblioteca C fue compilada para armv5t, no prohibe de compilar otros programas para armv7

DSI - FCEIA http://dsi.fceia.unr.edu.ar 68/263 Juego de herramientas de compilaci´oncruzada

Obteniendo el juego de herramientas

DSI - FCEIA http://dsi.fceia.unr.edu.ar 69/263 Construir el juego de herramientas de forma manual

Construir el juego de herramientas para la compilaci´oncruzada uno mismo es una tarea dificil y compleja que puede llevar d´ıase incluso semanas! I Gran cantidad de detalles para aprender: muchos componentes, configuraciones complicadas I Muchas decisiones que tomar (como ser la versi´onde la biblioteca C, ABI, mecanismos de punto flotante, versiones de los componentes) I Son necesarios los fuentes de las cabeceras del Kernel y la biblioteca C I Es necesario estar familiarizado con los problemas actuales y parches de gcc para su plataforma I Es ´utilestar familiarizado con las herramientas de construcci´ony configuraci´on I Vea el directorio docs/ de Crosstool-NG para detalles de como se construyen los juegos de herramientas.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 70/263 Obtener un juego de herramientas pre-compilado

I Es una soluci´onutilizada por muchas personas

I Ventaja: es la soluci´onm´assimple y la m´asconveniente I Desventaja: no es posible realizar un ajuste fino del juego de herramientas de acuerdo a sus necesidades

I Determinar que juego de herramientas necesita: CPU, endianism, biblioteca C, versi´onde componentes, ABI, soft float o hard float, etc.

I Verificar que los juegos de herramientas disponibles se ajustan a sus requerimientos. I Opciones posibles

I Juegos de herramientas de Sourcery CodeBench I Juegos de herramientas de Linaro I M´asreferencias en http://elinux.org/Toolchains

DSI - FCEIA http://dsi.fceia.unr.edu.ar 71/263 Sourcery CodeBench

I CodeSourcery fue una compan´ıacon un gran conocimiento en juegos de herramientas libres: gcc, gdb, binutils y glibc. Fue adquirida por Mentor Graphics, la cual contin´uabrindando servicios y productos similares

I Venden juegos de herramientas con soporte, pero tambi´en poseen una versi´on”Lite”, que es de libre y se puede utilizar en productos comerciales I Tienen juegos de herramientas disponibles para

I ARM I MIPS I PowerPC I SuperH I x86

I Aseg´uresede utilizar versiones Linux. Las versiones EABI son para el desarrollo bare-metal (sin sistema operativo)

DSI - FCEIA http://dsi.fceia.unr.edu.ar 72/263 Juego de herramientas de Linaro

I Linaro contribuye a mejorar la l´ıneaprincipal de gcc para ARM, en particular contratando desarrolladores de CodeSourcery.

I Para aquellos que no pueden esperar por la pr´oxima versi´onde gcc, Linaro lanza los fuentes modificados de versiones estables de gcc, con optimizaciones para ARM (en general para CPUs Cortex recientes).

I Como cualquier versi´onde gcc, estos fuentes pueden ser utilizados por las herramientas de construcci´onpara construir sus propios juegos de herramientas binarios (Buildroot, OpenEmbedded, etc.) Esto permite soportar glibc, uClibc y eglibc.

I https://wiki.linaro.org/WorkingGroups/ToolChain

I Paquetes binarios est´andisponibles para usurios de Ubuntu, https://launchpad.net/~linaro- maintainers/+archive/toolchain DSI - FCEIA http://dsi.fceia.unr.edu.ar 73/263 Instalar un juego de herramientas pre-compilado

I Siga el procedimiento de instalaci´onpropuesto por el fabricante

I Generalmente, es tan simple como extraer un archivo tar en la ruta donde quiera que quede instalado.

I Luego, agregue la ruta a los binarios del juego de herramientas en su PATH: export PATH=/path/to/toolchain/bin/:$PATH

I Finalmente, compile sus aplicaciones PREFIX-gcc -o foobar foobar.c

I PREFIX depende de la configuraci´ondel juego de herramientas, y permite distinguir entre herramientas de compilaci´oncruzada y utilidades de compilaci´onnativa

DSI - FCEIA http://dsi.fceia.unr.edu.ar 74/263 Utilidades para construir el juego de herramientas

Otra soluci´ones utilizar utilidades que automatizan el proceso de construcci´ondel juego de herramientas

I Las mismas ventajas que los juegos de herramientas pre-compilados: no necesita involucrarse en los detalles del proceso de construcci´on

I Pero tambi´en ofrece m´asflexibilidad en terminos de configuraci´ondel juego de herramientas, selecci´onde la versi´onde componente, etc.

I Generalmente, tambi´encontienen varios parches que corrijen problemas conocidos en diferentes componentes en algunas arquitecturas

I Multiples herramientas con id´enticosprincipios: shell scripts o Makefile que autom´aticamenterecuperan, extraen, configuran, compilan e instalan los diferentes componentes

DSI - FCEIA http://dsi.fceia.unr.edu.ar 75/263 Utilidades para construir el juego de herramientas (2)

I Crosstool-ng

I Refactorizaci´onde Crosstool, con una configuraci´onsimilar al sistema menuconfig I Caracter´ısticas: soporta uClibc, glibc, eglibc, hard float y soft float, varias arquitecturas I Mantenido activamente I http://crosstool-ng.org/

DSI - FCEIA http://dsi.fceia.unr.edu.ar 76/263 Utilidades para construir el juego de herramientas (3)

Varias utilidades para la construcci´onde sistemas de archivos ra´ız tambi´enpermiten la construcci´onde juego de herramientas I Buildroot

I Basado en Makefile. Puede construir juegos de herramientas basado en (e)glibc, uClibc y musl, para una amplia gama de arquitecturas. I http://www.buildroot.net I PTXdist

I Basado en Makefile, uClibc o glibc, mantenido por Pengutronix I http://pengutronix.de/software/ptxdist/ I OpenEmbedded / Yocto

I Muy completo en prestaciones, pero es un sistema de creaci´on m´ascomplicado I http://www.openembedded.org/ I https://www.yoctoproject.org/

DSI - FCEIA http://dsi.fceia.unr.edu.ar 77/263 Crosstool-NG: instalaci´ony uso

I La instalaci´onde Crosstool-NG se puede realizar a nivel del sistema o solamente de forma local en un directorio particular. Para la instalaci´onlocal: ./configure --enable-local make make install I Varias configuraciones de ejemplo para distintas arquitecturas est´andisponibles en samples, se pueden visualizar utilizando ./ct-ng list-samples I Para cargar una configuraci´onde ejemplo ./ct-ng I Para ajustar la configuraci´on ./ct-ng menuconfig I Para construir el juego de herramientas ./ct-ng build

DSI - FCEIA http://dsi.fceia.unr.edu.ar 78/263 Contenido del juego de herramientas

I Los binarios de compilaci´oncruzada en bin/ I Este directorio puede ser agregado a su PATH para utilizar de forma m´as simple el juego de herramientas I Uno o m´as sysroot, cada uno conteniendo I La biblioteca C y bibliotecas relacionadas, compiladas para el destino I Las cabeceras de la biblioteca C y las cabeceras del Kernel I Hay un sysroot por cada variante: los juegos de herramientas pueden ser multilib si poseen varias copias de la biblioteca C para diferentes configuraciones (por ejemplo: ARMv4T, ARMv5T, etc.) I Los juegos de herramientas de CodeSourcery para ARM son multilib, los sysroots est´anen arm-none-linux-gnueabi/libc/, arm-none-linux-gnueabi/libc/armv4t/, arm-none-linux-gnueabi/libc/thumb2 I Los juegos de herramientas de Crosstool-NG pueden ser multilib tambi´en(todav´ıaen etapa de experimentaci´on),sino el sysroot est´aen DSI - FCEIA http://dsi.fceia.unr.edu.ararm-unknown-linux-glibcgnueabi/sysroot 79/263 Gestor de arranque

DSI

Embedded Linux Gestor de arranque Developers

Free Electrons

© Copyright 2004-2018, Free Electrons. Creative Commons BY-SA 3.0 license. Corrections, suggestions, contributions and translations are welcome!

DSI - FCEIA http://dsi.fceia.unr.edu.ar 80/263 Gestor de arranque

Secuencia de inicio

DSI - FCEIA http://dsi.fceia.unr.edu.ar 81/263 Gestores de arranque

I El gestor de arranque es una pieza responsable de

I Inicializar de forma b´asicael Hardware I Cargar el binario de una aplicaci´on,generalmente el Kernel del sistema operativo, desde el almacenamiento Flash, desde la red, o desde otro tipo de almacenamiento no volatil. I Posibilita descomprimir el binario de la aplicaci´on I Ejecutar aplicaci´on I Adem´asde estas funciones b´asicas,la mayor´ıade los gestores arranque proveen un shell con una serie de comandos implementando diferentes operaciones

I Carga de datos desde el almacenamiento o red, inspecci´onde memoria, diagn´osticos y pruebas de Hardware, etc.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 82/263 Gestores de arranque en x86 1/2

I Los procesadores x86 normalmente se incluyen en una placa con memoria no vol´atilque contiene un programa, el BIOS. I Este programa es ejecutado por CPU luego de reiniciar, y es responsable de la inicializaci´on b´asicadel Hardware y la carga de un fragmento de c´odigodesde una memoria no vol´atil.

I Este bloque de c´odigogeneralmente ocupa los primeros 512 bytes de un dispositivo de almacenamiento

I Este bloque de c´odigosuele ser el gestor de arranque de primer nivel, que cargar´ael gestor de arranque completo.

I T´ıpicamentecomprende los formatos del sistema de archivos de modo que el archivo del Kernel se puede cargar directamente desde un sistema de archivos normal. DSI - FCEIA http://dsi.fceia.unr.edu.ar 83/263 Gestor de arranque en x86 2/2

I GRUB, Grand Unified Bootloader, el m´aspoderoso. http://www.gnu.org/software/grub/

I Puede leer muchos formatos de sistema de archivos para cargar la imagen del kernel y la configuraci´on,proporciona una shell poderosa con varios comandos, puede cargar im´agenesdel kernel a trav´esde la red, etc. I Vea nuestra presentaci´ondedicada para m´asdetalles: http://free-electrons.com/docs/grub/

I Syslinux, para arranque en red y medios extra´ıbles(clave USB, CD-ROM) http://www.kernel.org/pub/linux/utils/boot/syslinux/

DSI - FCEIA http://dsi.fceia.unr.edu.ar 84/263 Arranque en CPUs embebidas: caso 1

I Cuando se activa, la CPU comienza a ejecutar c´odigoen una direcci´onfija

I No hay ning´unotro mecanismo de arranque proporcionado por la CPU

I El dise˜nodel hardware debe garantizar que un chip flash NOR est´econectado para que sea accesible en la direcci´onen la que la CPU comienza a ejecutar instrucciones

I El gestor de arranque de la primera etapa debe estar programado en esa direcci´onen la NOR

I NOR es obligatorio, ya que permite el acceso aleatorio, que NAND no permite

I No muy com´un (poco pr´actico,y requiere una Flash NOR)

DSI - FCEIA http://dsi.fceia.unr.edu.ar 85/263 Arranque en CPUs embebidas: caso 2

I La CPU tiene un c´odigode arranque integrado en ROM

I BootROM en CPUs AT91, ”c´odigoROM” en OMAP, etc. I Los detalles exactos dependen de la CPU I Este c´odigode arranque es capaz de cargar un gestor de arranque de primer nivel desde un almacenamiento en una SRAM interna (la DRAM no se ha inicializado todav´ıa)

I El dispositivo de almacenamiento puede ser: MMC, NAND, flash SPI, UART, etc. I El gestor de arranque de primer nivel es

I Limitado en tama˜nodebido a restricciones de hardware (tama˜noSRAM) I Proporcionado ya sea por el vendedor de la CPU o por proyectos comunitarios

I Este gestor de arranque de primer nivel debe inicializar la DRAM y otros dispositivos de Hardware y cargar el gestor de arranque de segundo nivel en la RAM

DSI - FCEIA http://dsi.fceia.unr.edu.ar 86/263 Arranque en ARM Atmel AT91

I RomBoot: intenta encontrar una imagen de arranque v´alidadesde varias fuentes de almacenamiento y cargarlo en SRAM (DRAM no inicializada todav´ıa). Tama˜nolimitado a 4 KB. Ninguna interacci´ondel usuario es posible en el modo de arranque est´andar. I AT91Bootstrap: se ejecuta desde SRAM. Inicializa la DRAM, el controlador NAND o SPI y carga el gestor de arranque secundario en RAM y lo inicia. No es posible la interacci´oncon el usuario. I U-Boot: se ejecuta desde RAM. Inicializa otros dispositivos hardware (red, USB, etc.). Carga la imagen del n´ucleodesde almacenamiento o red a RAM y lo inicia. Provee un Shell con comandos. I Linux Kernel: se ejecuta desde RAM. Recupera el sistema completamente (los gestores de arranque ya no existen).

DSI - FCEIA http://dsi.fceia.unr.edu.ar 87/263 Arranque en ARM TI OMAP3

I ROM Code: intenta encontrar una imagen de arranque v´alidadesde varias fuentes de almacenamiento y cargarlo en SRAM o RAM (la RAM puede ser inicializada por el c´odigoROM a trav´esde un encabezado de configuraci´on). Tama˜nolimitado a <64 KB. No hay interacci´on del usuario posible. I X-Loader o U-Boot: se ejecuta desde SRAM. Inicializa la DRAM, el controlador NAND o MMC y carga el gestor de arranque secundario en la RAM y lo inicia. No es posible la interacci´ondel usuario. Archivo llamado MLO. I U-Boot: se ejecuta desde RAM. Inicializa otros dispositivos hardware (red, USB, etc.). Carga la imagen del n´ucleodesde almacenamiento o red a RAM y lo inicia. Provee un Shell de comandos. Archivo llamado u-boot.bin o u-boot.img. I Linux Kernel: se ejecuta desde RAM. Recupera el sistema completamente (el gestor no est´am´as

DSI - FCEIA http://dsi.fceia.unr.edu.ar disponible). 88/263 Arranque en Marvell SoC

I ROM Code: intenta encontrar una imagen de arranque v´alidadesde varias fuentes de almacenamiento, y la carga en la RAM. La configuraci´onde RAM se describe en un encabezado espec´ıfico de la CPU, adjuntado a la imagen del gestor de arranque. I U-Boot: se ejecuta desde RAM. Inicializa otros dispositivos hardware (red, USB, etc.). Carga la imagen del n´ucleodesde almacenamiento o red a RAM y lo inicia. Provee un Shell con comandos. Archivo llamado u-boot.kwb I Linux Kernel: se ejecuta desde RAM. Recupera el sistema completamente (los gestores de arranque ya no existen)

DSI - FCEIA http://dsi.fceia.unr.edu.ar 89/263 Gestores de arranque gen´ericos

I Nos centraremos en la parte gen´erica,el cargador principal, que ofrece las caracter´ısticasm´asimportantes.

I Hay varios gestores de arranque gen´ericosde c´odigoabierto. Aqu´ıest´anlos m´aspopulares:

I U-Boot, el gestor de arranque universal de Denx El m´asutilizado en ARM, tambi´ense utiliza en PPC, MIPS, x86, m68k, NIOS, etc. El est´andar de facto actual. Lo estudiaremos en detalle. http://www.denx.de/wiki/U-Boot I Barebox, un nuevo gestor de arranque con arquitectura neutra, escrito como un sucesor de U-Boot. Mejor dise˜no, mejor c´odigo,desarrollo activo, pero a´unno tiene tanto soporte de hardware como U-Boot. http://www.barebox.org I Tambi´enhay muchas otras aplicaciones de c´odigoabierto de gestores de arranque, a menudo espec´ıficosde la arquitectura

I RedBoot, Yaboot, PMON, etc.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 90/263 Gestor de arranque

El gestor de carga U-boot

DSI - FCEIA http://dsi.fceia.unr.edu.ar 91/263 U-Boot

U-Boot es un t´ıpicoproyecto de software libre

I Licencia: GPLv2 (igual que Linux)

I Disponible de forma libre en http://www.denx.de/wiki/U-Boot

I Documentaci´ondisponible en http://www.denx.de/wiki/U-Boot/Documentation

I El ´ultimoc´odigofuente de desarrollo est´adisponible en un repositorio Git: http://git.denx.de/?p=u-boot.git;a=summary

I El desarrollo y las discusiones ocurren alrededor de una lista abierta http://lists.denx.de/pipermail/u-boot/

I Desde finales de 2008, sigue un intervalo de versi´onfijo. Cada dos meses, se lanza una nueva versi´on.Las versions se llamana YYYY.MM.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 92/263 Configuraci´onde U-Boot

I Obtenga el c´odigofuente del sitio web y descomprimalo I El directorio include/configs/ contiene un archivo de configuraci´onpara cada placa soportada

I Define el tipo de CPU, los perif´ericosy su configuraci´on,el mapeo de memoria, las caracter´ısticasde U-Boot que se deben compilar, etc. I Se trata de un simple archivo .h que establece las constantes del preprocesador C. Vea el archivo README para la documentaci´onde estas constantes. Este archivo tambi´ense puede ajustar para agregar o eliminar funciones de U-Boot (comandos, etc.).

I Suponiendo que su placa ya est´asoportada por U-Boot, debe haber una entrada correspondiente a su placa en el archivo boards.cfg.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 93/263 Extracto del archivo de configuraci´onde U-Boot

/* CPU configuration */ #define CONFIG_ARMV7 1 #define CONFIG_OMAP 1 /* Available commands and features */ #define CONFIG_OMAP34XX 1 #define CONFIG_CMD_CACHE #define CONFIG_OMAP3430 1 #define CONFIG_CMD_EXT2 #define CONFIG_OMAP3_IGEP0020 1 #define CONFIG_CMD_FAT [...] #define CONFIG_CMD_I2C /* Memory configuration */ #define CONFIG_CMD_MMC #define CONFIG_NR_DRAM_BANKS 2 #define CONFIG_CMD_NAND #define PHYS_SDRAM_1 OMAP34XX_SDRC_CS0 #define CONFIG_CMD_NET #define PHYS_SDRAM_1_SIZE (32 << 20) #define CONFIG_CMD_DHCP #define PHYS_SDRAM_2 OMAP34XX_SDRC_CS1 #define CONFIG_CMD_PING [...] #define CONFIG_CMD_NFS /* USB configuration */ #define CONFIG_CMD_MTDPARTS #define CONFIG_MUSB_UDC 1 [...] #define CONFIG_USB_OMAP3 1 #define CONFIG_TWL4030_USB 1 [...]

DSI - FCEIA http://dsi.fceia.unr.edu.ar 94/263 Configuraci´ony compilaci´onde U-Boot

I U-Boot debe ser configurado antes de ser compilado

I make BOARDNAME_config I Donde BOARDNAME es el nombre de la placa, como se ve en el archivo boards.cfg (primera columna).

I Aseg´uresede que el compilador cruzado est´edisponible en PATH

I Compile U-Boot, especificando el prefijo del compilador cruzado. Por ejemplo, si el ejecutable del compilador cruzado es arm-linux-gcc: make CROSS_COMPILE=arm-linux-

I El resultado principal es un archivo u-boot.bin, que es la imagen de U-Boot. Dependiendo de su plataforma espec´ıfica, puede haber otras im´agenesespecializadas: u-boot.img, u-boot.kwb, MLO, etc.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 95/263 Instalando U-Boot

I Por lo general, U-Boot debe instalarse en la memoria flash para ser ejecutado por el hardware. Dependiendo del hardware, la instalaci´onde U-Boot se realiza de una manera diferente:

I La CPU proporciona alg´untipo de monitor de arranque espec´ıficocon el que puede comunicarse a trav´esde un puerto serie o USB mediante un protocolo espec´ıfico I La CPU arranca primero en medios extra´ıbles(MMC) antes de arrancar desde medios fijos (NAND). En este caso, arranca desde MMC para grabar una nueva version I U-Boot ya est´ainstalado y puede utilizarse para grabar una nueva versi´onde U-Boot. Sin embargo, tenga cuidado: i si la nueva versi´onde U-Boot no funciona, la tarjeta es quedar´a inutilizable I La placa proporciona una interfaz JTAG, que permite escribir la memoria flash de forma remota, sin ning´unsistema ejecutandose en la placa. Tambi´enpermite rescatar una placa si el gestor de arranque no funciona.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 96/263 Mensaje de U-boot

I Conecte el destino al anfitri´ona trav´esde la consola serie

I Encienda la placa. En la consola serie va a ver algo como:

U-Boot 2013.04 (May 29 2013 - 10:30:21)

OMAP36XX/37XX-GP ES1.2, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz IGEPv2 + LPDDR/NAND I2C: ready DRAM: 512 MiB NAND: 512 MiB MMC: OMAP SD/MMC: 0

Die ID #255000029ff800000168580212029011 Net: smc911x-0 U-Boot #

I El shell U-Boot ofrece un conjunto de comandos. Estudiaremos los m´asimportantes, consulte la documentaci´on para obtener una referencia completa o el comando help.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 97/263 Comandos de informaci´on

Informaci´onFlash (NOR y SPI flash)

U-Boot> flinfo DataFlash:AT45DB021 Nb pages: 1024 Page Size: 264 Size= 270336 bytes Logical address: 0xC0000000 Area 0: C0000000 to C0001FFF (RO) Bootstrap Area 1: C0002000 to C0003FFF Environment Area 2: C0004000 to C0041FFF (RO) U-Boot

Informaci´onflash de NAND

U-Boot> nand info Device 0: nand0, sector size 128 KiB Page size 2048 b OOB size 64 b Erase size 131072 b

Detalles de la versi´on

U-Boot> version U-Boot 2013.04 (May 29 2013 - 10:30:21)

DSI - FCEIA http://dsi.fceia.unr.edu.ar 98/263 Comandos importantes (1)

I El conjunto exacto de comandos depende de la configuraci´on de U-Boot I help and help command I boot, ejecuta el comando por defecto de inicio, almacenado en bootcmd I bootm

, inicia la imagen del kernel cargada en una direcci´onde memoria RAM dada I ext2load, carga un archivo desde el sistema de archivos ext2 a la RAM

I Y tambi´en ext2ls para ver los archivos, ext2info para informaci´on I fatload, carga un archivo desde el sistema de archivos FAT a la RAM

I Tambi´en fatls y fatinfo I tftp, carga un archivo desde la red a la RAM I ping, para probar la red

DSI - FCEIA http://dsi.fceia.unr.edu.ar 99/263 Comandos importantes (2)

I loadb, loads, loady, carga un archivo desde la linea serie en RAM I usb, para inicializar y controlar el sistema USB, principalmente utilizado para dispositivos de almacenamiento USB como ser pendrives I mmc, para inicializar y controlar el sistema MMC, utilizado por las tarjetas SD y microSD I nand, para borrar, leer y escribir contenidos a la flash NAND I erase, protect, cp, para borrar, proteger y escribir la flash NOR I md, muestra los contenidos de la memoria. Puede ser de utilidad verificar los contenidos cargados en la memoria, o mirar los registros del Hardware. I mm, modifica el contenido de la memoria. Puede ser ´utilpara modificar directamente los registros de Hardware, para propositos de prueba.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 100/263 Comandos de variables de entorno (1)

I U-Boot se puede configurar a trav´esde variables de entorno, que afectan al comportamiento de los diferentes comandos.

I Las variables de entorno se cargan de flash a RAM al inicio de U-Boot, se puede modificar y guardar de nuevo en flash para persistencia

I Hay una ubicaci´ondedicada en flash (o en el almacenamiento de MMC) para almacenar el entorno de U-Boot, definido en el archivo de configuraci´onde la tarjeta

DSI - FCEIA http://dsi.fceia.unr.edu.ar 101/263 Comandos de variables de entorno (2)

Comandos para manipular las variables de entorno:

I printenv Muestra todas las variables

I printenv Muestra el valor de una variable

I setenv Cambia el valor de una variable, solo en RAM

I editenv Modifica el valor de una variable, solo en RAM

I saveenv Guarda el estado actual del entorno en flash

DSI - FCEIA http://dsi.fceia.unr.edu.ar 102/263 Comandos de variables de entorno - Ejemplo

u-boot # printenv baudrate=19200 ethaddr=00:40:95:36:35:33 netmask=255.255.255.0 ipaddr=10.0.0.11 serverip=10.0.0.1 stdin=serial stdout=serial stderr=serial u-boot # printenv serverip serverip=10.0.0.1 u-boot # setenv serverip 10.0.0.100 u-boot # saveenv

DSI - FCEIA http://dsi.fceia.unr.edu.ar 103/263 Variables importantes del env de U-Boot

I bootcmd, contiene el comando que U-Boot ejecutar´ade forma autom´aticaal momento de iniciar despu´esde una espera configurable, si el proceso no es interrumpido I bootargs, contiene los argumentos pasados al kernel de Linux, contains the arguments passed to the Linux kernel, cubierto m´astarde I serverip, la direcci´onIP del servidor que U-Boot contactar´a para los comandos relacionados con la red I ipaddr, la direcci´onIP que U-Boot va a usar I netmask, la mascara de red para contactar al servidor I ethaddr, la direcci´onMAC, se puede asignar solo una vez I bootdelay, la espera en segundos antes de que U-Boot ejecute bootcmd I autostart, si es si, U-Boot inicia automaticamente una imagen que haya sido cargada en memoria

DSI - FCEIA http://dsi.fceia.unr.edu.ar 104/263 Scripts en variables de entorno

I Las variables de entorno pueden contener peque˜nosscripts, para ejecutar varios comandos y probar los resultados de los comandos.

I Util para automatizar el inicio o el proceso de mejora I Varios comandos pueden ser enganchados utilizando el operador ; I Las pruebas se pueden realizar haciendo if command ; then ... ; else ... ; fi I Los Scripts se ejecutan haciendo run I Se pueden referenciar otras variables haciendo ${variable-name} I Ejemplo

I setenv mmc-boot ’if fatload mmc 0 80000000 boot. ini; then source; else if fatload mmc 0 80000000 uImage; then run mmc-bootargs; bootm; fi; fi’

DSI - FCEIA http://dsi.fceia.unr.edu.ar 105/263 Transfiriendo archivos hacia el destino

I U-Boot se usa principalmente para cargar e iniciar una imagen del kernel, pero tambi´enpermite cambiar la imagen del kernel y el sistema de archivos ra´ızalmacenado en flash I Los archivos deben intercambiarse entre el destino y la estaci´onde trabajo de desarrollo. Esto es posible:

I A trav´esde la red si el destino tiene una conexi´onEthernet y U-Boot contiene un controlador para el chip Ethernet. Esta es la soluci´onm´asr´apiday eficiente. I A trav´esde una llave USB, si U-Boot soporta el controlador USB de su plataforma I A trav´esde una tarjeta SD o microSD, si U-Boot admite el controlador MMC de su plataforma I A trav´esdel puerto serie

DSI - FCEIA http://dsi.fceia.unr.edu.ar 106/263 TFTP

I La transferencia sobre la red desde la estaci´onde desarrollo y U-Boot en el destino se realiza a trav´esde TFTP

I Trivial File Transfer Protocol I Algo similar a FTP, pero sin autenticaci´onsobre UDP I Un servidor TFTP es necesario en la estaci´onde trabajo de desarrollo

I sudo apt-get install tftpd-hpa I Todos los archivos en /var/lib/tftpboot son visibles a trav´esde TFTP I Un cliente TFTP est´adisponible en el paquete tftp-hpa, para pruebas I Un cliente TFTP se encuentra integrado con U-Boot

I Configure las variables de entorno ipaddr y serverip I Utilice tftp

para cargar un archivo

DSI - FCEIA http://dsi.fceia.unr.edu.ar 107/263 mkimage de U-boot

I La imagen del n´ucleoque U-Boot carga e inicia debe estar preparado, de modo que se a˜nadeun encabezado espec´ıficode U-Boot delante de la imagen I Este encabezado proporciona detalles como el tama˜node la imagen, la direcci´onde carga esperada, el tipo de compresi´on, etc. I Esto se hace con una herramienta que viene en U-Boot, mkimage I Debian / Ubuntu: simplemente instale el paquete u-boot-tools. I O, comp´ılelousted mismo: simplemente configure U-Boot para cualquier placa de cualquier arquitectura y compile. A continuaci´on,instale mkimage: cp tools/mkimage /usr/local/bin/ I El destino especial uImage del Makefile del kernel puede luego ser utilizado para generar una imagen de kernel adecuada para U-Boot.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 108/263 Linux kernel introduction

Linux kernel DSI

Embedded Linux introduction Developers

Free Electrons

© Copyright 2004-2018, Free Electrons. Creative Commons BY-SA 3.0 license. Corrections, suggestions, contributions and translations are welcome!

DSI - FCEIA http://dsi.fceia.unr.edu.ar 109/263 Linux kernel introduction

Linux features

DSI - FCEIA http://dsi.fceia.unr.edu.ar 110/263 History

I The Linux kernel is one component of a system, which also requires libraries and applications to provide features to end users. I The Linux kernel was created as a hobby in 1991 by a Finnish student, Linus Torvalds.

I Linux quickly started to be used as the kernel for free software operating systems

I Linus Torvalds has been able to create a large and dynamic developer and user community around Linux.

I Nowadays, more than one thousand people contribute to each kernel release, individuals or companies big and small.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 111/263 Linux kernel key features

I Portability and hardware I Security. It can’t hide its support. Runs on most flaws. Its code is reviewed architectures. by many experts.

I Scalability. Can run on I Stability and reliability. super computers as well as I Modularity. Can include on tiny devices (4 MB of only what a system needs RAM is enough). even at run time. I Compliance to standards I Easy to program. You can and interoperability. learn from existing code. I Exhaustive networking Many useful resources on support. the net.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 112/263 Linux kernel in the system

DSI - FCEIA http://dsi.fceia.unr.edu.ar 113/263 Linux kernel main roles

I Manage all the hardware resources: CPU, memory, I/O.

I Provide a set of portable, architecture and hardware independent APIs to allow user space applications and libraries to use the hardware resources. I Handle concurrent accesses and usage of hardware resources from different applications.

I Example: a single network interface is used by multiple user space applications through various network connections. The kernel is responsible to “multiplex” the hardware resource.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 114/263 System calls

I The main interface between the kernel and user space is the set of system calls I About 300 system calls that provide the main kernel services

I File and device operations, networking operations, inter-process communication, process management, memory mapping, timers, threads, synchronization primitives, etc.

I This interface is stable over time: only new system calls can be added by the kernel developers

I This system call interface is wrapped by the C library, and user space applications usually never make a system call directly but rather use the corresponding C library function

DSI - FCEIA http://dsi.fceia.unr.edu.ar 115/263 Pseudo filesystems

I Linux makes system and kernel information available in user space through pseudo filesystems, sometimes also called virtual filesystems

I Pseudo filesystems allow applications to see directories and files that do not exist on any real storage: they are created and updated on the fly by the kernel I The two most important pseudo filesystems are

I proc, usually mounted on /proc: Operating system related information (processes, memory management parameters...) I sysfs, usually mounted on /sys: Representation of the system as a set of devices and buses. Information about these devices.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 116/263 Inside the Linux kernel

DSI - FCEIA http://dsi.fceia.unr.edu.ar 117/263 Linux license

I The whole Linux sources are Free Software released under the GNU General Public License version 2 (GPL v2). I For the Linux kernel, this basically implies that:

I When you receive or buy a device with Linux on it, you should receive the Linux sources, with the right to study, modify and redistribute them. I When you produce Linux based devices, you must release the sources to the recipient, with the same rights, with no restriction.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 118/263 Supported hardware architectures

I See the arch/ directory in the kernel sources

I Minimum: 32 bit processors, with or without MMU, and gcc support

I 32 bit architectures (arch/ subdirectories) Examples: arm, avr32, blackfin, c6x, m68k, microblaze, mips, score, sparc, um

I 64 bit architectures: Examples: alpha, arm64, ia64, tile

I 32/64 bit architectures Examples: powerpc, x86, sh, sparc

I Find details in kernel sources: arch//Kconfig, arch//README, or Documentation//

DSI - FCEIA http://dsi.fceia.unr.edu.ar 119/263 Linux kernel introduction

Linux versioning scheme and development process

DSI - FCEIA http://dsi.fceia.unr.edu.ar 120/263 Until 2.6 (1)

I One stable major branch every 2 or 3 years

I Identified by an even middle number I Examples: 1.0.x, 2.0.x, 2.2.x, 2.4.x I One development branch to integrate new functionalities and major changes

I Identified by an odd middle number I Examples: 2.1.x, 2.3.x, 2.5.x I After some time, a development version becomes the new base version for the stable branch

I Minor releases once in while: 2.2.23, 2.5.12, etc.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 121/263 Until 2.6 (2)

DSI - FCEIA http://dsi.fceia.unr.edu.ar 122/263 Changes since Linux 2.6

I Since 2.6.0, kernel developers have been able to introduce lots of new features one by one on a steady pace, without having to make disruptive changes to existing subsystems.

I Since then, there has been no need to create a new development branch massively breaking compatibility with the stable branch.

I Thanks to this, more features are released to users at a faster pace.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 123/263 3.x stable branch

I From 2003 to 2011, the official kernel versions were named 2.6.x.

I Linux 3.0 was released in July 2011 I This is only a change to the numbering scheme

I Official kernel versions are now named 3.x (3.0, 3.1, 3.2, etc.) I Stabilized versions are named 3.x.y (3.0.2, 3.4.3, etc.) I It effectively only removes a digit compared to the previous numbering scheme

DSI - FCEIA http://dsi.fceia.unr.edu.ar 124/263 New development model

Using merge and bug fixing windows

DSI - FCEIA http://dsi.fceia.unr.edu.ar 125/263 New development model - Details

I After the release of a 3.x version (for example), a two-weeks merge window opens, during which major additions are merged.

I The merge window is closed by the release of test version 3.(x+1)-rc1

I The bug fixing period opens, for 6 to 10 weeks.

I At regular intervals during the bug fixing period, 3.(x+1)-rcY test versions are released.

I When considered sufficiently stable, kernel 3.(x+1) is released, and the process starts again.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 126/263 More stability for the kernel source tree

I Issue: bug and security fixes only released for most recent stable kernel versions.

I Some people need to have a recent kernel, but with long term support for security updates.

I You could get long term support from a commercial embedded Linux provider.

I You could reuse sources for the kernel used in Ubuntu Long Term Support releases (5 years of free security updates).

I The http://kernel.org front page shows which versions will be supported for some time (up to 2 or 3 years), and which ones won’t be supported any more (”EOL: End Of Life”)

DSI - FCEIA http://dsi.fceia.unr.edu.ar 127/263 What’s new in each Linux release?

I The official list of changes for each Linux release is just a huge list of individual patches! commit aa6e52a35d388e730f4df0ec2ec48294590cc459 Author: Thomas Petazzoni Date: Wed Jul 13 11:29:17 2011 +0200

at91: at91-ohci: support overcurrent notification Several USB power switches (AIC1526 or MIC2026) have a digital output that is used to notify that an overcurrent situation is taking place. This digital outputs are typically connected to GPIO inputs of the processor and can be used to be notified of these overcurrent situations.

Therefore, we add a new overcurrent_pin[] array in the at91_usbh_data structure so that boards can tell the AT91 OHCI driver which pins are used for the overcurrent notification, and an overcurrent_supported boolean to tell the driver whether overcurrent is supported or not.

The code has been largely borrowed from ohci-da8xx.c and ohci-s3c2410.c.

Signed-off-by: Thomas Petazzoni Signed-off-by: Nicolas Ferre

I Very difficult to find out the key changes and to get the global picture out of individual changes.

I Fortunately, there are some useful resources available

I http://wiki.kernelnewbies.org/LinuxChanges I http://lwn.net I http://linuxfr.org, for French readers

DSI - FCEIA http://dsi.fceia.unr.edu.ar 128/263 Linux kernel introduction

Linux kernel sources

DSI - FCEIA http://dsi.fceia.unr.edu.ar 129/263 Location of kernel sources

I The official versions of the Linux kernel, as released by Linus Torvalds, are available at http://www.kernel.org

I These versions follow the development model of the kernel I However, they may not contain the latest development from a specific area yet. Some features in development might not be ready for mainline inclusion yet. I Many chip vendors supply their own kernel sources

I Focusing on hardware support first I Can have a very important delta with mainline Linux I Useful only when mainline hasn’t caught up yet. I Many kernel sub-communities maintain their own kernel, with usually newer but less stable features

I Architecture communities (ARM, MIPS, PowerPC, etc.), device drivers communities (I2C, SPI, USB, PCI, network, etc.), other communities (real-time, etc.) I No official releases, only development trees are available.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 130/263 Getting Linux sources

I The kernel sources are available from http://kernel.org/pub/linux/kernel as full tarballs (complete kernel sources) and patches (differences between two kernel versions). I However, more and more people use the git version control system. Absolutely needed for kernel development!

I Fetch the entire kernel sources and history git clone git://git.kernel.org/pub/scm/linux/ kernel/git/torvalds/linux.git I Create a branch that starts at a specific stable version git checkout -b v3.11 I Web interface available at http://git.kernel.org/cgit/ linux/kernel/git/torvalds/linux.git/tree/. I Read more about Git at http://git-scm.com/

DSI - FCEIA http://dsi.fceia.unr.edu.ar 131/263 Linux kernel size (1)

I Linux 3.10 sources: Raw size: 573 MB (43,000 files, approx 15,800,000 lines) gzip compressed tar archive: 105 MB bzip2 compressed tar archive: 83 MB (better) xz compressed tar archive: 69 MB (best)

I Minimum Linux 3.17 compiled kernel size, booting on the ARM Versatile board (hard drive on PCI, ext2 filesystem, ELF executable support, framebuffer console and input devices): 876 KB (compressed), 2.3 MB (raw)

I Why are these sources so big? Because they include thousands of device drivers, many network protocols, support many architectures and filesystems...

I The Linux core (scheduler, memory management...) is pretty small!

DSI - FCEIA http://dsi.fceia.unr.edu.ar 132/263 Linux kernel size (2)

As of kernel version 3.10.

I drivers/: 49.4% I tools/: 0.9% I arch/: 21.9% I scripts/: 0.5% I fs/: 6.0% I mm/: 0.5% I include/: 4.7% I crypto/: 0.4% I sound/: 4.4% I security/: 0.4% I Documentation/: 4.0% I lib/: 0.4% I net/: 3.9% I block/: 0.2% I firmware/: 1.0% I ... I kernel/: 1.0%

DSI - FCEIA http://dsi.fceia.unr.edu.ar 133/263 Getting Linux sources

I Full tarballs I Contain the complete kernel sources: long to download and uncompress, but must be done at least once I Example: http://www.kernel.org/pub/linux/kernel/v3.x/linux- 3.10.9.tar.xz

I Extract command: tar xf linux-3.10.9.tar.xz I Incremental patches between versions I It assumes you already have a base version and you apply the correct patches in the right order. Quick to download and apply I Examples: http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.10.xz (3.9 to 3.10) http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.10.9.xz (3.10 to 3.10.9) I All previous kernel versions are available in http://kernel.org/pub/linux/kernel/ DSI - FCEIA http://dsi.fceia.unr.edu.ar 134/263 Patch

I A patch is the difference between two source trees

I Computed with the diff tool, or with more elaborate version control systems

I They are very common in the open-source community

I Excerpt from a patch:

diff -Nru a/Makefile b/Makefile --- a/Makefile 2005-03-04 09:27:15 -08:00 +++ b/Makefile 2005-03-04 09:27:15 -08:00 @@ -1,7 +1,7 @@ VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 11 -EXTRAVERSION = +EXTRAVERSION = .1 NAME=Woozy Numbat

# *DOCUMENTATION*

DSI - FCEIA http://dsi.fceia.unr.edu.ar 135/263 Contents of a patch

I One section per modified file, starting with a header diff -Nru a/Makefile b/Makefile --- a/Makefile 2005-03-04 09:27:15 -08:00 +++ b/Makefile 2005-03-04 09:27:15 -08:00 I One sub-section per modified part of the file, starting with header with the affected line numbers @@ -1,7 +1,7 @@ I Three lines of context before the change VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 11 I The change itself -EXTRAVERSION = +EXTRAVERSION = .1 I Three lines of context after the change NAME=Woozy Numbat

# *DOCUMENTATION*

DSI - FCEIA http://dsi.fceia.unr.edu.ar 136/263 Using the patch command

The patch command:

I Takes the patch contents on its standard input

I Applies the modifications described by the patch into the current directory patch usage examples:

I patch -p < diff_file

I cat diff_file | patch -p

I xzcat diff_file.xz | patch -p

I bzcat diff_file.bz2 | patch -p

I zcat diff_file.gz | patch -p I Notes:

I n: number of directory levels to skip in the file paths I You can reverse apply a patch with the -R option I You can test a patch with --dry-run option

DSI - FCEIA http://dsi.fceia.unr.edu.ar 137/263 Applying a Linux patch

I Two types of Linux patches:

I Either to be applied to the previous stable version (from 3. to 3.x) I Or implementing fixes to the current stable version (from 3.x to 3.x.y) I Can be downloaded in gzip, bzip2 or xz (much smaller) compressed files. I Always produced for n=1 (that’s what everybody does... do it too!) I Need to run the patch command inside the kernel source directory I Linux patch command line example: cd linux-3.9 xzcat ../patch-3.10.xz | patch -p1 xzcat ../patch-3.10.9.xz | patch -p1 cd ..; mv linux-3.9 linux-3.10.9

DSI - FCEIA http://dsi.fceia.unr.edu.ar 138/263 Linux kernel introduction

Kernel configuration

DSI - FCEIA http://dsi.fceia.unr.edu.ar 139/263 Kernel configuration and build system

I The kernel configuration and build system is based on multiple Makefiles

I One only interacts with the main Makefile, present at the top directory of the kernel source tree I Interaction takes place

I using the make tool, which parses the Makefile I through various targets, defining which action should be done (configuration, compilation, installation, etc.). Run make help to see all available targets. I Example

I cd linux-3.6.x/ I make

DSI - FCEIA http://dsi.fceia.unr.edu.ar 140/263 Kernel configuration (1)

I The kernel contains thousands of device drivers, filesystem drivers, network protocols and other configurable items

I Thousands of options are available, that are used to selectively compile parts of the kernel source code

I The kernel configuration is the process of defining the set of options with which you want your kernel to be compiled I The set of options depends

I On your hardware (for device drivers, etc.) I On the capabilities you would like to give to your kernel (network capabilities, filesystems, real-time, etc.)

DSI - FCEIA http://dsi.fceia.unr.edu.ar 141/263 Kernel configuration (2)

I The configuration is stored in the .config file at the root of kernel sources

I Simple text file, key=value style I As options have dependencies, typically never edited by hand, but through graphical or text interfaces:

I make xconfig, make gconfig (graphical) I make menuconfig, make nconfig (text) I You can switch from one to another, they all load/save the same .config file, and show the same set of options

I To modify a kernel in a GNU/Linux distribution: the configuration files are usually released in /boot/, together with kernel images: /boot/config-3.2.0-31-generic

DSI - FCEIA http://dsi.fceia.unr.edu.ar 142/263 Kernel or module?

I The kernel image is a single file, resulting from the linking of all object files that correspond to features enabled in the configuration

I This is the file that gets loaded in memory by the bootloader I All included features are therefore available as soon as the kernel starts, at a time where no filesystem exists I Some features (device drivers, filesystems, etc.) can however be compiled as modules

I These are plugins that can be loaded/unloaded dynamically to add/remove features to the kernel I Each module is stored as a separate file in the filesystem, and therefore access to a filesystem is mandatory to use modules I This is not possible in the early boot procedure of the kernel, because no filesystem is available

DSI - FCEIA http://dsi.fceia.unr.edu.ar 143/263 Kernel option types

I There are different types of options I bool options, they are either

I true (to include the feature in the kernel) or I false (to exclude the feature from the kernel)

I tristate options, they are either

I true (to include the feature in the kernel image) or I module (to include the feature as a kernel module) or I false (to exclude the feature)

I int options, to specify integer values I hex options, to specify hexadecimal values I string options, to specify string values

DSI - FCEIA http://dsi.fceia.unr.edu.ar 144/263 Kernel option dependencies

I There are dependencies between kernel options

I For example, enabling a network driver requires the network stack to be enabled I Two types of dependencies

I depends on dependencies. In this case, option A that depends on option B is not visible until option B is enabled I select dependencies. In this case, with option A depending on option B, when option A is enabled, option B is automatically enabled I make xconfig allows to see all options, even the ones that cannot be selected because of missing dependencies. In this case, they are displayed in gray

DSI - FCEIA http://dsi.fceia.unr.edu.ar 145/263 make xconfig

make xconfig

I The most common graphical interface to configure the kernel.

I Make sure you read help -> introduction: useful options!

I File browser: easier to load configuration files

I Search interface to look for parameters

I Required Debian / Ubuntu packages: libqt4-dev g++ (libqt3-mt-dev for older kernel releases)

DSI - FCEIA http://dsi.fceia.unr.edu.ar 146/263 make xconfig screenshot

DSI - FCEIA http://dsi.fceia.unr.edu.ar 147/263 make xconfig search interface

Looks for a keyword in the parameter name. Allows to select or unselect found parameters.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 148/263 Kernel configuration options

DSI - FCEIA http://dsi.fceia.unr.edu.ar 149/263 Corresponding .config file excerpt

Options are grouped by sections and are prefixed with CONFIG_. # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=m CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_UDF_FS=y CONFIG_UDF_NLS=y

# # DOS/FAT/NT Filesystems # # CONFIG_MSDOS_FS is not set # CONFIG_VFAT_FS is not set CONFIG_NTFS_FS=m # CONFIG_NTFS_DEBUG is not set CONFIG_NTFS_RW=y

DSI - FCEIA http://dsi.fceia.unr.edu.ar 150/263 make gconfig

make gconfig

I GTK based graphical configuration interface. Functionality similar to that of make xconfig.

I Just lacking a search functionality.

I Required Debian packages: libglade2-dev

DSI - FCEIA http://dsi.fceia.unr.edu.ar 151/263 make menuconfig

make menuconfig

I Useful when no graphics are available. Pretty convenient too!

I Same interface found in other tools: BusyBox, Buildroot...

I Required Debian packages: libncurses-dev

DSI - FCEIA http://dsi.fceia.unr.edu.ar 152/263 make nconfig

make nconfig

I A newer, similar text interface

I More user friendly (for example, easier to access help information).

I Required Debian packages: libncurses-dev

DSI - FCEIA http://dsi.fceia.unr.edu.ar 153/263 make oldconfig

make oldconfig

I Needed very often!

I Useful to upgrade a .config file from an earlier kernel release

I Issues warnings for configuration parameters that no longer exist in the new kernel.

I Asks for values for new parameters If you edit a .config file by hand, it’s strongly recommended to run make oldconfig afterwards!

DSI - FCEIA http://dsi.fceia.unr.edu.ar 154/263 Undoing configuration changes

A frequent problem:

I After changing several kernel configuration settings, your kernel no longer works.

I If you don’t remember all the changes you made, you can get back to your previous configuration: $ cp .config.old .config

I All the configuration interfaces of the kernel (xconfig, menuconfig, oldconfig...) keep this .config.old backup copy.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 155/263 Configuration per architecture

I The set of configuration options is architecture dependent

I Some configuration options are very architecture-specific I Most of the configuration options (global kernel options, network subsystem, filesystems, most of the device drivers) are visible in all architectures.

I By default, the kernel build system assumes that the kernel is being built for the host architecture, i.e. native compilation

I The architecture is not defined inside the configuration, but at a higher level

I We will see later how to override this behaviour, to allow the configuration of kernels for a different architecture

DSI - FCEIA http://dsi.fceia.unr.edu.ar 156/263 Linux kernel introduction

Compiling and installing the kernel for the host system

DSI - FCEIA http://dsi.fceia.unr.edu.ar 157/263 Compilaci´ondel n´ucleo

I make

I en el directorio fuente principal de n´ucleo I Recuerde ejecutar multiples trabajos en paralelo si es que posee multiples n´ucleos.Ejemplo: make -j 4 I No es necesario ser administrador! I Esto genera

I vmlinux, the raw uncompressed kernel image, in the ELF format, useful for debugging purposes, but cannot be booted I arch//boot/*Image, the final, usually compressed, kernel image that can be booted

I bzImage for x86, zImage for ARM, vmImage.gz for Blackfin, etc.

I arch//boot/dts/*.dtb, compiled Device Tree files (on some architectures) I All kernel modules, spread over the kernel source tree, as .ko files.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 158/263 Kernel installation

I make install

I Does the installation for the host system by default, so needs to be run as root. Generally not used when compiling for an embedded system, as it installs files on the development workstation. I Installs

I /boot/vmlinuz- Compressed kernel image. Same as the one in arch//boot I /boot/System.map- Stores kernel symbol addresses I /boot/config- Kernel configuration for this version

I Typically re-runs the bootloader configuration utility to take the new kernel into account.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 159/263 Module installation

I make modules_install

I Does the installation for the host system by default, so needs to be run as root I Installs all modules in /lib/modules//

I kernel/ Module .ko (Kernel Object) files, in the same directory structure as in the sources. I modules.alias Module aliases for module loading utilities. Example line: alias sound-service-?-0 snd_mixer_oss I modules.dep Module dependencies I modules.symbols Tells which module a given symbol belongs to.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 160/263 Kernel cleanup targets

I Clean-up generated files (to force re-compilation): make clean

I Remove all generated files. Needed when switching from one architecture to another. Caution: it also removes your .config file! make mrproper

I Also remove editor backup and patch reject files (mainly to generate patches): make distclean

DSI - FCEIA http://dsi.fceia.unr.edu.ar 161/263 Linux kernel introduction

Cross-compiling the kernel

DSI - FCEIA http://dsi.fceia.unr.edu.ar 162/263 Cross-compiling the kernel

When you compile a Linux kernel for another CPU architecture

I Much faster than compiling natively, when the target system is much slower than your GNU/Linux workstation.

I Much easier as development tools for your GNU/Linux workstation are much easier to find.

I To make the difference with a native compiler, cross-compiler executables are prefixed by the name of the target system, architecture and sometimes library. Examples: mips-linux-gcc, the prefix is mips-linux- arm-linux-gnueabi-gcc, the prefix is arm-linux-gnueabi-

DSI - FCEIA http://dsi.fceia.unr.edu.ar 163/263 Specifying cross-compilation (1)

The CPU architecture and cross-compiler prefix are defined through the ARCH and CROSS_COMPILE variables in the toplevel Makefile.

I ARCH is the name of the architecture. It is defined by the name of the subdirectory in arch/ in the kernel sources

I Example: arm if you want to compile a kernel for the arm architecture. I CROSS_COMPILE is the prefix of the cross compilation tools

I Example: arm-linux- if your compiler is arm-linux-gcc

DSI - FCEIA http://dsi.fceia.unr.edu.ar 164/263 Specifying cross-compilation (2)

Two solutions to define ARCH and CROSS_COMPILE:

I Pass ARCH and CROSS_COMPILE on the make command line: make ARCH=arm CROSS_COMPILE=arm-linux- ... Drawback: it is easy to forget to pass these variables when you run any make command, causing your build and configuration to be screwed up.

I Define ARCH and CROSS_COMPILE as environment variables: export ARCH=arm export CROSS_COMPILE=arm-linux- Drawback: it only works inside the current shell or terminal. You could put these settings in a file that you source every time you start working on the project. If you only work on a single architecture with always the same toolchain, you could even put these settings in your ~/.bashrc file to make them permanent and visible from any terminal.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 165/263 Predefined configuration files

I Default configuration files available, per board or per-CPU family

I They are stored in arch//configs/, and are just minimal .config files I This is the most common way of configuring a kernel for embedded platforms

I Run make help to find if one is available for your platform

I To load a default configuration file, just run make acme_defconfig

I This will overwrite your existing .config file! I To create your own default configuration file

I make savedefconfig, to create a minimal configuration file I mv defconfig arch//configs/myown_defconfig

DSI - FCEIA http://dsi.fceia.unr.edu.ar 166/263 Configuring the kernel

I After loading a default configuration file, you can adjust the configuration to your needs with the normal xconfig, gconfig or menuconfig interfaces

I You can also start the configuration from scratch without loading a default configuration file I As the architecture is different from your host architecture

I Some options will be different from the native configuration (processor and architecture specific options, specific drivers, etc.) I Many options will be identical (filesystems, network protocols, architecture-independent drivers, etc.)

I Make sure you have the support for the right CPU, the right board and the right device drivers.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 167/263 Device Tree

I Many embedded architectures have a lot of non-discoverable hardware.

I Depending on the architecture, such hardware is either described using C code directly within the kernel, or using a special hardware description language in a Device Tree.

I ARM, PowerPC, OpenRISC, ARC, Microblaze are examples of architectures using the Device Tree. I A Device Tree Source, written by kernel developers, is compiled into a binary Device Tree Blob, passed at boot time to the kernel.

I There is one different Device Tree for each board/platform supported by the kernel, available in arch/arm/boot/dts/.dtb.

I The bootloader must load both the kernel image and the Device Tree Blob in memory before starting the kernel.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 168/263 Customize your board device tree!

Often needed for embedded board users:

I To describe external devices attached to non-discoverable busses (such as I2C) and configure them.

I To configure pin muxing: choosing what SoC signals are made available on the board external connectors.

I To configure some system parameters: flash partitions, kernel command line (other ways exist)

I Useful reference: Device Tree for Dummies, Thomas Petazzoni (Apr. 2014): http://j.mp/1jQU6NR

DSI - FCEIA http://dsi.fceia.unr.edu.ar 169/263 Building and installing the kernel

I Run make I Copy the final kernel image to the target storage

I can be uImage, zImage, vmlinux, bzImage in arch//boot I copying the Device Tree Blob might be necessary as well, they are available in arch//boot/dts I make install is rarely used in embedded development, as the kernel image is a single file, easy to handle

I It is however possible to customize the make install behaviour in arch//boot/install.sh I make modules_install is used even in embedded development, as it installs many modules and description files

I make INSTALL_MOD_PATH=

/ modules_install I The INSTALL_MOD_PATH variable is needed to install the modules in the target root filesystem instead of your host root filesystem.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 170/263 Booting with U-Boot

I Recent versions of U-Boot can boot the zImage binary. I Older versions require a special kernel image format: uImage

I uImage is generated from zImage using the mkimage tool. It is done automatically by the kernel make uImage target. I On some ARM platforms, make uImage requires passing a LOADADDR environment variable, which indicates at which physical memory address the kernel will be executed.

I In addition to the kernel image, U-Boot can also pass a Device Tree Blob to the kernel. I The typical boot process is therefore: 1. Load zImage or uImage at address X in memory 2. Load .dtb at address Y in memory 3. Start the kernel with bootz X - Y (zImage case), or bootm X - Y (uImage case) The - in the middle indicates no initramfs

DSI - FCEIA http://dsi.fceia.unr.edu.ar 171/263 Kernel command line

I In addition to the compile time configuration, the kernel behaviour can be adjusted with no recompilation using the kernel command line I The kernel command line is a string that defines various arguments to the kernel

I It is very important for system configuration I root= for the root filesystem (covered later) I console= for the destination of kernel messages I Many more exist. The most important ones are documented in admin-guide/kernel-parameters in kernel documentation. I This kernel command line is either

I Passed by the bootloader. In U-Boot, the contents of the bootargs environment variable is automatically passed to the kernel I Specified in the Device Tree (for architectures which use it) I Built into the kernel, using the CONFIG_CMDLINE option.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 172/263 Linux kernel introduction

Using kernel modules

DSI - FCEIA http://dsi.fceia.unr.edu.ar 173/263 Advantages of modules

I Modules make it easy to develop drivers without rebooting: load, test, unload, rebuild, load...

I Useful to keep the kernel image size to the minimum (essential in GNU/Linux distributions for PCs).

I Also useful to reduce boot time: you don’t spend time initializing devices and kernel features that you only need later.

I Caution: once loaded, have full control and privileges in the system. No particular protection. That’s why only the root user can load and unload modules.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 174/263 Module dependencies

I Some kernel modules can depend on other modules, which need to be loaded first.

I Example: the usb-storage module depends on the scsi_mod, libusual and usbcore modules.

I Dependencies are described in /lib/modules//modules.dep This file is generated when you run make modules_install.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 175/263 Kernel log

When a new module is loaded, related information is available in the kernel log.

I The kernel keeps its messages in a circular buffer (so that it doesn’t consume more memory with many messages)

I Kernel log messages are available through the dmesg command (diagnostic message)

I Kernel log messages are also displayed in the system console (console messages can be filtered by level using the loglevel kernel parameter, or completely disabled with the quiet parameter).

I Note that you can write to the kernel log from user space too: echo "Debug info" > /dev/kmsg

DSI - FCEIA http://dsi.fceia.unr.edu.ar 176/263 Module utilities (1)

I modinfo modinfo .ko Gets information about a module: parameters, license, description and dependencies. Very useful before deciding to load a module or not.

I sudo insmod .ko Tries to load the given module. The full path to the module object file must be given.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 177/263 Understanding module loading issues

I When loading a module fails, insmod often doesn’t give you enough details!

I Details are often available in the kernel log.

I Example: $ sudo insmod ./intr_monitor.ko insmod: error inserting './intr_monitor.ko': -1 Device or resource busy $ dmesg [17549774.552000] Failed to register handler for irq channel 2

DSI - FCEIA http://dsi.fceia.unr.edu.ar 178/263 Module utilities (2)

I sudo modprobe Most common usage of modprobe: tries to load all the modules the given module depends on, and then this module. Lots of other options are available. modprobe automatically looks in /lib/modules// for the object file corresponding to the given module name.

I lsmod Displays the list of loaded modules Compare its output with the contents of /proc/modules!

DSI - FCEIA http://dsi.fceia.unr.edu.ar 179/263 Module utilities (3)

I sudo rmmod Tries to remove the given module. Will only be allowed if the module is no longer in use (for example, no more processes opening a device file)

I sudo modprobe -r Tries to remove the given module and all dependent modules (which are no longer needed after removing the module)

DSI - FCEIA http://dsi.fceia.unr.edu.ar 180/263 Passing parameters to modules

I Find available parameters: modinfo snd-intel8x0m

I Through insmod: sudo insmod ./snd-intel8x0m.ko index=-2

I Through modprobe: Set parameters in /etc/modprobe.conf or in any file in /etc/modprobe.d/: options snd-intel8x0m index=-2

I Through the kernel command line, when the driver is built statically into the kernel: snd-intel8x0m.index=-2

I snd-intel8x0m is the driver name I index is the driver parameter name I -2 is the driver parameter value

DSI - FCEIA http://dsi.fceia.unr.edu.ar 181/263 Check module parameter values

How to find the current values for the parameters of a loaded module?

I Check /sys/module//parameters.

I There is one file per parameter, containing the parameter value.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 182/263 Useful reading

Linux Kernel in a Nutshell, Dec 2006

I By Greg Kroah-Hartman, O’Reilly http://www.kroah.com/lkn/

I A good reference book and guide on configuring, compiling and managing the Linux kernel sources.

I Freely available on-line! Great companion to the printed book for easy electronic searches! Available as single PDF file on http://free-electrons.com/ community/kernel/lkn/

I Our rating: 2 stars

DSI - FCEIA http://dsi.fceia.unr.edu.ar 183/263 Linux kernel introduction

Device Tree

DSI - FCEIA http://dsi.fceia.unr.edu.ar 184/263 Vision general

Es una estructura de datos para describir al Hardware Se pasa al Kernel en el momento de inicio Es una alternativa a los detalles de la plataforma hardcodeadas

I An example of this would be to describe how the UART interfaces with the system, which pins, how they should be muxed, the device to enable, and which driver to use.

I The original BeagleBone didn’t use the DT, but the recently released BeagleBone Black was released with the DT and is now using the 3.8 Linux Kernel.

I The following pages will attempt to break down the concepts, and give examples on howi and why you’d want to use the device tree in your every day development and hacking.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 185/263 Model del Device Tree

I Arbol de nodos y propiedades

I Los nodos dan estructura I Las propiedades agregan detalle

I Pares clave-valor I propiedad ’compatible’

I Cada valor ’compatible’ asociado con un ’binding’ I ’phandles’

I secondary connections between nodes I irqs, gpios, mdio, i2s, etc

DSI - FCEIA http://dsi.fceia.unr.edu.ar 186/263 Device Tree Background

The CPU architecture and cross-compiler prefix are defined through the ARCH and CROSS_COMPILE variables in the toplevel Makefile.

I ARCH is the name of the architecture. It is defined by the name of the subdirectory in arch/ in the kernel sources

I Example: arm if you want to compile a kernel for the arm architecture. I CROSS_COMPILE is the prefix of the cross compilation tools

I Example: arm-linux- if your compiler is arm-linux-gcc

DSI - FCEIA http://dsi.fceia.unr.edu.ar 187/263 Using an Intent to make a photo 3/4

/{ node1 { a-string-property = "A string"; a-string-list-property = "first string", "second string"; a-byte-data-property = [0x01 0x23 0x34 0x56]; child-node1 { first-child-property; second-child-property = <1>; a-string-property = "Hello, world"; }; child-node2 { }; }; node2 { an-empty-property; a-cell-property = <1234>; /* each number (cell) is a uint32 */ child-node1 { }; }; };

DSI - FCEIA http://dsi.fceia.unr.edu.ar 188/263 Device Tree Overlays

Two solutions to define ARCH and CROSS_COMPILE:

I Pass ARCH and CROSS_COMPILE on the make command line: make ARCH=arm CROSS_COMPILE=arm-linux- ... Drawback: it is easy to forget to pass these variables when you run any make command, causing your build and configuration to be screwed up.

I Define ARCH and CROSS_COMPILE as environment variables: export ARCH=arm export CROSS_COMPILE=arm-linux- Drawback: it only works inside the current shell or terminal. You could put these settings in a file that you source every time you start working on the project. If you only work on a single architecture with always the same toolchain, you could even put these settings in your ~/.bashrc file to make them permanent and visible from any terminal.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 189/263 Using an Intent to make a photo 3/4

/* * Copyright (C) 2013 CircuitCo * * Virtual cape for UART1 on connector pins P9.24 P9.26 * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. */ /dts-v1/; /plugin/;

/{ compatible = "ti,beaglebone", "ti,beaglebone-black";

/* identification */ part-number = "BB-UART1"; version = "00A0";

/* state the resources this cape uses */ exclusive-use = /* the pin header uses */ "P9.24", /* uart1_txd */ "P9.26", /* uart1_rxd */ /* the hardware ip uses */ "uart1";

DSI - FCEIA http://dsi.fceia.unr.edu.ar 190/263 Using an Intent to make a photo 3/4

fragment@0{ target = <&am33xx_pinmux>; __overlay__ { bb_uart1_pins: pinmux_bb_uart1_pins { pinctrl-single,pins = < 0x184 0x20 /* P9.24 uart1_txd.uart1_txd MODE0 OUTPUT (TX) */ 0x180 0x20 /* P9.26 uart1_rxd.uart1_rxd MODE0 INPUT (RX) */ >; }; }; };

fragment@1{ target = <&uart2>; /* really uart1 */ __overlay__ { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&bb_uart1_pins>; }; }; };

DSI - FCEIA http://dsi.fceia.unr.edu.ar 191/263 Predefined configuration files

I Default configuration files available, per board or per-CPU family

I They are stored in arch//configs/, and are just minimal .config files I This is the most common way of configuring a kernel for embedded platforms

I Run make help to find if one is available for your platform

I To load a default configuration file, just run make acme_defconfig

I This will overwrite your existing .config file! I To create your own default configuration file

I make savedefconfig, to create a minimal configuration file I mv defconfig arch//configs/myown_defconfig

DSI - FCEIA http://dsi.fceia.unr.edu.ar 192/263 Configuring the kernel

I After loading a default configuration file, you can adjust the configuration to your needs with the normal xconfig, gconfig or menuconfig interfaces

I You can also start the configuration from scratch without loading a default configuration file I As the architecture is different from your host architecture

I Some options will be different from the native configuration (processor and architecture specific options, specific drivers, etc.) I Many options will be identical (filesystems, network protocols, architecture-independent drivers, etc.)

I Make sure you have the support for the right CPU, the right board and the right device drivers.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 193/263 Device Tree

I Many embedded architectures have a lot of non-discoverable hardware.

I Depending on the architecture, such hardware is either described using C code directly within the kernel, or using a special hardware description language in a Device Tree.

I ARM, PowerPC, OpenRISC, ARC, Microblaze are examples of architectures using the Device Tree. I A Device Tree Source, written by kernel developers, is compiled into a binary Device Tree Blob, passed at boot time to the kernel.

I There is one different Device Tree for each board/platform supported by the kernel, available in arch/arm/boot/dts/.dtb.

I The bootloader must load both the kernel image and the Device Tree Blob in memory before starting the kernel.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 194/263 Customize your board device tree!

Often needed for embedded board users:

I To describe external devices attached to non-discoverable busses (such as I2C) and configure them.

I To configure pin muxing: choosing what SoC signals are made available on the board external connectors.

I To configure some system parameters: flash partitions, kernel command line (other ways exist)

I Useful reference: Device Tree for Dummies, Thomas Petazzoni (Apr. 2014): http://j.mp/1jQU6NR

DSI - FCEIA http://dsi.fceia.unr.edu.ar 195/263 Building and installing the kernel

I Run make I Copy the final kernel image to the target storage

I can be uImage, zImage, vmlinux, bzImage in arch//boot I copying the Device Tree Blob might be necessary as well, they are available in arch//boot/dts I make install is rarely used in embedded development, as the kernel image is a single file, easy to handle

I It is however possible to customize the make install behaviour in arch//boot/install.sh I make modules_install is used even in embedded development, as it installs many modules and description files

I make INSTALL_MOD_PATH=

/ modules_install I The INSTALL_MOD_PATH variable is needed to install the modules in the target root filesystem instead of your host root filesystem.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 196/263 Booting with U-Boot

I Recent versions of U-Boot can boot the zImage binary. I Older versions require a special kernel image format: uImage

I uImage is generated from zImage using the mkimage tool. It is done automatically by the kernel make uImage target. I On some ARM platforms, make uImage requires passing a LOADADDR environment variable, which indicates at which physical memory address the kernel will be executed.

I In addition to the kernel image, U-Boot can also pass a Device Tree Blob to the kernel. I The typical boot process is therefore: 1. Load zImage or uImage at address X in memory 2. Load .dtb at address Y in memory 3. Start the kernel with bootz X - Y (zImage case), or bootm X - Y (uImage case) The - in the middle indicates no initramfs

DSI - FCEIA http://dsi.fceia.unr.edu.ar 197/263 Kernel command line

I In addition to the compile time configuration, the kernel behaviour can be adjusted with no recompilation using the kernel command line I The kernel command line is a string that defines various arguments to the kernel

I It is very important for system configuration I root= for the root filesystem (covered later) I console= for the destination of kernel messages I Many more exist. The most important ones are documented in admin-guide/kernel-parameters in kernel documentation. I This kernel command line is either

I Passed by the bootloader. In U-Boot, the contents of the bootargs environment variable is automatically passed to the kernel I Specified in the Device Tree (for architectures which use it) I Built into the kernel, using the CONFIG_CMDLINE option.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 198/263 Linux Root Filesystem

Linux Root DSI

Embedded Linux Filesystem Developers

Free Electrons

© Copyright 2004-2018, Free Electrons. Creative Commons BY-SA 3.0 license. Corrections, suggestions, contributions and translations are welcome!

DSI - FCEIA http://dsi.fceia.unr.edu.ar 199/263 Linux Root Filesystem

Principle and solutions

DSI - FCEIA http://dsi.fceia.unr.edu.ar 200/263 Filesystems

I Filesystems are used to organize data in directories and files on storage devices or on the network. The directories and files are organized as a hierarchy

I In Unix systems, applications and users see a single global hierarchy of files and directories, which can be composed of several filesystems. I Filesystems are mounted in a specific location in this hierarchy of directories

I When a filesystem is mounted in a directory (called mount point), the contents of this directory reflects the contents of the storage device I When the filesystem is unmounted, the mount point is empty again.

I This allows applications to access files and directories easily, regardless of their exact storage location

DSI - FCEIA http://dsi.fceia.unr.edu.ar 201/263 Filesystems (2)

I Create a mount point, which is just a directory $ mkdir /mnt/usbkey

I It is empty $ ls /mnt/usbkey $

I Mount a storage device in this mount point $ mount -t vfat /dev/sda1 /mnt/usbkey $

I You can access the contents of the USB key $ ls /mnt/usbkey docs prog.c picture.png movie.avi $

DSI - FCEIA http://dsi.fceia.unr.edu.ar 202/263 mount / umount

I mount allows to mount filesystems

I mount -t type device mountpoint I type is the type of filesystem I device is the storage device, or network location to mount I mountpoint is the directory where files of the storage device or network location will be accessible I mount with no arguments shows the currently mounted filesystems I umount allows to unmount filesystems

I This is needed before rebooting, or before unplugging a USB key, because the Linux kernel caches writes in memory to increase performance. umount makes sure that these writes are committed to the storage.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 203/263 Root filesystem

I A particular filesystem is mounted at the root of the hierarchy, identified by /

I This filesystem is called the root filesystem I As mount and umount are programs, they are files inside a filesystem.

I They are not accessible before mounting at least one filesystem.

I As the root filesystem is the first mounted filesystem, it cannot be mounted with the normal mount command

I It is mounted directly by the kernel, according to the root= kernel option

I When no root filesystem is available, the kernel panics Please append a correct "root=" boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown block(0,0)

DSI - FCEIA http://dsi.fceia.unr.edu.ar 204/263 Location of the root filesystem

I It can be mounted from different locations

I From the partition of a hard disk I From the partition of a USB key I From the partition of an SD card I From the partition of a NAND flash chip or similar type of storage device I From the network, using the NFS protocol I From memory, using a pre-loaded filesystem (by the bootloader) I etc.

I It is up to the system designer to choose the configuration for the system, and configure the kernel behaviour with root=

DSI - FCEIA http://dsi.fceia.unr.edu.ar 205/263 Mounting rootfs from storage devices

I Partitions of a hard disk or USB key

I root=/dev/sdXY, where X is a letter indicating the device, and Y a number indicating the partition I /dev/sdb2 is the second partition of the second disk drive (either USB key or ATA hard drive) I Partitions of an SD card

I root=/dev/mmcblkXpY, where X is a number indicating the device and Y a number indicating the partition I /dev/mmcblk0p2 is the second partition of the first device I Partitions of flash storage

I root=/dev/mtdblockX, where X is the partition number I /dev/mtdblock3 is the fourth partition of a NAND flash chip (if only one NAND flash chip is present)

DSI - FCEIA http://dsi.fceia.unr.edu.ar 206/263 Mounting rootfs over the network (1)

Once networking works, your root filesystem could be a directory on your GNU/Linux development host, exported by NFS (Network File System). This is very convenient for system development:

I Makes it very easy to update files on the root filesystem, without rebooting. Much faster than through the serial port.

I Can have a big root filesystem even if you don’t have support for internal or external storage yet.

I The root filesystem can be huge. You can even build native compiler tools and build all the tools you need on the target itself (better to cross-compile though).

DSI - FCEIA http://dsi.fceia.unr.edu.ar 207/263 Mounting rootfs over the network (2)

On the development workstation side, a NFS server is needed

I Install an NFS server (example: Debian, Ubuntu) sudo apt-get install nfs-kernel-server

I Add the exported directory to your /etc/exports file: /home/tux/rootfs 192.168.1.111(rw,no_root_squash, no_subtree_check)

I 192.168.1.111 is the client IP address I rw,no_root_squash,no_subtree_check are the NFS server options for this directory export.

I Start or restart your NFS server (example: Debian, Ubuntu) sudo /etc/init.d/nfs-kernel-server restart

DSI - FCEIA http://dsi.fceia.unr.edu.ar 208/263 Mounting rootfs over the network (3)

I On the target system I The kernel must be compiled with

I CONFIG_NFS_FS=y (NFS support) I CONFIG_IP_PNP=y (configure IP at boot time) I CONFIG_ROOT_NFS=y (support for NFS as rootfs) I The kernel must be booted with the following parameters:

I root=/dev/nfs (we want rootfs over NFS) I ip=192.168.1.111 (target IP address) I nfsroot=192.168.1.110:/home/tux/rootfs/ (NFS server details)

DSI - FCEIA http://dsi.fceia.unr.edu.ar 209/263 Mounting rootfs over the network (4)

DSI - FCEIA http://dsi.fceia.unr.edu.ar 210/263 rootfs in memory: initramfs (1)

I It is also possible to have the root filesystem integrated into the kernel image

I It is therefore loaded into memory together with the kernel I This mechanism is called initramfs

I It integrates a compressed archive of the filesystem into the kernel image I Variant: the compressed archive can also be loaded separately by the bootloader. I It is useful for two cases

I Fast booting of very small root filesystems. As the filesystem is completely loaded at boot time, application startup is very fast. I As an intermediate step before switching to a real root filesystem, located on devices for which drivers not part of the kernel image are needed (storage drivers, filesystem drivers, network drivers). This is always used on the kernel of desktop/server distributions to keep the kernel image size reasonable.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 211/263 rootfs in memory: initramfs (2)

DSI - FCEIA http://dsi.fceia.unr.edu.ar 212/263 rootfs in memory: initramfs (3)

I The contents of an initramfs are defined at the kernel configuration level, with the CONFIG_INITRAMFS_SOURCE option

I Can be the path to a directory containing the root filesystem contents I Can be the path to a cpio archive I Can be a text file describing the contents of the initramfs (see documentation for details)

I The kernel build process will automatically take the contents of the CONFIG_INITRAMFS_SOURCE option and integrate the root filesystem into the kernel image

I Details (in kernel sources): Documentation/filesystems/ramfs-rootfs-initramfs.txt Documentation/early-userspace/README

DSI - FCEIA http://dsi.fceia.unr.edu.ar 213/263 Linux Root Filesystem

Contents

DSI - FCEIA http://dsi.fceia.unr.edu.ar 214/263 Root filesystem organization

I The organization of a Linux root filesystem in terms of directories is well-defined by the Filesystem Hierarchy Standard

I http://www.linuxfoundation.org/collaborate/ workgroups/lsb/fhs I Most Linux systems conform to this specification

I Applications expect this organization I It makes it easier for developers and users as the filesystem organization is similar in all systems

DSI - FCEIA http://dsi.fceia.unr.edu.ar 215/263 Important directories (1)

/bin Basic programs /boot Kernel image (only when the kernel is loaded from a filesystem, not common on non-x86 architectures) /dev Device files (covered later) /etc System-wide configuration /home Directory for the users home directories /lib Basic libraries /media Mount points for removable media /mnt Mount points for static media /proc Mount point for the proc virtual filesystem

DSI - FCEIA http://dsi.fceia.unr.edu.ar 216/263 Important directories (2)

/root Home directory of the root user /sbin Basic system programs /sys Mount point of the sysfs virtual filesystem /tmp Temporary files /usr /usr/bin Non-basic programs /usr/lib Non-basic libraries /usr/sbin Non-basic system programs /var Variable data files. This includes spool directories and files, administrative and logging data, and transient and temporary files

DSI - FCEIA http://dsi.fceia.unr.edu.ar 217/263 Separation of programs and libraries

I Basic programs are installed in /bin and /sbin and basic libraries in /lib

I All other programs are installed in /usr/bin and /usr/sbin and all other libraries in /usr/lib

I In the past, on Unix systems, /usr was very often mounted over the network, through NFS

I In order to allow the system to boot when the network was down, some binaries and libraries are stored in /bin, /sbin and /lib

I /bin and /sbin contain programs like ls, ifconfig, cp, bash, etc.

I /lib contains the C library and sometimes a few other basic libraries

I All other programs and libraries are in /usr

DSI - FCEIA http://dsi.fceia.unr.edu.ar 218/263 Linux Root Filesystem

Device Files

DSI - FCEIA http://dsi.fceia.unr.edu.ar 219/263 Devices

I One of the kernel important role is to allow applications to access hardware devices I In the Linux kernel, most devices are presented to user space applications through two different abstractions

I Character device I Block device I Internally, the kernel identifies each device by a triplet of information

I Type (character or block) I Major (typically the category of device) I Minor (typically the identifier of the device)

DSI - FCEIA http://dsi.fceia.unr.edu.ar 220/263 Types of devices

I Block devices

I A device composed of fixed-sized blocks, that can be read and written to store data I Used for hard disks, USB keys, SD cards, etc. I Character devices

I Originally, an infinite stream of bytes, with no beginning, no end, no size. The pure example: a serial port. I Used for serial ports, terminals, but also sound cards, video acquisition devices, frame buffers I Most of the devices that are not block devices are represented as character devices by the Linux kernel

DSI - FCEIA http://dsi.fceia.unr.edu.ar 221/263 Devices: everything is a file

I A very important Unix design decision was to represent most of the “system objects” as files

I It allows applications to manipulate all “system objects” with the normal file API (open, read, write, close, etc.)

I So, devices had to be represented as files to the applications

I This is done through a special artifact called a device file

I It is a special type of file, that associates a file name visible to user space applications to the triplet (type, major, minor) that the kernel understands

I All device files are by convention stored in the /dev directory

DSI - FCEIA http://dsi.fceia.unr.edu.ar 222/263 Device files examples

Example of device files in a Linux system

$ ls -l /dev/ttyS0 /dev/tty1 /dev/sda1 /dev/sda2 /dev/zero brw-rw---- 1 root disk 8, 1 2011-05-27 08:56 /dev/sda1 brw-rw---- 1 root disk 8, 2 2011-05-27 08:56 /dev/sda2 crw------1 root root 4, 1 2011-05-27 08:57 /dev/tty1 crw-rw---- 1 root dialout 4, 64 2011-05-27 08:56 /dev/ttyS0 crw-rw-rw- 1 root root 1, 5 2011-05-27 08:56 /dev/zero

Example C code that uses the usual file API to write data to a serial port

int fd; fd = open("/dev/ttyS0", O_RDWR); write(fd, "Hello",5); close(fd);

DSI - FCEIA http://dsi.fceia.unr.edu.ar 223/263 Creating device files

I On a basic Linux system, the device files have to be created manually using the mknod command

I mknod /dev/ [c|b] major minor I Needs root privileges I Coherency between device files and devices handled by the kernel is left to the system developer I On more elaborate Linux systems, mechanisms can be added to create/remove them automatically when devices appear and disappear

I devtmpfs virtual filesystem, since kernel 2.6.32 I udev daemon, solution used by desktop and server Linux systems I mdev program, a lighter solution than udev

DSI - FCEIA http://dsi.fceia.unr.edu.ar 224/263 Linux Root Filesystem

Pseudo Filesystems

DSI - FCEIA http://dsi.fceia.unr.edu.ar 225/263 proc virtual filesystem

I The proc virtual filesystem exists since the beginning of Linux I It allows

I The kernel to expose statistics about running processes in the system I The user to adjust at runtime various system parameters about process management, memory management, etc.

I The proc filesystem is used by many standard user space applications, and they expect it to be mounted in /proc

I Applications such as ps or top would not work without the proc filesystem

I Command to mount /proc: mount -t proc nodev /proc

I Documentation/filesystems/proc.txt in the kernel sources

I man proc

DSI - FCEIA http://dsi.fceia.unr.edu.ar 226/263 proc contents

I One directory for each running process in the system

I /proc/ I cat /proc/3840/cmdline I It contains details about the files opened by the process, the CPU and memory usage, etc.

I /proc/interrupts, /proc/devices, /proc/iomem, /proc/ioports contain general device-related information

I /proc/cmdline contains the kernel command line I /proc/sys contains many files that can be written to to adjust kernel parameters

I They are called sysctl. See Documentation/sysctl/ in kernel sources. I Example echo 3 > /proc/sys/vm/drop_caches

DSI - FCEIA http://dsi.fceia.unr.edu.ar 227/263 sysfs filesystem

I The sysfs filesystem is a feature integrated in the 2.6 Linux kernel

I It allows to represent in user space the vision that the kernel has of the buses, devices and drivers in the system

I It is useful for various user space applications that need to list and query the available hardware, for example udev or mdev.

I All applications using sysfs expect it to be mounted in the /sys directory

I Command to mount /sys: mount -t sysfs nodev /sys

I $ ls /sys/ block bus class dev devices firmware fs kernel module power

DSI - FCEIA http://dsi.fceia.unr.edu.ar 228/263 Linux Root Filesystem

Minimal filesystem

DSI - FCEIA http://dsi.fceia.unr.edu.ar 229/263 Basic applications

I In order to work, a Linux system needs at least a few applications I An init application, which is the first user space application started by the kernel after mounting the root filesystem

I The kernel tries to run /sbin/init, /bin/init, /etc/init and /bin/sh. I In the case of an initramfs, it will only look for /init. Another path can be supplied by the rdinit kernel argument. I If none of them are found, the kernel panics and the boot process is stopped. I The init application is responsible for starting all other user space applications and services I Usually a shell, to allow a user to interact with the system I Basic Unix applications, to copy files, move files, list files (commands like mv, cp, mkdir, cat, etc.) I These basic components have to be integrated into the root filesystem to make it usable

DSI - FCEIA http://dsi.fceia.unr.edu.ar 230/263 Overall booting process

DSI - FCEIA http://dsi.fceia.unr.edu.ar 231/263 Overall booting process with initramfs

DSI - FCEIA http://dsi.fceia.unr.edu.ar 232/263 Busybox

DSI

Embedded Linux Busybox Developers

Free Electrons

© Copyright 2004-2018, Free Electrons. Creative Commons BY-SA 3.0 license. Corrections, suggestions, contributions and translations are welcome!

DSI - FCEIA http://dsi.fceia.unr.edu.ar 233/263 Why Busybox?

I A Linux system needs a basic set of programs to work

I An init program I A shell I Various basic utilities for file manipulation and system configuration I In normal Linux systems, these programs are provided by different projects

I coreutils, bash, grep, sed, tar, wget, modutils, etc. are all different projects I A lot of different components to integrate I Components not designed with embedded systems constraints in mind: they are not very configurable and have a wide range of features

I Busybox is an alternative solution, extremely common on embedded systems

DSI - FCEIA http://dsi.fceia.unr.edu.ar 234/263 General purpose toolbox: BusyBox

I Rewrite of many useful Unix command line utilities

I Integrated into a single project, which makes it easy to work with I Designed with embedded systems in mind: highly configurable, no unnecessary features I All the utilities are compiled into a single executable, /bin/busybox

I Symbolic links to /bin/busybox are created for each application integrated into Busybox

I For a fairly featureful configuration, less than 500 KB (statically compiled with uClibc) or less than 1 MB (statically compiled with glibc).

I http://www.busybox.net/

DSI - FCEIA http://dsi.fceia.unr.edu.ar 235/263 BusyBox commands!

Commands available in BusyBox 1.13 [, [[, addgroup, adduser, adjtimex, ar, arp, arping, ash, awk, basename, bbconfig, bbsh, brctl, bunzip2, busybox, bzcat, bzip2, cal, cat, catv, chat, chattr, chcon, chgrp, chmod, chown, chpasswd, chpst, chroot, chrt, chvt, cksum, clear, cmp, comm, cp, cpio, crond, crontab, cryptpw, cttyhack, cut, date, dc, dd, deallocvt, delgroup, deluser, depmod, devfsd, df, dhcprelay, diff, dirname, dmesg, dnsd, dos2unix, dpkg, dpkg_deb, du, dumpkmap, dumpleases, e2fsck, echo, ed, egrep, eject, env, envdir, envuidgid, ether_wake, expand, expr, fakeidentd, false, fbset, fbsplash, fdflush, fdformat, fdisk, fetchmail, fgrep, find, findfs, fold, free, freeramdisk, fsck, fsck_minix, ftpget, ftpput, fuser, getenforce, getopt, getsebool, getty, grep, gunzip, gzip, halt, hd, hdparm, head, hexdump, hostid, hostname, httpd, hush, hwclock, id, ifconfig, ifdown, ifenslave, ifup, inetd, init, inotifyd, insmod, install, ip, ipaddr, ipcalc, ipcrm, ipcs, iplink, iproute, iprule, iptunnel, kbd_mode, kill, killall, killall5, klogd, lash, last, length, less, linux32, linux64, linuxrc, ln, load_policy, loadfont, loadkmap, logger, login, logname, logread, losetup, lpd, lpq, lpr, ls, lsattr, lsmod, lzmacat, makedevs, man, matchpathcon, md5sum, mdev, mesg, microcom, mkdir, mke2fs, mkfifo, mkfs_minix, mknod, mkswap, mktemp, modprobe, more, mount, mountpoint, msh, mt, mv, nameif, nc, netstat, nice, nmeter, nohup, nslookup, od, openvt, parse, passwd, patch, pgrep, pidof, ping, ping6, pipe_progress, pivot_root, pkill, poweroff, printenv, printf, ps, pscan, pwd, raidautorun, rdate, rdev, readahead, readlink, readprofile, realpath, reboot, renice, reset, resize, restorecon, rm, rmdir, rmmod, route, rpm, rpm2cpio, rtcwake, run_parts, runcon, runlevel, runsv, runsvdir, rx, script, sed, selinuxenabled, sendmail, seq, sestatus, setarch, setconsole, setenforce, setfiles, setfont, setkeycodes, setlogcons, setsebool, setsid, setuidgid, sh, sha1sum, showkey, slattach, sleep, softlimit, sort, split, start_stop_daemon, stat, strings, stty, su, sulogin, sum, sv, svlogd, swapoff, swapon, switch_root, sync, sysctl, syslogd, tac, tail, tar, taskset, tcpsvd, tee, telnet, telnetd, test, tftp, tftpd, time, top, touch, tr, traceroute, true, tty, ttysize, tune2fs, udhcpc, udhcpd, udpsvd, umount, uname, uncompress, unexpand, uniq, unix2dos, unlzma, unzip, uptime, usleep, uudecode, uuencode, vconfig, vi, vlock, watch, watchdog, wc, wget, which, who, whoami, xargs, yes, zcat, zcip

DSI - FCEIA http://dsi.fceia.unr.edu.ar 236/263 Applet highlight: Busybox init

I Busybox provides an implementation of an init program

I Simpler than the init implementation found on desktop/server systems: no runlevels are implemented I A single configuration file: /etc/inittab

I Each line has the form :::

I Allows to run services at startup, and to make sure that certain services are always running on the system

I See examples/inittab in Busybox for details on the configuration

DSI - FCEIA http://dsi.fceia.unr.edu.ar 237/263 Applet highlight - BusyBox vi

I If you are using BusyBox, adding vi support only adds 20K. (built with shared libraries, using uClibc).

I You can select which exact features to compile in.

I Users hardly realize that they are using a lightweight vi version!

I Tip: you can learn vi on the desktop, by running the vimtutor command.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 238/263 Configuring BusyBox

I Get the latest stable sources from http://busybox.net I Configure BusyBox (creates a .config file):

I make defconfig Good to begin with BusyBox. Configures BusyBox with all options for regular users. I make allnoconfig Unselects all options. Good to configure only what you need.

I make xconfig (graphical, needs the libqt3-mt-dev package) or make menuconfig (text) Same configuration interfaces as the ones used by the Linux kernel (though older versions are used).

DSI - FCEIA http://dsi.fceia.unr.edu.ar 239/263 BusyBox make xconfig

You can choose:

I the commands to compile,

I and even the command options and features that you need!

DSI - FCEIA http://dsi.fceia.unr.edu.ar 240/263 Compiling BusyBox

I Set the cross-compiler prefix in the configuration interface: BusyBox Settings -> Build Options - > Cross Compiler prefix Example: arm-linux- I Set the installation directory in the configuration interface: BusyBox Settings -> Installation Options - > BusyBox installation prefix I Add the cross-compiler path to the PATH environment variable: export PATH=/usr/xtools/arm-unknown-linux- uclibcgnueabi/bin:$PATH I Compile BusyBox: make I Install it (this creates a Unix directory structure symbolic links to the busybox executable): make install

DSI - FCEIA http://dsi.fceia.unr.edu.ar 241/263 Laboratorio pr´actico- A tiny embedded system

I Make Linux boot on a directory on your workstation, shared by NFS

I Create and configure a minimalistic Linux embedded system

I Install and use BusyBox

I System startup with /sbin/init

I Set up a simple web interface

I Use shared libraries

DSI - FCEIA http://dsi.fceia.unr.edu.ar 242/263 Block filesystems

DSI

Embedded Linux Block filesystems Developers

Free Electrons

© Copyright 2004-2018, Free Electrons. Creative Commons BY-SA 3.0 license. Corrections, suggestions, contributions and translations are welcome!

DSI - FCEIA http://dsi.fceia.unr.edu.ar 243/263 Block vs. flash

I Storage devices are classified in two main types: block devices and flash devices

I They are handled by different subsystems and different filesystems I Block devices can be read and written to on a per-block basis, without erasing.

I Hard disks, floppy disks, RAM disks I USB keys, Compact Flash, SD card: these are based on flash storage, but have an integrated controller that emulates a block device, managing and erasing flash sectors in a transparent way. I Flash devices can be read, but writing requires erasing, and often occurs on a larger size than the “block” size.

I NOR flash, NAND flash

DSI - FCEIA http://dsi.fceia.unr.edu.ar 244/263 Block device list

I The list of all block devices available in the system can be found in /proc/partitions $ cat /proc/partitions major minor #blocks name

179 0 3866624 mmcblk0 179 1 73712 mmcblk0p1 179 2 3792896 mmcblk0p2 8 0 976762584 sda 8 1 1060258 sda1 8 2 975699742 sda2

I And also in /sys/block/

DSI - FCEIA http://dsi.fceia.unr.edu.ar 245/263 Traditional block filesystems

Traditional filesystems

I Can be left in a non-coherent state after a system crash or sudden poweroff, which requires a full filesystem check after reboot.

I ext2: traditional Linux filesystem (repair it with fsck.ext2)

I vfat: traditional Windows filesystem (repair it with fsck.vfat on GNU/Linux or Scandisk on Windows)

DSI - FCEIA http://dsi.fceia.unr.edu.ar 246/263 Journaled filesystems

I Designed to stay in a correct state even after system crashes or a sudden poweroff

I All writes are first described in the journal before being committed to files

DSI - FCEIA http://dsi.fceia.unr.edu.ar 247/263 Filesystem recovery after crashes

I Thanks to the journal, the filesystem is never left in a corrupted state

I Recently saved data could still be lost

DSI - FCEIA http://dsi.fceia.unr.edu.ar 248/263 Journaled block filesystems

Journaled filesystems

I ext3: ext2 with journal extension ext4: the new generation with many improvements. Ready for production. They are the default filesystems for all Linux systems in the world.

I The Linux kernel supports many other filesystems: reiserFS, JFS, XFS, etc. Each of them have their own characteristics, but are more oriented towards server or scientific workloads

I Btrfs (“Butter FS”) The next generation. Great performance. In mainline but still experimental. We recommend ext2 for very small partitions (< 5 MB), because other filesystems need too much space for metadata (ext3 and ext4 need about 1 MB for a 4 MB partition).

DSI - FCEIA http://dsi.fceia.unr.edu.ar 249/263 Creating ext2/ext3/ext4 volumes

I To create an empty ext2/ext3/ext4 filesystem on a block device or inside an already-existing image file

I mkfs.ext2 /dev/hda3 I mkfs.ext3 /dev/sda2 I mkfs.ext4 /dev/sda3 I mkfs.ext2 disk.img I To create a filesystem image from a directory containing all your files and directories

I Use the genext2fs tool, from the package of the same name I genext2fs -d rootfs/ rootfs.img I Your image is then ready to be transferred to your block device

DSI - FCEIA http://dsi.fceia.unr.edu.ar 250/263 Mounting filesystem images

I Once a filesystem image has been created, one can access and modifies its contents from the development workstation, using the loop mechanism

I Example: genext2fs -d rootfs/ rootfs.img mkdir /tmp/tst mount -t ext2 -o loop rootfs.img /tmp/tst

I In the /tmp/tst directory, one can access and modify the contents of the rootfs.img file.

I This is possible thanks to loop, which is a kernel driver that emulates a block device with the contents of a file.

I Do not forget to run umount before using the filesystem image!

DSI - FCEIA http://dsi.fceia.unr.edu.ar 251/263 F2FS

http://en.wikipedia.org/wiki/F2FS

I Filesystem optimized for block devices based on NAND flash

I Available in the mainline Linux kernel

I Benchmarks: best performer on flash devices most of the time: See http://lwn.net/Articles/520003/

I Technical details: http://lwn.net/Articles/518988/

DSI - FCEIA http://dsi.fceia.unr.edu.ar 252/263 Squashfs

Squashfs: http://squashfs.sourceforge.net

I Read-only, compressed filesystem for block devices. Fine for parts of a filesystem which can be read-only (kernel, binaries...)

I Great compression rate and read access performance

I Used in most live CDs and live USB distributions

I Supports LZO compression for better performance on embedded systems with slow CPUs (at the expense of a slightly degraded compression rate)

I Now supports XZ algorithm, for a much better compression rate, at the expense of higher CPU usage and time. Benchmarks: (roughly 3 times smaller than ext3, and 2-4 times faster) http://elinux.org/Squash_Fs_Comparisons

DSI - FCEIA http://dsi.fceia.unr.edu.ar 253/263 Squashfs - How to use

I Need to install the squashfs-tools package I Creation of the image

I On your workstation, create your filesystem image: mksquashfs rootfs/ rootfs.sqfs I Caution: if the image already exists remove it first, or use the -noappend option. I Installation of the image

I Let’s assume your partition on the target is in /dev/sdc1 I Copy the filesystem image on the device dd if=rootfs.sqfs of=/dev/sdc1 Be careful when using dd to not overwrite the incorrect partition!

I Mount your filesystem: mount -t squashfs /dev/sdc1 /mnt/root

DSI - FCEIA http://dsi.fceia.unr.edu.ar 254/263 tmpfs

Not a block filesystem of course! Perfect to store temporary data in RAM: system log files, connection data, temporary files...

I tmpfs configuration: File systems -> Pseudo filesystems Lives in the Linux file cache. Doesn’t waste RAM: unlike ramdisks, no need to copy files to the file cache, grows and shrinks to accommodate stored files. Saves RAM: can swap out pages to disk when needed.

I How to use: choose a name to distinguish the various tmpfs instances you could have. Examples: mount -t tmpfs varrun /var/run mount -t tmpfs udev /dev See Documentation/filesystems/tmpfs.txt in kernel sources.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 255/263 Mixing read-only and read-write filesystems

Good idea to split your block storage into:

I A compressed read-only partition (Squashfs) Typically used for the root filesystem (binaries, kernel...). Compression saves space. Read-only access protects your system from mistakes and data corruption.

I A read-write partition with a journaled filesystem (like ext3) Used to store user or configuration data. Guarantees filesystem integrity after power off or crashes.

I Ram storage for temporary files (tmpfs)

DSI - FCEIA http://dsi.fceia.unr.edu.ar 256/263 Laboratorio pr´actico- Block filesystems

I Creating partitions on your block storage

I Booting your system with a mix of filesystems: SquashFS for the root filesystem (including applications), ext3 for configuration and user data, and tmpfs for temporary system files.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 257/263 References

DSI

Embedded Linux References Developers

Free Electrons

© Copyright 2004-2018, Free Electrons. Creative Commons BY-SA 3.0 license. Corrections, suggestions, contributions and translations are welcome!

DSI - FCEIA http://dsi.fceia.unr.edu.ar 258/263 Books

I Embedded Linux Primer, Second Edition, Prentice Hall By Christopher Hallinan, October 2010 Covers a very wide range of interesting topics. http://j.mp/17NYxBP

I Building Embedded Linux Systems, O’Reilly By Karim Yaghmour, Jon Masters, Gilad Ben-Yossef, Philippe Gerum and others (including Michael Opdenacker), August 2008 http://oreilly.com/catalog/9780596529680/

I Embedded Linux System Design and Development P. Raghavan, A. Lad, S. Neelakandan, Auerbach, Dec. 2005. Very good coverage of the POSIX programming API (still up to date). http://j.mp/19X8iu2

DSI - FCEIA http://dsi.fceia.unr.edu.ar 259/263 Web sites

I ELinux.org, http://elinux.org, a Wiki entirely dedicated to embedded Linux. Lots of topics covered: real-time, filesystem, multimedia, tools, hardware platforms, etc. Interesting to explore to discover new things.

I LWN, http://lwn.net, very interesting news site about Linux in general, and specifically about the kernel. Weekly newsletter, available for free after one week for non-paying visitors.

I Linux Gizmos, http://linuxgizmos.com, a news site about embedded Linux, mainly oriented on hardware platforms related news.

DSI - FCEIA http://dsi.fceia.unr.edu.ar 260/263 International conferences

Useful conferences featuring embedded Linux and kernel topics

I Embedded Linux Conference: http://embeddedlinuxconference.com/ Organized by the Linux Foundation: California (San Francisco, Spring), in Europe (Fall). Very interesting kernel and user space topics for embedded systems developers. Presentation slides freely available

I Linux Plumbers, http://linuxplumbersconf.org Conference on the low-level plumbing of Linux: kernel, audio, power management, device management, multimedia, etc.

I FOSDEM: http://fosdem.org (Brussels, February) For developers. Presentations about system development.

I Don’t miss our free conference videos on http://free- electrons.com/community/videos/conferences/!

DSI - FCEIA http://dsi.fceia.unr.edu.ar 261/263 Last slides

DSI

Embedded Linux Last slides Developers

Free Electrons

© Copyright 2004-2018, Free Electrons. Creative Commons BY-SA 3.0 license. Corrections, suggestions, contributions and translations are welcome!

DSI - FCEIA http://dsi.fceia.unr.edu.ar 262/263 Last slide

Thank you! And may the Source be with you

DSI - FCEIA http://dsi.fceia.unr.edu.ar 263/263