book

87
´ Indice general 1. PLATAFORMA DE DESARROLLO ECBOT 3 1.1. Introducci´ on .......................................... 3 1.1.1. Apropiaci´ on de Conocimiento ............................ 3 1.1.2. Contribuciones al desarrollo tecnol´ ogico en Colombia ............... 8 1.2. Sistemas Embebidos ..................................... 11 1.2.1. Caracter´ ısticas .................................... 11 1.2.2. Arquitectura ..................................... 12 1.2.3. Metodolog´ ıa de Dise ˜ no ................................ 13 1.2.4. Herramientas Software de libre distribuci´ on GNU toolchain ............ 15 1.2.5. Herramientas hardware ................................ 25 1.2.6. Interfaz JTAG ..................................... 31 1.3. El sistema Operativo Linux .................................. 35 1.3.1. Arquitectura de Linux [1] [2] ............................. 37 1.4. Portando Linux a la plataforma ECBOT y ECB AT91 .................... 42 1.4.1. El Kernel de Linux .................................. 42 1.4.2. Imagen del kernel ................................... 48 1.5. Inicializaci´ on del kernel .................................... 52 1.5.1. Darrel’s Loader .................................... 53 1.5.2. U-boot ........................................ 57 1.5.3. Portando U-boot a la familia de plataformas ECB AT91 .............. 58 1.5.4. Almacenamiento de la im´ agen del kernel ...................... 63 1.5.5. Inicializaci´ on del Kernel ............................... 65 1.6. Inicializaci´ on del Sistema ................................... 69 1.6.1. Sistema de Archivos ................................. 69 1.6.2. Primer Programa en Espacio de Usuario init ..................... 71 1

Transcript of book

Page 1: book

Indice general

1. PLATAFORMA DE DESARROLLO ECBOT 3

1.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.1. Apropiacion de Conocimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.2. Contribuciones al desarrollo tecnologico en Colombia . . . . . . . . . . . . . . . 8

1.2. Sistemas Embebidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.2.1. Caracterısticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.2.2. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.2.3. Metodologıa de Diseno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.2.4. Herramientas Software de libre distribucion GNU toolchain . . . . . . . . . . . . 15

1.2.5. Herramientas hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

1.2.6. Interfaz JTAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

1.3. El sistema Operativo Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

1.3.1. Arquitectura de Linux [1] [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

1.4. Portando Linux a la plataforma ECBOT y ECB AT91 . . . . . . . . . . . . . . . . . . . . 42

1.4.1. El Kernel de Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

1.4.2. Imagen del kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

1.5. Inicializacion del kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

1.5.1. Darrel’s Loader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

1.5.2. U-boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

1.5.3. Portando U-boot a la familia de plataformas ECB AT91 . . . . . . . . . . . . . . 58

1.5.4. Almacenamiento de la imagen del kernel . . . . . . . . . . . . . . . . . . . . . . 63

1.5.5. Inicializacion del Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

1.6. Inicializacion del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

1.6.1. Sistema de Archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

1.6.2. Primer Programa en Espacio de Usuario init . . . . . . . . . . . . . . . . . . . . . 71

1

Page 2: book

2 Sistemas Embebidos

1.6.3. Distribuciones Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

1.7. Modulos del kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

1.7.1. Ejemplo de un driver tipo caracter . . . . . . . . . . . . . . . . . . . . . . . . . . 75

1.8. Interfaz con Perifericos dedicados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

1.8.1. Comunicacion Procesador - Periferico . . . . . . . . . . . . . . . . . . . . . . . . 79

1.8.2. Comunicacion Periferico - Procesador . . . . . . . . . . . . . . . . . . . . . . . . 83

Page 3: book

Capıtulo 1

PLATAFORMA DE DESARROLLOECBOT

1.1. Introduccion

Uno de los objetivos principales del presente trabajo es la realizacion de actividades que ayude alpaıs en su desarrollo tecnologico; en la actualidad Colombia es un consumidor de tecnologıa, es decir, buscaen el exterior soluciones a sus problemas, en la mayorıa de las ocasiones, estas soluciones no se ajustan alos requerimientos, ya que no tienen en cuenta la situacion polıtica, cultural y social del paıs. En la mayorıade los casos, no se aumenta el conocimiento tecnologicos del paıs, y reduce las opciones de negocios paralas empresas locales a representantes de ventas o suministro de sevicios de mantenimiento.

Este esquema es nocivo para la industria Colombiana, ya que no existen mecanismos que permitasu desarrollo, protegiendola de alguna forma frente a los productos foraneos. Esto unido a las politicas deestado encaminadas a la apertura comercial, en donde los productos nacionales compiten con productos depaises con mayor desarrollo tecnologico nos llevara a la eliminacion total de la industrias Colombianas. Acontinuacion se presenta un resumen del estudio realizado por Hector Martınez sobre la Apropiacion delconocimiento en Colombia [3] durante los anos 1991 a 2000.

1.1.1. Apropiacion de Conocimiento

Para que Colombia deje de ser un paıs que consume tecnologıa y llegue en algun momento a sergenerador de productos tecnologicos, es necesario que se genere un conocimiento que permita esta transi-cion. “Para que el conocimiento sea motor de desarrollo es necesario el traspaso desde sus creadores a lasociedad, mediante la conversion a tecnologıas que produzcan cambios radicales que incrementen la pro-duccion. Esa transmision de tecnologıa generadora de crecimiento economico esta influenciada por diversosfactores: medio geografico, leyes de propiedad industrial, costos laborales, nivel de ciencia y tecnologıa, re-ligion, tipos de instituciones, resistencia a innovar, polıticas de estado, guerras, factores demograficos, entreotros” [4]

Pero como apropiar este conocimiento? Arrow [5] afirma que la apropicacion de conocimiento puedeefectuarse de varias formas: “aprender haciendo”, “aprender usando”, “aprender leyendo”. Cuando una em-presa decide transmitir su conocimiento disponible, lo hace en procesos de investigaciones conjuntas, en

3

Page 4: book

4 Sistemas Embebidos

actividades de produccion, y distribucion, mercadeo, servicio y soporte operativo o riesgo compartido. Tam-bien se presentan alianzas entre firmas como: contratos de I+D, acuerdos de licencias, licencias cruzadas. Laconformacion de estas asociaciones permite crear redes tecnologicas dominadas por paıses industrializadoscon sus respectivas empresas multinacionales monopolizando conocimiento [3]

Para Colombia, el problema radica en que mediante contratos de importacion de tecnologıa, lasempresas de capital nacional no estan adquiriendo el conocimiento necesario para lograr innovaciones alinterior de las mismas. De forma que puedan ser competitivas y logren acceder a mercados internacionalesofreciendo productos innovadores, de calidad y a precios competitivos. Con efectos directos como: gen-eracion de empleos especializados, desarrollo tecnologico e industrial sostenido, ampliacion del acervo deconocimiento nacional y disminucion de la salida de divisas (al mejorar los procesos de negociacion) ycreacion de externalidades positivas [3].

Ligado al problema de la senda tecnologica esta el del grado de lo tacito del conocimiento cientıfico.Teece [6] senala que al existir conocimiento tacito toda la tecnologıa disponible no se transfiere de losproductores a los receptores o compradores de la misma. Por tanto, los paıses seguidores siempre van aestar a la zaga tecnologica. Forbes y Wield [7] senalan que los esfuerzos adaptativos son mayores porquedeben acomodar las “innovaciones” a los materiales locales, fuerza laboral nativa, mercados internos ymedio ambiente local. Entonces, el problema no se limita a como transferir conocimiento, como develarsu parte tacita y como extraerlo de las multinacionales, sino que radica en el bajo poder de negociacion yadquisicion de tecnologıa por firmas pequenas y medianas, las cuales carecen de recursos y tienen procesosdeficientes de contratacion.

En este orden de ideas, si el paıs no es un innovador neto ¿no deberıa mas bien mostrar una ten-dencia a importar conocimiento? Y las firmas nacionales ¿no deberıan ser las que mas efectuaran este tipode contratos, para ası acceder al conocimiento de la tecnologıa adquirida? En resumen, conociendo mejorque tecnologıa se importa y que tipos de contratos se utilizan, es posible crear marcos de referencia paraempresas nacionales que esten interesadas en adquirir tecnologıa. Esto producirıa externalidades positivasen empresas importadoras de conocimiento y, a su vez, en la economıa del paıs. Con una adecuada im-portacion de conocimientos tecnologicos se crearıa una ventaja competitiva de caracter estructural, basadaen un acervo de conocimiento tecnologico que permita incrementar la productividad en todos los sectoreseconomicos de manera permanente [3].

Segun los estudios realizados por Martınez, con base en registros del Decreto 259/92, del Incomex.La importacion de conocimiento no esta siendo empleada con el proposito de utilizar tecnologıas de puntaque permitan efectuar innovaciones al interior de las empresas y de los sectores. Las empresas nacionalesse limitan a comprar un determinado dispositivo, sin tener el conocimiento para operarlo, hacerle manten-imiento ni mucho menos mejorarlo, por lo que se ven obligadas a contratar con el vendedor contratos paradicho fın. Esto indica que la adquisicion de tecnologıa no se realiza con base en programa desarrollado deantemano, sino son una respuesta a cambios en el mercado, lo cual evidencia la inexistencia de programasde innovacion encaminados a la disminucion de la brecha tecnologica.

Situacion de la Industria Electronica en Colombia

La industria electronica nacional no es ajena a las polıticas que siguen las empresas nacionales encuanto a la apropiacion de tecnologıa; Colombia depende totalmente de economıas mas desarrolladas parael suministro de dispositivos electronicos en diversas areas (comunicaciones, entretenimiento, industria,medicina, etc). Mientras en otros sectores de la economıa han pasado de ser consumidores a exportadores,y adquieren nuevas tecnologıas para ser mas competitivos, el sector electronico del paıs ha reducido susactividades de Investigacion y Desarrollo hasta el punto de depender totalmente de productos externos unosde baja calidad y que no suplen los requerimientos del mercado local, pero que son muy economicos.

Page 5: book

Carlos Ivan Camargo Bareno 5

En la actualidad la industria electronica presenta una gran dinamica a nivel mundial, el uso de lossistemas electronicos se extiende a todas las actividades humanas; La demanda mundial de este tipo desistemas aumentara de forma dramatica en los proximos anos, especialmente en los sectores de tecnologıamedica, movilidad, seguridad, comunicaciones y consumo [8]. El mercado de los sistemas embebidos es unaindustria que movio alrededor de 25 billones de dolares en el 2008 segun Venture Development Corporation[9]. Por otro lado, la inversion de capital necesaria para el diseno de Sistemas Embebidos es relativamentebaja, gracias a la gran demanda originada, los insumos y los servicios de fabricacion son muy economicos,por otro lado, las herramientas de desarrollo necesarias para la programacion y depuracion de este tipo desistemas son de libre distribucion.

Desafortunadamente en Colombia la industria electronica se encuentra muy rezagada en relacion alas de los paıses industrializados, y las ventajas y oportunidades de negocios mencionadas anteriormente noson aprovechadas en la actualidad.

Segun ASESEL 1 en el 2001 existıan 154 empresas productoras de componentes y equipos de lacadena electronica.

Dentro de los productos que la industria electronica exporta se encuentran registrados: Circuitos in-tegrados, circuitos impresos, microestructuras, instrumentos para medida y control, Instrumentos y aparatoselectricos o electronicos. Es importante decir que la industria colombiana, en la actualidad no fabrica cir-cuitos integrados, ni microestructuras, por lo que estas son ventas de productos comprados en paıses de-sarrollados. Segun Proexport el 91 % de las exportaciones son realizadas por Bogota y los destinos seencuentran en paıses cercanos como Venezuela, Peru, Ecuador y USA.

La electronica en Colombia y en el mundo hace parte de esas industrias que se mueven velozmenteen un camino desconocido, como consecuencia se hace necesario tener una actualizacion constante de losavances tecnologicos y las proyecciones futuras del sector. Debido a la importancia del sector tecnologicoes primordial que en Colombia se este consciente del estado actual y que se puede hacer en terminos deInvestigacion Cientıfica y Desarrollo Tecnologico (I+D) en Ingenierıa Electronica.

Un estudio realizado en la Universidad Nacional de Colombia [10] identifico los siguientes obstacu-los para el desarrollo de la industria electronica en Colombia: Deficientes relaciones Universidad Empresa,Pobre enfoque academico hacia la industria, Calidad de los productos nacionales, polıticas gubernamen-tales, falta de cultura de Investigacion y Reducida apropiacion tecnologica, competencia de paıses asiaticos,atraso tecnologico, limitado recurso humano con formacion avanzada.

De los problemas expuestos anteriormente podemos identificar cuales son los que mas afectan eldesarrollo de la industria electronica en Colombia, el que mas perjudica sin lugar a dudas es el atraso tec-nologico, no es posible ser competitivo en el mercado electronico mundial con tecnologıas y metodologıasde diseno obsoletas, en Colombia trabajamos aun con circuitos integrados que se crearon en la decada delos 80 del siglo pasado y utilizamos lenguajes de programacion como el assembler, para el cual el tiempode aprendizaje, desarrollo y de depuracion es muy largo. La culpa de este atraso tecnologico no es exclusivade la induatria, aunque, como vimos anteriormente muchas industrial Colombianas se resisten al cambio yprefieren comprar equipos en el exterior a buscarlos localmente, la falta de confiabilidad en los productosColombianos agrava este problema, esta falta de confianza en la industria local no es infundada, la mayorıade los productos Colombianos no cumplen con las normas mınimas de calidad y utilizan productos de bajocosto obtenidos en remates de componetes.

Otro actor que contribuye al retraso tecnologico es el sector academico; segun el Sistema Nacional deInformacion Superior, durante los ultimos 10 anos se han abierto 230 programas relacionados con la indus-tria electronica, estos programas estan repartidos entre programas de formacion Universitaria, tecnologicaterminal y de tecnica profesional, la mayorıa de estos centros de formacion se encuentran ubicados en 3 De-

1Asociacion de entidades del Sector Electronico

Page 6: book

6 Sistemas Embebidos

partamentos: Bogota, Antioquia y Valle [11]. El numero de Ingenieros graduados en un ano es entre 2 y 8veces mayor que en los paıses en vıa de desarrollo y doce veces mayor que los que se graduan en los paısesdesarrollados, en Colombia, este aumento es aportado por instituciones de poca consolidacion. Ademas laspreferencias en la educacion superior son Formacion tecnica / form. tecnologica / form. profesional que esjustamente lo opuesto a la de los paıses desarrollados [12].

Por otro lado, el contenido de las asignaturas relacionadas directamente con la industria electronicase encuentran muy desactualizados, y fuera del contexto mundial, se utilizan metodologıas de diseno an-tiguas en las que primaba la experiencia del disenador, se realizan tareas manuales, repetitivas que puedenser realizadas por herramientas de diseno moderno, los currıculos son conservadores hay poca experi-mentacion y su estructuracion y metodologıas son muy clasicas. Otro problema adicional radica en la faltade experiencia en el sector productivo por parte del personal academico, un componente importante de losprofesores nunca han sido parte de un proceso productivo o de un proceso de desarrollo que tenga como fınla creacion de un producto comercial, razon por la cual se evita la experimentacion y se da mas enfasis alanalisis y solo se llega a una simulacion.

De lo anterior podemos concluir que en Colombia se presenta una sobre-oferta de profesionales enel area electronica, muchos de los cuales provienen de instituciones educativas con poca consolidacion, yque han sido formados con programas desactualizados que no tienen en cuenta los avances tecnologicos ymetodologicos, lo cual explica la pobreza de ingenieros con altos niveles de formacion. Por esta razon noes de extranar la poca confianza que tienen los industriales en los productos nacionales.

Lo anterior unido a la falta de polıticas de estado que: tracen normas encaminadas a incentivar lainversion en investigacion y desarrollo, defina lıneas y campos de investigacion, regulacion de la ofertalaboral, regulacion de los programas academicos, generan el clima perfecto para que el atraso tecnologicose mantenga durante mucho tiempo y Colombia no deje de ser un consumidor de tecnologıa.

Pasos a seguir para iniciar la solucion al problema de atraso tecnologico

Estudios consultados [12] [11] [10] [3], coinciden en que para dar solucion a los problemas expuestosanteriormente se deben seguir las siguientes recomendaciones:

Al gobierno:

Fomento gubernamental de centros de investigacion y productividad para fortalecer la relacionesuniversidad empresa.

Fomentar cooperacion internacional e inversion extranjera con transferencia de tecnologıa. a nivelgubernamental, Apoyo del gobierno a personas que tienen un alto potencial de crear y desarrollartecnologıa.

Definir agendas de investigacion acordes con las tendencias mundiales y desarrollar capacidades enel paıs.

A los centros de Ensenanza:

Creacion de portafolio de servicios.

Realizar seminarios y lıneas de profundizacion de temas afines a la administracion y la gerencia enempresas de base tecnologica.

Montar laboratorios de pruebas e incentivar los productores nacionales para que logren una calidadque cumpla con los estandares internacionales.

Page 7: book

Carlos Ivan Camargo Bareno 7

Infraestructura institucional que impulse la actualizacion tecnologica en el sector mediante desarrollode proyectos de tecnologıa de punta con una posible transferencia de tecnologıa.

Incentivar la formacion de maestrıas y doctorados nacionales acorde con una agenda de investigacion.

Realizacion de proyectos de aplicacion.

El contacto con las empresas no debe ser encargada unicamente a los estudiantes, la Universidad debedesarrollar las competencias que la empresa requiere.

Interaccion entre Universidades, Conviene que buena parte de los trabajos realizados en doctoradosean de investigacion aplicada, orientadas a mejorar la productividad del sector empresarial

Innovacion curricular, actualizacion continua de profesionales.

Las facultades de Ingenierıa deben acompanar las demandas que surgen del sector productivo.

Necesidad de mejorar las competencias y habilidades generales de los ingenieros, (continuo apren-dizaje) habilidad para innovar, investigar, desarrollar nueva tecnologıa.

Estado de la Electronica Digital en la Universidad Nacional de Colombia

Hasta hace un ano en las asignaturas del area de electronica digital de la Universidad Nacional deColombia (La Universidad mas grande e importante del pais), se trabajaba con dispositivos que fueronsacados al mercado en 1966 y 1968, las familia logica TTL 7400 y CMOS 4000. El problema principal alutilizar esta tecnologıa no es su ano de creacion, ni siquiera que en la actualidad se consideren obsoletas parael diseno de un sistema digital completo. 2 El problema detras del uso de esta tecnologıa se encuentra en laausencia total de metodologıas de diseno (en el caso Colombiano). Y el desconocimiento en herramientastipo CAD. El proceso de diseno que realizaban los estudiantes era:

1. Especificaciones del sistema.

2. Generacion manual de ecuaciones boolenas.

3. Minimizacion manual utilizando mapas de Karnaugh.

4. Implementacion de las ecuaciones minimizadas utilizando las familias logicas 7400 y 4000, sobreplacas de pruebas (protoboards, breadboards)

5. Pruebas del sistema.

A manera de ejercicio academico se justifica el uso de las familias 7400 y 4000, sin embargo, elquedarse ahi no es bueno para una industria electronica desactualizada, debido a que este tipo de imple-mentaciones no pueden generar productos competitivos a nivel mundial. La razon de esto es que existenmuchas fuentes de error en el proceso, generados por la ausencia de herramientas CAD que realizan lasoperaciones tediosas como las minimizacion de ecuaciones booleanas, las cuales estan sujetas a erroreshumanos originados por cansancio, falta de concentracion, etc. Otro aspecto que vale la pena resaltar esla falta de ua simulacion funcional, la mayorıa de los estudiantes consultados no realizaban simulacionesfuncionales y preferıan probar el diseno una vez implementado fısicamente, esto unido a la dificultad dedepuracion innata a este tipo de implementaciones, aumentaba considerablemente el tiempo requerido pararealizar las pruebas al sistema.

2En la actualidad estas compuertas se utilizan para la implementacion de pequenas operaciones logicas

Page 8: book

8 Sistemas Embebidos

A los problemas mencionados anteriormente se suma la gran cantidad de circuitos integrados nece-sarios para implementar un sistema sencillo, se observaron hasta 8 placas de pruebas con cerca de 50 cir-cuitos integrados interconectados entre sı, lo cual aumenta las posibles causas de error y aumenta el tiempode desarrollo en forma considerable.

En el segundo curso del area de electronica digital, se introduce al estudiante al uso de los dispos-itivos logicos programables (PLD) y los lenguajes de descripcion de hardware (HDL) como herramientaspara el diseno de sistemas digitales, al comienzo, el contenido de estos cursos se limitaba al uso de unaherramienta de diseno y la ensenanza de nociones basicas del lenguaje VHDL, se daba mas importanciaal uso de la herramienta y no a la metodologıa de diseno, de nuevo el estudiante ataca los problemas sinuna metodologıa de diseno clara. Vale la pena indicar que este curso fue dictado por profesores ocasionalesdurante los ultimos cuatro anos, cada profesor utilizaba contenidos y niveles de exigencia diferentes.

En la tercera parte del curso se trabaja con sistemas microcontrolados, se utilizan microcontroladoresde 8 bits de diferentes familias y se utiliza el lenguaje ensamblador como herramienta de desarrollo. Una delas principales desventajas que presenta este curso (y de la lınea en general) es la falta de continuidad en loscontenidos y en la metodologıa utilizada, ya que el contenido de este curso se encuentra totalmente desliga-do al de los dos anteriores. Sin embargo, durante este curso se proporciona una metodologıa de diseno en laque los estudiantes emulan el comportamiento del microcontrolador antes de ser programado, sin embargo,esta practica no es seguida por la mayorıa de los estudiantes, una posible causa de este comportamientopuede ser la falta de metodologıas de diseno en los cursos anteriores.

La sensacion que queda al terminar el area de electronica digital es que lo unico que importa sonlos microcontroladores y que lo visto en los primeros cursos no es muy util. La siguiente tabla muestra losproblemas encontrados en el area de electronica digital de las carreras de Ingenierıa Electrica y Electronicade la Universidad Nacional de Colombia:

1. Falta de una metodologıa de diseno.

2. Utilizacion de herramientas obsoletas: Familias Logicas, lenguajes de programacion.

3. Poco uso de las herramientas CAD.

4. Falta de continuidad en las asignaturas.

5. Falta de docentes.

6. No se suministra una formacion adecuada que ayude a la industria electronica a salir del retrasotecnologico.

1.1.2. Contribuciones al desarrollo tecnologico en Colombia

Durante la realizacion de esta investigacion se llevaron a cabo varias actividades, cuyo objetivo prin-cipal es contribuir al desarrollo tecnologico en Colombia, como se expuso anteriormente el paıs presentaserias dificultades en este campo y es deber de la comunidad academica nacional atacar los problemas lo-cales. Por esta razon unoa de las matas del presente trabajo fue la creacion de una plataforma hardware quepermita implementar las diferentes modelos bio-inspirados. En la mayorıa de estudios similares no se con-templa la creacion de estas plataformas ya que en los paıses donde se desarrollan la investigacion existe unaindustria electronica competitiva y que esta al tanto de los desarrollos tecnologicos a nivel mundial. Comose menciono anteriormente este no es el caso de nuestro pais, en la mayorıa de las industrias nacionales yen las facultades relacionadas con la electronica se trabaja con tecnologıas de hace 30 anos (Familias 74TTL y 40 CMOS) y se utilizan herramientas de programacion de bajo nivel como el lenguaje ensamblador.

Page 9: book

Carlos Ivan Camargo Bareno 9

A continuacion se mestran una lista del trabajo realizado sobre algunas de las recomendacionesdadas por los estudios acerca del desarrollo tecnologico en Colombia; vale la pena anotar que no todasestan dentro del alcance de este trabajo, se eligieron en las que se podıa hacer un aporte significativo.

1. Realizacion de proyectos de aplicacion: La primera decision que se tomo en cuanto a la naturalezade esta investigacion fue la de generar una aplicacion fısica real que validara los modelos propuestos,este trabajo no se limitara a realizar simulaciones, sino que se construira una plataforma que seatecnologicamente “moderna” y que este al nivel de las plataformas utilizadas en estudios similares.Para esto se diseno la primer Computadora en una sola placa (SBC 3) que utiliza un procesador de32 Bits y utiliza Linux como sistema operativo 2

2. Infraestructura institucional que impulse la actualizacion tecnologica en el sector mediante desarrollode proyectos de tecnologıa de punta con una posible transferencia de tecnologıa:

3. El contacto con las empresas no debe ser encargada unicamente a los estudiantes, la Universidad debedesarrollar las competencias que la empresa requiere.

4. Interaccion entre Universidades, Conviene que buena parte de los trabajos realizados en doctoradosean de investigacion aplicada, orientadas a mejorar la productividad del sector empresarial

5. Innovacion curricular, actualizacion continua de profesionales.

6. Necesidad de mejorar las competencias y habilidades generales de los ingenieros, (continuo apren-dizaje) habilidad para innovar, investigar, desarrollar nueva tecnologıa.

Contribuciones a Nivel Tecnologico y Academico

En este capıtulo se realiza la presentacion de la plataforma Hardware y Software utilizada en eldesarrollo de esta investigacion. Uno de los objetivos de este trabajo, es la creacion de una plataformaEmbebida que permita la apropiacion de nuevas herramientas y metodologıas de diseno. El mercado de lossistemas embebidos continua en aumento y su campo de accion se ha extendido en casi todas las actividadeshumanas. Segun BBC, inc. 4 el mercado para el software embebido puede crecer de $1.6 billones a $3.5billones en 2009, con una tasa de crecimiemto anual (AAGR) del 16 %, mientras la tasa de crecimiento paralas tarjetas embebidas es del 10 %. (Favor ver Figura 1.1).

Esto unido a: el gran nivel de integracion obtenido por la industria de los semiconductores en losSOC, la disponibilidad de herramientas software de desarrollo gratuitas (compiladores, simuladores, libr-erıas, Sistemas Operativos) abre grandes posibilidades comerciales para paises en vıa de desarrollo ya queno son necesarias grandes inversiones de capital para la implementacion de estos sistemas.

Mas de un billon de dispositivos embebidos fueron vendidos en el 2004, segun Venture DevelopmentCorporation (VDC). De acuerdo con VDC el porcentaje de dispositivos basados en Sistemas Operativoscomerciales tiende a disminuir callendo del 43.1 % en 2001 a 37.1 % en 2004, esta tendencia se debe alaumento de complejidad de los dispositivos y a las necesidades de conexion (tales como Ethernet, bluetooth,WiFi, etc); ademas, la caida de precios del hardware, elimina la necesidad de eficiencia en el manejo derecursos proporcionada por muchos productos comerciales. Otro factor es el deseo de utilizar el mismoSistema Operativo para varios proyectos.

Recientes investigaciones de VDC sugieren que entre el 13 y el 15 % de los desarrolladores utilizanlinux como su sistema operativo principal, y se espera que esta cifra aumente al madurar la tecnologıa y

3Single Board Computer4http://www.bccresearch.com/

Page 10: book

10 Sistemas Embebidos

Figura 1.1: Mercado Global de Sistemas Embebidos 2003-2009. Fuente: BCC Inc.

el soporte de los recursos de la comunidad aumenten. La figura 1.2 muestra una encuenta realizada a 932desarrolladores de todo el mundo por linuxdevices 5

Figura 1.2: Preferencia de Sistema Operativo para Sistemas Embebidos 2003-2007. Fuente: linuxdevices.

La eleccion de Linux como herramienta de desarrollo esta fuertemente influenciada por su carac-ter libre, la gran disponibilidad de herramientas de desarrollo, aplicaciones, librerıas y la posibilidad demodificar o adaptar codigo ya existente.

El corazon de todo sistema embebido es su procesador, en la actualidad existen diversos fabricantesque ponen a disposicion de los desarrolladores System On Chip (SOC) que incluyen una gran variedad deperifericos que incluyen dispositivos de comunicacion (UARTs, USB, Ethernet), interface con el humano(Controladores de: LCD, tarjetas de sonido, dispositivos touch screen), almacenamiento (memorias: RAM,

5http://www.linuxdevices.com

Page 11: book

Carlos Ivan Camargo Bareno 11

SDRAM, SD, MMC). Al incluir la mayorıa de los perifericos en el mismo Chip se reduce el espacio de laplaca de circuito impreso (PCB) y se reduce la posibilidad de errores debido a interconexion y contrario alo que se podrıa esperar, el costo de este SOC es muy bajo (en comparacion con el costo de cada perifericopor separado). La figura 1.3 muestra la preferencia de los desarrolladores encuestados por linuxdevices.

Figura 1.3: Preferencia de CPU para Sistemas Embebidos 2004-2007. Fuente: linuxdevices.

Como puede verse en la Figura 1.3 existe una clara preferencia entre los procesadores x86 y losprocesadores ARM, siendo estos ultimos los mas populares en dispositivos de consumo como PDAs,Routers, telefonos celulares, consolas de juego p1.3ortatiles.

1.2. Sistemas Embebidos

Un Sistema Embebidos es un sistema de proposito especıfico en el cual, el computador es encap-sulado completamente por el dispositivo que el controla. A diferencia de los computadores de propositogeneral, un Sistema Embebido realiza tareas pre-definidas, lo cual permite su optimizacion, reduciendo eltamano y costo del producto [?]

1.2.1. Caracterısticas

Los sistemas embebidos son disenados para una aplicacion especıfica, es decir, estos sistemas realizanun grupo de funciones previamente definidasm y una vez el sistema es disenado, no se puede cambiarsu funcionalidad. Por ejemplo, el control de un asensor siempre realizara las mismas acciones durantesu vida util.

Debido a su interaccion con el entorno los ES deben cumplir esctrıctamente restricciones temporales.El termino Sistemas de Tiempo Real es utilizado para enfatizar este aspecto.

Los Sistemas Embebidos son heterogeneos, es decir, estan compuestos por componentes Hardwarey Software. Los componentes Hardware, como ASICs y Dispositivos Logicos Programables (PLD)proporcionan la velocidad de ejecucion y el cosumo de potencia necesarios en algunas aplicaciones.

Page 12: book

12 Sistemas Embebidos

Figura 1.4: Arquitectura de un Sistema Embebido

Los Sitemas Embebidos tienen grandes requerimientos en terminos de confiabilidad. Errores en apli-caciones como la aviacion y el automovilismo, pueden tener consecuencias desastrosas.

1.2.2. Arquitectura

En la Figura 1.4 se muestra la arquitectura tıpica de un Sistema Embebido. La cual integra un com-ponente hardware, implementado ya sea en un PLD (CPLD, FPGA) o en un ASIC, conocido con el nombrede perifericos y un componente software (procesador o DSP) capaz de ejecutar software, la parte del proce-sador esta dividida en la CPU (En algunos casos posee una cache) y las unidades de Memoria.

Al momento de disenar un Sistema Embebido encontramos las siguientes opciones:

Componente HW y SW Integrado en un dispositivo semiconductor (SoC): En la actualidad existenmuchas companıas que fabrican procesadores de 32 bits integrados a una gran variedad de perifericos,lo cual simplifica el diseno y reduce costos. 6. Este tipo de implementacion es muy popular en losdispositivos de consumo masivo (Reproductores de MP3, consolas de juego, etc), debido a los grandesniveles de produccion (del orden de millones de unidades) resulta mas economico contar con undispositivo que integre el mayor numero de funcionalidades, esto disminuye el costo de componentesy reduce el area de circuito impreso.

Componente SW en un SoC y componente HW en una FPGA: Cuando no existen en el mercado unSoC con la cantidad de perifericos requerida para una determinada aplicacion, o con una funcional-idad especıfica, es necesario recurrir a la utilizacion de dispositivos comerciales que implementen

6http://www.sharpsma.com, http://www.atmel.com, http://www.cirrus.com, http://www.samsung.com, http://www.freescale.com,etc

Page 13: book

Carlos Ivan Camargo Bareno 13

dicha operacion, en algunas ocaciones el periferico puede relizar funciones poco comunes y no seproporciona comercialmente, la solucion es entonces, implementar estas funcionalidades en una FP-GA; tambien se recomienda la utilizacion de FPGAs en sistemas que requieren la utilizacion de lamisma funcionalidad un gran numero de veces (Puertos seriales, Pines de Entrada/Salida). Esta de-cision esta atada al nivel de produccion, ya que al incluir una FPGA aumenta el costo global delproyecto.

Componente SW y HW en una FPGA: Esta es tal vez la opcion mas flexible, pero la de menordesempeno, ya que al utilizar los recursos logicos de la FPGA para la implementacion del procesador(softcore) la longitud de los caminos de interconexion entre los bloques logicos aumentan el retardode las senales, lo cual disminuye la maxima velocidad de funcionamiento. Los procesadores softcoremas populares en la actualidad son:

• Microblaze y Picoblaze de Xilinx7

• Leon de Gaisler Research 8

• LatticeMico32 de Lattice Semiconductors9

• OpenRisc 10

1.2.3. Metodologıa de Diseno

El proceso de diseno de un Sistema Embebido comienza con la especificacion del sistema, (verFigura 1.5), en este punto se describe la funcionalidad y se definen las restricciones fısicas, electricasy economicas. Esta especificacion debe ser muy general y no deben existir dependencias (tecnologicas,metodologicas) de ningun tipo, se suele utilizar lenguajes de alto nivel, como UML, C++. La especificacionpuede ser verificada a traves de una serie de pasos de analisis cuyo objetivo es determinar la validez de losalgorıtmos seleccionados, por ejemplo, determinar si el algoritmo siempre termina, los resultados satisfacenlas especificaciones. Desde el punto de vista de la re-utilizacion, algunas partes del funcionamiento globaldeben tomarse de una librerıa de algorıtmos existentes.

Una vez definidas las especificaciones del sistema se debe realizar un modelamiento que permitaextraer de estas la funcionalidad. El modelamiento es crucial en el diseno ya que de el depende el paso exis-toso de la especificacion a la implementacion. Es importante definir que modelo matematico debe soportarel entorno de diseno. Los modelos mas utilizados son: Maquinas de estados finitos, diagramas de flujos dedatos, Sistemad de Eventos Discretos y Redes de Petri. Cada modelo posee propiedades matematicas quepueden explotarse de forma eficiente para responder preguntas sobre la funcionalidad del sistema sin llevara cabo dispendiosas tareas de verificacion. Todo modelo obtenido debe ser verificado para comprobar quecumple con las restricciones del sistema.

Una vez se ha obtenido el modelo del sistema se procede a determinar su arquitectura, esto es, elnumero y tipo de componentes y su inter-conexion. Este paso no es mas que una exploracion del espaciode diseno en busqueda de soluciones que permitan la implementacion de una funcionalidad dada, y puederealizarse con varios criterios en mente: Costos, confiabilidad, viabilidad comercial.

Utilizando como base la arquitectura obtenida en el paso anterior las tareas del modelo del sistemasson mapeadas dentro de los componentes. Esto es, asignacion de funciones a los componentes de la arqui-tectura. Existen dos opciones a la hora de implementar las tareas o procesos:

7http://www.xilinx.com8http://www.gaisler.com/9http://www.latticesemi.com

10http://www.opencores.com

Page 14: book

14 Sistemas Embebidos

Figura 1.5: Flujo de Diseno de un Sistema Embebido [13]

Page 15: book

Carlos Ivan Camargo Bareno 15

1. Implementacion Software: La tarea se va a ejecutar en un procesador.

2. Implementacion Hardware: La tarea se va a ejecutar en un sistema digital dedicado.

Para cumplir las especificaciones del sistema algunas tareas deben ser implementadas en Hardware,esto con el fın de no ocupar al procesador en tareas cıclicas, un ejemplo tıpico de estas tareas es la gen-eracion de bases de tiempos. La decision de que tareas se implementan en SW y que tareas se implementanen HW recibe el nombre de particionamiento, esta seleccion es fuertemente dependiente de restriccioneseconomicas y temporales.

Las tareas Software deben compartir los recursos que existan en el sistema (procesador y memoria),por lo tanto se deben hacer decisiones sobre el orden de ejecucion y la prioridad de estas. Este procesorecibe el nombre de planificacion. En este punto del diseno el modelo debe incluir informacion sobre elmapeo, el particionamiento y la planificacion del sistema.

Las siguientes fases corresponden a la implementacion del modelo, para esto las tareas hardwaredeben ser llevadas al dispositivo elegido (ASIC o FPGA) y se debe obtener el ′′ejecutable′′ de las tareassoftware, este proceso recibe el nombre de sıntesis HW y SW respectivamente, ası mismo se deben sintetizarlos mecanismos de comunicacion.

El proceso de prototipado consiste en la realizacion fısica del sistema, finalmente el sistema fısicodebe someterse a pruebas para verificar que se cumplen con las especificaciones iniciales.

Como puede verse en el flujo de diseno existen realimentaciones, estas realimentaciones permitendepurar el resultado de pasos anteriores en el caso de no cumplirse con las especificaciones iniciales.

1.2.4. Herramientas Software de libre distribucion GNU toolchain

En el mercado existe una gran variedad de herramientas de desarrollo para Sistemas Embebidos, sinembargo, en este estudio nos centraremos en el uso de las herramientas de libre distribucion; esta eleccionse debe a que la mayorıa de los productos comerciales utilizan el toolchain de GNU11 internamente yproporcionan un entorno grafico para su facil manejo. Otro factor considerado a la hora de realizar nuestraeleccion es el economico, ya que la mayorıa de los productos comerciales son costosos y poseen soportelimitado. Por otro lado, el toolchain de GNU es utilizado ampliamente en el medio de los disenadores desistemas embebidos y se encuentra un gran soporte en multiples foros de discusion (ver Figura 1.6).

GNU binutils[14]

Son una coleccion de utilidades para archivos binarios y estan compuestas por:

addr2line Convierte direcciones de un programa en nombres de archivos y numeros de lınea. Dadauna direccion y un ejecutable, usa la informacion de depuracion en el ejecutabe para determinar quenombre de atchivo y numero de lpinea esta asociado con la direccion dada.

ar Esta utilidad crea, modifica y extrae desde ficheros. Un fichero es una coleccion de otros archivosen una estructura que hace posible obtener los archivos individuales miembros del archivo.

as Utilidad que compila la salida del compilador de C (GCC).

11http://www.gnu.org

Page 16: book

16 Sistemas Embebidos

Figura 1.6: Tendencia de utilizacion de herramientas de desarrollo

c++filt Este program realiza un mapeo inverso: Decodifica nombres de bajo-nivel en nombres a nivelde usuario, de tal forma que el linker pueda mantener estas funciones sobrecargadas (overloaded)“from clashing”.

gasp GNU Assembler Macro Preprocessor

ld El linker GNU combina un numero de objetos y ficheros, re-localiza sus datos y los relaciona conreferencias. Normalmente el ultimo paso en la construccion de un nuevo programa compilado es elllamado a ld.

nm Realiza un listado de sımbolos de archivos tipo objeto.

objcopy Copia los contenidos de un archivo tipo objeto a otro. objcopy utiliza la librerıa GNU BFDpara leer y escribir el archivo tipo objeto. Permite esccribibr el archivo destino en un formato diferenteal del archivo fuente.

objdump Despliega informacion sobre archivos tipo objeto.

ranlib Genera un ındice de contenidos de un fichero, y lo almacena en el.

readelf Interpreta encabezados de un archivo ELF.

size Lista el tamano de las secciones y el tamano total de un archivo tipo objeto.

strings Imprime las secuencias de caracteres imprimibles de almenos 4 caracteres de longitud.

strip Elimina todos los sımbolos de un archivo tipo objeto.

GNU Compiler Collection

El GNU Compiler Collection normalmente llamado GCC, es un grupo de compiladores de lenguajesde programacion producido por el proyecto GNU. Es el compilador standard para el software libre de lossistemas operativos basados en Unix y algunos propietarios como Mac OS de Apple. Soporta los siguienteslenguajes: ADA, C, C++, Fortran, Java, Objective-C, Objective-C++ para las arquitecturas: Alpha, ARM,Atmel AVR, Blackfin, H8/300, System/370, System/390, IA-32 (x86) and x86-64, IA-64 i.e. the ”Itanium”,

Page 17: book

Carlos Ivan Camargo Bareno 17

Motorola 68000, Motorola 88000, MIPS, PA-RISC, PDP-11, PowerPC, SuperH, SPARC, VAX, RenesasR8C/M16C/M32C, MorphoSys.

Como puede verse GCC soporta una gran cantidad de lenguajes de programacion, sin embargo, enel presente estudio solo lo utilizaremos como herramienta de compilacion para C y C++. Una caracterısticade resaltar de GCC es la gran cantidad de plataformas que soporta, esto lo hace una herramienta Universalpara el desarrollo de sistemas embebidos, el codigo escrito en una plataforma (en un lenguaje de alto nivel)puede ser implementado en otra sin mayores cambios, esto elimina la dependencia entre el codigo fuente yel HW12, lo cual no ocurre al utilizar lenguaje ensamblador.

Por otro lado, el tiempo requerido para realizar aplicaciones utilizando C o C++ disminuye, yaque no es necesario aprender las instrucciones en assembler de una plataforma determinada; ademas, ladisponibilidad de librerıas de multiples propositos reduce aun mas los tiempos de desarrollo, permitiendode esta forma tener bajos tiempos time to market y reducir de forma considerable el costo del desarrollo.

GNU Debugger

El depurador oficial de GNU (GDB), es un depurador que al igual que GCC tiene soporte paramultiples lenguajes y plataformas. GDB permite al usuario monitorear y modificar las variables internas delprograma y hacer llamado a funciones de forma independiente a la ejecucion normal del mismo. Ademas,permite establecer sesiones remotas utilizando el puerto serie o TCP/IP. Aunque GDB no posee una interfazgrafica, se han desarrollado varios front-ends como DDD o GDB/Insight.

Librerıas C

Adicionalmente es necesario contar con una librerıa que proporcione las librerıas standard de C:stdio, stdlib, math; las mas utilizadas en sistemas embebidos son:

glibc13 Es la librerıa C oficial del proyecto GNU. Uno de los inconvenientes al trabajar con estalibrerıa en sistemas embebidos es que genera ejecutables de mayor tamano que los generados a partirde otras librerıas, lo cual no la hace muy atractiva para este tipo de aplicaciones.

uClibc14 Es una librerıa disenada especialmente para sistemas embebidos, es mucho mas pequenaque glibc.

newlib15 Al igual que uClibc, esta disenada para sistemas embebidos. El tıpico “Hello, world!” ocupamenos de 30k en un entorno basado en newlib, mientras que en uno basado en glibc, puede ocupar380k [?].

diet libc16 Es una version de libc optimizada en tamano, puede ser utilizada para crear ejecutablesestaticamente enlazados para linux en plataformas alpha, arm, hppa, ia64, i386, mips, s390, sparc,sparc64, ppc y x86 64.

12Esto recibe el nombre de re-utilizacion de codigo13http://www.gnu.org/software/libc/14http://uclibc.org/15http://sources.redhat.com/newlib/16http://www.fefe.de/dietlibc/

Page 18: book

18 Sistemas Embebidos

Flujo de diseno software

En la figura 1.7 se ilustra la secuencia de pasos que se realizan desde la creacion de un archivo detexto que posee el codigo fuente de una aplicacion hasta su implementacion en la tarjeta de desarrollo.

Figura 1.7: Flujo de diseno SW utilizando la cadena de herramientas GNU

A continuacion se realiza una breve descripcion de los pasos necesarios para generar un ejecutablepara un sistema embebido:

1. Escritura del codigo fuente: Creacion del codigo fuente en cualquier editor de archivos de texto.

2. Compilacion: Utilizando el compilador gcc se compila el codigo fuente; vala la pena mencionar queen este punto el compilador solo busca en los encabezados (headers) de las librerıas la definicion deuna determinada funcion, como por ejemplo el printf en el archivo stdio.h. Como resultado de estepaso se obtiene un archivo tipo objeto.

3. Enlazado: En esta etapa se realizan dos tareas:

a) Se enlazan los archivos tipo objeto del proyecto, junto con las librerıas, si una determinada fun-cion no es edfinida por ninguna de las librerıas pasadas como parametro al linker, este gener-ara un error y no se generara el ejecutable.

