Ecb At91

Indice general
1. PLATAFORMA DE DESARROLLO ECBOT 1.1. Introducci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1. Apropiaci on de Conocimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.2. Contribuciones al desarrollo tecnol ogico en Colombia . . . . . . . . . . . . . . . 1.2. Sistemas Embebidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1. Caracter sticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3. Metodolog a de Dise no . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.4. Herramientas Software de libre distribuci on GNU toolchain . . . . . . . . . . . . 1.2.5. Herramientas hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.6. Interfaz JTAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3. El sistema Operativo Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.1. Arquitectura de Linux [1] [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4. Portando Linux a la plataforma ECBOT y ECB AT91 . . . . . . . . . . . . . . . . . . . . 1.4.1. El Kernel de Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.2. Imagen del kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5. Inicializaci on del kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.1. Darrels Loader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.2. U-boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.3. Portando U-boot a la familia de plataformas ECB AT91 . . . . . . . . . . . . . . 1.5.4. Almacenamiento de la im agen del kernel . . . . . . . . . . . . . . . . . . . . . . 1.5.5. Inicializaci on del Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6. Inicializaci on del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.1. Sistema de Archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.2. Primer Programa en Espacio de Usuario init . . . . . . . . . . . . . . . . . . . . . 1 3 3 3 8 11 11 12 13 15 25 31 35 37 42 42 48 52 53 57 58 63 65 69 69 71
Sistemas Embebidos 1.6.3. Distribuciones Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7. M odulos del kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.1. Ejemplo de un driver tipo caracter . . . . . . . . . . . . . . . . . . . . . . . . . . 1.8. Interfaz con Perif ericos dedicados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.8.1. Comunicaci on Procesador - Perif erico . . . . . . . . . . . . . . . . . . . . . . . . 1.8.2. Comunicaci on Perif erico - Procesador . . . . . . . . . . . . . . . . . . . . . . . . 74 75 75 79 79 83
Cap tulo 1
PLATAFORMA DE DESARROLLO ECBOT

1.1. Introducci on
Uno de los objetivos principales del presente trabajo es la realizaci on de actividades que ayude al pa s en su desarrollo tecnol ogico; en la actualidad Colombia es un consumidor de tecnolog a, es decir, busca en el exterior soluciones a sus problemas, en la mayor a de las ocasiones, estas soluciones no se ajustan a los requerimientos, ya que no tienen en cuenta la situaci on pol tica, cultural y social del pa s. En la mayor a de los casos, no se aumenta el conocimiento tecnol ogicos del pa s, y reduce las opciones de negocios para las 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 permita su desarrollo, protegi endola de alguna forma frente a los productos for aneos. Esto unido a las politicas de estado encaminadas a la apertura comercial, en donde los productos nacionales compiten con productos de paises con mayor desarrollo tecnol ogico nos llevar a a la eliminaci on total de la industrias Colombianas. A continuaci on se presenta un res umen del estudio realizado por Hector Mart nez sobre la Apropiaci on del conocimiento en Colombia [3] durante los a nos 1991 a 2000.
1.1.1.
Apropiaci on de Conocimiento
Para que Colombia deje de ser un pa s que consume tecnolog a y llegue en alg un momento a ser generador de productos tecnol ogicos, es necesario que se genere un conocimiento que permita esta transici on. Para que el conocimiento sea motor de desarrollo es necesario el traspaso desde sus creadores a la sociedad, mediante la conversi on a tecnolog as que produzcan cambios radicales que incrementen la producci on. Esa transmisi on de tecnolog a generadora de crecimiento econ omico esta inuenciada por diversos factores: medio geogr aco, leyes de propiedad industrial, costos laborales, nivel de ciencia y tecnolog a, religi on, tipos de instituciones, resistencia a innovar, pol ticas de estado, guerras, factores demogr acos, entre otros [4] Pero como apropiar este conocimiento? Arrow [5] arma que la apropicaci on de conocimiento puede efectuarse de varias formas: aprender haciendo, aprender usando, aprender leyendo. Cuando una empresa decide transmitir su conocimiento disponible, lo hace en procesos de investigaciones conjuntas, en 3
Sistemas Embebidos
actividades de producci on, y distribuci on, mercadeo, servicio y soporte operativo o riesgo compartido. Tambi en se presentan alianzas entre rmas como: contratos de I+D, acuerdos de licencias, licencias cruzadas. La conformaci on de estas asociaciones permite crear redes tecnol ogicas dominadas por pa ses industrializados con sus respectivas empresas multinacionales monopolizando conocimiento [3] Para Colombia, el problema radica en que mediante contratos de importaci on de tecnolog a, las empresas de capital nacional no est an adquiriendo el conocimiento necesario para lograr innovaciones al interior de las mismas. De forma que puedan ser competitivas y logren acceder a mercados internacionales ofreciendo productos innovadores, de calidad y a precios competitivos. Con efectos directos como: generaci on de empleos especializados, desarrollo tecnol ogico e industrial sostenido, ampliaci on del acervo de conocimiento nacional y disminuci on de la salida de divisas (al mejorar los procesos de negociaci on) y creaci on de externalidades positivas [3]. Ligado al problema de la senda tecnol ogica est a el del grado de lo t acito del conocimiento cient co. Teece [6] se nala que al existir conocimiento t acito toda la tecnolog a disponible no se transere de los productores a los receptores o compradores de la misma. Por tanto, los pa ses seguidores siempre van a estar a la zaga tecnol ogica. Forbes y Wield [7] se nalan que los esfuerzos adaptativos son mayores porque deben acomodar las innovaciones a los materiales locales, fuerza laboral nativa, mercados internos y medio ambiente local. Entonces, el problema no se limita a c omo transferir conocimiento, c omo develar su parte t acita y c omo extraerlo de las multinacionales, sino que radica en el bajo poder de negociaci on y adquisici on de tecnolog a por rmas peque nas y medianas, las cuales carecen de recursos y tienen procesos decientes de contrataci on. En este orden de ideas, si el pa s no es un innovador neto no deber a m as bien mostrar una tendencia a importar conocimiento? Y las rmas nacionales no deber an ser las que m as efectuaran este tipo de contratos, para as acceder al conocimiento de la tecnolog a adquirida? En resumen, conociendo mejor qu e tecnolog a se importa y qu e tipos de contratos se utilizan, es posible crear marcos de referencia para empresas nacionales que est en interesadas en adquirir tecnolog a. Esto producir a externalidades positivas en empresas importadoras de conocimiento y, a su vez, en la econom a del pa s. Con una adecuada importaci on de conocimientos tecnol ogicos se crear a una ventaja competitiva de car acter estructural, basada en un acervo de conocimiento tecnol ogico que permita incrementar la productividad en todos los sectores econ omicos de manera permanente [3]. Seg un los estudios realizados por Mart nez, con base en registros del Decreto 259/92, del Incomex. La importaci on de conocimiento no est a siendo empleada con el prop osito de utilizar tecnolog as de punta que permitan efectuar innovaciones al interior de las empresas y de los sectores. Las empresas nacionales se limitan a comprar un determinado dispositivo, sin tener el conocimiento para operarlo, hacerle mantenimiento ni mucho menos mejorarlo, por lo que se ven obligadas a contratar con el vendedor contratos para dicho f n. Esto indica que la adquisici on de tecnolog a no se realiza con base en programa desarrollado de antemano, sino son una respuesta a cambios en el mercado, lo cual evidencia la inexistencia de programas de innovaci on encaminados a la disminuci on de la brecha tecnol ogica.
Situaci on de la Industria Electr onica en Colombia La industria electr onica nacional no es ajena a las pol ticas que siguen las empresas nacionales en cuanto a la apropiaci on de tecnolog a; Colombia depende totalmente de econom as m as desarrolladas para el suministro de dispositivos electr onicos 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 m as competitivos, el sector electr onico del pa s ha reducido sus actividades de Investigaci on y Desarrollo hasta el punto de depender totalmente de productos externos unos de baja calidad y que no suplen los requerimientos del mercado local, pero que son muy econ omicos.
Carlos Iv an Camargo Bare no
En la actualidad la industria electr onica presenta una gran din amica a nivel mundial, el uso de los sistemas electr onicos se extiende a todas las actividades humanas; La demanda mundial de este tipo de sistemas aumentar a de forma dram atica en los pr oximos a nos, especialmente en los sectores de tecnolog a m edica, movilidad, seguridad, comunicaciones y consumo [8]. El mercado de los sistemas embebidos es una industria que movi o alrededor de 25 billones de d olares en el 2008 seg un Venture Development Corporation [9]. Por otro lado, la inversi on de capital necesaria para el dise no de Sistemas Embebidos es relativamente baja, gracias a la gran demanda originada, los insumos y los servicios de fabricaci on son muy econ omicos, por otro lado, las herramientas de desarrollo necesarias para la programaci on y depuraci on de este tipo de sistemas son de libre distribuci on. Desafortunadamente en Colombia la industria electr onica se encuentra muy rezagada en relaci on a las de los pa ses industrializados, y las ventajas y oportunidades de negocios mencionadas anteriormente no son aprovechadas en la actualidad. Seg un ASESEL cadena electr onica.
1
en el 2001 exist an 154 empresas productoras de componentes y equipos de la
Dentro de los productos que la industria electr onica exporta se encuentran registrados: Circuitos integrados, circuitos impresos, microestructuras, instrumentos para medida y control, Instrumentos y aparatos el ectricos o electr onicos. Es importante decir que la industria colombiana, en la actualidad no fabrica circuitos integrados, ni microestructuras, por lo que estas son ventas de productos comprados en pa ses desarrollados. Seg un Proexport el 91 % de las exportaciones son realizadas por Bogot a y los destinos se encuentran en pa ses cercanos como Venezuela, Per u, Ecuador y USA. La electr onica en Colombia y en el mundo hace parte de esas industrias que se mueven velozmente en un camino desconocido, como consecuencia se hace necesario tener una actualizaci on constante de los avances tecnol ogicos y las proyecciones futuras del sector. Debido a la importancia del sector tecnol ogico es primordial que en Colombia se est e consciente del estado actual y que se puede hacer en t erminos de Investigaci on Cient ca y Desarrollo Tecnol ogico (I+D) en Ingenier a Electr onica. Un estudio realizado en la Universidad Nacional de Colombia [10] identic o los siguientes obst aculos para el desarrollo de la industria electr onica en Colombia: Decientes relaciones Universidad Empresa, Pobre enfoque acad emico hacia la industria, Calidad de los productos nacionales, pol ticas gubernamentales, falta de cultura de Investigaci on y Reducida apropiaci on tecnol ogica, competencia de pa ses asi aticos, atraso tecnol ogico, limitado recurso humano con formaci on avanzada. De los problemas expuestos anteriormente podemos identicar cuales son los que m as afectan el desarrollo de la industria electr onica en Colombia, el que m as perjudica sin lugar a dudas es el atraso tecnol ogico, no es posible ser competitivo en el mercado electr onico mundial con tecnolog as y metodolog as de dise no obsoletas, en Colombia trabajamos a un con circuitos integrados que se crearon en la decada de los 80 del siglo pasado y utilizamos lenguajes de programaci on como el assembler, para el cual el tiempo de aprendizaje, desarrollo y de depuraci on es muy largo. La culpa de este atraso tecnol ogico no es exclusiva de la induatria, aunque, como vimos anteriormente muchas industrial Colombianas se resisten al cambio y preeren comprar equipos en el exterior a buscarlos localmente, la falta de conabilidad en los productos Colombianos agrava este problema, esta falta de conanza en la industria local no es infundada, la mayor a de los productos Colombianos no cumplen con las normas m nimas de calidad y utilizan productos de bajo costo obtenidos en remates de componetes. Otro actor que contribuye al retraso tecnol ogico es el sector acad emico; seg un el Sistema Nacional de ltimos 10 a Informaci on Superior, durante los u nos se han abierto 230 programas relacionados con la industria electr onica, estos programas est an repartidos entre programas de formaci on Universitaria, tecnol ogica terminal y de t ecnica profesional, la mayor a de estos centros de formaci on se encuentran ubicados en 3 De1 Asociaci on
de entidades del Sector Electr onico
Sistemas Embebidos
partamentos: Bogot a, Antioquia y Valle [11]. El n umero de Ingenieros graduados en un a no es entre 2 y 8 veces mayor que en los pa ses en v a de desarrollo y doce veces mayor que los que se grad uan en los pa ses desarrollados, en Colombia, este aumento es aportado por instituciones de poca consolidaci on. Adem as las preferencias en la educaci on superior son Formaci on t ecnica / form. tecnol ogica / form. profesional que es justamente lo opuesto a la de los pa ses desarrollados [12]. Por otro lado, el contenido de las asignaturas relacionadas directamente con la industria electr onica se encuentran muy desactualizados, y fuera del contexto mundial, se utilizan metodolog as de dise no antiguas en las que primaba la experiencia del dise nador, se realizan tareas manuales, repetitivas que pueden ser realizadas por herramientas de dise no moderno, los curr culos son conservadores hay poca experimentaci on y su estructuraci on y metodolog as son muy cl asicas. Otro problema adicional radica en la falta de experiencia en el sector productivo por parte del personal acad emico, un componente importante de los profesores nunca han sido parte de un proceso productivo o de un proceso de desarrollo que tenga como f n nfasis al la creaci on de un producto comercial, raz on por la cual se evita la experimentaci on y se da m as e an alisis y solo se llega a una simulaci on. De lo anterior podemos concluir que en Colombia se presenta una sobre-oferta de profesionales en rea electr el a onica, muchos de los cuales provienen de instituciones educativas con poca consolidaci on, y que han sido formados con programas desactualizados que no tienen en cuenta los avances tecnol ogicos y metodol ogicos, lo cual explica la pobreza de ingenieros con altos niveles de formaci on. Por esta raz on no es de extra nar la poca conanza 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 la inversi on en investigaci on y desarrollo, dena l neas y campos de investigaci on, regulaci on de la oferta laboral, regulaci on de los programas acad emicos, generan el clima perfecto para que el atraso tecnol ogico se mantenga durante mucho tiempo y Colombia no deje de ser un consumidor de tecnolog a. Pasos a seguir para iniciar la soluci on al problema de atraso tecnol ogico Estudios consultados [12] [11] [10] [3], coinciden en que para dar soluci on a los problemas expuestos anteriormente se deben seguir las siguientes recomendaciones: Al gobierno: Fomento gubernamental de centros de investigaci on y productividad para fortalecer la relaciones universidad empresa. Fomentar cooperaci on internacional e inversi on extranjera con transferencia de tecnolog a. a nivel gubernamental, Apoyo del gobierno a personas que tienen un alto potencial de crear y desarrollar tecnolog a. Denir agendas de investigaci on acordes con las tendencias mundiales y desarrollar capacidades en el pa s. A los centros de Ense nanza: Creaci on de portafolio de servicios. Realizar seminarios y l neas de profundizaci on de temas anes a la administraci on y la gerencia en empresas de base tecnol ogica. Montar laboratorios de pruebas e incentivar los productores nacionales para que logren una calidad que cumpla con los est andares internacionales.
Infraestructura institucional que impulse la actualizaci on tecnol ogica en el sector mediante desarrollo de proyectos de tecnolog a de punta con una posible transferencia de tecnolog a. Incentivar la formaci on de maestr as y doctorados nacionales acorde con una agenda de investigaci on. Realizaci on de proyectos de aplicaci on. nicamente a los estudiantes, la Universidad debe El contacto con las empresas no debe ser encargada u desarrollar las competencias que la empresa requiere. Interacci on entre Universidades, Conviene que buena parte de los trabajos realizados en doctorado sean de investigaci on aplicada, orientadas a mejorar la productividad del sector empresarial Innovaci on curricular, actualizaci on continua de profesionales. Las facultades de Ingenier a deben acompa nar las demandas que surgen del sector productivo. Necesidad de mejorar las competencias y habilidades generales de los ingenieros, (continuo aprendizaje) habilidad para innovar, investigar, desarrollar nueva tecnolog a. Estado de la Electr onica Digital en la Universidad Nacional de Colombia rea de electr Hasta hace un a no en las asignaturas del a onica digital de la Universidad Nacional de Colombia (La Universidad m as grande e importante del pais), se trabajaba con dispositivos que fueron sacados al mercado en 1966 y 1968, las familia l ogica TTL 7400 y CMOS 4000. El problema principal al utilizar esta tecnolog a no es su a no de creaci on, ni siquiera que en la actualidad se consideren obsoletas para el dise no de un sistema digital completo. 2 El problema detr as del uso de esta tecnolog a se encuentra en la ausencia total de metodolog as de dise no (en el caso Colombiano). Y el desconocimiento en herramientas tipo CAD. El proceso de dise no que realizaban los estudiantes era: 1. Especicaciones del sistema. 2. Generaci on manual de ecuaciones boolenas. 3. Minimizaci on manual utilizando mapas de Karnaugh. 4. Implementaci on de las ecuaciones minimizadas utilizando las familias l ogicas 7400 y 4000, sobre placas de pruebas (protoboards, breadboards) 5. Pruebas del sistema. A manera de ejercicio acad emico se justica el uso de las familias 7400 y 4000, sin embargo, el quedarse ahi no es bueno para una industria electr onica desactualizada, debido a que este tipo de implementaciones no pueden generar productos competitivos a nivel mundial. La raz on de esto es que existen muchas fuentes de error en el proceso, generados por la ausencia de herramientas CAD que realizan las operaciones tediosas como las minimizaci on de ecuaciones booleanas, las cuales est an sujetas a errores humanos originados por cansancio, falta de concentraci on, etc. Otro aspecto que vale la pena resaltar es la falta de ua simulaci on funcional, la mayor a de los estudiantes consultados no realizaban simulaciones funcionales y prefer an probar el dise no una vez implementado f sicamente, esto unido a la dicultad de depuraci on innata a este tipo de implementaciones, aumentaba considerablemente el tiempo requerido para realizar las pruebas al sistema.
2 En
la actualidad estas compuertas se utilizan para la implementaci on de peque nas operaciones l ogicas
Sistemas Embebidos
A los problemas mencionados anteriormente se suma la gran cantidad de circuitos integrados necesarios para implementar un sistema sencillo, se observaron hasta 8 placas de pruebas con cerca de 50 circuitos integrados interconectados entre s , lo cual aumenta las posibles causas de error y aumenta el tiempo de desarrollo en forma considerable. rea de electr En el segundo curso del a onica digital, se introduce al estudiante al uso de los dispositivos l ogicos programables (PLD) y los lenguajes de descripci on de hardware (HDL) como herramientas para el dise no de sistemas digitales, al comienzo, el contenido de estos cursos se limitaba al uso de una herramienta de dise no y la ense nanza de nociones b asicas del lenguaje VHDL, se daba m as importancia al uso de la herramienta y no a la metodolog a de dise no, de nuevo el estudiante ataca los problemas sin una metodolog a de dise no clara. Vale la pena indicar que este curso fue dictado por profesores ocasionales ltimos cuatro a durante los u nos, cada profesor utilizaba contenidos y niveles de exigencia diferentes. En la tercera parte del curso se trabaja con sistemas microcontrolados, se utilizan microcontroladores de 8 bits de diferentes familias y se utiliza el lenguaje ensamblador como herramienta de desarrollo. Una de las principales desventajas que presenta este curso (y de la l nea en general) es la falta de continuidad en los contenidos y en la metodolog a utilizada, ya que el contenido de este curso se encuentra totalmente desligado al de los dos anteriores. Sin embargo, durante este curso se proporciona una metodolog a de dise no en la que los estudiantes emulan el comportamiento del microcontrolador antes de ser programado, sin embargo, esta pr actica no es seguida por la mayor a de los estudiantes, una posible causa de este comportamiento puede ser la falta de metodolog as de dise no en los cursos anteriores. rea de electr nico que importa son La sensaci on que queda al terminar el a onica digital es que lo u til. La siguiente tabla muestra los los microcontroladores y que lo visto en los primeros cursos no es muy u rea de electr problemas encontrados en el a onica digital de las carreras de Ingenier a El ectrica y Electr onica de la Universidad Nacional de Colombia: 1. Falta de una metodolog a de dise no. 2. Utilizaci on de herramientas obsoletas: Familias L ogicas, lenguajes de programaci on. 3. Poco uso de las herramientas CAD. 4. Falta de continuidad en las asignaturas. 5. Falta de docentes. 6. No se suministra una formaci on adecuada que ayude a la industria electronica a salir del retraso tecnol ogico.
1.1.2.
Contribuciones al desarrollo tecnol ogico en Colombia
Durante la realizaci on de esta investigaci on se llevaron a cabo varias actividades, cuyo objetivo principal es contribuir al desarrollo tecnol ogico en Colombia, como se expuso anteriormente el pa s presenta serias dicultades en este campo y es deber de la comunidad acad emica nacional atacar los problemas locales. Por esta raz on unoa de las matas del presente trabajo fu e la creaci on de una plataforma hardware que permita implementar las diferentes modelos bio-inspirados. En la mayor a de estudios similares no se contempla la creaci on de estas plataformas ya que en los pa ses donde se desarrollan la investigaci on existe una industria electr onica competitiva y que esta al tanto de los desarrollos tecnol ogicos a nivel mundial. Como se mencion o anteriormente este no es el caso de nuestro pais, en la mayor a de las industrias nacionales y en las facultades relacionadas con la electr onica se trabaja con tecnolog as de hace 30 a nos (Familias 74 TTL y 40 CMOS) y se utilizan herramientas de programaci on de bajo nivel como el lenguaje ensamblador.
A continuaci on se mestran una lista del trabajo realizado sobre algunas de las recomendaciones dadas por los estudios acerca del desarrollo tecnol ogico en Colombia; vale la pena anotar que no todas est an dentro del alcance de este trabajo, se eligieron en las que se pod a hacer un aporte signicativo. 1. Realizaci on de proyectos de aplicaci on: La primera decisi on que se tom o en cuanto a la naturaleza de esta investigaci on fu e la de generar una aplicaci on f sica real que validara los modelos propuestos, este trabajo no se limitar a a realizar simulaciones, sino que se construir a una plataforma que sea tecnol ogicamente moderna y que este al nivel de las plataformas utilizadas en estudios similares. la primer Computadora en una sola placa (SBC 3 ) que utiliza un procesador de Para esto se dise no 32 Bits y utiliza Linux como sistema operativo 2 2. Infraestructura institucional que impulse la actualizaci on tecnol ogica en el sector mediante desarrollo de proyectos de tecnolog a de punta con una posible transferencia de tecnolog a: nicamente a los estudiantes, la Universidad debe 3. El contacto con las empresas no debe ser encargada u desarrollar las competencias que la empresa requiere. 4. Interacci on entre Universidades, Conviene que buena parte de los trabajos realizados en doctorado sean de investigaci on aplicada, orientadas a mejorar la productividad del sector empresarial 5. Innovaci on curricular, actualizaci on continua de profesionales. 6. Necesidad de mejorar las competencias y habilidades generales de los ingenieros, (continuo aprendizaje) habilidad para innovar, investigar, desarrollar nueva tecnolog a. Contribuciones a Nivel Tecnol ogico y Acad emico En este cap tulo se realiza la presentaci on de la plataforma Hardware y Software utilizada en el desarrollo de esta investigaci on. Uno de los objetivos de este trabajo, es la creaci on de una plataforma Embebida que permita la apropiaci on de nuevas herramientas y metodolog as de dise no. El mercado de los sistemas embebidos contin ua en aumento y su campo de acci on se ha extendido en casi todas las actividades humanas. Seg un BBC, inc. 4 el mercado para el software embebido puede crecer de $1.6 billones a $3.5 billones en 2009, con una tasa de crecimiemto anual (AAGR) del 16 %, mientras la tasa de crecimiento para las tarjetas embebidas es del 10 %. (Favor ver Figura 1.1). Esto unido a: el gran nivel de integraci on obtenido por la industria de los semiconductores en los SOC, la disponibilidad de herramientas software de desarrollo gratuitas (compiladores, simuladores, librer as, Sistemas Operativos) abre grandes posibilidades comerciales para paises en v a de desarrollo ya que no son necesarias grandes inversiones de capital para la implementaci on de estos sistemas. M as de un bill on de dispositivos embebidos fueron vendidos en el 2004, seg un Venture Development Corporation (VDC). De acuerdo con VDC el porcentaje de dispositivos basados en Sistemas Operativos comerciales tiende a disminuir callendo del 43.1 % en 2001 a 37.1 % en 2004, esta tendencia se debe al aumento de complejidad de los dispositivos y a las necesidades de conexi on (tales como Ethernet, bluetooth, WiFi, etc); adem as, la caida de precios del hardware, elimina la necesidad de eciencia en el manejo de recursos proporcionada por muchos productos comerciales. Otro factor es el deseo de utilizar el mismo Sistema Operativo para varios proyectos. Recientes investigaciones de VDC sugieren que entre el 13 y el 15 % de los desarrolladores utilizan linux como su sistema operativo principal, y se espera que esta cifra aumente al madurar la tecnolog a y
3 Single
Board Computer
4 http://www.bccresearch.com/
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 gura 1.2 muestra una encuenta realizada a 932 desarrolladores de todo el mundo por linuxdevices 5
Figura 1.2: Preferencia de Sistema Operativo para Sistemas Embebidos 2003-2007. Fuente: linuxdevices. La elecci on de Linux como herramienta de desarrollo esta fuertemente inuenciada por su caracter libre, la gran disponibilidad de herramientas de desarrollo, aplicaciones, librer as y la posibilidad de modicar o adaptar c odigo ya existente. El coraz on de todo sistema embebido es su procesador, en la actualidad existen diversos fabricantes que ponen a disposici on de los desarrolladores System On Chip (SOC) que incluyen una gran variedad de perif ericos que incluyen dispositivos de comunicaci on (UARTs, USB, Ethernet), interface con el humano (Controladores de: LCD, tarjetas de sonido, dispositivos touch screen), almacenamiento (memorias: RAM,
5 http://www.linuxdevices.com
11
SDRAM, SD, MMC). Al incluir la mayor a de los perif ericos en el mismo Chip se reduce el espacio de la placa de circuito impreso (PCB) y se reduce la posibilidad de errores debido a interconexi on y contrario a lo que se podr a esperar, el costo de este SOC es muy bajo (en comparaci on con el costo de cada perif erico por separado). La gura 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 los ltimos los m procesadores ARM, siendo estos u as populares en dispositivos de consumo como PDAs, Routers, tel efonos celulares, consolas de juego p1.3ort atiles.
1.2.
Sistemas Embebidos
Un Sistema Embebidos es un sistema de prop osito espec co en el cual, el computador es encapsulado completamente por el dispositivo que el controla. A diferencia de los computadores de prop osito general, un Sistema Embebido realiza tareas pre-denidas, lo cual permite su optimizaci on, reduciendo el tama no y costo del producto [?]
1.2.1.
Caracter sticas
Los sistemas embebidos son dise nados para una aplicaci on espec ca, es decir, estos sistemas realizan un grupo de funciones previamente denidasm y una vez el sistema es dise nado, no se puede cambiar su funcionalidad. Por ejemplo, el control de un asensor siempre realizar a las mismas acciones durante til. su vida u Debido a su interacci on con el entorno los ES deben cumplir esctr ctamente restricciones temporales. El t ermino Sistemas de Tiempo Real es utilizado para enfatizar este aspecto. Los Sistemas Embebidos son heterog eneos, es decir, est an compuestos por componentes Hardware y Software. Los componentes Hardware, como ASICs y Dispositivos L ogicos Programables (PLD) proporcionan la velocidad de ejecuci on y el cosumo de potencia necesarios en algunas aplicaciones.
12
Sistemas Embebidos
Figura 1.4: Arquitectura de un Sistema Embebido Los Sitemas Embebidos tienen grandes requerimientos en t erminos de conabilidad. Errores en aplicaciones como la aviaci on 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 componente hardware, implementado ya sea en un PLD (CPLD, FPGA) o en un ASIC, conocido con el nombre de perif ericos y un componente software (procesador o DSP) cap az de ejecutar software, la parte del procesador est a dividida en la CPU (En algunos casos posee una cach e) y las unidades de Memoria. Al momento de dise nar un Sistema Embebido encontramos las siguientes opciones: Componente HW y SW Integrado en un dispositivo semiconductor (SoC): En la actualidad existen muchas compa n as que fabrican procesadores de 32 bits integrados a una gran variedad de perif ericos, lo cual simplica el dise no y reduce costos. 6 . Este tipo de implementaci on es muy popular en los dispositivos de consumo masivo (Reproductores de MP3, consolas de juego, etc), debido a los grandes niveles de producci on (del orden de millones de unidades) resulta m as econ omico contar con un dispositivo que integre el mayor n umero de funcionalidades, esto disminuye el costo de componentes rea de circuito impreso. y reduce el a Componente SW en un SoC y componente HW en una FPGA: Cuando no existen en el mercado un SoC con la cantidad de perif ericos requerida para una determinada aplicaci on, o con una funcionalidad espec ca, es necesario recurrir a la utilizaci on de dispositivos comerciales que implementen
6 http://www.sharpsma.com,
http://www.atmel.com, http://www.cirrus.com, http://www.samsung.com, http://www.freescale.com,
etc
13
dicha operaci on, en algunas ocaciones el perif erico puede relizar funciones poco com unes y no se proporciona comercialmente, la soluci on es entonces, implementar estas funcionalidades en una FPGA; tambi en se recomienda la utilizaci on de FPGAs en sistemas que requieren la utilizaci on de la misma funcionalidad un gran n umero de veces (Puertos seriales, Pines de Entrada/Salida). Esta decisi on esta atada al nivel de producci on, ya que al incluir una FPGA aumenta el costo global del proyecto. Componente SW y HW en una FPGA: Esta es tal vez la opci on m as exible, pero la de menor desempe no, ya que al utilizar los recursos l ogicos de la FPGA para la implementaci on del procesador (softcore) la longitud de los caminos de interconexi on entre los bloques l ogicos aumentan el retardo de las se nales, lo cual disminuye la m axima velocidad de funcionamiento. Los procesadores softcore m as 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 dise no de un Sistema Embebido comienza con la especicaci on del sistema, (ver Figura 1.5), en este punto se describe la funcionalidad y se denen las restricciones f sicas, el ectricas y econ omicas. Esta especicaci on debe ser muy general y no deben existir dependencias (tecnol ogicas, metodol ogicas) de ning un tipo, se suele utilizar lenguajes de alto nivel, como UML, C++. La especicaci on puede ser vericada a trav es de una serie de pasos de an alisis cuyo objetivo es determinar la validez de los algor tmos seleccionados, por ejemplo, determinar si el algoritmo siempre termina, los resultados satisfacen las especicaciones. Desde el punto de vista de la re-utilizaci on, algunas partes del funcionamiento global deben tomarse de una librer a de algor tmos existentes. Una vez denidas las especicaciones del sistema se debe realizar un modelamiento que permita l depende el paso exisextraer de estas la funcionalidad. El modelamiento es crucial en el dise no ya que de e toso de la especicaci on a la implementaci on. Es importante denir que modelo matem atico debe soportar el entorno de dise no. Los modelos m as utilizados son: M aquinas de estados nitos, diagramas de ujos de datos, Sistemad de Eventos Discretos y Redes de Petri. Cada modelo posee propiedades matem aticas que pueden explotarse de forma eciente para responder preguntas sobre la funcionalidad del sistema sin llevar a cabo dispendiosas tareas de vericaci on. Todo modelo obtenido debe ser vericado para comprobar que cumple con las restricciones del sistema. Una vez se ha obtenido el modelo del sistema se procede a determinar su arquitectura, esto es, el n umero y tipo de componentes y su inter-conexi on. Este paso no es m as que una exploraci on del espacio de dise no en b usqueda de soluciones que permitan la implementaci on de una funcionalidad dada, y puede realizarse con varios criterios en mente: Costos, conabilidad, viabilidad comercial. Utilizando como base la arquitectura obtenida en el paso anterior las tareas del modelo del sistemas son mapeadas dentro de los componentes. Esto es, asignaci on de funciones a los componentes de la arquitectura. Existen dos opciones a la hora de implementar las tareas o procesos:
7 http://www.xilinx.com 8 http://www.gaisler.com/ 9 http://www.latticesemi.com 10 http://www.opencores.com
14
Sistemas Embebidos
Figura 1.5: Flujo de Dise no de un Sistema Embebido [13]
Carlos Iv an Camargo Bare no 1. Implementaci on Software: La tarea se va a ejecutar en un procesador. 2. Implementaci on Hardware: La tarea se va a ejecutar en un sistema digital dedicado.
15
Para cumplir las especicaciones 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 generaci on de bases de tiempos. La decisi on de que tareas se implementan en SW y que tareas se implementan en HW recibe el nombre de particionamiento, esta selecci on es fuertemente dependiente de restricciones econ omicas 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 ejecuci on y la prioridad de estas. Este proceso recibe el nombre de planicaci on. En este punto del dise no el modelo debe incluir informaci on sobre el mapeo, el particionamiento y la planicaci on del sistema. Las siguientes fases corresponden a la implementaci on del modelo, para esto las tareas hardware deben ser llevadas al dispositivo elegido (ASIC o FPGA) y se debe obtener el ejecutable de las tareas software, este proceso recibe el nombre de s ntesis HW y SW respectivamente, as mismo se deben sintetizar los mecanismos de comunicaci on. El proceso de prototipado consiste en la realizaci on f sica del sistema, nalmente el sistema f sico debe someterse a pruebas para vericar que se cumplen con las especicaciones iniciales. Como puede verse en el ujo de dise no existen realimentaciones, estas realimentaciones permiten depurar el resultado de pasos anteriores en el caso de no cumplirse con las especicaciones iniciales.
1.2.4.
Herramientas Software de libre distribuci on GNU toolchain
En el mercado existe una gran variedad de herramientas de desarrollo para Sistemas Embebidos, sin embargo, en este estudio nos centraremos en el uso de las herramientas de libre distribuci on; esta elecci on se debe a que la mayor a de los productos comerciales utilizan el toolchain de GNU11 internamente y proporcionan un entorno gr aco para su f acil manejo. Otro factor considerado a la hora de realizar nuestra elecci on es el econ omico, ya que la mayor a de los productos comerciales son costosos y poseen soporte limitado. Por otro lado, el toolchain de GNU es utilizado ampliamente en el medio de los dise nadores de sistemas embebidos y se encuentra un gran soporte en m ultiples foros de discusi on (ver Figura 1.6).
GNU binutils[14] Son una colecci on de utilidades para archivos binarios y estan compuestas por: addr2line Convierte direcciones de un programa en nombres de archivos y n umeros de l nea. Dada una direcci on y un ejecutable, usa la informaci on de depuraci on en el ejecutabe para determinar que nombre de atchivo y n umero de lpinea est a asociado con la direcci on dada. ar Esta utilidad crea, modica y extrae desde cheros. Un chero es una colecci on de otros archivos en una estructura que hace posible obtener los archivos individuales miembros del archivo. as Utilidad que compila la salida del compilador de C (GCC).
11 http://www.gnu.org
16
Sistemas Embebidos
Figura 1.6: Tendencia de utilizaci on de herramientas de desarrollo c++lt Este program realiza un mapeo inverso: Decodica nombres de bajo-nivel en nombres a nivel de 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 n umero de objetos y cheros, re-localiza sus datos y los relaciona con ltimo paso en la construcci referencias. Normalmente el u on de un nuevo programa compilado es el llamado 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 BFD para leer y escribir el archivo tipo objeto. Permite esccribibr el archivo destino en un formato diferente al del archivo fuente. objdump Despliega informaci on sobre archivos tipo objeto. l. ranlib Genera un ndice de contenidos de un chero, y lo almacena en e readelf Interpreta encabezados de un archivo ELF. size Lista el tama no de las secciones y el tama no 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 lenguajes de programaci on producido por el proyecto GNU. Es el compilador standard para el software libre de los sistemas operativos basados en Unix y algunos propietarios como Mac OS de Apple. Soporta los siguientes lenguajes: ADA, C, C++, Fortran, Java, Objective-C, Objective-C++ para las arquitecturas: Alpha, ARM, Atmel AVR, Blackn, H8/300, System/370, System/390, IA-32 (x86) and x86-64, IA-64 i.e. the Itanium,
17
Motorola 68000, Motorola 88000, MIPS, PA-RISC, PDP-11, PowerPC, SuperH, SPARC, VAX, Renesas R8C/M16C/M32C, MorphoSys. Como puede verse GCC soporta una gran cantidad de lenguajes de programaci on, sin embargo, en el presente estudio solo lo utilizaremos como herramienta de compilaci on para C y C++. Una caracter stica de resaltar de GCC es la gran cantidad de plataformas que soporta, esto lo hace una herramienta Universal para el desarrollo de sistemas embebidos, el c odigo escrito en una plataforma (en un lenguaje de alto nivel) puede ser implementado en otra sin mayores cambios, esto elimina la dependencia entre el c odigo fuente y el HW12 , lo cual no ocurre al utilizar lenguaje ensamblador. Por otro lado, el tiempo requerido para realizar aplicaciones utilizando C o C++ disminuye, ya que no es necesario aprender las instrucciones en assembler de una plataforma determinada; adem as, la disponibilidad de librer as de m ultiples prop ositos reduce a un m as los tiempos de desarrollo, permitiendo de esta forma tener bajos tiempos time to market y reducir de forma considerable el costo del desarrollo.
GNU Debugger El depurador ocial de GNU (GDB), es un depurador que al igual que GCC tiene soporte para m ultiples lenguajes y plataformas. GDB permite al usuario monitorear y modicar las variables internas del programa y hacer llamado a funciones de forma independiente a la ejecuci on normal del mismo. Adem as, permite establecer sesiones remotas utilizando el puerto serie o TCP/IP. Aunque GDB no posee una interfaz gr aca, 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 m as utilizadas en sistemas embebidos son: glibc13 Es la librer a C ocial del proyecto GNU. Uno de los inconvenientes al trabajar con esta librer a en sistemas embebidos es que genera ejecutables de mayor tama no que los generados a partir de otras librer as, lo cual no la hace muy atractiva para este tipo de aplicaciones. uClibc14 Es una librer a dise nada especialmente para sistemas embebidos, es mucho m as peque na que glibc. newlib15 Al igual que uClibc, est a dise nada para sistemas embebidos. El t pico Hello, world! ocupa menos de 30k en un entorno basado en newlib, mientras que en uno basado en glibc, puede ocupar 380k [?]. diet libc16 Es una versi on de libc optimizada en tama no, puede ser utilizada para crear ejecutables est aticamente enlazados para linux en plataformas alpha, arm, hppa, ia64, i386, mips, s390, sparc, sparc64, ppc y x86 64.
12 Esto
recibe el nombre de re-utilizaci on de c odigo
13 http://www.gnu.org/software/libc/ 14 http://uclibc.org/ 15 http://sources.redhat.com/newlib/ 16 http://www.fefe.de/dietlibc/
18 software Flujo de diseno
Sistemas Embebidos
En la gura 1.7 se ilustra la secuencia de pasos que se realizan desde la creaci on de un archivo de texto que posee el c odigo fuente de una aplicaci on hasta su implementaci on en la tarjeta de desarrollo.
Figura 1.7: Flujo de dise no SW utilizando la cadena de herramientas GNU A continuaci on se realiza una breve descripci on de los pasos necesarios para generar un ejecutable para un sistema embebido: 1. Escritura del c odigo fuente: Creaci on del c odigo fuente en cualquier editor de archivos de texto. 2. Compilaci on: Utilizando el compilador gcc se compila el c odigo fuente; vala la pena mencionar que en este punto el compilador solo busca en los encabezados (headers) de las librer as la denici on de una determinada funci on, como por ejemplo el printf en el archivo stdio.h. Como resultado de este paso 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 funci on no es ednida por ninguna de las librer as pasadas como par ametro al linker, este generar a un error y no se generar a el ejecutable. b) Se dene la posici ones f sicas de las secciones del ejecutable tipo ELF, esto se realiza a trav es de un link de enlazado el cual dene de forma expl cita su localizaci on. nicamente 4. Extracci on del archivo de programaci on En algunas aplicaciones es necesario extraer u las secciones que residen en los medios de almacenamiento no vol atil y eliminar las dem as secciones
19
del ejecutable. Esto se realiza con la herramiento objcopy, la cual, permite generar archivos en la mayor a de los formatos soportados por los programadores de memorias y procesadores, como por ejemplo S19 e Intel Hex. 5. Descarga del programa a la plataforma. Dependiendo de la plataforma existen varios m etodos para descargar el archivo de programaci on a la memoria de la plataforma de desarrollo: a) Utilizando un loader: El loader es una aplicaci on que reside en un medio de almacenamiento no vol atil 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 interfaz capaz de controlar los registros internos del procesador, y de esta forma, acceder a las memorias de la plataforma y ejecutar un programa residente en una determinada posici on de memoria. 6. Depuraci on Una vez se descarga la aplicaci on a la plataforma es necesario someterla a una serie de pruebas con el f n de probar su correcto funcionamiento. Esto se puede realizar con el depurador GNU (GDB) y una interfaz de comunicaci on 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 aplicaci on a una plataforma embebida. Debido a que las herramientas GNU solo poseen entrada por consola de comandos, es necesario escribir una serie de comandos cada vez que se realiza un cambio en el c odigo fuente, lo cual resulta poco pr actico durante la etapa de desarrollo. Para realizar este proceso de forma autom atica, se cre o la herramienta make, la cual recibe como entrada un archivo que normalmente recibe el nombre de Makele o makele. La herramienta make ejecuta los comandos necesarios para realizar la compilaci on, depuraci on, o programaci on, indicados en el archivo Makele o makele. Un ejemplo de este tipo de archivo se muestra a continuaci on:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 SHELL = / b i n / s h 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 gnu b i n d i r = ${ b a s e t o o l s d i r } / b i n l i b d i r = $ { b a s e t o o l s d i r } / l i b / g c c / arm s o f t f l o a t l i n u x gnu / 3 . 4 . 5 CC AS LD OBJCOPY = = = = arm s o f t f l o a t l i n u x gnug c c arm s o f t f l o a t l i n u x gnua s arm s o f t f l o a t l i n u x gnul d arm s o f t f l o a t l i n u x gnuo b j c o p y
CFLAGS =mcpu= a r m 9 2 0 t I . Wall LDFLAGS =L$ { l i b d i r } l g c c OBJS = \ main . o debug io . o at91rm9200 lowlevel . o p string .o ASFILES = a r m i n i t . o LIBS=$ { l i b d i r } / all : hello world h e l l o w o r l d : $ { OBJS } $ { ASFILES } $ { LIBS } $ {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}
\ \ \
20
29 30 31 32 33 34 35 36 37 $ {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 n clean : rm f . o h e l l o w o r l d . PREPROCESS . c = $ (CC) $ ( CPPFLAGS ) $ (TARGET ARCH) E Wp, C, dD, d I %.pp : %.c FORCE $ ( PREPROCESS . c ) $< > $@
Sistemas Embebidos
En las l neas 3-5 se denen algunas variables globales que ser an utilizadas a lo largo del archivo; en las l neas 7 - 10 se denen las herramientas de compilaci on a utilizar, espec camente los compiladores de C (CC), de assembler (AS), el linker (LD) y la utilidad objcopy. A partir de la l nea 15 se denen los objetos que forman parte del proyecto, en este caso: main.o, debug io.o, at91rm9200 lowlevel.o y p string.o; en la l nea 21 se denen los archivos en assembler que contiene el proyecto, para este caso arm init.o. Las l neas 12 y 13 denen dos variables especiales que se pasan directamente al compilador de C (CFLAGS) y al liniker (LDFLAGS) En las l neas 25, 27 y 31 aparecen unas etiquetas de la forma: nombre: esta es la forma de denir reglas y permiten ejecutar de forma independiente el conjunto de instrucciones asociadas a ellas, por ejemplo, si se ejecuta el comando: make clean make ejecutar a: 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 antes de 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 predenidas 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 necesario ejecutar $(CC) $(CFLAGS) -c $; de aqui la importancia de denir bien la variable de entorno CC cuando trabajamos con compiladores cruzados17 . Hasta este punto al ejecutar el comando: make hello world, make realizar a las siguientes operaciones:
arm s o f t f l o a t l i n u x gnug c c mcpu= a r m 9 2 0 t I . Wall c o main . o main . c arm s o f t f l o a t l i n u x gnug c c mcpu= a r m 9 2 0 t I . Wall c o d e b u g i o . o d e b u g i o arm s o f t f l o a t l i n u x gnug c c mcpu= a r m 9 2 0 t I . Wall c o a t 9 1 r m 9 2 0 0 l o w l e v e l at91rm9200 lowlevel arm s o f t f l o a t l i n u x gnug c c mcpu= a r m 9 2 0 t I . Wall c o p s t r i n g . o p s t r i n g arm s o f t f l o a t l i n u x gnua s o a r m i n i t . o a r m i n i t . s
.c .o .c .c
En las l neas 28 se realiza el proceso de enlazado; al linker se le pasan los par ametros:
17 Un compilador cruzado genera c odigo para una plataforma diferente en la que se est a ejecutando, por ejemplo, genera ejecutables para ARM pero se ejecuta en un x86
Carlos Iv an Camargo Bare no -e 0: Punto de entrada , utilice 0 como s mbolo para el inicio de ejecuci on. -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.
21
En la l nea 29 se utiliza la herramienta objcopy para generar un archivo binario (-O binary) con la informaci on necesaria para cargar en una memoria no vol atil. Esto se explicar a con mayor detalle m as adelante. El formato ELF El formato ELF (Executable and Linkable Format) Es un st andard para objetos, librer as y ejecutables y es el formato que genera las herramientas GNU. Como puede verse en la gura 1.8 est a compuesto por varias secciones (link view) o segmentos (execution view). Si un programador est a interesado en obtener informaci on de secciones sobre tablas de s mbolos, c odigo ejecutable espec co o informaci on de enlazado din amico debe utilizar link view. Pero si busca informaci on sobre segmentos, como por ejemplo, la localizaci on de los segmentos text o data debe utilizar execution view. El encabezado describe el layout del archivo, proporcionando informaci on de la forma de acceder a las secciones [15].
Figura 1.8: Formato ELF Las secciones pueden almacenar c odigo ejecutable, datos, informaci on de enlazado din amico, datos de depuraci on, tablas de s mbolos,comentarios, tablas de strings, y notas. Las secciones m as importantes son las siguientes: .bss Datos no inicializados. (RAM) .comment Informaci on de la versi on. .data y .data1 Datos inicializados. (RAM) .debug Informaci on para depuraci on simb olica. .dynamic Informaci on sobre enlace din amico .dynstr Strings necesarios para el enlacedin amico
22 .dynsym Tabla de s mbolos utilizada para enlace din amico. .ni C odigo de terminaci on de proceso. .init C odigo de inicializaci on de proceso. .line Informaci on de n umero de l nea para depuraci on simb olica. .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 aplicaci on sencilla:
# i n c l u d e < s t d i o . h> int global ; int global 1 = 1; i n t main ( v o i d ) { int i ; int j = 2; f o r ( i = 0 ; i < 10; i ++) { printf ( Printing % d\n , i j ) ; j = j + 1; global = i; global 1 = i+j ; } return 0; }
Sistemas Embebidos
/ / V a r i a b l e no i n i c i a l i z a d a / / Variable i n i c i a l i z a d a / / Caracteres constantes
Generemos el objeto compil andolo 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 Size ES F l g 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] . data PROGBITS 00000000 0000 d0 000004 00 WA 0 0 4 [ 4] . bss NOBITS 00000000 0000 d4 000000 00 WA 0 0 1 [ 5] . rodata 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 f 0 10 10 11 4 [10] . 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 ( g r o u p ) , 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 secci on .text, como se dijo anteriormente contiene las instrucciones ejecutables, por esta raz on se marca como ejecutable X en la columna Flg. Es posible ver las instrucciones que se ejecutan en esta secci on:
Carlos Iv an Camargo Bare no arm-none-eabi-objdump -d -j .text hello.o

