Abstract - Salle-URLusers.salleurl.edu/~xavier.canaleta/memories/CarlesGarcia_TFC.pdf · Abstract Este trabajo analizará con detalle cada una de las partes de hardware de la placa

Abstract Este trabajo analizará con detalle cada una de las partes de hardware de la

placa de desarrollo LN2410 del fabricante coreano Clabsys, para después adaptar dos de los sistemas operativos más comunes en el mercado.

Para ello se planteará toda la plataforma de hardware y software necesaria

para poder desarrollar tanto el sistema operativo deseado como las aplicaciones específicas capaces de explotar todas las posibilidades de este hardware empotrado.

Resumen

La placa de desarrollo LN2410 es un sistema hardware empotrado. Se llama así por que en un espacio físico reducido incorpora múltiples funcionalidades de procesado, adquisición de datos, comunicaciones, ínter actuación con el usuario, gráficos y expansión. El problema es la falta de documentación. La poca adjuntada está escrita en coreano. Otro problema es el incorrecto funcionamiento de parte del software proporcionado que sólo funciona en equipos coreanos.

Partiendo de esta base se inicia todo un proceso de investigación sobre las posibilidades de esta placa de desarrollo, sistemas operativos adecuados, cómo instalarlos y de qué manera desarrollar aplicaciones que corran sobre ellos.

Primero explicaremos de qué tipo de hardware disponemos en nuestra placa de desarrollo junto con sus especificaciones y características principales. Seguidamente profundizaremos en la mejor plataforma sobre la que desarrollaremos todo el proceso que nos llevará desde los ficheros fuente de un sistema operativo hasta una imagen binaria que arrancará todo el sistema. Por último es imprescindible conocer a los dos operativos actuales, Linux y Windows, que admite nuestra placa de desarrollo; su manera de configurar, compilar e instalarlos así como desarrollar aplicaciones sobre ellos.

Todo el trabajo está firmemente orientado como material docente para que pueda utilizarse en cualquier asignatura que abarque las áreas de creación y administración de sistemas operativos, indirectamente entornos distribuidos.

Índice 1. Introducción ....................................................................................................1 1.1 Enfoque del trabajo .................................................................................1 1.2 Objetivos..................................................................................................2 1.3 Estructura de la memoria...................................................................3 2. Arquitectura y componentes de la placa.........................................................4 2.1 Visión general..........................................................................................4 2.2 Arquitectura ARM ....................................................................................6 2.2.1 Historia............................................................................................6 2.2.2 Características ARM 920T..............................................................8 2.3 Dispositivos I/O......................................................................................10 2.3.1 Introducción ..................................................................................10 2.3.2 USB...............................................................................................10 2.3.3 Ethernet ........................................................................................11 2.3.4 RS232 ...........................................................................................12 2.3.5 Ranuras para tarjetas MMC/SD y CF ...........................................13 2.3.6 Conector IDE para HDD/CDROM.................................................15 2.3.7 Pantalla táctil LP35 .......................................................................15 2.3.8 Puerto JTAG .................................................................................17 2.4 Memoria.................................................................................................17 2.4.1 Introducción ..................................................................................17 2.4.2 Memoria Flash ..............................................................................18 2.4.2.1 Características generales.....................................................18 2.4.2.2 Funcionamiento....................................................................19 2.4.3 Memoria SDRAM ..........................................................................21 3. Entorno de trabajo.........................................................................................22 3.1 Plataforma de desarrollo .......................................................................22 3.2 Bootstrap ...............................................................................................24 3.2.1 Instalación controlador JTAG en el puerto paralelo......................25 3.2.2 Descarga del bootstrap a la memoria NOR ..................................29 4. Linux Embedded ...........................................................................................31 4.1 El kernel, Linux 2.6.21 ...........................................................................31 4.1.1 Historia..........................................................................................32 4.1.2 Características principales y diferencias con Linux 2.4 ................33 4.2 El Bootloader, Das U-Boot 1.1.1 ...........................................................37 4.2.1 Descarga del bootloader a la memoria NOR ................................38 4.2.2 Configuración del bootloader a través de Hyperterminal ..............40 4.3 Compilación cruzada del núcleo............................................................42 4.3.1 Instalación del compilador cruzado o toolchain ............................43

4.3.2 Compilando el núcleo ...................................................................48 4.3.3 Descarga del núcleo en la placa LN2410 .....................................55 4.4 El intérprete de comandos BusyBox .....................................................57 4.5 Comunicaciones por Bluetooth..............................................................60 4.5.1 Transferencia de ficheros por Bluetooth.............................................65 4.6 Entornos gráficos...................................................................................68 4.7 El sistema de ficheros ...........................................................................76 4.8 Arranque del sistema.............................................................................81 5. Windows CE..................................................................................................86 5.1 Introducción ...........................................................................................86 5.1.1 Historia..........................................................................................87 5.1.3 Características principales............................................................88 5.2 El bootloader, Eboot ..............................................................................89 5.2.1 Descarga del bootloader a la memoria NOR ................................89 5.2.2 Configuración del bootloader, Eboot, a través de Hyperterminal .91 5.3 Platform Builder .....................................................................................94 5.3.1 Instalación Platform Builder ..........................................................95 5.3.2 Instalación BSP de Clabsys para Platform Builder .....................100 5.3.3 Compilando Windows CE 5.0 con Platform Builder....................102 5.3.4 Descarga de Windows CE 5.0 en la placa LN2410 ....................104 5.4 Conexión al equipo host vía USB........................................................105 5.5 Ejemplo desarrollo de un aplicación con Visual Studio .......................109 6. Coste de realización....................................................................................114 7. Conclusiones ..............................................................................................115 8. Líneas de futuro ..........................................................................................117 9. Bibliografía ..................................................................................................118 10. Agradecimientos .......................................................................................121

Índice de figuras

Figura 2.1: Visión general posterior de la placa de desarrollo LN2410 ..............5 Figura 2.2: ARM: Visión del núcleo del procesador ARM920T...........................9 Figura 2.3: USB tipo Device..............................................................................11 Figura 2.4: USB tipo Host .................................................................................11 Figura 2.5: Puerto Ethernet...............................................................................12 Figura 2.6: Puerto RS232 .................................................................................12 Figura 2.7: Pantalla táctil Samsung LP35.........................................................16 Figura 3.1: Esquema de conexión del host a la placa LN2410.........................23 Figura 3.2: Mapa de memoria NOR en la placa LN2410 ..................................24 Figura 3.3: JATG: Instalación del controlador giveio.sys ..................................25 Figura 3.4: JATG: Instalación del controlador giveio.sys ..................................26 Figura 3.5: JATG: Instalación del controlador giveio.sys ..................................26 Figura 3.6: JATG: Instalación del controlador giveio.sys ..................................26 Figura 3.7: JATG: Instalación del controlador giveio.sys ..................................27 Figura 3.8: JATG: Instalación del controlador giveio.sys ..................................27 Figura 3.9: JATG: Instalación del controlador giveio.sys ..................................28 Figura 3.10: JATG: Instalación del controlador giveio.sys ................................28 Figura 3.11: JATG: Instalación del controlador giveio.sys ................................29 Figura 3.12: JFLASH: Escritura en memoria NOR del bootstrap......................30 Figura 4.1: Historia cronológica de Linux..........................................................33 Figura 4.2: Esquema por capas para carga de Linux .......................................36 Figura 4.3: Mapa de memoria en la placa LN2410 ...........................................36 Figura 4.4: JFLASH: Escritura en memoria NOR del bootloader......................39 Figura 4.5: Hyperterminal: Configuración de conexión .....................................40 Figura 4.6: Hyperterminal: Primera ejecución U-Boot.......................................41 Figura 4.7: Hyperterminal: Configuración variables de entorno Ethernet .........42 Figura 4.8: Descarga y descompresión de crosstools ......................................44 Figura 4.9: Instalación de crosstools ................................................................45 Figura 4.10: Instalación de crosstools ..............................................................46 Figura 4.11: Añadimos la ruta al PATH del sistema .........................................47 Figura 4.12: Comprobamos que tenemos acceso a los binarios ......................47 Figura 4.13: Descomprimimos el código fuente................................................48 Figura 4.14: Aplicamos el parche......................................................................49 Figura 4.15: Editando Makefile .........................................................................49 Figura 4.16: Gestor de Paquetes Synaptic .......................................................50 Figura 4.17: Carga de la configuración del núcleo............................................51 Figura 4.18: Rectificación de la configuración del núcleo .................................52 Figura 4.19: Rectificación de la configuración del núcleo .................................52 Figura 4.20: Configuración soporte Bluetooth...................................................53 Figura 4.21: Configuración soporte IDE............................................................54 Figura 4.22: Creación del kernel 2.6.21 para placa LN2410.............................54

Figura 4.23: Copiamos zImage de Linux a Windows........................................55 Figura 4.24: Descarga del núcleo en la placa LN2410 .....................................56 Figura 4.25: Descompresión Busybox 1.10.1 ...................................................57 Figura 4.26: Configuración Busybox 1.10.1 ......................................................58 Figura 4.27: Configuración opciones Busybox 1.10.1.......................................58 Figura 4.28: Compilación cruzada Busybox 1.10.1...........................................59 Figura 4.29: Arquitectura del subsistema Bluetooth con Bluez.........................60 Figura 4.30: Descompresión librería Bluez. ......................................................61 Figura 4.31: Configuración librería Bluez..........................................................62 Figura 4.32: Copiamos contenido generado al compilador...............................63 Figura 4.33: Descompresión utilidades Bluez...................................................63 Figura 4.34: Configuración utilidades Bluez......................................................64 Figura 4.35: Instalación ficheros para transferir ficheros por Bluetooth............65 Figura 4.36: Configuración openobex...............................................................66 Figura 4.37: Actualizamos el compilador cruzado ............................................67 Figura 4.38: Actualizamos el compilador cruzado ............................................67 Figura 4.39: Compilación e instalación de openobex .......................................68 Figura 4.40: Configuración zlib .........................................................................70 Figura 4.41: Instalación zlib en la placa de desarrollo LN2410.........................71 Figura 4.42: Descompresión ficheros necesarios Microwindows .....................72 Figura 4.43: Aplicamos parche para Microwindows..........................................72 Figura 4.44: Editando config .............................................................................73 Figura 4.45: Editando Makefile.rules.................................................................74 Figura 4.46: Ejecución aplicaciones Nano-X ....................................................75 Figura 4.47: Ejecución calibración Nano-X .......................................................75 Figura 4.48: Aplicaciones de demostración Nano-X.........................................76 Figura 4.49: Arranque placa LN2410................................................................78 Figura 4.50: Fichero de configuración rc.local ..................................................79 Figura 4.51: Fichero de configuración /etc/profile .............................................80 Figura 4.52: Línea de configuración de arranque del kernel.............................81 Figura 4.53: Creación de bootpimage...............................................................82 Figura 4.54: Arranque de Linux desde SDRAM................................................83 Figura 4.55: Formateamos la tarjeta SD...........................................................83 Figura 4.56: Intérprete de comandos Busybox .................................................85 Figura 5.1: Esquema por capas para carga de Windows CE ...........................88 Figura 5.2: Descarga bootloader Eboot a la memoria NOR .............................90 Figura 5.3: Pantalla bootloader Eboot en la placa LN2410...............................91 Figura 5.4: Inicio del bootloader Eboot .............................................................93 Figura 5.5: Configuración del bootloader Eboot................................................94 Figura 5.6: Instalación de Platform Builder .......................................................95 Figura 5.7: Instalación de Platform Builder .......................................................95 Figura 5.8: Aceptación de licencia de Platform Builder.....................................96 Figura 5.9: Introducción de la llave y registro de Platform Builder....................96 Figura 5.10: Instalación personalizada de Platform Builder..............................97 Figura 5.11: Selección de los directorios de instalación de Platform Builder....97 Figura 5.12: Personalización de la instalación de Platform Builder ..................98

Figura 5.13: Aceptación de licencia de Platform Builder...................................99 Figura 5.14 Listo para instalar de Platform Builder ...........................................99 Figura 5.15: Finalización de la instalación de Platform Builder.......................100 Figura 5.16: Instalación del BSP.....................................................................101 Figura 5.17: Ubicación de la instalación del BSP ...........................................101 Figura 5.18: Finalización de la instalación del BSP ........................................102 Figura 5.19: Entorno de desarrollo con Platform Builder ................................103 Figura 5.20: Conexión entre la placa LN2410 y Platform Builder ...................104 Figura 5.21: Descarga imagen Windows CE a la placa..................................105 Figura 5.22: Windows CE en la placa LN2410 ...............................................105 Figura 5.23: Instalación como USB Device.....................................................106 Figura 5.24: Hacemos caso omiso prueba logotipo Windows ........................107 Figura 5.25: Finalizamos la instalación ...........................................................107 Figura 5.26: Seleccionamos tipo asociación...................................................108 Figura 5.27: Conectamos con el equipo .........................................................108 Figura 5.28: Exploración placa LN2410..........................................................109 Figura 5.29: Creamos un nuevo proyecto.......................................................109 Figura 5.30: Especificamos tipo de aplicación ................................................110 Figura 5.31: Conectamos la placa de desarrollo LN2410 ...............................111 Figura 5.32: Descarga de la aplicación en la placa LN2410...........................112 Figura 5.33: Hola mundo en LN2410..............................................................112

1

Capítulo 1

Introducción 1.1 Enfoque del trabajo

Este trabajo está orientado a buscar una plataforma de desarrollo

adecuada para que cualquier persona sea capaz de crear, configurar y descargar un sistema operativo, completo y funcional en la placa de desarrollo LN2410.

Para ello será necesario que tenga un conocimiento profundo del hardware que la compone, que tenga instalado una correcta plataforma de desarrollo y que disponga de los ficheros fuente adecuados. Explicaremos la plataforma propuesta, sus ventajas e inconvenientes y poco a poco nos iremos sumergiendo en el proceso de desarrollo de todo el sistema operativo, tanto para Windows como para Linux, para después acabar explicando la manera de desarrollar aplicaciones para cada caso.

Como no teníamos un punto de partida fijo ya que la documentación era muy escasa muchas de las partes descritas son fruto de un largo proceso de investigación y de un testeo prueba-error muy agresivo.

Finalmente disponemos de un entorno sencillo, funcional y capaz de desarrollar un sistema operativo entero en muy poco tiempo, incluso si disponemos de la imagen es cuestión de segundos tener un sistema operativo corriendo en la placa LN2410.

Esto facilitará que, en un futuro, se abran nuevas vías de investigación tanto sobre los sistemas operativos como en las posibles aplicaciones que se pueden desarrollar.

Plataforma de desarrollo de la placa LN2410 2

1.2 Objetivos Los objetivos que se pretenden abarcar en este trabajo son:

• Visión global del hardware disponible en la placa LN2410 • Análisis de la plataforma de desarrollo adaptada a nuestro sistema

y que sea compatible tanto con nuestro entorno Windows como con Linux.

• Comprensión del proceso de configuración inicial de la placa. • Configuración, creación e instalación de los sistemas operativos

Windows y Linux. • Entorno propuesto para la creación de aplicaciones para cada uno

de ellos.


1.3 Estructura de la memoria La estructura de la memoria está dividida en dos partes claramente

diferenciadas. La primera parte corresponde a la descripción de la placa y de todos sus

componentes, identificándolos visualmente y técnicamente, junto a una descripción de su tecnología.

La segunda parte corresponde a la creación, configuración y descarga en la placa de ambos sistemas operativos además de la carga de la configuración inicial.

Se ha hecho de esta manera para dotar al trabajo de una visión más docente, explicando cada sistema operativo en profundidad al mismo tiempo que guía al lector en todo el proceso para, al final, tener un único fichero que cargaremos en la placa para obtener un sistema operativo completo funcionando sobre ella.

Ciertamente esta memoria no sigue una estructura convencional por varios motivos. El primero es que no se trata de desarrollo de software sino que se ha tratado de recopilar los procesos a seguir optimizados para crear un compendio de pasos a modo de guía didáctica. Esta guía es tan útil para el profesor docente con todo lujo de detalles como para los alumnos, en una versión reducida, para animar sus deseos de investigación.

Además sirve como punto de partida para todos aquellos proyectistas o intensificadores que estén interesados en adentrarse en el desarrollo de aplicaciones empotradas o ampliaciones y futuras actualizaciones de ambos sistemas operativos.

4

Capítulo 2

Arquitectura y componentes de la placa

2.1 Visión general La placa LN2410 del fabricante coreano Clabsys es una placa de

desarrollo especialmente diseñada para albergar sistemas empotrados. Cuenta con muchas características importantes, entre ellas la gran capacidad de memoria de almacenamiento (32MB) junto con la dedicada a la ejecución (64MB) así como las múltiples capacidades de expansión gracias a su puerto Ethernet y USB. Por contra cuenta con un procesador muy potente pero no suficiente para albergar algún sistema operativo moderno como Windows Mobile 6.0.

Las posibilidades potenciales de este conjunto, tanto por su procesador, como por todos sus dispositivos de entrada / salida, son enormes.

Aplicaciones móviles, entornos distribuidos, comunicaciones por Bluetooth, inalámbricas o por Ethernet, son algunos de los ejemplos posibles.


Identificaremos ahora sus componentes:

Figura 2.1: Visión general posterior de la placa de desarrollo LN2410


A: Conector para la alimentación. B: Puerto USB, configurado en modo Host, es decir, preparado para conectarle todo tipo de dispositivos USB como discos duros, pastillas Wi-fi, pastillas Bluetooth, etc. C: Puerto USB, configurado en modo Device, este será cuando queramos identificarlo como dispositivo tipo “Placa LN2410”. D: Puerto para conexión Ethernet. E: Puerto RS232 principalmente para conectarnos en modo consola remota. F: Primer banco de memoria SDRAM de 32MB modelo K4S561632H-T(U)C/L75. G: Memoria NOR modelo Am29LV160D de 2MB. H: Adaptador JTAG I: Lector de tarjetas SD/MMC. J: Lector de tarjetas CompactFlash. K: Botón de reset. L: Controlador GPIO modelo XC9536XL de Xilinx. M: Corazón del sistema. Procesador ARM S3C2410 con núcleo ARM920T N: Conector de corriente para un HDD, usando el conector J10 como bus de datos. O: Tarjeta de red, tipo CS8900 de Crystal LAN. P: Altavoz del sistema Q: Memoria NAND, lista para almacenar el sistema operativo, modelo K9F5608 de 32MB R: Segundo banco de memoria SDRAM de 32MB modelo K4S561632H-T(U)C/L75.

2.2 Arquitectura ARM

2.2.1 Historia El diseño del ARM comenzó en 1983 como un proyecto de desarrollo en la

empresa Acorn Computers Ltd. Roger Wilson y Steve Furber lideraban el equipo[1].

El equipo terminó el diseño preliminar y los primeros prototipos del procesador en el año 1985, al que llamaron ARM1. La primera versión utilizada comercialmente se bautizó como ARM2 y se lanzó en el año 1986.

La arquitectura del ARM2 posee un bus de datos de 32 bits y ofrece un espacio de direcciones de 26 bits, junto con 16 registros de 32 bits. Uno de estos registros se utiliza como contador de programa, aprovechándose sus 4 bits superiores y los 2 inferiores para contener los flags de estado del procesador.

El ARM2 es probablemente el procesador de 32 bits útil más simple del mundo, ya que posee sólo 30.000 transistores. Su simplicidad se debe a que no


está basado en microcódigo (sistema que suele ocupar en torno a la cuarta parte de la cantidad total de transistores usados en un procesador) y a que, como era común en aquella época, no incluye caché. Gracias a esto, su consumo en energía es bastante bajo, a la vez que ofrece un mejor rendimiento que un 286. Su sucesor, el ARM3, incluye una pequeña memoria caché de 4 KB, lo que mejora los accesos a memoria repetitivos.

A finales de los años 80, Apple Computer comenzó a trabajar con Acorn en nuevas versiones del núcleo ARM. En Acorn se dieron cuenta de que el hecho de que el fabricante de un procesador fuese también un fabricante de ordenadores podría echar para atrás a la competencia, por lo que se decidió crear una nueva compañía llamada Advanced RISC Machines, que sería la encargada del diseño y gestión de las nuevas generaciones de procesadores ARM. Ocurría esto en el año 1990.

Este trabajo derivó en el ARM6, presentado en 1991. Apple utilizó el ARM 610 (basado en el ARM6), como procesador básico para su innovador PDA, el Apple Newton. Por su parte, Acorn lo utilizó en 1994 como procesador principal en su RiscPC.

El núcleo mantuvo su simplicidad a pesar de los cambios: en efecto, el ARM2 tiene 30.000 transistores, mientras que el ARM6 sólo cuenta con 35.000. La idea era que el usuario final combinara el núcleo del ARM con un número opcional de periféricos integrados y otros elementos, pudiendo crear un procesador completo a la medida de sus necesidades.