b) Se define la posiciones fısicas de las secciones del ejecutable tipo ELF, esto se realiza a travesde un link de enlazado el cual define de forma explıcita su localizacion.

4. Extraccion del archivo de programacion En algunas aplicaciones es necesario extraer unicamentelas secciones que residen en los medios de almacenamiento no volatil y eliminar las demas secciones

Page 19: book

Carlos Ivan Camargo Bareno 19

del ejecutable. Esto se realiza con la herramiento objcopy, la cual, permite generar archivos en lamayorıa de los formatos soportados por los programadores de memorias y procesadores, como porejemplo S19 e Intel Hex.

5. Descarga del programa a la plataforma. Dependiendo de la plataforma existen varios metodos paradescargar el archivo de programacion a la memoria de la plataforma de desarrollo:

a) Utilizando un loader: El loader es una aplicacion que reside en un medio de almacenamientono volatil y permite la descarga de archivos utilizando el puerto serie o una interfaz de red.

b) Utilizando el puerto JTAG: El puerto JTAG (Joint Test Action Group) proporciona una interfazcapaz de controlar los registros internos del procesador, y de esta forma, acceder a las memoriasde la plataforma y ejecutar un programa residente en una determinada posicion de memoria.

6. Depuracion Una vez se descarga la aplicacion a la plataforma es necesario someterla a una seriede pruebas con el fın de probar su correcto funcionamiento. Esto se puede realizar con el depuradorGNU (GDB) y una interfaz de comunicacion que puede ser un puerto serie o un adaptador de red.

Make

Como vimoas anteriormente es necesario realizar una serie de pasos para poder descargar una apli-cacion a una plataforma embebida. Debido a que las herramientas GNU solo poseen entrada por consolade comandos, es necesario escribir una serie de comandos cada vez que se realiza un cambio en el codi-go fuente, lo cual resulta poco practico durante la etapa de desarrollo. Para realizar este proceso de formaautomatica, se creo la herramienta make, la cual recibe como entrada un archivo que normalmente recibeel nombre de Makefile o makefile. La herramienta make ejecuta los comandos necesarios para realizar lacompilacion, depuracion, o programacion, indicados en el archivo Makefile o makefile. Un ejemplo de estetipo de archivo se muestra a continuacion:

1 SHELL = / b i n / sh23 b a s e t o o l s d i r = / home / a t 9 1 / gcc−3.4.5− g l i b c −2 . 3 . 6 / arm−s o f t f l o a t −l i n u x−gnu4 b i n d i r = ${ b a s e t o o l s d i r } / b i n5 l i b d i r = ${ b a s e t o o l s d i r } / l i b / gcc / arm−s o f t f l o a t −l i n u x−gnu / 3 . 4 . 567 CC = arm−s o f t f l o a t −l i n u x−gnu−gcc8 AS = arm−s o f t f l o a t −l i n u x−gnu−as9 LD = arm−s o f t f l o a t −l i n u x−gnu−l d

10 OBJCOPY = arm−s o f t f l o a t −l i n u x−gnu−ob jcopy1112 CFLAGS =−mcpu= arm920t −I . −Wall13 LDFLAGS =−L${ l i b d i r } − l gcc1415 OBJS = \16 main . o \17 d e b u g i o . o \18 a t 9 1 r m 9 2 0 0 l o w l e v e l . o \19 p s t r i n g . o2021 ASFILES = a r m i n i t . o2223 LIBS=${ l i b d i r } /2425 a l l : h e l l o w o r l d2627 h e l l o w o r l d : ${OBJS} ${ASFILES} ${LIBS}28 ${LD} −e 0 −o h e l l o w o r l d . e l f −T l i n k e r . c f g ${ASFILES} ${OBJS} ${LDFLAGS}

Page 20: book

20 Sistemas Embebidos

29 ${OBJCOPY} −O b i n a r y h e l l o w o r l d . e l f h e l l o w o r l d . b i n3031 c l e a n :32 rm −f ∗ . o ∗ ˜ h e l l o w o r l d .∗3334 PREPROCESS . c = $ (CC) $ (CPPFLAGS) $ (TARGET ARCH) −E −Wp,−C,−dD,− dI3536 %.pp : %.c FORCE37 $ (PREPROCESS . c ) $< > $@

En las lıneas 3-5 se definen algunas variables globales que seran utilizadas a lo largo del archivo; enlas lıneas 7 - 10 se definen las herramientas de compilacion a utilizar, especıficamente los compiladores deC (CC), de assembler (AS), el linker (LD) y la utilidad objcopy. A partir de la lınea 15 se definen los objetosque forman parte del proyecto, en este caso: main.o, debug io.o, at91rm9200 lowlevel.o y p string.o; en lalınea 21 se definen los archivos en assembler que contiene el proyecto, para este caso arm init.o. Las lıneas12 y 13 definen dos variables especiales que se pasan directamente al compilador de C (CFLAGS) y alliniker (LDFLAGS)

En las lıneas 25, 27 y 31 aparecen unas etiquetas de la forma: nombre: esta es la forma de definirreglas y permiten ejecutar de forma independiente el conjunto de instrucciones asociadas a ellas, por ejem-plo, si se ejecuta el comando:make clean

make ejecutara:

rm -f *.o * hello world.*

Observemos los comandos asociados a la etiqueta hello world: En la misma lınea aparecen $OBJS$ASFILES $LIBS, estos reciben el nombre de dependencias y le indican a la herramienta make que antesde ejecutar los comandos asociados a este label, debe realizar las acciones necesarias para generar $OBJS$ASFILES $LIBS, esto es: main.o, debug io.o, at91rm9200 lowlevel.o, p string.o, arm init.o y libgcc.a.make tiene predefinidas una serie de reglas para compilar los archivos .c la regla es de la forma:

. c . o :$ (CC) $ (CFLAGS) −c $<

. c :$ (CC) $ (CFLAGS) $@. c $ (LDFLAGS) −o $@

Lo cual le indica a la herramienta make que para generar un archivo .o a partir de uno .c es necesarioejecutar $(CC) $(CFLAGS) -c $¡; de aqui la importancia de definir bien la variable de entorno CC cuandotrabajamos con compiladores cruzados17. Hasta este punto al ejecutar el comando: make hello world, makerealizarıa las siguientes operaciones:

arm−s o f t f l o a t −l i n u x−gnu−gcc −mcpu= arm920t −I . −Wall −c −o main . o main . carm−s o f t f l o a t −l i n u x−gnu−gcc −mcpu= arm920t −I . −Wall −c −o d e b u g i o . o d e b u g i o . carm−s o f t f l o a t −l i n u x−gnu−gcc −mcpu= arm920t −I . −Wall −c −o a t 9 1 r m 9 2 0 0 l o w l e v e l . o

a t 9 1 r m 9 2 0 0 l o w l e v e l . carm−s o f t f l o a t −l i n u x−gnu−gcc −mcpu= arm920t −I . −Wall −c −o p s t r i n g . o p s t r i n g . carm−s o f t f l o a t −l i n u x−gnu−as −o a r m i n i t . o a r m i n i t . s

En las lıneas 28 se realiza el proceso de enlazado; al linker se le pasan los parametros:17Un compilador cruzado genera codigo para una plataforma diferente en la que se esta ejecutando, por ejemplo, genera ejecutables

para ARM pero se ejecuta en un x86

Page 21: book

Carlos Ivan Camargo Bareno 21

-e 0: Punto de entrada , utilice 0 como sımbolo para el inicio de ejecucion.

-o hello world.elf: Nombre del archivo de salida hello world

-T linker.cfg: Utilice el archivo de enlace linker.cfg

$ASFILES $OBJS $LDFLAGS: Lista de objetos y librerıas para crear el ejecutable.

En la lınea 29 se utiliza la herramienta objcopy para generar un archivo binario (-O binary) conla informacion necesaria para cargar en una memoria no volatil. Esto se explicara con mayor detalle masadelante.

El formato ELF

El formato ELF (Executable and Linkable Format) Es un standard para objetos, librerıas y ejecuta-bles y es el formato que genera las herramientas GNU. Como puede verse en la figura 1.8 esta compuestopor varias secciones (link view) o segmentos (execution view). Si un programador esta interesado en obtenerinformacion de secciones sobre tablas de sımbolos, codigo ejecutable especıfico o informacion de enlazadodinamico debe utilizar link view. Pero si busca informacion sobre segmentos, como por ejemplo, la local-izacion de los segmentos text o data debe utilizar execution view. El encabezado describe el layout delarchivo, proporcionando informacion de la forma de acceder a las secciones [15].

Figura 1.8: Formato ELF

Las secciones pueden almacenar codigo ejecutable, datos, informacion de enlazado dinamico, datosde depuracion, tablas de sımbolos,comentarios, tablas de strings, y notas. Las secciones mas importantesson las siguientes:

.bss Datos no inicializados. (RAM)

.comment Informacion de la version.

.data y .data1 Datos inicializados. (RAM)

.debug Informacion para depuracion simbolica.

.dynamic Informacion sobre enlace dinamico

.dynstr Strings necesarios para el enlacedinamico

Page 22: book

22 Sistemas Embebidos

.dynsym Tabla de sımbolos utilizada para enlace dinamico.

.fini Codigo de terminacion de proceso.

.init Codigo de inicializacion de proceso.

.line Informacion de numero de lınea para depuracion simbolica.

.rodata y .rodta1 Datos de solo-lectura (ROM)

.shstrtab Nombres de secciones.

.symtab Tabla de sımbolos.

.text Instrucciones ejecutables (ROM)

Para aclarar un poco este concepto, escribamos una aplicacion sencilla:

# i n c l u d e <s t d i o . h>

i n t g l o b a l ;i n t g l o b a l 1 = 1 ;

i n t main ( void ){

i n t i ; / / V a r i a b l e no i n i c i a l i z a d ai n t j = 2 ; / / V a r i a b l e i n i c i a l i z a d af o r ( i =0 ; i <10; i ++){

p r i n t f ( ” P r i n t i n g %d\n ” , i ∗ j ) ; / / C a r a c t e r e s c o n s t a n t e sj = j + 1 ;g l o b a l = i ;g l o b a l 1 = i + j ;

}re turn 0 ;

}

Generemos el objeto compilandolo con el siguiente comando: arm-none-eabi-gcc -c hello.c

Examinemos que tipo de secciones tiene este ejecutable arm-none-eabi-readelf -S hello.o

S e c t i o n Headers :[ Nr ] Name Type Addr Off S i z e ES Flg Lk I n f Al[ 0 ] NULL 00000000 000000 000000 00 0 0 0[ 1 ] . t e x t PROGBITS 00000000 000034 00009 c 00 AX 0 0 4[ 2 ] . r e l . t e x t REL 00000000 000484 000020 08 9 1 4[ 3 ] . d a t a PROGBITS 00000000 0000 d0 000004 00 WA 0 0 4[ 4 ] . b s s NOBITS 00000000 0000 d4 000000 00 WA 0 0 1[ 5 ] . r o d a t a PROGBITS 00000000 0000 d4 000010 00 A 0 0 4[ 6 ] . comment PROGBITS 00000000 0000 e4 00004 d 00 0 0 1[ 7 ] .ARM. a t t r i b u t e s ARM ATTRIBUTES 00000000 000131 00002 e 00 0 0 1[ 8 ] . s h s t r t a b STRTAB 00000000 00015 f 000051 00 0 0 1[ 9 ] . symtab SYMTAB 00000000 000368 0000 f0 10 10 11 4[ 1 0 ] . s t r t a b STRTAB 00000000 000458 00002 b 00 0 0 1

Key t o F l a g s :W ( w r i t e ) , A ( a l l o c ) , X ( e x e c u t e ) , M ( merge ) , S ( s t r i n g s )I ( i n f o ) , L ( l i n k o r d e r ) , G ( group ) , x ( unknown )O ( e x t r a OS p r o c e s s i n g r e q u i r e d ) o (OS s p e c i f i c ) , p ( p r o c e s s o r s p e c i f i c )

La seccion .text, como se dijo anteriormente contiene las instrucciones ejecutables, por esta razonse marca como ejecutable “X” en la columna Flg. Es posible ver las instrucciones que se ejecutan en estaseccion:

Page 23: book

Carlos Ivan Camargo Bareno 23

arm-none-eabi-objdump -d -j .text hello.o

00000000 <main >:0 : e92d4800 stmdb sp ! , { fp , l r }4 : e28db004 add fp , sp , #4 ; 0x48 : e24dd008 sub sp , sp , #8 ; 0x8c : e3a03002 mov r3 , #2 ; 0x2