00000000 <main > : 0: e92d4800 4: e28db004 8: e24dd008 c: e3a03002 10: e50b3008 14: e3a03000 18: e50b300c 1c : ea000013 20: e51b200c 24: e51b3008 28: e0030392 2c : e59f005c 30: e1a01003 34: ebfffffe 38: e51b3008 3c : e2833001 40: e50b3008 44: e59f2048 48: e51b300c 4c : e5823000 50: e51b200c 54: e51b3008 58: e0822003 5c : e59f3034 60: e5832000 64: e51b300c 68: e2833001 6c : e50b300c 70: e51b300c 74: e3530009 78: daffffe8 7c : e3a03000 80: e1a00003 84: e24bd004 88: e8bd4800 8c : e12fff1e stmdb add sub mov str mov str b ldr ldr mul ldr mov bl ldr add str ldr ldr str ldr ldr add ldr str ldr add str ldr cmp ble mov mov sub ldmia bx s p ! , { fp , l r } fp , sp , #4 sp , sp , #8 r3 , #2 ; 0 x2 r3 , [ fp , # 8] r3 , #0 ; 0 x0 r3 , [ fp , # 12] 70 <main +0 x70> r2 , [ fp , # 12] r3 , [ fp , # 8] r3 , r2 , r 3 r0 , [ pc , # 9 2 ] r1 , r 3 0 <p r i n t f > r3 , [ fp , # 8] r3 , r3 , #1 r3 , [ fp , # 8] r2 , [ pc , # 7 2 ] r3 , [ fp , # 12] r3 , [ r 2 ] r2 , [ fp , # 12] r3 , [ fp , # 8] r2 , r2 , r 3 r3 , [ pc , # 5 2 ] r2 , [ r 3 ] r3 , [ fp , # 12] r3 , r3 , #1 r3 , [ fp , # 12] r3 , [ fp , # 12] r3 , #9 ; 0 x9 20 <main +0 x20> r3 , #0 ; 0 x0 r0 , r 3 sp , fp , #4 s p ! , { fp , l r } lr
23
; 0 x4 ; 0 x8
; 90 < . t e x t +0 x90>
; 0 x1 ; 94 < . t e x t +0 x94>
; 98 < . t e x t +0 x98>
; 0 x1
; 0 x4
La secci on .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
nicamente el valor de inicializaci Como vemos, la secci on .data contiene u on de la variable global 1 n acerca de la variable j, esto se debe a que la informaci (1) y no muestra informaci oo on est a en el stack del proceso. Si observamos el contenido de la secci on .text observamos que esta variable es asignada en tiempo de ejecuci on, en la l nea 0c:
0c : 10: e3a03002 e50b3008 mov str r3 , #2 ; 0 x2 r3 , [ fp , # 8]
se ve la asignaci on de esta variable. La secci on .bss mantiene la informaci on de las variables no incializadas: arm-none-eabi-objdump -d -j .bss hello
24
000145 c4 < g l o b a l > : 145 c4 : 00000000
Sistemas Embebidos
En Linux todas las variables no inicializadas, se inicializadan en cero. La secci on .rodata mantiene los datos que no cambian durante la ejecuci on del programa, es decir, de solo lectura, si examinamos esta secci on obtenemos: hexdump -C hello.o grep -i 000000d0 (la secci on .rodata comienza en la posici on de memoria 0xd4)
000000 d0 000000 e0 01 00 00 00 50 72 69 6 e 00 00 00 00 00 47 43 43 74 69 6 e 67 20 25 64 0 a 3 a 20 28 43 6 f 64 65 53 | . . . . Printing % d.| | . . . . . GCC: ( CodeS |
Observamos que en el archivo se almacena la cadena de caracteres Printing %d n la cual no se modica durante la ejecuci on del programa. Linker Script Como vimos anteriormente, el linker es el encargado de agrupar todos los archivos objeto .o, y las librer as necesarias para crear el ejecutable, este linker permite denir donde ser an ubicados los diferentes segmentos del archivo ELF, por medio de un archivo de enlace linker script. De esta forma podemos ajustar el ejecutable a plataformas con diferentes conguraciones de memoria.Esto brinda un grado mayor de exibilidaad de la cadena de herramientas GNU. Cuando se dispone de un sistema operativo como Linux no es necesario denir este archivo, ya que el sistema operativo se encarga de guardar las secciones en el lugar indicado, sin embargo, es necesario tenerlo presente ya que como veremos m as adelante existe un momento en el que el sistema operativo no ha sido cargado en la plataforma y las aplicaciones que se ejecuten deben proporcionar esta informaci on. A continuaci on se muestra un ejemplo de este archivo:
/ i d e n t i f y the Entry Point ENTRY( v e c r e s e t ) ( vec res et is defined in f i l e crt . s ) /
/ 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 ram : ORIGIN = 0 x00200000 , LENGTH = 64K } / d e f i n e a g l o b a l symbol s t a c k e n d = 0x20FFFC ; stack end /
/ FLASH EPROM / s t a t i c RAM a r e a
/ /
/ 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 locati on counter to address zero / . text : / 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 / { (. text ) / a l l . t e x t s e c t i o n s ( code ) / (. rodata ) / a l l . rodata s e c t i o n s ( constants , strings , etc . ) / ( . r o d a t a ) / a l l . rodata s e c t i o n s ( constants , strings , etc . ) / (. glue 7 ) / a l l . glue 7 s e c t i o n s ( no i d e a what t h e s e a r e ) / (. glue 7t ) / 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 a r e ) / etext = .; / 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 a b o v e i n t o FLASH / . data : / c o l l e c t a l l i n i t i a l i z e d . d a t a s e c t i o n s t h a t go i n t o RAM /