La mayor utilización de la tecnología ARM se alcanzó con el procesador ARM7TDMI, con millones de unidades en teléfonos móviles y sistemas de videojuegos portátiles.

DEC licenció el diseño, lo cual generó algo de confusión debido a que ya producía el DEC Alpha, y creó el StrongARM. Con una velocidad de reloj de 233 MHz, este procesador consumía solo 1 watt de potencia (este consumo de energía se ha reducido en versiones más recientes). Esta tecnología pasó posteriormente a manos de Intel, como fruto de un acuerdo jurídico, que la integró en su línea de procesadores Intel i960 e hizo más ardua la competencia.

Freescale (una empresa que derivó de Motorola en el año 2004), IBM, Infineon Technologies, OKI, Texas Instruments, Nintendo, Philips, VLSI, Atmel, Sharp, Samsung y STMicroelectronics también licenciaron el diseño básico del ARM.

El diseño del ARM se ha convertido en uno de los más usados del mundo, desde discos duros hasta juguetes. Hoy en día, cerca del 75% de los procesadores de 32 bits poseen este chip en su núcleo.

El procesador incluido el la placa de desarrollo LN2410SBC es el modelo ARM 920T, pertenece a la familia ARM9TDMI y tiene una caché de 16KB/16KB y MMU, junto con una velocidad de proceso de 200MIPS


2.2.2 Características ARM 920T En primer lugar es necesario ubicarnos en el procesador de la placa, un

Samsung S3c2410 con núcleo ARM 920T de la familia ARM9TDMI[2]. El ARM 920T es un procesador integrado RISC de 32 bits de alto

rendimiento para sistemas abiertos que requieren una administración de memoria virtual completa junto con una sofisticada protección de memoria.

Construido sobre la base del núcleo del robusto procesador ARM9TDMI, la familia ARM9 trabaja hasta 250MHz sobre una tecnología de 0,13 µgm, incorporando el juego de instrucciones de 16 bits Thumb, que mejora la densidad de código hasta un 40%.

Tiene un alto rendimiento lo que permite integrar mayores funcionalidades en aplicaciones de reducido coste, complejidad i consumo energético.

Una mejorada versión de la implementación de la MMU de la arquitectura ARM permite la traducción y control de acceso para instrucciones y direcciones de datos.

El código binario generado para este procesador es 100% con el núcleo ARM7TDMI y con la familia ARM7 Thumb y los procesadores StrongARM, facilitando la tarea de los diseñadores para escoger entre una amplia gama de procesadores desde 60 a más de 200 MiPS.

Para reducir el efecto del ancho de banda de la memoria y la latencia en el rendimiento utiliza caché de datos e instrucciones, MMU, TLBs y buffer de escritura y direcciones físicas TAG RAM.

Actualmente la arquitectura ARM se usa en aplicaciones basadas en sistemas operativos como Windows CE, EPOC, Linux y QNX, así como en más de 40 sistemas operativos de tiempo real, aplicaciones inalámbricas de alto rendimiento como SmartPhones o PDAs, codificación de audio y video, soluciones de control para automóviles, etc.

Sus características más destacadas son:

• Procesador RISC de 32 bits con juego de instrucciones Thumb. • Dos caches de 16KB, una para datos y otra para instrucciones,

cada una conectada por un bus de 32 bits al núcleo del ARM9TDMI permitiendo decodificar una instrucción al mismo tiempo que hacemos un acceso a memoria.

• Bloqueo de caché que permite a secuencias de código críticas bloquearse dentro de la caché para asegurar la previsibilidad en tiempo real. El algoritmo de reemplazamiento lo selecciona el operativo y puede ser tanto pseudo aleatorio como round-robin.

• Buffer de escritura de 16 entradas para prevenir paradas del procesador al escribir en memorias externas.

• Uso de memoria PATAG RAM permitiendo guardar las direcciones físicas retenidas en la caché de datos eliminando la traducción de direcciones cuando el procesador las necesita.


• Unidad de gestión de memoria (MMU Memory Management Unit ). Permite múltiples tamaños de secciones de mapeo de memoria, permiso de acceso por secciones, 2 TLBs de 64 posiciones, uno para datos y otro para instrucciones y un algoritmo de reemplazamiento cíclico ( round-robin )

• Controlador del sistema, que gestiona las peticiones entre las instrucciones y el acceso a datos dando prioridad a un recurso o permitiendo que la ejecución continúe.

• Llevable a tecnologías de integración de silicio de 0.18 µgm, 0.15 µgm y 0.13 µgm.

• El diseño del procesador permite ajustar dinámicamente su velocidad, incluso pararlo, para adaptarse a las necesidades inmediatas de procesamiento.

• El bus del sistema i la memoria externa también pueden adaptarse a una velocidad menor que l procesador para reducir el consumo de memoria.

• Sistema de interrupciones de baja latencia i soporte para memoria virtual.

Figura 2.2: ARM: Visión del núcleo del procesador ARM920T


2.3 Dispositivos I/O

2.3.1 Introducción La placa de desarrollo LN2410SBC consta de una serie de periféricos I/O

como son el puerto USB, Ethernet, RS232, junto con dos ranuras para tarjetas, uno para MMC/SD y otra para CF. Además también incorpora un puerto IDE para conexión HDD/CDROM y una pantalla táctil para interactuar con el usuario.

También es importante la adición de un puerto JTAG para tener un acceso completo a la memoria del dispositivo.

2.3.2 USB El Universal Serial Bus (bus universal en serie)[3] es un puerto que sirve

para conectar periféricos a una computadora. Fue creado en 1996 por siete empresas: IBM, Intel, Northern Telecom, Compaq, Microsoft, Digital Equipment Corporation y NEC. El estándar incluye la transmisión de energía eléctrica al dispositivo conectado. Algunos dispositivos requieren una potencia mínima, así que se pueden conectar varios sin necesitar fuentes de alimentación extra. La gran mayoría de los concentradores incluyen fuentes de alimentación que brindan energía a los dispositivos conectados a ellos, pero algunos dispositivos consumen tanta energía que necesitan su propia fuente de alimentación. Los concentradores con fuente de alimentación pueden proporcionarle corriente eléctrica a otros dispositivos sin quitarle corriente al resto de la conexión (dentro de ciertos límites).

El diseño del USB tenía en mente eliminar la necesidad de adquirir tarjetas separadas para poner en los puertos bus ISA o PCI, y mejorar las capacidades plug-and-play permitiendo a esos dispositivos ser conectados o desconectados al sistema sin necesidad de reiniciar. Cuando se conecta un nuevo dispositivo, el servidor lo enumera y agrega el software necesario para que pueda funcionar.

El USB puede conectar los periféricos como ratones, teclados, escáneres, cámaras digitales, teléfonos móviles, reproductores multimedia, impresoras, discos duros externos, tarjetas de sonido, sistemas de adquisición de datos y componentes de red. Para dispositivos multimedia como escáneres y cámaras digitales, el USB se ha convertido en el método estándar de conexión. Para impresoras, el USB ha crecido tanto en popularidad que ha desplazado a un segundo plano a los puertos paralelos porque el USB hace mucho más sencillo el poder agregar más de una impresora a una computadora personal.

La placa de desarrollo LN2410 cuenta con dos puertos USB, uno de tipo Host y otro de tipo Device. El puerto de tipo Host será en el que conectemos cualquier dispositivo USB que queramos, como por ejemplo una pastilla Bluetooth. El puerto de tipo Device es el que al conectarlo a otro equipo


identificará a la placa como “Placa de desarrollo LN2410”. Este tipo de conexiones tipo Device son especialmente útiles para conectar la placa a un entorno de desarrollo de alto nivel, como, por ejemplo, Visual Studio, desde donde podremos crear nuestra aplicación en cualquier lenguaje de programación y hacer un deploy o desplegarla en la placa a través de un cable USB, pudiendo debugar la aplicación desde nuestra estación de desarrollo.

Figura 2.4: USB tipo Device Figura 2.5: USB tipo Host

2.3.3 Ethernet El puerto Ethernet está gobernado por el chip CS8900A de Cirrus Logic[4],

también conocido como Crystal LAN, su diseño extremadamente integrado elimina la necesidad de otros aparatosos componentes.

Incluye una memoria RAM, filtro para recibir y enviar en 10BASET y una interfaz BUS-ISA directa.

Sus características más destacadas son:

• Consumo mínimo de tan solo 55mA, pudiendo trabajar si fuera necesario a 3V.

• Arquitectura PacketPage capaz de adaptarse a los cambios del tráfico de la red y a los recursos del sistema disponibles aumentando la eficacia del mismo.

• Funcionamiento en modo Full-Dúplex. • Puerto 10BASET con filtros analógicos que permiten detectar y

corregir la polaridad automáticamente. • Características de transmisión programables, como la retransmisión

automática al darse colisión o la generación automática de CRC o padding.

• Características de recepción programables, como Stream Transfer™ que evita sobrecarga de la CPU, cambio automático entre memoria del chip y la DMA, rechazo automático de los paquetes erróneos o interrupciones tempranas para el preproceso de tramas.

• Soporta EEPROM para auto-configuraciones. • Boot PROM, para arrancar desde sistemas sin disco.


Gracias a su puerto Ethernet, la placa LN2410 expande sus posibilidades adquiridas con su puerto USB, dotándola de un gran interconectividad entre sistemas.

Figura 2.6: Puerto Ethernet

2.3.4 RS232 También conocido como Electronic Industries Alliance RS-232C[5], es una

interfaz que designa una norma para el intercambio serie de datos binarios entre un DTE (Data Terminal Equipment, Equipo terminal de datos, en nuestro caso la placa de desarrollo LN2410) y un DCE (Data Communication Equipment, Equipo de Comunicación de datos, en nuestro caso el PC de desarrollo), aunque existen otras situaciones en las que también se utiliza la interfaz RS-232.

Para gestionar esta comunicación es necesario de una UART, diseñadas para convertir las señales que maneja la CPU y transmitirlas al exterior. La UART debe resolver problemas tales como la conversión de voltajes internos del DCE con respecto al DTE, gobernar las señales de control, y realizar la transformación desde el bus de datos de señales en paralelo a serie y viceversa.

Debe ser robusta y deberá tolerar circuitos abiertos, cortocircuitos y escritura simultánea sobre un mismo pin, entre otras consideraciones.

Cabe destacar que la placa incorpora una UART de tres canales de los que uno se dedica íntegramente al control del puerto RS232 y los otros dos quedan relegados al puerto de expansión J6, normalmente dedicado al control y gestión de la pantalla táctil.

Además es necesario la utilización de un cable null-modem, en donde tenemos cruzadas las líneas de recepción y de transmisión, DE-9 (9 pines), para que la comunicación sea efectiva.

Esta comunicación es necesaria para poder interactuar con la placa en las primeras fases de la instalación, para debugar más adelante o para comunicarnos con otros dispositivos.

Figura 2.7: Puerto RS232


2.3.5 Ranuras para tarjetas MMC/SD y CF Mediante las dos ranuras para tarjetas, uno para MMC/SD y otro para CF,

disponemos de una gran variedad de aplicaciones. La ranura MMC/SD la utilizaremos principalmente como lector de

dispositivos de memoria. La tarjeta MMC[6] es un estándar de tarjeta de memoria flash. Prácticamente igual a la SD, carece de la pestaña de seguridad que evita sobrescribir la información grabada en ella. Su forma está inspirada en el aspecto de los antiguos disquetes de 3'5 pulgadas. Actualmente ofrece una capacidad máxima de 4GB.

Presentada en 1997 por Siemens AG y SanDisk, se basa en la memoria flash de Toshiba base NAND, y por ello es más pequeña que sistemas anteriores basados en memorias flash de Intel base NOR, tal como la CompactFlash. MMC tiene el tamaño de un sello de correos: 24 mm x 32 mm x 1,4 mm. Originalmente usaba un interfaz serie de 1-bit, pero versiones recientes de la especificación permite transferencias de 4 o a veces incluso 8 bits de una vez. Han sido más o menos suplantadas por las Secure Digital (SD), pero siguen teniendo un uso importante porque las MMCs pueden usarse en la mayoría de aparatos que soportan tarjetas SD (son prácticamente iguales), pudiendo retirarse fácilmente para leerse en un PC.

Las MMCs están actualmente disponibles en tamaños de hasta 4GB con modelos de 8GB anunciados, aún no disponibles. Se usan en casi cualquier contexto donde se usen tarjetas de memoria, como teléfonos móviles, reproductores de audio digital, cámaras digitales y PDAs. Desde la introducción de la tarjeta Secure Digital y la ranura SDIO (Secure Digital Input/Output), pocas compañías fabrican ranuras MMC en sus dispositivos, pero las MMCs, ligeramente más delgadas y de pines compatibles, pueden usarse en casi cualquier dispositivo que soporte tarjetas SD si lo hace su software/firmware.

La otra ranura es de tipo CF[7], fue originalmente un tipo de dispositivo de almacenamiento de datos, usado en dispositivos electrónicos portátiles. Como dispositivo de almacenamiento, suele usar memoria flash en una carcasa estándar, y fue especificado y producido por primera vez por SanDisk Corporation en 1994. El formato físico sirve ahora para una gran variedad de dispositivos.

Principalmente hay dos tipos de tarjetas CF, el Tipo I y el Tipo II, ligeramente más grueso. Para nuestros propósitos con la placa de desarrollo LN2410 sólo podemos disponer de tarjetas CF Tipo I.

CF estaba entre los primeros estándares de memoria flash para competir con las anteriores, y de un tamaño mayor, tarjetas de memoria PC Card Tipo I, y se fabricó originalmente a partir de memorias flash basadas en NOR de Intel, aunque finalmente se pasó a usar NAND. Se ha beneficiado de tener tanto un buen coste en relación a la capacidad de la memoria comparado con otros formatos.

La memoria flash basada en NOR tiene una densidad menor que la de los sistemas más recientes basados en NAND, CompactFlash es, por consiguiente,


el más grande de los tres formatos de tarjetas de memoria que aparecieron a principios de los años 90, siendo las otras dos la Miniature Card (MiniCard) y SSDFC (SmartMedia). Sin embargo, CF pasó a utilizar más tarde una memoria de tipo NAND. Además, el formato de IBM MicroDrive que usaba CF de Tipo II no era una memoria semiconductora.

CompactFlash define una interfaz física que es más pequeña que la interfaz PCMCIA-ATA, pero eléctricamente idéntica. Es decir, aparece para el dispositivo host como si fuera un disco duro de un tamaño definido y tiene un diminuto controlador IDE integrado en el mismo dispositivo CF. Desafortunadamente, el modelo de placa de desarrollo LN2410 en su versión actual (v1.6) no dispone de compatibilidad para esta característica.

El conector mide de ancho unos 43 mm y la carcasa tiene 36 mm de profundidad y está disponible en dos grosores diferentes, CF (3,3 mm) y CF II (5 mm). Sin embargo, ambos tipos son idénticos. Las tarjetas CF I pueden ser usadas en las ranuras para CF II, pero las tarjetas CF II son demasiado gruesas para poder encajar en las ranuras para CF I. Las tarjetas de memoria son habitualmente del tipo CF I.

Las tarjetas CF son mucho más compactas que las tarjetas de memoria PC Card (PCMCIA) de Tipo I, excepto por su grosor, que es el mismo que las tarjetas PC Card Tipo I y Tipo II respectivamente. CF ha logrado ser el más exitoso de los primeros formatos de tarjetas de memoria, sobreviviendo tanto a la Miniature Card, como a la SmartMedia y PC Card Tipo I. SmartMedia supuso una competencia dura para CF en dispositivos más pequeños, y fue más popular que CF en términos de penetración en el mercado, pero SmartMedia le cedería esta área a tipos de tarjetas más nuevos (durante el escaso período 2002-2005).

Los formatos de tarjetas de memoria que aparecieron a finales de los años 90 y a principios de la siguiente década (SD/MMC, varios formatos de Memory Stick, xD-Picture Card, etc.) supusieron una dura competencia. Los nuevos formatos, más pequeños, tenían un tamaño de una fracción del tamaño de CF, y en algunos casos incluso más pequeños de los que CF había sido respecto a PC Card. Estos nuevos formatos dominarían las PDAs, teléfonos móviles, y cámaras digitales (especialmente los modelos más compactos).

El formato CompactFlash sirve también para varios dispositivos de entrada/salida y de interfaz. Dado que es eléctricamente idéntico a PC Card, muchas PC Cards tienen equivalentes CF.

Algunos ejemplos incluyen:

• Adaptador de pantalla Super VGA • Cámara digital • GPS • Escáner de código de barras • Tarjeta Ethernet • Lector de bandas magnéticas • Lectores para otros dispositivos Flash • Módem


• Wi-Fi

Gracias a esta opción volvemos a dejar constancia de la gran variedad de uso y opciones de expansión de las que dispone la placa de desarrollo LN2410.

2.3.6 Conector IDE para HDD/CDROM Gracias al puerto J4 tenemos la posibilidad de acoplar un dispositivo IDE

como puede ser un disco duro, tal y como los que hoy conocemos de hasta 300 GB, o un CDROM o DVDROM, grabadoras, etc.

Este puerto es el mismo que también gestiona la pantalla táctil, de la misma manera que pasa con el puerto J6 y es posible gracias a la utilización del chip XC9536XL de Xilinx [8], que no es más que un CPLD.

Los CPLD extienden el concepto de un PLD (Programmable Logic Device) a un mayor nivel de integración, permiten implementar sistemas más eficaces, ya que utilizan menor espacio, mejoran la fiabilidad del diseño, y reducen costos. Un CPLD se forma con múltiples bloques lógicos, cada uno similar a un PLD. Los bloques lógicos se comunican entre sí utilizando una matriz programable de interconexiones, lo cual hace más eficiente el uso del silicio, conduciendo a una mejor eficiencia a menor costo.

Gracias al diseño de nuestra placa somos capaces de controlar casi todas las señales involucradas en los procesos de escritura y lectura del procesador y de los periféricos que gestiona, todos estos parámetros de configuración de los CPLD son inicializados en fábrica por lo que no debemos preocuparnos de nada.

2.3.7 Pantalla táctil LP35 La pantalla táctil LP35 está formada por el modelo LTV350QV-F04[9] con

módulo táctil de Samsung. Utiliza una matriz de color activa de tipo TFT (Thin Film Transistor) en la

que cada píxel tiene su propio transistor dedicado, que permitirá a cada línea de la columna acceder a un píxel.

Cuando una línea de fila está activada, todas las líneas de la columna están conectadas a una fila de píxeles y una correcta tensión de alimentación es impulsada a todas las líneas de la columna. Cuando la línea de fila se desactiva, la siguiente línea de fila es activada. Todas las líneas de la fila se activan secuencialmente durante una operación de actualización. La matriz activa está dirigida a dispositivos con un mayor brillo y tamaño que a los que se dirige la matriz pasiva (dirigida a dispositivos de pequeño tamaño, y, en general, que tienen tiempos de respuesta más rápidos, produciendo imágenes mucho mejores).


Además trabaja en modo TN, twisted nematic, donde las direcciones de alineación de la superficie de los dos electrodos son perpendiculares entre sí, y así se organizan las moléculas en una estructura helicoidal, o retorcida. Cuando no se aplica voltaje a una celda de cristal líquido TN, la luz se polariza para pasar a través de la célula. En proporción a la tensión aplicada, las células del cristal líquido giran hasta 90 grados cambiando la polarización y bloqueando el camino de la luz.

Incluye un circuito controlador y una luz trasera para iluminar todo el sistema, dando una calidad de imagen muy buena y nítida.

Tiene una pantalla de 3,5” con una resolución de 320x240 píxel pudiendo generar un total de 16.7 millones de colores gracias a su interfície RGB de 24 bits.

Es capaz de trabajar en modo DE (Data Enable) o SYNC (VSync, Hsync) para sincronizar la pantalla.

El módulo de reconocimiento táctil viene integrado en este modelo y es de tipo resistivo formada por varias capas.

Las más importantes son dos finas capas de material conductor entre las cuales hay una pequeña separación. Cuando algún objeto toca la superficie de la capa exterior, las dos capas conductoras entran en contacto en un punto concreto. De esta forma se produce un cambio en la corriente eléctrica que permite a un controlador calcular la posición del punto en el que se ha tocado la pantalla midiendo la resistencia.

Figura 2.8: Pantalla táctil Samsung LP35


2.3.8 Puerto JTAG JTAG, un acrónimo para Joint Test Action Group[10], es el nombre común

utilizado para la norma IEEE 1149.1 titulada Standard Test Access Port and Boundary-Scan Architecture para acceso a puertos de testeo, utilizada para testear circuitos impresos utilizando escaneo de límites.