1 0 : e50b3008 s t r r3 , [ fp , #−8]1 4 : e3a03000 mov r3 , #0 ; 0x01 8 : e50b300c s t r r3 , [ fp , #−12]1 c : ea000013 b 70 <main+0x70>2 0 : e51b200c l d r r2 , [ fp , #−12]2 4 : e51b3008 l d r r3 , [ fp , #−8]2 8 : e0030392 mul r3 , r2 , r32 c : e59f005c l d r r0 , [ pc , #92] ; 90 <. t e x t +0x90>3 0 : e1a01003 mov r1 , r33 4 : e b f f f f f e b l 0 <p r i n t f >3 8 : e51b3008 l d r r3 , [ fp , #−8]3 c : e2833001 add r3 , r3 , #1 ; 0x14 0 : e50b3008 s t r r3 , [ fp , #−8]4 4 : e59f2048 l d r r2 , [ pc , #72] ; 94 <. t e x t +0x94>4 8 : e51b300c l d r r3 , [ fp , #−12]4 c : e5823000 s t r r3 , [ r2 ]5 0 : e51b200c l d r r2 , [ fp , #−12]5 4 : e51b3008 l d r r3 , [ fp , #−8]5 8 : e0822003 add r2 , r2 , r35 c : e59f3034 l d r r3 , [ pc , #52] ; 98 <. t e x t +0x98>6 0 : e5832000 s t r r2 , [ r3 ]6 4 : e51b300c l d r r3 , [ fp , #−12]6 8 : e2833001 add r3 , r3 , #1 ; 0x16 c : e50b300c s t r r3 , [ fp , #−12]7 0 : e51b300c l d r r3 , [ fp , #−12]7 4 : e3530009 cmp r3 , #9 ; 0x97 8 : d a f f f f e 8 b l e 20 <main+0x20>7 c : e3a03000 mov r3 , #0 ; 0x08 0 : e1a00003 mov r0 , r38 4 : e24bd004 sub sp , fp , #4 ; 0x48 8 : e8bd4800 ldmia sp ! , { fp , l r }8 c : e 1 2 f f f 1 e bx l r

La seccion .data mantiene las variables inicializadas, y contiene:

arm-none-eabi-objdump -d -j .data hello.o

00000000 <g l o b a l 1 >:0 : 01 00 00 00

Como vemos, la seccion .data contiene unicamente el valor de inicializacion de la variable global 1(1) y no muestra informacioon acerca de la variable j, esto se debe a que la informacion esta en el stack delproceso. Si observamos el contenido de la seccion .text observamos que esta variable es asignada en tiempode ejecucion, en la lınea 0c:

0 c : e3a03002 mov r3 , #2 ; 0x21 0 : e50b3008 s t r r3 , [ fp , #−8]

se ve la asignacion de esta variable.

La seccion .bss mantiene la informacion de las variables no incializadas: arm-none-eabi-objdump -d-j .bss hello

Page 24: book

24 Sistemas Embebidos

000145 c4 <g l o b a l >:145 c4 : 00000000

En Linux todas las variables no inicializadas, se inicializadan en cero.

La seccion .rodata mantiene los datos que no cambian durante la ejecucion del programa, es decir,de solo lectura, si examinamos esta seccion obtenemos:

hexdump -C hello.o — grep -i 000000d0 (la seccion .rodata comienza en la posicion de memoria0xd4)

000000 d0 01 00 00 00 50 72 69 6 e 74 69 6 e 67 20 25 64 0 a | . . . . P r i n t i n g %d . |000000 e0 00 00 00 00 00 47 43 43 3 a 20 28 43 6 f 64 65 53 | . . . . . GCC: ( CodeS |

Observamos que en el archivo se almacena la cadena de caracteres Printing %dn la cual no se modifica durante la ejecucion del programa.

Linker Script

Como vimos anteriormente, el linker es el encargado de agrupar todos los archivos objeto .o, y laslibrerıas necesarias para crear el ejecutable, este linker permite definir donde seran ubicados los diferentessegmentos del archivo ELF, por medio de un archivo de enlace linker script. De esta forma podemos ajustarel ejecutable a plataformas con diferentes configuraciones de memoria.Esto brinda un grado mayor deflexibilidaad de la cadena de herramientas GNU. Cuando se dispone de un sistema operativo como Linuxno es necesario definir este archivo, ya que el sistema operativo se encarga de guardar las secciones enel lugar indicado, sin embargo, es necesario tenerlo presente ya que como veremos mas adelante existeun momento en el que el sistema operativo no ha sido cargado en la plataforma y las aplicaciones que seejecuten deben proporcionar esta informacion. A continuacion se muestra un ejemplo de este archivo:

/∗ i d e n t i f y t h e E n t r y P o i n t ( v e c r e s e t i s d e f i n e d i n f i l e c r t . s ) ∗ /ENTRY( v e c r e s e t )

/∗ s p e c i f y t h e memory a r e a s ∗ /MEMORY{

f l a s h : ORIGIN = 0 , LENGTH = 256K /∗ FLASH EPROM ∗ /ram : ORIGIN = 0 x00200000 , LENGTH = 64K /∗ s t a t i c RAM area ∗ /

}

/∗ d e f i n e a g l o b a l symbol s t a c k e n d ∗ /s t a c k e n d = 0x20FFFC ;

/∗ now d e f i n e t h e o u t p u t s e c t i o n s ∗ /SECTIONS{

. = 0 ; /∗ s e t l o c a t i o n c o u n t e r t o a d d r e s s z e r o ∗ /

. t e x t : /∗ c o l l e c t a l l s e c t i o n s t h a t s h o u l d go i n t o FLASH a f t e r s t a r t u p ∗ /{∗ ( . t e x t ) /∗ a l l . t e x t s e c t i o n s ( code ) ∗ /∗ ( . r o d a t a ) /∗ a l l . r o d a t a s e c t i o n s ( c o n s t a n t s , s t r i n g s , e t c . ) ∗ /∗ ( . r o d a t a ∗ ) /∗ a l l . r o d a t a ∗ s e c t i o n s ( c o n s t a n t s , s t r i n g s , e t c . ) ∗ /∗ ( . g l u e 7 ) /∗ a l l . g l u e 7 s e c t i o n s ( no i d e a what t h e s e are ) ∗ /∗ ( . g l u e 7 t ) /∗ a l l . g l u e 7 t s e c t i o n s ( no i d e a what t h e s e are ) ∗ /

e t e x t = . ; /∗ d e f i n e a g l o b a l symbol e t e x t j u s t a f t e r t h e l a s t code b y t e ∗ /} > f l a s h /∗ p u t a l l t h e above i n t o FLASH ∗ /

. d a t a : /∗ c o l l e c t a l l i n i t i a l i z e d . da ta s e c t i o n s t h a t go i n t o RAM ∗ /

Page 25: book

Carlos Ivan Camargo Bareno 25

{d a t a = . ; /∗ c r e a t e a g l o b a l symbol marking t h e s t a r t o f t h e . da ta s e c t i o n ∗ /∗ ( . d a t a ) /∗ a l l . da ta s e c t i o n s ∗ /

e d a t a = . ; /∗ d e f i n e a g l o b a l symbol marking t h e end o f t h e . da ta s e c t i o n ∗ /} >ram AT > f l a s h /∗ p u t a l l t h e above i n t o RAM ( b u t load t h e LMA i n i t i a l i z e r copy i n t o FLASH )

∗ /

. b s s : /∗ c o l l e c t a l l u n i n i t i a l i z e d . b s s s e c t i o n s t h a t go i n t o RAM ∗ /{

b s s s t a r t = . ; /∗ d e f i n e a g l o b a l symbol marking t h e s t a r t o f t h e . b s s s e c t i o n ∗ /∗ ( . b s s ) /∗ a l l . b s s s e c t i o n s ∗ /

} >ram /∗ p u t a l l t h e above i n RAM ( i t w i l l be c l e a r e d i n t h e s t a r t u p code ∗ /. = ALIGN ( 4 ) ; /∗ advance l o c a t i o n c o u n t e r t o t h e n e x t 32− b i t boundary ∗ /b s s e n d = . ; /∗ d e f i n e a g l o b a l symbol marking t h e end o f t h e . b s s s e c t i o n ∗ /

}end = . ; /∗ d e f i n e a g l o b a l symbol marking t h e end o f a p p l i c a t i o n RAM ∗ /

En las primeras lıneas del archivo aparece la declaracion de las memorias de la plataforma, en esteejemplo tenemos una memoria RAM de 64kB que comienza en la posicion de memoria 0x00200000 yuna memoria flash de 256k que comienza en la posicion 0x0. A continuacion se definen las secciones y ellugar donde seran almacenadas; En este caso, las secciones .text (codigo ejecutable) y .rodata (datos de sololectura) se almacenan en una memoria no volatil la flash. Cuando el sistema sea energizado el procesadorejecutara el codigo almacenado en su memoria no volatil. Las secciones .data (variables inicializadas) y .bss(variables no inicializadas) se almacenaran en la memoria volatil RAM, ya que el acceso a las memorias novolatiles son mas lentas y tienen ciclos de lectura/escritura finitos.

En algunos procesadores (como el AT91RM9200) no se dispone de una memoria no volatil, por loque es necesario que la aplicacion sea cargada por completo en la RAM. Algunos desarrolladores prefierenalmacenar y ejecutar sus aplicaciones en las memorias volatiles durante la etapa de desarrollo, debido a quela programacion de las memorias no volatiles toman mucho mas tiempo. Obviamente una vez finalizada laetapa de desarrollo las aplicaciones deben ser almacenadas en memorias no volatiles.

1.2.5. Herramientas hardware

Como se menciono anteriormente existen varias alternativas al momento de implementar un SistemaEmbebido (ver Figura 1.4). En este trabajo se utiliza una arquitectura compuesta por el SoC de Atmel elAT91RM9200 y una FPGA, teniendo en cuenta que esta pataforma tiene fines academicos es muy impor-tante tener la posibilidad de crear tareas HW en un Dispositivo Logico Programable (PLD).

SoC

La Figura 1.9 muestra la arquitectura de un SoC actual, especıficamente del AT91RM920 de At-mel. En este diagrama podemos observar el nucleo central un procesador ARM920T de 180MHz y losperifericos asociados a el. En la actualidad podemos encontrar una gran variedad de SoC disenados paradiferentes aplicaciones: Multimedia, Comunicaciones, Asistentes Digitales; los perifericos incluidos en ca-da SoC buscan minimizar el numero de componentes externos, y de esta forma reducir los costos. Este SoCen particular fue uno de los primeros que diseno ATMEL y esta enfocado a tareas en las que se requiere unaconexion de red. Dentro de los perifericos encontramos:

Controlador para memorias: NAND flash, DataFlash, SDRAM, SD/MMC

Puerto USB 2.0 host.

Page 26: book

26 Sistemas Embebidos

Puerto I2C

Interfaz Ethernet 10/100.

Interfaz high speed USB 2.0

4 Puertos SPI.

2 puertos seriales (RS232).

Soporte JTAG.

Interfaz de Bus externo (EBI).

Figura 1.9: SoC AT91RM9200 fuente: Hoja de Especificaciones AT91RM9200, ATMEL

Existen una serie de perifericos que son indispensables en todo Sistema Embebido, los cuales fa-cilitan la programacion de aplicaciones y la depuracion de las mismas. A continuacion se realizara unadescripcion de los diferentes perifericos que se encuentran disponibles en este SoC, indicando los quefueron utilizados en la plataforma de desarrollo.

Page 27: book

Carlos Ivan Camargo Bareno 27

Memorias Volatiles

Como se estudio anteriormente existen secciones del ejecutable que deben ser almacenadas enmemorias volatiles o en memorias no volatiles. Debido a esto la mayorıa de los SoC incluyen periferi-cos dedicados a controlar diferentes tipos de memoria, las memorias volatiles son utilizadas como memoriade acceso aleatorio (RAM) gracias a su bajo tiempo de accesso y al ilimitado numero de ciclos de lectura/e-scritura.

El tipo de memoria mas utilizado en los sistemas embebidos actuales es la memoria SDRAM; lacual esta organizada como una matriz de celdas, con un numero de bits dedicados al direccionamiento delas filas y un numero dedicado a direccionar columnas (ver Figura 1.10).

Figura 1.10: Diagrama de Bloques de una memoria SDRAM fuente: Hoja de EspecificacionesMT48LC16M16, Micron Technology

Un ejemplo simplificado de una operacion de lectura es el siguiente: Una posicion de memoria sedetermina colocando la direccion de la fila y la de la columna en las lıneas de direccion de fila y colum-na respectivamente, un tiempo despues el dato almacenado aparecera en el bus de datos. El procesadorcoloca la direccion de la fila en el bus de direcciones y despues activa la senal RAS (Row Access Strobe).Despues de un retardo de tiempo predeterminado para permitir que el circuito de la SDRAM capture ladireccion de la fila, el procesador coloca la direccion de la columna en el bus de direcciones y activa lasenal CAS (Column Access Strobe). Una celda de memoria SDRAM esta compuesta por un transistor y uncondensador; el transistor suministra la carga y el condensador almacena el estado de cada celda, esta cargaen el condensador desaparece con el tiempo, razon por la cual es necesario recargar estos condensadoresperiodicamente, este proceso recibe el nombre de Refresco. Un ciclo de refresco es un ciclo especial en elque no se escribe ni se lee informacion, solo se recargan los condensadores para mantener la informacion.El periferico que controla la SDRAM esta encargado de garantizar los ciclos de refresco de acuerdo con losrequerimientos de la SDRAM [16]. La figura 1.11 muestra el diagrama de conexiones de una memoria de32MB utilizada en la plataforma ECBOT.

El SoC AT91RM9200 posee un periferico que es capaz de controlar la memoria SDRAM sin necesi-dad de logica adicional.

Page 28: book

28 Sistemas Embebidos

Figura 1.11: Diagrama de conexiones de la memoria SDRAM de la plataforma ECBOT

Memorias No Volatiles

La memorias no volatiles almacenan por largos perıodos de tiempo informacion necesaria para laoperacion de un Sistema Embebido, pueden ser vistos como discos duros de estado solido; existen dos tiposde memoria las memorias NOR y las NAND; las dos poseen la capacidad de ser escritas y borradas utilizan-do control de software, con lo que no es necesario utilizar programadores externos y puedens er modificadasuna vez instaladas en el circuito integrado. Una desventaja de estas memorias es que los tiempos de escrituray borrado son muy largos en comparacion con los requeridos por las memorias RAM.

Las memorias NOR poseen buses de datos y direccion, con lo que es posible acceder de forma facil acada byte almacenado en ella. Los bits datos pueden ser cambiados de 0 a 1 utilizando el control de softwareun byte a la vez, sin embargo, para cambiar un bit de 1 a 0 es necesario borrar una serie de unidades deborrado que reciben el nombre de bloques, lo que permite reducir el tiempo de borrado de la memoria.Debido a que el borrado y escritura de una memoria ROM se puede realizar utilizando el control software(ver Figura 1.12) no es necesario contar con un periferico especializado para su manejo.

Las memorias NOR son utilizadas en aplicaciones donde se necesiten altas velocidades de lectura ybaja densidad, debido a que los tiempos de escritura y lectura son muy grandes se utilizan como memoriasROM. Las memorias NAND disminuyen los tiempos de escritura y aumentan la capacidad de almace-namiento, ideales para aplicaciones donde se requiera almacenamiento de informacion. Adicionalmente lasmemorias NAND consumen menos potencia que las memorias NAND, por esta razon este tipo de memo-rias son utilizadas en casi todos los dispositivos de almacenamiento modernos como las memorias SD ylas memorias USB, los cuales integran una memoria NAND con un circuito encargado de controlarlas eimplementar el protocolo de comunicacion. A diferencia de las flash tipo NOR, los dispositivos NANDse acceden de forma serial utilizando interfaces complejas; su operacion se asemeja a un disco duro tradi-cional. Se accede a la informacion utilizando bloques (mas pequenos que los bloques NOR). Los ciclos deescritura de las flash NAND son mayores en un orden de magnitud que los de las memorias NOR.

Page 29: book

Carlos Ivan Camargo Bareno 29

Figura 1.12: Ciclos de escritura y borrado de una memoria flash NOR

Un problema al momento de trabajar con las memorias tipo NAND es que requieren el uso de unmanejo de bloques defectuosos, esto es necesario ya que las celdas de memoria pueden danarse de formaespontanea durante la operacion normal. Debido a esto se debe tener un determinado numero de bloquesque se encargen de almacenar tablas de mapeo para manejar los bloques defectuosos; o puede hacerse unchequeo en cada inicializacion del sistema de toda la RAM para actualizar esta lista de sectores defectu-osos. El algoritmo de ECC (Error-Correcting Code) debe ser capaz de corregir errores tan pequenos comoun bit de cada 2048 bits, hasta 22 bits de cada 2048. Este algorıtmo es capaz de detectar bloques defectu-osos en la fase de programacıon comparando la informacion almacenada con la que debe ser almacenada(verificacion), si encuentra un error marca el bloque como defectuoso y utiliza un bloque sin defactos paraalmacenar la informacion.

La tabla 1.1 resume las principales caracterısticas de los diferentes tipos de memoria flash.

SLC NAND MLC NAND MLC NORDensidad 512Mbits - 4GBits 1Gbits - 16GBits 16MBits - 1GBitVelocidad de Lectura 24MB/s 18.6MB/s 103MB/sVelocidad de escritura 8 MB/s 2.4MB/s 0,47MB/sTiempo de borrado 2ms 2ms 900msInterfaz Acceso Indirecto Acceso Indirecto Acceso AleatorioAplicacion Almacenamiento Almacenamiento Solo lectura

Cuadro 1.1: Cuadro de comparacion de las memorias flash NAND y NOR

El AT91RM9200 tiene un periferico que puede manejar una memoria flash NAND, sin embargo,no se utilizo en esta aplicacion. En su lugar se utilizo una memoria DataFlash de Atmel, este dispositivobasicamente es una memoria flash tipo NOR con una interfaz SPI, permite una velocidad de lectura de

Page 30: book

30 Sistemas Embebidos

hasta 66MHz utilizando solamente 4 pines para la comunicacion con el procesador. La figura 1.13 muestrael diagrama de conexiones de esta memoria.

Figura 1.13: Conexiones de la memoria DataFlash de la plataforma ECBOT

Metodos de arranque

Como es obvio todo SoC debe ser programado para que pueda ejecutar una determinada tarea; esteprograma debe estar almacenado en una memoria no volatil y debe estar en el formato requerido por elprocesador. Normalmente los SoCs proporcionan varios caminos (habilitando diferentes perifericos) parahacer esto. Un programa de inicializacion (boot program) contenido en una pequena ROM del SoC seencarga de configurar, y revisar ciertos perifericos en busqueda de un ejecutable, una vez lo encuentra, locopia a la memoria RAM interna y lo ejecuta desde allı. No sobra mencionar que este ejecutable debe estarenlazado de tal forma que todas las secciones se encuentren en el espacio de la memoria RAM interna(0x0 despues del REMAP 18). El AT91RM9200 posee una memoria interna SRAM de 16 kbytes. Despuesdel reset esta memoria esta disponible en la posicion 0x200000, despues del remap esta memoria se puedeacceder en la posicion 0x0. Algunos fabricantes, en la etapa de produccion graban en las memorias novolatiles las apliacaciones definitivas, y soldan en la placa de circuito impreso los dispoditivos programados,esto es muy conveniente cuando se trabaja con grandes cantidades ya que ahorra tiempo en el montaje delos dispositivos.

El programa de inicializacion del AT91RM9200 (se ejecuta si el pin BMS se encuentra en un valorlogico alto) busca una secuencia de 8 vectores de excepcion ARM validos en la DataFlash conectada alpuerto SPI, en una EEPROM conectada a la interfaz I2C o en una memoria de 8 bits conectada a la interfazde bus externo (EBI), estos vectores deben ser instrucciones LDR o Bbranch, menos la sexta instruccion(posicion 14 a 17) que contiene informacion sobre el tamano de la imagen (en bytes) a descargar y el tipode dispositivo DataFlash. Si la secuencia es encontrada, el codigo es almacenado en la memoria SRAMinterna y se realiza un remap (con lo que la memoria interna SRAM es accesible en la posicion 0x0 verFigura 1.14).

Si no se encuentra la secuencia de vectores ARM, se inicializa un programa que configura el puertoserial de depuracion (DBGU) y el puerto USB Device. Quedando en espera de la descarga de una aplicaciona traves del protocolo DFU (Digital Firmware Upgrade) por el puerto USB o con el protocolo XMODEMen el puerto DBGU. La figura 1.15 muestra el diagrama de flujo del programa de inicializacion del SoCAT91RM9200

El programa descargado a la memoria SRAM interna debe ser capaz de programar una memoria novolatil (La Flash DataFlash SPI para el ECBOT), debe proporcionar un canal de comunicacion que permitadescargar ejecutables mas grandes, y debe inicializar el controlador de memoria SDRAM para que almacene

18Los procesadores ARM pueden intercambiar el sitio de la memoria RAM interna y la memoria no volatil

Page 31: book

Carlos Ivan Camargo Bareno 31

Figura 1.14: Diagrama de flujo del programa de inicializacion del SoC AT91RM9200

Figura 1.15: Diagrama de flujo del programa de inicializacion del SoC AT91RM9200

temporalmente el ejecutable a grabar, esto es necesario ya que la memoria interna del AT91RM9200 soloes de 16kBytes. Mas adelante hablaremos detalladamente de la aplicacion que realiza estas funciones.

1.2.6. Interfaz JTAG

A mediados de los 1970s, la estructura de pruebas para tarjetas de circuito impreso (PCB, PrintedCircuit Boards) se basaba en el uso de la tecnica “bed-of-nails”. Este metodo hacia uso de un dispositivoque contenıa una serie de puntos de prueba, que permitıan el acceso a dispositivos en la tarjeta a traves depuntos de prueba colocados en la capa de cobre, o en otros puntos de contacto convenientes. Las pruebasse realizaban en dos fases: La prueba del circuito apagado y la prueba del circuito funcionando. Con laaparicion de los dispositivos de montaje superficial se empezo a colocar dispositivos en las dos caras dela tarjeta, debido a que las dimensiones de los dispositivos de montaje superficial son muy pequenas, sedisminuyo la distancia fısica entre las interconexiones, dificultando el proceso de pruebas.

A mediados de los 1980s un grupo de ingenieros de pruebas miembros de companıas electronicasEuropeas se reunieron para examinar el problema y buscar posibles soluciones. Este grupo se autode-

Page 32: book

32 Sistemas Embebidos

nomino JETAG (Joint European Test Action Group). El metodo de solucion propuesto por ellos estababasado en el concepto de un registro de corrimiento serial colocado alrededor de la frontera dispositivo,de aquı el nombre ?Boundary Scan?. Despues el grupo se asocio a companıas norteamericanas y la “E” de“European” desaparecio del nombre de la organizacion convirtiendose en JTAG (Join Test Action Group).

Arquitectura BOUNDARY SCAN

A cada senal de entrada o salida se le adiciona un elemento de memoria multi-proposito llamado“Boundary Scan Cell” (BSC). Las celdas conectadas a los pines de entrada reciben el nombre de “Celdasde entrada”, y las que estan conectadas a los pines de salida “Celdas de salida”. En la Figura 1.16 se muestraesta arquitectura.

Figura 1.16: Arquitectura Boundary Scan

Las BSC se configuran en un registro de corrimiento de entrada y salida paralela. Una carga paralelade los registros (captura) ocasiona que los valores de las senales aplicadas a los pines del dispositivo pasena las celdas de entrada y que opcionalmente los valores de las senales internas del dispositivo pasen a lasceldas de salida. Una descarga paralela (Actualizacion) ocasiona que los valores presentes en las celdas desalida pasen a los pines del dispositivo, y opcionalmente los valores almacenados en las celdas de entradapasen al interior del dispositivo.

Los datos pueden ser corridos a traves del registro de corrimiento, de forma serial, empezando por unpin dedicado TDI (Test Data In) y terminando en un pin de salida dedicado llamado TDO (Test Data Out).La senal de reloj se proporciona por un pin externo TCLK (Test Clock) y el modo de operacion se controlapor la senal TMS (Test Mode Select). Los elementos del Boundary Scan no afectan el funcionamiento deldispositivo. Y son independientes del nucleo logico del mismo.

Instrucciones JTAG

El Standard IEEE 1149.1 describe tres instrucciones obligatorias: Bypass, Sample/Preload, y Extest[17].

Page 33: book

Carlos Ivan Camargo Bareno 33

BYPASS Esta instruccion permite que el chip permanezca en un modo funcional, hace que el registrode Bypass se coloque entre TDI y TDO; permitiendo la transferencia serial de datos a traves delcircuito integrado desde TDI hacia TDO sin afectar la operacion. La codificacion en binario para estainstruccion debe ser con todos los bits en uno.

SAMPLE/PRELOAD Esta instruccion selecciona el registro Boundary-Scan para colocarse entrelos terminales TDI y TDO. Durante esta instruccion, el registro Boundary-Scan puede ser accesadoa traves de la operacion Data Scan, para tomar una muestra de los datos de entrada y salida del chip.Esta instruccion tambien se utiliza para precargar los datos de prueba en el registro Boundary-Scanantes de ejecutar la instruccion EXTEST. La codificacion de esta instruccion la define el fabricante.

EXTEST Esta instruccion coloca al circuito integrado en modo de test externo (pruebas de la inter-conexion) y conecta el regsitro Boundary-Scan entre TDI y TDO. Las senales que salen del circuitoson cargadas en el registro boundary-scan en el flanco de bajada de TCK en el estado Capture-DR; lassenales de entrada al dispositivo son cargadas al registro boundary-scan durante el flanco de bajadade TCK en el estado Update-DR (ver Figura 1.17) . La codificacion para esta instruccion esta definidacon todos los bits en cero.

INTEST La instruccion opcional INTEST tambien selecciona el registro boundary-scan, pero esutilizado para capturar las senales que salen del nucleo logico del dispositivo, y para aplicar valoresconnocidos a las senales de entrada del nucleo. La codificacion para esta senal es asignada por eldisenador.

Figura 1.17: Arquitectura Boundary Scan

Depuracion del core ARM [18]

Todos los nucleos ARM7 y ARM9 poseen soporte de depuracion en modo halt, lo que permitedetener por competo el nucleo. Durante este estado es posible modificar y capturar las senales del nucleo,

Page 34: book

34 Sistemas Embebidos

permitiendo cambiar y examinar el core y el estado del sistema. En este estado la fuente de reloj del core esel reloj de depuracion (DCLK) que es generado por la logica de depuracion. Los nucleos ARM7 y ARM9implementan un controlador compatible con JTAG, con dos cadena boundary-scan alrededor de las senalesdel core, una con las senales del core, para pruebas del dispositivo y la otra es un sub-set de la primeracon senales importantes para la depuracion. La Figura 1.18 muestra el orden de las senales en las cadenaspara los nucleos ARM7TDMI y ARM9TDMI. Para popositos de depuracion es suficiente la cadena 1. Estacadena puede ser utilizada en modo INTEST, permitiendo capturar las senales del core y aplicar vectores almismo, o en modo EXTEST, permitiendo la salida y entrada de informacion hacia y desde exterior del corerespectivamente.

Figura 1.18: Cadena Boundary Scan 1

Las senales D[0:31] del ARM7TDMI estan conectadas al bus de datos del nucleo y se utiliza paracapturar instrucciones o lectura/escritura de informacion; la senal BREAKPT se utiliza para indicar que lainstruccion debe ejecutarse a la velocidad del sistema, esto es, utilizando el reloj MCLK en lugar de DCLK.

Las senales ID[0:31] del ARM9TDMI estan conectadas al bus de instrucciones y se utilizan paracapturar instrucciones, las senales DD[31:0] estan conectadas al bus de dtaos bi-direccional y se utilizanpara leer o escribir informacion.

Figura 1.19: Cadena Boundary Scan 2 (Embedded ICE)

Los ARM7 y ARM9 poseen un modulo ICE (In Circuit Emulator) que reemplaza el microcontro-lador con una variacion que posee facilidades para la depuracion hardware. El emulador es conectado a uncomputador que ejecuta el software de depuracion. Esto permite realizar depuracion activa y pasiva, dandoun punto de vista no intrusivo del flujo del programa. La Figura 1.19 muestra la cadena scan ICE, que es lamisma para los nucleos ARM7 y ARM9, esta formada por 32 bits de datos, 5 bits de direcciones y un flagpara diferenciar entre lectura (nRW bajo) y escritura. Se puede acceder a las caracterısticas ICE a traves deregistros, cuya direccion es colocada en el bus de direcciones.

Page 35: book

Carlos Ivan Camargo Bareno 35

El proyecto OPENOCD (Open On-Chip Debugger 19) permite la programacion de la memoria flashinterna de algunos procesadores ARM7TDMI, y la depuracion de procesadores ARM7 y ARM9 utilizndoel modulo ICE. Este proyecto se ha convertido en el mas popular dentro del grupo de desarrolladores desistemas Embebidos. En [18] se puede encontrar el funcionamiento interno de esta herramienta.

Programacion de memorias Flash

Algunos SoC no poseen programas de inicializacion que permitan la descarga de aplicaciones yasea a las memorias externas o a la interna, una solucion podrıa ser utilizar el protocolo JTAG para cargarlas aplicaciones en la RAM interna, sin embargo, existen procesadore en los que no se conocen las es-pcificaciones del ICE y en en otros este modulo no existe. En estos casos se utiliza la interfaz JTAG enmodo EXTEST para controlar directamente las memorias conectadas a los SoCs. El proyecto UrJTAG, 20

permite la programacion de diversas memorias flash, utilizando los pines del dispositivo. UrJTAG permitela creacion de diferentes interfaces para conectarse con las memorias, estas interfaces reciben el nombre debuses y pueden ser creadas e incluidas en el codigo original de forma facil.

1.3. El sistema Operativo Linux

Hello everybody out there using minix - I’m doing a (free) operating system (just a hobby, won’t bebig and professional like gnu) for 386(486) AT clones.

Con este mail enviado al foro de discusion comp.os.minix, Linus Torvalds, un estudiante de la Uni-versidad de Helsinki en Finlandia introduce Linux el 25 de Agosto de 1991. A principios de los 90, elsistema operativo Unix (desarrollado en The Bell Labs a principios de los 60s), tenıa una solida posicion enel mercado de servidores, y estaba muy bien posicionado en las Universidades, por lo tanto, un gran numerode estudiantes trabajaban a diario con el y muchos de ellos deseaban poder utilizarlo en sus computadorespersonales, sin embargo, Unix era un producto comercial muy costoso. La figura 1.20 muestra el desarrol-lo previo a la creacion de la primera version de linux hasta el dıa de hoy. Una de las caracterısticas masimportantes de Linux es que desde su creacion, fue pensado como un sistema operativo gratuito y de libredistribucion. Esta caracterıstica ha permitido que programadores a lo largo del mundo puedan manipular elcodigo fuente para eliminar errores y para aumentar sus capacidades.

Sin embargo, el credito de las que conocemos hoy (Debian, Ubuntu, Suse, etc) no solo se debe aTorvalds, ya que linux es solo el kernel del sistema operativo. En 1983, Richard Stallman funda en proyectoGNU, el cual proporciona una parte esencial de los sistemas linux. A principios de los 90s, GNU habıaproducido una serie de herramientas como librerıas, compiladores, editores de texto, Shells, etc. Estas her-ramientas fueron utilizadas por Torvalds para escribir el elemento que le hacıa falta al proyecto GNU paracompletar su sistema operativo: el kernel.

Desde el lanzamiento de la primera version de linux, cientos, miles, cientos de miles y millones deprogramadores se han puesto en la tarea de convertir a linux en un sistema operativo robusto, amigable yactualizado; tan pronto como se desarrolla una nueva pieza de hardware existen cientos de programadorestrabajando en crear el soporte para linux.

19http://openocd.berlios.de/web/20http://urjtag.sourceforge.net/

Page 36: book

36 Sistemas Embebidos

Figura 1.20: Linux: Historia Fuente.

Porque Linux

Existen varias motivaciones para escoger Linux frente a un sistema oeprativo tradicional para sis-temas embebidos [19]:

Calidad Y confiabilidad del codigo: Aunque estas medidas son subjetivas, miden el nivel de confi-anza en el codigo, que compromete software como el kernel y las aplicacione proporcionadas por lasdistribuciones.

Disponibilidad de Codigo: Todo el codigo fuente de las aplicaciones, del sistema operativo y de lasherramientas de compilacion se encuentran disponibles sin ninguna restriccion. Existen varios tiposde licencias: la GNU General Public License (GPL). BSD (Berkeley Software Distribution), la cualpermite la distribucion de binarios sin el codigo fuente.

Soporte de Hardware: Linux soporta una gran variedad de dispositivos y plataformas, a pesar de quemuchos fabricantes no proporcionan soporte para Linux, la comunidad trabaja arduamente en incluirel nuevo hardware en las nuevas distribuciones de Linux. Linux en la actualidad se puede ejecutaren docenas de diferentes arquitecturas hardware, lo cual lo convierte en el Sistema Operativo masportable.

Protocolos de Comunicacion y estandares de Software: Linux proporciona muchos protocolos decomunicacion, lo que permite su facil integracion a marcos de trabajo ya existentes.

Disponibilidad de Herramientas: La variedad de herramientas disponibles para Linux lo hacen muyversatil. Existen grandes comunidades como SourceForge21 o Freshmeat 22 que permiten a miles dedesrroladores compartir sus trabajos y es posible que en ellas se encuentre una aplicacion que cumplacon sus necesidades.

21http://www.sourceforge.net22http://www.freshmeat.net

Page 37: book

Carlos Ivan Camargo Bareno 37

Soporte de la Comunidad: Esta es la principal fortaleza de Linux. Millones de usuarios alrededor delmundo pueden encontrar errores en alguna aplicacion y desarrolladores miembros de la cumonidad(en algunos casos los creadores de las aplicaciones) arreglaran este problema y difundiran su solucion.El mejor sitio para hacer esto son las listas de correo de soporte y desarroll.

Licencia: Al crear una aplicacion bajo alguna de las licencias usuales en Linux, no implica perder laporpiedad intelectual ni los derechos de autor la misma.

Independencia del vendedor: No existe solo un distribuidor del sistema operativo GNU-Linux, yaque las licencias de Linux garantizan igualdad a los distribuidores. Algunos vendedores poporcionanaplicaciones adicionales que no son libres y pro lo tanto no se encuentran disponibles con otrosvendedores. Esto debe tenerse en cuenta en el momento de elegir la distribucion a utilizar.

Costo: Muchas de las herramientas de deasrrollo y componentes de Linux son gratuitos, y no re-quieren el pago por ser incluidos en productos comerciales.

1.3.1. Arquitectura de Linux [1] [2]

Linux (Linus’ Minix) es un clon del sistema operativo Unix para PC con procesador Intel 386.Linux toma dos caracterısticas muy importantes de Unix: es un sistema multitarea y multiusuario, lo cualfue implementado posteriormente por los sistemas operativos Windows y MacOS. Con estas caracterısticases posible ejecutar tareas de forma independiente, y transparente para el/los usuarios.

Linux esta compuesto por cinco sub-modulos [2]: El programador (Scheduler), el manejador dememoria, el sistema de archivos virtual, la interfaz de red y la comunicacion entre procesos (IPC). Tal comose ilustra en la figura 1.21.

Figura 1.21: Estructura del kernel de linux

Como puede observarse en la figura 1.21 el kernel de linux posee sub-modulos que son indepen-dientes de la arquitectura y otros que deben ser escritos para el procesador utilizado, esto hace que Linuxsea un sistema operativo portable. En la actualidad existe una gran variedad de arquitecturas soportadas porlinux, entre las que se encuentran:

alpha arm26 frv i386 m32r m68knommu parisc ppc64 sh sparc um x86 64 arm cris h8300 ia64 m68kmips ppc s390 sh64 sparc64 v850

Las funciones de estos componentes se describen a continuacion [1]:

Page 38: book

38 Sistemas Embebidos

Programador de procesos (Scheduler)

Es el corazon del sistema operativo linux. Esta encargado de realizar las siguientes tareas:

Permitir a los procesos hacer copias de si mismos.

Determinar que procesos pueden acceder a la CPU y efectuar la transferencia entre los procesos enejecucion.

Recibir interrupciones y llevarlas al subsistema del kernel adecuado.

Enviar senales a los procesos de usuario.

Manejar el timer fısico.

Liberar los recursos de los procesos, cuando estos finalizan su ejecucion.

El programador de procesos proporciona dos interfaces: Una limitada para los procesos de usuarioy una interfaz amplia para el resto del kernel. El scheduler de Linux utiliza una interrupcion del timer quese presenta cada 10 ms, por lo tanto, el cambio de estado del programador se realiza cada 10 ms. Esto debeser tenido en cuenta a la hora de realizar procesos que manejen dispositivos hardware veloces. Un procesopuede estar en uno de los siguientes estados:

En ejecucion.

Retornando de un llamado de sistema.

Procesando una rutina de interrupcion.

Procesando un llamado del sistema.

Listo.

En espera.

Manejador de Memoria

En el momento en que se energiza la CPU, esta solo ve 1-MB de memoria fısica (Incluyendo lasROMs). El codigo de inicializacion del Sistema Operativo debe activar el modo protegido del procesador, detal forma que la memoria Extendida (incluyendo la memoria de los dispositivos) sea accesible. Finalmenteel OS habilita la memoria virtual para permitir la ilusion de un espacio de memoria de 4 GB. El manejadorde memoria proporciona los siguientes servicios (ver figuras 1.22 y 1.23):

Gran espacio de memoria. Los procesos usuario, pueden referenciar mas memoria que la existentefısicamente.

Proteccion La memoria de un proceso es privada y no puede ser leıda o modificada por otro proceso.Adicionalmente evita que los procesos sobreescriban datos de solo lectura.

Mapeo de memoria Los usuarios pueden mapear un archivo en un area de memoria virtual y accesarel archivo como una memoria.

Acceso transparente a la memoria fısica esto asegura un buen desempeno del sistema.

Page 39: book

Carlos Ivan Camargo Bareno 39

Memoria compartida

Al igual que el programador el manejador de memoria proporciona dos diferentes niveles de accesoa memoria el nivel de usuario y el de kernel.

Nivel de Usuario

• malloc() / free(). Asigna o libera memoria para que sea utilizada por un proceso.

• mmap() / munmap() / msync() /mremap() Mapea archivos en regiones de memoria virtual.

• mprotect Cambia la proteccion sobre una region de una memoria virtual.

• mlock() / mlockall() / munlock() / munlockall() Rutinas que permiten al super usuario prevenirel intercambio de memoria.

• swapon() / swapoff() Rutinas que le permiten al super-usuario agregar o eliminar archivos swapen el sistema.

Nivel de kernel

• kmalloc() / kfree() Asigna o libera memoria para que sea utilizada por estructuras de datos delkernel.

• verify area() Verifica que una region de la memoria de usuario ha sido mapeada con los per-misos necesarios.

• get free page() / free page() Asigna y libera paginas de memoria fısica.

Figura 1.22: Mapeo de memoria del Kernel.

Comunicacion Entre Procesos (IPC)

El mecanismo IPC de Linux posibilita la ejecucion concurrente de procesos, permitiendo compartirrecursos, la sincronizacion e intercambio de datos entre ellos. Linux proporciona los siguientes mecanismos:

Senales Mensajes asıncronos enviados a los procesos.

Page 40: book

40 Sistemas Embebidos

Figura 1.23: Mapeo de memoria para una aplicacion

Listas de espera Proporciona mecanismos para colocar a dormir a los procesos mientras esperan queuna operacion se complete, o un recurso se libere.

Bloqueo de archivos Permite a un proceso declarar una region de un archivo como solo lectura paralos demas procesos.

Conductos (pipe) Permite transferencias bi-direccionales entre dos procesos.

System V

• Semaforos Una implementacion del modelo clasico del semaforo.

• Lista de Mensajes Secuencia de bytes, con un tipo asociado, los mensajes son escritos a unalista de mensajes y pueden obtenerse leyendo esta lista.

• Memoria Compartida Mecanismo por medio del cual varios procesos tienen acceso a la mismaregion de memoria fısica.

Sockets del dominio Unix Mecanismo de transferencia de datos orientada a la conexion.

Interfaces de Red

Este sistema proporciona conectividad entre maquinas, y un modelo de comunicacion por sockets.Se proporcionan dos modelos de implementacion de sockets: BSD e INET. Ademas, proporciona dos pro-tocolos de transporte con diferentes modelos de comunicacion y calidad de servicio: El poco confiableprotocolo UDP (User Datagram Protocol) y el confiable TCP (Transmission Control Protocol), este ulti-mo garantiza el envıo de los datos y que los paquetes seran entregados en el mismo orden en que fueronenviados. Se proporcionan tres tipos diferentes de conexion: SLIP (Serial), PLIP (paralela) y ethernet.

Sistema de archivo virtual

El sistema de archivos de linux cumple con las siguientes tareas:

Controlar multiples dispositivos hardware

Page 41: book

Carlos Ivan Camargo Bareno 41

Manejar sistemas de archivos logicos

Soporta diferentes formatos ejecutables Por ejemplo a.out, ELF, java)

Homogeneidad Proporciona una interfaz comun a todos los dispositivos logicos o fısicos.

Desempeno

Seguridad

Confiabilidad

Drivers de Dispositivos

La capa manejador de dispositivos es responsable de presentar una interfaz comun a todos los dispos-itivos fısicos. El kernel de Linux tiene 3 tipos de controladores de dispositivo: Caracter (acceso secuencial),bloque (acceso en multiplos de tamano de bloque) y red. Ejemplos de controladores secuenciales son elmodem, el mouse; ejemplos de controladores tipo bloque son los dispositivos de almacenamiento masivocomo discos duros, memorias SD. Los manejadores de dispositivos soportan las operaciones de archivo, ypueden ser tratados como tal.

Sistema de Archivos logico

Aunque es posible acceder a dispositivos fısicos a traves de un archivo de dispositivo, es comunacceder a dispositivos tipo bloque utilizando un sistema de arcvhivos logico, el que puede ser montado enun punto del sistema de archivos virtual.

Para dar soporte al sistema de archivos virtual, Linux utiliza el concepto de inodes. Linux usa uninode para representar un archivo sobre un dispositivo tipo bloque. El inode es virtual en el sentido quecontiene operaciones que son implementadas diferentemente dependiendo de el sistema logico y del sistemafısico donde reside el archivo. La interfaz inode hace que todos los archivos se vean igual a otros subsistemasLinux. El inode se utiliza como una posicion de almacenamiento para la informacion relacionada con unarchivo abierto en el disco. El inode almacena los buffers asociados, la longitud total del archivo en bloques,y el mapeo entre el offset del archivo y los bloques del dispositivo.

Modulos

La mayor funcionalidad del sistema de archivos virtual se encuentra disponible en la forma de modu-los cargados dinamicamente. Esta cconfiguracion dinamica permite a los usuarios de Linux compilar unkernel tan pequeno como sea posible, mientras permite cargar el manejador del dispositivo y modulos delsistema de archivos si solo son necesarios durante una sesion. Esto es util en el caso de los dispositivos quese pueden conectar en caliente, como por ejemplo un scanner, si tenemos el manejador del scanner craga-do aun sin que este este conectado a nuestro equipo se esta desperdiciando la memoria asociada a dichocontrolador.

Interfaces de Red

Este sistema proporciona conectividad entre maquinas, y un modelo de comunicacion por sockets.Se proporcionan dos modelos de implementacion de sockets: BSD e INET. Ademas, proporciona dos pro-tocolos de transporte con diferentes modelos de comunicacion y calidad de servicio: El poco confiable

Page 42: book

42 Sistemas Embebidos

protocolo UDP (User Datagram Protocol) y el confiable TCP (Transmission Control Protocol), este ulti-mo garantiza el envıo de los datos y que los paquetes seran entregados en el mismo orden en que fueronenviados. Se proporcionan tres tipos diferentes de conexion: SLIP (Serial), PLIP (paralela) y ethernet.

1.4. Portando Linux a la plataforma ECBOT y ECB AT91

Como vimos anteriormente el kernel de Linux es el corazon del sistema operativo GNU/Linux y esel encargado de manejar directamente el Hardware asociado a una determinada plataforma, por lo tanto, esnecesario que este sea capaz de manejar todos los perifericos asociados a esta y proporcione caminos paracontrolarlos. En esta seccion se describira el proceso que debe realizarse para hacer que Linux se ejecutede forma correcta en una plataforma y que permita controlar sus diferentes componentes hardware (esteproceso recibe el nombre de Porting).

1.4.1. El Kernel de Linux

El codigo fuente se encuentra dividido entre el codigo especıfico a una arquitectura y el codigocomun. El codigo especıfico de cada arquitectura lo encontramos en los subdirectorios arch y include/asm-xxx, en ellos podemos encuentrar los archivos para las arquitecturas: alpha, blackfin, h8300, m68k, parisc,s390, sparc, v850, arm, cris, ia64, m68knommu, powerpc, sh, sparc64, x86, avr32, frv, m32r, mips, ppc,sh64, um, xtensa. A continuacion se listan los directorios que hacen parte sdel codigo fuente de Linux.

a r c h f s l i b n e t b l o c ku s r i n c l u d e c r y p t o i p c s c r i p t sDocumenta t ion mm s e c u r i t y d r i v e r s k e r n e lsound

Dentro de cada arquitectura soportada por Linux (arch/xxx/ ) encontramos los siguientes directorios:

kernel Codigo del nucleo del kernel.

mm Codigo para el manejo de memoria.

lib Librerıa de funciones internas, optimizadas para la arquitectura (backtrace, memcpy, funcionesI/O, bit-twiddling etc);

nwfpe Implementaciones de punto flotante.

boot Sition donde reside la imagen del kernel una vez compilado, este directorio contiene herramien-tas para generar imagenes comprimidas.

tools Contiene scripts para la autogeneracion de archivos, tambien contiene el archivo mach-typesque contiene la lista de las maquinas (plataformas) registradas.

configs Contiene el archivo de configuracion para cada plataforma.

Si deseamos dar soporte a una determinada plataforma debemos trabajar en el directorio que contienela arquitectura del procesador a utilizar, en nuestro caso trabajaremos con la arquitectura arm. En el codigofuente de Linux se encuentran muchas plataformas que utilizan las diferentes architecturas, los archivosde configuracion de estas pueden ser utilizados para crear una propia. En nuestro caso tomamos comoreferenica la plataforma Atmel AT91RM9200-EK disenada por ATMEL. Los archivos de configuracion

Page 43: book

Carlos Ivan Camargo Bareno 43

de esta plataforma se encuentra en: arch/arm/mach-at91/board-ek.c; dentro de la arquitectura arm existenvarias sub-arquitecturas que corresponden a las diferentes familias de SoC; El AT91RM9200 hace parte dela familia de SoCs AT91 de ATMEL.

Existen dos formas en las que podemos adaptar nuestra plataforma al kernel de Linux, la primera esutilizando un archivo de configuracion de una plataforma existente, y la otra es registrar la nuestra. Cadaplataforma es identificada por un machine ID, el primero paso en el proceso de port es obter un ID, lo cual sepuede hacer en lınea: http://www.arm.linux.org.uk/developer/machines/, mientras que se asigna un nuevonumero puede asignarse uno que no este utilizado en el archivo: arch/arm/tools/mach-types. La entradacorrespondiente a la familia de plataformas ECBACT91 es:

e c b a t 9 1 MACH ECBAT91 ECBAT91 1072

Con este ID (o uno temporal) se debe crear la siguiente entrada en el archivo /arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig:

c o n f i g MACH ECBAT91boo l ” emQbit ECB AT91 SBC”depends on ARCH AT91RM9200h e l p

S e l e c t t h i s i f you a r e u s i n g emQbit ’ s ECB AT91 board .<h t t p : / / w ik i . emqbi t . com / f r e e−ecb−a t91>

La que permite seleccionar nuestra plataforma desde el programa de configuracion de Linux23(VerFigura 1.24)

Figura 1.24: Herramienta de configuracion de Linux mostrando la plataforma ECB AT91

Al seleccionar nuestra plataforma el programa de configuracion creara un archivo de configuracion.config 24 localizado en la raız del codigo fuente, este archivo refleja las selecciones realizadas para config-urar la imagen del kernel; en este caso especıfico se agragara la lınea:

CONFIG MACH ECBAT91=y

Como veremos mas adelante, la aplicacion encargada de cargar la imagen del kernel de Linux lepasa a este el numero de identificacion de la plataforma, si este numero no es el mismo que el kerneltiene registrado se generara un error, para evitar esto debemos incluir las siguientes lıneas en el archivoarch/arm/boot/compressed/head-at91rm9200.S

23este programa se ejecuta con el comando: make ARCH=arm CROSS COMPILE=arm-none-eabi-24los archivos que comienzan con “.” estan ocultos

Page 44: book

44 Sistemas Embebidos

@ emQbit ECB AT91 : 1072mov r3 , # (MACH TYPE ECBAT91 & 0 x f f )o r r r3 , r3 , # (MACH TYPE ECBAT91 & 0 x f f 0 0 )cmp r7 , r3beq 99 f

El archivo /arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile contiene una relacion en-tre la plataforma seleccionada y el archivo de compilacion a utilizar, por lo que debemos incluir las sigu-ientes lıneas:

obj−$ (CONFIG MACH ECBAT91) += board−e c b a t 9 1 . o

Con esto asignamos el archivo de configuracion board-ecbat91.c a la plataforma MACH ECBAT91.

Archivo de configuracion de la plataforma ECB AT91

En esta seccion realizaremos una descripcion del archivo de configuracion de la familia de platafor-mas ECB AT91 (board-ecbat91.c) y se hara una explicacion de cada uno de los parametros de este archivo.

Como todo archivo escrito en C al comienzo se declaran los encabezados que contienen las funcionesutilizadas, en nuestro caso:

1 # i n c l u d e <l i n u x / t y p e s . h>2 # i n c l u d e <l i n u x / i n i t . h>3 # i n c l u d e <l i n u x /mm. h>4 # i n c l u d e <l i n u x / module . h>5 # i n c l u d e <l i n u x / dma−mapping . h>6 # i n c l u d e <l i n u x / p l a t f o r m d e v i c e . h>7 # i n c l u d e <l i n u x / s p i / s p i . h>8 # i n c l u d e <l i n u x / s p i / f l a s h . h>9 # i n c l u d e <l i n u x / l e d s . h>

1011 # i n c l u d e <asm / ha rdware . h>12 # i n c l u d e <asm / s e t u p . h>13 # i n c l u d e <asm / mach−t y p e s . h>14 # i n c l u d e <asm / i r q . h>1516 # i n c l u d e <asm / mach / a r c h . h>17 # i n c l u d e <asm / mach / map . h>18 # i n c l u d e <asm / mach / i r q . h>1920 # i n c l u d e <asm / a r c h / boa rd . h>21 # i n c l u d e <asm / a r c h / at91rm9200 mc . h>22 # i n c l u d e <asm / a r c h / gp io . h>23 # i n c l u d e <l i n u x / g p i o k e y s . h>24 # i n c l u d e <l i n u x / i n p u t . h>2526 # i n c l u d e ” g e n e r i c . h ”27 # i n c l u d e <asm / a r c h / a t 9 1 p i o . h>2829 # i n c l u d e <l i n u x / w1−gp io . h>

Cada arquitectura (CPU) posee un archivo donde se declaran los diferentes perifericos que puedenser utilizados: arch/arm/mach-at91/at91rm9200 devices.c en el caso del procesador AT91RM9200; En elpodemos encontrar soporte para: USB Host, USB Device, Ethernet, Compact Flash / PCMCIA, MMC /SD, NAND / SmartMedia, TWI (i2c), SPI, Timer/Counter blocks, RTC, Watchdog, SSC – Synchronous

Page 45: book

Carlos Ivan Camargo Bareno 45

Serial Controller, UART. Este archivo ademas proporciona funciones que permiten incluir y configurar losdiferentes controladores asociados al SoC, adicionalmente realiza las operaciones necesarias para poderutilizarlo, como por ejemplo, definir que el control de un determinado pin este a cargo del periferico.

El primer dispositivo declarado en el archivo de configuracion es el puerto serial (UART), este puertoes vital ya que es el unico medio de comunicacion que tenemos con nuestra plataforma.

s t a t i c s t r u c t a t 9 1 u a r t c o n f i g i n i t d a t a e c b a t 9 1 u a r t c o n f i g = {. c o n s o l e t t y = 0 , /∗ t t y S 0 ∗ /. n r t t y = 2 ,. t t y m a p = { 4 , 0 , −1, −1, −1 } /∗ t t y S 0 , . . . , t t y S 4 ∗ /

} ;

Los parametros de configuracion de la UART se declaran utilizando la estructura at91 uart configdeclarada en el archivo include/asm-arm/arch/board.h, la variable console tty define el numero del dispos-itivo tty asociado a la consola serial, ttyS0 en nuestro caso, la variable nr tty define el numero de interfacesseriales disponibles 25, ttyS0 y ttyS1 en nuestro caso; tty map realiza la correspondencia entre los disposi-tivos tty y las UART disponibles en el SoC, para este ejemplo asocia ttyS0 a la UART4 y ttyS1 a la UART0

s t a t i c vo id i n i t e c b a t 9 1 m a p i o ( void ){

/∗ I n i t i a l i z e p r o c e s s o r : 18 .432 MHz c r y s t a l ∗ /a t 9 1 r m 9 2 0 0 i n i t i a l i z e (18432000 , AT91RM9200 PQFP ) ;

/∗ S e t u p t h e LEDs ∗ /a t 9 1 i n i t l e d s ( AT91 PIN PB20 , AT91 PIN PB20 ) ;

/∗ S e t u p t h e s e r i a l p o r t s and c o n s o l e ∗ /a t 9 1 i n i t s e r i a l (& e c b a t 9 1 u a r t c o n f i g ) ;

}

La funcion at91rm9200 initialize declarada en arch/arm/mach-at91/at91rm9200.c se encarga, comosu nombre lo indica, de inicializar el procesador AT91RM9200, especıficamente se encarga de configurar, elreloj interno del procesador (con la funcion at91 clock init), registra los Osciladores configurables PCK0 aPCK3 (utilizando la funcion at91rm9200 register clocks) y finalmente habilita el soporte para los pines deentrada/salida de proposito general GPIOs (utilizando la funcion at91 gpio init). Adicionalmente informaque se esta utilizando el empaquetado TQFP208 (Este chip viene en dos versiones TQFP y BGA).

Las plataforma que carecen de un dispositivo de visualizacion como una pantalla, reflejan la ac-tividad de procesos importantes en el estado de diodos emisores de luz LEDs, Linux permite visualizar laactividad de la CPU y el estado de un timer interno (at91 init leds( cpu led, timer led)). Nuestra plataformautiliza un LED conectado al pin PB20 para estas indicaciones.

La funcion at91 init serial(&ecb at91uart config), como su nombre lo indica inicializa las inter-faces seriales utilizando como configuracion la estructura at91 init serial explicada anteriormente.

s t a t i c vo id i n i t e c b a t 9 1 i n i t i r q ( void ){

a t 9 1 r m 9 2 0 0 i n i t i n t e r r u p t s (NULL ) ;}

La funcion at91rm9200 init interrupts inicializa el Controlador de Interrupciones del AT91RM9200y permite que estas sean atendidas.

s t a t i c s t r u c t a t 9 1 u s b h d a t a i n i t d a t a e c b a t 9 1 u s b h d a t a = {

25El AT91RM9200 tiene 4 USARTS y una UART para depuracion

Page 46: book

46 Sistemas Embebidos

. p o r t s = 1 ,} ;

La estructra at91 usbh data fija el numero de puertos USB host a 1 (El encapsulado TQFP solo tieneun puerto USB host, la version BGA tiene 2).

s t a t i c s t r u c t a t91 mmc da ta i n i t d a t a ecb a t91mmc da ta = {. s l o t b = 0 ,. w i re4 = 1 ,

} ;

El SoC AT91RM9200 puede manejar dos memorias SD, la variable slot b determina cual se usa, elslot a en nuestro caso; la variable wire4 selecciona el numero de lıneas de datos entre 1 y 4 (wire4 = 1).

# i f d e f i n e d (CONFIG MTD DATAFLASH)s t a t i c s t r u c t m t d p a r t i t i o n i n i t d a t a m y f l a s h 0 p a r t i t i o n s [ ] ={{

. name = ” D a r r e l−l o a d e r ” , / 0x0

. o f f s e t = 0 ,

. s i z e = 12∗ 1056 , / / 12672 b y t e s} ,{

. name = ” uboo t ” , / / 0 x3180

. o f f s e t = MTDPART OFS NXTBLK,

. s i z e = 118 ∗ 1056 ,} ,{

. name = ” k e r n e l ” , / / 0 x21840

. o f f s e t = MTDPART OFS NXTBLK,

. s i z e = 1534 ∗ 1056 , /∗ 1619904 b y t e s ∗ /} ,{

. name = ” f i l e s y s t e m ” ,

. o f f s e t = MTDPART OFS NXTBLK,

. s i z e = MTDPART SIZ FULL ,}

} ;