{ data = . ; (. data ) edata = . ; } >ram AT > f l a s h / . bss : { bss start = .; ( . bss ) } >ram . = ALIGN ( 4 ) ; bss end = . ; } end = . ; / d e f i n e a g l o b a l s y m b o l m a r k i n g t h e end o f a p p l i c a t i o n RAM / / 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 / / / / / / / / / /
25
c r e a t e a g l o b a l symbol marking t h e s t a r t of t h e . data s e c t i o n / a l l . data s e c t i o n s / d e f i n e a g l o b a l s y m b o l m a r k i n g t h e end o f t h e . d a t a s e c t i o n / p u t a l l t h e a b o v e i n t o RAM ( b u t l o a d t h e LMA i n i t i a l i z e r c o p y i n t o FLASH )
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 . bss s e c t i o n / a l l . bss s e c t i o n s / p u t a l l t h e a b o v e 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 c o d e / a d v a n c e 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 b o u n d a r y / d e f i n e a g l o b a l s y m b o l m a r k i n g t h e end o f t h e . b s s s e c t i o n /
En las primeras l neas del archivo aparece la declaraci on de las memorias de la plataforma, en este ejemplo tenemos una memoria RAM de 64kB que comienza en la posici on de memoria 0x00200000 y una memoria ash de 256k que comienza en la posici on 0x0. A continuacion se denen las secciones y el lugar donde ser an almacenadas; En este caso, las secciones .text (c odigo ejecutable) y .rodata (datos de solo lectura) se almacenan en una memoria no vol atil la ash. Cuando el sistema sea energizado el procesador ejecutar a el c odigo almacenado en su memoria no vol atil. Las secciones .data (variables inicializadas) y .bss (variables no inicializadas) se almacenar an en la memoria vol atil RAM, ya que el acceso a las memorias no vol atiles son m as lentas y tienen ciclos de lectura/escritura nitos. En algunos procesadores (como el AT91RM9200) no se dispone de una memoria no vol atil, por lo que es necesario que la aplicaci on sea cargada por completo en la RAM. Algunos desarrolladores preeren almacenar y ejecutar sus aplicaciones en las memorias vol atiles durante la etapa de desarrollo, debido a que la programaci on de las memorias no vol atiles toman mucho m as tiempo. Obviamente una vez nalizada la etapa de desarrollo las aplicaciones deben ser almacenadas en memorias no vol atiles.
1.2.5.
Herramientas hardware
Como se mencion o anteriormente existen varias alternativas al momento de implementar un Sistema Embebido (ver Figura 1.4). En este trabajo se utiliza una arquitectura compuesta por el SoC de Atmel el AT91RM9200 y una FPGA, teniendo en cuenta que esta pataforma tiene nes acad emicos es muy importante tener la posibilidad de crear tareas HW en un Dispositivo L ogico Programable (PLD). SoC La Figura 1.9 muestra la arquitectura de un SoC actual, espec camente del AT91RM920 de Atmel. En este diagrama podemos observar el n ucleo central un procesador ARM920T de 180MHz y los l. En la actualidad podemos encontrar una gran variedad de SoC dise perif ericos asociados a e nados para diferentes aplicaciones: Multimedia, Comunicaciones, Asistentes Digitales; los perif ericos incluidos en cada SoC buscan minimizar el n umero de componentes externos, y de esta forma reducir los costos. Este SoC en particular fu e uno de los primeros que dise no ATMEL y est a enfocado a tareas en las que se requiere una conexi on de red. Dentro de los perif ericos encontramos: Controlador para memorias: NAND ash, DataFlash, SDRAM, SD/MMC Puerto USB 2.0 host.
26 Puerto I2C Interfaz Ethernet 10/100. Interfaz high speed USB 2.0 4 Puertos SPI. 2 puertos seriales (RS232). Soporte JTAG. Interf az de Bus externo (EBI).
Sistemas Embebidos
Figura 1.9: SoC AT91RM9200 fuente: Hoja de Especicaciones AT91RM9200, ATMEL Existen una serie de perif ericos que son indispensables en todo Sistema Embebido, los cuales facilitan la programaci on de aplicaciones y la depuraci on de las mismas. A continuaci on se realizar a una descripci on de los diferentes perif ericos que se encuentran disponibles en este SoC, indicando los que fueron utilizados en la plataforma de desarrollo.
Carlos Iv an Camargo Bare no Memorias Vol atiles
27
Como se estudi o anteriormente existen secciones del ejecutable que deben ser almacenadas en memorias vol atiles o en memorias no vol atiles. Debido a esto la mayor a de los SoC incluyen perif ericos dedicados a controlar diferentes tipos de memoria, las memorias vol atiles son utilizadas como memoria de acceso aleatorio (RAM) gracias a su bajo tiempo de accesso y al ilimitado n umero de ciclos de lectura/escritura. El tipo de memoria m as utilizado en los sistemas embebidos actuales es la memoria SDRAM; la cual est a organizada como una matriz de celdas, con un n umero de bits dedicados al direccionamiento de las las y un n umero dedicado a direccionar columnas (ver Figura 1.10).
Figura 1.10: Diagrama de Bloques de una memoria SDRAM fuente: Hoja de Especicaciones MT48LC16M16, Micron Technology Un ejemplo simplicado de una operaci on de lectura es el siguiente: Una posici on de memoria se determina colocando la direcci on de la la y la de la columna en las l neas de direcci on de la y columna respectivamente, un tiempo despu es el dato almacenado aparecer a en el bus de datos. El procesador coloca la direcci on de la la en el bus de direcciones y despu es activa la se nal RAS (Row Access Strobe). Despu es de un retardo de tiempo predeterminado para permitir que el circuito de la SDRAM capture la direcci on de la la, el procesador coloca la direcci on de la columna en el bus de direcciones y activa la se nal CAS (Column Access Strobe). Una celda de memoria SDRAM esta compuesta por un transistor y un condensador; el transistor suministra la carga y el condensador almacena el estado de cada celda, esta carga en el condensador desaparece con el tiempo, raz on por la cual es necesario recargar estos condensadores peri odicamente, este proceso recibe el nombre de Refresco. Un ciclo de refresco es un ciclo especial en el que no se escribe ni se lee informaci on, solo se recargan los condensadores para mantener la informaci on. El perif erico que controla la SDRAM est a encargado de garantizar los ciclos de refresco de acuerdo con los requerimientos de la SDRAM [16]. La gura 1.11 muestra el diagrama de conexiones de una memoria de 32MB utilizada en la plataforma ECBOT. El SoC AT91RM9200 posee un perif erico que es cap az de controlar la memoria SDRAM sin necesidad de l ogica adicional.
28
Sistemas Embebidos
Figura 1.11: Diagrama de conexiones de la memoria SDRAM de la plataforma ECBOT Memorias No Vol atiles La memorias no vol atiles almacenan por largos per odos de tiempo informaci on necesaria para la operaci on de un Sistema Embebido, pueden ser vistos como discos duros de estado s olido; existen dos tipos de memoria las memorias NOR y las NAND; las dos poseen la capacidad de ser escritas y borradas utilizando control de software, con lo que no es necesario utilizar programadores externos y puedens er modicadas una vez instaladas en el circuito integrado. Una desventaja de estas memorias es que los tiempos de escritura y borrado son muy largos en comparaci on con los requeridos por las memorias RAM. Las memorias NOR poseen buses de datos y direcci on, con lo que es posible acceder de forma f acil a cada byte almacenado en ella. Los bits datos pueden ser cambiados de 0 a 1 utilizando el control de software un byte a la vez, sin embargo, para cambiar un bit de 1 a 0 es necesario borrar una serie de unidades de borrado 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 perif erico especializado para su manejo. Las memorias NOR son utilizadas en aplicaciones donde se necesiten altas velocidades de lectura y baja densidad, debido a que los tiempos de escritura y lectura son muy grandes se utilizan como memorias ROM. Las memorias NAND disminuyen los tiempos de escritura y aumentan la capacidad de almacenamiento, ideales para aplicaciones donde se requiera almacenamiento de informaci on. Adicionalmente las memorias NAND consumen menos potencia que las memorias NAND, por esta raz on este tipo de memorias son utilizadas en casi todos los dispositivos de almacenamiento modernos como las memorias SD y las memorias USB, los cuales integran una memoria NAND con un circuito encargado de controlarlas e implementar el protocolo de comunicaci on. A diferencia de las ash tipo NOR, los dispositivos NAND se acceden de forma serial utilizando interfaces complejas; su operaci on se asemeja a un disco duro tradicional. Se accede a la informaci on utilizando bloques (m as peque nos que los bloques NOR). Los ciclos de escritura de las ash NAND son mayores en un orden de magnitud que los de las memorias NOR.
29
Figura 1.12: Ciclos de escritura y borrado de una memoria ash NOR Un problema al momento de trabajar con las memorias tipo NAND es que requieren el uso de un manejo de bloques defectuosos, esto es necesario ya que las celdas de memoria pueden da narse de forma espont anea durante la operaci on normal. Debido a esto se debe tener un determinado n umero de bloques que se encargen de almacenar tablas de mapeo para manejar los bloques defectuosos; o puede hacerse un chequeo en cada inicializaci on del sistema de toda la RAM para actualizar esta lista de sectores defectuosos. El algoritmo de ECC (Error-Correcting Code) debe ser cap az de corregir errores tan peque nos como un bit de cada 2048 bits, hasta 22 bits de cada 2048. Este algor tmo es capaz de detectar bloques defectu n comparando la informaci osos en la fase de programac o on almacenada con la que debe ser almacenada (vericaci on), si encuentra un error marca el bloque como defectuoso y utiliza un bloque sin defactos para almacenar la informaci on. La tabla 1.1 resume las principales caracter sticas de los diferentes tipos de memoria ash. SLC NAND 512Mbits - 4GBits 24MB/s 8 MB/s 2ms Acceso Indirecto Almacenamiento MLC NAND 1Gbits - 16GBits 18.6MB/s 2.4MB/s 2ms Acceso Indirecto Almacenamiento MLC NOR 16MBits - 1GBit 103MB/s 0,47MB/s 900ms Acceso Aleatorio Solo lectura
Densidad Velocidad de Lectura Velocidad de escritura Tiempo de borrado Interfaz Aplicaci on
Cuadro 1.1: Cuadro de comparaci on de las memorias ash NAND y NOR
El AT91RM9200 tiene un perif erico que puede manejar una memoria ash NAND, sin embargo, no se utiliz o en esta aplicaci on. En su lugar se utiliz o una memoria DataFlash de Atmel, este dispositivo b asicamente es una memoria ash tipo NOR con una interfaz SPI, permite una velocidad de lectura de
30
Sistemas Embebidos
hasta 66MHz utilizando solamente 4 pines para la comunicaci on con el procesador. La gura 1.13 muestra el diagrama de conexiones de esta memoria.
Figura 1.13: Conexiones de la memoria DataFlash de la plataforma ECBOT
M etodos de arranque Como es obvio todo SoC debe ser programado para que pueda ejecutar una determinada tarea; este programa debe estar almacenado en una memoria no vol atil y debe estar en el formato requerido por el procesador. Normalmente los SoCs proporcionan varios caminos (habilitando diferentes perif ericos) para hacer esto. Un programa de inicializaci on (boot program) contenido en una peque na ROM del SoC se encarga de congurar, y revisar ciertos perif ericos en b usqueda de un ejecutable, una vez lo encuentra, lo copia a la memoria RAM interna y lo ejecuta desde all . No sobra mencionar que este ejecutable debe estar enlazado de tal forma que todas las secciones se encuentren en el espacio de la memoria RAM interna (0x0 despu es del REMAP 18 ). El AT91RM9200 posee una memoria interna SRAM de 16 kbytes. Despu es del reset esta memoria esta disponible en la posici on 0x200000, despu es del remap esta memoria se puede acceder en la posici on 0x0. Algunos fabricantes, en la etapa de producci on graban en las memorias no vol atiles las apliacaciones denitivas, 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 de los dispositivos. El programa de inicializaci on del AT91RM9200 (se ejecuta si el pin BMS se encuentra en un valor l ogico alto) busca una secuencia de 8 vectores de excepci on ARM v alidos en la DataFlash conectada al puerto SPI, en una EEPROM conectada a la interfaz I2C o en una memoria de 8 bits conectada a la interfaz de bus externo (EBI), estos vectores deben ser instrucciones LDR o Bbranch, menos la sexta instrucci on (posici on 14 a 17) que contiene informaci on sobre el tama no de la im agen (en bytes) a descargar y el tipo de dispositivo DataFlash. Si la secuencia es encontrada, el c odigo es almacenado en la memoria SRAM interna y se realiza un remap (con lo que la memoria interna SRAM es accesible en la posici on 0x0 ver Figura 1.14). Si no se encuentra la secuencia de vectores ARM, se inicializa un programa que congura el puerto serial de depuraci on (DBGU) y el puerto USB Device. Quedando en espera de la descarga de una aplicaci on a trav es del protocolo DFU (Digital Firmware Upgrade) por el puerto USB o con el protocolo XMODEM en el puerto DBGU. La gura 1.15 muestra el diagrama de ujo del programa de inicializaci on del SoC AT91RM9200 El programa descargado a la memoria SRAM interna debe ser capaz de programar una memoria no vol atil (La Flash DataFlash SPI para el ECBOT), debe proporcionar un canal de comunicaci on que permita descargar ejecutables m as grandes, y debe inicializar el controlador de memoria SDRAM para que almacene
18 Los
procesadores ARM pueden intercambiar el sitio de la memoria RAM interna y la memoria no vol atil
31
Figura 1.14: Diagrama de ujo del programa de inicializaci on del SoC AT91RM9200
Figura 1.15: Diagrama de ujo del programa de inicializaci on del SoC AT91RM9200 temporalmente el ejecutable a grabar, esto es necesario ya que la memoria interna del AT91RM9200 solo es de 16kBytes. M as adelante hablaremos detalladamente de la aplicaci on que realiza estas funciones.
1.2.6.
Interfaz JTAG
A mediados de los 1970s, la estructura de pruebas para tarjetas de circuito impreso (PCB, Printed Circuit Boards) se basaba en el uso de la t ecnica bed-of-nails. Este m etodo hacia uso de un dispositivo que conten a una serie de puntos de prueba, que permit an el acceso a dispositivos en la tarjeta a trav es de puntos de prueba colocados en la capa de cobre, o en otros puntos de contacto convenientes. Las pruebas se realizaban en dos fases: La prueba del circuito apagado y la prueba del circuito funcionando. Con la aparici on de los dispositivos de montaje supercial se empez o a colocar dispositivos en las dos caras de la tarjeta, debido a que las dimensiones de los dispositivos de montaje supercial son muy peque nas, se disminuy o la distancia f sica entre las interconexiones, dicultando el proceso de pruebas. A mediados de los 1980s un grupo de ingenieros de pruebas miembros de compa n as electr onicas Europeas se reunieron para examinar el problema y buscar posibles soluciones. Este grupo se autode-
32
Sistemas Embebidos
nomin o JETAG (Joint European Test Action Group). El m etodo de soluci on propuesto por ellos estaba basado en el concepto de un registro de corrimiento serial colocado alrededor de la frontera dispositivo, de aqu el nombre ?Boundary Scan?. Despu es el grupo se asoci o a compa n as norteamericanas y la E de European desapareci o del nombre de la organizaci on convirti endose en JTAG (Join Test Action Group). Arquitectura BOUNDARY SCAN A cada se nal de entrada o salida se le adiciona un elemento de memoria multi-prop osito llamado Boundary Scan Cell (BSC). Las celdas conectadas a los pines de entrada reciben el nombre de Celdas de entrada, y las que est an conectadas a los pines de salida Celdas de salida. En la Figura 1.16 se muestra esta arquitectura.
Figura 1.16: Arquitectura Boundary Scan Las BSC se conguran en un registro de corrimiento de entrada y salida paralela. Una carga paralela de los registros (captura) ocasiona que los valores de las se nales aplicadas a los pines del dispositivo pasen a las celdas de entrada y que opcionalmente los valores de las se nales internas del dispositivo pasen a las celdas de salida. Una descarga paralela (Actualizaci on) ocasiona que los valores presentes en las celdas de salida pasen a los pines del dispositivo, y opcionalmente los valores almacenados en las celdas de entrada pasen al interior del dispositivo. Los datos pueden ser corridos a trav es del registro de corrimiento, de forma serial, empezando por un pin dedicado TDI (Test Data In) y terminando en un pin de salida dedicado llamado TDO (Test Data Out). La se nal de reloj se proporciona por un pin externo TCLK (Test Clock) y el modo de operaci on se controla por la se nal TMS (Test Mode Select). Los elementos del Boundary Scan no afectan el funcionamiento del dispositivo. Y son independientes del n ucleo l ogico del mismo. Instrucciones JTAG El Standard IEEE 1149.1 describe tres instrucciones obligatorias: Bypass, Sample/Preload, y Extest [17].
33
BYPASS Esta instrucci on permite que el chip permanezca en un modo funcional, hace que el registro de Bypass se coloque entre TDI y TDO; permitiendo la transferencia serial de datos a trav es del circuito integrado desde TDI hacia TDO sin afectar la operaci on. La codicaci on en binario para esta instrucci on debe ser con todos los bits en uno. SAMPLE/PRELOAD Esta instrucci on selecciona el registro Boundary-Scan para colocarse entre los terminales TDI y TDO. Durante esta instrucci on, el registro Boundary-Scan puede ser accesado a trav es de la operaci on Data Scan, para tomar una muestra de los datos de entrada y salida del chip. Esta instrucci on tambi en se utiliza para precargar los datos de prueba en el registro Boundary-Scan antes de ejecutar la instrucci on EXTEST. La codicaci on de esta instrucci on la dene el fabricante. EXTEST Esta instrucci on coloca al circuito integrado en modo de test externo (pruebas de la interconexi on) y conecta el regsitro Boundary-Scan entre TDI y TDO. Las se nales que salen del circuito son cargadas en el registro boundary-scan en el anco de bajada de TCK en el estado Capture-DR; las se nales de entrada al dispositivo son cargadas al registro boundary-scan durante el anco de bajada de TCK en el estado Update-DR (ver Figura 1.17) . La codicaci on para esta instrucci on est a denida con todos los bits en cero. INTEST La instrucci on opcional INTEST tambi en selecciona el registro boundary-scan, pero es utilizado para capturar las se nales que salen del n ucleo l ogico del dispositivo, y para aplicar valores connocidos a las se nales de entrada del n ucleo. La codicaci on para esta se nal es asignada por el dise nador.
Figura 1.17: Arquitectura Boundary Scan
Depuraci on del core ARM [18] Todos los nucleos ARM7 y ARM9 poseen soporte de depuraci on en modo halt, lo que permite detener por competo el n ucleo. Durante este estado es posible modicar y capturar las se nales del n ucleo,
34
Sistemas Embebidos
permitiendo cambiar y examinar el core y el estado del sistema. En este estado la fuente de reloj del core es el reloj de depuraci on (DCLK) que es generado por la l ogica de depuraci on. Los n ucleos ARM7 y ARM9 implementan un controlador compatible con JTAG, con dos cadena boundary-scan alrededor de las se nales del core, una con las se nales del core, para pruebas del dispositivo y la otra es un sub-set de la primera con se nales importantes para la depuraci on. La Figura 1.18 muestra el orden de las se nales en las cadenas para los n ucleos ARM7TDMI y ARM9TDMI. Para pop ositos de depuraci on es suciente la cadena 1. Esta cadena puede ser utilizada en modo INTEST, permitiendo capturar las se nales del core y aplicar vectores al mismo, o en modo EXTEST, permitiendo la salida y entrada de informaci on hacia y desde exterior del core respectivamente.
Figura 1.18: Cadena Boundary Scan 1 Las se nales D[0:31] del ARM7TDMI est an conectadas al bus de datos del n ucleo y se utiliza para capturar instrucciones o lectura/escritura de informaci on; la se nal BREAKPT se utiliza para indicar que la instrucci on debe ejecutarse a la velocidad del sistema, esto es, utilizando el reloj MCLK en lugar de DCLK. Las se nales ID[0:31] del ARM9TDMI est an conectadas al bus de instrucciones y se utilizan para capturar instrucciones, las se nales DD[31:0] est an conectadas al bus de dtaos bi-direccional y se utilizan para leer o escribir informaci on.
Figura 1.19: Cadena Boundary Scan 2 (Embedded ICE) Los ARM7 y ARM9 poseen un m odulo ICE (In Circuit Emulator) que reemplaza el microcontrolador con una variaci on que posee facilidades para la depuraci on hardware. El emulador es conectado a un computador que ejecuta el software de depuraci on. Esto permite realizar depuraci on activa y pasiva, dando un punto de vista no intrusivo del ujo del programa. La Figura 1.19 muestra la cadena scan ICE, que es la misma para los n ucleos ARM7 y ARM9, esta formada por 32 bits de datos, 5 bits de direcciones y un ag para diferenciar entre lectura (nRW bajo) y escritura. Se puede acceder a las caracter sticas ICE a trav es de registros, cuya direcci on es colocada en el bus de direcciones.
35
El proyecto OPENOCD (Open On-Chip Debugger 19 ) permite la programaci on de la memoria ash interna de algunos procesadores ARM7TDMI, y la depuraci on de procesadores ARM7 y ARM9 utilizndo el m odulo ICE. Este proyecto se ha convertido en el m as popular dentro del grupo de desarrolladores de sistemas Embebidos. En [18] se puede encontrar el funcionamiento interno de esta herramienta.
Programaci on de memorias Flash Algunos SoC no poseen programas de inicializaci on que permitan la descarga de aplicaciones ya sea a las memorias externas o a la interna, una soluci on podr a ser utilizar el protocolo JTAG para cargar las aplicaciones en la RAM interna, sin embargo, existen procesadore en los que no se conocen las espcicaciones del ICE y en en otros este m odulo no existe. En estos casos se utiliza la interfaz JTAG en modo EXTEST para controlar directamente las memorias conectadas a los SoCs. El proyecto UrJTAG, 20 permite la programaci on de diversas memorias ash, utilizando los pines del dispositivo. UrJTAG permite la creaci on de diferentes interfaces para conectarse con las memorias, estas interfaces reciben el nombre de buses y pueden ser creadas e incluidas en el c odigo original de forma f acil.
1.3.
El sistema Operativo Linux
Hello everybody out there using minix - Im doing a (free) operating system (just a hobby, wont be big and professional like gnu) for 386(486) AT clones. Con este mail enviado al foro de discusi on comp.os.minix, Linus Torvalds, un estudiante de la Universidad de Helsinki en Finlandia introduce Linux el 25 de Agosto de 1991. A principios de los 90, el sistema operativo Unix (desarrollado en The Bell Labs a principios de los 60s), ten a una solida posici on en el mercado de servidores, y estaba muy bien posicionado en las Universidades, por lo tanto, un gran n umero l y muchos de ellos deseaban poder utilizarlo en sus computadores de estudiantes trabajaban a diario con e personales, sin embargo, Unix era un producto comercial muy costoso. La gura 1.20 muestra el desarrollo previo a la creaci on de la primera versi on de linux hasta el d a de hoy. Una de las caracter sticas m as importantes de Linux es que desde su creaci on, fue pensado como un sistema operativo gratuito y de libre distribuci on. Esta caracter stica ha permitido que programadores a lo largo del mundo puedan manipular el c odigo fuente para eliminar errores y para aumentar sus capacidades. Sin embargo, el cr edito de las que conocemos hoy (Debian, Ubuntu, Suse, etc) no solo se debe a Torvalds, ya que linux es solo el kernel del sistema operativo. En 1983, Richard Stallman funda en proyecto GNU, el cual proporciona una parte esencial de los sistemas linux. A principios de los 90s, GNU hab a producido una serie de herramientas como librer as, compiladores, editores de texto, Shells, etc. Estas herramientas fueron utilizadas por Torvalds para escribir el elemento que le hac a falta al proyecto GNU para completar su sistema operativo: el kernel. Desde el lanzamiento de la primera versi on de linux, cientos, miles, cientos de miles y millones de programadores se han puesto en la tarea de convertir a linux en un sistema operativo robusto, amigable y actualizado; tan pronto como se desarrolla una nueva pieza de hardware existen cientos de programadores trabajando en crear el soporte para linux.
19 http://openocd.berlios.de/web/ 20 http://urjtag.sourceforge.net/
36
Sistemas Embebidos
Figura 1.20: Linux: Historia Fuente. Porqu e Linux Existen varias motivaciones para escoger Linux frente a un sistema oeprativo tradicional para sistemas embebidos [19]: Calidad Y conabilidad del c odigo: Aunque estas medidas son subjetivas, miden el nivel de conanza en el c odigo, que compromete software como el kernel y las aplicacione proporcionadas por las distribuciones. Disponibilidad de C odigo: Todo el c odigo fuente de las aplicaciones, del sistema operativo y de las herramientas de compilaci on se encuentran disponibles sin ninguna restricci on. Existen varios tipos de licencias: la GNU General Public License (GPL). BSD (Berkeley Software Distribution), la cual permite la distribuci on de binarios sin el c odigo fuente. Soporte de Hardware: Linux soporta una gran variedad de dispositivos y plataformas, a pesar de que muchos fabricantes no proporcionan soporte para Linux, la comunidad trabaja arduamente en incluir el nuevo hardware en las nuevas distribuciones de Linux. Linux en la actualidad se puede ejecutar en docenas de diferentes arquitecturas hardware, lo cual lo convierte en el Sistema Operativo m as portable. Protocolos de Comunicaci on y est andares de Software: Linux proporciona muchos protocolos de comunicaci on, lo que permite su f acil integraci on a marcos de trabajo ya existentes. Disponibilidad de Herramientas: La variedad de herramientas disponibles para Linux lo hacen muy vers atil. Existen grandes comunidades como SourceForge21 o Freshmeat 22 que permiten a miles de desrroladores compartir sus trabajos y es posible que en ellas se encuentre una aplicaci on que cumpla con sus necesidades.
21 http://www.sourceforge.net 22 http://www.freshmeat.net
37
Soporte de la Comunidad: Esta es la principal fortaleza de Linux. Millones de usuarios alrededor del mundo pueden encontrar errores en alguna aplicaci on y desarrolladores miembros de la cumonidad (en algunos casos los creadores de las aplicaciones) arreglar an este problema y difundir an su soluci on. El mejor sitio para hacer esto son las listas de correo de soporte y desarroll. Licencia: Al crear una aplicaci on bajo alguna de las licencias usuales en Linux, no implica perder la porpiedad intelectual ni los derechos de autor la misma. Independencia del vendedor: No existe solo un distribuidor del sistema operativo GNU-Linux, ya que las licencias de Linux garantizan igualdad a los distribuidores. Algunos vendedores poporcionan aplicaciones adicionales que no son libres y pro lo tanto no se encuentran disponibles con otros vendedores. Esto debe tenerse en cuenta en el momento de elegir la distribuci on a utilizar. Costo: Muchas de las herramientas de deasrrollo y componentes de Linux son gratuitos, y no requieren 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 cual fue implementado posteriormente por los sistemas operativos Windows y MacOS. Con estas caracter sticas es posible ejecutar tareas de forma independiente, y transparente para el/los usuarios. Linux est a compuesto por cinco sub-m odulos [2]: El programador (Scheduler), el manejador de memoria, el sistema de archivos virtual, la interfaz de red y la comunicaci on entre procesos (IPC). Tal como se ilustra en la gura 1.21.
Figura 1.21: Estructura del kernel de linux Como puede observarse en la gura 1.21 el kernel de linux posee sub-m odulos que son independientes de la arquitectura y otros que deben ser escritos para el procesador utilizado, esto hace que Linux sea un sistema operativo portable. En la actualidad existe una gran variedad de arquitecturas soportadas por linux, entre las que se encuentran: alpha arm26 frv i386 m32r m68knommu parisc ppc64 sh sparc um x86 64 arm cris h8300 ia64 m68k mips ppc s390 sh64 sparc64 v850 Las funciones de estos componentes se describen a continuaci on [1]:
38 Programador de procesos (Scheduler)
Sistemas Embebidos
Es el coraz on 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 en ejecuci on. Recibir interrupciones y llevarlas al subsistema del kernel adecuado. Enviar se nales a los procesos de usuario. Manejar el timer f sico. Liberar los recursos de los procesos, cuando estos nalizan su ejecuci on. El programador de procesos proporciona dos interfaces: Una limitada para los procesos de usuario y una interfaz amplia para el resto del kernel. El scheduler de Linux utiliza una interrupci on del timer que se presenta cada 10 ms, por lo tanto, el cambio de estado del programador se realiza cada 10 ms. Esto debe ser tenido en cuenta a la hora de realizar procesos que manejen dispositivos hardware veloces. Un proceso puede estar en uno de los siguientes estados: En ejecuci on. Retornando de un llamado de sistema. Procesando una rutina de interrupci on. 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 las ROMs). El c odigo de inicializaci on del Sistema Operativo debe activar el modo protegido del procesador, de tal forma que la memoria Extendida (incluyendo la memoria de los dispositivos) sea accesible. Finalmente el OS habilita la memoria virtual para permitir la ilusi on de un espacio de memoria de 4 GB. El manejador de memoria proporciona los siguientes servicios (ver guras 1.22 y 1.23): Gran espacio de memoria. Los procesos usuario, pueden referenciar m as memoria que la existente f sicamente. Protecci on La memoria de un proceso es privada y no puede ser le da o modicada por otro proceso. Adicionalmente evita que los procesos sobreescriban datos de solo lectura. rea de memoria virtual y accesar Mapeo de memoria Los usuarios pueden mapear un archivo en un a el archivo como una memoria. Acceso transparente a la memoria f sica esto asegura un buen desempe no del sistema.
Carlos Iv an Camargo Bare no Memoria compartida
39
Al igual que el programador el manejador de memoria proporciona dos diferentes niveles de acceso a 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 protecci on sobre una regi on de una memoria virtual. mlock() / mlockall() / munlock() / munlockall() Rutinas que permiten al super usuario prevenir el intercambio de memoria. swapon() / swapoff() Rutinas que le permiten al super-usuario agregar o eliminar archivos swap en el sistema. Nivel de kernel kmalloc() / kfree() Asigna o libera memoria para que sea utilizada por estructuras de datos del kernel. verify area() Verica que una regi on de la memoria de usuario ha sido mapeada con los permisos necesarios. get free page() / free page() Asigna y libera p aginas de memoria f sica.
Figura 1.22: Mapeo de memoria del Kernel.
Comunicaci on Entre Procesos (IPC) El mecanismo IPC de Linux posibilita la ejecuci on concurrente de procesos, permitiendo compartir recursos, la sincronizaci on e intercambio de datos entre ellos. Linux proporciona los siguientes mecanismos: Senales Mensajes as ncronos enviados a los procesos.
40
Sistemas Embebidos
Figura 1.23: Mapeo de memoria para una aplicaci on Listas de espera Proporciona mecanismos para colocar a dormir a los procesos mientras esperan que una operaci on se complete, o un recurso se libere. Bloqueo de archivos Permite a un proceso declarar una regi on de un archivo como solo lectura para los dem as procesos. Conductos (pipe) Permite transferencias bi-direccionales entre dos procesos. System V Sem aforos Una implementaci on del modelo cl asico del sem aforo. Lista de Mensajes Secuencia de bytes, con un tipo asociado, los mensajes son escritos a una lista de mensajes y pueden obtenerse leyendo esta lista. Memoria Compartida Mecanismo por medio del cual varios procesos tienen acceso a la misma regi on de memoria f sica. Sockets del dominio Unix Mecanismo de transferencia de datos orientada a la conexi on. Interfaces de Red Este sistema proporciona conectividad entre m aquinas, y un modelo de comunicaci on por sockets. Se proporcionan dos modelos de implementaci on de sockets: BSD e INET. Adem as, proporciona dos protocolos de transporte con diferentes modelos de comunicaci on y calidad de servicio: El poco conable ltiprotocolo UDP (User Datagram Protocol) y el conable TCP (Transmission Control Protocol), este u mo garantiza el env o de los datos y que los paquetes ser an entregados en el mismo orden en que fueron enviados. Se proporcionan tres tipos diferentes de conexi on: 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
Carlos Iv an Camargo Bare no Manejar sistemas de archivos l ogicos Soporta diferentes formatos ejecutables Por ejemplo a.out, ELF, java) Homogeneidad Proporciona una interfaz com un a todos los dispositivos l ogicos o f sicos. Desempeno Seguridad Conabilidad Drivers de Dispositivos
41
La capa manejador de dispositivos es responsable de presentar una interfaz com un a todos los dispositivos f sicos. El kernel de Linux tiene 3 tipos de controladores de dispositivo: Caracter (acceso secuencial), bloque (acceso en m ultiplos de tama no de bloque) y red. Ejemplos de controladores secuenciales son el modem, el mouse; ejemplos de controladores tipo bloque son los dispositivos de almacenamiento masivo como discos duros, memorias SD. Los manejadores de dispositivos soportan las operaciones de archivo, y pueden ser tratados como tal. Sistema de Archivos l ogico Aunque es posible acceder a dispositivos f sicos a trav es de un archivo de dispositivo, es com un acceder a dispositivos tipo bloque utilizando un sistema de arcvhivos l ogico, el que puede ser montado en un punto del sistema de archivos virtual. Para dar soporte al sistema de archivos virtual, Linux utiliza el concepto de inodes. Linux usa un inode para representar un archivo sobre un dispositivo tipo bloque. El inode es virtual en el sentido que contiene operaciones que son implementadas diferentemente dependiendo de el sistema l ogico y del sistema f sico donde reside el archivo. La interfaz inode hace que todos los archivos se vean igual a otros subsistemas Linux. El inode se utiliza como una posici on de almacenamiento para la informaci on relacionada con un archivo 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. M odulos La mayor funcionalidad del sistema de archivos virtual se encuentra disponible en la forma de m odulos cargados din amicamente. Esta cconguraci on din amica permite a los usuarios de Linux compilar un kernel tan peque no como sea posible, mientras permite cargar el manejador del dispositivo y m odulos del til en el caso de los dispositivos que sistema de archivos si solo son necesarios durante una sesi on. Esto es u se pueden conectar en caliente, como por ejemplo un scanner, si tenemos el manejador del scanner cragado a un sin que este este conectado a nuestro equipo se esta desperdiciando la memoria asociada a dicho controlador. Interfaces de Red Este sistema proporciona conectividad entre m aquinas, y un modelo de comunicaci on por sockets. Se proporcionan dos modelos de implementaci on de sockets: BSD e INET. Adem as, proporciona dos protocolos de transporte con diferentes modelos de comunicaci on y calidad de servicio: El poco conable
42
Sistemas Embebidos
ltiprotocolo UDP (User Datagram Protocol) y el conable TCP (Transmission Control Protocol), este u mo garantiza el env o de los datos y que los paquetes ser an entregados en el mismo orden en que fueron enviados. Se proporcionan tres tipos diferentes de conexi on: 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 coraz on del sistema operativo GNU/Linux y es el encargado de manejar directamente el Hardware asociado a una determinada plataforma, por lo tanto, es necesario que este sea cap az de manejar todos los perif ericos asociados a esta y proporcione caminos para controlarlos. En esta secci on se describir a el proceso que debe realizarse para hacer que Linux se ejecute de forma correcta en una plataforma y que permita controlar sus diferentes componentes hardware (este proceso recibe el nombre de Porting).
1.4.1.
El Kernel de Linux
El c odigo fuente se encuentra dividido entre el c odigo espec co a una arquitectura y el c odigo com un. El c odigo espec co de cada arquitectura lo encontramos en los subdirectorios arch y include/asmxxx, en ellos podemos encuentrar los archivos para las arquitecturas: alpha, blackn, h8300, m68k, parisc, s390, sparc, v850, arm, cris, ia64, m68knommu, powerpc, sh, sparc64, x86, avr32, frv, m32r, mips, ppc, sh64, um, xtensa. A continuaci on se listan los directorios que hacen parte sdel c odigo fuente de Linux.
arch usr Documentation sound fs include mm lib crypto security net ipc drivers block scripts kernel
Dentro de cada arquitectura soportada por Linux (arch/xxx/ ) encontramos los siguientes directorios: kernel C odigo del n ucleo del kernel. mm C odigo para el manejo de memoria. lib Librer a de funciones internas, optimizadas para la arquitectura (backtrace, memcpy, funciones I/O, bit-twiddling etc); nwfpe Implementaciones de punto otante. boot Sition donde reside la im agen del kernel una vez compilado, este directorio contiene herramientas para generar im agenes comprimidas. tools Contiene scripts para la autogeneraci on de archivos, tambi en contiene el archivo mach-types que contiene la lista de las m aquinas (plataformas) registradas. congs Contiene el archivo de conguraci on para cada plataforma. Si deseamos dar soporte a una determinada plataforma debemos trabajar en el directorio que contiene la arquitectura del procesador a utilizar, en nuestro caso trabajaremos con la arquitectura arm. En el c odigo fuente de Linux se encuentran muchas plataformas que utilizan las diferentes architecturas, los archivos de conguraci on de estas pueden ser utilizados para crear una propia. En nuestro caso tomamos como referenica la plataforma Atmel AT91RM9200-EK dise nada por ATMEL. Los archivos de conguraci on
43
de esta plataforma se encuentra en: arch/arm/mach-at91/board-ek.c; dentro de la arquitectura arm existen varias sub-arquitecturas que corresponden a las diferentes familias de SoC; El AT91RM9200 hace parte de la familia de SoCs AT91 de ATMEL. Existen dos formas en las que podemos adaptar nuestra plataforma al kernel de Linux, la primera es utilizando un archivo de conguraci on de una plataforma existente, y la otra es registrar la nuestra. Cada plataforma es identicada por un machine ID, el primero paso en el proceso de port es obter un ID, lo cu al se puede hacer en l nea: http://www.arm.linux.org.uk/developer/machines/, mientras que se asigna un nuevo n umero puede asignarse uno que no este utilizado en el archivo: arch/arm/tools/mach-types. La entrada correspondiente a la familia de plataformas ECBACT91 es:
ecbat91 MACH ECBAT91 ECBAT91 1072
Con este ID (o uno temporal) se debe crear la siguiente entrada en el archivo /arch/arm/machat91/Kcong b/arch/arm/mach-at91/Kcong:
c o n f i g MACH ECBAT91 b o o l emQbit ECB AT91 SBC d e p e n d s on ARCH AT91RM9200 help 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 b o a r d . < h t t p : / / w i k i . e m q b i t . com / f r e e ecb a t 9 1 >
La que permite seleccionar nuestra plataforma desde el programa de conguraci on de Linux23 (Ver Figura 1.24)
Figura 1.24: Herramienta de conguraci on de Linux mostrando la plataforma ECB AT91 Al seleccionar nuestra plataforma el programa de conguraci on crear a un archivo de conguraci on .cong 24 localizado en la ra z del c odigo fuente, este archivo reeja las selecciones realizadas para congurar la imagen del kernel; en este caso espec co se agragar a la l nea:
CONFIG MACH ECBAT91=y
Como veremos m as adelante, la aplicaci on encargada de cargar la im agen del kernel de Linux le pasa a este el n umero de identicaci on de la plataforma, si este n umero no es el mismo que el kernel tiene registrado se generar a un error, para evitar esto debemos incluir las siguientes l neas en el archivo arch/arm/boot/compressed/head-at91rm9200.S
23 este 24 los
programa se ejecuta con el comando: make ARCH=arm CROSS COMPILE=arm-none-eabiarchivos que comienzan con . est an ocultos
44
Sistemas Embebidos
@ emQbit ECB AT91 : 1072 mov r3 , # ( MACH TYPE ECBAT91 & 0 x f f ) orr r3 , r3 , # ( MACH TYPE ECBAT91 & 0 x f f 0 0 ) cmp r7 , r 3 beq 99 f
El archivo /arch/arm/mach-at91/Makele b/arch/arm/mach-at91/Makele contiene una relaci on entre la plataforma seleccionada y el archivo de compilaci on a utilizar, por lo que debemos incluir las siguientes l neas:
o b j $ ( CONFIG MACH ECBAT91 ) += b o a r d e c b a t 9 1 . o
Con esto asignamos el archivo de conguraci on board-ecbat91.c a la plataforma MACH ECBAT91. Archivo de conguraci on de la plataforma ECB AT91 En esta secci on realizaremos una descripci on del archivo de conguraci on de la familia de plataformas ECB AT91 (board-ecbat91.c) y se har a una explicaci on de cada uno de los par ametros de este archivo. Como todo archivo escrito en C al comienzo se declaran los encabezados que contienen las funciones utilizadas, en nuestro caso:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 # include # include # include # include # include # include # include # include # include # include # include # include # include <l i n u x <l i n u x <l i n u x <l i n u x <l i n u x <l i n u x <l i n u x <l i n u x <l i n u x / t y p e s . h> / i n i t . h> /mm. h> / module . h> / dmamapping . h> / p l a t f o r m d e v i c e . h> / s p i / s p i . h> / s p i / f l a s h . h> / l e d s . h>
<asm / h a r d w a r e . h> <asm / s e t u p . h> <asm / mach t y p e s . h> <asm / i r q . h>
# i n c l u d e <asm / mach / a r c h . h> # i n c l u d e <asm / mach / map . h> # i n c l u d e <asm / mach / i r q . h> # include # include # include # include # include <asm / a r c h / b o a r d . h> <asm / a r c h / at91rm9200 mc . h> <asm / a r c h / g p i o . h> < l i n u x / g p i o k e y s . h> < l i n u x / i n p u t . h>
# include generic . h # i n c l u d e <asm / a r c h / a t 9 1 p i o . h> # i n c l u d e < l i n u x / w1g p i o . h>
Cada arquitectura (CPU) posee un archivo donde se declaran los diferentes perif ericos que pueden l ser utilizados: arch/arm/mach-at91/at91rm9200 devices.c en el caso del procesador AT91RM9200; En e podemos 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
45
Serial Controller, UART. Este archivo adem as proporciona funciones que permiten incluir y congurar los diferentes controladores asociados al SoC, adicionalmente realiza las operaciones necesarias para poder utilizarlo, como por ejemplo, denir que el control de un determinado pin este a cargo del perif erico. El primer dispositivo declarado en el archivo de conguraci on es el puerto serial (UART), este puerto nico medio de comunicaci es vital ya que es el u on que tenemos con nuestra plataforma.
static struct at91 uart . console tty . nr tty . tty map }; config initdata ecb at91uart config = { = 0, / ttyS0 / = 2, = { 4 , 0 , 1, 1, 1 } / ttyS0 , . . . , ttyS4 /
Los par ametros de conguraci on de la UART se declaran utilizando la estructura at91 uart cong declarada en el archivo include/asm-arm/arch/board.h, la variable console tty dene el n umero del disposumero de interfaces itivo tty asociado a la consola serial, ttyS0 en nuestro caso, la variable nr tty dene el n seriales disponibles 25 , ttyS0 y ttyS1 en nuestro caso; tty map realiza la correspondencia entre los dispositivos 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 void i n i t ecb at91map io ( void ) { / I n i t i a l i z e p r o c e s s o r : 1 8 . 4 3 2 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 ( 1 8 4 3 2 0 0 0 , 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 funci on at91rm9200 initialize declarada en arch/arm/mach-at91/at91rm9200.c se encarga, como su nombre lo indica, de inicializar el procesador AT91RM9200, espec camente se encarga de congurar, el reloj interno del procesador (con la funci on at91 clock init), registra los Osciladores congurables PCK0 a PCK3 (utilizando la funci on at91rm9200 register clocks) y nalmente habilita el soporte para los pines de entrada/salida de prop osito general GPIOs (utilizando la funci on at91 gpio init). Adicionalmente informa que se est a utilizando el empaquetado TQFP208 (Este chip viene en dos versiones TQFP y BGA). Las plataforma que carecen de un dispositivo de visualizaci on como una pantalla, reejan la actividad de procesos importantes en el estado de diodos emisores de luz LEDs, Linux permite visualizar la actividad de la CPU y el estado de un timer interno (at91 init leds( cpu led, timer led)). Nuestra plataforma utiliza un LED conectado al pin PB20 para estas indicaciones. La funci on at91 init serial(&ecb at91uart cong), como su nombre lo indica inicializa las interfaces seriales utilizando como conguraci on la estructura at91 init serial explicada anteriormente.
s t a t i c void 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 funci on at91rm9200 init interrupts inicializa el Controlador de Interrupciones del AT91RM9200 y permite que estas sean atendidas.
static struct at91 usbh data
25 El
i n i t d a t a ecb at91usbh data = {
AT91RM9200 tiene 4 USARTS y una UART para depuraci on
46
. ports }; = 1,
Sistemas Embebidos
La estructra at91 usbh data ja el n umero de puertos USB host a 1 (El encapsulado TQFP solo tiene un puerto USB host, la versi on BGA tiene 2).
s t a t i c s truc t at91 mmc data . slot b = 0, . wire4 = 1, }; i n i t d a t a ecb at91mmc data = {
El SoC AT91RM9200 puede manejar dos memorias SD, la variable slot b determina cual se usa, el slot a en nuestro caso; la variable wire4 selecciona el n umero de l neas de datos entre 1 y 4 (wire4 = 1).
# i f d e f i n e d ( CONFIG MTD DATAFLASH ) static struct mtd partition initdata my flash0 partitions [] = { { . name = D a r r e l l o a d e r , / 0 x0 . offset = 0, . s i z e = 12 1 0 5 6 , / / 12672 b y t e s }, { . name = u b o o t , / / 0 x3180 . o f f s e t = MTDPART OFS NXTBLK , . s i z e = 118 1 0 5 6 , }, { . name = k e r n e l , / / 0 x21840 . o f f s e t = MTDPART OFS NXTBLK , . s i z e = 1534 1 0 5 6 , / 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 , } }; static struct flash platform data i n i t d a t a my flash0 platform = { . name = Removable f l a s h c a r d , . parts = my flash0 partitions , . 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 ) }; # endif
Muchos dispositivos ash est an divididos en secciones que reciben el nombre de particiones, similares a las particiones encontradas en un disco duro. El subsistema MTD proporciona soporte para estas particiones Flash, si esta funci on es seleccionada con la herramienta de conguraci on del kernel (CONFIG MTD DATAFLASH = y). La familia de plataformas ECB AT91 tiene un dispositivo DataFlash serial de 16 Mbits (2Mbytes), en la que creamos 4 particiones, en las que se almacenar an el loader, el u-boot, la imagen del kernel, y el sistema de archivos (En el dispositivo ash actual no hay suciente espacio para ltimo). Cada partici este u on se dene con una estructura mtd partition formada por 3 variables: name, offset (Direcci on inicial de la partici on) y .size.
static struct spi board info initdata ecb at91spi devices [] = { { / DataFlash chip / . modalias = mtd dataflash ,

. chip select . max speed hz . bus num . platform data }, { = = = = 0, 10 1000 1 0 0 0 , 0, &m y f l a s h 0 p l a t f o r m ,
47
/ User a c c e s s a b l e s p i c s 1 ( 2 5 0 KHz ) / . modalias = s p i c s 1 , . chip select = 1, . max speed hz = 250 1 0 0 0 , / User a c c e s s a b l e s p i c s 2 ( 1MHz) / . modalias = s p i c s 2 , . chip select = 2, . max speed hz = 1 1000 1 0 0 0 , / User a c c e s s a b l e s p i c s 3 ( 1 0MHz) / . modalias = s p i c s 3 , . chip select = 3, . max speed hz = 10 1000 1 0 0 0 ,
}, {
}, {
}, };
La estructura spi board info dene los dispositivos SPI conectados al SoC, esta formada por la variable modalias, chip select y max speed hz. Nuestro dispositivo DataFlash se controla utilizando un puerto SPI, por esto se dene la variable platform data = &my ash0 platform
s t a t i c void 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 / at91 add device serial (); / USB H o s t / 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 , &e c b a t 9 1 m m c d a t a ) ; / 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 C l o c k 1 / a t 9 1 s e t B p e r i p h ( AT91 PIN PA4 , 0 ) ; }
Una vez congurados los perif ericos utilizados en la plataforma debemos agregar estos dispositos, con las funciones correspondientes at91 add device (serial, usbh, i2c, mmc, spi) estas funciones hacen un llamado a la funci on 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 / . phys io = AT91 BASE SYS , . io pg offst = ( AT91 VA BASE SYS >> 1 8 ) & 0 x f f f c , . boot params = AT91 SDRAM BASE + 0 x100 , . timer = &a t 9 1 r m 9 2 0 0 t i m e r , . map io = ecb at91map io , . init irq = ecb at91init irq , . init machine = ecb at91board init , MACHINE END
48 Archivo de Conguraci on del kernel
Sistemas Embebidos
Finalmente debemos incluir un archivo de conguraci on para el kernel (arch/arm/congs/ecbat91 defcong) el cual contiene la conguraci on inicial que cngura de forma correcta todos los perif ericos de la plataforma.
1.4.2.
Imagen del kernel
En esta secci on se realizar a una descripci on de los pasos necesarios para compilar la im agen del es, se realizar a un an alisis de la imagen, kernel de Linux para la familia de plataforma ECB AT91; despu indicando su composici on. Compilaci on de la Im agen del kernel En la secci on anetrior vimos como dar soporte a nuestra plataforma, en esta secci on describiremos el proceso de creaci on de la im agen del kernel. El primer paso obvio es obtener la im agen del kernel, la que obtenemos del sitio ocial ftp.kernel.org
wget h t t p : / / f t p . k e r n e l . o r g / 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 . b z 2 t a r x j f l i n u x 2 . 6 . 2 4 . 4 . t a r . bz2 cd l i n u x 2 . 6 . 2 4 . 4
A continuaci on descargargamos un parche que mantienen los desarrolladores de la familia de SoCs de ATMEL, este parche modica algunos archivos de la distribuci on ocial de Linux para dar sopote completo y actualizado a los procesadores ATMEL.
wget h t t p : / / maxim . o r g . z a / AT91RM9200 / 2 . 6 / 2 . 6 . 2 4 a t 9 1 . p a t c h . g z z 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 c odigo fuente, mencionados anteriormente fueron enviados a los encargados de mantener estas actualizaciones, por lo que no es necesario modicarlos para dar soporte a la familia de plataformas ECB AT91. Finalmente debemos compilar el kernel utilizando la cadena de herramientas GNU, el resultado de este tipo de compilaciones son ejecutables para una arquitectura ARM, este proceso recibe el nombre de compilaci on cruzada, debido a que da como resultado archivos que se ejecutan en una arquitectura diferente (ARM) a la que realiz o el proceso de compilaci on (X86 en nuestro caso). Lo primero que debemos hacer es hacer visibles los ejecutables de la cadena de herramientas, esto se hace adicionando la ruta donde se encuentran 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 r o s s m a k e = make ARCH=arm CROSS COMPILE=armnone e a b i
El alias crossmake hace que cada vez que se escriba esta palabra el sistema lo reemplaze por make ametros ARCH=arm CROSS COMPILE=arm-none-eabi-, lo que ahorra tiempo al momento de pasar los par a la herramienta make; estos par ametros son: 1. ARCH=arm Dene la arquitectura arm. 2. CROSS COMPILE=arm-none-eabi- Indica que se realizar a una compilaci on cruzada y que los ejecutables de la cadena de herramientas (gcc, c++, ld, objcopy, etc) comienzan con el prejo arm-noneeabi- (por lo que el nombre del ejecutable del compilador de c es arm-none-eabi-gcc)
49
Una vez declaradas estas variables de entorno debemos generar el archivo oculto .cong 26 ejecutando el siguiente comando:
crossmake e c b a t 9 1 d e f c o n f i g o make ARCH=arm CROSS COMPILE=armnone e a b i e c b a t 9 1 d e f c o n f i g
A continuaci on se muestra una secci on 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 compilaci on:

c r o s s m a k e j 2 ( o make ARCH=arm CROSS COMPILE=armnone e a b i j 2 )
Si no ocurre ning un error, al nalizar debemos observar lo siguiente:

LD vmlinux SYSMAP System . map SYSMAP . t m p S y s t e m . map OBJCOPY a r c h / arm / b o o t / Image B u i l d i n g modules , s t a g e 2 . MODPOST 1 m o d u l e s K e r n e l : a r c h / arm / b o o t / Image i s r e a d y AS a r c h / arm / b o o t / c o m p r e s s e d / h e a d . o CC d r i v e r s / s c s i / s c s i w a i t s c a n . mod . o GZIP a r c h / arm / b o o t / c o m p r e s s e d / p i g g y . gz LD [M] d r i v e r s / s c s i / s c s i w a i t s c a n . ko CC a r c h / arm / b o o t / c o m p r e s s e d / m i s c . o AS a r c h / arm / b o o t / c o m p r e s s e d / head a t 9 1 r m 9 2 0 0 . o AS a r c h / arm / b o o t / c o m p r e s s e d / p i g g y . o LD a r c h / arm / b o o t / c o m p r e s s e d / v m l i n u x OBJCOPY a r c h / arm / b o o t / zImage K e r n e l : a r c h / arm / b o o 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 / b o o t / b o o t p c o m p r e s s e d Image $ l s vmlinux vmlinux vmlinux . o i n s t a l l . sh Makefile zImage
26 este
archivo es utilizado por las herramientas de compilaci on para determinar que soporte fu e incluido en el kernel
50 Componentes de la Im agen del kernel
Sistemas Embebidos
Como nuestro inster es en este punto es entender la estructura de la im agen del kernel podemos indicarle a nuestra herramienta de compilaci on que nos muestre m as informaci on del proceso, ejecutando el comando:
c r o s s m a k e j 2 V=1
Al nalizar el proceso de compilaci on obtenemos:

armnone e a b i l d EL p nou n d e f i n e d X o v m l i n u x T a r c h / arm / k e r n e l / v m l i n u x . l d s a r c h / arm / k e r n e l / h e a d . 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 g r o u p \ 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 / macha 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 \ lib / lib . 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 \ s o u n d / b u i l t i n . o n e t / b u i l t i n . o \ endg r o u p \ . tmp kallsyms2 . o
En la primera l nea de el listado anterior (arm-none-eabi-ld -EL -p no-undened -X -o vmlinux T arch/arm/kernel/vmlinux.lds) se realiza el proceso de enlace del archivo vmlinux, utilizando el script de enlace vmlinux.lds, incluyendo los objetos (archivos .o indicados en la lista. N otese que el primer archivo enlazado es head.o, el cual se genera a partir de arch/arm/kernel/head.S, y contiene rutinas de inicializaci on del kernel. Este proceso se explicar a detalladamente m as adelante. El siguiente objeto es init task.o, el cual establece estructuras de datos e hilos que utilizar a el kernel. A continuaci on se enlazan una serie de objetos con el nombre built-in.o, la ruta del archivo indica la funci on que realiza el objeto, por ejemplo el objeto arch/arm/mm/built-in.o realiza operaciones de manejo de memoria espec cas a la arquitectura arm. En la Figura 1.25 se muestran los componentes de la im agen vmlinux y un tama no de una compilaci on en particular que nos da una idea de la relaci on de tama nos. A continuaci on se realiza la descripci on de los componentes de la im agen del kernel vmlinux[16] 1. arch/arm/kernel/head.o C odigo de inicializaci on del kernel dependiente de la arquitectura. 2. init task.o Hilos y estructuras inicialies utilizadas por el kernel. 3. init/built-in.o C odigo de inicializaci on del kernel. 4. usr/built-in.o Im agen interna initramfs. 5. arch/arm/kernel/built-in.o C odigo del kernel espec co de la arquitectura. 6. arch/arm/mm/built-in.o C odigo de manejo de memoria espec co de la arquitectura. 7. arch/arm/common/built-in.o C odigo gen erico especico de la arquitectura. 8. arch/arm/mach-at91/built-in.o C odigo de inicializaci on espec co de la plataforma. 9. arch/arm/nwfpe/built-in.o Emulaci on de punto ot ante espec co de la arquitectura.
51
Figura 1.25: Componentes de la Imag en del kernel de Linux vmlinux 10. kernel/built-in.o C odigo de componentes com unes del kernel. 11. mm/built-in.o C odigo de componentes com unes de manejo de memoria. 12. ipc/built-in.o Comunicaci on 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 co 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.
52
Sistemas Embebidos
La im agen vmlinux generada tiene un tama no relativamente grande lo que la hace inconveniente para ser almacenada en un dispositivo Flash, por esta raz on se acostrumbra comprimirla. A continuaci on describiremos el proceso que se realiza para crear una im agen compatible con u-boot, el cargador de Linux m as utilizado para las plataformas embebidas. El primer paso para es reducir el tama no del ejecutable ELF vmlinux es eliminar la informaci on de depuraci on (notas y comentarios).
$ c r o s s m a k e j 3 v m l i n u x ( 4 . 4 MBytes ) $ armnone e a b i o b j c o p y O b i n a r y R . n o t e R . comment S v m l i n u x 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 continuaci on se comprime el archivo resultante utilizando la herramienta gzip, como resultado obtenemos un archivo de 1.6M, la tercera parte del archivo original.
1.5.
Inicializaci on del kernel
Como se mencion o anteriormente, el SoC AT91RM9200, posee un programa residente en una peque na ROM interna que revisa los controladores de memorias ash en busca de un programa v alido. 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 ejecuci on de aplicaciones cuando se energiza nuestra plataforma.
Figura 1.26: Flujo de ejecuci on en la inicializaci on de plataforma ECB AT91 La primera aplicaci on en ejecutarse es el loader de Darrel 27 . Debido a que la RAM interna del AT91RM9200 es de tan solo 16kBytes, es necesario utilizar otra aplicaci on para poder cargar el loader de Linux U-boot en la memoria SDRAM externa (con capacida de de 32Mbytes). Recordemos que incialmente el SoC no posee ninguna aplicaci on v alida en la memoria DataFlash, por lo que el programa interno de inicializaci on dara comienzo a una comunicaci on Xmodem, para que se descargue una aplicaci on a la memoria RAM interna utilizando el puerto de depuraci on serial a una velocidad de 115200 baudios.
27 Originalmente
creado por Darrel Harmon: http://dlharmon.com/
53
1.5.1.
Darrels Loader
Esta aplicaci on permite congurar la memoria externa SDRAM, congurar el puerto serie, implementar un protocolo xmodem que permita transferir aplicaciones a la memoria SDRAM, controlar la memoria DataFlash y almacenar aplicaciones en ella. El loader de Darrel est a basado en u-boot, es una versi on nicamente las operaciones mencioandas anteriormente, lo que resulta en un reducida de este y permite u archivo adecuado para ser almacenado en la memoria RAM interna (9.3 kBytes). Es interesante analizar esta aplicaci on, ya que esta se ejecuta sin ning un soporte de sistema operativo, lo que lo hace interesante para plataformas en las que no se puede ejecutar Linux. Su c odigo fuente lo podemos descargar utilizando el siguiente comando:
$ s v n co h t t p : / / s v n . a r h u a c o . o r g / s v n / s r c / e m q b i t / ECB AT91 V2 / d a r r e l l l o a d e r /
La estructura del c odigo fuente se muestra en el siguiente listado:

| | | | | | | | include | asm | | a r c h | | p r o c | p r o c armv l i n u x | b y t e o r d e r mtd src
Antes de estudiar el c odigo fuente demos un vistazo al archivo Makele para ver el proceso de compilaci on. De ella podemos extraer las partes m as interesantes: Los objetos que hacen parte del ejecutable, el proceso de enlazado, y la creaci on del archivo a descargar en la plataforma:
AOBJS = COBJS = LDSCRIPT : = LDFLAGS += OBJCFLAGS += TEXT BASE = loader : src / s t a r t . o / / ASSEMBLER OBJECTS s r c / b o a r d . 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 i v 0 . o s r c / i n t e r r u p t s . o ub o o t . l d s B s t a t i c T $ ( LDSCRIPT ) T t e x t $ ( TEXT BASE ) gap f i l l =0 x f f 0 x00000000 $ ( AOBJS ) $ ( COBJS ) $ ( LDSCRIPT ) $ (LD) $ (LDFLAGS) $ ( AOBJS ) $ ( COBJS ) \ s t a r t g r o u p $ ( PLATFORM LIBS ) endg r o u p \ Map l o a d e r . map o l o a d e r loader $ ( OBJCOPY ) $ {OBJCFLAGS} O b i n a r y $< $@
loader . bin :
Como podemos observar, esta aplicaci on esta compuesta por el c odigo en ensamblador src/start.S y el c odigo en C src/board.c src/serial.c src/xmodem.c src/dataash.c src/div0.c src/interrupts.c. Para generar el ejecutable loader (en formato ELF), encadenamos los objetos AOBJS y COBJS utilizando el script de enlazado u-boot.lds. A continuaci on se muestra el comando ejecutado por las herramientas de compilaci on al crear el ejecutable loader
arm e l f l d B s t a t i c T ub o o t . l d s T t e x t 0 x00000000 s r c / s t a r t . o s r c / b o a r d . 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 i v 0 . o s r c / i n t e r r u p t s . o s t a r t g r o u p nowarnm i s m a t c h 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 endg r o u p Map l o a d e r . map o l o a d e r
54 A continuaci on 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 ) ; . text : { src / s t a r t . o (. text ) }
Sistemas Embebidos
(. text )
. = ALIGN ( 4 ) ; . rodata : { (. rodata ) } . = ALIGN ( 4 ) ; . data : { (. data ) } . = ALIGN ( 4 ) ; . got : { ( . got ) } . = ALIGN ( 4 ) ; bss start = .; . bss : { ( . bss ) } end = . ; }
Este archivo indica que la primera direcci on del ejecutable es la 0x0 y que la primera instrucci on en ejecutarse (denida por ENTRY ) se encuentra en el s mbolo start denida en el archivo start.S; por otro lado, este script de enlazado nos informa que las secciones .text .rodata .data .got y .bss ser an incluidas en el ejecutable y se encuentran en la misma regi on de memoria (lo que era de esperarse ya que solo tenemos la memoria interna RAM). crt0.S (startup.S) Cuando se crea un ejecutable para ser utilizado en una plataforma espec ca, es necesario incluir el archivo crt0.S (C runtime startup code). Este archivo contiene el punto de entrada start y est a encargado de las siguientes funciones: 1. Inicilizaci on de las pilas (stacks). 2. Copiar el contenido de la secci on .data (datos inicializados) de la memoria no vol atil. 3. Inicializar la secci on .bss 4. Hacer el llamado al punto de entrada main ( start armboot para el Darrels loader) Y esta compuesto por: 1. vectors Tabla de vectores de excepciones. Deben estar colocados en la direcci on 0x0000.
55
2. reset handler Esta funci on maneja el reset , y es el punto de entrada principal de un ejecutable. Realiza operaciones de inicializaci on espec ca de la arquitectura. 3. undef handler Es el manejador de las instrucciones no denidas. 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. q handler Manejador de las FIQ (Fast Iterrupt Request). El archivo crt0.S es escrito en languaje ensamblador, y es fuertemente dependiente de la arquitectura, solo programadores expertos con un muy buen conocimiento de la arquitectura podr an escribirlo; sin embargo, los fabricantes proporcionan ejemplos de este tipo de archivos para que pueden ser utilizados sin tener 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 punto de entrada start armboot (ldr pc, start armboot) serial.c, xmpdem.c, dataash.c, div0.c, interrupts.c A continuaci on se realiza una descripci on de los archivos que hacen parte del loader de Darrel: serial.c: Inicializa y congura el puerto serial de depuraci on (DBGU) a uan velocidad ed 115200 baudios, 8 bits de datos, paridad, par. Adicionalmente proporciona las funciones: putc: Transmite un caracter por la interfaz serial de depuraci on. puts: Transmite una cadena de caracteres. getc: Recibe un caracter por la interfaz serial de depuraci on. xmodem.c: Implementa la recepci on serial utilizando elprotocolo xmodem. dataash.c: Inicializa el puerto SPI, y proporciona funciones de alto nivel para la escritura de la DataFlash. write dataash(addr dest, addr src, size) div0.c: Remplazo (dummy) del manejador divisi on por cero de GNU/Linux. interrupts.c: Proporciona funciones para el manejo de interrupciones e implementaci on de retardos. board.c El archivo board.c proporciona el punto de entrada start armboot y realiza las siguientes operaciones: Conguraci on del Controlador de manejo de potencia (PMC).
56 Hace un llamado a la incializaci on del puerto serie de depuraci on serial init() Congura la SDRAM externa try congure sdram Despliega un men u de funciones. Realiza las operaciones del men u.
Sistemas Embebidos
Una vez se carga el archivo loader.bin, el que resulta de quitarle al archivo ELF la informaci on de depuraci on 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 o b j c o p y 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 desplegar a el siguiente men u:

D a r r e l l s l o a d e r Thanks t o t h e ub o o t p r o j e c t V e r s i o n 1 . 0 . B u i l d J u l 29 2007 1 2 : 0 4 : 0 4 RAM: 3 2MB 1: 2: 3: 4: 5: 6: Upload D a r r e l l s Upload ub o o t t o Upload K e r n e l t o S t a r t ub o o t Upload F i l e s y s t e m Memory t e s t loader to Dataflash Dataflash Dataflash image
La opci on 1. del men u permite almacenar el archivo loader.bin en la memoria DataFlash, una vez hecho esto, el programa de inicializaci on almacenado en la memoria ROM interna lo ejecutar a cada vez que se reinicie la plataforma. Las opciones 2 y 3 son similares a la 1, solo que se cargan las aplicaciones en diferentes direcciones de memoria, observemos el c odigo 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 ub o o t . b i n v i a Xmodem\ n \ 0 ) ; l e n = rxmodem ( ( char ) 0 x20000000 ) ; AT91F DataflashInit ( ) ; dataflash print info (); 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 opci on 2, se despliega un mensaje indicandole al usuario que transmita el archivo u-boot.bin utilizando el protocolo xmodem, despu es se ejecuta la funci on rxmodem la que recibe los datos por el serial y lo almacena en la SDRAM externa (direcci on 0x20000000) y nalmente se almacena esta informaci on en la direcci on DATAFLASH UBOOT BASE. La opci on 4. del men u transere la ejecuci on
e l s e i f ( key == 4 | | ( ( s c a n s > 3 0 0 0 0 0 ) && a u t o b o o t ) ) { i f ( AT91F DataflashInit ()){ dataflash print info (); i f ( r e a d d a t a f l a s h ( DATAFLASH UBOOT BASE , 0 x1C000 , ( 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 Ub o o t \ n ) ; asm ( l d r pc , =0 x20700000 ) ; } } }
57
En esta opci on se copian 0x1C000 bytes del contenido de la memoria DataFlash comenzando en la posici on DATAFLASH UBOOT BASE a la direcci on de memoria 0x20700000 (SDRAM externa) y luego se carga el contador de programa con la direcci on 0x20700000, con lo que se inicia la ejecuci on del programa almacenado en la DataFlash, es importante hacer notar que el programa debe ser enlazado para que las secciones est en en la posici on de memoria donde ser an ejecutadas (0x20700000), no en la direcci on donde son almacenadas.
1.5.2.
U-boot
La opci on n umero 4 del men u copia el programa u-boot almacenado en la DataFlash a la memoria SDRAM y comienza su ejecuci on, en esta secci on se realizar a una descrici on del loader u-boot. U-boot es un bootloader que permite cargar archivos utilizando una gran variedad de perif ericos como: Puerto serie, Memoria SD, Memorias Flash Paraleas, seriales, NAND. NOR, Ethernet. Es cap az ltimo almacena de iniciar una variedad de tipos de archivos, adem as de un formato especial propio; este u informaci on sobre el tipo de sistema operativo, la direcci on de carga, el punto de entrada, vericaci on de integridad via CRC, tipos de compresi on, y textos descriptivos. La siguiente informaci on es desplegada cuando u-boot se inicializa una imagen del kernel de linux.
# # B o o t i n g image a t c0021840 . . . Image Name : L i n u x K e r n e l Image Image Type : ARM L i n u x K e r n e l Image ( g z i p c o m p r e s s e d ) Data S i z e : 1550369 B y t e s = 1 . 5 MB Load A d d r e s s : 20008000 E n t r y P o i n t : 20008000 V e r i f y i n g Checksum . . . OK U n c o m p r e s s i n g K e r n e l Image . . . OK
Para crear una im agen 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 d l i n u x . b i n . gz e c b a t 9 1 . img a 0 x20008000 e 0 x20008000 n L i n u x K e r n e l Image \
Ac a denimos ARM como arquitectura, linux como sistema operativo, Kernel como el tipo de im agen, gzip el m etodo de compresi on, 0x20008000 la direcci on de carga y punto de entrada (son iguales para kernels superiores al 2.3.X) Linux Kernel Image el nombre de la im agen linux.bin.gz el archivo de entrada y ecb at91.img el archivo de salida. Esta informaci on es almacenada en el encabezado de la im agen y 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 : Created : Image Type : Data S i z e : Load A d d r e s s : Entry Point : L i n u x K e r n e l Image F r i J u n 26 0 9 : 2 6 : 0 3 2009 ARM L i n u x K e r n e l Image ( g z i p c o m p r e s s e d ) 1550369 B y t e s = 1 5 1 4 . 0 3 kB = 1 . 4 8 MB 0 x20008000 0 x20008000
El siguiente listado muestra la estructura del envabezado denida por u-boot, en ella podemos obervar sus componentes y el tama no de cada uno de ellos.
typedef struct uint32 uint32 uint32 image header { t ih magic ; t ih hcrc ; t ih time ; / Image Header Magic Number / Image Header CRC Checksum / Image C r e a t i o n T i m e s t a m p / / /
58
uint32 uint32 uint32 uint32 uint8 t uint8 t uint8 t uint8 t uint8 t } image header t t t t ih ih ih ih ih ih ih ih ih size ; / load ; / ep ; / dcrc ; / os ; / arch ; / type ; / comp ; / n a m e [ IH NMLEN ] ; Image Data S i z e Data Load A d d r e s s Entry Point Address Image Data CRC Checksum Operating System CPU a r c h i t e c t u r e Image Type C o m p r e s s i o n Type / Image Name
Sistemas Embebidos
/ / / / / / / / /
t;
1.5.3.
Portando U-boot a la familia de plataformas ECB AT91

Es necesario modicar varios archivos para que u-boot soporte la familia de plataformas ECB AT91:
Makele Se le debe indicar a las herramientas de compilaci on la nueva plataforma, adicionando las siguientes l neas.
ecb at91 config : unconfig @$(MKCONFIG) $ (@: c o n f i g = ) arm a r m 9 2 0 t e c b a t 9 1 NULL a t 9 1 r m 9 2 0 0
MAKEALL Se debe agregar la siguiente entrada en el archivo MAKEALL:

LIST ARM9= \ a t 9 1 r m 9 2 0 0 d k cmc pu2 e c b a t 9 1
board/ecb at91/Makele En el directorio board/ecb at91 se alojan los archivos que dan soporte a la nueva arquitectura, el archivo de reglas de Conguraci on se muestra a continuaci on:
i n c l u d e $ ( TOPDIR ) / c o n f i g . mk LIB COBJS SRCS OBJS SOBJS = $ ( o b j ) l i b $ (BOARD ) . a : = $ (BOARD ) . o a t 4 5 . o f l a s h . o : = $ ( SOBJS : . o = . S ) $ ( COBJS : . o = . c ) : = $ ( a d d p r e f i x $ ( o b j ) , $ ( COBJS ) ) : = $ ( a d d p r e f i x $ ( o b j ) , $ ( SOBJS ) )
$ ( LIB ) : $ ( o b j ) . d e p e n d $ ( OBJS ) $ ( SOBJS ) $ (AR) $ (ARFLAGS) $@ $ ( OBJS ) $ ( SOBJS ) clean : rm f $ ( SOBJS ) $ ( OBJS )
59
distclean : clean rm f $ ( LIB ) c o r e . bak . d e p e n d # d e f i n e s $ ( obj ) . depend t a r g e t i n c l u d e $ ( SRCTREE ) / r u l e s . mk s i n c l u d e $ ( obj ) . depend
Este es el formato utilizado para todas las plataformas, la parte importante se encuentra en la denici on 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 ash.o: soporte gen erico para dispositivos ash28 . board/ecb at91/board.c Este archivo contiene toda la conguraci on espec ca de la plataforma, y como se puede ver en el siguiente listado, ja el n umero de la plataforma a: MACH TYPE ECBAT91 (1072 denida en include/asmarm/mach-types.h) y los par ametros del boot en: PHYS SDRAM + 0x100; (PHYS SDRAM = 0x20000000 est a denido en include/congs/ecb at91.h). Adicionalmente, inicializa la SDRAM, la interfaz de red y la memoria DataFlash.
# include # include # include # include <common . h> <asm / a r c h / AT91RM9200 . h> < a t 9 1 r m 9 2 0 0 n e t . h> < l x t 9 7 2 . h>
DECLARE GLOBAL DATA PTR ; / Miscelaneous platform dependant 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 / console init f (); / a r c h number o f ECB AT91 b o a r d / gd >bd >b i a r c h n u m b e r = MACH TYPE ECBAT91 ; / adress of boot parameters / gd >bd > b i b o o t p a r a m s = PHYS SDRAM + 0 x100 ; return 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 ; return 0; }
28 Estos archivos ecbat91.patch
pueden
ser
descargados
de:
http://svn.arhuaco.org/svn/src/emqbit/ECB AT91 V2/u-boot/u-boot-1.1.6-
60
Sistemas Embebidos
# i f d e f CONFIG DRIVER ETHER # i f (CONFIG COMMANDS & CFG CMD NET ) / Name : at91rm9200 GetPhyInterface Description : 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 Return value : None / v o i d 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 p h y o p s ) { p phyops >I n i t = l x t 9 7 2 I n i t P h y ; p phyops >I s P h y C o n n e c t e d = l x t 9 7 2 I s P h y C o n n e c t e d ; p phyops >G e t L i n k S p e e d = 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 AT91F DataflashMapInit ( void ) { s t a t i c i n t c s [ ] [ CFG MAX DATAFLASH BANKS] = { / L o g i c a l a d r e s 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 ] = { / define the dataflash 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 , Ub o o t } , {DATAFLASH ENV UBOOT BASE , DATAFLASH KERNEL BASE 1 , FLAG PROTECT CLEAR , E n v i r o n m e n t } , {DATAFLASH KERNEL BASE , DATAFLASH FILESYSTEM BASE 1 , FLAG PROTECT CLEAR , K e r n 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 ) ; } # endif
include/congs/ecb at91.h Este archivo contiene variables que son utilizadas para la inicializaci on de la plataforma, algunas de estas ellas denen el valor de registros de conguraci on de perif ericos como: El controlador del reloj del sistema, controlador de memorias SDRAM y memorias Flash.
Carlos Iv an Camargo Bare no A continuaci on se muestra un segmento de este archivo, en el que se dene 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 # d e f i n e AT91C MASTER CLOCK # d e f i n e AT91 SLOW CLOCK # define # define # define # undef # define CONFIG ARM920T CONFIG AT91RM9200 CONFIG ECB AT91 CONFIG USE IRQ USE 920T MMU 1 1 1 1 / e n a b l e p a s s i n g o f ATAGs /
61
180000000 60000000 32768 / / / / / slow c l o c k / / / / /
T h i s i s an ARM920T Core I t s an A t m e l AT91RM9200 SoC on an AT91RM9200DK Board we don t n e e d IRQ / FIQ s t u f f
# d e f i n e CONFIG CMDLINE TAG 1 # 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 tambi en incluye el valor predeterminado de las variables de entorno utilizadas por uboot:
# define # define # define # define # define # define # define # define # define # define 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 , 1 1 5 2 0 0 n8 r o o t d e l a y =1 CONFIG ETHADDR 00:00:00:00:00:5 b CONFIG NETMASK 255.255.255.0 CONFIG IPADDR 192.168.0.135 CONFIG SERVERIP 192.168.0.128 CONFIG BOOTDELAY 2 CONFIG BOOTCOMMAND bootm C0021840 CONFIG BOOTFILE e c b a t 9 1 . img CONFIG ROOTPATH / home / a t 9 1 / r o o t f s CONFIG LOADADDR 0 x20200000
La variable bootargs son par ametros pasados al kernel en su inicializaci on, y en este ejemplo ja la memoria RAM en 32 Mbytes, indica que el sistema de archivos se encuentra en el dispositivo /dev/mmcblk0p1 y utiliza el sistema de archivos ext3, la consola es el dispositivo serial /dev/ttyS0 congurado a una velocidad de 115200 baudios, bit de paridad y 8 bits de datos y que debe esperar 1 segundo para montar el sistema de archivos. Las variables ethaddr, netmask, ipaddr, serverip conguran la interfaz de red y las direcciones IP de la plataforma y de un servidor de donde puede descargarse la im agen del kernel. La variable bootdelay ja el n umero de segundos que esperar a u-boot para ejecutar el comando almacenado en bootcmd, este conteo puede detenerse para interactuar con u-boot. El comando bootm C0021840 (bootcmd) es utilizado para iniciar la im agen almacenada en la direcci on de memoria 0xC0021840 (direcci on donde almacena el loader de Darrel la im agen del kernel), bootm utiliza la informaci on almacenada en el encabezado de la im agen para utilizar el m etodo de descompresi on adecuado, almacenarlo en la direcci on requerida y pasarle los par ametros 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 m u s t h a v e 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 + ub o o t e n v ) / # d e f i n e DATAFLASH MAX PAGESIZE 1056 # d e f i n e DATAFLASH LOADER BASE ( 0 DATAFLASH MAX PAGESIZE )
62
# define # define # define # define DATAFLASH UBOOT BASE DATAFLASH ENV UBOOT BASE DATAFLASH KERNEL BASE DATAFLASH FILESYSTEM BASE ( 1 2 DATAFLASH ( 1 2 2 DATAFLASH ( 1 3 0 DATAFLASH ( 1 6 6 4 DATAFLASH MAX MAX MAX MAX PAGESIZE ) PAGESIZE ) PAGESIZE ) PAGESIZE )
Sistemas Embebidos
Compilaci on de U-boot en la familia de plataformas ECB AT91 A continuaci on se indican los pasos necesarios para generar el archivo u-boot.bin que ser a almacenado en la memoria DataFlash por el loader de Darrel. El primer paso es obviamente descargar el c odigo fuente de la versi on 1.1.6 de http://sourceforge.net/projects/uboot/, despu es debemos descargar el patch que da soporte a la familia de plataformas ECB AT91:
$ wget h t t p : / / s v n . a r h u a c o . o r g / s v n / s r c / e m q b i t / ECB AT91 V2 / ub o o t / ub o o t 1.1.6 e c b a t 9 1 . p a t c h $ t a r x j f ub o o t 1 . 1 . 6 . t a r . bz2 $ cd ub o o t 1 . 1 . 6
Aplicamos el patch
$ cat . . / ub o o t 1.1.6 e c b a t 9 1 . p a t c h | p a t c h p1
Conguramos y generamos las herramientas utilizadas por u-boot (entre ellas mkimage).
$ make e c b a t 9 1 c o n f i g Configuring for ecb at91 board . . . $ make t o o l s ( E s t e e s un c o m e n t a r i o )
ltimo compilamos u-boot: Por u