JTAG se estandarizó en 1990 como la norma IEEE 1149.1-1990. En 1994 se agregó un suplemento que contiene una descripción del boundary scan description language (BSDL). Desde entonces, esta norma fue adoptada por las compañías electrónicas de todo el mundo. Actualmente, Boundary scan y JTAG son sinónimos.

Diseñado originalmente para circuitos impresos, actualmente es utilizado para la prueba de submódulos de circuitos integrados, y es muy útil también como mecanismo para depuración de aplicaciones empotradas, puesto que provee una puerta trasera hacia dentro del sistema. Cuando se utiliza como herramienta de depuración, un emulador en circuito que usa JTAG como mecanismo de transporte permite al programador acceder al módulo de depuración que se encuentra integrado dentro de la CPU.

En la placa de desarrollo LN2410 este puerto es extremadamente útil para tener un acceso completo y directo a toda la memoria. Podremos escribir, leer y visualizar el contenido de la memoria con un sencillo programa y un pequeño módulo de hardware.

A través del puerto JTAG será cuando interactuemos por primera vez con todo el núcleo interno de la placa LN2410 de una manera muy elemental. Tan sólo seremos capaces, en un primer momento, de acceder a la memoria para cargar las instrucciones más básicas para inicializar todo el sistema y poder empezar a cargar instrucciones más complejas que nos llevarán a pequeño entorno desde el que podremos interactuar con ella.

2.4 Memoria

2.4.1 Introducción La placa LN2410 consta de dos tipos de memorias claramente

diferenciadas. Memoria de tipo flash, separada en dos módulos. Uno de 2MB, tipo NOR y

otro de 32MB, tipo NAND. Memoria de tipo SDRAM, en un único módulo de 64MB cuya principal

aplicación es dar memoria para los procesos en ejecución.


2.4.2 Memoria Flash La memoria flash es una forma evolucionada de la memoria EEPROM

permitiendo que múltiples posiciones de memoria sean escritas o borradas en una misma operación a través de impulsos eléctricos, al contrario de las anteriores que sólo podían escribir o borrar una única celda de cada vez. Por este motivo, las memorias flash permiten trabajar a más alta velocidad que sus predecesoras, cuando los sistemas utilizan lectura y escritura en diversos puntos de la memoria al mismo tiempo.

Nuestra placa consta de dos módulos de memoria flash:

• Memoria NOR: 2MB, chip Am29LV160D de AMD. • Memoria NAND: 32MB, chip K9F5608 de Samsung.

A continuación describimos las características generales de las memorias flash y explicamos los dos tipos con sus ventajas e inconvenientes.

2.4.2.1 Características generales Las memorias flash son de tipo no volátil, esto significa que la información

guardada no se pierde cuando desconectamos de la red eléctrica. El principal uso de estas memorias son pequeños dispositivos basados en

el uso de baterías como teléfonos móviles, PDA, etc. Nuestra placa LN2410 incorpora dos memorias flash: una NAND y otra NOR.

Es importante remarcar que las memorias flash permiten un número finito y limitado de escrituras y borrados, generalmente entre 100.000 y un millón, dependiendo de la celda, la precisión del proceso de fabricación y del voltaje necesario para su borrado.

Estos dos tipos de memorias deben su nombre al tipo de puertas lógicas con los que están fabricados, NOR y NAND, para almacenar los 1’s y 0’s correspondientes, de la misma manera que las memorias CompactFlash (CF) comentadas anteriormente.

Los sistemas de ficheros para estas memorias están en pleno desarrollo aunque ya hay algunos funcionando como JFFS originalmente diseñado para trabajar sobre NOR y que ha evolucionado a JFFS2 para soportar también NAND, YAFFS para NAND, CRAMFS sobre NAND aunque es de sólo lectura ocupa muy poco ya que esta comprimido.

Por supuesto también se utilizan sistemas de ficheros tipo FAT para compatibilidad.


2.4.2.2 Funcionamiento La memoria flash como es de tipo EEPROM[11], contiene una array de

celdas junto con un transistor evolucionado con dos puertas en cada intersección. Tradicionalmente sólo almacenaba un bit de información. Las nuevas memorias flash, llamadas también dispositivos de celdas multinivel, pueden almacenar más de un único bit por celda variando el número de electrones que almacena.

Estas memorias están basadas en los transistores FAMOS (Floating Gate Avalanche-Injection Metal Oxide Semiconductor).

Memorias flash de tipo NOR

Las memorias flash de tipo NOR son utilizadas tradicionalmente para almacenar pequeñas cantidades de código ejecutable para dispositivos empotrados como PDAs y teléfonos móviles. Las memorias NOR son muy apropiadas para almacenar código porque son fiables, rápida lectura de las operaciones y acceso aleatoria a la memoria. Por la sencilla razón de que el código se puede ejecutar directamente en el mismo sitio, NOR es ideal para almacenar firmware, código de arranque (boot), sistemas operativos y cualquier otro dato que cambie poco frecuentemente.

Cabe destacar que las memorias flash están divididas en bloques (también llamadas sectores) y por tanto, cuando borramos lo que hacemos es limpiar bloques enteros de datos para agilizar, ja que es la parte más lenta del proceso. Por esta razón las memorias flash son tan rápidas, porque borran byte a byte.

El problema está en el momento que queremos escribir, antes de escribir debemos borrar todo el bloque para reescribir su contenido después.

Memorias flash de tipo NAND

Las memorias flash basadas en puertas lógicas NAND funcionan de forma ligeramente diferente: usan un túnel de inyección para la escritura y para el borrado un túnel de ‘soltado’. Las memorias basadas en NAND tienen, además de la evidente base en otro tipo de puertas, un coste bastante inferior, unas diez veces de más resistencia a las operaciones pero sólo permiten acceso secuencial (más orientado a dispositivos de almacenamiento masivo), frente a las memorias flash basadas en NOR que permiten lectura de acceso aleatorio. Sin embargo, han sido las NAND las que han permitido la expansión de este tipo de memoria, ya que el mecanismo de borrado es más sencillo (aunque también se borre por bloques) lo que ha proporcionado una base más rentable para la creación de dispositivos de tipo tarjeta de memoria.


Comparación de memorias flash basadas en NOR y NAND

Seguidamente compararemos algunos de los aspectos fundamentales de estos dos tipos de memorias flash. El primer aspecto a destacar es que al densidad de almacenaje de los chips es, actualmente, bastante más grande en las memorias NAND y que el coste de las memorias NOR es mucho más grande.

El acceso a la memoria NOR es aleatorio y orientado a bloques para modificarlo. En cambio, NAND ofrece sólo acceso directo para los bloques y lectura secuencial dentro de los mismos. En la escritura NOR podemos llegar a modificar un único bit. Esto destaca la limitada reprogramación de las NAND que deben modificar bloques o palabras completas. La velocidad de lectura es mucho más rápida en NOR (50 – 100 ns) frente a las NAND (10 µs de búsqueda de la página + 50 ns por byte).

La velocidad de escritura de la NOR es de 5 µs por cada byte mientras que en la NAND necesitamos 200 µs por página. La velocidad de borrado para la NOR es de 1s por cada bloque de 64KB mientras que en la NAND tardamos 2ms por cada bloque de 16KB.

La fiabilidad de dispositivos basados en NOR es realmente muy alta, prácticamente inmune a la corrupción de datos y tampoco tiene existencia de bloques erróneos frente a la escasa fiabilidad de los sistemas NAND que requieren de corrección de datos y donde existe la posibilidad que queden bloques marcados como erróneos e inservibles.

En resumen, los sistemas basados en NAND son bastante más económicos y rápidos pero tienen una falta de fiabilidad que los hacen poco eficientes, lo que demuestra la necesidad de un buen sistema de ficheros.

En este punto, diseñar un sistema de archivos eficiente para las memorias flash se ha convertido en proceso arduo y complejo, ya que, aunque ambos (NOR y NAND) son tipos de memoria flash, tienen características muy diferentes entre sí a la hora de acceder a esos datos. Esto es porque un sistema de ficheros que trabaje con memorias de tipo NOR incorpora varios mecanismos innecesarios para NAND y, a su vez, NAND requiere mecanismos adicionales, innecesarios para gestionar la memoria de tipo NOR.

Un ejemplo podría ser un recolector de basura. Esta herramienta está condicionada por el rendimiento de las funciones de borrado que, en el caso de NOR es muy lento y, además, un recolector de basura NOR requiere una complejidad relativa bastante alta y limita las opciones de diseño del sistema de archivos. Comparándolo con los sistemas NAND, que borran mucho más rápidamente, estas limitaciones no tienen sentido.

Otra de las grandes diferencias entre estos sistemas es el uso de bloques erróneos que pueden existir en NAND pero no tienen sentido en los sistemas NOR que garantizan la integridad. El tamaño que deben manejar unos y otros sistemas también difiere sensiblemente y por lo tanto es otro factor a tener en cuenta.


2.4.3 Memoria SDRAM La memoria SDRAM pertenece al tipo de memoria RAM. Son memorias

"de acceso aleatorio" o "de acceso directo" porque los diferentes accesos son independientes entre sí (no obstante, el resto de memorias ROM, ROM borrables y Flash, también son de acceso aleatorio). Esto hace que cuando necesitemos un dato el tiempo de búsqueda y acceso al dato sea extremadamente bajo, lo que las hace ideales para emplearlas como almacenamiento temporal donde el computador guarda los datos que esta utilizando en el momento presente.

El único problema es que se trata de una memoria de tipo volátil, es decir, que se borra cuando apagamos el ordenador, aunque también hay memorias RAM no volátiles (como por ejemplo las memorias de tipo flash).

En concreto, nuestra placa de desarrollo LN2410 utiliza una memoria RAM tipo SDRAM. La memoria SDRAM (Synchronous Dynamic RAM) es una memoria RAM electrónica construida mediante condensadores. Los condensadores son capaces de almacenar un bit de información almacenando una carga eléctrica. Lamentablemente los condensadores sufren de fugas lo que hace que la memoria SDRAM necesite refrescarse cada cierto tiempo: el refresco de una memoria RAM consiste en recargar los condensadores que tienen almacenado un uno para evitar que la información se pierda por culpa de las fugas (de ahí lo de Dynamic). La memoria SDRAM es la más utilizada comúnmente como memoria principal. Al ser síncrona mantiene la misma velocidad que el bus del sistema haciendo que el flujo de datos sea constante.

El modelo utilizado es el K4S561632H-T(U)C/L75 de Samsung, organizada en 2 chips de 32MB, dando un total de 64MB. Su frecuencia máxima de trabajo es de 133MHz con un CAS Latency de 3. Su periodo de refresco es de 64ms y un tiempo de acceso mínimo de 7,5 ns.

22

Capítulo 3 Entorno de trabajo

3.1 Plataforma de desarrollo ARM es una arquitectura hardware propia diferente de las que estamos

acostumbrados a trabajar como son PC’s o MAC’s, todos ellos con procesadores cuya arquitectura es Intel, AMD, PPC (aunque actualmente también están basados en procesadores Intel), por tanto incompatibles con los procesadores ARM, ya que usan juegos de instrucciones diferentes.

Debido a esto es necesario disponer de una plataforma accesible a nuestros propósitos, como Intel o AMD, llamada también host, desde la que desarrollaremos nuestras aplicaciones con el juego instrucciones de ARM. Esto lo haremos con un proceso que se denomina cross compiling o compilación cruzada usando un compilador que se ejecuta en nuestro equipo pero genera código fuente para ARM.

Este proceso dificulta sobremanera todo el proceso de instalación, modificación y compilación del kernel, ya que estamos sujetos a múltiples variables, como pueden ser la versión del compilador, de las librerías, de si el sistema operativo host soporte o no algunas de las opciones de desarrollo, etc.

Obviamente cualquier aplicación desarrollada para funcionar sobre la placa LN2410 también deberá ser compilada con el compilador cruzado y cualquier librería o módulo extra que utilice, como las librerías que controlan el subsistema Bluetooth, también.

Por ello, nuestro equipo host consta de dos partes diferenciadas. Un sistema Windows XP como base para las comunicaciones a través del puerto


serie RS232 mediante el programa Hyperterminal, para tareas de lectura y escritura sobre la memoria NOR y más adelante, tareas de compilación y descarga del sistema operativo Windows CE, y un sistema operativo Linux, basado en una distribución Ubuntu 8.04.1 virtualizado a través del software WMware, de distribución gratuita.

Así, todas las tareas de compilación cruzada, tanto para generar el kernel del sistema Linux embedded como para compilar las aplicaciones que necesitemos o para crear y descargar el sistema de ficheros, utilizaremos esta distribución de Linux basada en Ubuntu.

Cada vez que sea necesario el intercambio de ficheros entre las dos plataformas utilizaremos una carpeta compartida por Windows a la que tendremos acceso desde Linux gracias a las funciones de adaptadores de red virtuales incluidas en WMware.

El equipo resultante es una única plataforma hardware que dispone en tiempo real de todas las funciones que podemos necesitar, tanto de un sistema operativo como de otro, formando un pilar básico para el desarrollo de aplicaciones y sistemas operativos para la placa LN2410.

Figura 3.1: Esquema de conexión del host a la placa LN2410

A continuación detallaremos como se realiza la instalación del bootstrap,

que es la configuración inicial de todo el hardware de nuestra placa de desarrollo LN2410 y, además, es imprescindible para instalar cualquier sistema operativo.


3.2 Bootstrap El bootstrap contiene todas las instrucciones de inicialización de nuestro

sistema. Por ello, deberemos colocarlo en el primer lugar en el que la placa LN2410

mire en busca de configuración, esto es, en la posición de memoria 0x0000 0000, que corresponde a la memoria Flash NOR, donde empezará a leer y ejecutar instrucciones y vectores de inicialización.

Recordamos que la memoria NOR no se borra aunque se produzca un corte de la alimentación como sucede con la memoria flash SDRAM, además es una memoria de alta fiabilidad y muy rápida, idónea para almacenar las partes más importantes de nuestro sistema, pero al mismo tiempo muy cara y por tanto, con una cantidad limitada de espacio, en nuestro caso de 2MB. Además está formada por bloques con lo que tenemos una cantidad de espacio forzada para cada caso. Por ejemplo, el primer bloque está en la dirección 0x0000 0000, pero aunque tan sólo escribamos 5 bytes, la siguiente dirección útil es la 0x0000 4000, esto es debido a que el tamaño del primer bloque es de 4000h.

Si miramos con detenimiento el mapa de memoria correspondiente veremos qué lugares emplearemos para qué procedimientos.

Figura 3.2: Mapa de memoria NOR en la placa LN2410


Aunque estamos adelantando acontecimientos, observamos que una parte

la memoria NOR también está dedicada a almacenar el bootloader, en nuestro caso Das U-boot bootloader, por su alta compatibilidad con entornos arm. También vemos el lugar que ocupará el núcleo de Linux en la memoria permanente.

Volviendo al bootstrap, necesitamos de alguna utilidad que nos permita un acceso directo a la memoria desde la estación de desarrollo. Esta utilidad se llama JFLASH.EXE, se comunica con la placa de desarrollo LN2410 gracias al puerto JTAG incorporado en la placa y con el ordenador host con el puerto paralelo gracias al cable JTAG-Paralelo.

Por último, para adaptarnos al lenguaje JTAG, utilizado por la placa para programar la memoria NOR, es necesario instalar un pequeño controlador para el puerto paralelo en el equipo host y así poder comunicarme completamente con la placa.

3.2.1 Instalación controlador JTAG en el puerto paralelo Primero de todo debemos copiar el fichero giveio.sys al directorio

C:\Windows\system32\drivers Seguidamente vamos al Panel de Control y hacemos clic en Agregar

Hardware.

Figura 3.3: JATG: Instalación del controlador giveio.sys

Pulsamos en Siguiente, esperamos un poco mientras nuestro sistema

detecta la inserción de nuevos elementos hardware, cuando haya terminado seleccionamos “Sí, ya he conectado el hardware” y hacemos clic en Siguiente.



En la siguiente pantalla iremos al final de la lista y seleccionaremos

“Agregar un nuevo dispositivo de hardware”, a continuación hacemos clic en siguiente.


Seleccionamos “Instalar el hardware seleccionándolo manualmente de una

lista (Avanzado)” y hacemos clic en Siguiente.



De toda la lista que se nos muestra seleccionamos “Puertos (COM & LPT)” y hacemos clic en Siguiente.


En la siguiente pantalla seleccionamos “Utilizar disco” y vamos al directorio

donde este el fichero giveio.sys y hacemos clic en Aceptar, confirmamos toda la operación haciendo clic en Siguiente.


Ahora instalará el controlador pero como no ha pasado la prueba del

logotipo de Windows generará unos cuantos avisos que deberemos obviar, hacemos clic en Siguiente.



Hacemos clic en Siguiente, Continuar y Siguiente hasta el final del

proceso.


Finalmente veremos como el controlador se ha instalado correctamente:



Es imprescindible configurar el modo de nuestro puerto paralelo como

ECP+EPP, en la BIOS de nuestro equipo ya que sino el programa para escribir sobre la memoria NOR no dará ningún problema y reconocerá correctamente el chip pero no servirá de nada ya que ningún dato será grabado en la memoria.

A continuación podremos ejecutar el programa JFLASH.EXE, suministrado por el fabricante para comunicarnos con la memoria NOR para descargar la secuencia de bootstrap.

3.2.2 Descarga del bootstrap a la memoria NOR Utilizaremos el programa suministrado por el fabricante. Este programa funciona sobre la línea de comandos de Windows y antes

de ejecutarlo deberemos revisar que todas las conexiones (puerto JTAG placa – puerto paralelo ordenador y cable de alimentación conectado) son correctas. En este punto la placa está alimentada, por lo que veremos algunos led’s encendidos y podremos proceder a la descarga del bootstrap

El programa necesita recibir por línea de comandos el nombre de la imagen binaria que contiene el bootstrap para descargarlo en memoria. Una vez ejecutado veremos que detecta correctamente la placa al mostrar “LN2410 is detected”,y que entre las opciones que se nos presentan deberemos marcar “1” para “NOR Prog”, ya que es la memoria NOR a la que queremos acceder, después seccionaremos el tipo de chip que es, el Am29lv160eb (2MB) y finalmente, el desplazamiento, que será 0x0 porque queremos escribir al principio de la memoria.

Como este programa funciona por línea de comandos, bastará con ir al directorio que contiene el ejecutable y el fichero bootstrap y escribir:

$ jflash /f:LN2410SBC_bootstrap_1.6.bin


Figura 3.12: JFLASH: Escritura en memoria NOR del bootstrap

Podemos ver, entre otros datos, como la memoria NOR se organiza,

efectivamente, en bloques y cómo, aunque tan sólo hemos escrito una imagen de tamaño 24D8h, el siguiente bloque disponible como opción es el 0x4000.

Como nuestro bootstrap tiene preconfigurado saltar a la posición 0x10000 después de inicializar parámetros, será ahí donde colocaremos el bootloader, U-boot, desde el que arrancaremos el núcleo del sistema operativo Linux 2.6.21.

31

Capítulo 4

Linux Embedded

4.1 El kernel, Linux 2.6.21 El kernel o núcleo, es el corazón de nuestro sistema operativo. Linux embedded[12] se refiere al uso del sistema operativo Linux en un

sistema embebido, como por ejemplo PDA's, teléfonos móviles, robots, enrutadores / servidores, dispositivos electrónicos y aplicaciones industriales con microcontroladores y microprocesadores.

En el pasado, el desarrollo de empotrados fue llevado a cabo en su mayoría utilizando código propietario escrito en ensamblador. Los desarrolladores debían escribir los controladores para los dispositivos de hardware y las interfícies desde cero.

El núcleo de Linux, combinado con un conjunto de algunas otras utilidades de Software Libre, puede ajustarse dentro del limitado espacio de hardware de los sistemas empotrados. Una instalación típica de un Linux empotrado ocupa en promedio 2 MB.

Existen otros sistemas operativos empotrados como el QNX, LynxOS, Windows CE, Windows NT Embedded, Palm OS.


Linux Empotrado tiene algunas ventajas en relación a otros sistemas

operativos empotrados, como pueden ser el Código abierto, pequeño (Windows CE ocupa 21 MB comparado con los 2 MB para Linux Empotrado), puede no tener costos por derechos, maduro y estable (Más de 10 años de edad y utilizado en muchos dispositivos) y con respaldado.

Nuestro sistema está basado en el núcleo 2.6.21 y modificado para trabajar sobre la placa de desarrollo LN2410.

4.1.1 Historia Linux hace su aparición a principios de la década de los noventa, era el

año 1991 y por aquel entonces un estudiante de informática de la Universidad de Helsinki, llamado Linus Torvalds empezó, -como una afición y sin poder imaginar a lo que llegaría este proyecto, a programar las primeras líneas de código de este sistema operativo al que llamaría más tarde Linux.