s t a t i c s t r u c t f l a s h p l a t f o r m d a t a i n i t d a t a m y f l a s h 0 p l a t f o r m = {. name = ” Removable f l a s h c a r d ” ,. p a r t s = m y f l a s h 0 p a r t i t i o n s ,. n r p a r t s = ARRAY SIZE ( m y f l a s h 0 p a r t i t i o n s )

} ;# e n d i f

Muchos dispositivos flash estan divididos en secciones que reciben el nombre de particiones, sim-ilares a las particiones encontradas en un disco duro. El subsistema MTD proporciona soporte para estasparticiones Flash, si esta funcion es seleccionada con la herramienta de configuracion del kernel (CON-FIG MTD DATAFLASH = y). La familia de plataformas ECB AT91 tiene un dispositivo DataFlash serialde 16 Mbits (2Mbytes), en la que creamos 4 particiones, en las que se almacenaran el loader, el u-boot, laimagen del kernel, y el sistema de archivos (En el dispositivo flash actual no hay suficiente espacio paraeste ultimo). Cada particion se define con una estructura mtd partition formada por 3 variables: name, offset(Direccion inicial de la particion) y .size.

s t a t i c s t r u c t s p i b o a r d i n f o i n i t d a t a e c b a t 9 1 s p i d e v i c e s [ ] = {{ /∗ DataFlash c h i p ∗ /

. m o d a l i a s = ” m t d d a t a f l a s h ” ,

Page 47: book

Carlos Ivan Camargo Bareno 47

. c h i p s e l e c t = 0 ,

. max speed hz = 10 ∗ 1000 ∗ 1000 ,

. bus num = 0 ,

. p l a t f o r m d a t a = &m y f l a s h 0 p l a t f o r m ,} ,{ /∗ User a c c e s s a b l e s p i − cs1 (250KHz ) ∗ /

. m o d a l i a s = ” s p i−cs1 ” ,

. c h i p s e l e c t = 1 ,

. max speed hz = 250 ∗ 1000 ,} ,{ /∗ User a c c e s s a b l e s p i − cs2 (1MHz) ∗ /

. m o d a l i a s = ” s p i−cs2 ” ,

. c h i p s e l e c t = 2 ,

. max speed hz = 1 ∗ 1000 ∗ 1000 ,} ,{ /∗ User a c c e s s a b l e s p i − cs3 (10MHz) ∗ /

. m o d a l i a s = ” s p i−cs3 ” ,

. c h i p s e l e c t = 3 ,

. max speed hz = 10 ∗ 1000 ∗ 1000 ,} ,

} ;