$ make ARCH=arm CROSS COMPILE=armnone e a b i o definido ) crossmake ( s i e l a l i a s crossmake e s t a
Si el proceso se sigui o correctamente y no se presentan errores al nal del proceso obtenemos el mensaje:
armnone e a b i o b j c o p y gap f i l l =0 x f f O s r e c ub o o t ub o o t . s r e c armnone e a b i o b j c o p y gap f i l l =0 x f f O b i n a r y ub o o t ub o o t . b i n
Lo que nos indica que se gener o exitosamente el archivo u-boot.bin, que puede ser descargado utilizando la opci on 2 del men u del loader de Darrel (Upload u-boot to Dataash) y el protocolo xmodem. Podemos vericar que el archivo fu e generado y almacenado en la Dataash podemos ejecutar la opci on n umero 4 del men u del loader de Darrel (Start u-boot), como se mencion o anteriormente esta opci on copia el archivo u-boot desde la DataFlash a la memoria SDRAM y es ejecutado desde alli, con lo que se desplegar a 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 Ub o o t UBoot 1 . 1 . 6 ( J u l 29 2007 1 2 : 1 2 : 3 8 ) DRAM: 32 MB Atmel : F l a s h : 0 kB D a t a F l a s h : AT45DB161 Nb p a g e s : 4096 Page S i z e : 528 S i z e = 2162688 b y t e s

L o g i c a l a d d r e s s : 0 xC0000000 Area 0 : C0000000 t o C000317F (RO) Area 1 : C0003180 t o C001F73F (RO) Area 2 : C001F740 t o C002183F Area 3 : C0021840 t o C01ACFFF Area 4 : C01AD000 t o C020FFFF (RO) In : serial Out : serial Err : serial PHY 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
63
Darrell loader Ub o o t Environment Kernel Filesystem
Si se presiona cualquier tecla antes de que el contador llegue a 0, podemos interactuar con u-boot, si ejecutamos el comando print (Despliega en pantalla las variables de entorno denidas):
bootcmd =bootm C0021840 b o o t d e l a y =2 b a u d r a t e =115200 ethaddr =00:00:00:00:00:5 b ipaddr =192.168.0.135 serverip =192.168.0.128 r o o t p a t h = / home / a t 9 1 / r o o t f s netmask =255.255.255.0 b o o t f i l e = e c b a t 9 1 . img l o a d a d d r =0 x20200000 b 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 , 1 1 5 2 0 0 n8 r o o t d e l a y =1 stdin=serial stdout= serial stderr=serial Environment s i z e : 345/8188
Podemos cambiar el valor predeterminado de la variable bootdelay a 1:

ecb at91> setenv bootdelay 1
Y almacenamos los cambios realizados en una secci on de la ash reservada para este n con el comando:
ecb at91> save Saving Environment to 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 , 1 1 5 2 0 0 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 i m e o =200 , r e t r a n s =500 i p = : : : : : e t h 0 : on ecb at91> save
1.5.4.
Almacenamiento de la im agen del kernel
Una vez creada la im agen del kernel (ecb at91.img) con el formato de U-boot debemos probar su correcto funcionamiento; esto lo podemos hacer de dos formas: Almacenandola directamente en una memoria no vol atil o carg andola en la memoria RAM y ejecut andola desde all .
64 Almacenamiento en la memoria DataFlash
Sistemas Embebidos
Cuando almacenamos la im agen del kernel de Linux a un medio de almacenamiento no vol atil, debemos tener presente que los ciclos de borrado y escritura de este toman un tiempo mucho mayor que en el caso de las memorias no vol atiles, por esto, se recomienda esta opci on cuando ya se cuente con una im agen 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 Rees de observar el set disponible en todas las plataformas de la familia ECB AT91. Inmediatamente despu men u del loader debemos oprimir cualquier tecla para interrumpir la ejecuci on autom atica del u-boot. Seleccionando la opci on del men u: 3: Upload linux to Dataash, podemos iniciar la transferencia de la im agen 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 Xmodem R 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 protocolo xmodem. Unos minutos despu es la transferencia naliza, sin embargo, debemos esperar a que la informaci on sea almacenada en la memoria DataFlash, mientras se completa la escritura la consola no mostrar a ninguna actividad, eso es normal y no se debe reiniciar la board. Una vez nalizada la escritura observaremos el mensaje:
%%%%%%%%%%%%%%%%%%%%%
Almacenamiento en la memoria RAM El proceso de grabaci on en la memoria DataFlash puede tomar alrededor de 6 minutos, lo que no lo hace conveniente cuando se est a tratando de crear una imagen propia o se est an realizando cambios a la misma. Cuando necesitamos modicar esta im agen ya sea porque queremos hacerlo nosotros mismos o porque deseamos una versi on de kernel m as moderna, es preferible utilizar un m etodo de transferencia m as r apido. La plataforma ECB AT91 posee una interfaz de red que puede ser controlada por u-boot. Utilizando el protocolo tftp U-boot puede descargar la im agen desde un servidor a la memoria SDRAM y ejecutarla desde all , ese proceso se realiza en segundos, facilitando de esta forma el proceso de desarrollo. A continuaci on se desciben los pasos que deben seguirse para realizar esta operaci on: Primero debemos instalar y congurar el servidor tftp en el computador donde se tiene las herramientas de desarrollo:
$ aptitude install tftpd tftp .
Se debe agregar la siguiente l nea al archivo /etc/inetd.conf

tftp dgram udp wait nobody / usr / sbin / tcpd / usr / sbin / in . t f t p d / srv / t f t p
Debe asegurarse que el protocolo tftp utiliza el puerto UDP 69

$ cat / etc / s e r v i c e s | grep t f t p tftp 6 9 / udp
l: Ahora creamos el directorio /srv/tftp29 y colocamos la imagen en e

29 Este
l directorio tiene restricciones de seguridad, debe contactarse con el administrador de su equipo para permitir el acceso a e
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 vericar la correcta conguraci on 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 r t f t p > g e t e c b a t 9 1 . img R e c e i v e d 1319525 b y t e s i n 0 . 2 s e c o n d s tftp > quit
Ahora se deben congurar algunas variables de entorno en nuestra plataforma para indicarle a u-boot la direcci on IP, el nombre y la ubicaci on de la im agen del kernel. Estas variables deben ser modicadas para que contengan los siguientes valores:
l o a d a d d r =0 x20200000 b o o t d e l a y =1 b o o t f i l e = e c b a t 9 1 . img f i l e a d d r =20200000 gatewayip =192.168.0.1 netmask =255.255.255.0 serverip =192.168.0.128
Estas variables jan la direcci on IP de: la plataforma a 192.168.0.2, del gateway a 192.168.0.1, la del servidor tftp a 192.168.0.12830 . Adicionalmente dene el nombre de la im agen del kernel a ecb at91.img. Una vez congurado U-boot podemos descargar la im agen a la direcci on de memoria 0x20200000:
ecb at91 >t f t p TFTP from s e r v e r 1 9 2 . 1 6 8 . 0 . 1 ; o u r I P a d d r e s s i s 1 9 2 . 1 6 8 . 0 . 2 F i l e n a m e e c b a t 9 1 . img . Load a d d r e s s : 0 x20200000 L o a d i n g : ################################################################# ################################################################# ################################################################# ################################################################# ################ done B y t e s t r a n s f e r r e d = 1409031 ( 1 5 8 0 0 7 hex ) ecb at91 >
1.5.5.
Inicializaci on del Kernel

En general los cargadores de Linux como el u-boot realizan las siguientes funciones:
Congurar e inicializar la RAM Inicializar un puerto serial Detectar el tipo de m aquina: El boot loader debe proporcionar un valor MACH TYPE XXX al kernel, como vimos anteriormente tanto u-boot como Linux jan este valor a 1072.
30 Direcci on
IP del PC donde est an las herramientas de desarrollo
66
Sistemas Embebidos Congurar la kernel tagged list: El boot loader debe crear e inicializar una estructura llamada kernel tagged list, al cual comienza con ATAG CORE y naliza con ATAG NONE. El tag ATAG CORE puede o no estar desocupado, si se encuentra desocupado debe jar el campo size en 2. El campo size del tag ATAG NONE debe jarse en 0. Se pueden denir cualquier n umero de tags, pero se deben denir por lo menos el tama no y la localizaci on de la memoria del sistema, y la localizaci on del sistema de archivos. Esta tagged list debe ser almacenada en RAM, en una regi on que no pueda ser modicada por el descompresor del kernel o por el programa initrd. Se recomienda colocarlo en los primeros 16kBytes de la RAM. Hacer un llamado a la im agen del kernel: Existen dos formas de hacer este llamado, directamente desde la ash o en en cualquier posici on de la RAM. Los dos m etodos deben cumplir las siguientes condiciones: Desactiva los dispositivos que tienen capacidad de DMA, de tal forma que la memoria no se corrompa. Fijar los registros de la CPU: r0 = 0, r1 = t po de m aquina, r2 = direcci on f sica de la tagged list en RAM. Modo de la CPU: Deshabilitar todas las interrupcione (IRQs y FIQs) y colocar a la CPU en modo SVC Caches, MMU: Debe estar desactivada la MMU, La cache de instrucci ones puede estar activada o desactivada, la cache de datos debe estar desactivada.
Llamado a la Im agen del kernel Como mencionamos anteriormente, u-boot ejecuta las instrucciones almacenadas en la variable de entorno bootcmd; que para la familia de plataformas ECB AT91 almacena el comando bootm C0021840, esta instrucci on le indica a u-boot que ejecute el comando bootm con una im agen almacenada en la posici on de memoria 0xC0021840, en la que (como mencionamos anteriormente (Figura 1.26)) se almacena la im agen del kernel. El c odigo 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 im agen del kernel (la que almacenamos utilizando la opci on 3 del loader de Darrel). La funci on do bootm realiza las siguientes operaciones: Vericar la existencia de un n umero m agico en los primeros 4 bytes de la im agen (0x27051956). Si no se encuentra este n umero se desplegar a el mensaje: Bad Magic Number Verica la integridad del encabezado de la im agen. De no pasar esta prueba se mostrar a el mensaje: Bad Header Checksum. Imprime el encabezado de la im agen, aparecer a algo como: C alcula el CRC del archivo almacenado y lo compara con el almacenado en la cabecera de la im agen. Si no se supera esta prueba, se desplegar a el mensaje: Bad Data CRC Comprueba que la arquitectura est a soportada por u-boot. Descomprime la im agen almacenada en la direcci on load address (la cual se pasa como par ametro en el momento de la creaci on de la im agen). Transferir el control a Linux en la funci on do bootm linuxU-boot es un loader que permite trabajar con: LYNXOS, RTEMS, VXWORKS, QNX, ARTOS, NETBSD
67
La funci on 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 Informaci on de la plataforma de desarrollo:

typedef struct bd info { int bi baudrate ; / s e r i a l baudrate / unsigned long bi ip addr ; / IP A d d r e s s / u n s i g n e d char bi enetaddr [ 6 ] ; / Ethernet adress / struct environment s bi env ; ulong b i a r c h n u m b e r ; / i d f o r t h i s board / ulong b i b o o t p a r a m s ; / b o o t params / struct / RAM c o n f i g u r a t i o n / { ulong s t a r t ; ulong 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 memoria RAM, el sistema es almacenado en alg un medio no vol atil y despu es es descomprimido en la RAM, esto acelera la ejecuci on ya que como se mencion o anteriormente, el acceso a las memorias vol atiles es mucho menor. initrd start - initrd end indican el inicio y n de este archivo cmd start - cmd end: Posici on de memoria donde se almacenan los par ametros 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 lo m as atractivo de u-boot es su capacidad para manejar diferentes dispositivos de almacenamiento no vol atiles como Memorias Flash, memorias SD y su capacidad para manejar interfaces de red y permitir utilizarlas para al carga de im agenes del kernel. Punto de Entrada del Kernel head.o Como puede verse en 1.25 el primer archivo encadenado en la im agen del kernel es arch/arm/kernel/head.o, y corresponde al punto de entrada del kernel de Linux, este archivo ejecuta las siguientes funciones: 1. Vericar que la arquitectura y el procesador sean v alidos. Si el procesador no es v alido se generar a un error y en la consola aparecer a una p, si la plataforma no corresponde se genera un error y se imprimir a una a en la consola. 2. Se genera una estructura de datos (page table) que almacena el mapeo entre las direcciones de memoria virtual y la memoria f sica. Antes de pasar el control al kernel, el procesador corre un un modo real, en el que las direcciones corresponden a direcciones reales de los dispositivos conectados f sicamente al procesador. 3. Activa la unidad de manejo de memoria (MMU) del procesador. Cuando se activa la MMU el esquema de memoria f sico se remplaza por un direccionamiento virtual determinado por los desarrolladores del kernel.
68 4. Establece un limitado mecanismo de detecci on y reporte de errores. 5. Hace un llamado a la funci on start kernel en init/main.c
s e t u p a r c h (& c o m m a n d l i n e ) ; setup command line ( command line ) ; sched init (); preempt disable ( ) ; page alloc init (); console init (); mem init ( ) ; kmem cache init ( ) ; setup per cpu pageset (); numa policy init (); calibrate delay (); pidmap init ( ) ; pgtable cache init (); prio tree init (); anon vma init ( ) ; f o r k i n i t ( num physpages ) ; proc caches init (); buffer init (); unnamed dev init ( ) ; key init (); security init (); v f s c a c h e s i n i t ( num physpages ) ; radix tree init (); signals init (); page writeback init (); proc root init (); cgroup init (); cpuset init (); taskstats init early (); delayacct init (); acpi early init (); schedule ( ) ; preempt disable ( ) ;
Sistemas Embebidos
ltimos pasos en el proceso de arranque de Linux, se libera la memoria que ser En los u a utilizada por los procesos de inicializaci on, abre un dispositivo que permita la interacci on con el usuario /dev/console (consola serial en nuestro caso) y ejecuta el primer proceso en espacio de usuario init. El siguiente listado ltima fase del proceso de arranque. muestra el c odigo que implementa esta u
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 ) { free initmem ( ) ; unlock kernel ( ) ; mark rodata ro ( ) ; s y s t e m s t a t e = SYSTEM RUNNING ; numa default policy ( ) ; 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 ) sys dup ( 0 ) ; ( void ) sys dup ( 0 ) ; i f ( ramdisk execute command ) { r u n i n i t p r o c e s s ( ramdisk 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 \n ,

ramdisk execute command ) ; } / We t r y e a c h 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 u s e d i n s t e a d o f i n i t i f we a r e 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. Attempting d e f a u l t s . . . \ n , execute command ) ; } run init process ( / sbin / i n i t ) ; run init process ( / etc / i n i t ); r u n i n i t p r o c e s s ( / bin / i n i t ) ; r u n i n i t p r o c e s s ( / bin / sh ) ; p a n i c ( No i n i t f o u n d . } 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 . ) ;
69
ltimo p Como podemos obsever el u aso consiste en el llamado a un archivo en espacio de usuario llamado init o sh, en la siguiente subsecci on se describir a las acciones que se realizan cuando se ejecuta este archivo. De no encontrarse se desplegar a el mensaje No init found. Try passing init= option to kernel. y la plataforma pasar a a un estado de inactividad.
1.6.
Inicializaci on del Sistema
En esta secci on describiremos el proceso de inicializaci on de la plataforma embebida, en la secci on anterior se estudi o la inicializaci on del kernel de Linux. En esta secci on se realizar a una descripci on del sistema de archivos que contiene aplicaciones que Linux requiere para inicializar servicios como los de red y la consola, cargar drivers (m odulos) de dispositivos y montar sistemas de archivos adicionales.
1.6.1.
Sistema de Archivos
Anteriormente hemos hecho referencia a la localizaci on de la ra z del sistema de archivos (root), e indicamos que est a se encuentra en una determinada memoria no vol atil, estamos indicando donde se encuentra el nivel m as alto del sistema de archivos, el cual se denota como /. Existen varias opciones entre las que se encuentran: Second Extended File System (ext2) : Este sistema de archivos utiliza bloques como unidad de almacenamiento b asico, inodes como medio para mentener un seguimiento de archivos y objetos de sistema, grupos de bloques para dividir l ogicamente el disco en secciones m as menejables, directorios para proporcionar una organizaci on jer arquica de archivos, bloques y mapas de bits (bitmap) de bloques e inodes para mantener un seguimiento de bloques e inodes asignados, y superbloques para denir los par ametros del sistema de archivos y su estado general. Adicionalmente posee la capacidad de crear enlaces simb olicos, un tipo especial de archivo que contiene la referencia a otro archivo o directorio. Third Extended File System (ext3): ext3 es una extensi on del sistema de archivos ext2 con capacidades de journaling. El Journaling es utilizado para seguir cambios de archivos y tiene como
70
Sistemas Embebidos prop osito asegurar que las transacciones sean procesadas de forma adecuada; adicionalmente permite arreglar da nos en el sistema de archivos originados por una falla en la fuente de alimentaci on de la plataforma. ReiserFS: Este sistema de archivos al igual que ext3 utiliza journaling. Fu e creado con el f n de aumentar el desempe no frente al sistema ext2, es un sistema eciente en espacio, y mejora el manejo de grandes directorios. Journalling FIle FLash System 2 (JFFS2): Sistema creado para trabajar con dispositivos Flash, los cuales son utilizados ampliamente en aplicaciones embebidas. Compresed ROM le system (cramfs): Sistema de solo lectura, es utilizado cuando se dispone de una peque na memoria ash NOR. El m aximo tama no de cramfs es de 256MB. Los archivos en este sistema de archivos se encuentran comprimidos. Network File System: Permite montar particiones de disco o directorios de sistemas remotos como un sistema de archivos local, esto permite compartir recursos como unidades de CDs, DVDs u otro medio de almacenamiento masivo. Por otro lado, reduce el tiempo de desarrollo ya que no es necesario transferir archivos entre el sitio donde se encuentran las herramientas de desarrollo y la plataforma. Pseudo File System Este sistema de archivos es utilizado por Linux para representar el estado actual l podemos endel kernel. Este sistema de archivos est a montado en el directorio /proc, y dentro de e contrar informaci on detallada del hardware del sistema. Adicionalmente algunos archivos pueden ser manipulados para informar al kernel cambios en la conguraci on. Este sistema de archivos es virtual y es constantemente actualizado por el kernel. Los archivos /proc/cpuinfo, /proc/interrupt, /proc/devices, /proc/mounts Proporcionan informaci on 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 utilizado en los sistemas operativos UNIX. Este standard permite que los programas y los usuarios conozcan de antemano la localizaci on de los archivos instalados. Los siguientes directorios o links simb olicos son de uso obligatorio: 1. bin Ejecutables esenciales. 2. boot Archivos est aticos del boot loader. 3. dev Archivos de dispositivos. 4. etc Conguraci on espec ca del host. 5. lib Librer as esenciales y m odulos 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
Carlos Iv an Camargo Bare no 10. srv Datos de servicios suministrados por el sistema. 11. tmp Archivos temporales. 12. usr Segunda jerarqu a. 13. var Datos variables.
71
1.6.2.
Primer Programa en Espacio de Usuario init
Como vimos anteriormente, la primera aplicaci on en espacio de usuario que ejecuta el kernel es l y es /sbin/init, todos los procesos que no sean del kernel son generados de forma directa o indirecta por e responsable de la inicializaci on de los scripts y terminales. Su papel m as importante es generar procesos adicionales bajo la direcci on de un archivo de congraci on especial /etc/inittab Modos de operaci on Existen dos modos de operaci on en Linux: Modo usuario simple y Multi-usuario, en el primero nico usuario que puede utilizarla es el super-usuario root; es solo se activa una l nea de comandos y el u utilizado para sistemas en mantenimiento y normalmente se le asigna el nivel de ejecuci on 1. En este nivel de ejecuci on, no existen procesos demonios32 en ejecuci on, y la interfaz de red no est a congurada[20]. El modo multi-usuario es el modo normal de ejecuci on del sistema Linux, cuando Linux inicia en este 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 ejecuci on Ejecuta los scripts asociados con este nivel de ejecuci on. Inicializa los demonios. Permite el acceso a usuarios. Niveles de ejecuci on Un nivel de ejecuci on puede entenderse como un estado del sistema Hoy d a, la mayor a de las distribuciones utilizan los siguientes niveles de ejecuci on[20]: 1. 0. Cierre o detenci on del sistema (halt). 2. 1. Modo usuario simple para conguraci on del sistema y mantenimiento. 3. 2. Modo multi-usuario sin red remota.
32 Proceso
que se ejecuta de forma discreta sin intervenci on del usuario y es activado por la ocurrencia de una condici on espec ca
72
Sistemas Embebidos 4. 3. Modo multi-usuario con red. Este es el modo de operaci on normal de un usuario de un sistema sin capacidades gr acas. 5. 4. No utilizado - Denido por el usuario. 6. 5. Modo multi-usuario con interf az gr aca. 7. 6. Re-inicializaci on del sistema (reboot).
El nivel de ejecuci on pude ser cambiado por el super-usuario (root) en cualquier momento utilizando el comando init n, donde n es el nivel de ejecuci on deseado. El Archivo /etc/inittab Como se mencion o anteriormente el programa init est a encargado de montar el sistema de archivos y de analizar el archivo /etc/inittab. Este archivo contiene: Una entrada para el nivel de ejecuci on por defecto. Nivel de ejecuci on en que inicia el sistema a menos que especique otra cosa en el boot loader. Entradas que deben ser ejecutadas en todos o en un espec co nivel de ejecuci on, su sint axis es: id:runlevels:action:process [arguments] id Cualquier cosa. runlevels Puede ser un n umero o lista de n umeros de 0 a 6. action Acci on a tomar: respawn El proceso debe ser re-iniciado una vez nalice. wait start Ejecuta el proceso cuando se ingresa al nivel de ejecuci on y espera por su terminaci on. bootwait El proceso debe ser ejecutado durante la incializaci on del sistema. initdefault Especica el nivel de ejecuci on al que se ingresa despu es de la inicializaci on del sistema. sysinit El proceso debe ejecutarse durante la inicializaci on 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 . id : 5 : i n i t d e f a u l t : # Boot t i m e s y s t e m 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 . # T h i s i s r u n f i r s t e x c e p t when b o o t i n g i n e m e r g e n c y ( b ) mode . s i : : s y s i n i t : / e t c / i n i t . d / rcS # What t o do i n s i n g l e u s e r mode . : S : wait : / sbin / sulogin # / 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 c h a n g e # of r u n l e v e l .