Este comienzo estuvo inspirado en MINIX, un pequeño sistema Unix desarrollado por Andy Tanenbaum. Las primeras discusiones sobre Linux fueron en el grupo de noticias comp.os.minix, en estas discusiones se hablaba sobre todo del desarrollo de un pequeño sistema Unix para usuarios de Minix que querían más.

El 25 de agosto de 1991, Linus Torvalds envió un mensaje al grupo de noticias confirmando que había sido capaz de crear un sistema operativo compatible para arquitecturas AT 386. Había conseguido compilar un bash y el compilador gcc. Él mismo reconocía que el sistema era muy limitado y que seguramente nunca funcionaria sobre ningún otro soporte que no fuera discos duros AT.

El 5 de octubre de 1991, Linus anuncio la primera versión "Oficial" de Linux, -versión 0.02. Con esta versión Linus pudo ejecutar Bash (GNU Bourne Again Shell) y gcc (El compilador GNU de C) pero no mucho más funcionaba. En este estado de desarrollo ni se pensaba en los términos soporte, documentación, distribución, etc.

Después de la versión 0.03, Linus salto en la numeración hasta la 0.10, más y más programadores a lo largo y ancho de Internet empezaron a trabajar en el proyecto y después de sucesivas revisiones, Linus incremento el número de versión hasta la 0.95 (Marzo 1992), la primera capaz de ejecutar el sistema X-Windows. Más de un año después (diciembre 1993) el núcleo del sistema estaba en la versión 0.99 y la versión 1.0.0 no llego hasta el 14 de marzo de 1994.

El 9 de Mayo 1996, Tux fue propuesto como mascota oficial de Linux. El 9 de junio de 1996 fue lanzada la serie 2.0.x, la 2.2.x no llegó hasta el

25 de enero de 1999 y la 2.4.x hasta el 4 de enero del 2001.


El 17 de diciembre del 2003 fue lanzada la serie actual del núcleo, la 2.6.x y el desarrollo de Linux sigue avanzando día a día con la meta de perfeccionar y mejorar el sistema.

Figura 4.1: Historia cronológica de Linux1

4.1.2 Características principales y diferencias con Linux 2.4 Actualmente Linux es un núcleo monolítico híbrido. Los controladores de

dispositivos y las extensiones del núcleo normalmente se ejecutan en un espacio privilegiado conocido como anillo 0, con acceso irrestricto al hardware, aunque algunos se ejecutan en espacio de usuario. A diferencia de los núcleos monolíticos tradicionales, los controladores de dispositivos y las extensiones al sistema operativo se pueden cargar y descargar fácilmente como módulos, mientras el sistema continúa funcionando sin interrupciones. También, a diferencia de los núcleos monolíticos tradicionales, los controladores pueden ser

1 Imagen extraída de http://www.aforce2.com/linux.php


prevolcados (detenidos momentáneamente por actividades más importantes) bajo ciertas condiciones. Esta habilidad fue agregada para gestionar correctamente interrupciones de hardware, y para mejorar el soporte de multiprocesamiento simétrico.

Linux admite multitarea real "preemptive" (en los modos de usuario y de núcleo), memoria virtual, bibliotecas compartidas, carga por demanda, manejo de memoria, la pila de TCP/IP e hilos múltiples.

A diferencia del núcleo 2.4, las rutinas del código del núcleo se pueden interrumpir en casi cualquier momento[13]. Esto reduce la latencia en los procesos que tengan alta prioridad y que además reemplaza el parche de la versión 2.4 que añadía esta funcionalidad pero a la vez también muchísimas llamadas al scheduler o planificador del núcleo. Esto implica que puede pasar casi cualquier cosa entre dos instrucciones, realmente multitarea y por tanto precaución a la hora de escribir controladores para dispositivos.

En la versión 2.4, el planificador analizaba cada proceso antes de asignarle un tiempo de ejecución, añadiendo una sobrecarga de proceso y de tiempo considerable. En la versión 2.6 el tiempo que asigna el planificador a cada proceso es constante, mira en la cola de procesos en ejecución, da tiempo al proceso para su ejecución, cuando termina su quantum lo añade a la cola de procesos expirados y la reordena en función de la prioridad de procesos, volviendo a empezar el ciclo hasta que la cola esté vacía.

Se han reconstruido las primitivas de sincronización:

• Mutex: esta función se asegura que un recurso compartido se use por sólo un proceso en cada momento. De esta manera evitamos el consumo de tiempo por esta llamada al sistema cuando el recurso compartido no está siendo usado y, por tanto, el proceso no necesita estar bloqueado.

• Exclusión mutua más rápida en el espacio de usuario: permite comprobar la disponibilidad de un recurso desde el espacio del usuario antes de hacer la llamada al sistema para bloquear el proceso. También permite a las aplicaciones priorizar el acceso a recursos compartidos entre procesos.

Se ha mejorado los subsistemas de entrada / salida y se ha reescrito el

planificador de E/S, asegurando que ningún proceso se queda pendiente por mucho tiempo.

Se puede compilar sin sistema de memoria virtual. Eliminando la sobrecarga en el manejo de páginas, siendo mucho más eficiente que eliminar la partición de intercambio o swap.

El núcleo 2.6 tiene soporte para acceso a memoria de manera no uniforme (NUMA) pensado para estaciones de alto rendimiento con múltiples procesadores con diferentes bancos de memoria conectados directamente a cada uno de ellos. El acceso a memoria es mucho más rápido si se hace a través del procesador local. Para todo este sistema se ha diseñado una nueva


API que es la misma que usa el planificador y por tanto permite ejecutar procesos en el mejor procesador.

Tiene soporte para tecnología Hyperthreading, que hace que el sistema crea que tiene dos procesadores aunque físicamente sólo tenga uno (únicamente implementado en Intel P4) permitiendo que, a diferencia del núcleo 2.4 que podría sobrecargar uno de los dos procesadores virtuales, el planificador sepa optimizar la carga entre los dos procesadores.

Incluye mejoras en cuanto escalabilidad, hasta 64GB de RAM en modo paginado sobre 32 bit en arquitecturas x86, aumento del número de grupos y usuarios, de 65000 a 4 billones y sistemas de ficheros hasta 16 TB.

Nuevo sistema de dispositivos (devices) con una nueva interfaz que referencia bus de dispositivos, subdispositivos e información de alimentación. Toda esta información está recogida en el nuevo punto de montaje del sistema /sys (que sustituye al antiguo /proc/sys). Además incorpora una mejor gestión de la energía y soporte para ACPI.

En el apartado de USB, incluye soporte para USB 2.0, tecnología USB On-The-GO y, además, podemos configurar nuestro sistema empotrado Linux como un USB Device, esto es, cuando lo conectemos a nuestro equipo host lo reconocerá como si un dispositivo USB más se tratara.

Se han reescrito los controladores IDE. Ahora podemos usar controladores IDE para discos duros o lectores CD/RW sin necesidad de añadir emulación SCSI. En cuanto al sistema de ficheros, la novedad es el soporte para particiones NTFS (lectura y escritura) aunque todavía está en fase experimental. Se ha mejorado el soporte para FAT12 que se usa comúnmente en reproductores multimedia con almacenamiento flash.

Además incluye soporte para pantallas táctiles y rotación de pantalla, extremadamente útil en entornos empotrados.

En cuanto a interconexión de redes, tenemos soporte para protocolos IPsec que dan seguridad criptográfica a nivel de red y son, por tanto, transparentes a las aplicaciones del usuario. Se ha incluido soporte para el sistema de ficheros en red NFS v4, además de un servidor NFS y soporte para CIFS (como extensión del SMB) con el que podemos trabajar desconectados trabajando sobre ficheros en caché local.

Algunas aplicaciones y características han sido eliminadas desde la versión 2.4 del núcleo como son, el servidor http incluido en el kernel, resolviendo todos los cuellos de botellas con Apache y otros y código antiguo.

Los sistemas empotrados como la placa de desarrollo LN2410 necesitan algo más que el sistema operativo para poder arrancar. Es imprescindible utilizar un sistema por capas, donde secuencialmente se van inicializando todos los parámetros, como son el bootstrap, bootloader, kernel.


Figura 4.2: Esquema por capas para carga de Linux

Para entender el proceso de carga del sistema operativo Linux, deberemos

tener una visión completa del mapa de memoria de la placa LN2410, ya que es necesario colocar las imágenes creadas en los lugares apropiados para ello porque, si no, sería imposible la carga del sistema operativo.

En la figura 4.2 puede verse el mapa de memoria de la placa LN2410. La memoria NOR, al ser la memoria de más fiabilidad es la que almacenará el código binario de la configuración del hardware de la placa, bootstrap, y el cargador de arranque, bootloader, al más puro estilo de un típico PC a los que estamos habituados.

Figura 4.3: Mapa de memoria en la placa LN2410


Podemos comprobar como están repartidos todos los periféricos que requieren de un acceso a memoria.

Como esta es una representación lógica de la memoria, no hay que perder de vista que cada segmento puede ser un periférico o hardware independiente como la memoria NOR, representada por un chip de memoria de 2MB tipo Am29LV160D de AMD, o la memoria SDRAM de 32MB tipo K9F5608 de Samsung, todos ellos con sus direcciones físicas correspondientes, necesarias para los accesos de lectura y escritura.

Este mapa de memoria es muy importante porque será el que determinará ciertos parámetros de configuración para el correcto funcionamiento del sistema operativo Linux. Veremos cómo los controladores de los lectores de tarjetas CompactFlash deben ser configurados para trabajar en las direcciones específicas reservadas para tal uso o si no, no funcionarían.

4.2 El Bootloader, Das U-Boot 1.1.1 El bootloader utilizado se llama Das U-Boot 1.1.1, está ampliamente

extendido en entornos empotrados y soporta una amplia variedad de placas. Das U-Boot es una herramienta open source diseñada para realizar el

arranque del sistema. Un cargador de arranque o bootloader es un sencillo programa (que no tiene todas las funcionalidades de un sistema operativo) diseñado exclusivamente para preparar todo lo que necesita el sistema operativo para funcionar.

El cargador de arranque, también llamado monitor de arranque, es una pequeña aplicación de software que se ejecuta justo después de inicializar la placa LN2410, recordemos la secuencia de arranque, bootstrap->bootloader->núcleo del sistema operativo.

En nuestros ordenadores personales nos pueden ser familiares algunos como GRUB o LILO, sobretodo en entornos Linux, los cuales residen en el master boot record (MBR) de nuestro disco duro. Después de que la BIOS inicialice algunos parámetros del sistema, ésta ejecuta el cargador de arranque que reside en el MBR. Este pasa la información del sistema al núcleo del sistema operativo y lo ejecuta. Por ejemplo, el cargador de arranque informa al núcleo de cual es la partición del disco duro que se tiene que montar como root.

En los sistemas empotrados las funciones del cargador de arranque son más complicadas porque carecen de una BIOS que realice la configuración inicial del sistema. El bajo nivel de inicialización de los microprocesadores, controladores de memoria y demás hardware específico varía entre placa y placa y de CPU a CPU. Esta inicialización se tiene que llevar a cabo antes que el núcleo sea ejecutado y, por tanto, no nos queda más remedio que compilar U-Boot específicamente para cada placa.


U-Boot tiene las siguientes características principales[14]:

• Tamaño pequeño: normalmente U-Boot se almacenará en memorias NOR (de tamaño pequeño por el coste económico respecto a las memorias NAND donde almacenaremos el sistema operativo y las aplicaciones),por tanto, consumir el mínimo tamaño es muy importante. U-Boot es capaz de incluir un intérprete de comandos interactivo básico, soporte para descargas a través de Ethernet y funciones para programar la memoria flash en tan solo 128 KB.

• Carga rápida: en los sistemas empotrados lo que más importa es la carga del sistema operativo y de sus aplicaciones lo más rápido posible, la carga del bootloader es un paso más en este proceso, consumiendo un tiempo mínimo. Para ello incluye una serie de prestaciones como activar la caché cuando sea posible, inicializar los periféricos (por ejemplo, Ethernet, RS232, USB o IDE) sólo cuando sea necesario y desactivarlos después de usarlos.

• Funciones útiles: es el encargado de la inicialización del controlador de memoria, proporciona los parámetros de arranque al núcleo, podemos leer y escribir en la memoria flash, descargar imágenes binarias a la memoria de la placa a través del puerto serie con el protocolo kermit, o utilizando el puerto Ethernet.

En definitiva, será el encargado de crear una pequeña capa de interacción

con el usuario por primera vez desde el proceso de configuración de la placa LN2410, conformando el punto de partida para acabar ejecutando aplicaciones de alto nivel.

4.2.1 Descarga del bootloader a la memoria NOR Como hemos hecho anteriormente con el bootstrap, cargaremos el

bootloader en la posición 0x10000 de la memoria NOR, posición a la que saltaremos después de cargar los vectores de inicialización del bootstrap.

Para ello utilizaremos el programa suministrado para este propósito y que ya conocemos, el JFLASH.EXE.

Observaremos algunas diferencias respecto a la carga del boostrap. La más evidente es que tarda, sustancialmente, bastante más. Esto es debido a que la imagen es más grande y que el proceso de carga a través del puerto paralelo mediante el adaptador JTAG es muy lento, aparte de ralentizar sobremanera el equipo host.

Los pasos a seguir son muy parecidos a la carga del boostrap, una vez ejecutado veremos que detecta correctamente la placa al mostrar “LN2410SBC < ID=0x0032409d> is detected”, y que entre las opciones que se nos presentan deberemos marcar “1” para “NOR Prog”, seleccionamos el tipo de


chip(Am29lv160eb (2MB)) y finalmente, el desplazamiento, que será 0x10000, lugar donde el bootstrap saltará después de configurar la placa. Tan sólo deberemos pasarle por la línea de comandos el nombre de la imagen del U-Boot que queramos cargar en memoria escribiendo la siguiente instrucción:

C:\LN2410> jflash /f:u-boot.bin

Figura 4.4: JFLASH: Escritura en memoria NOR del bootloader


Ahora ya tenemos instalado nuestro cargador de arranque o bootloader en

la placa de desarrollo LN2410, listo para empezar la configuración del sistema y la descarga del núcleo del sistema operativo. Para poder comunicarnos con esta primera capa de interacción tenemos que hacerlo a través de algún programa de comunicaciones vía serie. En nuestro caso hemos utilizado Hyperterminal, tanto por su integración dentro de Windows XP, como por su facilidad de uso.

4.2.2 Configuración del bootloader a través de Hyperterminal

Tal y como viene configurado de serie, para poder establecer una conexión

a través del puerto serie RS232 es necesario que nuestro programa Hyperterminal esté configurado para trabajar a 115200 baudios, 8 bits de datos, sin paridad, 1 bit de parada y sin control de flujo.

Esto lo haremos en la pantalla de conexión del Hyperterminal, después de dar un nombre a la conexión y de seleccionar el puerto serie en el que tenemos conectado el cable DB-9 NULL MODEM (otro modelo no funcionaria). Veremos una pantalla como la siguiente:

Figura 4.5: Hyperterminal: Configuración de conexión

Acto seguido, después de hacer un reset a la placa o apretar la tecla Intro

repetidas veces, veremos por primera vez el intérprete de comandos del U-Boot


con un mensaje de error debido a que no tiene ninguna variable de entorno y, por tanto, cargará los valores por defecto.

Figura 4.6: Hyperterminal: Primera ejecución U-Boot

A partir de este momento somos capaces de interactuar con nuestro

sistema de desarrollo LN2410. El cargador de arranque tiene multitud de funciones muy útiles que iremos detallando a medida que sean necesarias.

Como la descarga de imágenes binarias es mucho más rápida por el puerto Ethernet que por el puerto serie, nos centraremos en la primera, siendo necesario establecer algunos datos indispensables para la puesta en marcha de este puerto como son la dirección ip del adaptador, la máscara de subred y la ip del servidor TFTP que contiene las imágenes, que en nuestro caso será la ip del equipo host.

Esto lo haremos introduciendo las siguientes instrucciones en el intérprete de comandos de nuestro monitor de arranque:

LN2410SBC #setenv ipaddr 192.168.1.236 /*ip de la placa*/ LN2410SBC #setenv serverip 192.168.1.2 /*ip del servidor tftp*/ LN2410SBC #setenv netmask 255.255.255.0 /*máscara de subred*/ LN2410SBC #saveenv La última instrucción, saveenv[15], es la necesaria para guardar los valores

de las variables de entorno en la región de memoria NOR dedicada a ello. Es un


sector protegido contra escritura y que el propio sistema desbloqueará para escribir los nuevos datos, manteniéndolos siempre a buen resguardo.

Figura 4.7: Hyperterminal: Configuración variables de entorno Ethernet

A partir de este momento ya somos capaces de descargar el núcleo del

sistema operativo Linux a través del puerto Ethernet, mediante el uso del protocolo TFTP.

Recordamos que para poder utilizar el protocolo TFTP es necesario tener instalado en nuestro host un servidor TFTP. Para nuestro caso, hemos escogido el servidor gratuito TFTP de Solarwinds, ya que una de las premisas de este proyecto es utilizar, siempre que se pueda, software gratuito para evitar el uso de licencias. Este servidor TFTP es muy sencillo de utilizar y tiene las funciones necesarias para la descarga de imágenes.

Ahora veamos el proceso de creación, compilación, descarga y ejecución del núcleo del sistema operativo Linux.

4.3 Compilación cruzada del núcleo Para obtener un núcleo estable y correcto funcionando sobre la placa de

desarrollo LN2410 es necesario realizar una compilación cruzada, ya que el equipo host está basado en una arquitectura x86 y la placa en una ARM.


Es una tarea bastante compleja porque, dependiendo de qué compilador escojamos es posible que nuestro núcleo no funcione y, por supuesto, deberemos recompilar todas nuestras aplicaciones para trabajar con ese compilador.

Por tanto, lo primero que vamos a hacer es instalar nuestro compilador cruzado o crosscompiler.

4.3.1 Instalación del compilador cruzado o toolchain Para realizar la compilación cruzada del núcleo y de cualquier otra

aplicación que deseemos ejecutar en nuestra placa de desarrollo LN2410, utilizaremos un paquete bastante usado en entorno ARM y que da muy buenos resultados. Se trata de un toolchain, que no es más que un script del shell que se dedica a descargar los paquetes de software necesarios y los instala en nuestro sistema.

En nuestro caso este toolchain se denomina Crosstools 0.43, de Dan Kegel16], y lo personalizaremos para trabajar con gcc 3.4.3 y glibc 2.3.5, además de usar binutils 2.15, todo ello lo compilaremos para arquitectura ARM y finalmente obtendremos todos los compiladores y librerías, necesarias para compilar nuestras fuentes para ARM.

Desde nuestro máquina virtual con un Ubuntu instalado, accederemos a un terminal, nos logeamos como súper usuario y descargamos el toolchain.

Antes de empezar a compilar nada deberemos readaptar el bash del Ubuntu, ya que, de serie, trabaja con una versión llamada dash que no es del todo compatible con el toolchain y puede dar problemas en el momento de compilar con algunos detalles sobre cadenas.

Por tanto redireccionaremos el dash al bash, con la siguiente instrucción: $ sudo ln –sf bash /bin/sh Introducimos la contraseña del administrador y ya está. Ahora ya podemos descargarlo y descomprimirlo. $ wget http://kegel.com/crosstool/crosstool-0.42.tar.gz $ tar -xzvf crosstool-0.42.tar.gz $ cd crosstool-0.42


Figura 4.8: Descarga y descompresión de crosstools

Entramos en el directorio de trabajo con las fuentes descomprimidas, listas

para ser compiladas, y tan sólo deberemos hacer unos cuantos retoques en algunos fichero para adaptarlos a nuestra arquitectura ARM.

El primer fichero a editar es demo-arm.sh, para cambiar la línea de serie por la siguiente:

eval `cat arm.dat gcc-3.4.3-glibc-2.3.5.dat` sh all.sh –notest Cuidado con la comillas simples que son muy importantes, básicamente lo

que estamos haciendo es decirle al script que versiones del compilador queremos. Una vez editado guardamos y vamos a por el siguiente.

El próximo fichero es all.sh, donde comentaremos una parte del script que nos fuerza a salir si nos hemos autenticado como root en la línea 59.

#case $USER in #xroot) abort “Don´t run all.sh or crosstool.sh as root, it’s dangerous”;; #*) #esac Finalmente, editaremos el fichero arm.dat para especificar qué prefijo

usaremos para compilar, en nuestro caso, arm-linux. De esta manera, el compilador tradicional gcc pero para arquitectura ARM se llamará arm-linux-gcc.

TARGET=arm-linux Después de todo este proceso de configuración no nos queda más que

ejecutar el script que descargará el software necesario y lo irá compilando para que después lo podamos usar.

$ ./demo-arm.sh


Figura 4.9: Instalación de crosstools

El proceso de instalación es bastante arduo y complejo por lo que requiere