La estructura spi board info define los dispositivos SPI conectados al SoC, esta formada por lavariable modalias, chip select y max speed hz. Nuestro dispositivo DataFlash se controla utilizando unpuerto SPI, por esto se define la variable platform data = &my flash0 platform

s t a t i c vo id i n i t e c b a t 9 1 b o a r d i n i t ( void ){

/∗ S e r i a l ∗ /a t 9 1 a d d d e v i c e s e r i a l ( ) ;

/∗ USB Host ∗ /a t 9 1 a d d d e v i c e u s b h (& e c b a t 9 1 u s b h d a t a ) ;

/∗ I2C ∗ /a t 9 1 a d d d e v i c e i 2 c (NULL, 0 ) ;

/∗ MMC ∗ /a t 9 1 a d d d e v i c e m m c ( 0 , &ecb a t91mmc da ta ) ;

/∗ SPI ∗ /a t 9 1 a d d d e v i c e s p i ( e c b a t 9 1 s p i d e v i c e s , ARRAY SIZE ( e c b a t 9 1 s p i d e v i c e s ) ) ;

/∗ Programmable Clock 1 ∗ /a t 9 1 s e t B p e r i p h ( AT91 PIN PA4 , 0 ) ;

}

Una vez configurados los perifericos utilizados en la plataforma debemos agregar estos dispositos,con las funciones correspondientes at91 add device (serial, usbh, i2c, mmc, spi) estas funciones hacen unllamado a la funcion platform device register la que adiciona el dispositivo a nivel de plataforma.

MACHINE START(ECBAT91 , ” emQbit ’ s ECB AT91” )/∗ M a i n t a i n e r : emQbit . com ∗ /. p h y s i o = AT91 BASE SYS ,. i o p g o f f s t = ( AT91 VA BASE SYS >> 18) & 0 x f f f c ,. b o o t p a r a m s = AT91 SDRAM BASE + 0x100 ,. t i m e r = &a t 9 1 r m 9 2 0 0 t i m e r ,. map io = e c b a t 9 1 m a p i o ,. i n i t i r q = e c b a t 9 1 i n i t i r q ,. i n i t m a c h i n e = e c b a t 9 1 b o a r d i n i t ,

MACHINE END

Page 48: book

48 Sistemas Embebidos

Archivo de Configuracion del kernel

Finalmente debemos incluir un archivo de configuracion para el kernel (arch/arm/configs/ecbat91 defconfig)el cual contiene la configuracion inicial que cnfigura de forma correcta todos los perifericos de la platafor-ma.

1.4.2. Imagen del kernel

En esta seccion se realizara una descripcion de los pasos necesarios para compilar la imagen delkernel de Linux para la familia de plataforma ECB AT91; despues, se realizara un analisis de la imagen,indicando su composicion.

Compilacion de la Imagen del kernel

En la seccion anetrior vimos como dar soporte a nuestra plataforma, en esta seccion describiremosel proceso de creacion de la imagen del kernel. El primer paso obvio es obtener la imagen del kernel, la queobtenemos del sitio oficial ftp.kernel.org

wget h t t p : / / f t p . k e r n e l . org / pub / l i n u x / k e r n e l / v2 . 6 / l i n u x − 2 . 6 . 2 4 . 4 . t a r . bz2t a r x j f l i n u x − 2 . 6 . 2 4 . 4 . t a r . bz2cd l i n u x −2 . 6 . 2 4 . 4

A continuacion descargargamos un parche que mantienen los desarrolladores de la familia de SoCsde ATMEL, este parche modifica algunos archivos de la distribucion oficial de Linux para dar sopote com-pleto y actualizado a los procesadores ATMEL.

wget h t t p : / / maxim . org . za / AT91RM9200 / 2 . 6 / 2 . 6 . 2 4 − a t91 . p a t c h . gzz c a t 2.6.24− a t 9 1 . p a t c h . gz | p a t c h −p1

Los cambios que se deben realizar en el codigo fuente, mencionados anteriormente fueron enviadosa los encargados de mantener estas actualizaciones, por lo que no es necesario modificarlos para dar soportea la familia de plataformas ECB AT91.

Finalmente debemos compilar el kernel utilizando la cadena de herramientas GNU, el resultado deeste tipo de compilaciones son ejecutables para una arquitectura ARM, este proceso recibe el nombre decompilacion cruzada, debido a que da como resultado archivos que se ejecutan en una arquitectura diferente(ARM) a la que realizo el proceso de compilacion (X86 en nuestro caso). Lo primero que debemos haceres hacer visibles los ejecutables de la cadena de herramientas, esto se hace adicionando la ruta donde seencuentran instalados a la variable de entorno PATH.

e x p o r t e x p o r t PATH=$PATH : / home / a t 9 1 / arm−2007q1 / b i n /a l i a s c rossmake = ’ make ARCH=arm CROSS COMPILE=arm−none−eab i−’

El alias crossmake hace que cada vez que se escriba esta palabra el sistema lo reemplaze por makeARCH=arm CROSS COMPILE=arm-none-eabi-, lo que ahorra tiempo al momento de pasar los parametrosa la herramienta make; estos parametros son:

1. ARCH=arm Define la arquitectura arm.

2. CROSS COMPILE=arm-none-eabi- Indica que se realizara una compilacion cruzada y que los eje-cutables de la cadena de herramientas (gcc, c++, ld, objcopy, etc) comienzan con el prefijo arm-none-eabi- (por lo que el nombre del ejecutable del compilador de c es arm-none-eabi-gcc)

Page 49: book

Carlos Ivan Camargo Bareno 49

Una vez declaradas estas variables de entorno debemos generar el archivo oculto .config 26 ejecutan-do el siguiente comando:

c rossmake e c b a t 9 1 d e f c o n f i gomake ARCH=arm CROSS COMPILE=arm−none−eab i− e c b a t 9 1 d e f c o n f i g

A continuacion se muestra una seccion de este archivo:

## A u t o m a t i c a l l y g e n e r a t e d make c o n f i g : don ’ t e d i t# Linux k e r n e l v e r s i o n : 2 . 6 . 2 4 . 4# S a t J u l 25 1 1 : 3 9 : 0 7 2009#CONFIG ARM=y. . . . .## AT91RM9200 Board Type#CONFIG MACH ECBAT91=y. . . . .

CONFIG AEABI=y. . . . .

Finalmente damos incio al proceso de compilacion:

c rossmake −j 2 ( o make ARCH=arm CROSS COMPILE=arm−none−eab i− −j 2 )

Si no ocurre ningun error, al finalizar debemos observar lo siguiente:

LD vmlinuxSYSMAP System . mapSYSMAP . tmp System . mapOBJCOPY a r c h / arm / boo t / ImageB u i l d i n g modules , s t a g e 2 .MODPOST 1 modulesK er ne l : a r c h / arm / boo t / Image i s r e a d yAS a r c h / arm / boo t / compressed / head . oCC d r i v e r s / s c s i / s c s i w a i t s c a n . mod . oGZIP a r c h / arm / boo t / compressed / p iggy . gzLD [M] d r i v e r s / s c s i / s c s i w a i t s c a n . koCC a r c h / arm / boo t / compressed / misc . oAS a r c h / arm / boo t / compressed / head−at91rm9200 . oAS a r c h / arm / boo t / compressed / p iggy . oLD a r c h / arm / boo t / compressed / vml inuxOBJCOPY a r c h / arm / boo t / zImageK er ne l : a r c h / arm / boo t / zImage i s r e a d y

y el contenido de los siguientes ditrectorios debe ser algo como:

$ l s a r c h / arm / boo t /boo tp compressed Image i n s t a l l . sh M a k e f i l e zImage

$ l s vmlinux∗vmlinux vmlinux . o

26este archivo es utilizado por las herramientas de compilacion para determinar que soporte fue incluido en el kernel

Page 50: book

50 Sistemas Embebidos

Componentes de la Imagen del kernel

Como nuestro insteres en este punto es entender la estructura de la imagen del kernel podemosindicarle a nuestra herramienta de compilacion que nos muestre mas informacion del proceso, ejecutandoel comando:

c rossmake −j 2 V=1

Al finalizar el proceso de compilacion obtenemos:

arm−none−eab i−l d −EL −p −−no−u n d e f i n e d −X −o vmlinux −T a r c h / arm / k e r n e l / vml inux . l d sa r c h / arm / k e r n e l / head . o a r c h / arm / k e r n e l / i n i t t a s k . o \i n i t / b u i l t−i n . o \−−s t a r t −group \

u s r / b u i l t−i n . o a r c h / arm / k e r n e l / b u i l t−i n . o \a r c h / arm /mm/ b u i l t−i n . o a r c h / arm / common / b u i l t−i n . o \a r c h / arm / mach−a t 9 1 / b u i l t−i n . o a r c h / arm / nwfpe / b u i l t−i n . o \k e r n e l / b u i l t−i n . o mm/ b u i l t−i n . o \f s / b u i l t−i n . o i p c / b u i l t−i n . o \s e c u r i t y / b u i l t−i n . o c r y p t o / b u i l t−i n . o \b l o c k / b u i l t−i n . o a r c h / arm / l i b / l i b . a \l i b / l i b . a a r c h / arm / l i b / b u i l t−i n . o \l i b / b u i l t−i n . o d r i v e r s / b u i l t−i n . o \sound / b u i l t−i n . o n e t / b u i l t−i n . o \−−end−group \. t m p k a l l s y m s 2 . o