l0 : 0 : wait : / etc / i n i t . d / rc 0 l1 : 1 : wait : / etc / i n i t . d / rc 1 l2 : 2 : wait : / etc / i n i t . d / rc 2 l3 : 3 : wait : / etc / i n i t . d / rc 3 l4 : 4 : wait : / etc / i n i t . d / rc 4 l5 : 5 : wait : / etc / i n i t . d / rc 5 l6 : 6 : wait : / etc / i n i t . d / rc 6 # Normally not reached , but f a l l t h r o u g h i n case of emergency . z6 : 6 : r e s p a w n : / s b i n / s u l o g i n S : 2 3 4 5 : r e s p a w n : / s b i n / g e t t y 115200 t t y S 0 # / sbin / getty invocations for the r u n l e v e l s . 1 : 2 3 4 5 : r e s p a w n : / s b i n / g e t t y 38400 t t y 1
73
En este archivo se dene el nivel de ejecuci on 5 como el nivel por defecto. El primer script en ejecutarse es /etc/init.d/rcS (ya que su acci on es del tipo sysinit). Luego se ingresa al nivel de ejecuci on 5 y se ejecuta el script /etc/init.d/rc pas andole 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 un entero 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 num ericos: S[0-9][0-9], S[09][0-9]. Un script t pico de inicializaci on del demonio del servidor web cherokee se muestra en el siguiente listado (/etc/rc5.d/S91cherokee):
# ! / bin / sh DAEMON= / u s r / s b i n / c h e r o k e e CONFIG = / e t c / c h e r o k e e / c h e r o k e e . c o n f PIDFILE = / v a r / r u n / c h e r o k e e . p i d NAME= c h e r o k e e DESC= C h e r o k e e 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 e t e s t x $DAEMON | | e x i t 0 t e s t ! r $CONFIG && e x i t 0 c a s e $1 i n start ) e c h o S t a r t i n g $DESC : s t a r t s t o p daemon oknodo S x $DAEMON b C $CONFIG ;; stop ) e c h o S t o p p i n g $DESC : s t a r t s t o p daemon K p $PIDFILE ;; restart ) $0 s t o p >/ dev / n u l l 2>&1 $0 s t a r t ;; ) e c h o Usage : $0 { s t a r t | s t o p | r e s t a r t } exit 0 ;; esac
Como podemos ver existen tres par ametros que podemos pasar al script: start, stop y restart, cuyas acciones son iniciar, detener y reiniciar el demonio respectivamente. El directorio /etc/init.d contiene todos los scripts utilizados en los diferentes niveles de ejecuci on, el nombre de ellos en este directorio no incluyen
74 los caracteres S[0-9][0-9] o K[0-9][0-9].
Sistemas Embebidos
La l nea S:2345:respawn:/sbin/getty 115200 ttyS0 inicia una consola por el puerto serial /dev/ttyS0 con una velocidad de 9200 baudios, cuando el nivel de ejecucion sea 2, 3, 4 o 5. Finalmente se crea una terminal virtual para los niveles de ejecuci on multi-usuario. nicos al Cuando el super-usuario cambia el nivel de ejecuci on con el comando init, los procesos u nicos del nuevo nivel son iniciados. nievel anterior son terminados y los procesos u
1.6.3.
Distribuciones Linux
Aunque es posible construir el sistema de atchivos nosotros mismos, no es nada pr actico ya que es una tarea tediosa que requiere cierto nivel de experiencia. En la actualidad, existen varias distribuciones que realizan estas tareas por nosotros, dentro de las m as utilizadas se encuentran:
Busybox Dise nado para optimizar el tama no y rendimiento de aplicaciones embebidas, BusyBox 33 combina en un solo ejecutable m as de 70 utilidades est andares UNIX, en sus versiones ligeras. BusyBox es considerada la navaja suiza de los sistema embebidos, dado que permite sustituir la gran mayor a de utilidades que se suelen localizar en los paquetes GNU leutils, shellutils, ndutils, textutils, modutils, grep, gzip, tar, etc. Busybox hace parte de la mayor a de distribuciones de Linux para sistemas embebidos y en la actualidad 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, delgroup, deluser, df, dirname, dmesg, dos2unix, dpkg, dpkg-deb, du, dumpkmap, dumpleases, echo, egrep, env, expr, false, fbset, fdush, fdisk, fgrep, nd, fold, free, freeramdisk, fsck.minix, ftpget, ftpput, getopt, getty, grep, gunzip, gzip, halt, head, hexdump, hostid, hostname, httpd, hwclock, id, ifcong, 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, mkfo, 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 Makeles y patches que facilita la generaci on de la cadena de herramientas y el sistema de archivos para un sistema embebido que usa Linux. Posee una interfaz que permite realizar de forma f acil la conguraci on; utiliza busybox para generar la utilidades b asicas de Linux y permite adaptar software adicional de forma f acil 35 .
33 http://www.busybox.net/ 34 http://buildroot.uclibc.org/ 35 http://buildroot.uclibc.org/buildroot.html#add
software
Carlos Iv an Camargo Bare no Openembedded
75
Al igual que Buildroot, el proyecto openembedded proporciona un entorno que permite generar la cadena de herramientas y el sistema de atchivos para un sistema embebido, utiliza busybox y permite la creaci on de archivos que permiten compilar software que no se incluya en la distribuci on original. Adicionalmente openembedded crea archivos de instalaci on con un formato derivado del proyecto handhelds 36 ipk, lo que permite la instalaci on de paquetes de forma similar a la distribuci on debian. La informaci on necesaria para generar una distribuci on utilizando las herramientas de Openembedded se encuentra en http://www.emqbit.com/mediawiki/index.php/Main Page/ecb at91/OE.
1.7.
M odulos del kernel
Los m odulos son peque nas piezas de c odigo que pueden ser cargadas y descargadas en el kernel en el momento que sea necesario. Ellos extienden la funcionalidad del kernel, sin la necesidad de reiniciar el sistema y recompilar el kernel. Por ejemplo, un tipo de m odulo es el controlador de dispositivo, el cual permite al kernel acceder a un dispositivo hardware conectado al sistema. Este tipo de m odulos ser an estudiados en esta secci on. Existen tres tipos de dispositivos en Linux [22]: Tipo Caracter: Puede accederse de forma similar a un archivo; este tipo de dispositivos permite por lo 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 realiza nicamente; un ejemplo de este tipo de dispositivo es el disco duro operaci ones de bloques de datos u (/dev/hda). Red: Toda transacci on de red se realiza a trav es 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
rea de usario, no puede acceder directamente al a rea del kernel; Recuerde que una aplicaci on en el a los dispositivos se acceden a trav es de archivos de dispositivos, localizados en /dev (ver gura 1.28), A continuaci on se muestra la salida del comando ls -l /dev/
brwrw brwrw brwrw crwrw crwrw 1 1 1 1 1 root root root root root disk disk disk uucp uucp 3, 3, 3, 4, 4, 0 1 2 64 65 Nov Nov Nov Nov Nov 27 27 27 27 27 hda hda1 hda2 ttyS0 ttyS1
Los archivos tipo caracter est an identicados por una c en la primera columna, mientras que los dispositivos tipo bloque por una b. Podemos observar que existen dos n umeros (5ta y 6ta columna) que identican al driver, el n umero de la 5ta columna recibe el nombre de major number y el de la sexta minor
36 http://handhelds.org
76
Sistemas Embebidos
rea de usuario y el driver del dispositivo. Fuente: [?] Figura 1.27: Interacci on entre el a number; estos n umeros son utilizados por el sistema operativo para determinar el dispositivo y el driver que deben ser accesados ante una solicitud a nivel de usuario. El major number identica la clase o grupo del dispositivo, mientras que el minor number se utiliza para identicar 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 n umero 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 un nico a cada una; lo mismo sucede con el puerto serie. n umero menor u Implementaci on del driver de un LED A continuaci on se realizar a la descripci on 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 siguientes operaciones: init: Se ejecuta cuando se carga el m odulo, el LED se apagar a. close: Se ejecuta cuando se descarga el m odulo, el LED se encender a. open: Se ejecuta cuando se realiza una operaci on de lectura o escritura al dispositivo.
77
Existen dos funciones que deben estar presentes en todo tipo de m odulo, estas son: module init y module exit las cuales se ejecutan cuando se carga y descarga el m odulo respectivamente.
struct f i l e o p e r a t i o n s fops = { . open = device open , . release = device release , }; static int 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 with % d \ n , Major ) ; r e t u r n Major ; } p r i n t k ( KERN ALERT I was a s s i g n e d m a j o r 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 e w i t h \n ) ; p r i n t k ( KERN ALERT mknod / dev/ %s c % d 0 .\ n , DEVICE NAME , Major ) ; p x a g p i o m o d e ( GPIO LED MD ) ; p x a g p i o m o d e ( GPIO LED OFF ) ; return 0; }
/ Turn LED OFF /
s t a t i c void { int ret ;
e x i t b l i n k e x i t ( void )
r e t = u n r e g i s t e r c h r d e v ( Major , DEVICE NAME ) ; if ( ret < 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 ) ; }
module init ( blink init ); module exit ( 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 ser an visibles fuera del archivo. Como puede observarse en la l nea 83 se hace la denici on de las funciones que deben ejecutarse al cargar y descargar el m odulo en nuestro caso blink init y blink exit respectivamente. La informaci on sobre el m odulo aparece en las l neas 87-90.
78
Sistemas Embebidos
En la l nea 40 se dene la estructura de operaciones de archivo del m odulo; cada campo de la estructura corresponde a la direcci on de una funci on denida por el driver para manejar una solicitud determinada. En nuestro caso solo existe una funci on open, la cual ser a denida m as adelante. Como se puede ver en la gura 1.28 es necesario que el kernel sepa que driver est a encargado del dispositivo, esto es, el major number del driver que lo maneja; por esto, lo primero que se debe hacer nea 49) podemos observar la forma en que se realiza es obtener este n umero. En la funci on blink init (l umero mayor asignado de forma el registro de nuestro dispositivo. La funci on register chrdev retorna el n din amica, esto es recomendable ya que si se jara un n umero de forma arbitaria, podr a causar conictos con otros dispositivos. De esta forma, al cargar el m odulo con el comando: insmod blinker.ko, el LED se apagar a y aparecer a el siguiente mensaje en la consola:
BLINK module i s Up . I was a s s i g n e d m a j o r number 2 5 3 . To t a l k t o t h e d r i v e r , c r e a t e a dev f i l e w i t h mknod / dev / b l i n k c 253 0 . Con lo anterior, nuestro dispositivo es registrado y se le asigna el n umero 253 como major number, en el archivo /proc/devices aparecen los dispositivos que actualmente est an siendo utilizados por el kernel, este archivo debe contener una entrada para blink de la forma: 253 blink. En la funci on blink exit se realiza la liberaci on del dispositivo ( la funci on unregister chrdev, l nea 75), la cual se ejecuta cuando 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 mencion o 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. s t a t i c i n t device open ( s t r u c t inode inode , \ struct f i l e f i l e ) { unsigned i n t i ; p r i n t k ( KERN INFO Open BLINKER\ n ) ; if ( is device open ) r e t u r n EBUSY ; is device open = 1; f o r ( i = 0 ; i < 5; i ++ ) { p x a g p i o m o d e ( GPIO LED ON ) ; mdelay ( 0 x0080 ) ; p x a g p i o m o d e ( GPIO LED OFF ) ; mdelay ( 0 x0080 ) ; } t r y m o d u l e g e t ( THIS MODULE ) ; r e t u r n SUCCESS ; } Esta secci on de c odigo se ejecuta cada vez que el archivo de dispositivo /dev/blink es abierto, esto sucede en operaciones de lectura o escritura. Es decir si se utilizan los siguientes comandos: more / dev / b l i n k c a t f i l e > / dev / b l i n k cp f i l e / dev / b l i n k Con cada uno de estos comandos el LED se encender a y apagar a y en la consola se despliega el mensaje: Open BLINKER C l o s e BLINKER 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39
79
1.8.
Interfaz con Perif ericos dedicados
Es com un que algunas aplicaciones requieran ciertos perif ericos especiales que les permitan cumplir las restricciones temporales, es decir, es necesario crear tareas Hardware que ayuden a las tareas software a cumplir con las restricciones de dise no. Para esto es necesario implementar algunas funciones en perif ericos externos al procesador. Si la tarea no se encuentra implementada en un dispositivo comercial es necesario implementarlas en un Dispositivo L ogico Programable (PLD) o en un Circuito Integrado de Aplicaci on Espec ca (ASIC). En esta secci on realizaremos una explicaci on detallada del proceso de comunicaci on entre el procesador y un perif erico implementado en una FPGA.
1.8.1.
Comunicaci on Procesador - Perif erico
La gura 1.29 muestra una arquitectura b asica para la comunicaci on de tareas Hardware - Software; en ella podemos observar que el procesador maneja tres buses: Bus de Datos: Bus bidireccional por donde se realiza el intercambio de informaci on. Bus de Direcciones: Bis controlado por el procesador y es utilizado para direccionar un determinado perif erico o una detrminada funcionalidad del mismo. Bus de control: Se nales necesarias para indicarle a los perif ericos el tipo de comunicaci on (Lectura o escritura).
Figura 1.29: Arquitectura b asica Hardware/Software

Todos los perif ericos que requieren intercambio de informaci on con el procesador comparten el mismo bus de datos, por lo que es necesario que mientras el procesador no se comunique con ellos permanezcan en estadp de alta impedancia, esto es necesario para evitar corto - circuitos originados por diferentes niveles l ogicos en el bus. Por lo tanto, las comunicaciones siempre son iniciadas por el procesador y se selecciona uno y solo un perif erico. El decodicador de direcciones es el encargado de habilitar un determinado perif erico ante una solicitud del procesador (mediante una direcci on de memoria), esto lo hace activando la se nal CSX, cuando esta se nal se encuentra en estado l ogico alto el perif erico coloca su bus de datos en alta impedancia, si se encuentra en estado l ogico bajo el perif erica escribe o lee el bus de datos, dependiendo de la activaci on de las se nales del bus de control RD y WR. El decodicador de direcciones, como su nombre lo indica utiliza como entradas el bus de direcciones y activa solo una se nal de selecci on de Chip (CSx), bas andose en un rango de direcciones asignado a cada perif erico, este rango de direcciones no debe traslaparse para asegurar que solo un chip es seleccionado. Este rango de direcciones que se asigna a cada dispositivo que puede ser nico para cada plataforma. accesado por la unidad de procesamiento recibe el nombre de mapa de memoria y puede ser u Cuando la unidad de procesamiento necesite comunicarse con un determinado perif erico, colocar a en el bus de direcciones una valor que se encuentre en el rango de direcciones asignado para ese perif erico, esto hace que el decodicador de direcciones active
80
Sistemas Embebidos
la se nal de selecci on adecuada para informarle al perif erico que el procesador va a iniciar una transferencia de informaci on. La Figura 1.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 perif erico es visto por el procesador como una posici on de memoria m as y las nicamente el procesador. transacciones las inicia u
Implementaci on de Perif ericos 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 se nales del bus de control, por lo que es necesario asegurarse que cada vez que el procesador realiza una solicitud de lectura o escritura, la se nal de activaci on cambia del estado l ogico alto al bajo; si solo se tiene en cuenta el estado bajo de la se nal CSX el perif erico puede ejecutar la tarea varias veces en el mismo ciclo de activaci on, 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 se nales del procesador con el reloj de la FPGA; si esto no se hace las se nales fuera de fase pueden originar un estado de metaestabilidad en los Flip-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 est e habilitando un perif erico. La FPGA no permite implementar buffers tri-estado internamente por lo que es necesario separar los buses de entrada y salida a cada perif erico. El bus de entrada es com un a todos los perif ericos mientra que es necesario utilizar un esquema de multiplexaci on entre los buses de salida. La gura 1.31 muestra el diagrama de bloques de la interfaz necesaria para poder comunicar un grupo de perif ericos o tareas Hardware con el bus de datos, direcci on y control de un procesador. El bloque SYNC se encarga de sincronizar las se nales provenientes de la FPGA con el reloj interno de la misma. El m odulo Write Pulse generator genera un pulso cuando las se nales sncs y snwe son activadas como se indica en la gura 1.32. El decodicador de direcciones selecciona un determinado perif erico dependiendo del rango especicado para cado uno. Como mencionamos anteriormente, las FPGAs no permiten implementar buffers tri-estado internamente , por lo que cada perif erico debe tener un bus de entrada y uno de salida de datos, los buses de entrada de datos son comunes, mientras que los de salida deben ser manejados por un dispositivo de salida, el cual puede ser un multiplexor controlado por el decodicador de direcciones o una ltimo caso es necesario que los perif compuerta OR, para este u ericos coloquen el bus de datos en 0 cuando no est en seleccionados. Finalmente es necesario colocar un buffer tri-estado en los pines de la FPGA, este buffer est a controlado por las se nales nwe, noe, ncs y solo se activa cuando nwe = 1, noe = 0, ncs = 0, es decir, cuando se selecciona el rango de memoria de la FPGA y el procesador inicia una operaci on de lectura.
81
Figura 1.31: Diagrama de Bloques para la comunicaci on de tareas HW-SW 1.29
Figura 1.32: Generaci on del pulso de escritura Programa en Espacio de Usuario para la comunicaci on
El kernel de Linux proporciona una interfaz que permite a una aplicaci on mapear un archivo en memoria, lo que hace que exista una correspondencia uno a uno entre las direcciones de memoria y el contenido del archivo. Linux implementa la llamada de sistema mmap() para mapear objetos en memoria.[23] # i n c l u d e < s y s / mman . h> v o i d mmap ( v o i d a d d r , s i z e t len , int prot , int flags , i n t fd , off t offset ); Un llamado a mmap() le pide al kernel hacer un mapeo en la memoria de len bytes del objeto representado por el descriptor de archivo fd, comenzando a offset bytes dentro del archivo. Si se especica addr, se utiliza este valor como la direcci on inicial en la memoria. Los permisos de acceso son determinados por prot; PROT READ habilita la lectura, PROT WRITE habilita escritura y PROT EXEC habilita la ejecuci on. El argumento asgs describe el tipo de mapeo, y algunos elementos de su comportamiento y puede
82
tomar los valores:
Sistemas Embebidos
MAP FIXED: hace que addr sea un requerimiento, si el kernel es incapaz de hacer el mapeo en esta direcci on el llamado falla, reas que se traslapan y se remplazan si los par ametros de direcci on y longitud traslapan un mapeo existente se descartan las a por el nuevo mapeo. MAP PRIVATE: Establece que el mapeo no es compartido. Los cambios realizados a la memoria por este proceso no se reejan 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 escribir en el archivo. A continuaci on se lista un ejemplo de la utilizaci on del llamado mmap # d e f i n e MAP SIZE 0 x 2 0 0 0 0 0 0 l / / ECBOT USE A11 t o A25 # d e f i n e MAP MASK ( MAP SIZE 1 ) in t fd ; unsigned long i , j ; void base ; v o l a t i l e unsigned short v i r t a d d r ; i o m a p ( 0 xFFFFFF7C ) ; o f f t a d d r e s s = 0 x40000000 ; / / C o n f i g u r e CS3 a s 16 b i t Memory and 0 W a i t S t a t e s / / CS3 Base A d d r e s s
i f ( ( f d = open ( / dev / mem , O RDWR | O SYNC ) ) == 1) { p r i n t f ( C a n n o t open / dev / mem. \ n ) ; r e t u r n 1; } p r i n t f ( / dev / mem o p e n e d . \ n ) ; b a s e = mmap ( 0 , MAP SIZE , PROT READ | PROT WRITE , MAP SHARED, fd , a d d r e s s ) ; i f ( b a s e == ( v o i d ) 1) { p r i n t f ( C a n n o t mmap . \ n ) ; r e t u r n 1; } p r i n t f ( Memory mapped a t a d d r e s s % p .\ n , base ) ; v i r t a d d r = base ; En este ejemplo utilizamos el llamado mmap para hacer un mapeo de la direcci on 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 la memoria virtual. Adicionalmente permitimos operaciones de lectura/escritura (PROT READ PROT WRITE) y permitimos el acceso a otros proceso. Finalmente podemos usar la variable virt addres para escribir en cualquier posici on de memoria desde 0x40000000 hasta 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 u s e A11 t o A25
p r i n t f ( R e a d i n g Memory . . \ n ) ; f o r ( i = 0 ; i < 3 2 ; i ++) { j = v i r t a d d r [ i << 10]; printf ( % X = % X\ n , i , j ) ; } i f ( munmap ( b a s e , MAP SIZE ) == 1) { p r i n t f ( C a n n o t munmap . \ n ) ; r e t u r n 1; }
83
1.8.2.
Comunicaci on Perif erico - Procesador
Cuando un perif erico requiere atenci on por parte de la CPU debido a que termin o de realizar un proceso o porque requiere nuevas instrucciones para seguir operando, o un evento originado por un usuario necesita ser atendido, se debe iniciar un proceso para l. Como se mencion que la unidad de procesamiento se comunique con e o anteriormente la unidad de procesamiento est a encargada de forma exclusiva de iniciar las operaciones de lectura/ecritura con los perif ericos, por esta raz on, el perif erico utiliza una se nal (IRQ) para informarle al procesador que requiere ser atendido. Algunas arquitecturas poseen un mecanismo que permite el acceso a la memoria por parte de los perif ericos sin utilizar el procesador, esto permite que perif ericos de diferentes velocidades se comuniquen sin someter al procesador a una carga excesiva. En esta secci on hablaremos de la forma de denir las interrupciones en un driver de Linux.
Manejo de Interrupciones
A continuaci on se describir a la forma de manejar las interrupciones utilizando un driver de Linux. Analicemos la funci on qem init static int { int res ; 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 ) { r e t u r n 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 = i o r e m a p ( FPGA BASE , 0 x4000 ) ; return 0; } Esta rutina es similar a la presentada anteriormente, solo se agrega un par de comandos para denir un pin del procesador como entrada, para poder utilizarlo como se nal 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 funci on request irq que asigna recursos a la interrupci on, habilita el manejador y la l nea de interrupci on. En nuestro caso dene el pin FPGA IRQ PIN como la l nea de interrupci on, la rutina irq handler ser a ejecutada cuando se presente una interrupci on, el ag IRQF DISABLED deshabilita las interrupciones locales mientras se procesa, el nombre del dispositivo que realiza la interrupci on es FPGA - IRQ. La funci on ioremap(offset, size), una secuencia de operaciones que permiten que la memoria de la CPU se pueda acceder con las funciones readb/readw/readl/writeb/writew/write, utilizando la variable ioaddress. Finalmente se dene el tipo de interrupci on del pin FPGA IRQ PIN como IRQT RISING. La funci on que se ejecuta cuando se presenta la interrupci on, se dene 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 irq , void dev id , s t r u c t p t r e g s r e gs ) { if ( irq enabled ) { i n t e r r u p t c o u n t e r ++; i n i t q e m i n i t ( void )
84
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 ) ; } r e t u r n IRQ HANDLED ; }
Sistemas Embebidos
Cada vez que se produce una interrupci on y si la variable global irq enabled es igual a 1, se aumenta en 1 el valor de interrupt counter, se imprime su valor y el de un registro interno del perif erico. En este driver utilizaremos la funci on device read para enviar informaci on a un programa en espacio de usuario. s t a t i c s s i z e t device read ( struct f i l e filp , / see include / linux / f s . h / char b u f f e r , / b u f f e r to f i l l with data / s i z e t count , / l e n g t h of t he b u f f e r / loff t offset ) { 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; } else{ 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 ) ) ; } return 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 operaci on de lectura desde espacio de usuario, el proceso quedar a bloqueado por la funci on wait event interruptible hasta que la rutina de atenci on a la interrupci on ejecute la funci on wake up interruptible, pero es necesario que se cumpla la condici on evaluada 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 despertar a y el proceso de lectura quedar a 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 ( t o , from , l o n g n ) ; Se utiliza la funci on copy to user para intercambiar informaci on con el programa que se ejecuta en espacio de usuario. En este caso se copia a char *buffer, la variable interrupt counter. Existe una funci on an aloga que recibe informaci on proveniente del espacio de usuario copy from user En la Figura 1.33 se muestran estas operaciones. En la funci on qem exit se liberan los recursos de la interrupci on y la variable ioaddress. s t a t i c void e x i t qem exit ( void ) { int ret ; / 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 ) ; }
85
Figura 1.33: Intercambio de informaci on entre los espacios de kernel y usuario