de un elevado tiempo, tanto por las descargas, como por las descompresiones y por todo el proceso de compilación sobre nuestra arquitectura.

Finalmente, dependiendo de la máquina, puede tardar más de una hora, veremos que todo se ha instalado correctamente y cómo el propio script verifica que es capaz de compilar un pequeño ejecutable tipo “Hola mundo”


Figura 4.10: Instalación de crosstools

No hay que olvidar que es importantísimo añadir la ruta que contiene los

ejecutables a la variable PATH del sistema ya que sino no podremos compilar para ARM porque no sabrá dónde se encuentran los binarios para dicho fin.

Por defecto, el compilador cruzado crosstools se instala en el directorio /opt/crosstool/gcc-3.4.3-glibc-2.3.5/arm-linux/ y será esta la ruta principal hacia los binarios (./bin) que necesitamos.

Por tanto, editaremos el fichero de variables de entorno, que en Ubuntu se encuentra en el directorio /etc/environment.

$ gedit /etc/environment


Figura 4.11: Añadimos la ruta al PATH del sistema

Ahora recargaremos las variables de entorno para hacer efectivas las

nuevas rutas. $ source /etc/environment Comprobamos que son correctas escribiendo arm-linux y tabulamos, así el

sistema nos dirá todos los binarios que empiezan por esas letras y que están incluidos en la variable de entorno PATH. También podemos verificar la ruta escribiendo echo $PATH para saber su valor.

Figura 4.12: Comprobamos que tenemos acceso a los binarios

A partir de este momento podemos compilar cualquier código para la

arquitectura ARM escribiendo el nombre del compilador con el prefijo arm-linux. Por ejemplo si quisiéramos compilar el programa hola_mundo.c para ARM bastaría con escribir:

$ arm-linux-gcc hola_mundo.c –o hola_mundo


4.3.2 Compilando el núcleo Ahora que tenemos listo el compilador cruzado, es el momento de compilar

el núcleo de nuestro sistema operativo Linux. Para necesitaremos el código fuente adaptado a nuestra plataforma (linux-2.6.21-ln2410sbc.tar.gz) y un pequeño parche (linux-2.6.1-ln2410sbc-lp35sam.patch.bz2) para mejorar algunos periféricos como los lectores de tarjetas de memoria y la pantalla táctil.

Para ello crearemos un directorio al que llamaremos kernel, donde copiaremos los dos ficheros comentados anteriormente.

$ mkdir kernel $ cd kernel /kernel$ cp /home/ficheros/linux-2.6.21-ln2410sbc* . /*suponiendo que están en el directorio ficheros*/

Figura 4.13: Descomprimimos el código fuente

Una vez copiados, descomprimimos y aplicamos el parche para acabar de

ajustar parámetros de los periféricos. $ tar –xvjf linux-2.6.21-ln2410sbc.tar.gz $ bunzip2 –dc linux-2.6.1-ln2410sbc-lp35sam.patch.bz2 | (cd linux-2.6.2-

ln2410sbc;patch –p1)


Figura 4.14: Aplicamos el parche

El siguiente paso consiste en configurar el Makefile para decirle que

compile el núcleo para arquitecturas ARM, esto lo haremos cambiando la variable CROSS_COMPILE, ubicada en la línea 186/196, por la ruta donde se encuentra el compilador cruzado junto con el prefijo que usa, /opt/crosstool/gcc-3.4.3-glibc-2.3.5/arm-linux/bin/arm-linux-.

$ cd linux-2.6.21-ln2410 / linux-2.6.21-ln2410$ gedit Makefile

Figura 4.15: Editando Makefile


Ahora seleccionaremos las características del núcleo que queramos, como, por ejemplo, el subsistema Bluetooth, soporte para tarjetas SD, la pantalla táctil LP35 de Samsung, etc.

Hay que tener en cuenta que para cargar el módulo de configuración es necesario tener instaladas todas las librerías de ncurses, si lo deseamos configurar desde el terminal, o las de Qt si queremos un entorno gráfico.

Estas librerías las podemos buscar e instalar fácilmente desde el Gestor de Descargas Synaptic de Ubuntu, por ejemplo.

Figura 4.16: Gestor de Paquetes Synaptic

Para seleccionar las opciones en modo terminal: / linux-2.6.21-ln2410$ make menuconfig Y en modo gráfico: / linux-2.6.21-ln2410$ make xconfig Vamos a trabajar en modo gráfico ya que así es más visual. Una vez

ejecutado compilará una serie de fuentes y finalmente aparecerá una pantalla con un árbol de opciones que se irá desplegando más a medida que profundicemos en los detalles de cada característica del núcleo. Pero antes de


seleccionar nada tenemos que cargar la configuración base para nuestro sistema de desarrollo LN410. Para ello iremos a File->Load y navegaremos hasta el directorio /arch/arm/configs/ y seleccionaremos el archivo ln2410sbc_lp35_samsung_defconfig y haremos clic en Open.

Figura 4.17: Carga de la configuración del núcleo


Tan sólo hay que desmarcar una opción incluida en la configuración por defecto y es el soporte para los botones laterales y el ratón. Esto es debido a que los controladores incluidos en el parche no están de todo adaptados al núcleo de nuestro sistema y provocan que en algunos modelos de placa no arranque. Por tanto, eliminaremos estas opciones, ambas incluidas en Input Device Support.

Figura 4.18: Rectificación de la configuración del núcleo

Figura 4.19: Rectificación de la configuración del núcleo

Ahora guardamos la configuración, File -> Save, y ya tendremos cargada la

configuración base de nuestro sistema lista para seleccionar algunos parámetros extras que nos pueden ser muy útiles a la hora de desarrollar aplicaciones, como, por ejemplo, el módulo Bluetooth o los lectores de tarjetas con soporte IDE para arrancar el sistema de ficheros desde una tarjeta SD o CompactFlash.

Ejemplos:

• Subsistema Bluetooth: añadimos soporte para el subsistema Bluetooth haciendo clic en Networking. Nos aparecerán las opciones y hacemos doble clic en Bluetooth Subsystem Support. En el siguiente árbol despegable marcamos L2CAP, SCO y RFCOMM, ya que son los protocolos más comunes y los que, generalmente, más usemos. Por último, hacemos doble clic en la


opción Bluetooth Device Drivers y marcamos las opciones HCI USB driver junto con SCO (Voice Support). Así, nuestro núcleo, será capaz de gestionar peticiones Bluetooth mediante dongles, o pastillas, Bluetooth conectados a través del puerto USB.

Figura 4.20: Configuración soporte Bluetooth

• Soporte IDE para HDD y tarjetas SD/CompactFlash: con este

soporte seremos capaces de arrancar nuestro sistema de ficheros desde un disco duro convencional, un lector de CD o una tarjeta de memoria flash tipo SD o CompactFlash. Para activarlo, dentro de la opción Device Drivers, seleccionamos ATA/ATAPI/MFM/RLL Support y en las opciones que aparecen a la derecha debemos marcar Ln2410SBC IDE Compact Flash Support y Ln2410SBC IDE Hard Drive Support. Al hacerlo tendremos soporte pleno para configurar dispositivos IDE y podremos arrancar el sistema de ficheros desde una tarjeta SD. Esto implica una serie de consecuencias muy importantes, ya que, por primera vez, desbloqueamos el límite existente en el tamaño del sistema de ficheros que, hasta el momento, era del tamaño de la memoria flash (32MB) y que, ahora, puede superar el de gigabytes de información. Si que es cierto que es más lento que el acceso a la memoria flash pero ganamos mucho en espacio de almacenamiento y, sobretodo, lo podemos utilizar o no en función de cada aplicación. Es importante recordar que las memorias flash tienen un límite de escrituras, entre 100.000 y un millón, por lo que es importante valorar el uso de un disco duro físico convencional antes que arriesgarnos a perder los datos porque tenemos una aplicación que escribe mucho sobre el soporte físico.


Figura 4.21: Configuración soporte IDE

A continuación, como ya tenemos todas las opciones marcadas,

guardamos la configuración con File -> Save y salimos del programa de configuración, volviendo al shell.

Tan sólo nos falta compilar el núcleo, lo haremos mediante las siguientes instrucciones:

/ linux-2.6.21-ln2410$ make clean

/*por si queda algún rastro de alguna instalación previa*/ / linux-2.6.21-ln2410$ make /*para empezar el proceso de creación del núcleo*/

Figura 4.22: Creación del kernel 2.6.21 para placa LN2410


Después de unos 5 minutos que tarda en compilar el núcleo tenemos la imagen que contiene todas las instrucciones necesarias para cargar todo el sistema operativo.

4.3.3 Descarga del núcleo en la placa LN2410 Ahora que ya disponemos de la imagen del núcleo es momento de volcarla

en la memoria de la placa. Para ello, navegaremos hasta el directorio /arch/arm/boot/ y copiaremos ese fichero a nuestro Windows XP, para poder descargarlo via el servidor TFTP en la placa. Esto, típicamente, lo hacemos compartiendo un directorio en el equipo Windows XP y accediendo a él desde el Ubuntu en la máquina virtual. Por ejemplo, supongamos que nuestro equipo Windows XP en el host tiene una dirección IP 192.168.1.4 y el directorio donde residen los ficheros compartidos a través de TFTP se ubica en C:\TFTP-Root. Compartiremos esta carpeta y desde Ubuntu nos conectaremos a ella para copiar el fichero zImage con total facilidad.

Figura 4.23: Copiamos zImage de Linux a Windows

Ahora que ya tenemos la imagen en Windows XP, procederemos a su

descarga en la placa de desarrollo LN2410. Para ello activaremos nuestro servidor TFTP de SolarWinds junto con la conexión serie a través del Hyperterminal que ya teníamos abierta.


Debemos asegurarnos que tenemos un cable de red cruzado o cross cable conectado al equipo host y a la placa de desarrollo y que las direcciones de red IP de la placa pertenecen a la misma red que el equipo host ya que de otra manera la conexión sería imposible.

Una vez realizadas las comprobaciones procedemos a la descarga mediante la siguiente instrucción del cargador de arranque o bootloader U-Boot:

LN2410SBC #tftp 30f00000 zImage /*tftp <dirección_de_memoria_destino> <nombre_de_la_imagen>*/

Figura 4.24: Descarga del núcleo en la placa LN2410

El hecho de descargar la imagen en la dirección 0x030F0 0000, no es

gratuito, el cargador de arranque U-Boot, guarda algunos parámetros necesarios para su ejecución en el primer bloque de la memoria flash de 32MB y por tanto es necesario saltar este tramo para evitar un error de CRC.

Ahora que ya tenemos el núcleo en la memoria de la placa LN2410 tan sólo nos queda ejecutarlo mediante la instrucción:

LN2410SBC #go 30f00000 /*go <dirección_de_memoria_para_empezar_a_ejecutar>*/ Veremos que empieza la descompresión del núcleo de Linux y a

continuación el proceso de arranque y configuración de dispositivos durante un corto lapso de tiempo para acabar con un Kernel Panic. Esto es debido a que no encuentra un sistema de ficheros válido para trabajar y, por tanto, para la ejecución. Para solucionarlo es imprescindible montar un buen sistema de


ficheros jerárquico formateándolo en el sistema que queramos, siempre y cuando esté soportado por nuestro núcleo Linux, junto con un intérprete de comandos que interactúe con el usuario como el shell.

4.4 El intérprete de comandos BusyBox Linux dispone de muchísimas utilidades para realizar cientos de funciones

y tareas todas ellas ejecutadas a través de nuestro intérprete, a partir de ahora shell. Debemos tener en cuenta que cada aplicación, para ser ejecutada en nuestra arquitectura ARM, debe ser descargada en el host, compilada para ARM y luego incluirla en el sistema de ficheros, ardua tarea teniendo en cuenta todas las que hay. Por ello, utilizaremos el programa Busybox[17] que no es más que un shell que incluye la mayoría de utilidades necesarias para trabajar con Linux en un único fichero ejecutable. Así si queremos hacer un ls, basta con escribir Busybox ls, y ejecutará ls.Mediante el uso de enlaces simbólicos simplificaremos los comandos para que el usuario final tenga la sensación que sólo hace un ls.

Por tanto, creamos un directorio para copiar los ficheros fuentes y descomprimirlos para realizar la compilación cruzada. Actualmente trabajamos con la versión Busybox 1.10.1.

$ mkdir busybox $ cd busybox /busybox$cp /home/ficheros/busybox-1.10.1.tar.bz2 . /busybox$tar xvjf busybox-1.10.1.tar.bz2

Figura 4.25: Descompresión Busybox 1.10.1


Una vez, descomprimido entramos en el directorio de trabajo y cargamos

la configuración por defecto. /busybox$cd busybox-1.10.1 /busybox/ busybox-1.10.1$make defconfig

Figura 4.26: Configuración Busybox 1.10.1 Una vez cargada la configuración por defecto ajustaremos todos los

parámetros que queramos configurando todas las utilidades que queramos incluir en el ejecutable.

/busybox/ busybox-1.10.1$make menuconfig

Figura 4.27: Configuración opciones Busybox 1.10.1


Ahora tan sólo nos falta realizar la compilación cruzada para ARM

mediante la opción CROSS_COMPILER=arm-linux-.

Figura 4.28: Compilación cruzada Busybox 1.10.1

Una vez terminado el proceso, obtendremos un fichero ejecutable busybox

de unos 760KB que contiene la mayoría de aplicaciones necesarias para Linux y una serie de enlaces simbólicos de cada aplicación disponible.

Para hacernos una idea, estas son todas las utilidades incluidas en busybox, la mayoría en el ejecutable que hemos creado para la placa de desarrollo LN2410[18]:

[, [[, 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.2

4.5 Comunicaciones por Bluetooth Bluetooth fue desarrollado por Ericsson con la ayuda de Intel y presentado

en 1994. Actualmente se ha creado un grupo de desarrollo formado por Ericsson, IBM, Intel, Nokia y Toshiba que incluye a más de 1900 compañías.

Hoy en día un gran número de dispositivos como PDAs y teléfonos móviles disponen de capacidades Bluetooth.

Bluetooth opera en la banda gratuita de 2.4GHz y utiliza la tecnología de salto en frecuencia para dotar de conectividad inalámbrica a los dispositivos incluidos dentro de un radio de acción, sin necesidad de configuración ya que los propios dispositivos publicitan sus servicios de manera que los demás puedan conectarse a ellos. También pueden formar piconets, pequeñas redes inalámbricas pero con las mismas características que una convencional.

Linux dispone de cuatro pilas Bluetooth principales: Bluez, OpnBT, Affix y BlueDrekar. Nuestro sistema trabaja con la pila Bluez[19] que, a diferencia de OpenBT que trabaja sobre una abstracción del puerto serie, trabaja mediante un socket llamado AF_BLUETOOTH y que está plenamente integrado en el núcleo

Figura 4.29: Arquitectura del subsistema Bluetooth con Bluez3

2 Encontraremos un descripción de todos los parámetros de cada instrucción en

http://www.busybox.net/downloads/BusyBox.html 3 Imagen extraída de YAGHMOUR,K. (2003).Building Embedded Linux Systems.O’Reilly.pag. 103. ISBN 0-596-00222-X


Este paquete se compone de dos módulos, la librería y los ejecutables

necesarios para hacer que el sistema funcione, como pueden ser demonios, ejecutables para comprobar parámetros de comunicación, etc. Para ejecutarlo en nuestra placa de desarrollo LN2410 será necesario realizar la compilación cruzada de las fuentes para la arquitectura ARM. Primero, copiaremos el fichero comprimido de la librería a un directorio de trabajo que crearemos, para luego descomprimirlo:

$mkdir arm-bluetooth $cd arm-bluetooth /arm-bluetooth$cp /home/ficheros/bluez-libs-2.25.tar.gz . /arm-bluetooth$tar –xvzf bluez-libs-2.25.tar.gz

Figura 4.30: Descompresión librería Bluez.

Una vez descomprimida, entramos en el nuevo directorio y configuramos

los parámetros de instalación: /arm-bluetooth$cd bluez-libs-2.25 /arm-bluetooth/ bluez-libs-2.25$./configure --host=arm-linux --prefix=/tmp/LN2410_bluez


Con la opción host=arm-linux estamos indicando que utilice el entorno

creado para la compilación cruzada empleando los compiladores para ARM y la opción prefix=/tmp/LN2410_bluez será la responsable de crear el directorio /tmp/LN2410_bluez y almacenar ahí los ficheros generados que deberemos copiar al sistema de ficheros si queremos tener comunicaciones por Bluetooth.

Figura 4.31: Configuración librería Bluez

Finalmente compilamos e instalamos mediante: /arm-bluetooth/ bluez-libs-2.25$make && make install Al terminar todo el proceso es obligatorio copiar todo el contenido

generado a la carpeta del compilador porque de otra manera no podremos compilar código con capacidades Bluetooth ya que el compilador no encontrará la librería ni las cabeceras de funciones. Por tanto, navegaremos hasta el directorio del compilador y copiaremos el contenido.

/arm-bluetooth/ bluez-libs-2.25$cd /opt/crosstools/gcc-3.4.3-glibc-2.3.5/arm-linux/arm-linux


/opt/crosstools/gcc-3.4.3-glibc-2.3.5/arm-linux/arm-linux $cp –a /tmp/LN2410_bluez/* .

Figura 4.32: Copiamos contenido generado al compilador.

Ahora ya podemos compilar aplicaciones que requieran soporte para

Bluetooth. Nuestra primera aplicación será las utilidades Bluetooth que, entre otras características, nos ayudarán a arrancar todo el subsistema Bluetooth. Para ello, volvemos al directorio dedicado a Bluetooth y copiamos el paquete de utilidades bluez-utils-2.25.tar.gz y descomprimimos.

/opt/crosstools/gcc-3.4.3-glibc-2.3.5/arm-linux/arm-linux $cd /home/usuario/arm-bluetooth /arm-bluetooth$cp /home/ficheros/bluez-utils-2.25.tar.gz . /arm-bluetooth$tar –xvzf bluez-utils-2.25.tar.gz

Figura 4.33: Descompresión utilidades Bluez.


Una vez descomprimida, entramos en el nuevo directorio y configuramos

los parámetros de instalación: /arm-bluetooth$cd bluez-utils-2.25 /arm-bluetooth/ bluez-utils-2.25$./configure --host=arm-linux --prefix=/tmp/LN2410_bluez --with-bluez=/tmp/LN2410_bluez --enable-all La opción de configuración with-bluez=/tmp/LN2410_bluez significa que

queremos que utilice los ficheros generados anteriormente para ARM. Aún así, dará un error si no tenemos instalado el componente libbluetooth-dev, el cual podemos instalar desde el Gestor de Paquetes Synaptic. La opción enable-all sirve para activar todos los componentes incluidos en el paquete de utilidades.

Figura 4.34: Configuración utilidades Bluez

Finalmente, compilamos e instalamos: /arm-bluetooth/ bluez-utils-2.25$make && make install


4.5.1 Transferencia de ficheros por Bluetooth Para poder transferir ficheros via Bluetooth existen dos aplicaciones para

ello basadas en el protocolo OBEX[20], openobex y openftp. En algunas distribuciones de Linux es necesario incluir también zlib.

Empezaremos creando un directorio de trabajo, copiamos los ficheros y descomprimimos ambos, la librería por un lado (openobex) y el módulo de nivel superior (openftp):

$mkdir obex $cd obex /obex$cp /home/ficheros/openobex-1.3.tar.gz . /obex$cp /home/ficheros/obexftpx-0.22.tar.bz2 . /obex$ tar –xvzf openobex-1.3.tar.gz /obex$ tar –xvjf obexftpx-0.22.tar.bz2

Figura 4.35: Instalación ficheros para transferir ficheros por Bluetooth

Seguidamente entramos en el directorio de la librería openobex para

realizar la compilación cruzada y configuramos la instalación:


/obex$cd openobex-1.3 /obex/ openobex-1.3$./configure --host=arm-linux --prefix=/tmp/LN2410_bluez --with-bluez=/tmp/LN2410_bluez Son las mismas opciones que anteriormente ya que nuestra finalidad es crear un directorio que incluya todas las funciones Bluetooth y así copiarlo a nuestro sistema de ficheros.

Figura 4.36: Configuración openobex

Una vez configurado correctamente compilamos e instalamos: /obex/ openobex-1.3$make && make install No hay que olvidar que es necesario copiar los ficheros generado a la

carpeta de nuestro compilador cruzado, ya que de otra manera no podríamos emplear las características OBEX en nuestras aplicaciones.

/arm-bluetooth/ bluez-libs-2.25$cd /opt/crosstools/gcc-3.4.3-glibc-2.3.5/arm-linux/arm-linux /opt/crosstools/gcc-3.4.3-glibc-2.3.5/arm-linux/arm-linux $cp –a /tmp/LN2410_bluez/*


Figura 4.37: Actualizamos el compilador cruzado

Seguidamente instalaremos obexftp. Entramos dentro del directorio creado

y lo configuramos, pero, para ello, necesitaremos copiar la configuración de openobex para que el paquete pkg la reconozca. Para ello introducimos la siguiente instrucción:

/opt/crosstools/gcc-3.4.3-glibc-2.3.5/arm-linux/arm-linux $ cd /home/usuario/obex/obexftp-0.22 / obex/obexftp-0.22$./configure --host=arm-linux --prefix=/tmp/LN2410_bluez --with-bluez=/tmp/LN2410_bluez --disable=perl --disable-python --disable=ruby

Figura 4.38: Actualizamos el compilador cruzado


Una vez configurado, compilamos e instalamos: / obex/obexftp-0.22$make && make install

Figura 4.39: Compilación e instalación de openobex

4.6 Entornos gráficos Como entorno gráfico trabajaremos con Microwindows[21], muy extendido

y adaptado a nuestra placa de desarrollo LN2410. En la mayoría de sistemas empotrados el sistema de ventanas X-Window

sobrecarga sobremanera el sistema, especialmente cuando ejecutamos aplicaciones gráficas dedicadas. Por esta razón se desarrollo el proyecto Microwindows. Es un sistema de código abierto centrado en producir aplicaciones gráficas de calidad para dispositivos empotrados. Su arquitectura permite de una manera sencilla añadir pantallas, ratones, pantallas táctiles y teclados. Desde la versión del núcleo de Linux 2.2.0, contiene código que permite a las aplicaciones de usuario acceder a la memoria de la pantalla como


un framebuffer, que es una región de memoria en el espacio del usuario que cuando se escribe en ella, controla la apariencia de la pantalla.

Esto nos permite escribir aplicaciones que controlen la pantalla sin tener conocimientos de la capa inferior de hardware que la controla.

Microwindows se diseño para crear aplicaciones comerciales rápidamente con un esfuerzo mínimo. Microwindows implementa dos populares APIs, una GDI usada en Microsoft Windows32/Lince, usada en la mayoría de aplicaciones Windows CE y Win32,y otra tipo Xlib, conocida como Nano-X, usada a bajo nivel por todos los entornos Linux. Esto permite a un gran número de programadores en Windows que sean capaces de desarrollar aplicaciones graficas fácilmente, tanto como para los desarrolladores de aplicaciones Linux que trabajan con X11.

Microwindows se ejecuta en tan sólo 50-250KB de memoria, una magnitud mucho más inferior que el sistema de ventanas XWindow. Esto se consigue básicamente usando una única rutina para cada función de dibujo en la capa gráfica.

Microwindows soporta completamente la arquitectura framebuffer del núcleo de Linux, y actualmente tiene soporte para 1, 2, 4, 8, 16, 24 y 32 bits por píxel, con soporte para implementaciones de color de pantalla paletizada y color verdadero, así como escala de grises. Con ambas APIs, los colores se especifican en el formato portátil de RGB y el sistema incluye rutinas para convertirlos en el color disponible más cercano. Aunque Microwindows tiene soporte completo para el núcleo de Linux, su arquitectura interna está basada en la interfaz del dispositivo de pantalla (/dev) y puede funcionar en la mayoría de sistemas operativos de tiempo real así como en multitud de hardware. Esto aporta una gran ventaja: las aplicaciones gráficas se pueden compartir entre diferentes proyectos con diferentes sistemas operativos de tiempo real, sin necesidad de reescribir la parte gráfica de la aplicación.

Microwindows incluye un emulador para poder testear las aplicaciones en Linux en la estación host sin necesidad de realizar una compilación cruzada para descargarlo en la placa de desarrollo. Incluso, aunque nuestra estación host tenga una resolución de pantalla de 24 bits, el emulador es capaz de mostrar la aplicación en 2 bits por píxel para poder emular completamente el sistema destino.De esta manera podemos desarrollar y prototipar toda la aplicación para más adelante montarla en nuestra placa de desarrollo LN2410

Microwindows es, esencialmente, un diseño por capas que permite a las diferentes capas ser usadas o rescritas en función de las necesidades de cada proyecto. A bajo nivel, los controladores de la pantalla, el ratón, la pantalla táctil o el teclado son los encargados de interactuar con el usuario. En un nivel medio, implementamos el motor gráfico, capaz de dibujar líneas, rellenos, polígonos, etc. En el nivel superior, hay varias APIs implementadas para que el programador sea capaz de crear aplicaciones gráficas.

Gracias a la extremada compatibilidad entre las APIs de Win32 y de los sistemas XWindow, la portabilidad entre sistemas es muy sencilla.

Para ello, crearemos un directorio de trabajo donde copiaremos los ficheros necesarios. Serán necesarios cuatro ficheros, el código fuente del sistema de ventanas microwindows-0.90.tar.gz, las fuentes para mostrar por


pantalla, microwindows-fonts-0.90.tar.gz, el parche con la configuración para la placa LN2410, patch-0.90-lc1.patch.gz y las fuentes para generar la librería zlib para ARM, zlib-1.2.3.tar.gz, necesaria para poder realizar la compilación cruzada de Microwindows.

$mkdir microwindows $cd microwindows /microwindows$cp /home/ficheros/ microwindows-0.90.tar.gz . /microwindows$cp /home/ficheros/ microwindows-fonts-0.90.tar.gz . /microwindows$cp /home/ficheros/ patch-0.90-lc1.patch.gz . /microwindows$cp /home/ficheros/ zlib-1.2.3.tar.gz . Empezaremos por la instalación de zlib, ya que es prerequisito para

Microwindows. Descomprimimos el código fuente y lo configuramos para usar nuestro compilador cruzado y para que se instale, la librería resultante, en la carpeta del compilador cruzado y, así, estar disponible en el futuro para cualquier código que lo necesite.

/microwindows$tar zxvf zlib-1.2.3.tar.gz . /microwindows$cd zlib-1.2.3 /microwindows/zlib-1.2.3$CC=arm-linux-gcc ./configure --prefix=/opt/crosstools/gcc-3.4.3-glibc-2.3.5/arm-linux/arm-linux

Figura 4.40: Configuración zlib


La variable CC=arm-linux-gcc es necesaria para indicar qué compilador

vamos a utilizar, en nuestro caso, el apropiado para la arquitectura ARM. Como queremos que, una vez compilado, esté disponible, para, en el futuro, poder compilar con la opción de usar la librería zlib, añadiremos la opción --prefix=/opt/crosstools/gcc-3.4.3-glibc-2.3.5/arm-linux/arm-linux que copiará las librerías resultantes en el directorio del compilador. Si además queremos que nuestra placa de desarrollo LN2410 tenga acceso a la librería zlib, podemos instalarla en nuestro sistema de fichero mediante la opción INSTALL_PREFIX=/tmp/LN2410_bluez.

/microwindows/zlib-1.2.3$make INSTALL_PREFIX=/tmp/LN2410_bluez install

Figura 4.41: Instalación zlib en la placa de desarrollo LN2410

Ahora que ya tenemos el prerequisito para compilar Microwindows para

ARM, iniciaremos el proceso. Primero de todo descomprimiremos los ficheros necesarios en el lugar

adecuado: /microwindows/zlib-1.2.3$cd .. /microwindows$ tar xvzf microwindows-0.90.tar.gz Una vez descomprimido el código fuente descomprimiremos las fuentes

para la pantalla en el directorio de Microwindows. /microwindows$cd microwindows-0.90 /microwindows/microwindows-0.90$tar xvzf ../microwindows-fonts-0.90.tar.gz


De esta manera tenemos todos los ficheros necesarios que componen el gestor gráfico Microwindows. El paso siguiente es aplicar una serie de parches y modificaciones para que, al final, podemos compilarlo para nuestra arquitectura ARM.

Figura 4.42: Descompresión ficheros necesarios Microwindows

Para aplicar los parches, seguiremos los siguientes pasos: /microwindows/microwindows-0.90$cd .. /microwindows$gzip –cd patch-0.90-lc1.gz | (cd microwindows-0.90:patch -p1)

Figura 4.43: Aplicamos parche para Microwindows


Ahora editamos los ficheros de configuración para decirle qué compilador

cruzado vamos a utilizar. /microwindows$cd microwindows-0.90 /microwindows/microwindows-0.90$gedit src/config En la línea 146, escribiremos la ruta completa que contiene la librería zlib

para ARM, requisito previo. Por tanto actualizaremos el valor de la variable LIBZ: LIBZ=/opt/crosstools/gcc-3.4.3-glibc-2.3.5/arm-linux/arm-linux/lib/libz.a

Figura 4.44: Editando config

Ahora deberemos modificar el fichero Makefile.rules para indicarle la ruta

hacia las librerías de nuestro compilador cruzado. En la línea 39, colocaremos la ruta de nuestro compilador como se puede ver en la imagen.


/microwindows/microwindows-0.90$gedit src/Makefile.rules

Figura 4.45: Editando Makefile.rules

Finalmente compilaremos e instalaremos en el directorio de nuestro

sistema de ficheros para la placa de desarrollo LN2410: /microwindows/microwindows-0.90$cd src /microwindows/microwindows-0.90/src$make /microwindows/microwindows-0.90/src$ make INSTALL_PREFIX=/tmp/LN2410_bluez install Ahora nuestra placa de desarrollo dispondrá de un entorno gráfico. Como

el entorno Microwindows funciona bajo una arquitectura cliente-servidor en la que primero cargamos el servidor gráfico y después las aplicaciones clientes las que se comunican con él para gestionar las peticiones de pantalla, es necesario


cargar el servidor Nano-X para que funcione en background. A continuación vemos un ejemplo del proceso:

[LN2410]$cd bin /*entramos al directorio donde reside nano-X*/ [LN2410]$nano-X & /*lo ejecutamos en background*/ [LN2410]$nxcal /*iniciamos calibración*/

Figura 4.46: Ejecución aplicaciones Nano-X

El resultado es la carga del proceso para calibrar la pantalla:

Figura 4.47: Ejecución calibración Nano-X


La ejecución de nxcal genera un fichero llamado nxcal.dat que incluye los parámetros de calibración de la pantalla. Este fichero será cargado por defecto por nano-X para leer la calibración correcta de la pantalla.

Otro ejemplo es la ejecución de un ejecutable para ver las opciones de creación de ventanas y relleno que tiene Microwindows. Recargamos el servidor gráfico y ejecutamos:

[LN2410]$nano-X & /*lo ejecutamos en background*/ [LN2410]$demo /*ejecutamos demostración*/

Figura 4.48: Aplicaciones de demostración Nano-X

4.7 El sistema de ficheros El sistema de ficheros contendrá todos los directorios necesarios para la

ejecución del núcleo y la comunicación con el usuario y los periféricos. A lo largo de todo el proceso de compilación cruzada tanto del núcleo

como de sus aplicaciones hemos ido marcando el directorio destino /tmp/LN2410_bluez, lugar, por tanto, donde residen una primera parte de los ficheros necesarios compilados para nuestra arquitectura destino ARM.


La creación del sistema de ficheros tiene un proceso meticuloso y muy adaptable a nuestras necesidades[22]. Partiremos de la creación de una imagen del tamaño que necesitemos, siempre y cuando sea menor de los 32MB disponibles en la placa de desarrollo LN2410, para después montarla sobre nuestro sistema host con el fin de crear directorios, dispositivos, copiar ficheros y enlaces, y editar todos los ficheros de configuración.

Empezaremos por crear la imagen y montarla, el tamaño escogido es de 16MB, suficiente para almacenar los binarios y librerías más importantes. No olvidemos que, gracias al soporte de tarjetas SD y CompactFlash, siempre podremos cargar los ficheros que necesitemos sobre estos soportes.

$dd if=/dev/zero of=/tmp/disco_LN2410 bs=1024 count=16000 Hemos creado una imagen en /tmp/ramdisk.img de 16MB con bloques de

1KB. A continuación la formatearemos con el formato Ext2, aunque existen otros sistemas de ficheros muy válidos en entornos empotrados, para montarla sobre un directorio donde realizaremos todas las operaciones sobre ficheros.

$mkdir rootfs /*creamos directorio donde realizaremos operaciones*/ $/sbin/mke2fs -F -m 0 -b 1024 /tmp/ disco_LN2410 16000 /*formateamos en ext2*/ $mount /tmp/ disco_LN2410 rootfs -t ext2 -o loop=/dev/loop0 /*montamos imagen en directorio*/ Copiamos todo el contenido del directorio temporal usado durante el

proceso de configuración de las aplicaciones al directorio destino donde guardaremos el sistema de ficheros.

$cd rootfs /entramos dentro del sistema de ficheros de la placa*/ rootfs$cp -a /tmp/LN2410_bluez/* . Copiamos el contenido de la librería de nuestro compilador cruzado al

sistema de ficheros. Este directorio del compilador cruzado incluye las librerías necesarias para la ejecución de múltiples aplicaciones como Busybox.

rootfs$cp -a /opt/crosstools/gcc-3.4.3-glibc-2.3.5/arm-linux/arm-linux/lib/* . Ahora crearemos los enlaces simbólicos a los dispositivos. Esta parte es

crítica porque necesitamos montar la imagen base suministrada por el fabricante para copiar los enlaces de los dispositivos a nuestro sistema además de otros directorios útiles, como el /etc, /var, /share, etc. Para ello crearemos otro directorio temporal únicamente para este fin.

rootfs$cd ..


$mkdir temp $ mount –o loop /home/ficheros/LN2410disk temp /*montamos la imagen del fabricante en el directorio /home/temp*/ $cp -a temp/dev/ rootfs/. /*copiamos los enlaces simbólicos del fabricante*/ $cp -a temp/etc/ rootfs/. $cp -a temp/var/ rootfs/. $cp -a temp/share/ rootfs/. /*copiamos demás directorios importantes */ Ahora crearemos algunos directorios necesarios como el /proc donde se

montará una parte del núcleo o el /tmp. $cd rootfs rootfs$mkdir proc rootfs$mkdir tmp Hemos creado todo el árbol de directorios para que Linux pueda trabajar

con normalidad. Antes de ajustar los parámetros finales profundizaremos un poco sobre el proceso de arranque de Linux.

Cuando el núcleo ha terminado de cargarse y de inicializar dispositivos, llama al proceso marcado por la variable init, en nuestro caso linuxrc, que no es más que un enlace simbólico a /bin/busybox. Busybox es capaz de arrancar como proceso init, el primero del sistema operativo de Linux y padre de todos los demás procesos, de ahí que tenga 1 como identificador de proceso [12].

Este proceso mirará la configuración incluida en el fichero /etc/init.d/rc.local, inicializará ciertas variables, montará dispositivos, configurará direcciones de red y arrancará el subsistema Bluetooth, para, finalmente, llamar al shell del sistema, en nuestro caso ash.

Figura 4.49: Arranque placa LN2410


Para hacerlo un poco más visual e intuitivo se han incorporado una serie de echos a la pantalla de nuestro sistema de desarrollo LN2410 para mostrar por pantalla lo que va sucediendo a medida que inicializamos parámetros.

Figura 4.50: Fichero de configuración rc.local

El shell ash cargará otro archivo de configuración ubicado en /etc/profile

donde personalizará el shell en sí.


Figura 4.51: Fichero de configuración /etc/profile

Ahora que tenemos todo el sistema de ficheros parametrizado y

configurado, lo desmontaremos y lo compactaremos en un fichero único. En el que después, o lo montamos sobre una tarjeta flash o lo adjuntamos al núcleo en un único fichero binario que contenga núcleo y sistema de ficheros.

rootfs$cd .. /*salimos del directorio sino el núcleo no permitirá desmontar la imagen*/ $umount /tmp/ disco_LN2410 /*desmontamos imagen*/ $gzip -9 /tmp/ disco_LN2410 /*comprimimos imagen*/ $cp /tmp/ disco_LN2410.gz . /*la copiamos a nuestro directorio principal*/


4.8 Arranque del sistema Como última opción de diseño debemos escoger dónde vamos a cargar el

sistema, en la memoria SDRAM de 64MB de la placa o en una tarjeta de memoria externa tipo SD o CompactFlash. Esta decisión es importante porque ambas tienen sus ventajas e inconvenientes.

• Memoria SDRAM de la placa: la placa de desarrollo ln2410 dispone

de una memoria de 64MB adecuada para almacenar el sistema de ficheros pero tiene el problema inherente que al desconectar la alimentación se borran todos los datos. Para cargar el sistema de ficheros a la memoria flash, debemos asegurarnos que tenemos configurado la línea de comandos de arranque que le pasamos al núcleo de Linux correctamente. Para ello recompilamos el núcleo con la siguiente opción de carga en la sección Boot options -> Default kernel command string: Console=ttySAC0 mem=64 root=/dev/ram0 init=/linuxrc

Figura 4.52: Línea de configuración de arranque del kernel

El siguiente paso consiste en mezclar en una única imagen binaria el núcleo y el sistema de ficheros. Entramos en el directorio donde tenemos instalados los ficheros fuente del sistema Linux 2.6.21 y escribimos: / linux-2.6.21-ln2410$ make bootpImage INITRD_PHYS=0x30800000 INITRD=/ruta/a/disco_LN2410.gz


/*Típicamente la ruta será /home/nombre_usuario/*/

Los parámetros INITRD_PHYS, que indica la dirección de memoria dónde se colocará el sistema de ficheros, e INITRD, que le dice el nombre de la imagen binaria comprimida que contiene el sistema de ficheros, son imprescindibles para la correcta creación de la imagen boopImage.

Figura 4.53: Creación de bootpimage

Una vez creado copiamos el fichero bootpImage, que está dentro del directorio de Linux en linux-2.6.21-ln2410/arch/arm/boot/ al directorio donde se almacenan los ficheros el servidor TFTP, típicamente C:\TFTP-Root\, de la misma manera que para cargar el núcleo. Una vez realizado, abrimos nuestra sesión de hyperterminal y escribimos:

LN2410SBC #tftp 30f00000 bootpImage /*cargamos todo el sistema Linux*/ Al finalizar la descarga a la placa de desarrollo LN2410 de la imagen binaria que contiene el núcleo de Linux 2.6.21, junto con el sistema de ficheros, sólo queda ejecutarlo. Esto lo haremos mediante la siguiente instrucción: LN2410SBC #go 30f00000 /*go <dirección_de_memoria_a_ejecutar>*/ Y, de inmediato, empezará el proceso de arranque del núcleo. Si todo ha ido correctamente, al final aparecerá un mensaje indicándonos que podemos empezar a ejecutar el intérprete de comandos o shell.


Figura 4.54: Arranque de Linux desde SDRAM

• Tarjeta de memoria SD o CompactFlash: la placa de desarrollo

ln2410 dispone de un lector de tarjetas de memoria para SD y otro para CompactFlash. El proceso siguiente lo centraremos para el caso de una tarjeta SD.Para cargar el sistema de ficheros en la tarjeta SD lo que haremos será montar la imagen binaria en un directorio de nuestro entorno Linux par luego copiarlo a nuestra tarjeta SD. El proceso es el siguiente: Formateamos la tarjeta de memoria SD en formato ext2, para ello será necesario desmontar la unidad si se ha montado de forma automática con la instrucción umount –a. $ mkfs.ext2 /dev/sdb1

Figura 4.55: Formateamos la tarjeta SD


Descomprimimos la imagen binaria: $ gzip –d disco_LN2410.gz Lo montamos en un directorio para luego copiarlo a la tarjeta de memoria SD: $mount –o loop disco_LN2410 /home/user/temp $cd /media/disk /*accedemos al punto de montaje de la tarjeta SD*/ /media/disk$cp –dpR /home/user/temp/* . /*copiamos todos los ficheros incluidos los enlaces simbólicos*/

Ahora que ya tenemos todo el sistema en la tarjeta de memoria, deberemos modificar la linea de arranque del núcleo de Linux para que busque el sistema de ficheros en la tarjeta de memoria. Para ello recompilamos el núcleo con la siguiente opción de carga en la sección Boot options -> Default kernel command string: Console=ttySAC0 mem=64 root=/dev/mmcblk0p1 rootfstype=ext2 rootdelay=5 init=/linuxrc El parámetro rootdelay=5 es necesario porque las tarjetas de memoria requieren un pequeño tiempo para cargarse y tener acceso a los datos, con 5 segundos será suficiente. Para realizar la descarga abrimos nuestra sesión de hyperterminal y escribimos:

LN2410SBC #tftp 30f00000 zImage /*cargamos el núcleo de Linux*/

Veremos como se realiza la descarga a la memoria flash de la placa de desarrollo LN2410. Finalmente ejecutamos la posición de memoria dende tenemos el núcleo con la instrucción:

LN2410SBC #go 30f00000 /*arrancamos el sistema Linux*/

El sistema arrancará descomprimiendo el núcleo para seguidamente inicializar todos sus parámetros y variables necesarios para configurar todos los dispositivos vinculados a nuestro sistema.


Al final, tanto si tenemos el sistema en la memoria flash como si nos hemos decidido por cargarlo en una tarjeta de memoria SD obtendremos el resultado final, el acceso al intérprete de comandos de Linux 2.6.21:

Figura 4.56:Intérprete de comandos Busybox

86

Capítulo 5 Windows CE 5.1 Introducción

Windows CE es un sistema operativo abierto y escalable de 32 bits que

integra funciones fiables en tiempo real junto con las más avanzadas tecnologías de todo el sistema Windows [23]. Windows CE permite adaptarse a múltiples dispositivos innovadores que requieran de un mínimo espacio ideal en los entornos empotrados como la placa de desarrollo LN2410.

Los dispositivos basados en Windows CE están diseñados para un uso específico, normalmente funcionando de manera autónoma y que requieren un pequeño sistema operativo que responda de una manera concreta a las interrupciones que se le presentan. Como ejemplos tenemos dispositivos electrónicos del cliente, terminales Web, dispositivos de acceso a Internet, controladores industriales especializados, televisores interactivos, ordenadores de bolsillo, dispositivos de comunicación empotrados e incluso consolas de video juegos como fue en el caso de la Sega Dreamcast (1997 - 2001) con procesador SH4 de 128 Bits que aunque contaba con un sistema operativo propio, incluía compatibilidad con los kits para desarrollo de software de Windows CE

Windows CE no es un subconjunto de Windows XP, o de Windows NT, sino que fue desarrollado a base de nuevas arquitecturas y una nueva plataforma de desarrollo. Aun así mantiene cierta conexión con sus hermanos. Windows CE tiene sus propias APIs para desarrollo, y necesita sus propios controladores para el hardware con el cual va a interactuar.

Cabe destacar que este sistema operativo es el único producto de Microsoft que se distribuye junto con el código fuente (tal como Linux) y usa una licencia llamada Shared Source, así pues permite al usuario final modificar el código fuente sin notificar al propietario.


5.1.1 Historia Windows CE nació en 1994 con el nombre de “proyecto Pulsar”, el cual al

final acabó convirtiéndose en este conocido sistema operativo [24]. La primera versión fue la versión Windows CE 1.0 y su código fuente fue

escrito desde cero y lanzado comercialmente en 1996. Era parcialmente compatible con el Windows tradicional ya que una parte de la conocida API Win32 era soportada por Windows CE. Además era compatible con la mayoría de las arquitecturas hardware de 32 bits.

Un año más tarde nació la versión Windows CE 2.0, en 1997, y estaba basado completamente en la versión predecesora 1.0. Una de sus mejoras más sustanciales fue el soporte para arquitecturas Intel y AMD. En el apartado multimedia se actualizó aportando funciones para gestionar pantallas con resolución de 24 bits. Esta versión incluyó adaptadores para la interconexión de redes. En la sección de software incorporaba una máquina virtual Java y la ejecución de tecnología ActiveX, además de soporte parcial para Microsoft Foundation Classes, una librería de clases en C++ para programación bajo Windows. También proporcionó conectividad por USB e infrarrojos, soporte para el sistema de ficheros FAT y servicios de impresión. Como podemos comprobar, fue un salto cualitativo considerable y muy importante.

En el año 2000 salió al mercado la versión 3.0. En ese momento PALM dominaba bastante el mercado de sistemas empotrados con su sistema operativo PALM OS y la respuesta de Microsoft fue Windows CE 3.0. Entre la mayoría de funcionalidades incorpora interrupciones con prioridades y una mayor de la gestión de los hilos, además de una comunicación entre procesos. También se le dotó de una mayor capacidad de almacenamiento. Esto lo consolidó como la base del sistema operativo PocketPC 2002, que se encontraba en ese momento en multitud de PDAs y teléfonos.

Windows CE 4.0 aparece en marzo de 2002. Considerado un sistema operativo mucho más robusto y eficiente respecto a su versión anterior en cuanto a capacidades multiproceso se refiere. La mayor mejora es un mayor grado de comunicación y sincronización con el sistema operativo Windows tradicional. Windows CE 4.0 fue el responsable de la salida al mercado en junio del 2003 de la conocida versión Windows Mobile 2003. En esencia fue un cambio de nombre incluyendo algunas aplicaciones nuevas.

En mayo del 2005 Microsoft lanzaba Windows CE 5.0, versión actual con al que trabajamos en la placa de desarrollo LN2410, y que incluía mejoras en la pila Bluetooth así como una paquete ofimático y multimedia más completo. Su versión estrella fue Windows Mobile 5.0, muy extendido en multitud de teléfonos móviles y PDAs.

La última versión de este sistema operativo es Windows CE 6.0, un 30% superior en prestaciones a su predecesor, capaz de acceder mediante una API personalizada a un dispositivo de entrada/salida en tan sólo un ciclo de 100us. La mayoría de cambios se encuentran en el núcleo del sistema operativo, revisando completamente la arquitectura del sistema. Además cada proceso es


capaz de direccionar 2GB y el número de procesos simultáneos ha aumentado de 32 a 32000.

5.1.2 Características principales Windows CE es un sistema operativo completo además de aportar unas

inmejorables herramientas de desarrollo que contienen todas las funcionalidades para construir, depurar y desplegar dispositivos basados en Windows CE.

Utilizaremos un entorno de desarrollo completamente integrado para construir sistemas operativos específicos basados en Windows CE y todos los componentes para dispositivos empotrados que Microsoft ha desarrollado para ese fin, Platform Builder.

Windows CE incluye controladores de dispositivos de alta calidad que utilizan menos código en plataformas de hardware específicas, abstrayendo todas las asignaciones de recursos al registro y creando librerías reusables e independientes de la plataforma de hardware que utilicemos. De esta manera reducimos la complejidad de adaptar los controladores para que funcionen en hardware propio.

Windows CE, aumenta la productividad de los desarrolladores de aplicaciones gracias a un conjunto de herramientas de programación para crear código gestionado y aplicaciones en código nativo para dispositivos basados en Windows CE. Ofrece a los desarrolladores de aplicaciones el versátil entorno de la interfaz de programación basada en las API de Microsoft Win32 además de la facilidad y versatilidad de los lenguajes de secuencias de comandos o scripts. También ofrece soporte de serie para servicios multimedia, Internet, redes de área local, comunicaciones móviles y seguridad.

Además podemos hacer uso de la plataforma .NET sobre Windows CE para aumentar la portabilidad de aplicaciones entre diferentes sistemas operativos.

De la misma manera que en Linux, para realizar la instalación de Windows CE en la placa de desarrollo LN2410 es necesario seguir un modelo por capas. Cada una de ellas debe estar correctamente instalada antes de proceder a la carga de la siguiente. Las capas son el bootstrap, bootloader, núcleo.

Figura 5.1: Esquema por capas para carga de Windows CE


Existen unas diferencias significativas respecto a Linux. El bootstrap, al realizar todas las tareas de inicialización y configuración en común a ambos sistemas operativos. El bootloader en este caso se llama eboot, propietario de Microsoft y del que hablaremos más adelante. Finalmente el núcleo de Windows CE 5.0 completo con el sistema de ficheros y sin muchas opciones de alterarlo a diferencia de Linux.

5.2 El bootloader, Eboot Eboot es el bootloader o cargador de arranque necesario para que la placa

de desarrollo LN2410 sea capaz de arrancar el sistema operativo Windows CE. Es un software propietario de Microsoft que se distribuye junto con los controladores del hardware de la placa por su fabricante. Clabsys provee varios modelos de Eboot, uno para cada plataforma hardware de que dispone. El modelo LN2410 funciona únicamente con el modelo diseñado para la pantalla táctil Samsung LP35 de la que disponemos. Es capaz de realizar prácticamente las mismas funciones que su homólogo de Linux pero con una mayor sencillez.

Su entorno está dividido en tres bloques. El primero dedicado a la configuración del puerto Ethernet, dirección de

red, máscara de subred, si se autoconfigura mediante la conexión a un servidor DHCP o si queremos cambiar la dirección física MAC.

El segundo controla todo lo dedicado al sistema como puede ser la rutina de ejecución automática al inicio de la placa, el tiempo que tardará en ejecutarla, la carga de la configuración por defecto o el borrado de las variables de entorno.

El tercer bloque trata todas las gestiones relacionadas con la memoria NAND, su formateo a bajo nivel o la opción de grabar todo el sistema a la memoria NAND de manera que no sea necesaria su descarga cada vez que se inicia la placa como en Linux. Finalmente dispone de las opciones de grabar la configuración, descargar una imagen binaria a través de USB o Ethernet y de lanzar la imagen descargada.

Cabe comentar que la opción de descarga vía USB es muy interesante por su velocidad y la simplicidad de hardware, tan sólo es un cable. Pero otra vez nos encontramos con los problemas de software relacionados con este modelo LN2410 al descubrir que para realizar la descarga por USB es necesario el software ArmDown que solo opera en entornos coreanos.

5.2.1 Descarga del bootloader a la memoria NOR Para descargar el cargador de arranque a la memoria NOR es necesario

utilizar el software de escritura en memoria, JFLASH.EXE, pasándole como parámetro la imagen binaria del bootloader.

Accedemos al directorio donde reside el software JFLASH.EXE y lo ejecutamos con la opción de la imagen binaria del cargador de arranque. Una


vez ejecutado, comprobamos que ha detectado la placa correctamente al mostrar “LN2410SBC < ID=0x0032409d> is detected”, y que entre las opciones que se nos presentan deberemos marcar “1” para “NOR Prog”, seleccionamos el tipo de chip(Am29lv160eb (2MB)) y finalmente, el desplazamiento, que será 0x10000, lugar donde el bootstrap saltará después de configurar la placa. Tan sólo deberemos pasarle por la línea de comandos el nombre de la imagen del Eboot escribiendo la siguiente instrucción:

C:\LN2410> jflash /f:eboot.nb0

Figura 5.2: Descarga bootloader Eboot a la memoria NOR


Veremos que la instalación del cargador de arranque es correcta porque al conectar la placa a la alimentación, en la pantalla aparecen cuatro cuadros de colores.

Figura 5.3: Pantalla bootloader Eboot en la placa LN2410

5.2.2 Configuración del bootloader, Eboot, a través de Hyperterminal

Para poder establecer una conexión a través del puerto serie RS232 es

necesario que nuestro programa Hyperterminal esté configurado para trabajar a 115200 baudios, 8 bits de datos, sin paridad, 1 bit de parada y sin control de flujo, de la misma manera que para hacer la descarga de su homólogo en Linux.

Esto lo haremos en la pantalla de conexión del Hyperterminal, después de dar un nombre a la conexión y de seleccionar el puerto serie en el que tenemos conectado el cable DB-9 NULL MODEM (otro modelo no funcionaria). Veremos una pantalla como la siguiente:


Figura 4.5: Hyperterminal: Configuración de conexión

Acto seguido, después de apretar el botón de reset de la placa podremos

realizar operaciones con el cargador de arranque. Tenemos 5 segundos antes que empiece la rutina predeterminada de descarga de imagen desde el software Platform Builder a la placa de desarrollo LN2410. Si apretamos la tecla Espacio, entraremos en el menú de configuración del cargador de arranque dónde encontraremos las opciones para modificar las variables de entorno predefinidas.

La idea es configurar el sistema para que una vez descargada la imagen del sistema operativo se escriba en la memoria NAND para quede permanentemente y luego lanzar el sistema operativo cada vez que se inicie la placa.


Figura 5.4: Inicio del bootloader Eboot

Como está distribuido en tres bloques iremos configurando cada uno de

ellos nuestros fines. En el apartado de configuración Ethernet, cambiaremos la dirección de red

y la máscara de subred a las que correspondan a nuestro entorno, por ejemplo: Dirección de red: 192.168.1.239 Máscara de subred: 255.255.255.0

Para ello, apretaremos “1”, introducimos la nueva dirección de red y

después apretamos “2” e introducimos la nueva máscara de subred. Además, si configuramos una dirección de red no tiene sentido utilizar un

servidor DHCP y, por tanto, lo desactivaremos apretando “2”. En cuanto a la configuración por defecto que queremos del sistema es que

una vez arranque la placa cargue inmediatamente el sistema operativo Windows, por lo que marcaremos “4” hasta que quede la opción ”launch existint resident image”.

El siguiente bloque es el referido a las operaciones sobre la memoria NAND. Marcaremos “7” hasta dejar la opción “Program disk image into the NAND: Enabled “. Así nos aseguramos que, una vez descargada la imagen binaria del sistema operativo, se escriba en la memoria NAND y nos borre aunque se corte la alimentación.

Finalmente apretamos “S” para guardar la configuración y lo dejamos todo preparado para iniciar la descarga de la imagen con tan sólo apretar “E”.


Figura 5.5: Configuración del bootloader Eboot

5.3 Platform Builder Microsoft ha desarrollado una aplicación completa para poder configurar y

compilar el sistema operativo Windows CE llamada Platform Builder [25]. Platform Builder es un entorno de desarrollo integrado que sirve para

generar a medida sistemas operativos empotrados basados en Windows CE. Es decir, podemos seleccionar los módulos que deseemos incorporar a nuestro sistema creando infinidad de combinaciones, cada una de ellas, apropiada para un uso específico.

Se trata de un espacio de trabajo visual donde podemos diseñar cualquier configuración de sistema operativo tan sólo arrastrando módulos de las opciones posibles a nuestro proyecto.

Es necesario disponer de un BSP (Board Support Package). El BSP son una serie de ficheros que contienen todos los controladores propios de nuestra placa de desarrollo LN2410 sin los cuales no sería posible arrancar el sistema operativo. Este BSP lo suministra el fabricante para cada versión de Windows CE (4.2 o 5.0).

Veremos que en una parte del entorno de desarrollo tenemos todas las funciones propias del núcleo del sistema Windows CE y por otro lado los controladores específicos de los dispositivos que incorpora nuestra placa LN2410.


5.3.1 Instalación Platform Builder Para instalar Platform Builder introduciremos el DVD de instalación y

esperamos que se auto ejecute. En la pantalla de bienvenida seleccionamos “Install” para iniciar el proceso de instalación.

Figura 5.6: Instalación de Platform Builder

Una vez que configura el instalador de Windows XP aparece el asistente a

la instalación. Hacemos clic en Next para continuar con la instalación de Microsoft Windows CE.

Figura 5.7: Instalación de Platform Builder


Nos aparecerá la pantalla con los términos de la licencia. Aceptamos los términos y hacemos clic en Next.

Figura 5.8: Aceptación de licencia de Platform Builder

Seguidamente podemos configurar el nombre de usuario y la organización

a la que se pertenece. Por último sólo resta introducir la llave del producto y hacer clic en Next.

Figura 5.9: Introducción de la llave y registro de Platform Builder

La siguiente pantalla se refiere a qué tipo de instalación queremos hacer,

el sistema operativo juntos con sus herramientas o sólo las herramientas. En nuestro caso, como queremos desarrollar todo el sistema operativo desde el principio seleccionaremos el sistema operativo junto con sus herramientas. Para


ello seleccionaremos un tipo de instalación Custom (Tools and OS). Hacemos clic en Next.

Figura 5.10: Instalación personalizada de Platform Builder

Ahora debemos escoger los directorios de instalación base. Es importante

mencionar que el directorio donde se almacenarán todos los ficheros del árbol de nuestro sistema operativo debe ser C:\WINCE500, porque es el mismo que lleva integrado el BSP del fabricante y si lo cambiamos nuestro sistema sufriría serias deficiencias. Hacemos clic en Next para seguir con la instalación.

Figura 5.11: Selección de los directorios de instalación de Platform Builder

La siguiente pantalla es extremadamente importante. En ella debemos

seleccionar que instale completamente, junto con todas sus opciones, tanto el


código compartido de Windows CE (Shared Source) como el sistema operativo Windows CE 5.0 para AMRV4I. Para ello hacemos clic en Shared Source for Windows CE 5.0 y marcamos la opción “This feature, and all subfeatures, will be installed on local hard drive”. Repetimos el proceso con la opción ARMV4I dentro de Windows CE 5.0 Operating System y hacemos clic en Next.

Figura 5.12: Personalización de la instalación de Platform Builder

Acto seguido deberemos aceptar la licencia de uso de Microsoft Windows

CE 5.0 y su entorno de desarrollo Platform Builder. Marcamos la opción “I accept the term in the license agreement” y hacemos clic en Next.


Figura 5.13: Aceptación de licencia de Platform Builder

Ahora ya tenemos todo listo para la instalación de todo el entorno. Por

tanto haremos clic en Install y una vez haya terminado de copiar e instalar todos los ficheros en nuestro equipo host podremos ver la pantalla confirmando que todo ha ido bien para finalmente hacer clic en Finish.

Figura 5.14 Listo para instalar de Platform Builder


Figura 5.15: Finalización de la instalación de Platform Builder

5.3.2 Instalación BSP de Clabsys para Platform Builder Una vez tenemos instalado Microsoft Platform Builder ya estamos

preparados para configurar nuestro sistema operativo Windows CE. El primer factor a tener en cuenta es para qué tipo de arquitectura hardware vamos a desarrollar nuestro sistema operativo, de qué dispositivos consta la placa de desarrollo LN2410 y cómo se gestionan.

Para ello, el fabricante de la placa de desarrollo LN2410 suministra un BSP (Board Support Package), como lo hacen todos, donde están todos los ficherso necesarios para configurar los dispositivos que conforman el modelo LN2410. En esta versión de BSP tenemos soporte para la memoria NAND, los lectores de tarjetas SD, los accesorios USB, la pantalla junto con su módulo táctil y la tarjeta de sonido

Hacemos doble clic en el fichero de instalación de nuestro BSP para empezar con la importación de los ficheros necesarios para la creación del sistema operativo adaptado a la placa de desarrollo LN2410. Hacemos clic en Next para empezar con la instalación.


Figura 5.16: Instalación del BSP

La siguiente pantalla nos indicará dónde se instalará el BSP para la placa

de desarrollo LN2410. Está prefijado que se instale en el directorio C:\WINCE500 por eso es tan importante fijar este directorio en la instalación de Microsoft Platform Builder. Hacemos clic en Install para proceder con la instalación.

Figura 5.17: Ubicación de la instalación del BSP

Después de la copia de los ficheros necesarios a la ubicación especificada

veremos la pantalla final confirmando la correcta instalación del BSP. .


Figura 5.18: Finalización de la instalación del BSP

En estos momentos disponemos de todas las herramientas necesarias

para poder configurar, editar, compilar e instalar el sistema operativo Windows CE 5.0 en la placa de desarrollo LN2410.

5.3.3 Compilando Windows CE 5.0 con Platform Builder Platform Builder es un entorno gráfico de desarrollo. Con él crearemos

proyectos que tendrán como objetivo desarrollar un sistema operativo Windows CE 5.0 adecuado a las necesidades de cada uno.

Su entorno se basa en el modelo de arrastrar y soltar módulos sobre el proyecto en el que estemos trabajando.

En la parte de la izquierda tenemos el proyecto que estamos construyendo y en la parte de la derecha los módulos disponibles. Está separado por secciones en función de nuestras necesidades. Tenemos la sección BSP’s, dedicada a los BSP que vienen de serie con Platform Builder y que hacen referencia a algunos modelos de placas de desarrollo empotrado existentes en el mercado. La sección Core OS es muy interesante porque es la sección principal que incluye absolutamente todas las opciones disponibles para la personalización del sistema operativo. Separado por las funciones finales de cada módulo podemos dotar a nuestro sistema operativo empotrado de soporte para aplicaciones .NET, conexiones inalámbricas por USB, impresión por Bluetooth, cliente para servidor de correo Exchange, visor de presentaciones realizadas con Powerpoint y un sinfín de aplicaciones que podemos encontrar en cualquier sistema operativo. Como sólo instalaremos las funciones necesarias para cada proyecto conseguimos un rendimiento muy bien unido a un tiempo de carga del sistema operativo y tamaño de imagen binaria mínimo.


Figura 5.19: Entorno de desarrollo con Platform Builder

En Device Drivers encontraremos todos los controladores de dispositivos

que podemos necesitar. Pero, debemos prestar atención a una sección llamada Third Party que no es más que la sección donde se han instalado los controladores suministrados por el fabricante para gestionar la placa de desarrollo LN2410 y que deben estar todos incluidos siempre ya que de otra manera tendríamos resultados imprevisibles con partes de hardware que no estarían operativas.

Tenemos una configuración base, incluida en el paquete BSP, sobre la que retocaremos lo necesario para adaptarla a nuestro proyecto en C:\WINCE500\PBWorkspaces\LN2410SBC_P\LN2410SBC_P.pbxml

Una vez que tenemos todo configurado, con los módulos que queremos incluir, los ficheros personalizados y demás compilamos el sistema operativo junto con el sistema de ficheros con la opción Build OS -> Sysgen.

Es un proceso bastante largo pero al final veremos como ha finalizado con algún aviso pero sin errores. Esto significa que tenemos que descargarla a la placa de desarrollo LN2410.


5.3.4 Descarga de Windows CE 5.0 en la placa LN2410 Para descargar la imagen generada por Platform Builder en la placa de

desarrollo LN2410 es necesario establecer una conexión entre Platform Builder y la placa. Para ello tenemos un apartado dedicado en la opción del menú Target.

Con la placa encendida y conectada vía serie por Hyperterminal y vía Ethernet con un cable cruzado, entramos en el menú de configuración del cargador de arranque apretando la tecla Espacio. Ahora tenemos la placa en espera. Nos vamos a la opción de Platform Builder, Target->Connectivity Options y hacemos clic. En las opciones que nos aparecen debemos seleccionar Download->Ethernet para indicarle que vamos a proceder con la descarga de la imagen vía Ethernet. Hacemos clic en Settings donde nos aparecerá nuestra placa. La seleccionamos y hacemos clic en OK.

Figura 5.20: Conexión entre la placa LN2410 y Platform Builder

Ahora hacemos clic en Apply y ya tenemos configurada la vinculación entre

nuestra placa y Platform Builder. Finalmente para asociarlas al proyecto que tengamos abierto en ese

momento hacemos clic en Target->Attach Device, y desde ese momento tendremos vinculadas permanentemente la placa a ese proyecto. Si una vez configurado y compilado Windows CE 5.0 queremos descargarlo en la placa para ver su rendimiento, tan sólo es necesario conectarse a la placa vía serie por Hyperterminal y seleccionar la opción “E”. Acto seguido la placa envía una señal que reconoce Platform Builder e inicia la descarga a través del puerto Ethernet. Una vez descargada, y según la configuración establecida en el cargador de arranque, esa imagen binaria se copiará a la memoria NAND para hacer la carga permanente.


Figura 5.21: Descarga imagen Windows CE a la placa

Si todo ha ido correctamente, arrancaremos Windows CE 5.0 por primera

vez. Después de calibrar la pantalla veremos el familiar entorno de Windows.

Figura 5.22: Windows CE en la placa LN2410

5.4 Conexión al equipo host vía USB Como la mayoría de dispositivos móviles basados en Windows CE, la

placa de desarrollo LN2410 tiene la capacidad de comunicarse con un entorno


Windows a través del puerto USB Device montado en la placa para ese propósito.

Una vez en marcha Windows CE si conectamos el cable, nuestro equipo host lo reconocerá como si de cualquier otro dispositivo USB se tratara, por ejemplo un disco USB o un cámara de fotos. En concreto lo identificará como “Anchor USB EZ-Link Cable” y nos pedirá que instalemos el software apropiado. Instalaremos un software estándar para este tipo de aplicaciones. Para ello una vez se nos abra el asistente para la instalación de nuevo hardware encontrado, le decimos que no queremos que busque online y, seguidamente, marcaremos la opción de “Instalar desde una lista o ubicación específica” y haremos clic en Siguiente.

Figura 5.23: Instalación como USB Device

En la siguiente pantalla nos pedirá donde se encuentran los ficheros de

instalación. Típicamente se encontraran en un directorio que hayamos creado con el fin de estructurar todo nuestro proyecto y que puede ser, por ejemplo, C:\LN2410.

Introducimos el directorio donde se encuentran y hacemos clic en Siguiente.

Saltará un error sobre que el controlador no pasa la prueba del logotipo de Windows, hacemos caso omiso haciendo clic en Continuar


Figura 5.24: Hacemos caso omiso prueba logotipo Windows

Copiará los ficheros a los directorios oportunos y finalizará la instalación.

Haremos clic en Finalizar para salir de la instalación.

Figura 5.25: Finalizamos la instalación

A partir de este momento nuestro equipo Windows XP identifica la placa de

desarrollo LN2410 como un dispositivo móvil, a todos los efectos como si de una PDA o de un teléfono móvil se tratara. Por tanto, lo primero que hace s lanzar la aplicación predeterminada de Microsoft para ese fin, ActiveSync.

Aparecerá un cuadro de diálogo informándonos que se ha detectado una asociación nueva y nos pregunta sobre que tipo de conexión queremos hacer.


Si seleccionamos que queremos configurar una asociación intentará sincronizar nuestra agenda, contactos, etc. Si no es nuestro deseo, marcamos no. Sea cual se la opción marcada se establecerá una conexión entre el equipo y el dispositivo empotrado.

Figura 5.26: Seleccionamos tipo asociación

Figura 5.27: Conectamos con el equipo

Esto significa que podemos instalar aplicaciones para dispositivos

empotrados, desarrollar aplicaciones con un entorno integrado de desarrollo como Visual Studio, copiar y eliminar ficheros entre otras.

En la siguiente imagen vemos como podemos explorar el dispositivo.


Figura 5.28: Exploración placa LN2410

5.5 Ejemplo desarrollo de un aplicación con Visual Studio

Vamos a ilustrar el desarrollo de una aplicación simple, tipo “Hola mundo”,

para mostrar la sencillez de trabajo sobre la placa LN2410 en conjunción con el entorno de desarrollo integrado Visual Studio de Microsoft.

Una vez abierto Visual Studio seleccionaos File->New->Project.

Figura 5.29: Creamos un nuevo proyecto


El tipo de proyecto debe ser uno orientado a sistemas empotrados o Smart Devices, lo podemos desarrollar en cualquier lenguaje de programación soportado por Visual Studio. Para el ejemplo seleccionaremos Visual C# y escogeremos una plantilla para desarrollar una aplicación gráfica con Device Application.

Figura 5.30: Especificamos tipo de aplicación

Una vez construida la típica aplicación “Hola mundo”, conectamos la placa

de desarrollo mediante el cable USB como se indica en el apartado anterior y veremos como nuestro equipo host Windows XP la ha detectado correctamente.

Es muy importante conectar la placa al mismo puerto USB donde se instaló la primera vez ya que sino es posible que nuestro equipo Windows se reinicie dando un excepción por un error con la asignación IRQ.

La placa de desarrollo LN2410 deberá estar correctamente conectada a la alimentación y con el sistema operativo Windows CE 5.0 ejecutándose completamente para que se inicialice el subsistema que permite la conexión y depuración mediante ActiveSync de Microsoft.


Figura 5.31: Conectamos la placa de desarrollo LN2410

Ahora que tenemos todas las conexiones realizadas y están operativas,

apretamos F5 o hacemos clic en el botón de Play para empezar el proceso de conexión y descarga en la placa LN2410.

Como esta aplicación está basada en el framework .NET, la primera tarea que se realizará es la actualización del sistema operativo incluyendo las últimas actualizaciones de la plataforma que disponga el equipo host. Por ello es necesario tenerlo actualizado en la medida de lo posible.

Finalmente nos preguntará para qué plataforma se realizará la descarga. Como nuestra plataforma pertenece al sistema operativo Windwos CE 5.0 seleccionaremos Windows CE 5.0 Device y haremos clic en Deploy.


Figura 5.32: Descarga de la aplicación en la placa LN2410

Si todo ha ido correctamente veremos nuestra aplicación ejecutándose en

la placa y podremos depurarla desde nuestra equipo host Windows XP.

Figura 5.33: Hola mundo en LN2410



Capítulo 6

Coste de realización El hecho de que este proyecto partiera de una base con muy poca

documentación ha exigido un esfuerzo mayor en la parte de investigación, tanto de búsqueda de información como en ensayos prueba-error.

Después de todo el proceso de investigación se ha conseguido convertir toda esa búsqueda en una serie de procesos específicos para cada función. Por ejemplo, siguiendo los pasos correctos el tiempo requerido para instalar un sistema operativo sobre la placa de desarrollo LN2410 es mínimo.

Durante meses se ha buscado referencias, ejemplos e información por Internet para depurarla y enfocarla a nuestra placa. Además del tiempo empleado en el desarrollo y en la memoria. Por tanto, el cómputo de horas es el siguiente:

Coste de realización:

40%

25%

21%

14%

Búsqueda

InvestigaciónDesarrolloDocumentación

En total han sido necesarias alrededor de 960 horas para toda la

realización del proyecto. El hecho de encontrarnos con una plataforma hardware extremadamente compleja con apenas manuales o documentación han disparado la dedicación de horas.


Capítulo 7

Conclusiones Las conclusiones están separadas es tres áreas diferenciadas

correspondientes a las tres partes de la placa de desarrollo LN2410. Respecto a la parte hardware nos encontramos con una plataforma basada

en el modelo de placa de desarrollo de Samsung 2410 pero con muchísimas mejoras. Es un modelo que aporta un procesador rápido, una cantidad de memoria más que generosa, una pantalla táctil de un tamaño adecuado además de todas las opciones de comunicaciones y expansión que ofrece. Además contamos con un precio bastante reducido en placas con hardware similar. Incluyendo toda la investigación y la búsqueda que se ha realizado hemos completado con éxito la configuración e instalación de este hardware sobre dos de los sistemas operativos más conocidos. Podemos establecer comunicaciones por Bluetooth sin problemas desde Linux evitando el coste de las licencias o crear completos sistemas empotrados multimedia con Windows CE. Todo ello gracias a un hardware más que completo.

Incluso esta preparado para admitir más dispositivos hardware que no vienen incluido en la placa como discos duros o lectores de DVD.

El lanzamiento al mercado de su hermana mayor la LN2440, implica una madurez de hardware que la hace mucho más compatible y, por tanto, más llevable a un entorno docente o dedicado a proyectistas o intensificadores.

En cuanto a los sistemas operativos que se han conseguido instalar en este sistema empotrado ambos tienen sus ventajas e inconvenientes y, por tanto, deberemos dejar que sea la aplicación objetivo la que dedica en que sistema operativo correrá.

Linux Embedded cuenta con múltiples y potentes características, se ha centrado el proyecto en la comunicación por Bluetooth consiguiéndose completamente. Es un sistema operativo rápido, potente y conocido por los alumnos. Ha requerido de un esfuerzo adicional por mi parte ya que la especialidad cursada no se centraba en profundidad en la implementación e instalación de Linux. Se ha comprobado su estabilidad la completa compilación del código de diferente software de una arquitectura a otra, ya que trabajamos en plataformas Intel pero desarrollamos para ARM. Linux es un sistema abierto ampliamente modificable y configurable por el usuario que permite realizar prácticamente cualquier aplicación que se nos ocurra. Por contra, la complejidad del cargador de arranque debido a la falta de documentación de la placa de desarrollo LN2410 no ha permitido la instalación en la memoria NAND de un sistema de ficheros permanente que guarde tanto los datos nuevos como el sistema de ficheros, forzándonos a la descarga de todo el sistema cada vez que


se conecta a la alimentación. Cabe recordar que aunque no sea positiva la escritura continua en la memoria NAND, debido a su número limitado de escrituras, podríamos montar un sistema de ficheros de sólo lectura. Aunque por contra incorpora controladores para dispositivos IDE con lo que podríamos conectar un disco duro convencional.

Por otro lado el sistema operativo Windows es un sistema operativo que no es Open Source como Linux y, por tanto, deberemos comprar una licencia para trabajar con Platform Builder. Si que es cierto que mantiene una licencia de código compartido mediante la cual podemos modificar parte del código sin avisar al propietario. Es un sistema muy estable, muy fácil de instalar y configurar pero no permite un nivel de personalización tan elevado como Linux. Su mayor ventaja es que el sistema de ficheros permanece guardado en la memoria NAND junto con todo el núcleo del sistema y no hace falta descargar el sistema continuamente. Soporta multitud de dispositivos por su puerto USB con lo que tenemos tantas opciones de expansión como en su homólogo Linux. Pero su mayor logro es la total integración con entornos integrados de desarrollo de aplicaciones como Visual Studio. Tan sólo conectando un cable, nuestro equipo lo reconoce como un dispositivo y ya podemos empezar a programar aplicaciones para sistemas empotrados, incluso si la tenemos desarrollada utilizando frameworks como .NET no hace falta nada. Desde un entorno gráfico podemos descargar, depurar y controlar la ejecución de nuestra aplicación empotrada e incluso actualizar el sistema.

La placa de desarrollo es una oportunidad única para conocer de cerca todo lo relacionado con sistemas empotrados y los operativos que corren sobre ellos.

Es una muy buena aplicación tanto desde el punto de vista docente, para dotar de una primera visión de los sistemas empotrados al alumno, como para todos aquellos proyectistas que quieren desarrollar aplicaciones para sistemas distribuidos o para cualquier otro ámbito.


Capítulo 8

Líneas de futuro Existen multitud de líneas de futuro que intentaremos sintetizar el los

siguientes apartados:

• Movilidad: dotar de movilidad a la placa de desarrollo LN2410 sería muy importante para desarrollar múltiples aplicaciones de campo como GPS, puntos calientes de publicidad por Bluetooth, en los que al pasar cerca de ellos nos envían un mensaje al teléfono móvil con publicidad localizada, posicionadores locales capaces de triangular nuestra posición según la intensidad de la señal Bluetooth, analizadores de campo, etc.

• Sistema de ficheros: en Linux existen multitud de sistemas de ficheros. Una línea de investigación podría trabajar sobre su estudio orientado a hardware NAND donde las veces que escribimos son un punto a tener en cuenta.

• Soportes físicos: emplear el puerto IDE externo que tiene para conectar discos duros convencionales y así evitar el problema de la memoria NAND, quedando ésta relegada a almacenar el núcleo del sistema operativo, sino lo hace la memoria NOR, almacenando el sistema de ficheros en ellos.

• Entorno gráfico: explorar las posibilidades que ofrecen entornos gráficos prediseñados para Linux como Opie. Su viabilidad de instalación en la placa de desarrollo LN2410 así como su estabilidad y comparativa respecto a Windows.

• Aplicaciones distribuidas: la creación de entornos distribuidos autónomos empleando el hardware dedicado de comunicaciones de la placa para desarrollar aplicaciones distribuidas y comprobar su rendimiento.

• Domótica: utilizar la placa de desarrollo como unidad central de control, gestión y mantenimiento de instalaciones domóticas ya sea mediante su puerto Ethernet, una pastilla Bluetooth o por su puerto GPIO.

Como podemos comprobar las líneas de futuro tan sólo están limitadas por

nuestra imaginación.


Capítulo 9

Bibliografía

[1] ROGER WILSON (1988, 2 de abril). “Some facts about the Acorn RISC Machine” [en línea] [GOOGLE GRUPOS][Consultado: 9 de Septiembre 2007] disponible: http://groups.google.com/group/comp.arch/msg/269fe7defd51f29e [2] ARM (2001, 18 de abril). “ARM920T technical reference” [en línea] [ARM][Consultado: 21 de septiembre 2007] disponible: http://infocenter.arm.com/ help/topic/com.arm.doc.ddi0151c/ARM920T_TRM1_S.pdf [3] USB (2000, 27 de Abril). “The Original USB 2.0” [en línea] [USB][Consultado: 21 de octubre 2007] disponible: http://www.usb.org/developers/docs/ [4] CIRRUS LOGIC (2007, agosto). “Product Data Sheet” [en línea] [CIRRUS][Consultado: 1 de noviembre 2007] disponible: http://www.cirrus.com/en/pubs/proDatasheet/CS8900A_F4.pdf [5] IA/EIA STANDARD (1994, mayo), “Electrical Characteristics of Balanced Voltage Digital Interface Circuits”, TIA/EIA-422-B [6] MULTIMEDIA CARD ASSOCIATION (2007), “What is MMC?” [en línea] [MMCA][Consultado: 5 de noviembre 2007] disponible: http://www.mmca.org/technology/about/ [7] COMAPCT FLASH ASSOCIATION (2008, 17 de agosto), “Compactflash frequently asked questions” [en línea] [COMPACTFLASH][Consultado: 5 de noviembre 2007] disponible: http://www.mmca.org/technology/about/ [8] XILINX (2006, 3 de abril), “XC9572 In-System Programmable CPLD” [en línea] [XILINX][Consultado: 23 de noviembre 2007] disponible: http://www.xilinx.com/support/documentation/data_sheets/ds065.pdf [9] SAMSUNG ELECTRONICS CO. (2005, 17 de enero), “Product Information” [en línea] [DATASHEET4U][Consultado: 2 de octubre 2007] disponible: http://www.datasheet4u.com/share_search.php?sWord=LTV350QV-F04


[10] BOUNDARY-SCAN “IEEE 1149 Technology Summary” [en línea] [BOUNDARY-SCAN][Consultado: 5 de octubre 2007] disponible: http://www.boundary-scan.co.uk/page3.html [11] TAL, A. (2002, febrero), “NAND vs. NOR flash technology” [en línea] [electronicproducts][Consultado: 12 de octubre 2007] disponible: http://www2.electronicproducts.com/NAND_vs_NOR_flash_technology-article-FEBMSY1-FEB2002.aspx [12] HOLLABAUGH, C. (2002, 17 de marzo), “Embedded Linux(R): Hardware, Software, and Interfacing”, Addison-Wesley Professional, ISBN 0672322269 [13] Opdenacker, M. (2004-2007), “What’s new in Linux 2.6?” [en línea] [free-electrons][Consultado: 20 de octubre 2007] disponible: http://free-electrons.com/doc/linux26.pdf [14] Denk, W. (2005, 30 de noviembre), “Design Principles U-Boot” [en línea] [denx][Consultado: 15 de noviembre 2007] disponible: http://www.denx.de/wiki/U-Boot/DesignPrinciples [15] Denk, W. (2005, 30 de noviembre), “Uboot Cmd Group Environment” [en línea] [denx][Consultado: 19 de noviembre 2007] disponible: http://www.denx.de/wiki/view/DULG/UBootCmdGroupEnvironment#Section_5.9.6.2 [16] Kegel, D. (2006, 7 de diciembre), “Building and Testing gcc/glibc cross toolchains” [en línea] [kegel][Consultado: 4 de diciembre 2007] disponible: http://www.kegel.com/crosstool/ [17] Andersen, E. (1999-2008), “Busybox” [en línea] [busybox][Consultado: 20 de enero 2008] disponible: http://www.busybox.net/ [18] Andersen, E. (1999-2008), “Busybox – The Swiss Army Knife Of Embedded Linux” [en línea] [busybox][Consultado: 13 de febrero 2008] disponible: http://www.busybox.net/downloads/BusyBox.html [19] Bluez Project (2000-2008), “Bluez” [en línea] [bluez][Consultado: 4 de marzo 2008] disponible: http://www.bluez.org/ [20] “OpenOBEX” [en línea] [openobex][Consultado: 23 de marzo 2008] disponible: http://dev.zuckschwerdt.org/openobex [21] Haerr, G. (2005, Enero), “Greg Haerr's Nano-X Window System Page (previously Microwindows)” [en línea] [microwindows][Consultado: 2 de marzo 2008] disponible: http://www.microwindows.org/


[22] Tim Jones, M. (2006, 31 de julio), “Linux initial RAM disk (initrd) overview” [en línea] [IBM][Consultado: 4 de abril 2008] disponible: http://www.ibm.com/developerworks/linux/library/l-initrd.html [23] MICROSOFT CORPORATION (2008), “Welcome to Windows CE” [en línea] [MSDN][Consultado: 3 de mayo 2008] disponible: http://msdn.microsoft.com/en-us/library/ms905511.aspx [24] BLOGELECTRÓNICA (2007), “Historia del sistema operativo Windows CE” [en línea] [IBM][Consultado: 12 de mayo 2008] disponible: http://www.blogelectronica.com/historia-del-sistema-operativo-windows-ce/ [25] MICROSOFT CORPORATION (2008), “Platform Builder User’s Guide” [en línea] [MSDN][Consultado: 3 de mayo 2008] disponible: http://msdn.microsoft.com/en-us/library/aa448756.aspx


Capítulo 10

Agradecimientos Quisiera agradecer el soporte que me ha dado toda mi familia

incondicionalmente. Ellos saben porqué lo digo. A mi ponente, Xavier Canaleta, por ser un docente excelente y por ser un

modelo de profesional a seguir. Quisiera agradecer de igual manera a mi compañero de departamento, Hugo Meza, por aguantar interminables horas de conversación sobre los problemas que he tenido con la placa.

A todos mis amigos más cercanos que saben lo que es hacer un trabajo de final de carrera y a los que no. Todos ellos son partícipes de mi trabajo.

A todos aquellos que me han ayudado y que no he mencionado, perdonen mi memoria. Seguro que saben que no es muy buena.

Finalmente mi más sincero agradecimiento al Sr. Cios, Sr. Norrea. Ellos ya saben porqué.

Documents

Abstract - Salle-URLusers.salleurl.edu/~xavier.canaleta/memories/CarlesGarcia_TFC.pdf · Abstract Este trabajo analizará con detalle cada una de las partes de hardware de la placa