En la primera lınea de el listado anterior (arm-none-eabi-ld -EL -p –no-undefined -X -o vmlinux -T arch/arm/kernel/vmlinux.lds) se realiza el proceso de enlace del archivo vmlinux, utilizando el script deenlace vmlinux.lds, incluyendo los objetos (archivos .o indicados en la lista. Notese que el primer archivoenlazado es head.o, el cual se genera a partir de arch/arm/kernel/head.S, y contiene rutinas de inicializaciondel kernel. Este proceso se explicara detalladamente mas adelante. El siguiente objeto es init task.o, el cualestablece estructuras de datos e hilos que utilizara el kernel. A continuacion se enlazan una serie de objetoscon el nombre built-in.o, la ruta del archivo indica la funcion que realiza el objeto, por ejemplo el objetoarch/arm/mm/built-in.o realiza operaciones de manejo de memoria especıficas a la arquitectura arm. Enla Figura 1.25 se muestran los componentes de la imagen vmlinux y un tamano de una compilacion enparticular que nos da una idea de la relacion de tamanos.

A continuacion se realiza la descripcion de los componentes de la imagen del kernel vmlinux[16]

1. arch/arm/kernel/head.o Codigo de inicializacion del kernel dependiente de la arquitectura.

2. init task.o Hilos y estructuras inicialies utilizadas por el kernel.

3. init/built-in.o Codigo de inicializacion del kernel.

4. usr/built-in.o Imagen interna initramfs.

5. arch/arm/kernel/built-in.o Codigo del kernel especıfico de la arquitectura.

6. arch/arm/mm/built-in.o Codigo de manejo de memoria especıfico de la arquitectura.

7. arch/arm/common/built-in.o Codigo generico especifico de la arquitectura.

8. arch/arm/mach-at91/built-in.o Codigo de inicializacion especıfico de la plataforma.

9. arch/arm/nwfpe/built-in.o Emulacion de punto flotante especıfico de la arquitectura.

Page 51: book

Carlos Ivan Camargo Bareno 51

Figura 1.25: Componentes de la Imagen del kernel de Linux vmlinux

10. kernel/built-in.o Codigo de componentes comunes del kernel.

11. mm/built-in.o Codigo de componentes comunes de manejo de memoria.

12. ipc/built-in.o Comunicacion Interproceso.

13. security/built-in.o Componentes de seguridad de Linux.

14. lib/lib.a Diferentes funciones auxiliares.

15. arch/arm/lib/lib.a Diferentes funciones auxiliares, especıfico de la aquitectura.

16. lib/built-in.o Funciones auxiliares comunes del kernel.

17. drivers/built-in.o Drivers internos o drivers no cargables.

18. sound/built-in.o Drivers de sonido.

19. net/built-in.o Red de Linux.

20. .tmp kallsyms2.o Tabla de sımbolos.

Page 52: book

52 Sistemas Embebidos

La imagen vmlinux generada tiene un tamano relativamente grande lo que la hace inconvenientepara ser almacenada en un dispositivo Flash, por esta razon se acostrumbra comprimirla. A continuaciondescribiremos el proceso que se realiza para crear una imagen compatible con u-boot, el cargador de Linuxmas utilizado para las plataformas embebidas. El primer paso para es reducir el tamano del ejecutable ELFvmlinux es eliminar la informacion de depuracion (notas y comentarios).

$ crossmake −j 3 vmlinux ( 4 . 4 MBytes )$ arm−none−eab i−ob jcopy −O b i n a r y −R . n o t e −R . comment −S vmlinux l i n u x . b i n ( 3 . 4 MBytes )$ g z i p −c −9 l i n u x . b i n > l i n u x . b i n . gz ( 1 . 6M)

A continuacion se comprime el archivo resultante utilizando la herramienta gzip, como resultadoobtenemos un archivo de 1.6M, la tercera parte del archivo original.

1.5. Inicializacion del kernel

Como se menciono anteriormente, el SoC AT91RM9200, posee un programa residente en unapequena ROM interna que revisa los controladores de memorias flash en busca de un programa valido.En la familia de plataforma ECB AT91 se utiliza la memoria DataFlash para almacenar: el bootloader,el loader de Linux (u-boot) y la imagen del kernel. La Figura 1.26 indica la secuencia de ejecucion deaplicaciones cuando se energiza nuestra plataforma.

Figura 1.26: Flujo de ejecucion en la inicializacion de plataforma ECB AT91

La primera aplicacion en ejecutarse es el loader de Darrel 27. Debido a que la RAM interna delAT91RM9200 es de tan solo 16kBytes, es necesario utilizar otra aplicacion para poder cargar el loader deLinux U-boot en la memoria SDRAM externa (con capacida de de 32Mbytes). Recordemos que incialmenteel SoC no posee ninguna aplicacion valida en la memoria DataFlash, por lo que el programa interno deinicializacion dara comienzo a una comunicacion Xmodem, para que se descargue una aplicacion a lamemoria RAM interna utilizando el puerto de depuracion serial a una velocidad de 115200 baudios.

27Originalmente creado por Darrel Harmon: http://dlharmon.com/

Page 53: book

Carlos Ivan Camargo Bareno 53

1.5.1. Darrel’s Loader

Esta aplicacion permite configurar la memoria externa SDRAM, configurar el puerto serie, imple-mentar un protocolo xmodem que permita transferir aplicaciones a la memoria SDRAM, controlar la memo-ria DataFlash y almacenar aplicaciones en ella. El loader de Darrel esta basado en u-boot, es una versionreducida de este y permite unicamente las operaciones mencioandas anteriormente, lo que resulta en unarchivo adecuado para ser almacenado en la memoria RAM interna (9.3 kBytes).

Es interesante analizar esta aplicacion, ya que esta se ejecuta sin ningun soporte de sistema operativo,lo que lo hace interesante para plataformas en las que no se puede ejecutar Linux. Su codigo fuente lopodemos descargar utilizando el siguiente comando:

$svn co h t t p : / / s vn . arhuaco . org / svn / s r c / em qb i t / ECB AT91 V2 / d a r r e l l−l o a d e r /

La estructura del codigo fuente se muestra en el siguiente listado:

|−− i n c l u d e| |−− asm| | |−− a r c h| | |−− p roc| | ‘−− proc−armv| ‘−− l i n u x| |−− b y t e o r d e r| ‘−− mtd‘−− s r c

Antes de estudiar el codigo fuente demos un vistazo al archivo Makefile para ver el proceso de com-pilacion. De ella podemos extraer las partes mas interesantes: Los objetos que hacen parte del ejecutable, elproceso de enlazado, y la creacion del archivo a descargar en la plataforma:

AOBJS = s r c / s t a r t . o / / ASSEMBLER OBJECTSCOBJS = s r c / boa rd . o s r c / s e r i a l . o s r c / xmodem . o s r c / d a t a f l a s h . o s r c / d iv0 . o s r c / i n t e r r u p t s . oLDSCRIPT := u−boo t . l d sLDFLAGS += −B s t a t i c −T $ ( LDSCRIPT ) −T t e x t $ ( TEXT BASE )OBJCFLAGS += −−gap− f i l l =0 x f fTEXT BASE = 0 x00000000

l o a d e r : $ (AOBJS) $ ( COBJS ) $ ( LDSCRIPT )$ (LD) $ (LDFLAGS) $ (AOBJS) $ ( COBJS ) \

−−s t a r t −group $ ( PLATFORM LIBS ) −−end−group \−Map l o a d e r . map −o l o a d e r

l o a d e r . b i n : l o a d e r$ (OBJCOPY) ${OBJCFLAGS} −O b i n a r y $< $@

Como podemos observar, esta aplicacion esta compuesta por el codigo en ensamblador src/start.S yel codigo en C src/board.c src/serial.c src/xmodem.c src/dataflash.c src/div0.c src/interrupts.c. Para generarel ejecutable loader (en formato ELF), encadenamos los objetos AOBJS y COBJS utilizando el script deenlazado u-boot.lds. A continuacion se muestra el comando ejecutado por las herramientas de compilacional crear el ejecutable loader

arm−e l f−l d −B s t a t i c −T u−boo t . l d s −T t e x t 0 x00000000s r c / s t a r t . o s r c / boa rd . o s r c / s e r i a l . o s r c / xmodem . o s r c / d a t a f l a s h . o s r c / d iv0 . o s r c / i n t e r r u p t s . o−−s t a r t −group−−no−warn−mismatch −L / home / a t 9 1 / g n u t o o l s / arm−e l f / b i n / . . / l i b / gcc−l i b / arm−e l f / 3 . 2 . 1 −l g c c−−end−group −Map l o a d e r . map−o l o a d e r

Page 54: book

54 Sistemas Embebidos

A continuacion se muestra el contenido del archivo u-boot.lds

OUTPUT FORMAT( ” e l f 3 2− l i t t l e a r m ” , ” e l f 3 2− l i t t l e a r m ” , ” e l f 3 2− l i t t l e a r m ” )/∗OUTPUT FORMAT(” e l f 3 2−arm ” , ” e l f 3 2−arm ” , ” e l f 3 2−arm ”) ∗ /OUTPUT ARCH( arm )ENTRY( s t a r t )SECTIONS{

. = 0 x00000000 ;

. = ALIGN ( 4 ) ;

. t e x t :{

s r c / s t a r t . o ( . t e x t )∗ ( . t e x t )

}

. = ALIGN ( 4 ) ;

. r o d a t a : { ∗ ( . r o d a t a ) }

. = ALIGN ( 4 ) ;

. d a t a : { ∗ ( . d a t a ) }

. = ALIGN ( 4 ) ;

. g o t : { ∗ ( . g o t ) }

. = ALIGN ( 4 ) ;b s s s t a r t = . ;

. b s s : { ∗ ( . b s s ) }end = . ;

}

Este archivo indica que la primera direccion del ejecutable es la 0x0 y que la primera instruccion enejecutarse (definida por ENTRY) se encuentra en el sımbolo start definida en el archivo start.S; por otrolado, este script de enlazado nos informa que las secciones .text .rodata .data .got y .bss seran incluidas enel ejecutable y se encuentran en la misma region de memoria (lo que era de esperarse ya que solo tenemosla memoria interna RAM).

crt0.S (startup.S)

Cuando se crea un ejecutable para ser utilizado en una plataforma especıfica, es necesario incluir elarchivo crt0.S (C runtime startup code). Este archivo contiene el punto de entrada start y esta encargadode las siguientes funciones:

1. Inicilizacion de las pilas (stacks).

2. Copiar el contenido de la seccion .data (datos inicializados) de la memoria no volatil.

3. Inicializar la seccion .bss

4. Hacer el llamado al punto de entrada main ( start armboot para el Darrel’s loader)

Y esta compuesto por:

1. vectors Tabla de vectores de excepciones. Deben estar colocados en la direccion 0x0000.

Page 55: book

Carlos Ivan Camargo Bareno 55

2. reset handler Esta funcion maneja el reset , y es el punto de entrada principal de un ejecutable.Realiza operaciones de inicializacion especıfica de la arquitectura.

3. undef handler Es el manejador de las instrucciones no definidas.

4. swi handler Manejador de las interrupciones software.

5. pabort handler Manejador de las excepciones prefetch abort.

6. dabort handler Manejador de las excepciones data abort.

7. irq handler Manejador de las IRQ (Interrupt Request).

8. fiq handler Manejador de las FIQ (Fast Iterrupt Request).

El archivo crt0.S es escrito en languaje ensamblador, y es fuertemente dependiente de la arquitec-tura, solo programadores expertos con un muy buen conocimiento de la arquitectura podrıan escribirlo; sinembargo, los fabricantes proporcionan ejemplos de este tipo de archivos para que pueden ser utilizados sintener que estudiar profundamente la arquitectura y el lenguaje ensamblador de la misma.

Una vez se han ejecutado las operaciones mendionadas anteriormente se hace un llamado al puntode entrada start armboot (ldr pc, start armboot)

serial.c, xmpdem.c, dataflash.c, div0.c, interrupts.c

A continuacion se realiza una descripcion de los archivos que hacen parte del loader de Darrel:

serial.c: Inicializa y configura el puerto serial de depuracion (DBGU) a uan velocidad ed 115200baudios, 8 bits de datos, paridad, par. Adicionalmente proporciona las funciones:

• putc: Transmite un caracter por la interfaz serial de depuracion.

• puts: Transmite una cadena de caracteres.

• getc: Recibe un caracter por la interfaz serial de depuracion.

xmodem.c: Implementa la recepcion serial utilizando elprotocolo xmodem.

dataflash.c: Inicializa el puerto SPI, y proporciona funciones de alto nivel para la escritura de laDataFlash.

• write dataflash(addr dest, addr src, size)

div0.c: Remplazo (dummy) del manejador division por cero de GNU/Linux.

interrupts.c: Proporciona funciones para el manejo de interrupciones e implementacion de retardos.

board.c

El archivo board.c proporciona el punto de entrada start armboot y realiza las siguientes opera-ciones:

Configuracion del Controlador de manejo de potencia (PMC).

Page 56: book

56 Sistemas Embebidos

Hace un llamado a la incializacion del puerto serie de depuracion serial init()

Configura la SDRAM externa try configure sdram

Despliega un menu de funciones.

Realiza las operaciones del menu.

Una vez se carga el archivo loader.bin, el que resulta de quitarle al archivo ELF la informacion dedepuracion y notas:

/ home / a t 9 1 / g n u t o o l s / arm−e l f / b i n / arm−e l f−ob jcopy −−gap− f i l l =0 x f f −O b i n a r y l o a d e r l o a d e r . b i n

El programa desplegara el siguiente menu:

D a r r e l l ’ s l o a d e r − Thanks t o t h e u−boo t p r o j e c tV e r s i o n 1 . 0 . B u i l d J u l 29 2007 1 2 : 0 4 : 0 4RAM: 3 2MB

1 : Upload D a r r e l l ’ s l o a d e r t o D a t a f l a s h2 : Upload u−boo t t o D a t a f l a s h3 : Upload K er ne l t o D a t a f l a s h4 : S t a r t u−boo t5 : Upload F i l e s y s t e m image6 : Memory t e s t

La opcion 1. del menu permite almacenar el archivo loader.bin en la memoria DataFlash, una vezhecho esto, el programa de inicializacion almacenado en la memoria ROM interna lo ejecutara cada vez quese reinicie la plataforma.

Las opciones 2 y 3 son similares a la 1, solo que se cargan las aplicaciones en diferentes direccionesde memoria, observemos el codigo fuente que implementa estas opciones:

e l s e i f ( key == ’ 2 ’ ){p u t s ( ” P l e a s e t r a n s f e r u−boo t . b i n v i a Xmodem\n\0 ” ) ;l e n = rxmodem ( ( char ∗ )0 x20000000 ) ;A T 9 1 F D a t a f l a s h I n i t ( ) ;d a t a f l a s h p r i n t i n f o ( ) ;i f ( w r i t e d a t a f l a s h (DATAFLASH UBOOT BASE, 0 x20000000 , l e n ) )

p u t s ( ” D a t a f l a s h w r i t e s u c c e s s f u l \n ” ) ;dispmenu = 1 ;

}

Aca vemos como si se elije la opcion 2, se despliega un mensaje indicandole al usuario que transmitael archivo u-boot.bin utilizando el protocolo xmodem, despues se ejecuta la funcion rxmodem la que recibelos datos por el serial y lo almacena en la SDRAM externa (direccion 0x20000000) y finalmente se almacenaesta informacion en la direccion DATAFLASH UBOOT BASE.

La opcion 4. del menu transfiere la ejecucion

e l s e i f ( key == ’ 4 ’ | | ( ( s c a n s > 300000) && a u t o b o o t ) ){i f ( A T 9 1 F D a t a f l a s h I n i t ( ) ) {

d a t a f l a s h p r i n t i n f o ( ) ;i f ( r e a d d a t a f l a s h (DATAFLASH UBOOT BASE, 0x1C000 , ( char ∗ )0 x20700000 ) ){

p u t s ( ” D a t a f l a s h r e a d s u c c e s s f u l : S t a r t i n g U−boo t\n ” ) ;asm ( ” l d r pc , =0 x20700000 ” ) ;

}}

}

Page 57: book

Carlos Ivan Camargo Bareno 57

En esta opcion se copian 0x1C000 bytes del contenido de la memoria DataFlash comenzando en la posicionDATAFLASH UBOOT BASE a la direccion de memoria 0x20700000 (SDRAM externa) y luego se cargael contador de programa con la direccion 0x20700000, con lo que se inicia la ejecucion del programaalmacenado en la DataFlash, es importante hacer notar que el programa debe ser enlazado para que lassecciones esten en la posicion de memoria donde seran ejecutadas (0x20700000), no en la direccion dondeson almacenadas.

1.5.2. U-boot

La opcion numero 4 del menu copia el programa u-boot almacenado en la DataFlash a la memoriaSDRAM y comienza su ejecucion, en esta seccion se realizara una descricion del loader u-boot.

U-boot es un bootloader que permite cargar archivos utilizando una gran variedad de perifericoscomo: Puerto serie, Memoria SD, Memorias Flash Paraleas, seriales, NAND. NOR, Ethernet. Es capazde iniciar una variedad de tipos de archivos, ademas de un formato especial propio; este ultimo almacenainformacion sobre el tipo de sistema operativo, la direccion de carga, el punto de entrada, verificacion deintegridad via CRC, tipos de compresion, y textos descriptivos. La siguiente informacion es desplegadacuando u-boot se inicializa una imagen del kernel de linux.

## Boo t ing image a t c0021840 . . .Image Name : Linux K er n e l ImageImage Type : ARM Linux K er n e l Image ( g z i p compressed )Data S i z e : 1550369 Bytes = 1 . 5 MBLoad Address : 20008000E n t r y P o i n t : 20008000V e r i f y i n g Checksum . . . OKUncompress ing Ke r ne l Image . . . OK

Para crear una imagen con el formato U-boot basta con ejecutar el siguiente comando:

$ mkimage −A arm −O l i n u x −T k e r n e l −C g z i p −a 0 x20008000 −e 0 x20008000 −n ” Linux Ke rn e l Image ” \−d l i n u x . b i n . gz e c b a t 9 1 . img

Aca definimos ARM como arquitectura, linux como sistema operativo, Kernel como el tipo deimagen, gzip el metodo de compresion, 0x20008000 la direccion de carga y punto de entrada (son igualespara kernels superiores al 2.3.X) Linux Kernel Image el nombre de la imagen linux.bin.gz el archivo deentrada y ecb at91.img el archivo de salida. Esta informacion es almacenada en el encabezado de la imageny puede ser leido utilizando el comando:

$mkimage − l / home / a t 9 1 / b i n a r i e s / e c b a t 9 1 . img

Image Name : Linux K er n e l ImageC r e a t e d : F r i Jun 26 0 9 : 2 6 : 0 3 2009Image Type : ARM Linux K er n e l Image ( g z i p compressed )Data S i z e : 1550369 Bytes = 1514 .03 kB = 1 . 4 8 MBLoad Address : 0 x20008000E n t r y P o i n t : 0 x20008000

El siguiente listado muestra la estructura del envabezado definida por u-boot, en ella podemos ober-var sus componentes y el tamano de cada uno de ellos.

t y p e d e f s t r u c t i m a g e h e a d e r {u i n t 3 2 t i h m a g i c ; /∗ Image Header Magic Number ∗ /u i n t 3 2 t i h h c r c ; /∗ Image Header CRC Checksum ∗ /u i n t 3 2 t i h t i m e ; /∗ Image C r e a t i o n Timestamp ∗ /

Page 58: book

58 Sistemas Embebidos

u i n t 3 2 t i h s i z e ; /∗ Image Data S i z e ∗ /u i n t 3 2 t i h l o a d ; /∗ Data Load Addres s ∗ /u i n t 3 2 t i h e p ; /∗ E n t r y P o i n t Addres s ∗ /u i n t 3 2 t i h d c r c ; /∗ Image Data CRC Checksum ∗ /u i n t 8 t i h o s ; /∗ O p e r a t i n g Sys tem ∗ /u i n t 8 t i h a r c h ; /∗ CPU a r c h i t e c t u r e ∗ /u i n t 8 t i h t y p e ; /∗ Image Type ∗ /u i n t 8 t ih comp ; /∗ Compress ion Type ∗ /u i n t 8 t ih name [IH NMLEN ] ; /∗ Image Name ∗ /

} i m a g e h e a d e r t ;

1.5.3. Portando U-boot a la familia de plataformas ECB AT91

Es necesario modificar varios archivos para que u-boot soporte la familia de plataformas ECB AT91:

Makefile

Se le debe indicar a las herramientas de compilacion la nueva plataforma, adicionando las siguienteslıneas.

e c b a t 9 1 c o n f i g : u n c o n f i g@$(MKCONFIG) $ (@: c o n f i g =) arm arm920t e c b a t 9 1 NULL at91rm9200

MAKEALL

Se debe agregar la siguiente entrada en el archivo MAKEALL:

LIST ARM9=” \−−−−−

at91rm9200dk cmc pu2 e c b a t 9 1

board/ecb at91/Makefile

En el directorio board/ecb at91 se alojan los archivos que dan soporte a la nueva arquitectura, elarchivo de reglas de Configuracion se muestra a continuacion:

i n c l u d e $ ( TOPDIR ) / c o n f i g . mk

LIB = $ ( o b j ) l i b $ (BOARD) . a

COBJS := $ (BOARD) . o a t 4 5 . o f l a s h . o

SRCS := $ ( SOBJS : . o = . S ) $ ( COBJS : . o = . c )OBJS := $ ( a d d p r e f i x $ ( o b j ) , $ ( COBJS ) )SOBJS := $ ( a d d p r e f i x $ ( o b j ) , $ ( SOBJS ) )

$ ( LIB ) : $ ( o b j ) . depend $ ( OBJS ) $ ( SOBJS )$ (AR) $ (ARFLAGS) $@ $ ( OBJS ) $ ( SOBJS )

c l e a n :rm −f $ ( SOBJS ) $ ( OBJS )

Page 59: book

Carlos Ivan Camargo Bareno 59

d i s t c l e a n : c l e a nrm −f $ ( LIB ) c o r e ∗ . bak . depend

# d e f i n e s $ ( o b j ) . depend t a r g e ti n c l u d e $ (SRCTREE ) / r u l e s . mks i n c l u d e $ ( o b j ) . depend

Este es el formato utilizado para todas las plataformas, la parte importante se encuentra en la defini-cion de la variable COBJS; en la que se incluyen los archivos ecb at91.o: archivo de la plataforma at45.0:soporte a las memorias DataFlash AT45 y flash.o: soporte generico para dispositivos flash28.

board/ecb at91/board.c

Este archivo contiene toda la configuracion especıfica de la plataforma, y como se puede ver en elsiguiente listado, fija el numero de la plataforma a: MACH TYPE ECBAT91 (1072 definida en include/asm-arm/mach-types.h) y los parametros del boot en: PHYS SDRAM + 0x100; (PHYS SDRAM = 0x20000000esta definido en include/configs/ecb at91.h). Adicionalmente, inicializa la SDRAM, la interfaz de red y lamemoria DataFlash.

# i n c l u d e <common . h># i n c l u d e <asm / a r c h / AT91RM9200 . h># i n c l u d e <a t 9 1 r m 9 2 0 0 n e t . h># i n c l u d e <l x t 9 7 2 . h>

DECLARE GLOBAL DATA PTR ;

/∗∗ M i s c e l a n e o u s p l a t f o r m dependan t i n i t i a l i s a t i o n s∗ /

void l o w l e v e l i n i t ( void ){

/∗ R e q u i r e d by a s s e m b l y f u n c t i o n s − do n o t h i n g ∗ /}

i n t b o a r d i n i t ( void ){

/∗ Enable C t r l c ∗ /c o n s o l e i n i t f ( ) ;

/∗ arch number o f ECB AT91 board ∗ /gd−>bd−>b i a r c h n u m b e r = MACH TYPE ECBAT91 ;

/∗ a d r e s s o f boo t p a r a m e t e r s ∗ /gd−>bd−>b i b o o t p a r a m s = PHYS SDRAM + 0 x100 ;

re turn 0 ;}

i n t d r a m i n i t ( void ){

gd−>bd−>b i d r a m [ 0 ] . s t a r t = PHYS SDRAM;gd−>bd−>b i d r a m [ 0 ] . s i z e = PHYS SDRAM SIZE ;re turn 0 ;

}

28Estos archivos pueden ser descargados de: http://svn.arhuaco.org/svn/src/emqbit/ECB AT91 V2/u-boot/u-boot-1.1.6-ecbat91.patch

Page 60: book

60 Sistemas Embebidos

# i f d e f CONFIG DRIVER ETHER# i f (CONFIG COMMANDS & CFG CMD NET)

/∗∗ Name :∗ a t 9 1 r m 9 2 0 0 G e t P h y I n t e r f a c e∗ D e s c r i p t i o n :∗ I n i t i a l i s e t h e i n t e r f a c e f u n c t i o n s t o t h e PHY∗ Arguments :∗ None∗ Re tu rn v a l u e :∗ None∗ /

void a t 9 1 r m 9 2 0 0 G e t P h y I n t e r f a c e ( AT91PS PhyOps p phyops ){

p phyops−>I n i t = l x t 9 7 2 I n i t P h y ;p phyops−>I sPhyConnec t ed = l x t 9 7 2 I s P h y C o n n e c t e d ;p phyops−>GetLinkSpeed = l x t 9 7 2 G e t L i n k S p e e d ;p phyops−>A u t o N e g o t i a t e = l x t 9 7 2 A u t o N e g o t i a t e ;

}

# e n d i f /∗ CONFIG COMMANDS & CFG CMD NET ∗ /# e n d i f /∗ CONFIG DRIVER ETHER ∗ /

# i f d e f CONFIG HAS DATAFLASH# i n c l u d e <d a t a f l a s h . h>

void A T 9 1 F D a t a f l a s h M a p I n i t ( void ){

s t a t i c i n t cs [ ] [ CFG MAX DATAFLASH BANKS] = {/∗ L o g i c a l adres s , CS ∗ /{CFG DATAFLASH LOGIC ADDR CS0 , 0} ,} ;

s t a t i c d a t a f l a s h p r o t e c t t a r e a l i s t [NB DATAFLASH AREA] = {/∗ d e f i n e t h e d a t a f l a s h o f f s e t s ∗ /{DATAFLASH LOADER BASE /∗ 0 ∗ / , DATAFLASH UBOOT BASE − 1 ,

FLAG PROTECT SET , ” D a r r e l l l o a d e r ” } ,{DATAFLASH UBOOT BASE, DATAFLASH ENV UBOOT BASE − 1 ,

FLAG PROTECT SET , ”U−boo t ” } ,{DATAFLASH ENV UBOOT BASE, DATAFLASH KERNEL BASE − 1 ,

FLAG PROTECT CLEAR , ” Envi ronment ” } ,{DATAFLASH KERNEL BASE , DATAFLASH FILESYSTEM BASE − 1 ,

FLAG PROTECT CLEAR , ” K e rn e l ” } ,{DATAFLASH FILESYSTEM BASE , 0 x 1 f f f f f , FLAG PROTECT SET , ” F i l e s y s t e m ” } ,} ;

AT91F MapInit ( cs , a r e a l i s t ) ;}

# e n d i f

include/configs/ecb at91.h

Este archivo contiene variables que son utilizadas para la inicializacion de la plataforma, algunas deestas ellas definen el valor de registros de configuracion de perifericos como: El controlador del reloj delsistema, controlador de memorias SDRAM y memorias Flash.

Page 61: book

Carlos Ivan Camargo Bareno 61

A continuacion se muestra un segmento de este archivo, en el que se define la arquitectura:

/∗ ARM a s y n c h r o n o u s c l o c k ∗ /# d e f i n e AT91C MAIN CLOCK 180000000# d e f i n e AT91C MASTER CLOCK 60000000

# d e f i n e AT91 SLOW CLOCK 32768 /∗ s low c l o c k ∗ /

# d e f i n e CONFIG ARM920T 1 /∗ T h i s i s an ARM920T Core ∗ /# d e f i n e CONFIG AT91RM9200 1 /∗ I t ’ s an Atmel AT91RM9200 SoC ∗ /# d e f i n e CONFIG ECB AT91 1 /∗ on an AT91RM9200DK Board ∗ /# undef CONFIG USE IRQ /∗ we don ’ t need IRQ / FIQ s t u f f ∗ /# d e f i n e USE 920T MMU 1

# d e f i n e CONFIG CMDLINE TAG 1 /∗ e n a b l e p a s s i n g o f ATAGs ∗ /# d e f i n e CONFIG SETUP MEMORY TAGS 1# d e f i n e CONFIG INITRD TAG 1

# i f n d e f CONFIG SKIP LOWLEVEL INIT# d e f i n e CFG LONGHELP

Este archivo tambien incluye el valor predeterminado de las variables de entorno utilizadas por u-boot:

# d e f i n e CONFIG BOOTARGS ”mem=32M r o o t = / dev / mmcblk0p1 r o o t f s t y p e = e x t 3 c o n s o l e = t t y S 0 ,115200 n8 r o o t d e l a y =1”# d e f i n e CONFIG ETHADDR 0 0 : 0 0 : 0 0 : 0 0 : 0 0 : 5 b# d e f i n e CONFIG NETMASK 2 5 5 . 2 5 5 . 2 5 5 . 0# d e f i n e CONFIG IPADDR 1 9 2 . 1 6 8 . 0 . 1 3 5# d e f i n e CONFIG SERVERIP 1 9 2 . 1 6 8 . 0 . 1 2 8# d e f i n e CONFIG BOOTDELAY 2# d e f i n e CONFIG BOOTCOMMAND ” bootm C0021840 ”# d e f i n e CONFIG BOOTFILE ” e c b a t 9 1 . img ”# d e f i n e CONFIG ROOTPATH ” / home / a t 9 1 / r o o t f s ”# d e f i n e CONFIG LOADADDR 0 x20200000

La variable bootargs son parametros pasados al kernel en su inicializacion, y en este ejemplo fijala memoria RAM en 32 Mbytes, indica que el sistema de archivos se encuentra en el dispositivo /dev/mm-cblk0p1 y utiliza el sistema de archivos ext3, la consola es el dispositivo serial /dev/ttyS0 configurado a unavelocidad de 115200 baudios, bit de paridad y 8 bits de datos y que debe esperar 1 segundo para montar elsistema de archivos.

Las variables ethaddr, netmask, ipaddr, serverip configuran la interfaz de red y las direcciones IPde la plataforma y de un servidor de donde puede descargarse la imagen del kernel. La variable bootdelayfija el numero de segundos que esperara u-boot para ejecutar el comando almacenado en bootcmd, esteconteo puede detenerse para interactuar con u-boot. El comando bootm C0021840 (bootcmd) es utilizadopara iniciar la imagen almacenada en la direccion de memoria 0xC0021840 (direccion donde almacena elloader de Darrel la imagen del kernel), bootm utiliza la informacion almacenada en el encabezado de laimagen para utilizar el metodo de descompresion adecuado, almacenarlo en la direccion requerida y pasarlelos parametros almacenados en bootcmd.

# d e f i n e CONFIG COMMANDS \( ( CONFIG CMD DFL | CFG CMD NET | CFG CMD PING | CFG CMD DHCP ) & \˜ ( CFG CMD BDI | CFG CMD FPGA | CFG CMD MISC ) )

/∗ Remember t h a t you must have t h e same mapping i n t h e D a r r e l l l o a d e r ∗ /# d e f i n e NB DATAFLASH AREA 5 /∗ p r o t e c t e d a r e a s (4 + u−boo t env ) ∗ /# d e f i n e DATAFLASH MAX PAGESIZE 1056# d e f i n e DATAFLASH LOADER BASE (0∗DATAFLASH MAX PAGESIZE)

Page 62: book

62 Sistemas Embebidos

# d e f i n e DATAFLASH UBOOT BASE (12∗DATAFLASH MAX PAGESIZE)# d e f i n e DATAFLASH ENV UBOOT BASE (122∗DATAFLASH MAX PAGESIZE)# d e f i n e DATAFLASH KERNEL BASE (130∗DATAFLASH MAX PAGESIZE)# d e f i n e DATAFLASH FILESYSTEM BASE (1664∗DATAFLASH MAX PAGESIZE)

Compilacion de U-boot en la familia de plataformas ECB AT91

A continuacion se indican los pasos necesarios para generar el archivo u-boot.bin que sera almace-nado en la memoria DataFlash por el loader de Darrel.

El primer paso es obviamente descargar el codigo fuente de la version 1.1.6 de http://sourceforge.net/projects/u-boot/, despues debemos descargar el patch que da soporte a la familia de plataformas ECB AT91:

$ wget h t t p : / / s vn . arhuaco . org / svn / s r c / em qb i t / ECB AT91 V2 / u−boo t / u−boot −1.1.6− e c b a t 9 1 . p a t c h$ t a r x j f u−boot −1 . 1 . 6 . t a r . bz2$ cd u−boot −1.1 .6

Aplicamos el patch

$ c a t . . / u−boot −1.1.6− e c b a t 9 1 . p a t c h | p a t c h −p1

Configuramos y generamos las herramientas utilizadas por u-boot (entre ellas mkimage).

$ make e c b a t 9 1 c o n f i gC o n f i g u r i n g f o r e c b a t 9 1 board . . . ( E s t e e s un c o m e n t a r i o )

$ make t o o l s

Por ultimo compilamos u-boot:

$ make ARCH=arm CROSS COMPILE=arm−none−eab i−ocrossmake ( s i e l a l i a s c rossmake e s t a d e f i n i d o )

Si el proceso se siguio correctamente y no se presentan errores al final del proceso obtenemos elmensaje:

arm−none−eab i−ob jcopy −−gap− f i l l =0 x f f −O s r e c u−boo t u−boo t . s r e carm−none−eab i−ob jcopy −−gap− f i l l =0 x f f −O b i n a r y u−boo t u−boo t . b i n

Lo que nos indica que se genero exitosamente el archivo u-boot.bin, que puede ser descargado utilizando laopcion 2 del menu del loader de Darrel (Upload u-boot to Dataflash) y el protocolo xmodem.

Podemos verificar que el archivo fue generado y almacenado en la Dataflash podemos ejecutar laopcion numero 4 del menu del loader de Darrel (Start u-boot), como se menciono anteriormente esta opcioncopia el archivo u-boot desde la DataFlash a la memoria SDRAM y es ejecutado desde alli, con lo que sedesplegara el siguiente mensaje:

D a t a f l a s h r e a d s u c c e s s f u l : S t a r t i n g U−boo tU−Boot 1 . 1 . 6 ( J u l 29 2007 − 1 2 : 1 2 : 3 8 )

DRAM: 32 MBAtmel : F l a s h : 0 kBD a t a F l a s h : AT45DB161Nb pages : 4096Page S i z e : 528S i z e = 2162688 b y t e s

Page 63: book

Carlos Ivan Camargo Bareno 63

L o g i c a l a d d r e s s : 0xC0000000Area 0 : C0000000 t o C000317F (RO) D a r r e l l l o a d e rArea 1 : C0003180 t o C001F73F (RO) U−boo tArea 2 : C001F740 t o C002183F Envi ronmentArea 3 : C0021840 t o C01ACFFF K e rn e lArea 4 : C01AD000 t o C020FFFF (RO) F i l e s y s t e mIn : s e r i a lOut : s e r i a lE r r : s e r i a lPHY n o t c o n n e c t e d ! !H i t any key t o s t o p a u t o b o o t : 2

Si se presiona cualquier tecla antes de que el contador llegue a 0, podemos interactuar con u-boot, siejecutamos el comando print (Despliega en pantalla las variables de entorno definidas):

bootcmd=bootm C0021840b o o t d e l a y =2b a u d r a t e =115200e t h a d d r = 0 0 : 0 0 : 0 0 : 0 0 : 0 0 : 5 bi p a d d r = 1 9 2 . 1 6 8 . 0 . 1 3 5s e r v e r i p = 1 9 2 . 1 6 8 . 0 . 1 2 8r o o t p a t h =” / home / a t 9 1 / r o o t f s ”netmask = 2 5 5 . 2 5 5 . 2 5 5 . 0b o o t f i l e =” e c b a t 9 1 . img ”l o a d a d d r =0 x20200000b o o t a r g s =mem=32M r o o t = / dev / mmcblk0p2 r o o t f s t y p e = e x t 3 c o n s o l e = t t y S 0 ,115200 n8 r o o t d e l a y =1s t d i n = s e r i a ls t d o u t = s e r i a ls t d e r r = s e r i a lEnvi ronment s i z e : 345/8188

Podemos cambiar el valor predeterminado de la variable bootdelay a 1:

e c b a t 9 1 > s e t e n v b o o t d e l a y 1

Y almacenamos los cambios realizados en una seccion de la flash reservada para este fin con elcomando:

e c b a t 9 1 > s aveSav ing Envi ronment t o d a t a f l a s h . . .

s

Podemos generar una nueva variable de entorno, almacenarla en la DataFlash

e c b a t 9 1 > s e t e n v n f s a r g s =mem=32M c o n s o l e = t t y S 0 ,115200 n8 r o o t = / dev / n f s n f s r o o t = 1 9 2 . 1 6 8 . 0 . 1 2 8 : / home/ a t 9 1 / r o o t f s , t imeo =200 , r e t r a n s =500 i p = : : : : : e t h 0 : on

e c b a t 9 1 > s ave

1.5.4. Almacenamiento de la imagen del kernel

Una vez creada la imagen del kernel (ecb at91.img) con el formato de U-boot debemos probarsu correcto funcionamiento; esto lo podemos hacer de dos formas: Almacenandola directamente en unamemoria no volatil o cargandola en la memoria RAM y ejecutandola desde allı.

Page 64: book

64 Sistemas Embebidos

Almacenamiento en la memoria DataFlash

Cuando almacenamos la imagen del kernel de Linux a un medio de almacenamiento no volatil,debemos tener presente que los ciclos de borrado y escritura de este toman un tiempo mucho mayor queen el caso de las memorias no volatiles, por esto, se recomienda esta opcion cuando ya se cuente con unaimagen estable o cuando no existan otros medios (como en el caso de la plataforma ECBOT).

Inicialmente debemos ejecutar el loader de Darrel, esto se hace presionando el pulsador de Re-set disponible en todas las plataformas de la familia ECB AT91. Inmediatamente despues de observar elmenu del loader debemos oprimir cualquier tecla para interrumpir la ejecucion automatica del u-boot.

Seleccionando la opcion del menu: 3: Upload linux to Dataflash, podemos iniciar la transferenciade la imagen a la memoria SDRAM de nuestra plataforma:

P l e a s e t r a n s f e r l i n u x v i a XmodemR e c e i v i n g Xmodem t r a n s f e r

Cuando aparezca este mensaje se debe transmitir el archivo ecb at91.img utilizando el protocoloxmodem. Unos minutos despues la transferencia finaliza, sin embargo, debemos esperar a que la informa-cion sea almacenada en la memoria DataFlash, mientras se completa la escritura la consola no mostrara ningu-na actividad, eso es normal y no se debe reiniciar la board. Una vez finalizada la escritura observaremos elmensaje:

% % % % % % % % % % % % % % % % % % % % %

Almacenamiento en la memoria RAM

El proceso de grabacion en la memoria DataFlash puede tomar alrededor de 6 minutos, lo que nolo hace conveniente cuando se esta tratando de crear una imagen propia o se estan realizando cambios ala misma. Cuando necesitamos modificar esta imagen ya sea porque queremos hacerlo nosotros mismos oporque deseamos una version de kernel mas moderna, es preferible utilizar un metodo de transferencia masrapido.

La plataforma ECB AT91 posee una interfaz de red que puede ser controlada por u-boot. Utilizandoel protocolo tftp U-boot puede descargar la imagen desde un servidor a la memoria SDRAM y ejecutarladesde allı, ese proceso se realiza en segundos, facilitando de esta forma el proceso de desarrollo. A contin-uacion se desciben los pasos que deben seguirse para realizar esta operacion:

Primero debemos instalar y configurar el servidor tftp en el computador donde se tiene las herramien-tas de desarrollo:

$ a p t i t u d e i n s t a l l t f t p d t f t p .

Se debe agregar la siguiente lınea al archivo /etc/inetd.conf

t f t p dgram udp w a i t nobody / u s r / s b i n / t c p d / u s r / s b i n / i n . t f t p d / s r v / t f t p

Debe asegurarse que el protocolo tftp utiliza el puerto UDP 69

$ c a t / e t c / s e r v i c e s | g rep t f t pt f t p 6 9 / udp

Ahora creamos el directorio /srv/tftp29 y colocamos la imagen en el:29Este directorio tiene restricciones de seguridad, debe contactarse con el administrador de su equipo para permitir el acceso a el

Page 65: book

Carlos Ivan Camargo Bareno 65

$ mkdir / s r v / t f t p /$ chown myuser . / s r v / t f t p /$ cp e c b a t 9 1 . img / s r v / t f t p /

Para verificar la correcta configuracion del servidor, podemos utilizar un cliente tftp:

$ cd / tmp /$ t f t p l o c a l h o s t # from t h e s e r v e rt f t p > g e t e c b a t 9 1 . imgRece ived 1319525 b y t e s i n 0 . 2 s e c o n d st f t p > q u i t

Ahora se deben configurar algunas variables de entorno en nuestra plataforma para indicarle a u-bootla direccion IP, el nombre y la ubicacion de la imagen del kernel. Estas variables deben ser modificadaspara que contengan los siguientes valores:

l o a d a d d r =0 x20200000b o o t d e l a y =1b o o t f i l e =” e c b a t 9 1 . img ”f i l e a d d r =20200000g a t e w a y i p = 1 9 2 . 1 6 8 . 0 . 1netmask = 2 5 5 . 2 5 5 . 2 5 5 . 0s e r v e r i p = 1 9 2 . 1 6 8 . 0 . 1 2 8

Estas variables fijan la direccion IP de: la plataforma a 192.168.0.2, del gateway a 192.168.0.1, la delservidor tftp a 192.168.0.12830. Adicionalmente define el nombre de la imagen del kernel a ecb at91.img.Una vez configurado U-boot podemos descargar la imagen a la direccion de memoria 0x20200000:

e c b a t 9 1 > t f t pTFTP from s e r v e r 1 9 2 . 1 6 8 . 0 . 1 ; our IP a d d r e s s i s 1 9 2 . 1 6 8 . 0 . 2F i l ename ’ e c b a t 9 1 . img ’ .Load a d d r e s s : 0 x20200000Loading : #################################################################

###################################################################################################################################################################################################################

doneBytes t r a n s f e r r e d = 1409031 (158007 hex )e c b a t 9 1 >

1.5.5. Inicializacion del Kernel

En general los cargadores de Linux como el u-boot realizan las siguientes funciones:

Configurar e inicializar la RAM

Inicializar un puerto serial

Detectar el tipo de maquina: El boot loader debe proporcionar un valor MACH TYPE XXX al ker-nel, como vimos anteriormente tanto u-boot como Linux fijan este valor a 1072.

30Direccion IP del PC donde estan las herramientas de desarrollo

Page 66: book

66 Sistemas Embebidos

Configurar la kernel tagged list: El boot loader debe crear e inicializar una estructura llamada kerneltagged list, al cual comienza con ATAG CORE y finaliza con ATAG NONE. El tag ATAG COREpuede o no estar desocupado, si se encuentra desocupado debe fijar el campo size en ’2’. El camposize del tag ATAG NONE debe fijarse en 0. Se pueden definir cualquier numero de tags, pero sedeben definir por lo menos el tamano y la localizacion de la memoria del sistema, y la localizaciondel sistema de archivos. Esta tagged list debe ser almacenada en RAM, en una region que no puedaser modificada por el descompresor del kernel o por el programa initrd. Se recomienda colocarlo enlos primeros 16kBytes de la RAM.

Hacer un llamado a la imagen del kernel: Existen dos formas de hacer este llamado, directamentedesde la flash o en en cualquier posicion de la RAM. Los dos metodos deben cumplir las siguientescondiciones:

• Desactiva los dispositivos que tienen capacidad de DMA, de tal forma que la memoria no secorrompa.

• Fijar los registros de la CPU: r0 = 0, r1 = tıpo de maquina, r2 = direccion fısica de la taggedlist en RAM.

• Modo de la CPU: Deshabilitar todas las interrupcione (IRQs y FIQs) y colocar a la CPU enmodo SVC

• Caches, MMU: Debe estar desactivada la MMU, La cache de instrucciones puede estar activadao desactivada, la cache de datos debe estar desactivada.

Llamado a la Imagen del kernel

Como mencionamos anteriormente, u-boot ejecuta las instrucciones almacenadas en la variable deentorno bootcmd; que para la familia de plataformas ECB AT91 almacena el comando bootm C0021840, es-ta instruccion le indica a u-boot que ejecute el comando bootm con una imagen almacenada en la posicion dememoria 0xC0021840, en la que (como mencionamos anteriormente (Figura 1.26)) se almacena la imagendel kernel. El codigo que implementa el comando bootm se encuentra en el archivo common/cmd bootm.c;analizando este archivo podemos descubrir el proceso que realiza u-boot al hacer el llamado a la imagendel kernel (la que almacenamos utilizando la opcion 3 del loader de Darrel). La funcion do bootm realizalas siguientes operaciones:

Verificar la existencia de un numero magico en los primeros 4 bytes de la imagen (0x27051956). Sino se encuentra este numero se desplegara el mensaje: Bad Magic Number

Verifica la integridad del encabezado de la imagen. De no pasar esta prueba se mostrara el mensaje:Bad Header Checksum.

Imprime el encabezado de la imagen, aparecera algo como:

Calcula el CRC del archivo almacenado y lo compara con el almacenado en la cabecera de la imagen.Si no se supera esta prueba, se desplegara el mensaje: Bad Data CRC

Comprueba que la arquitectura esta soportada por u-boot.

Descomprime la imagen almacenada en la direccion load address (la cual se pasa como parametroen el momento de la creacion de la imagen).

Transferir el control a Linux en la funcion do bootm linuxU-boot es un loader que permite trabajarcon: LYNXOS, RTEMS, VXWORKS, QNX, ARTOS, NETBSD

Page 67: book

Carlos Ivan Camargo Bareno 67

La funcion do bootm linux hace el llamado a la imagen del kernel utilizando el siguiente comando:

(∗ k e r n e l ) ( kbd , i n i t r d s t a r t , i n i t r d e n d , c m d s t a r t , cmd end ) ;

en donde:

kbd Informacion de la plataforma de desarrollo:

t y p e d e f s t r u c t b d i n f o {i n t b i b a u d r a t e ; /∗ s e r i a l b a u d r a t e ∗ /unsigned long b i i p a d d r ; /∗ IP Addres s ∗ /unsigned char b i e n e t a d d r [ 6 ] ; /∗ E t h e r n e t a d r e s s ∗ /s t r u c t e n v i r o n m e n t s ∗ b i e n v ;u long b i a r c h n u m b e r ; /∗ i d f o r t h i s board ∗ /u long b i b o o t p a r a m s ; /∗ boo t params ∗ /s t r u c t /∗ RAM c o n f i g u r a t i o n ∗ /{

u long s t a r t ;u long s i z e ;

} b i d r a m [CONFIG NR DRAM BANKS ] ;} b d t ; \end{ i t e m i z e }

initrd start - initrd end: Linux permite que el sistema de archivos sea almacenado en la memoriaRAM, el sistema es almacenado en algun medio no volatil y despues es descomprimido en la RAM,esto acelera la ejecucion ya que como se menciono anteriormente, el acceso a las memorias volatileses mucho menor. initrd start - initrd end indican el inicio y fin de este archivo

cmd start - cmd end: Posicion de memoria donde se almacenan los parametros pasados al kernel(mem=32M root=/dev/mmcblk0p2 rootfstype=ext3 console=ttyS0,115200n8 rootdelay=1)

En este punto termina el trabajo de u-boot y el control es pasado al kernel. Como pudimos darnos cuenta lomas atractivo de u-boot es su capacidad para manejar diferentes dispositivos de almacenamiento no volatilescomo Memorias Flash, memorias SD y su capacidad para manejar interfaces de red y permitir utilizarlaspara al carga de imagenes del kernel.

Punto de Entrada del Kernel head.o

Como puede verse en 1.25 el primer archivo encadenado en la imagen del kernel es arch/arm/k-ernel/head.o, y corresponde al punto de entrada del kernel de Linux, este archivo ejecuta las siguientesfunciones:

1. Verificar que la arquitectura y el procesador sean validos. Si el procesador no es valido se generara unerror y en la consola aparecera una “p”, si la plataforma no corresponde se genera un error y seimprimira una “a” en la consola.

2. Se genera una estructura de datos (page table) que almacena el mapeo entre las direcciones de memo-ria virtual y la memoria fısica. Antes de pasar el control al kernel, el procesador corre un un modoreal, en el que las direcciones corresponden a direcciones reales de los dispositivos conectados fısica-mente al procesador.

3. Activa la unidad de manejo de memoria (MMU) del procesador. Cuando se activa la MMU el es-quema de memoria fısico se remplaza por un direccionamiento virtual determinado por los desarrol-ladores del kernel.

Page 68: book

68 Sistemas Embebidos

4. Establece un limitado mecanismo de deteccion y reporte de errores.

5. Hace un llamado a la funcion start kernel en init/main.c

s e t u p a r c h (& command l ine ) ;s e t u p c o m m a n d l i n e ( command l ine ) ;s c h e d i n i t ( ) ;p r e e m p t d i s a b l e ( ) ;p a g e a l l o c i n i t ( ) ;c o n s o l e i n i t ( ) ;mem in i t ( ) ;k m e m c a c h e i n i t ( ) ;s e t u p p e r c p u p a g e s e t ( ) ;n u m a p o l i c y i n i t ( ) ;c a l i b r a t e d e l a y ( ) ;p i d m a p i n i t ( ) ;p g t a b l e c a c h e i n i t ( ) ;p r i o t r e e i n i t ( ) ;a n o n v m a i n i t ( ) ;f o r k i n i t ( num physpages ) ;p r o c c a c h e s i n i t ( ) ;b u f f e r i n i t ( ) ;u n n a m e d d e v i n i t ( ) ;k e y i n i t ( ) ;s e c u r i t y i n i t ( ) ;v f s c a c h e s i n i t ( num physpages ) ;r a d i x t r e e i n i t ( ) ;s i g n a l s i n i t ( ) ;

p a g e w r i t e b a c k i n i t ( ) ;p r o c r o o t i n i t ( ) ;c g r o u p i n i t ( ) ;c p u s e t i n i t ( ) ;t a s k s t a t s i n i t e a r l y ( ) ;d e l a y a c c t i n i t ( ) ;a c p i e a r l y i n i t ( ) ;s c h e d u l e ( ) ;p r e e m p t d i s a b l e ( ) ;

En los ultimos pasos en el proceso de arranque de Linux, se libera la memoria que sera utilizada porlos procesos de inicializacion, abre un dispositivo que permita la interaccion con el usuario /dev/console(consola serial en nuestro caso) y ejecuta el primer proceso en espacio de usuario init. El siguiente listadomuestra el codigo que implementa esta ultima fase del proceso de arranque.

s t a t i c i n t n o i n l i n e i n i t p o s t ( void ){

f r e e i n i t m e m ( ) ;u n l o c k k e r n e l ( ) ;m a r k r o d a t a r o ( ) ;s y s t e m s t a t e = SYSTEM RUNNING ;n u m a d e f a u l t p o l i c y ( ) ;

i f ( s y s o p e n ( ( c o n s t char u s e r ∗ ) ” / dev / c o n s o l e ” , O RDWR, 0) < 0)p r i n t k (KERN WARNING ” Warning : u n a b l e t o open an i n i t i a l c o n s o l e .\ n ” ) ;

( void ) s y s d u p ( 0 ) ;( void ) s y s d u p ( 0 ) ;

i f ( r amdisk execu te command ) {r u n i n i t p r o c e s s ( ramdisk execu te command ) ;p r i n t k (KERN WARNING ” F a i l e d t o e x e c u t e %s\n ” ,

Page 69: book

Carlos Ivan Camargo Bareno 69

r amdisk execu te command ) ;}

/∗∗ We t r y each o f t h e s e u n t i l one s u c c e e d s .∗∗ The Bourne s h e l l can be used i n s t e a d o f i n i t i f we are∗ t r y i n g t o r e c o v e r a r e a l l y broken machine .∗ /

i f ( execute command ) {r u n i n i t p r o c e s s ( execute command ) ;p r i n t k (KERN WARNING ” F a i l e d t o e x e c u t e %s . A t t e m p t i n g ”

” d e f a u l t s . . . \ n ” , execute command ) ;}r u n i n i t p r o c e s s ( ” / s b i n / i n i t ” ) ;r u n i n i t p r o c e s s ( ” / e t c / i n i t ” ) ;r u n i n i t p r o c e s s ( ” / b i n / i n i t ” ) ;r u n i n i t p r o c e s s ( ” / b i n / sh ” ) ;

p a n i c ( ”No i n i t found . Try p a s s i n g i n i t = o p t i o n t o k e r n e l . ” ) ;}

Como podemos obsever el ultimo paso consiste en el llamado a un archivo en espacio de usuariollamado init o sh, en la siguiente subseccion se describira las acciones que se realizan cuando se ejecutaeste archivo. De no encontrarse se desplegara el mensaje No init found. Try passing init= option to kernel.y la plataforma pasara a un estado de inactividad.

1.6. Inicializacion del Sistema

En esta seccion describiremos el proceso de inicializacion de la plataforma embebida, en la seccionanterior se estudio la inicializacion del kernel de Linux. En esta seccion se realizara una descripcion delsistema de archivos que contiene aplicaciones que Linux requiere para inicializar servicios como los de redy la consola, cargar drivers (modulos) de dispositivos y montar sistemas de archivos adicionales.

1.6.1. Sistema de Archivos

Anteriormente hemos hecho referencia a la localizacion de la raız del sistema de archivos (root),e indicamos que esta se encuentra en una determinada memoria no volatil, estamos indicando donde seencuentra el nivel mas alto del sistema de archivos, el cual se denota como “/”. Existen varias opcionesentre las que se encuentran:

Second Extended File System (ext2) : Este sistema de archivos utiliza bloques como unidad de al-macenamiento basico, inodes como medio para mentener un seguimiento de archivos y objetos desistema, grupos de bloques para dividir logicamente el disco en secciones mas menejables, directo-rios para proporcionar una organizacion jerarquica de archivos, bloques y mapas de bits (bitmap) debloques e inodes para mantener un seguimiento de bloques e inodes asignados, y superbloques paradefinir los parametros del sistema de archivos y su estado general. Adicionalmente posee la capacidadde crear enlaces simbolicos, un tipo especial de archivo que contiene la referencia a otro archivo odirectorio.

Third Extended File System (ext3): ext3 es una extension del sistema de archivos ext2 con ca-pacidades de journaling. El Journaling es utilizado para seguir cambios de archivos y tiene como

Page 70: book

70 Sistemas Embebidos

proposito asegurar que las transacciones sean procesadas de forma adecuada; adicionalmente permitearreglar danos en el sistema de archivos originados por una falla en la fuente de alimentacion de laplataforma.

ReiserFS: Este sistema de archivos al igual que ext3 utiliza journaling. Fue creado con el fın deaumentar el desempeno frente al sistema ext2, es un sistema eficiente en espacio, y mejora el manejode grandes directorios.

Journalling FIle FLash System 2 (JFFS2): Sistema creado para trabajar con dispositivos Flash, loscuales son utilizados ampliamente en aplicaciones embebidas.

Compresed ROM file system (cramfs): Sistema de solo lectura, es utilizado cuando se dispone deuna pequena memoria flash NOR. El maximo tamano de cramfs es de 256MB. Los archivos en estesistema de archivos se encuentran comprimidos.

Network File System: Permite montar particiones de disco o directorios de sistemas remotos co-mo un sistema de archivos local, esto permite compartir recursos como unidades de CDs, DVDs uotro medio de almacenamiento masivo. Por otro lado, reduce el tiempo de desarrollo ya que no esnecesario transferir archivos entre el sitio donde se encuentran las herramientas de desarrollo y laplataforma.

Pseudo File System Este sistema de archivos es utilizado por Linux para representar el estado actualdel kernel. Este sistema de archivos esta montado en el directorio /proc, y dentro de el podemos en-contrar informacion detallada del hardware del sistema. Adicionalmente algunos archivos pueden sermanipulados para informar al kernel cambios en la configuracion. Este sistema de archivos es virtualy es constantemente actualizado por el kernel. Los archivos /proc/cpuinfo, /proc/interrupt, /proc/de-vices, /proc/mounts Proporcionan informacion sobre los dispositivos Hardware de la plataforma

Estructura del Sistema de Archivos

Todas las distribuciones de linux se basan en el standard Filesystem Hierarchy Standard 31 utilizadoen los sistemas operativos UNIX. Este standard permite que los programas y los usuarios conozcan deantemano la localizacion de los archivos instalados. Los siguientes directorios o links simbolicos son deuso obligatorio:

1. bin Ejecutables esenciales.

2. boot Archivos estaticos del boot loader.

3. dev Archivos de dispositivos.

4. etc Configuracion especıfica del host.

5. lib Librerıas esenciales y modulos de kernel.

6. media Punto de montaje para sispositivos removibles.

7. mnt Punto de montaje temporal.

8. opt

9. sbin Ejecutables esenciales del sistema.

31

Page 71: book

Carlos Ivan Camargo Bareno 71

10. srv Datos de servicios suministrados por el sistema.

11. tmp Archivos temporales.

12. usr Segunda jerarquıa.

13. var Datos variables.

1.6.2. Primer Programa en Espacio de Usuario init

Como vimos anteriormente, la primera aplicacion en espacio de usuario que ejecuta el kernel es/sbin/init, todos los procesos que no sean del kernel son generados de forma directa o indirecta por el y esresponsable de la inicializacion de los scripts y terminales. Su papel mas importante es generar procesosadicionales bajo la direccion de un archivo de configracion especial /etc/inittab

Modos de operacion

Existen dos modos de operacion en Linux: Modo usuario simple y Multi-usuario, en el primerosolo se activa una lınea de comandos y el unico usuario que puede utilizarla es el super-usuario root; esutilizado para sistemas en mantenimiento y normalmente se le asigna el nivel de ejecucion 1. En este nivelde ejecucion, no existen procesos demonios32 en ejecucion, y la interfaz de red no esta configurada[20].

El modo multi-usuario es el modo normal de ejecucion del sistema Linux, cuando Linux inicia eneste modo se ejecutan los siguientes procesos:

Se revisa el estado del sistema de archivos con fsck.

Se monta en sistema de archivos.

init analiza el archivo /etc/inittab y

• Determina el nivel de ejecucion

• Ejecuta los scripts asociados con este nivel de ejecucion.

Inicializa los demonios.

Permite el acceso a usuarios.

Niveles de ejecucion

Un nivel de ejecucion puede entenderse como un estado del sistema Hoy dıa, la mayorıa de lasdistribuciones utilizan los siguientes niveles de ejecucion[20]:

1. 0. Cierre o detencion del sistema (halt).

2. 1. Modo usuario simple para configuracion del sistema y mantenimiento.

3. 2. Modo multi-usuario sin red remota.32Proceso que se ejecuta de forma discreta sin intervencion del usuario y es activado por la ocurrencia de una condicion especıfica

Page 72: book

72 Sistemas Embebidos

4. 3. Modo multi-usuario con red. Este es el modo de operacion normal de un usuario de un sistema sincapacidades graficas.

5. 4. No utilizado - Definido por el usuario.

6. 5. Modo multi-usuario con interfaz grafica.

7. 6. Re-inicializacion del sistema (reboot).

El nivel de ejecucion pude ser cambiado por el super-usuario (root) en cualquier momento utilizandoel comando init n, donde n es el nivel de ejecucion deseado.

El Archivo /etc/inittab

Como se menciono anteriormente el programa init esta encargado de montar el sistema de archivosy de analizar el archivo /etc/inittab. Este archivo contiene:

Una entrada para el nivel de ejecucion por defecto. Nivel de ejecucion en que inicia el sistema amenos que especifique otra cosa en el boot loader.

Entradas que deben ser ejecutadas en todos o en un especıfico nivel de ejecucion, su sintaxis es:id:runlevels:action:process [arguments]

• id Cualquier cosa.

• runlevels Puede ser un numero o lista de numeros de 0 a 6.

• action Accion a tomar:

◦ respawn El proceso debe ser re-iniciado una vez finalice.◦ wait start Ejecuta el proceso cuando se ingresa al nivel de ejecucion y espera por su termi-

nacion.◦ bootwait El proceso debe ser ejecutado durante la incializacion del sistema.◦ initdefault Especifica el nivel de ejecucion al que se ingresa despues de la inicializacion del

sistema.◦ sysinit El proceso debe ejecutarse durante la inicializacion del sistema. Debe ejecutarse

antes de cualquier entrada boot o bootinit

• process Programa o script a ser ejecutado.

En el siguiente listado se muestra un archivo inittab tıpico:

# The d e f a u l t r u n l e v e l .i d : 5 : i n i t d e f a u l t :

# Boot−t ime sys tem c o n f i g u r a t i o n / i n i t i a l i z a t i o n s c r i p t .# Thi s i s run f i r s t e x c e p t when b o o t i n g i n emergency (−b ) mode .s i : : s y s i n i t : / e t c / i n i t . d / r cS

# What t o do i n s i n g l e−u s e r mode .˜ ˜ : S : w a i t : / s b i n / s u l o g i n

# / e t c / i n i t . d e x e c u t e s t h e S and K s c r i p t s upon change# of r u n l e v e l .

Page 73: book

Carlos Ivan Camargo Bareno 73

l 0 : 0 : w a i t : / e t c / i n i t . d / r c 0l 1 : 1 : w a i t : / e t c / i n i t . d / r c 1l 2 : 2 : w a i t : / e t c / i n i t . d / r c 2l 3 : 3 : w a i t : / e t c / i n i t . d / r c 3l 4 : 4 : w a i t : / e t c / i n i t . d / r c 4l 5 : 5 : w a i t : / e t c / i n i t . d / r c 5l 6 : 6 : w a i t : / e t c / i n i t . d / r c 6# Normal ly n o t r eached , b u t f a l l t h r o u g h i n case of emergency .z6 : 6 : respawn : / s b i n / s u l o g i nS : 2 3 4 5 : respawn : / s b i n / g e t t y 115200 t t y S 0# / s b i n / g e t t y i n v o c a t i o n s f o r t h e r u n l e v e l s .

1 : 2 3 4 5 : respawn : / s b i n / g e t t y 38400 t t y 1

En este archivo se define el nivel de ejecucion 5 como el nivel por defecto. El primer script enejecutarse es /etc/init.d/rcS (ya que su accion es del tipo sysinit). Luego se ingresa al nivel de ejecucion5 y se ejecuta el script /etc/init.d/rc pasandole el argumento “5” y espera hasta que el script se complete./etc/init.d/rc ejecuta los scripts localizados en directorios individuales para cada nivel: /etc/rcX.d (X unentero de 0 a 6); el nombre de los archivos localizados en estos directorios deben comenzar con el caracter“S” (para iniciar procesos) o “K” (para “matar” procesos), y dos caracteres numericos: S[0-9][0-9], S[0-9][0-9]. Un script tıpico de inicializacion del demonio del servidor web cherokee se muestra en el siguientelistado (/etc/rc5.d/S91cherokee):

# ! / b i n / shDAEMON=/ u s r / s b i n / c h e r o k e eCONFIG=/ e t c / c h e r o k e e / c h e r o k e e . con fPIDFILE =/ v a r / run / c h e r o k e e . p i dNAME=” c h e r o k e e ”DESC=” Cherokee h t t p s e r v e r ”

t e s t −r / e t c / d e f a u l t / c h e r o k e e && . / e t c / d e f a u l t / c h e r o k e et e s t −x ”$DAEMON” | | e x i t 0t e s t ! −r ”$CONFIG” && e x i t 0

case ” $1 ” i ns t a r t )