Finalmente el programa en espacion de usuario es: i n t main ( v o i d ) { int char fileNum , b y t e s ; data [40];
f i l e N u m = open ( / dev / f p g a , O RDWR ) ; i f ( fileNum < 0) { p r i n t f ( U n a b l e t o open f i l e \ n ) ; exit (1); } p r i n t f ( Opened d e v i c e \ n ) ; b y t e s = r e a d ( fileNum , d a t a , s i z e o f ( d a t a ) ) ; i f ( bytes > 0) printf ( % x\n , d a t a ) ; c l o s e ( fileNum ) ; return ( 0 ) ; } En este programa se abre el dispositivo /dev/fpga que corresponde a nuestro driver y se utiliza la funci on read para leer la informaci on suministrada por el driver.
86
Sistemas Embebidos
Bibliograf a
[1] I. Bowman, S. Siddiqi, and M. Tanuan. Concrete http://docs.huihoo.com/linux/kernel/a2/index.html, 12 February 1998. Architecture of the Linux Kernel.
[2] I. Bowman. Conceptual Architecture of the Linux Kernel. http://docs.huihoo.com/linux/kernel/a1/, 1998. [3] H ector Mart nez. Apropiaci on de conocimiento en Colombia. El caso de los contratos de importaci on de tecnolog a. Revista Cuadernos 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 the American 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 Integration. 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. Masters thesis, Universidad Nacional de Colombia, 2007. [11] D Zuluaga, S Campos, M Tovar, R Rodr guez, J S anchez, A Aguilera, L Land nez, and J Medina. Informe de Vigilancia Tecnol ogica: Aplicaciones de la Electr onica en el Sector Agr cola. Technical report, COLCIENCIAS, 2007. [12] M. Duque and A. Gauthier. Formaci on de Inegnieros para la Innovaci on y el Desarrollo Tecnol ogico en Colombia. Revista de la Facultad de Minas - Universidad Nacional de Colombia, December 1999. [13] Luis Alejandro Cort es. Verication and Scheduling Techniques for Real-Time Embedded Systems. PhD thesis, Link opings universitet 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, 21 September 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. OREILLY, 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 Dise no de Sistemas Embebidos y Co-Dise no HW/SW. VIII Jornadas de Computaci on Recongurable y Aplicaciones, September 2008. [22] J. Corbet, A. Rubini, and G. Kroah-Hartman. Linux Device Drivers, Third Edition. OReilly, 2005. [23] R Love. Linux System Programming. OReilly Media, Inc., 2007.
87