echo ” S t a r t i n g $DESC : ”s t a r t −s top−daemon −−oknodo −S −x $DAEMON −− −b −C $CONFIG; ;

s t o p )echo ” S t o p p i n g $DESC : ”s t a r t −s top−daemon −K −p $PIDFILE; ;

r e s t a r t )$0 s t o p >/dev / n u l l 2>&1$0 s t a r t; ;

∗ )echo ” Usage : $0 { s t a r t | s t o p | r e s t a r t }”e x i t 0; ;

e s a c

Como podemos ver existen tres parametros que podemos pasar al script: start, stop y restart, cuyasacciones son iniciar, detener y reiniciar el demonio respectivamente. El directorio /etc/init.d contiene todoslos scripts utilizados en los diferentes niveles de ejecucion, el nombre de ellos en este directorio no incluyen

Page 74: book

74 Sistemas Embebidos

los caracteres S[0-9][0-9] o K[0-9][0-9].

La lınea S:2345:respawn:/sbin/getty 115200 ttyS0 inicia una consola por el puerto serial /dev/ttyS0con una velocidad de 9200 baudios, cuando el nivel de ejecucion sea 2, 3, 4 o 5. Finalmente se crea unaterminal virtual para los niveles de ejecucion multi-usuario.

Cuando el super-usuario cambia el nivel de ejecucion con el comando init, los procesos unicos alnievel anterior son terminados y los procesos unicos del nuevo nivel son iniciados.

1.6.3. Distribuciones Linux

Aunque es posible construir el sistema de atchivos nosotros mismos, no es nada practico ya que esuna tarea tediosa que requiere cierto nivel de experiencia. En la actualidad, existen varias distribuciones querealizan estas tareas por nosotros, dentro de las mas utilizadas se encuentran:

Busybox

Disenado para optimizar el tamano y rendimiento de aplicaciones embebidas, BusyBox 33 combinaen un solo ejecutable mas de 70 utilidades estandares UNIX, en sus versiones ligeras. BusyBox es consid-erada la navaja suiza de los sistema embebidos, dado que permite sustituir la gran mayorıa de utilidades quese suelen localizar en los paquetes GNU fileutils, shellutils, findutils, textutils, modutils, grep, gzip, tar, etc.

Busybox hace parte de la mayorıa de distribuciones de Linux para sistemas embebidos y en la actu-alidad proporciona las siguientes funciones:

addgroup, adduser, adjtimex, ar, arping, ash, awk, basename, bunzip2, busybox, bzcat, cal, cat,chgrp, chmod, chown, chroot, chvt, clear, cmp, cp, cpio, crond, crontab, cut, date, dc, dd, deallocvt, del-group, deluser, df, dirname, dmesg, dos2unix, dpkg, dpkg-deb, du, dumpkmap, dumpleases, echo, egrep,env, expr, false, fbset, fdflush, fdisk, fgrep, find, fold, free, freeramdisk, fsck.minix, ftpget, ftpput, getopt, get-ty, grep, gunzip, gzip, halt, head, hexdump, hostid, hostname, httpd, hwclock, id, ifconfig, ifdown, ifup, init,ip, ipaddr, ipcalc, iplink, iproute, iptunnel, kill, killall, klogd, last, length, linuxrc, ln, loadfont, loadkmap,logger, login, logname, logread, losetup, ls, makedevs, md5sum, mesg, mkdir, mkfifo, mkfs.minix, mknod,mkswap, mktemp, more, mount, mt, mv, nameif, nc, netstat, nslookup, od, openvt, passwd, patch, pidof, ping,ping6, pivot root, poweroff, printf, ps, pwd, rdate, readlink, realpath, reboot, renice, reset, rm, rmdir, route,rpm, rpm2cpio, run-parts, sed, setkeycodes, sh, sha1sum, sleep, sort, start-stop-daemon, strings, stty, su,sulogin, swapoff, swapon, sync, syslogd, tail, tar, tee, telnet, telnetd, test, tftp, time, top, touch, tr, traceroute,true, tty, udhcpc, udhcpd, umount, uname, uncompress, uniq, unix2dos, unzip, uptime, usleep, uudecode,uuencode, vi, vlock, watch, watchdog, wc, wget, which, who, whoami, xargs, yes, zcat.

Buildroot

Buildroot34 Es un grupo de Makefiles y patches que facilita la generacion de la cadena de herramien-tas y el sistema de archivos para un sistema embebido que usa Linux. Posee una interfaz que permite realizarde forma facil la configuracion; utiliza busybox para generar la utilidades basicas de Linux y permite adaptarsoftware adicional de forma facil 35.

33http://www.busybox.net/34http://buildroot.uclibc.org/35http://buildroot.uclibc.org/buildroot.html#add software

Page 75: book

Carlos Ivan Camargo Bareno 75

Openembedded

Al igual que Buildroot, el proyecto openembedded proporciona un entorno que permite generar lacadena de herramientas y el sistema de atchivos para un sistema embebido, utiliza busybox y permite lacreacion de archivos que permiten compilar software que no se incluya en la distribucion original. Adi-cionalmente openembedded crea archivos de instalacion con un formato derivado del proyecto handhelds36 ipk, lo que permite la instalacion de paquetes de forma similar a la distribucion debian.

La informacion necesaria para generar una distribucion utilizando las herramientas de Openembed-ded se encuentra en http://www.emqbit.com/mediawiki/index.php/Main Page/ecb at91/OE.

1.7. Modulos del kernel

Los modulos son pequenas piezas de codigo que pueden ser cargadas y descargadas en el kernelen el momento que sea necesario. Ellos extienden la funcionalidad del kernel, sin la necesidad de reini-ciar el sistema y recompilar el kernel. Por ejemplo, un tipo de modulo es el controlador de dispositivo, elcual permite al kernel acceder a un dispositivo hardware conectado al sistema. Este tipo de modulos seranestudiados en esta seccion.

Existen tres tipos de dispositivos en Linux [22]:

Tipo Caracter: Puede accederse de forma similar a un archivo; este tipo de dispositivos permite porlo menos las operaciones open, close, read. Ejemplos de este tipo de dispositivo son el puerto serie(/dev/ttyS0) y la consola (/dev/console)

Tipo Bloque: Este tipo de dispositivo puede hospedar un sistema de archivos; normalmente realizaoperaciones de bloques de datos unicamente; un ejemplo de este tipo de dispositivo es el disco duro(/dev/hda).

Red: Toda transaccion de red se realiza a traves de una interfaz, esto es, un dispositivo hardware(/dev/eth0) o software (loopback) capaz de intercambiar datos con otros hosts.

1.7.1. Ejemplo de un driver tipo caracter

Recuerde que una aplicacion en el area de usario, no puede acceder directamente al area del kernel;los dispositivos se acceden a traves de archivos de dispositivos, localizados en /dev (ver figura 1.28), Acontinuacion se muestra la salida del comando ls -l /dev/

brw−rw−−−− 1 r o o t d i s k 3 , 0 Nov 27 hdabrw−rw−−−− 1 r o o t d i s k 3 , 1 Nov 27 hda1brw−rw−−−− 1 r o o t d i s k 3 , 2 Nov 27 hda2crw−rw−−−− 1 r o o t uucp 4 , 64 Nov 27 t t y S 0crw−rw−−−− 1 r o o t uucp 4 , 65 Nov 27 t t y S 1

Los archivos tipo caracter estan identificados por una “c” en la primera columna, mientras que losdispositivos tipo bloque por una “b”. Podemos observar que existen dos numeros (5ta y 6ta columna) queidentifican al driver, el numero de la 5ta columna recibe el nombre de major number y el de la sexta minor

36http://handhelds.org

Page 76: book

76 Sistemas Embebidos

Figura 1.27: Interaccion entre el area de usuario y el driver del dispositivo. Fuente: [?]

number; estos numeros son utilizados por el sistema operativo para determinar el dispositivo y el driver quedeben ser accesados ante una solicitud a nivel de usuario.

El major number identifica la clase o grupo del dispositivo, mientras que el minor number se utilizapara identificar sub-dispositivos (Ver Figura ??).

Figura 1.28: major y minor footnotehttp://uw713doc.sco.com/en/HDK concepts/ddT majmin.html

El kernel de linux permite que los drivers compartan el numero mayor, como el caso del disco duro,hda posee dos particiones hda1 y hda2, las cuales son manejadas por el mismo driver, pero se asigna unnumero menor unico a cada una; lo mismo sucede con el puerto serie.

Implementacion del driver de un LED

A continuacion se realizara la descripcion de un driver tipo caracter para un dispositivo muy sencillo,un LED [?]. Este ejemplo fue implementado en un procesador PXA255 de Intel y realiza las siguientesoperaciones:

init: Se ejecuta cuando se carga el modulo, el LED se apagara.

close: Se ejecuta cuando se descarga el modulo, el LED se encendera.

open: Se ejecuta cuando se realiza una operacion de lectura o escritura al dispositivo.

Page 77: book

Carlos Ivan Camargo Bareno 77

Existen dos funciones que deben estar presentes en todo tipo de modulo, estas son: module init ymodule exit las cuales se ejecutan cuando se carga y descarga el modulo respectivamente.

s t r u c t f i l e o p e r a t i o n s f o p s = {. open = d e v i c e o p e n ,. r e l e a s e = d e v i c e r e l e a s e ,

} ;

s t a t i c i n t i n i t b l i n k i n i t ( void ){

p r i n t k ( KERN INFO ”BLINK module i s Up .\ n ” ) ;

Major = r e g i s t e r c h r d e v ( 0 , DEVICE NAME, &f o p s ) ;

i f ( Major < 0) {p r i n t k (KERN ALERT ” R e g i s t e r i n g c h a r d e v i c e f a i l e d

wi th %d\n ” , Major ) ;re turn Major ;

}

p r i n t k (KERN ALERT ” I was a s s i g n e d major number %d .To t a l k t o \n ” , Major ) ;

p r i n t k (KERN ALERT ” t h e d r i v e r , c r e a t e a dev f i l ewi th\n ” ) ;

p r i n t k (KERN ALERT ” ’ mknod / dev/ %s c %d 0 ’ .\ n ” ,DEVICE NAME, Major ) ;

pxa gp io mode ( GPIO LED MD ) ;pxa gp io mode ( GPIO LED OFF ) ; /∗ Turn LED OFF∗ /

re turn 0 ;}

s t a t i c vo id e x i t b l i n k e x i t ( void ){

i n t r e t ;

r e t = u n r e g i s t e r c h r d e v ( Major , DEVICE NAME ) ;i f ( r e t < 0 )

p r i n t k ( KERN ALERT ” E r r o r i n u n r e g i s t e r c h r d e v :%d\n ” , r e t ) ;

p r i n t k ( KERN INFO ”BLINK d r i v e r i s down . . . \ n ” ) ;}

m o d u l e i n i t ( b l i n k i n i t ) ;m o d u l e e x i t ( b l i n k e x i t ) ;

MODULE LICENSE( ”GPL” ) ;MODULE AUTHOR( ” C a r l o s Camargo UNAL” ) ;MODULE DESCRIPTION( ”BLINKER LED d r i v e r ” ) ;MODULE VERSION( ” 1 : 0 . 1 ” ) ;

Las funciones module init module exit deben ser declaradas como static ya que no seran visiblesfuera del archivo. Como puede observarse en la lınea 83 se hace la definicion de las funciones que debenejecutarse al cargar y descargar el modulo en nuestro caso blink init y blink exit respectivamente. La infor-macion sobre el modulo aparece en las lıneas 87-90.

Page 78: book

78 Sistemas Embebidos

En la lınea 40 se define la estructura de operaciones de archivo del modulo; cada campo de la estruc-tura corresponde a la direccion de una funcion definida por el driver para manejar una solicitud determinada.En nuestro caso solo existe una funcion open, la cual sera definida mas adelante.

Como se puede ver en la figura 1.28 es necesario que el kernel sepa que driver esta encargado deldispositivo, esto es, el major number del driver que lo maneja; por esto, lo primero que se debe haceres obtener este numero. En la funcion blink init (lınea 49) podemos observar la forma en que se realizael registro de nuestro dispositivo. La funcion register chrdev retorna el numero mayor asignado de formadinamica, esto es recomendable ya que si se fijara un numero de forma arbitaria, podrıa causar conflictoscon otros dispositivos. De esta forma, al cargar el modulo con el comando: insmod blinker.ko, el LED seapagara y aparecera el siguiente mensaje en la consola:

BLINK module i s Up .I was a s s i g n e d major number 2 5 3 . To t a l k t ot h e d r i v e r , c r e a t e a dev f i l e w i th’ mknod / dev / b l i n k c 253 0 ’ .

Con lo anterior, nuestro dispositivo es registrado y se le asigna el numero 253 como major number, en el archivo /proc/devicesaparecen los dispositivos que actualmente estan siendo utilizados por el kernel, este archivo debe contener una entrada para blink dela forma: 253 blink.

En la funcion blink exit se realiza la liberacion del dispositivo ( la funcion unregister chrdev, lınea 75), la cual se ejecutacuando se lanza el comando: rmmod blinker.ko, el que a su vez hace que se encienda el LED y se imprima en la consola el mensaje:

BLINK d r i v e r i s down . . .

Como se menciono anteriormente es posible manejar un archivo tipo caracter como si fuera un archivo de texto, por lo tanto,es posible adicionar funciones a las acciones de abrir, cerrar, escribir en o leer del dispositivo.

20s t a t i c i n t d e v i c e o p e n ( s t r u c t i n o d e ∗ inode , \21s t r u c t f i l e ∗ f i l e )22{23unsigned i n t i ;24p r i n t k ( KERN INFO ”Open BLINKER\n ” ) ;25i f ( i s d e v i c e o p e n )26re turn −EBUSY;2728i s d e v i c e o p e n = 1 ;2930f o r ( i =0 ; i <5; i ++ ){31pxa gp io mode ( GPIO LED ON ) ;32mdelay (0 x0080 ) ;33pxa gp io mode ( GPIO LED OFF ) ;34mdelay (0 x0080 ) ;35}3637t r y m o d u l e g e t (THIS MODULE ) ;38re turn SUCCESS ;39}

Esta seccion de codigo se ejecuta cada vez que el archivo de dispositivo /dev/blink es abierto, esto sucede en operaciones delectura o escritura. Es decir si se utilizan los siguientes comandos:

more / dev / b l i n kc a t f i l e > / dev / b l i n kcp f i l e / dev / b l i n k

Con cada uno de estos comandos el LED se encendera y apagara y en la consola se despliega el mensaje:

Open BLINKERClose BLINKER

Page 79: book

Carlos Ivan Camargo Bareno 79

1.8. Interfaz con Perifericos dedicados

Es comun que algunas aplicaciones requieran ciertos perifericos especiales que les permitan cumplir las restricciones tem-porales, es decir, es necesario crear tareas Hardware que ayuden a las tareas software a cumplir con las restricciones de diseno. Paraesto es necesario implementar algunas funciones en perifericos externos al procesador. Si la tarea no se encuentra implementada enun dispositivo comercial es necesario implementarlas en un Dispositivo Logico Programable (PLD) o en un Circuito Integrado deAplicacion Especıfica (ASIC).

En esta seccion realizaremos una explicacion detallada del proceso de comunicacion entre el procesador y un perifericoimplementado en una FPGA.

1.8.1. Comunicacion Procesador - Periferico

La figura 1.29 muestra una arquitectura basica para la comunicacion de tareas Hardware - Software; en ella podemos observarque el procesador maneja tres buses:

Bus de Datos: Bus bidireccional por donde se realiza el intercambio de informacion.Bus de Direcciones: Bis controlado por el procesador y es utilizado para direccionar un determinado periferico o una detrmi-nada funcionalidad del mismo.Bus de control: Senales necesarias para indicarle a los perifericos el tipo de comunicacion (Lectura o escritura).

Figura 1.29: Arquitectura basica Hardware/Software

Todos los perifericos que requieren intercambio de informacion con el procesador comparten el mismo bus de datos, por loque es necesario que mientras el procesador no se comunique con ellos permanezcan en estadp de alta impedancia, esto es necesariopara evitar corto - circuitos originados por diferentes niveles logicos en el bus. Por lo tanto, las comunicaciones siempre son iniciadaspor el procesador y se selecciona uno y solo un periferico. El decodificador de direcciones es el encargado de habilitar un determinadoperiferico ante una solicitud del procesador (mediante una direccion de memoria), esto lo hace activando la senal CSX, cuando estasenal se encuentra en estado logico alto el periferico coloca su bus de datos en alta impedancia, si se encuentra en estado logico bajoel periferica escribe o lee el bus de datos, dependiendo de la activacion de las senales del bus de control RD y WR.

El decodificador de direcciones, como su nombre lo indica utiliza como entradas el bus de direcciones y activa solo unasenal de seleccion de Chip (CSx), basandose en un rango de direcciones asignado a cada periferico, este rango de direcciones no debetraslaparse para asegurar que solo un chip es seleccionado. Este rango de direcciones que se asigna a cada dispositivo que puede seraccesado por la unidad de procesamiento recibe el nombre de mapa de memoria y puede ser unico para cada plataforma.

Cuando la unidad de procesamiento necesite comunicarse con un determinado periferico, colocara en el bus de direccionesuna valor que se encuentre en el rango de direcciones asignado para ese periferico, esto hace que el decodificador de direcciones active

Page 80: book

80 Sistemas Embebidos

la senal de seleccion adecuada para informarle al periferico que el procesador va a iniciar una transferencia de informacion. La Figura1.30 muestra el diagrama de tiempos para un ciclo de lectura y escritura del procesador.

Figura 1.30: Ciclo de lectura y escritura para la arquitectura de la Figura 1.29

De lo anterior podemos concluir que un periferico es visto por el procesador como una posicion de memoria mas y lastransacciones las inicia unicamente el procesador.

Implementacion de Perifericos en una FPGA

Es importante tener en cuenta los siguientes items cuando se implemente una tarea Hardware en una FPGA:

La frecuencia del reloj de la FPGA es mucho mayor que la de las senales del bus de control, por lo que es necesario asegurarseque cada vez que el procesador realiza una solicitud de lectura o escritura, la senal de activacion cambia del estado logico altoal bajo; si solo se tiene en cuenta el estado bajo de la senal CSX el periferico puede ejecutar la tarea varias veces en el mismociclo de activacion, lo que puede llevar a resultados incorrectos.

La fase de los relojes del procesador y la FPGA no es la misma, por lo que es necesario sincronizar las senales del procesadorcon el reloj de la FPGA; si esto no se hace las senales fuera de fase pueden originar un estado de metaestabilidad en losFlip-Flops internos y por lo tanto el mal-funcionamiento del sistema.

El bus de datos es bidireccional, por lo que es necesario que la FPGA lo coloque en alta impedancia cuando no se este habili-tando un periferico.

La FPGA no permite implementar buffers tri-estado internamente por lo que es necesario separar los buses de entrada ysalida a cada periferico. El bus de entrada es comun a todos los perifericos mientra que es necesario utilizar un esquema demultiplexacion entre los buses de salida.

La figura 1.31 muestra el diagrama de bloques de la interfaz necesaria para poder comunicar un grupo de perifericos o tareasHardware con el bus de datos, direccion y control de un procesador. El bloque SYNC se encarga de sincronizar las senales provenientesde la FPGA con el reloj interno de la misma.

El modulo Write Pulse generator genera un pulso cuando las senales sncs y snwe son activadas como se indica en la figura1.32. El decodificador de direcciones selecciona un determinado periferico dependiendo del rango especificado para cado uno. Comomencionamos anteriormente, las FPGAs no permiten implementar buffers tri-estado internamente , por lo que cada periferico debetener un bus de entrada y uno de salida de datos, los buses de entrada de datos son comunes, mientras que los de salida debenser manejados por un dispositivo de salida, el cual puede ser un multiplexor controlado por el decodificador de direcciones o unacompuerta OR, para este ultimo caso es necesario que los perifericos coloquen el bus de datos en “0” cuando no esten seleccionados.Finalmente es necesario colocar un buffer tri-estado en los pines de la FPGA, este buffer esta controlado por las senales nwe, noe, ncsy solo se activa cuando nwe = 1, noe = 0, ncs = 0, es decir, cuando se selecciona el rango de memoria de la FPGA y el procesadorinicia una operacion de lectura.

Page 81: book

Carlos Ivan Camargo Bareno 81

Figura 1.31: Diagrama de Bloques para la comunicacion de tareas HW-SW 1.29

Figura 1.32: Generacion del pulso de escritura

Programa en Espacio de Usuario para la comunicacion

El kernel de Linux proporciona una interfaz que permite a una aplicacion mapear un archivo en memoria, lo que hace queexista una correspondencia uno a uno entre las direcciones de memoria y el contenido del archivo. Linux implementa la llamada desistema mmap() para mapear objetos en memoria.[23]

# i n c l u d e <s y s / mman . h>

void ∗ mmap ( void ∗ addr ,s i z e t l en ,i n t p r o t ,i n t f l a g s ,i n t fd ,o f f t o f f s e t ) ;

Un llamado a mmap() le pide al kernel hacer un mapeo en la memoria de len bytes del objeto representado por el descriptorde archivo fd, comenzando a offset bytes dentro del archivo. Si se especifica addr, se utiliza este valor como la direccion inicial enla memoria. Los permisos de acceso son determinados por prot; PROT READ habilita la lectura, PROT WRITE habilita escritura yPROT EXEC habilita la ejecucion. El argumento flasgs describe el tipo de mapeo, y algunos elementos de su comportamiento y puede

Page 82: book

82 Sistemas Embebidos

tomar los valores:

MAP FIXED: hace que addr sea un requerimiento, si el kernel es incapaz de hacer el mapeo en esta direccion el llamado falla,si los parametros de direccion y longitud traslapan un mapeo existente se descartan las areas que se traslapan y se remplazanpor el nuevo mapeo.

MAP PRIVATE: Establece que el mapeo no es compartido. Los cambios realizados a la memoria por este proceso no sereflejan en el archivo actual o en el mapeo de los otros procesos.

MAP SHARED: Comparte el mapeo con otros procesos que usan el mismo archivo. Escribir en el mapeo equivale a escribiren el archivo.

A continuacion se lista un ejemplo de la utilizacion del llamado mmap

# d e f i n e MAP SIZE 0 x2000000l / / ECBOT USE A11 t o A25# d e f i n e MAP MASK ( MAP SIZE − 1)

i n t fd ;unsigned long i , j ;void ∗ base ;v o l a t i l e unsigned s h o r t ∗ v i r t a d d r ;

io map (0 xFFFFFF7C ) ; / / C o n f i g u r e CS3 as 16 b i t Memory and 0 Wait S t a t e so f f t a d d r e s s = 0 x40000000 ; / / CS3 Base Addres s

i f ( ( fd = open ( ” / dev /mem” , O RDWR | O SYNC ) ) == −1){p r i n t f ( ” Cannot open / dev /mem.\ n ” ) ;re turn −1;

}p r i n t f ( ” / dev /mem opened .\ n ” ) ;

ba se = mmap ( 0 , MAP SIZE , PROT READ | PROT WRITE ,MAP SHARED, fd , a d d r e s s ) ;

i f ( ba se == ( void ∗ ) −1){p r i n t f ( ” Cannot mmap .\ n ” ) ;re turn −1;

}p r i n t f ( ”Memory mapped a t a d d r e s s %p .\ n ” , ba se ) ;

v i r t a d d r = base ;

En este ejemplo utilizamos el llamado mmap para hacer un mapeo de la direccion de memoria correspondiente al CS3(0x40000000). El descriptor del archvio utilizado es el dispositivo /dev/mem el cual permite operaciones de lectura y escritura a lamemoria virtual. Adicionalmente permitimos operaciones de lectura/escritura (PROT READ — PROT WRITE) y permitimos el acce-so a otros proceso. Finalmente podemos usar la variable virt addres para escribir en cualquier posicion de memoria desde 0x40000000hasta 0x40000000 + MAP SIZE. El siguiente listado muestra un ejemplo de la forma de hacer estas operaciones.

p r i n t f ( ” W r i t i n g Memory . . \ n ” ) ;f o r ( i = 0 ; i <32; i ++){v i r t a d d r [ i <<10] = i ∗3 ; / / ECBOT use A11 t o A25}

p r i n t f ( ” Reading Memory . . \ n ” ) ;f o r ( i = 0 ; i < 3 2 ; i ++){

j = v i r t a d d r [ i <<10];p r i n t f ( ” %X = %X\n ” , i , j ) ;

}i f ( munmap ( base , MAP SIZE ) == −1){

p r i n t f ( ” Cannot munmap .\ n ” ) ;re turn −1;

}

Page 83: book

Carlos Ivan Camargo Bareno 83

1.8.2. Comunicacion Periferico - Procesador

Cuando un periferico requiere atencion por parte de la CPU debido a que termino de realizar un proceso o porque requierenuevas instrucciones para seguir operando, o un evento originado por un usuario necesita ser atendido, se debe iniciar un proceso paraque la unidad de procesamiento se comunique con el. Como se menciono anteriormente la unidad de procesamiento esta encargadade forma exclusiva de iniciar las operaciones de lectura/ecritura con los perifericos, por esta razon, el periferico utiliza una senal(IRQ) para informarle al procesador que requiere ser atendido. Algunas arquitecturas poseen un mecanismo que permite el acceso a lamemoria por parte de los perifericos sin utilizar el procesador, esto permite que perifericos de diferentes velocidades se comuniquensin someter al procesador a una carga excesiva. En esta seccion hablaremos de la forma de definir las interrupciones en un driver deLinux.

Manejo de Interrupciones

A continuacion se describira la forma de manejar las interrupciones utilizando un driver de Linux. Analicemos la funcionqem init

s t a t i c i n t i n i t q e m i n i t ( void ){

i n t r e s ;p r i n t k ( KERN INFO ”FPGA module i s Up .\ n ” ) ;

Major = r e g i s t e r c h r d e v ( 0 , DEVICE NAME, &f o p s ) ;

i f ( Major < 0) {re turn Major ;

}

/∗ S e t up t h e FGPA i r q l i n e ∗ /a t 9 1 s e t g p i o i n p u t ( FPGA IRQ PIN , 0 ) ;a t 9 1 s e t d e g l i t c h ( FPGA IRQ PIN , 1 ) ;

r e s = r e q u e s t i r q ( FPGA IRQ PIN , i r q h a n d l e r , IRQF DISABLED , ”FPGA − IRQ” , NULL ) ;

s e t i r q t y p e ( FPGA IRQ , IRQT RISING ) ;

i o a d d r e s s = ioremap ( FPGA BASE , 0 x4000 ) ;

re turn 0 ;}

Esta rutina es similar a la presentada anteriormente, solo se agrega un par de comandos para definir un pin del procesadorcomo entrada, para poder utilizarlo como senal IRQ, en la lınea:

r e s = r e q u e s t i r q ( FPGA IRQ PIN , i r q h a n d l e r , IRQF DISABLED , ”FPGA − IRQ” , NULL ) ;r e q u e s t i r q ( i n t i r q , h a n d l e r , i r q f l a g s , devname , d e v i d ) ;

Se hace un llamado a la funcion request irq que asigna recursos a la interrupcion, habilita el manejador y la lınea de inter-rupcion. En nuestro caso define el pin FPGA IRQ PIN como la lınea de interrupcion, la rutina irq handler sera ejecutada cuando sepresente una interrupcion, el flag IRQF DISABLED deshabilita las interrupciones locales mientras se procesa, el nombre del disposi-tivo que realiza la interrupcion es FPGA - IRQ.

La funcion ioremap(offset, size), una secuencia de operaciones que permiten que la memoria de la CPU se pueda acceder conlas funciones readb/readw/readl/writeb/writew/write, utilizando la variable ioaddress. Finalmente se define el tipo de interrupcion delpin FPGA IRQ PIN como IRQT RISING.

La funcion que se ejecuta cuando se presenta la interrupcion, se define en el siguiente listado:

i r q r e t u r n t i r q h a n d l e r ( i n t i r q , void ∗ d e v i d , s t r u c t p t r e g s ∗ r e g s ){

i f ( i r q e n a b l e d ){

i n t e r r u p t c o u n t e r ++;

Page 84: book

84 Sistemas Embebidos

p r i n t k ( KERN INFO ” i n t e r r u p t c o u n t e r= %d\n ” , i n t e r r u p t c o u n t e r ) ;p r i n t k ( ”\n k e r n e l : IREG LP: %X \n ” , r e a d b ( &i o a d d r e s s [0 x40 ] ) ) ;w a k e u p i n t e r r u p t i b l e (&wq ) ;

}re turn IRQ HANDLED ;

}

Cada vez que se produce una interrupcion y si la variable global irq enabled es igual a 1, se aumenta en 1 el valor deinterrupt counter, se imprime su valor y el de un registro interno del periferico.

En este driver utilizaremos la funcion device read para enviar informacion a un programa en espacio de usuario.

s t a t i c s s i z e t d e v i c e r e a d ( s t r u c t f i l e ∗ f i l p , /∗ s e e i n c l u d e / l i n u x / f s . h ∗ /char ∗ b u f f e r , /∗ b u f f e r t o f i l l w i t h da ta ∗ /s i z e t count , /∗ l e n g t h o f t h e b u f f e r ∗ /l o f f t ∗ o f f s e t )

{i f ( i r q e n a b l e d ){

w a i t e v e n t i n t e r r u p t i b l e ( wq , i n t e r r u p t c o u n t e r ! = 0 ) ;c o p y t o u s e r ( b u f f e r , &i n t e r r u p t c o u n t e r , s i z e o f ( i n t e r r u p t c o u n t e r ) ) ;i n t e r r u p t c o u n t e r =0 ;

}e l s e {

i n t e r r u p t c o u n t e r = −1;c o p y t o u s e r ( b u f f e r , &i n t e r r u p t c o u n t e r , s i z e o f ( i n t e r r u p t c o u n t e r ) ) ;

}re turn s i z e o f ( i n t e r r u p t c o u n t e r ) ;

}

Cuando se realice una operacion de lectura desde espacio de usuario, el proceso quedara bloqueado por la funcion wait event interruptiblehasta que la rutina de atencion a la interrupcion ejecute la funcion wake up interruptible, pero es necesario que se cumpla la condicionevaluada por wait event interruptible para que se ejecute la tarea. Para este ejemplo:

w a i t \ e v e n t \ i n t e r r u p t i b l e ( wq , i n t e r r u p t \ c o u n t e r ! = 0 ) ;

Por lo que irq handler debe hacer:

i n t e r r u p t c o u n t e r ++;w a k e u p i n t e r r u p t i b l e (&wq ) ;

Si no se hace esto el proceso nunca se despertara y el proceso de lectura quedara bloqueado.

En la lınea:

c o p y t o u s e r ( b u f f e r , &i n t e r r u p t c o u n t e r , s i z e o f ( i n t e r r u p t c o u n t e r ) ) ;c o p y t o u s e r ( to , from , long n ) ;

Se utiliza la funcion copy to user para intercambiar informacion con el programa que se ejecuta en espacio de usuario. Eneste caso se copia a char *buffer, la variable interrupt counter. Existe una funcion analoga que recibe informacion proveniente delespacio de usuario copy from user En la Figura 1.33 se muestran estas operaciones.

En la funcion qem exit se liberan los recursos de la interrupcion y la variable ioaddress.

s t a t i c vo id e x i t q e m e x i t ( void ){

i n t r e t ;/∗ Tho o r d e r f o r f r e e i r q , iounmap & u n r e g i s t e r i s v e r y i m p o r t a n t ∗ /f r e e i r q ( FPGA IRQ PIN , NULL ) ;iounmap ( i o a d d r e s s ) ;u n r e g i s t e r c h r d e v ( Major , DEVICE NAME ) ;

p r i n t k ( KERN INFO ”FPGA d r i v e r i s down . . . \ n ” ) ;}

Page 85: book

Carlos Ivan Camargo Bareno 85

Figura 1.33: Intercambio de informacion entre los espacios de kernel y usuario

Finalmente el programa en espacion de usuario es:

i n t main ( void ) {

i n t f i leNum , b y t e s ;char d a t a [ 4 0 ] ;

f i leNum = open ( ” / dev / fpga ” , O RDWR ) ;i f ( f i leNum < 0) {

p r i n t f ( ” Unable t o open f i l e \n ” ) ;e x i t ( 1 ) ;

}

p r i n t f ( ” Opened d e v i c e \n ” ) ;

b y t e s = r e a d ( f i leNum , da t a , s i z e o f ( d a t a ) ) ;

i f ( b y t e s > 0)p r i n t f ( ” %x\n ” , d a t a ) ;

c l o s e ( f i leNum ) ;

re turn ( 0 ) ;}

En este programa se abre el dispositivo /dev/fpga que corresponde a nuestro driver y se utiliza la funcion read para leer lainformacion suministrada por el driver.

Page 86: book

86 Sistemas Embebidos

Page 87: book

Bibliografıa

[1] I. Bowman, S. Siddiqi, and M. Tanuan. Concrete Architecture of the Linux Kernel.http://docs.huihoo.com/linux/kernel/a2/index.html, 12 February 1998.

[2] I. Bowman. Conceptual Architecture of the Linux Kernel. http://docs.huihoo.com/linux/kernel/a1/, 1998.

[3] Hector Martınez. Apropiacion de conocimiento en Colombia. El caso de los contratos de importacion de tecnologıa. RevistaCuadernos de Economıa, 2004.

[4] Joel Mokyr. The Lever of Riches, Technological Creativity and Economic Progress. Oxford University Press, 1990.

[5] Kenneth Arrow. Economic Welfare and the Allocation of Resources for Invention. Princeton University Press, 1962.

[6] D Teece. The Market for Know-how. Technology Transfer: New Issues, New Analysis. Special issue of the Annals of theAmerican Academy of Political and Social Science, 1981.

[7] Naushad Forbes and David Wield. Managing R&D in technology-followers. Research Policy, September 2000.

[8] European Technology Platform on Smart Sistem Integration (EPoSS). European Technology Platform on Smart Systems Inte-gration. Strategic Research Agenda 2009. 2009.

[9] VDC corp. Embedded Software 2008 Market Intelligence System. Technical report, VDC Research Group, 2008.

[10] M. Tovar and R. Rodrıguez. PROSPECTIVA Y VIGILANCIA TECNOLOGICA DE LA ELECTRONICA EN COLOMBIA.Master’s thesis, Universidad Nacional de Colombia, 2007.

[11] D Zuluaga, S Campos, M Tovar, R Rodrıguez, J Sanchez, A Aguilera, L Landınez, and J Medina. Informe de VigilanciaTecnologica: Aplicaciones de la Electronica en el Sector Agrıcola. Technical report, COLCIENCIAS, 2007.

[12] M. Duque and A. Gauthier. Formacion de Inegnieros para la Innovacion y el Desarrollo Tecnologico en Colombia. Revista dela Facultad de Minas - Universidad Nacional de Colombia, December 1999.

[13] Luis Alejandro Cortes. Verification and Scheduling Techniques for Real-Time Embedded Systems. PhD thesis, Linkopingsuniversitet Institute of Technology, 2005.

[14] Aleph 1. Building the Toolchain. http://www.aleph1.co.uk/node/279.

[15] Michael L. Haungs. The Executable and Linking Format (ELF). http://www.cs.ucdavis.edu/ haungs/paper/node1.html, 21September 1998.

[16] C. Hallinan. Embedded Linux Premiere A Practical Real-World Approach. Prentice Hall, 18 September 2006.

[17] Texas Instruments. IEEE Std 1149.1 (JTAG) Testability. 1997 Semiconductor Group, 1996.

[18] Dominic Rath. Open On-Chip Debugger. PhD thesis, University of Applied Sciences Augsburg, 2005.

[19] Karim Yaghmour, Jon Masters, Gilad Ben-Yossef, and Philippe Gerum. Building Embedded Linux Systems. O’REILLY, 2008.

[20] J Feldman. The Linux startup process. The Linux Expertise Center, Hewlett-Packard Company.

[21] C. Camargo. ECBOT y ECB AT91 Plataformas Abiertas para el Diseno de Sistemas Embebidos y Co-Diseno HW/SW. VIIIJornadas de Computacion Reconfigurable y Aplicaciones, September 2008.

[22] J. Corbet, A. Rubini, and G. Kroah-Hartman. Linux Device Drivers, Third Edition. O’Reilly, 2005.

[23] R Love. Linux System Programming. O’Reilly Media, Inc., 2007.

87