Ecb At91

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Ecb At91

Hochgeladen von

Copyright:

Verfügbare Formate

Indice general

PLATAFORMA DE DESARROLLO ECBOT

Carlos Iv an Camargo Bare no

en el 2001 exist an 154 empresas productoras de componentes y equipos de la

de entidades del Sector Electr onico

Carlos Iv an Camargo Bare no

Contribuciones al desarrollo tecnol ogico en Colombia

Carlos Iv an Camargo Bare no

Carlos Iv an Camargo Bare no

http://www.atmel.com, http://www.cirrus.com, http://www.samsung.com, http://www.freescale.com,

Carlos Iv an Camargo Bare no

Figura 1.5: Flujo de Dise no de un Sistema Embebido [13]

Herramientas Software de libre distribuci on GNU toolchain

Carlos Iv an Camargo Bare no

recibe el nombre de re-utilizaci on de c odigo

13 http://www.gnu.org/software/libc/ 14 http://uclibc.org/ 15 http://sources.redhat.com/newlib/ 16 http://www.fefe.de/dietlibc/

18 software Flujo de diseno

Carlos Iv an Camargo Bare no

/ / V a r i a b l e no i n i c i a l i z a d a / / Variable i n i c i a l i z a d a / / Caracteres constantes

Carlos Iv an Camargo Bare no arm-none-eabi-objdump -d -j .text hello.o

/ FLASH EPROM / s t a t i c RAM a r e a

Carlos Iv an Camargo Bare no

Carlos Iv an Camargo Bare no Memorias Vol atiles

Carlos Iv an Camargo Bare no

Densidad Velocidad de Lectura Velocidad de escritura Tiempo de borrado Interfaz Aplicaci on

Cuadro 1.1: Cuadro de comparaci on de las memorias ash NAND y NOR

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

Carlos Iv an Camargo Bare no

Carlos Iv an Camargo Bare no

Figura 1.17: Arquitectura Boundary Scan

Carlos Iv an Camargo Bare no

El sistema Operativo Linux

Carlos Iv an Camargo Bare no

Arquitectura de Linux [1] [2]

38 Programador de procesos (Scheduler)

Carlos Iv an Camargo Bare no Memoria compartida

Figura 1.22: Mapeo de memoria del Kernel.

Portando Linux a la plataforma ECBOT y ECB AT91

Carlos Iv an Camargo Bare no

<asm / h a r d w a r e . h> <asm / s e t u p . h> <asm / mach t y p e s . h> <asm / i r q . h>

# include generic . h # i n c l u d e <asm / a r c h / a t 9 1 p i o . h> # i n c l u d e < l i n u x / w1g p i o . h>

Carlos Iv an Camargo Bare no

i n i t d a t a ecb at91usbh data = {

AT91RM9200 tiene 4 USARTS y una UART para depuraci on

Carlos Iv an Camargo Bare no

48 Archivo de Conguraci on del kernel

Imagen del kernel

Carlos Iv an Camargo Bare no

A continuaci on se muestra una secci on de este archivo:

Finalmente damos incio al proceso de compilaci on:

Si no ocurre ning un error, al nalizar debemos observar lo siguiente:

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

50 Componentes de la Im agen del kernel

Al nalizar el proceso de compilaci on obtenemos:

Carlos Iv an Camargo Bare no

Inicializaci on del kernel

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

Carlos Iv an Camargo Bare no

La estructura del c odigo fuente se muestra en el siguiente listado:

54 A continuaci on se muestra el contenido del archivo u-boot.lds

Carlos Iv an Camargo Bare no

El programa desplegar a el siguiente men u: