Dise˜ no e implementaci´ on, sobre un FPGA, de un sistema reconfigurable din´ amicamente instalado como un nodo de un cluster.

Ing. William Alex´ ander Salamanca Becerra

Trabajo de investigaci´ on presentado como requerimiento parcial para optar al t´ıtulo de:

Magister en Ingenier´ıa Electr´ onica

Tesis desarrollada dentro del convenio de cooperaci´ on UIS-ICP 005 de 2003

Directora: PhD(C). Ana Beatr´ız Ram´ırez Silva

Co-Director: PhD. William Mauricio Agudelo Zambrano

Escuela de Ingenier´ıas El´ ectrica, Electr´ onica y de Telecomunicaciones

Universidad Industrial de Santander Facultad de Ingenier´ıas F´ısico-Mec´anicas Escuela de Ingenier´ıa El´ectrica, Electr´ oncia y de Telecomunicaciones Bucaramanga Marzo, 2011

Dise˜ no e implementaci´ on, sobre un FPGA, de un sistema reconfigurable din´ amicamente instalado como un nodo de un cluster.

Ing. William Alex´ ander Salamanca Becerra

Trabajo de investigaci´ on presentado como requerimiento parcial para optar al t´ıtulo de:

Magister en Ingenier´ıa Electr´ onica

Tesis desarrollada dentro del convenio de cooperaci´ on UIS-ICP 005 de 2003

Directora: MSc. Ana Beatr´ız Ram´ırez Silva

Co-Director: PhD. William Mauricio Agudelo Zambrano

Escuela de Ingenier´ıas El´ ectrica, Electr´ onica y de Telecomunicaciones

Universidad Industrial de Santander Facultad de Ingenier´ıas F´ısico-Mec´anicas Escuela de Ingenier´ıa El´ectrica, Electr´ oncia y de Telecomunicaciones Bucaramanga Marzo, 2011

3

4

Agradecimientos Este trabajo investigativo ha llegado a feliz t´ermino y el m´erito no es solo m´ıo sino tambi´en de todas las personas que me apoyaron durante todo su desarrollo. En primer lugar, agradezco a Dios, a mis padres y a mi hermano, a quienes dedico este trabajo por su apoyo infinitamente incondicional. Quiero resaltar la dedicaci´on y diposici´on que tuvo mi directora de tesis, la Profesora Ana Beatriz Ram´ırez, a la cual le deseo muchos ´exitos en sus proyectos. El apoyo incondicional y la confianza que tuvo el PhD. William Mauricio Agudelo, mi codirector, quien desde un principio crey´ o en esta idea y en nosotros para llevarla a cabo. Al Profesor Jorge Ram´on que me ha acompa˜ nado y apoyado en todo mi proceso de formaci´on que aun sigue en desarrollo. Al grupo de investigaci´on CPS, quienes nos acogieron y brindaron el espacio para desarrollar el presente trabajo. A todos los compa˜ neros de oficina, con quienes hemos podido forjar buenas amistades y un buen ambiente que favoreci´ o el desarrollo del proyecto. Al grupo de investigaci´on Petros´ısmica por respaldar la idea en cabeza de sus interventores el Profesor Jorge Eduardo Pinto, William Mauricio Agudelo y Andr´es Calle. A los compa˜ neros del grupo que han mostrado inter´es, nos han dado apoyo y han hecho sus observaciones en su debido momento. A todos mis amigos, que me han acompa˜ nado y apoyado, les quiero compartir este momento y este trabajo.

Universidad Industrial de Santander

5

´Indice

Introducci´ on

17

Cap´ıtulo 1. Implementaci´ on del Embedded System sobre el FPGA

21

1.1

Sistema de desarrollo ML507 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.2

Integrated Software Environment (ISE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 1.2.1

1.3

Flujo de dise˜ no tradicional con FPGA (Tomado de [1]) . . . . . . . . . . . . . . . . . 23 1.2.1.1

Ingreso de archivos fuente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

1.2.1.2

S´ıntesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

1.2.1.3

Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

1.2.1.4

Place and Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

1.2.1.5

Generaci´ on del archivo de configuraci´ on . . . . . . . . . . . . . . . . . . . . 25

Embedded Development Kit (EDK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 1.3.1

Hardware > Generate Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

1.3.2

Hardware > Generate Bitstream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

1.3.3

Software > Build User Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

1.3.4

Device Configuration > Update Bitstream . . . . . . . . . . . . . . . . . . . . . . . . 26

1.3.5

Device Configuration > Download Bitstream

1.3.6

PlanAhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

. . . . . . . . . . . . . . . . . . . . . . 27

1.4

Implementaci´ on del sistema base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

1.5

Sistema operativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 1.5.1

Arranque del Sistema operativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

1.5.2

Entorno de trabajo del sistema de desarrollo. . . . . . . . . . . . . . . . . . . . . . . 31

1.5.3

Instalaci´on del bootloader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

1.5.4

Compilaci´ on del kernel

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Universidad Industrial de Santander

6

´Indice

1.6

1.5.5

Sistema de archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

1.5.6

Configuraci´ on de u-boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Resumen del cap´ıtulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Cap´ıtulo 2. Configuraci´ on del cl´ uster

36

2.1

Organizaci´on del cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.2

Herramientas del cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.3

2.2.1

Ajustes preliminares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.2.2

Instalaci´on de PVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.2.3

Instalaci´on de LAM-MPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.2.4

Instalaci´on de Ganglia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Resultados del cap´ıtulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Cap´ıtulo 3. Interpretaci´ on de los bitstreams 3.1

3.2

42

Configuraci´ on del FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.1.1

M´etodos de configuraci´ on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.1.2

Arquitectura del FPGA V5FX70 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.1.3

Bitstreams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.1.3.1

Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.1.3.2

Estructura del bitstream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Int´erprete de bitstream en Matlab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.2.1

Organizaci´on del script

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.2.2

Resultados obtenidos con Matlab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Cap´ıtulo 4. Perif´ erico para la reconfiguraci´ on parcial 4.1

Modificaciones al sistema base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.1.1

Perif´erico reconfigurable de prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.1.2

Perif´erico para acceder a la configuraci´ on del FPGA . . . . . . . . . . . . . . . . . . 52 4.1.2.1

4.1.3

4.2

50

XPS HWICAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Optimizaciones en la implementaci´ on mediante PlanAhead . . . . . . . . . . . . . . 53 4.1.3.1

Objetivos de las restricciones de localizaci´ on . . . . . . . . . . . . . . . . . 53

4.1.3.2

Restricciones del perif´erico reconfigurable. . . . . . . . . . . . . . . . . . . . 57

4.1.3.3

Regreso de archivos a EDK . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Driver del perif´erico XPS HWICAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.2.1

Driver de Xilinx del XPS HWICAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.2.2

Compilaci´ on en Linux desde el espacio del usuario . . . . . . . . . . . . . . . . . . . 61

4.2.3

Ejemplos modificados y scripts de Linux hechos para pruebas . . . . . . . . . . . . . 63 Universidad Industrial de Santander

7

´Indice

4.2.4

4.2.5

4.3

4.2.3.1

xhwicap read frame polled example args.c . . . . . . . . . . . . . . . . . . . 63

4.2.3.2

leer frames de una columna.sh . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.2.3.3

leer toda la configuracion.sh . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.2.3.4

w lee y escribe frame.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.2.3.5

w cambia cada bit de una columna.sh . . . . . . . . . . . . . . . . . . . . . 64

Identificaci´on de los bits que afectan el comportamiento de las LUTs. . . . . . . . . 65 4.2.4.1

Programa operaLUTs y operaLUTs verbose . . . . . . . . . . . . . . . . . 65

4.2.4.2

FPGA Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.2.4.3

Estrategia para identificar los bits del bitstream

4.2.4.4

An´alisis de los resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

. . . . . . . . . . . . . . . 66

Compilaci´ on en Linux desde el espacio del kernel . . . . . . . . . . . . . . . . . . . . 69 4.2.5.1

Estructura de la implementaci´ on del driver desde el espacio del kernel . . . 70

4.2.5.2

Desarrollo del m´odulo del kernel . . . . . . . . . . . . . . . . . . . . . . . . 70

4.2.5.3

Modificaciones sobre las librer´ıas del espacio del usuario. . . . . . . . . . . 72

4.2.5.4

Nueva librer´ıa xil io.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Resultados del cap´ıtulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Cap´ıtulo 5. Pruebas finales y conclusiones 5.1

Medici´ on del tiempo de reconfiguraci´ on

75 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.1.1

Modificaciones a la aplicaci´ on w escribe una LUT. . . . . . . . . . . . . . . . . . . 76

5.1.2

Modificaciones al driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.1.3

Adecuaci´on de los datos extraidos desde el espacio del kernel . . . . . . . . . . . . . 77

5.2

Reconfiguraci´ on desde el cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.3

Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5.4

Trabajo Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Bibliograf´ıa

86

I Anexos

87

Anexo A. Gu´ıa para la configuraci´ on del embedded system.

88

A.1 Descripci´ on del montaje f´ısico del cluster

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

A.2 Instalaci´on, configuraci´ on y personalizaci´on del sistema operativo del frontend y los nodos con PPG

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

A.2.1 Configuraci´ on del servidor DHCP en el router . . . . . . . . . . . . . . . . . . . . . . 89 A.2.2 Configuraci´ on de la interfaz de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Universidad Industrial de Santander

8

´Indice A.2.3 Configuraci´ on del repositorio en internet . . . . . . . . . . . . . . . . . . . . . . . . . 91 A.2.4 Personalizaci´on de vim, bash, etc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 A.3 servidor DNS y RDNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 A.4 Configuraci´ on el servidor DCHP en el nodo maestro . . . . . . . . . . . . . . . . . . . . . . 94 A.5 Instalaci´on y configuraci´ on del servidor y los clientes NFS. . . . . . . . . . . . . . . . . . . . 96 A.6 Configuraci´ on de SSH y los usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 A.7 servidor TFTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 A.8 Herramientas para compilaci´on cruzada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 A.9 Instalaci´on del sistema base en la tarjeta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 A.10 Instalaci´on del Bootloader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 A.11 Compilar el kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 A.12 Creaci´ on del sistema de archivos para debian . . . . . . . . . . . . . . . . . . . . . . . . . . 113 A.13 Configuraci´ on del sistema operativo de la tarjeta . . . . . . . . . . . . . . . . . . . . . . . . 116 A.14 Configuraci´ on del directorio compartido en el cluster . . . . . . . . . . . . . . . . . . . . . . 117 A.15 Configuraci´ on de otros servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 A.15.1 Servidor DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 A.16 Instalaci´on de PVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 A.17 Adici´ on del FPGA a la instalaci´ on de PVM . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 A.18 Instalaci´on de LAM-MPI

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

A.19 Adici´ on de nodo x86 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 A.20 Procedimiento para a˜ nadir un nodo FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 A.21 Soporte para el desarrollo de drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 A.21.1 Implementaci´ on del ´ arbol de fuentes sobre el nodo Okinawa-02 (x86) . . . . . . . . . 133 A.21.2 Implementaci´ on del ´ arbol de fuentes sobre el nodo Okinawa-21 (FPGA) . . . . . . . 134 Anexo B. Script tcl para la generaci´ on del archivo bmm requerido por data2mem

136

B.1 Archivo crea bmm.tcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 B.2 Archivo system bd.bmm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Anexo C. Script de Matlab para la interpretaci´ on de los bitstreams.

139

C.1 Funci´ on principal: InterpretaBitstream(archivo) . . . . . . . . . . . . . . . . . . . . . . . . . 139 C.1.1 interpretaword(unaword) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 C.1.1.1

identificaregistro(direccion) . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

C.1.1.2

analizoregistro(unaword) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

interpretadirframe(unaword) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 C.1.1.3

frameautoinc(framedirin) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Universidad Industrial de Santander

9

´Indice C.2 grep(archivo,patron,varargin) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 C.3 analizogrep(archivo) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 Anexo D. Procedimiento para compilar el driver de EDK sobre el sistema operativo.

154

D.1 Modificaciones sobre los archivos del driver xhwicap . . . . . . . . . . . . . . . . . . . . . 154 D.2 Modificaciones sobre los archivos de ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 D.3 Makefile para compilar las fuentes y los ejemplos. . . . . . . . . . . . . . . . . . . . . . . 156 Anexo E. C´ odigo de la librer´ıa xil io (versi´ on espacio del usuario).

160

E.1 Archivo xil io.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Anexo F. Programas y scripts creados durante la compilaci´ on del driver desde el espacio 163

del usuario.

F.1 xhwicap read frame polled example args.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 F.1.1 Ejemplos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 F.1.2 C´ odigo fuente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 F.2 leer frames de una columna.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 F.2.1 Ejemplo de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 F.2.2 C´ odigo fuente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 F.3 leer toda la configuracion.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 F.3.1 Ejemplo de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 F.3.2 C´ odigo fuente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 F.4 w lee y escribe frame.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 F.4.1 Ejemplos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 F.4.2 C´ odigo fuente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 F.5 w cambia cada bit de una columna.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 F.5.1 Ejemplo de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 F.5.2 C´ odigo fuente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 F.6 operaLUTs.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 F.6.1 Ejemplo de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 F.6.2 C´ odigo fuente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 F.7 w escribe una LUT.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 F.7.1 Ejemplos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 F.7.2 C´ odigo Fuente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Anexo G. C´ odigo de la librer´ıa xil io (versi´ on espacio del kernel ).

186

G.1 Archivo xil io.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Universidad Industrial de Santander

10

´Indice Anexo H. Plantilla del driver.

189

H.1 Archivo periferico.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 H.2 Archivo periferico.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 H.3 Archivo montar.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Anexo I. M´ odulo del kernel (Adaptaci´ on de la plantilla).

201

I.1

Archivo XPS HWICAP.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

I.2

Archivo XPS HWICAP.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

Universidad Industrial de Santander

11

Lista de Figuras 0.1

Diagrama general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

0.2

Pasos de la implementaci´ on del sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.1

Diagrama general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.2

Pasos de la implementaci´ on del sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1.3

Diagrama de bloques del sistema de desarrollo ML507 (Adaptado de [2]) . . . . . . . . . . . . . 23

1.4

Flujo de dise˜ no con FPGA (Adaptado de [1]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

1.5

Flujo de EDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

1.6

Alternativa orientada al desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

1.7

Alternativa para un funcionamiento definitivo. . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

1.8

Entorno de trabajo para el desarrollo e implementaci´ on del embedded system . . . . . . . . . . 31

1.9

Instalaci´on y configuraci´ on del bootloader y los requerimientos del sistema operativo . . . . . . 32

2.1

Diagrama general. Recursos empleados durante este cap´ıtulo. . . . . . . . . . . . . . . . . . . . 36

2.2

Pasos de la implementaci´ on del sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.3

Diagrama de la implementaci´ on f´ısica del sistema. . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.4

Visualizaci´ on de los nodos del sistema en ganglia. . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.1

Pasos de la implementaci´ on del sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.2

Arquitectura del FPGA Virtex 5 FX70, donde se aprecia la organizaci´ on en filas, columnas y elementos l´ ogicos. (Im´ agenes tomadas de PlanAhead.) . . . . . . . . . . . . . . . . . . . . . . . 44

3.3

Campos de la direcci´on de un Frame (Adaptada de [3]) . . . . . . . . . . . . . . . . . . . . . . 45

3.4

Scripts de matlab para interpretar los bitstreams. . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.1

Pasos de la implementaci´ on del sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.2

Diagrama general. Recursos empleados durante este cap´ıtulo. . . . . . . . . . . . . . . . . . . . 51

Universidad Industrial de Santander

12

Lista de Figuras 4.3

Estructura del perif´erico reconfigurable de pruebas. . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.4

Flujo de EDK modificado para emplear PlanAhead . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.5 4.6

Restricciones del sistema base impuestas por EDK . . . . . . . . . . . . . . . . . . . . . . . . . 55 ´ Area reservada para el sistema base. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.7

R . . . . 59 Dependencia en los archivos del c´odigo fuente del driver del HWICAP dado por Xilinx

4.8

Compilaci´ on de las fuentes del driver y una aplicaci´ on sobre una fuente de ejemplo. . . . . . . 62

4.9

Estrategia para identificar los bits que modifican el comporamiento de las LUT de un slice . . . 67

A.1 Diagrama de la implementaci´ on f´ısica del sistema. . . . . . . . . . . . . . . . . . . . . . . . . . 89 A.2 Sistemas involucrados en esta etapa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 A.3 Elementos involucrados en la instalaci´on del servidor DNS y RDNS. . . . . . . . . . . . . . . . 92 A.4 Elementos involucrados en esta secci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 A.5 Elementos involucrados en la implementaci´ on del sistema base. . . . . . . . . . . . . . . . . . . 101 A.6 Elementos involucrados en la instalaci´on del bootloader. . . . . . . . . . . . . . . . . . . . . . . 102 A.7 Funci´ on de EDK para descargar el bitstream del dise˜ no de referencia. . . . . . . . . . . . . . . . 104 A.8 Funci´ on de EDK para descargar un archivo a la memoria Flash.

. . . . . . . . . . . . . . . . . 105

A.9 Cuadro de di´alogo con la configuraci´ on para descargar u-boot a la Flash. . . . . . . . . . . . . 106 A.10 Aplicaci´ on iMPACT usada para generar el archivo de configuraci´ on de la PROM y programarla.107 A.11 Di´ alogo donde se especifican los par´ ametros generales del archivo para la memoria PROM que se desea generar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 A.12 Di´ alogo donde se especifica si el archivo se va a cargar de forma serial o paralela. . . . . . . . . 108 A.13 Di´ alogo donde se definen el tipo y la cantidad de memorias PROM disponibles. . . . . . . . . . 108 A.14 Di´ alogo donde confirman los par´ ametros del archivo que se va a generar. . . . . . . . . . . . . . 109 A.15 En la ventana se observan las memorias PROM que se van a usar y los archivos que se cargar´an en ellas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 A.16 Aplicaci´ on iMPACT usada para generar el archivo de configuraci´ on de la PROM y programarla.110 A.17 Aplicaci´ on iMPACT usada para generar el archivo de configuraci´ on de la PROM y programarla.110 A.18 Aplicaci´ on iMPACT usada para generar el archivo de configuraci´ on de la PROM y programarla.111 A.19 Elementos involucrados en la compilaci´on del kernel . . . . . . . . . . . . . . . . . . . . . . . . 112 A.20 Elementos involucrados en la creaci´on del sistema de archivos para debian. . . . . . . . . . . . 114 C.1 Scripts de matlab para interpretar los bitstreams. . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Universidad Industrial de Santander

13

Lista de Tablas 1.1

Recursos del FPGA (Adaptado de [4]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1.2

Mapa de memoria del sistema base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.1

Configuraci´ on del sistema de archivos compartido. . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.1

Modos de configuraci´ on del FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.2

N´ umero de frames que componen cada una de las columnas seg´ un el tipo de recurso . . . . . . 46

3.3

Organizaci´on de los recursos del FPGA por columnas . . . . . . . . . . . . . . . . . . . . . . . 49

4.1

Algunas distribuciones estudiadas para ser asignadas al sistema base . . . . . . . . . . . . . . . 56

4.2

Opciones de visualizaci´ on de xhwicap read frame polled example args.c . . . . . . . . . . . . . 63

4.3

Orden en el que el script w invierte LUTs de un slice.sh manipul´ o los bits de los frames 68

4.4

Orden en el que el script manipul´ o los bits de las 4 LUTs del un slice . . . . . . . . . . . . . . 68

5.1

Resumen de resultados de la medici´ on del tiempo de escritura y lectuar de un frame del FPGA. 78

5.2

Implementaci´ on Actual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5.3

Espectativa para una implementaci´ on reducida. . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

A.1 Mapa de memoria del sistema base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 D.1 Archivos traidos desde EDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 F.1 Opciones de visualizaci´ on de xhwicap read frame polled example args.c . . . . . . . . . . . . . 163 F.2 Opciones de visualizaci´ on de xhwicap read frame polled example args.c . . . . . . . . . . . . . 171

Universidad Industrial de Santander

14

Resumen ´ ˜ TITULO: DISENO E IMPLEMENTACION, SOBRE UN FPGA, DE UN SISTEMA RECONFIGURABLE ´ DINAMICAMENTE INSTALADO COMO UN NODO DE UN CLUSTER.∗ AUTOR: WILLIAM ALEXANDER SALAMANCA BECERRA∗∗ ´ Reconfigurable, HPC. PALABRAS CLAVE: FPGA, HPRC, Computacion

´ de circuitos integrados mejora d´ıa a d´ıa, y esto se ve reflejado en la capacidad de La tecnolog´ıa de fabricacion ´ ´ computo de las plataformas basadas en procesadores de proposito general (PPG). As´ı mismo, este avance favorece otros circuitos digitales como los Field Programmable Gate Arrays (FPGAs) y los hace competitivos como ´ ˜ ha sido evidenciado en aplicaciones donde son empleados para impledispositivos de computo. Su desempeno ´ ´ mentar procesadores de proposito espec´ıfico (PPE) y logran acelerar procesos de computo hasta 1700 veces respecto a PPG. ´ Reconfigurable de Alto Rendimiento (HPRC) propone un nuevo paradigma de computacion ´ La Computacion ´ de FPGAs y PPG con muy buenas expectativas debido a que la rata de crecimiento basada en la combinacion ´ de la capacidad de computo de los FPGAs es muy superior a la que han tenido los PPGs. Teniendo en cuenta ´ esto, empresas como el Instituto Colombiano de Petroleo (ICP), se han interesado en el tema y han apoyado investigaciones que permitan finalmente llevar a cabo sus algoritmos de procesamiento de datos en un menor tiempo. ´ de una plataforma El presente proyecto de maestr´ıa realizo´ un avance significativo hacia la construccion ´ ´ economica de HPRC, implementando un cluster heterogeneo compuesto por PPG y FPGAs. Adicionalmente ´ se implemento´ un mecanismo que permite reconfigurar parcialmente los recursos logicos del FPGA lanzando una ´ desde el sistema operativo instalado en el FPGA o desde el cluster mediante MPI o PVM. aplicacion ´ de los recursos logicos ´ De esta forma, se pudo medir el tiempo de reconfiguracion y as´ı establecer las caracter´ısticas de las aplicaciones que se ver´ıan favorecidas al ser implementadas sobre este tipo de plataformas.

∗

´ Trabajo de investigacion ´ ´ ´ Facultad: Facultad de Ingenier´ıas F´ısico Mecanicas. Escuela: Escuela de Ingenier´ıas Electrica, Electronica y Telecomunicaciones. ´ CPS. Director: PhD(c) Ana Beatr´ız Ram´ırez Silva Grupo de Investigacion: ∗∗

15

Abstract TITLE: DESIGN AND IMPLEMENTATION, OVER AN FPGA, OF A DYNAMICALLY RECONFIGURABLE SYSTEM INSTALLED AS A NODE CLUSTER. ∗ AUTHOR: WILLIAM ALEXANDER SALAMANCA BECERRA∗∗ KEY WORDS: FPGA, HPRC, Reconfigurable Computing, HPC.

The integrated circuit fabrication technology is improving with time and it can be observed in the performance of the latest computing platforms based on General Purpose Processors (PPG). Furthermore, it provides new benefits to other digital circuits such as Field Programmable Gate Arrays (FPGAs) making them more competitive as computing devices. FPGAs have been used in applications where Specific Purpose Processors (PPE) can be implemented and it has been demonstrated that they can reach accelerations up to 1700 times compared to PPG.

High Performance Reconfigurable Computing (HPRC) propose a new paradigm in computation based on the combination of FPGAs and PPGs with high expectations due to the computing performance growth rate of the FPGAs has been greater than PPGs. Bearing in mind this, companies, as the Colombian Petroleum Institute (ICP), are interested in this topic and they have supported investigations in HPRC that can execute their algorithms for data processing in less time.

This master thesis makes a significant progress to the construction of an inexpensive HPRC platform. In this work the implementation of a heterogeneous cluster with PPGs and FPGAs is proposed. In addition, a method to partially reconfigure the FPGA’s logic resources is implemented by deploying an application from the FPGA’s operating system or from the cluster through MPI or PVM.

Finally, the logic resources reconfiguration time was measured in the proposed heterogeneous cluster and characteristics of the applications that can be beneficed with the implementation in this type of computing platform were established.

∗

´ Trabajo de investigacion Faculty: Physico-mechanical Engineering Faculty. School: School of Electrical, Electronics and Telecommunications Engineering. Research group: CPS. Director: PhD(c) Ana Beatr´ız Ram´ırez Silva ∗∗

16

´ Introduccion La computaci´ on de alto rendimiento (CAR)1 , hasta hace poco, se ha basado principalmente en procesadores de prop´osito general (PPG). Los clusters y grid, implementados para formar plataformas con las m´as grandes capacidades de c´omputo, se fundamentan en la agrupaci´on de este tipo de procesadores. Por otro lado los procesadores de prop´osito espec´ıfico (PPE), gran parte de estos implementados sobre FPGAs, se han caracterizado por obtener un desempe˜ no superior a los PPG al llevar a cabo la funci´on para la cual son dise˜ nados. Las plataformas basadas en PPE han reportado en la literatura factores de aceleraci´on que van desde 1 hasta varios miles de veces, comparado con plataformas basadas en PPG[5]. Esto le ha permitido a los FPGA introducirse fuertemente como una alternativa entre los dispositivos de c´omputo disponibles. Adem´ as de la posibilidad de configurar los FPGAs como PPE, existe la posibilidad de reconfigurarlos durante el tiempo de ejecuci´ on de un proceso. Esto ha abierto las puertas de un nuevo paradigma en computaci´ on que involucra el uso de diferentes PPE configurados en diferentes instantes de tiempo sobre los mismos recursos de un FPGA. Basados en este principio, los sistemas reconfigurables(RS) y los sistemas de computaci´ on reconfigurable de alto rendimiento (HPRC) han surgido como las nuevas arquitecturas de c´omputo. Aunque estas arquitecturas tienen mucho potencial, han tenido varias dificultades en su proceso de acogida por parte de los desarrolladores debido principalmente a dos caracter´ısticas: el conocimiento sobre implementaci´ on de hardware requerido por parte del desarrollador y el tiempo de desarrollo significativamente alto para una aplicaci´ on. Por otro lado, aunque los fabricantes de los FPGAs han dado mecanismos para llevar a cabo la reconfiguraci´ on, solo actualmente se est´ a comenzando a dar el soporte t´ecnico y las herramientas software para llevar a cabo este tipo de aplicaciones mediante licencias comerciales.

1 en

ingl´ es High Performance Computing (HPC)

Universidad Industrial de Santander

17

Lista de Tablas El presente proyecto realiza un aporte en el avance hacia la implementaci´ on de una plataforma experimental, econ´ omica y flexible para HPRC con el objetivo de permitir el desarrollo de nuevos trabajos y estimar el impacto que este paradigma de computaci´ on reconfigurable puede tener.

Descripci´ on del proyecto Este trabajo es la base para la implementaci´ on de una plataforma que permite llevar a cabo aplicaciones HPRC, la cual ofrece los mecanismos para reconfigurar un FPGA en un entorno de computaci´ on paralela. Los sistemas HPRC se caracterizan por ser una combinaci´on de PPGs y FPGAs interconectados por una red de datos. Seg´ un como ´estos se organicen en los nodos de la red, se pueden clasificar como Uniform Nodes Non-uniform Systems (UNNS) y Non-uniform Nodes Uniform System (NNUS). En los sistemas UNNS se encuentra en cada uno de los nodos un solo tipo de procesador, es decir FPGA o PPG, mientras que los sistemas NNUS se caracterizan por tener todos los nodos homog´eneos con igual cantidad de PPG y de FPGAs en cada uno de ellos. [6] El sistema HPRC que se realiz´ o, est´ a representado en la Figura 0.1. En esta se observa la interconexi´on de PPG y sistemas de desarrollo ML507 de FPGAs mediante una red de datos ethernet formando un sistema tipo UNNS. Se seleccion´ o esta arquitectura porque sigue la filosof´ıa de los cluster beowulf, lo cual lo hace flexible durante su implementaci´ on facilitando la adici´on de nodos. As´ı mismo el usuario puede decidir f´acilmente la cantidad de FPGAs y PPG que desea usar para llevar a cabo la aplicaci´on.

Figura 0.1: Diagrama general

El proyecto se desarroll´ o mediante la implementaci´ on en el FPGA de un embedded system basado en Universidad Industrial de Santander

18

Lista de Tablas R un procesador PowerPC , el cual tiene las funciones de un sistema reconfigurable y de un nodo del cluster R heterog´eneo formado con los PPG. Como sistema reconfigurable, el PowerPC puede modificar el estado

de sus recursos l´ ogicos para implementar perif´ericos que le pueden ayudar a efectuar funciones de c´alculo R intensivo; y como nodo del cluster, el PowerPC puede recibir carga e interactuar dentro de un entorno

de computaci´ on paralela. La implementaci´ on del sistema se realiz´ o seg´ un el diagrama mostrado en la Figura 0.2. Inicialmente R con sus perif´ericos b´asicos se cre´o el sistema base de la plataforma de c´omputo, es decir el PowerPC R interconectados por el bus PLB, mediante la herramienta EDK del fabricante del FPGA, Xilinx

.

Posteriormente se procedi´ o a instalar un bootloader que permitiera al sistema iniciar un sistema operativo . Para que el sistema operativo pudiera correr, fue necesario compilar el kernel, preparar un sistema de archivos NFS, adem´ as de configurar otros servicios de red

. Al mismo tiempo, se instal´o un cluster

de PPG que al ser integrado con el FPGA, se convirti´ o en un cluster heterog´eneo formado por FPGAs y PPG

.

Figura 0.2: Pasos de la implementaci´ on del sistema.

El siguiente paso consisti´ o en permitir que el embedded system tenga la capacidad de reconfigurar parcialmente sus recursos l´ ogicos Para ello, se implement´ o un perif´erico basado en el m´odulo Internal Configuration Access Port (ICAP) del FPGA y se desarroll´ o un driver para el sistema operativo que permitiera administrar el perif´erico y los recursos l´ ogicos bajo demanda por parte de los procesos que R se ejecutan en el procesador PowerPC . Y de esta forma el sistema pudo recibir desde el cluster una

orden para reconfigurar sus recursos l´ ogicos, con lo que se finaliz´o la implementaci´ on del sistema HPRC.

Universidad Industrial de Santander

19

.

Lista de Tablas Finalmente se estableci´ o un procedimiento para determinar el correcto funcionamiento y medir el desempe˜ no de la reconfiguraci´ on para establecer el impacto que tiene sobre una aplicaci´on.

Mapa del documento Este documento recopila el proceso de dise˜ no, las experiencias y la implementaci´ on del sistema HPRC descrito en la secci´on anterior. Est´a distribuido en cap´ıtulos de la siguiente forma: Cap´ıtulo 1: En este cap´ıtulo se presenta el proceso de implementaci´ on del embedded system sobre el R FPGA, basado en el procesador PowerPC , desde su implementaci´ on en EDK hasta la instalaci´on

y configuraci´ on del sistema operativo. on del FPGA, de la Cap´ıtulo 3: En este cap´ıtulo se introducen los conceptos b´asicos de la configuraci´ arquitectura del FPGA y los archivos de configuraci´ on. Adem´ as como resumen de la documentaci´ on del fabricante y del proceso de ingenier´ıa inversa, se presenta un script en matlab que interpreta un archivo de configuraci´ on. Cap´ıtulo 4: En este cap´ıtulo se documenta todo el proceso de adici´on del perif´erico que permite hacer la reconfiguraci´ on y su puesta en marcha desde el entorno de EDK y el entorno del sistema operativo. Adicionalmente se presenta una aplicaci´ on desarrollada que permiti´o determinar y validar exactamente cuales bits del bitstream modifican el comportamiento de las LUT del FPGA. Cap´ıtulo 5: Finalmente en este cap´ıtulo se recopilan las conclusiones a las que se lleg´ o despu´es de llevar a cabo esta implementaci´ on y la continuidad que se le puede dar a esta investigaci´on en el futuro.

Universidad Industrial de Santander

20

Cap´ıtulo

´ del Embedded System Sobre el Implementacion FPGA A lo largo del presente cap´ıtulo, se presentar´an los detalles de la implementaci´ on del embedded system. La Figura 1.1 muestra los bloques del sistema que est´ an involucrados en este cap´ıtulo, mientras la Figura 1.2 muestra el avance de esta implementaci´ on dentro del proceso general. A continuaci´on se exponen algunos detalles de la plataforma y las herramientas empleadas y posteriormente se presentan detalles sobre la implementaci´ on del sistema.

Figura 1.1: Diagrama general

1.1

Sistema de desarrollo ML507

Para llevar a cabo el proyecto se seleccion´ o el sistema de desarrollo ML507, el cual es una plataforma de prop´osito general para aplicaciones que involucran FPGA, RocketIO GTX o embedded system[2]. Esta Universidad Industrial de Santander

21

1

Sistema de desarrollo ML507

Figura 1.2: Pasos de la implementaci´ on del sistema.

R XC5VFX70TFFG1136 de la familia plataforma tiene como componente principal el FPGA de Xilinx

Virtex-5, cuyos recursos se resumen en la Tabla 1.1. Esta familia de FPGA est´ a orientada hacia el desarrollo de embedded system con comunicaciones seriales de alta velocidad, por lo que dispone entre sus R y m´odulos RocketIO GTX. La Tabla 1.1 adicionalmente, recursos de un n´ ucleo del procesador PowerPC

dimensiona la cantidad de recursos del FPGA seleccionado al compararlo respecto al miembro m´as grande y al m´as peque˜ no de la subfamilia FX de la Virtex-5. Dispositivo XC5VFX30T XC5VFX70T XC5VFX200T

Configurable Logic Arreglo V5 FilxCol Slices 80 x 38 5120 160 x 38 11200 240 x 68 30720

Blocks RAMD (Kb) 380 820 2280

Slices DSP48E 64 128 384

Bloques RAM 36 Kb Max (Kb) 68 2448 148 5328 456 16416

CMTs

PowerPC Blocks

Ethernet MACs

2 6 6

1 1 2

4 4 8

Max User I/O 360 640 960

Tabla 1.1: Recursos del FPGA (Adaptado de [4])

El diagrama de bloques del sistema ML507 se presenta en la Figura 1.3. En ´el se resumen los recursos del sistema y se resaltan los componentes utlizados en la realizaci´ on del proyecto. Cabe aclarar que debido a que la tarjeta es un sistema de desarrollo, no todos sus recursos son empleados, pero aplicaciones futuras pueden hacer uso de ellos. Como dispositivo central se encuentra el FPGA, el cual dispone de recursos l´ ogicos con los que se implement´ o el sistema base y la secci´on reconfigurable. Como elementos de almacenamiento permanente, se emple´ o la memoria Platform Flash que almacen´ o el archivo de configuraci´ on del FPGA con el sistema base; la memoria Flash que contiene el ejecutable del bootloader y podr´ıa ser usada para almacenar el kernel del sistema operativo; y la memoria I2C que almacen´ o los par´ ametros de u-boot del arranque del sistema. La implementaci´ on de la memoria RAM DDR2 y la interfaz de ethernet, complementaron el sistema para permitir la ejecuci´ on del sistema operativo y el acceso a los servicios de red. El puerto RS-232 Universidad Industrial de Santander

22

Integrated Software Environment (ISE)

Figura 1.3: Diagrama de bloques del sistema de desarrollo ML507 (Adaptado de [2])

permiti´o implementar la entrada y salida est´ andar por consola en un terminal, y los dem´ as perif´ericos como los GPIO, y la pantalla LCD permiten desplegar informaci´on del sistema o hacer pruebas.

1.2

Integrated Software Environment (ISE)

El entorno de trabajo Integrated Software Environment (ISE) es un conjunto de herramientas software que permite llevar hacer el dise˜ no de un circuito desde el ingreso de las fuentes hasta su implementaci´ on sobre un dispositivo FPGA o CPLD. Estas herramientas se acceden por medio de una interfaz gr´ afica que ilustra el flujo de dise˜ no de un circuito digital, adem´ as permite administrar y acceder a los archivos intermedios que se generan durante el proceso como por ejemplo los reportes de cada una de las etapas. La administraci´on de los archivos permite manejar proyectos que comprometen gran cantidad de archivos fuentes o jerarqu´ıas en el dise˜ no. Para entender mejor las funciones de la herramienta que aplican al proyecto, es necesario comprender el flujo de dise˜ no de circuitos sobre FPGA.

1.2.1

Flujo de dise˜ no tradicional con FPGA (Tomado de [1])

R est´ a bien definida por el La metodolog´ıa para la implementaci´ on de un circuito en un FPGA Xilinx

fabricante y se puede resumir en el diagrama de la Figura 1.4. En ella se pueden observar los procesos y los archivos intermedios en el proceso desde que se ingresa los archivos fuente hasta la generaci´on del archivo de configuraci´ on del dispositivo. Estos procesos se pueden agrupar en tres secciones: la s´ıntesis, la implementaci´ on y la validaci´ on. Para implementar un dise˜ no es necesario llevar a cabo solo las dos primeras etapas, por lo tanto el texto profundizar´a u ´nicamente en estas dos secciones.

Universidad Industrial de Santander

23

Integrated Software Environment (ISE)

Figura 1.4: Flujo de dise˜ no con FPGA (Adaptado de [1])

1.2.1.1

Ingreso de archivos fuente

En esta etapa, el dise˜ nador ingresa o crea los archivos fuentes del proyecto. Existen diferentes tipos de archivos fuente, seg´ un la etapa de dise˜ no a la cual afectan. Los archivos que contienen la informaci´on del funcionamiento o interconexi´on del circuito que se va a implementar se pueden ingresar en modo esquem´atico (gr´afico) o por medio de un lenguaje de descripci´on de hardware (HDL). Los archivos que imponen restricciones a las herramientas software se pueden ingresar en modo texto o en modo gr´ afico por medio de una interfaz gr´ afica. Estas restricciones pueden estar relacionadas con la ubicaci´ on de las partes del dise˜ no en el FPGA o restricciones de tiempos o frecuencias de trabajo de algunas se˜ nales. Finalmente algunas fuentes est´ an orientadas a la simulaci´on del dise˜ no a diferentes niveles; ´estas fuentes se pueden ingresar por medio de un lenguaje de HDL o mediante una interfaz gr´ afica otorgada por el simulador de ISE.

Universidad Industrial de Santander

24

Embedded Development Kit (EDK) 1.2.1.2

S´ıntesis

Una vez ingresados los archivos fuente, la herramienta de s´ıntesis los interpreta y crea a partir de ellos un archivo de objetos gen´ericos que contiene la informaci´on de los componentes e interconexiones del circuito a implementar. Este proceso se lleva a cabo en dos etapas: la primera la lleva a cabo la herramienta XST que crea un netlist del circuito (archivo NGC) y posteriormente la herramienta NGDBuild crea una base de datos (archivo NGD) que contiene la descripci´on l´ ogica del circuito y su jerarqu´ıa. 1.2.1.3

Mapping

R Durante esta etapa se hace una asociaci´ on de las primitivas1 de Xilinx que se encuentran en el archivo R NGD a elementos propios del FPGA de Xilinx sobre el cual se va a implementar el circuito. Uno de los

archivos de salida es de extensi´ on NCD, el cual es una descripci´on f´ısica del dise˜ no en funci´on de elementos del FPGA a emplear; el otro es de extensi´ on PCF, el cual incluye una traducci´on a restricciones f´ısicas de las restricciones del archivo UCF ingresado por el usuario. Este proceso de mapping puede variar considerablemente cuando implementa el circuito sobre una u otra familia de FPGA. 1.2.1.4

Place and Routing

Esta etapa busca seleccionar los recursos que se van a emplear para la implementaci´ on del dise˜ no y realizar la interconexi´on que el dise˜ no exija para su correcto funcionamiento. Esta etapa se puede llevar a cabo de forma autom´atica y manipulada por medio de restricciones o manualmente por medio de las herramientas FPGA Editor y PlanAhead. 1.2.1.5

Generaci´ on del archivo de configuraci´ on

Finalmente una vez seleccionados los recursos a usar, se procede a crear el archivo de configuraci´ on que contiene la informaci´on para ajustar cada uno de los elementos a usar en el FPGA y su interconexi´on con los dem´ as. Con este archivo es posible configurar el FPGA o crear un archivo a partir de ´el para programar una memoria de configuraci´ on externa al FPGA.

1.3

Embedded Development Kit (EDK)

El entorno de trabajo Embedded Development Kit (EDK), permite crear sistemas de c´omputo basados R en los procesadores PowerPC y MicroBlaze. Mediante su interfaz gr´ afica se puede manipular tanto el

software que se ejecuta en el procesador como la interconexi´on de los elementos del sistema, los buses, interrupciones y dem´ as elementos del hardware. La implementaci´ on de estos sistemas se realiza en FPGAs 1 La palabra primitiva ser´ a usada como traducci´ on del t´ ermino del idioma ingl´ es primitive que hace referencia a los elementos l´ ogicos b´ asicos que componen un FPGA y que pueden aparecer como instancias en una descripci´ on HDL.

Universidad Industrial de Santander

25

Embedded Development Kit (EDK) R de Xilinx , por lo EDK hace uso de las herramientas de s´ıntesis e implementaci´ on de ISE. Adem´ as de

las herramientas para la implementaci´ on del dise˜ no, EDK permite realizar la simulaci´on del sistema o la depuraci´on paso a paso del programa mientras se ejecuta en el procesador. En la interfaz de EDK, el proceso de implementaci´ on es presentado al usuario en forma de men´ u, donde se llevan a cabo secuencialmente un conjunto de ´ordenes que est´ an representadas en la Figura 1.5. Cada una de las ´ ordenes involucra la ejecuci´ on de programas de ISE y algunas otras aplicaciones complementarias. Durante las siguientes secciones del documento se ampliar´a lo que sucede en cada una de las etapas del proceso.

1.3.1

Hardware > Generate Netlist

Durante esta etapa, EDK se encarga de sintetizar cada uno de los m´odulos del dise˜ no, es decir, cada perif´erico, interfaz de bus, procesador, controlador de memoria, etc. Para ello usa la herramienta xst y de cada uno de ellos, se genera un archivo netlist NGC; as´ı mismo se genera un archivo NGC del sistema completo que contiene u ´nicamente cajas negras interconectadas.

1.3.2

Hardware > Generate Bitstream

R En esta etapa, se realiza toda la implementaci´ on del sistema, donde se emplean las herramientas de Xilinx

NGDBuild, map, par y BitGen para generar finalmente el archivo system.bit, que permite configurar el FPGA con el sistema dise˜ nado, pero este sistema carece de un programa de arranque.

1.3.3

Software > Build User Applications

Esta funci´on de EDK se encuentra del lado de la implementaci´ on del software y busca compilar el programa que se desea que el procesador ejecute al energizarse el sistema. Su resultado es un archivo ejecutable de extensi´ on ELF.

1.3.4

Device Configuration > Update Bitstream

Mediante esta funci´on se hace la integraci´ on hardware/software y consiste en la adici´on del c´odigo compilado a los bloques RAM del sistema. Para efectuar esta tarea, se emplea el ejecutable Data2Mem que toma el ejecutable de extensi´ on ELF, el archivo de configuraci´ on system.bit y un archivo BMM para generar un nuevo archivo de configuraci´ on actualizado. El archivo BMM es un archivo de texto que contiene la ubicaci´ on de los bloques de memoria cuando se ejecut´ o PAR durante la implementaci´ on.

Universidad Industrial de Santander

26

Embedded Development Kit (EDK)

1.3.5

Device Configuration > Download Bitstream

Esta funci´on finalmente descarga el archivo de configuraci´on al FPGA ejecutando un script para el software iMPACT encargado de manejar el puerto JTAG para la configuraci´ on del FPGA.

Figura 1.5: Flujo de EDK

1.3.6

PlanAhead

Es una herramienta complementaria a ISE que permite optimizar la implementaci´ on de un dise˜ no porque permite manipular m´as f´acilmente las restricciones tanto de ubicaci´ on de componentes como las de tiempos. Adicionalmente permite realizar varias veces la implementaci´ on bajo diferentes par´ ametros con el objetivo R de encontrar la mejor implementaci´ on. Por otro lado, Xilinx ha integrado su u ´ltima versi´on del flujo

Universidad Industrial de Santander

27

Implementaci´ on del sistema base de dise˜ no de reconfiguraci´ on parcial con esta herramienta. Dentro del proceso de implementaci´ on, se ha usado esta herramienta para restringir el sistema base a un sector espec´ıfico del FPGA, cumpliendo las restricciones de tiempo propias del mismo. Aunque este proceso ser´a explicado m´as ampliamente en el cap´ıtulo 4.

1.4

Implementaci´ on del sistema base

Teniendo en cuenta los requerimientos b´asicos del sistema y los recursos disponibles en el sistema de R y los perif´ericos. desarrollo ML507, se configur´ o el sistema base compuesto por el procesador PowerPC

Esto se hizo con ayuda del asistente para la creaci´on de un nuevo proyecto, el cual permite seleccionar entre los perif´ericos disponibles, cuales se quieren implementar en el sistema. La Tabla 1.2 presenta el mapa de memoria del sistema, donde se listan los componentes del sistema y el rango de memoria asignado.

Elemento R Procesador PowerPC 440 Bloque RAM GPIO Leds GPIO Positions GPIO PushButtons GPIO DipSwitch IIC EEPROM Controlador de Interrupciones MAC HW Ethernet SysACE CompactFlash Temporizador Watchdog Temporizador Puerto Serie RS-232 RAM DDR2 Memoria Flash

Direcci´ on base

Tama˜ no Rango

0xFFFF0000 0x81400000 0x81420000 0x81440000 0x81460000 0x81600000 0x81800000 0x81C00000 0x83600000 0x83A00000 0x83C00000 0x83E00000 0x00000000 0xFC000000

64K 64K 64K 64K 64K 64K 64K 64K 64K 64K 64K 64K 256MB 32MB

Tabla 1.2: Mapa de memoria del sistema base

1.5

Sistema operativo

El sistema operativo es el software que, en un sistema de c´omputo, administra los recursos que ´este posee como los perif´ericos, el procesador, la memoria, el acceso al sistema de archivos, etc. El sistema operativo interact´ ua con las aplicaciones y los procesos que se est´ an ejecutando y les permite acceder al hardware del sistema mediante colas y otros mecanismos definidos en el kernel del mismo. Esta es la parte m´as importante del sistema operativo, debido a que brinda a las aplicaciones una abstracci´on del hardware

Universidad Industrial de Santander

28

Sistema operativo sencilla con mecanismos de acceso. De la misma forma en que se administran los perif´ericos y la memoria, el kernel puede administrar el tiempo de uso del procesador y as´ı multiplexar el uso del mismo y generar un entorno multi-tareas. Para el desarrollo del proyecto se manej´o el sistema operativo Linux debido a su amplia documentaci´ on y su c´odigo abierto. Este se emple´ o tanto en los nodos del cluster, como en el sistema de desarrollo ML507. La utilizaci´ on de un sistema operativo en el sistema ML507 tiene su justificaci´ on debido a los siguientes aspectos: La administraci´ on de los recursos l´ ogicos del sistema: Un sistema operativo permitir´ıa la administraci´on de los recursos l´ ogicos del FPGA bajo un modelo de abstracci´on para el usuario que facilite su utilizaci´ on; de forma similar a la administraci´on de la memoria en un sistema. El dise˜ no modular del kernel de Linux permitir´ıa crear esta estructura para la implementaci´ on posterior de aplicaciones. La necesidad de integrar la plataforma dentro de un cluster de procesadores Linux: Con el objetivo de que el sistema pueda ser reconocido e interact´ ue con los dem´ as nodos del cluster, es necesario que ´este ejecute servicios de red, servicios para desplegar entornos paralelos, servicios de monitorizaci´on y administraci´on del cluster, etc. Esta tarea se facilita significativamente si se trabaja en un entorno multitarea Linux con la misma distribuci´ on a lo largo de todo el cluster. Es posible encontrar gran variedad de distribuciones de Linux, que se diferencian en la adici´on o configuraci´on de algunos paquetes que son de inter´es para alg´ un grupo de usuarios. Aunque casi ninguna distribuci´ on realiza cambios sobre el n´ ucleo, la uniformidad en la distribuci´ on de Linux a lo largo del sistema facilita la configuraci´ on del mismo y elimina uno de los factores que definen un cluster como heterog´eneo[7]. Por ello se ha decidido utilizar la distribuci´ on Debian. Debido a la estandarizaci´ on de las plataformas de c´omputo de prop´osito general, la instalaci´on y el manejo de Linux se puede llevar a cabo sin necesidad de tener muchos detalles sobre el funcionamiento del sistema operativo, gracias a las herramientas que se han generado para la automatizaci´ on de estos procesos. En el caso de un embedded system, como lo es el sistema de desarrollo ML507, es necesario conocer m´as a fondo la plataforma y el sistema operativo para instalarlo y configurarlo adecuadamente.

1.5.1

Arranque del Sistema operativo

Antes de realizar la instalaci´ on del sistema operativo fue necesario comprender c´omo es el proceso de afica este proceso. Para que un sistema arranque del mismo; las Figuras 1.6 y 1.7 muestran de forma gr´ operativo Linux pueda iniciar, requiere como m´ınimo disponer de un sistema de archivos y del ejecutable Universidad Industrial de Santander

29

Sistema operativo de un kernel ; el archivo DTB no es obligatorio, pero ofrece informaci´on acerca del hardware del sistema. Estos archivos pueden estar ubicados en una memoria local dentro del sistema de desarrollo ML507, o pueden estar en un servidor de archivos remoto. En caso de que el sistema est´e en etapa de desarrollo, puede ser m´as f´acil trabajar con un servidor de archivos, debido a que este puede estar ubicado en el mismo equipo host; mientras que si el sistema ya pas´ o a la etapa de producci´on, es mejor que estos archivos se encuentren de forma local debido a que esto agilizar´ıa el arranque del sistema operativo.

Figura 1.6: Alternativa orientada al desarrollo

Figura 1.7: Alternativa para un funcionamiento definitivo.

En las Figuras 1.6 y 1.7 tambi´en se observa que el primer software que se ejecuta al iniciar el sistema no es el del sistema operativo. Normalmente el primer software que se ejecuta, prepara el sistema para ejecutar el bootloader, el cual es un software m´as elaborado que realiza los preparativos para cargar el sistema operativo en s´ı. En el caso del sistema impementado, nos referiremos al primer software que se ejecuta como pre-bootloader. Su funci´on es cargar en la memoria RAM el archivo del bootloader que ha sido previamente almacenado en la memoria Flash del sistema para desde ah´ı ejecutarlo. El bootloader es un software que se encarga de detectar los recursos disponibles en el sistema y ofrecer mecanismos para descargar o configurar el kernel y el sistema de archivos requerido para el arranque del sistema operativo. El bootloader puede configurar los perif´ericos del sistema como la interfaz de red para acceder a servidores de archivos; algunos bootloader implementan un int´erprete de comandos que permite interactuar con el usuario para configurar los par´ ametros de inicio del sistema. El bootloader seleccionado para el sistema fue u-boot. Los requerimientos del sistema en cuanto a la selecci´on sugieren que este debe permitir acceder al kernel por medio de la red de datos, debido a que esto facilita la actualizaci´ on del kernel en el cluster principalmente en la etapa de la implementaci´ on donde es Universidad Industrial de Santander

30

Sistema operativo posible que se requiera compilar el kernel varias ocaciones. Esta facilidad est´ a representada en el hecho de que todos los nodos de FPGA pueden acceder al mismo kernel por medio de un servidor de archivos y en que no es necesario descargarlo a una memoria local no vol´ atil para que comience a trabajar. Otro requerimiento est´ a relacionado con el tama˜ no del ejecutable, el cual debe permitir que este se almacene en la memoria Flash del sistema. La mayor´ıa de bootloaders cumplen esta condici´ on pero la afinidad que tiene u-boot con las herramienR y el trabajo adelantado en esta ´area por el grupo de trabajo de [8] permiti´o seleccionar tas de Xilinx

esta alternativa.

1.5.2

Entorno de trabajo del sistema de desarrollo.

El desarrollo de sistemas embebidos, normalmente requiere el uso de sistemas host como lo muestra la Figura 1.8. Durante el desarrollo del proyecto se emple´ o el equipo que iba a tomar el papel de maestro en el cluster para esta tarea.

Figura 1.8: Entorno de trabajo para el desarrollo e implementaci´ on del embedded system

Este sistema host permite al sistema target realizar las siguientes funciones: • Las herramientas cruzadas y de desarrollo para el sistema target, permiten compilar aplicaciones y generar archivos de configuraci´ on para el FPGA. • Extender los perif´ericos del sistema al manejar el puerto serie RS232 como salida y entrada est´ andar. • Depurar la ejecuci´ on en software y hardware mediante el protocolo JTAG y las herramientas del fabricante del FPGA. • Intercambiar informaci´on mediante la red de datos ethernet. En esta red pueden correr gran variedad de servicios de red que amplian las posibilidades para el sistema target. Basado en este entorno de desarrollo, la implementaci´ on del pre-bootloader, el u-boot y el sistema operativo se llev´o acabo como se muestra en la Figura 1.9.

Universidad Industrial de Santander

31

Sistema operativo

Figura 1.9: Instalaci´on y configuraci´ on del bootloader y los requerimientos del sistema operativo

1.5.3

Instalaci´ on del bootloader

Para llevar a cabo la instalaci´ on de u-boot se requeire compilar el c´odigo fuente, por lo cual se requiri´o R un compilador cruzado que permita crear el ejecutable para el procesador PowerPC desde el computador

host de arquitectura x86. El compilador cruzado normalmente est´ a incluido dentro de un conjunto de herramientas de desarrollo llamadas toolchain, el cual incluye las herramientas GNU b´asicas para la generaci´on cruzada de ejecutables como: ar, as, g++, gcc, gdb, ld, readelf, etc. Para este proyecto se emple´ o el Embedded Linux Development Kit (ELKD), el cual es una compilaci´on de herramientas, que incluyen el toolchain, que permiten implementar Embedded Linux y configurarlo con un sistema de paquetes basado en RPMs. Una vez instaladas las herramientas se compil´o el bootloader, para lo cual se descargaron las fuentes del sitio git://git.xilinx.com/u-boot-xlnx.git/. Se comprob´ o que el archivo xparameters.h del c´odigo fuente fuera el mismo que se gener´ o con EDK en el sistema base, se dejaron las opciones del c´odigo por defecto y se compil´o con ayuda del makefile que est´ a en la fuente. La instalaci´ on del ejecutable en el sistema consiste en que este se almacene en la memoria flash, para lo cual fue necesario crear el pre-bootloader que cargara el ejecutable a la RAM y comenzara la ejecuci´ on del bootloader. Para esta tarea se emple´ o EDK, debido a que ´este permite especificar el programa de arranque y permite llevar informaci´on desde la memoria del host a la memoria flash del sistema. Con esta etapa finalizada, el sistema fue capaz de iniciar el bootloader y se pudo emplear la l´ınea de comandos para configurar manualmente el arranque.

Universidad Industrial de Santander

32

Sistema operativo

1.5.4

Compilaci´ on del kernel

Compilar el kernel de Linux es una tarea comunmente realizada durante el desarrollo de embedded system, esto permite generar un ejecutable m´as liviano u ´nicamente con los m´odulos necesarios por el sistema. La configuraci´ on del kernel requiere de experiencia, conocimiento del hardware y de las aplicaciones que estar´an ejecut´ andose. Para la compilaci´on realizada para el proyecto, se accedi´ o al sitio http://git.xilinx.com/ R que contiene un kernel preconfigurado para los sistemas de desarrollo de Xilinx y para los procesadores R MicroBlaze y PowerPC .

Las modificaciones m´as relevantes para el sistema est´ an relacionadas con la generaci´on del archivo DTB que contiene informaci´on sobre el hardware disponible en la tarjeta y a trav´es de ´el se pueden establecer los par´ ametros de arranque del kernel. Estos se definieron de la siguiente forma en el archivo DTS: 1 2 3 4 5

bootargs =

console=ttyS0 ip=on root=/dev/nfs nfsroot=192.168.16.150:/opt/debian/ppc_4xxFP_Okinawa-21,tcp rw local-mac-address = [ 00 0A 35 01 D7 4E ];

La generaci´on del archivo DTB require la compilaci´on del archivo DTS mediante el script DTC, disponible en la fuente del kernel. Finalmente el kernel se ha compiado cargando las opciones por defecto R 440 e indicando al momento de compilar que el kernel iba a ser cargado para el procesador PowerPC

por u-boot para que se a˜ nadiera el cabecero requerido por este. Terminado esta etapa, se procedi´ o a crear el sistema de archivos base para el sistema operativo.

1.5.5

Sistema de archivos

Un sistema de archivos permite organizar y almacenar informaci´on ofreciendo m´etodos de acceso a los datos que lo componen y administrando el dispositivo de almacenamiento. En el caso del proyecto, se ha optado por implementar un sistema de archivos remoto de tipo NFS, aprovechando el entorno de computaci´ on paralela que se despliega en el cluster. El kernel puede acceder al sistema de archivos gracias a la configuraci´ on realizada al crear el archivo DTB y este se implement´ o en el nodo maestro del cluster. El sistema de archivos est´ a ubicado en un subdirectorio del nodo host, y su creaci´on se realiza de forma similar a la instalaci´ on que se hace de un sistema operativo en un ordenador personal. El hecho de que el sistema de archivos est´e sobre un equipo con una arquitectura diferente al que lo va a usar, representa una dificultad, debido a que gran parte de los archivos base para el sistema operativo son ejecutables y librer´ıas din´ amicas compiladas para la arquitectura que va a correr el sistema operativo.

Universidad Industrial de Santander

33

Sistema operativo El sistema de archivos guarda relaci´ on con la distribuci´ on de linux que se seleccion´ o, para ello la herramienta emplea un repositorio de Debian vesi´ on Lenny, la misma que se seleccion´ o para el cluster. Inicialmente la herramienta descarga los archivos necesarios para un sistema base, y posteriormente es necesario que se ejecute una segunda etapa directamente por el procesador que usar´a el sistema. Finalmente dentro de la preparaci´on que se puede hacer al sistema de archivos se pueden modificar los archivos de configuraci´ on desde el host para que estos se adapten a los par´ ametros que este nodo tendr´ a dentro de la red de datos.

1.5.6

Configuraci´ on de u-boot

Una vez compilado el kernel y el u-boot, configurado el sistema de archivos y generado el archivo DTB, se configuraron los par´ ametros de u-boot para que ´este permita iniciar el sistema de forma autom´atica. Para ello fue necesario iniciar u-boot mediante la opci´on de la l´ınea de comandos donde se puedieron realizar ajustes y pruebas sobre el tipo de arranque y los par´ ametros del mismo. Una vez quedaron establecidos los par´ ametros de arranque, se compil´o nuevamente el u-boot de modo que estos par´ ametros de inicio quedaran fijos. Esto se hizo modificando la variable CONFIG_EXTRA_ENV_SETTINGS del c´odigo fuente, lo cual permite crear un peque˜ no script basado en variables de entorno. Al iniciar, u-boot despliega un conteo regresivo para permitir al usuario interrumpir la ejecuci´ on autom´atica. En caso de terminar el conteo, u-boot ejecuta el comando almacenado en la variable de entorno CONFIG BOOTCOMMAND el cual fue ajustado al valor ‘‘run bootnfs’’, lo cual realiza las siguientes acciones: • Carga el kernel y el archivo DTB por TFTP. • Borra la variable del sistema de archivos en RAM, debido a que se va a usar el sistema de archivos en red (NFS). • Iniciar el sistema operativo. Las modificaciones realizadas se resumen en el siguiente cuadro: 1 2

Modificaciones a las variables de entorno de u-boot #define CONFIG_BOOTCOMMAND "run bootnfs"

3 4 5 6 7 8

#define CONFIG_EXTRA_ENV_SETTINGS \ "serverip=192.168.16.150\0" \ "ipaddr=192.168.16.171\0" \ "bootnfs=run loadkernel;run loaddtb;setenv ramimg_addr -;run runkernel\0" \ "boottftp=run loadkernel;run loadramimg;run loaddtb;run runkernel\0" \

Universidad Industrial de Santander

34

Resumen del cap´ıtulo 9 10 11 12 13 14 15 16 17 18

"loadkernel=tftp $(kernel_addr) $(bootfile)\0" \ "kernel_addr=0x1c00000\0" \ "bootfile=Linuxboot/uImage\0" \ "loadramimg=tftp $(ramimg_addr) $(ramfile)\0" \ "ramimg_addr=0x1800000\0" \ "ramfile=Linuxboot/ramimg.gz\0" \ "loaddtb=tftp $(dtb_addr) $(dtbfile)\0" \ "dtb_addr=0x1000000\0" \ "dtbfile=Linuxboot/ml507-Okinawa-21.dtb\0" \ "runkernel=bootm $(kernel_addr) $(ramimg_addr) $(dtb_addr)\0" $

19

1.6

Resumen del cap´ıtulo

Con el avance mostrado en el presente cap´ıtulo, se ha configurado el sistema de desarrollo ML507 como un R que corre Linux Lenny con ayuda de varios servicios embedded system basado en el procesador PowerPC

de red y de un sistema de archivos NFS implementados sobre el nodo maestro del cluster. Esto ha permitido que tanto el sistema de desarrollo ML507, como el cluster obtengan beneficios mutuos. El sistema de desarrollo ha suplido requisitos para correr el sistema operativo, mientras el cluster ha ganado un trabajador con recursos l´ ogicos para procesamiento embebido.

Universidad Industrial de Santander

35

Cap´ıtulo

´ del cluster Configuracion ´ A lo largo del presente cap´ıtulo se presentan los aspectos m´as relevantes de la configuraci´ on del cluster heterog´eneo conformado por el nodo maestro Okinawa-00, nodos trabajadores Okinawa-01 y Okinawa-02 de arquitectura x86 implementados como m´aquinas virtuales y el sistema ML507 configurado como se mostr´ o en el cap´ıtulo 1. La Figura 2.1 muestra los elementos involucrados durante este proceso, mientras la Figura 2.2 presenta las etapas expuestas en este cap´ıtulo dentro del plan para el desarrollo del proyecto.

Figura 2.1: Diagrama general. Recursos empleados durante este cap´ıtulo. La estrategia adoptada para la configuraci´ on de las herramientas que permiten convertir el sistema en un cluster, inicialmente se centr´o en los nodos de arquitectura x86 y por u ´ltimo en los nodos FPGA. Esto debido a que la instalaci´ on y pruebas son m´as f´aciles de llevar a cabo sobre sistemas homog´eneos.

Universidad Industrial de Santander

36

2

Organizaci´on del cluster

Figura 2.2: Pasos de la implementaci´ on del sistema.

2.1

Organizaci´ on del cluster

Antes de iniciar las labores de configuraci´ on de los sistemas de c´omputo, se definieron algunos par´ ametros del sistema relacionados con el sistema de archivos compartido y las direcciones IP de cada uno de los nodos. La Figura 2.3 muestra la disposici´on f´ısica de los nodos y la asignaci´on de los par´ ametros de configuraci´ on de red.

Figura 2.3: Diagrama de la implementaci´ on f´ısica del sistema.

La organizaci´ on del sistema de archivos se realiz´ o con el objetivo de cumplir con los requerimientos que tiene el cluster y con los que tiene el sistema de desarrollo ML507 para ejecutar el sistema operativo. La Tabla 2.1 muestra la organizaci´ on final de los directorios compartidos. All´ı se observa que existen directorios que son compartidos entre todos los nodos del cluster y otros directorios que son compartidos para los nodos de una arquitectura en particular. De esta forma, la informaci´on que es com´ un, como por ejemplo los directorios home de los usuarios del cluster, pueden ser accedidos desde cualquier nodo; pero los archivos que son compilados para una arquitectura en particular, como ejecutables o librer´ıas son Universidad Industrial de Santander

37

Herramientas del cluster. accedidos en directorios compartidos para esa arquitectura. La Tabla 2.1 tambi´en muestra algunos directorios compatidos que corresponden a los sistemas de archivos de los nodos FPGA, tanto en su versi´on final, como en las etapas de desarrollo. Directorio compartido en el Nodo Maestro /compartido/comun /compartido/x86 /compartido/powerpc /opt/ELDK/4.2/ppc 4xxFP /opt/debian/ppc 4xxFP /opt/debian/ppc 4xxFP Okinawa-21

Punto de montaje en Nodos x86 /compartido/comun /compartido/x86 – – – –

Punto de montaje en R Nodos PowerPC /compartido/comun – /compartido/powerpc / (Solo durante la configuraci´ on inicial) / (Sistema de archivos base) / (Copia del sistema de archivos para Okinawa-21)

Tabla 2.1: Configuraci´ on del sistema de archivos compartido.

2.2

Herramientas del cluster.

Aunque cada herramienta fue probada inicialmente en el cluster homog´eneo que forman los nodos de arquitectura x86, la selecci´on de cada una de ellas y la asignaci´on de par´ ametros durante su instalaci´on se realiz´ o teniendo en cuenta que la implementaci´ on final es de uno heterog´eneo. Las herramientas seleccionadas para el desarrollo de aplicaciones paraleas fueron PVM y LAM-MPI, las cuales se caracterizan por dar soporte a cluster con cierto grado de heterogeneidad. Adicionalmente se instal´o ganglia como herramienta de monitorizaci´on.

2.2.1

Ajustes preliminares

Las herramientas que se instalaron, sugieren que el cluster disponga de algunos servicios de red y de algunas configuraciones particulares que son requeridas o que facilitan su funcionamiento. Dentro del cluster se realizaron espec´ıficamente los siguientes ajustes: Instalaci´ on de ssh: Esta utilidad es requerida por todas las heramientas porque da soporte a la seguridad de las conexiones entre los nodos del sistema. Usuarios del cluster : Los usuarios del cluster, fueron creados en cada uno de los nodos del mismo. Estos fueron configurados para que cuando se inicie sesi´on remota desde otro nodo, no se requiriera clave.

Universidad Industrial de Santander

38

Herramientas del cluster. Ubicaci´ on de los directorios de usuario: El directorio home de cada usuario se ubic´ o en un directorio compartido mediante NFS. De esta forma, con el mismo usuario, se accede a la misma informaci´on desde cualquier nodo. Servidor DNS: Es m´as f´acil siempre hacer referencia a los nodos del sistema mediante nombres que mediante sus IPs. Por ello se instal´o este servicio de red.

2.2.2

Instalaci´ on de PVM

La instalaci´ on de PVM requiere la compilaci´on de las librer´ıas y los servicios en cada una de las arquitecturas. Para ello se siguieron los procedimientos del sitio de soporte de la herramienta, donde tambi´en se descargaron las fuentes http://www.netlib.org/pvm3/. Inicialmente se realiz´ o este procedimiento con los nodos de arquitectura x86 y posteriormente con el nodo FPGA. En cada uno de los casos se ejecut´ o un programa de prueba para comprobar la funcionalidad de la librer´ıa, y los procedimientos para compilar y ejecutar el ejemplo en ambas arquitecturas. Los detalles de la instalaci´on y las pruebas realizadas se encuentran en el Anexo A. Al ejecutar el programa de ejemplo, se solicit´ o que cada uno de los nodos del sistema imprimiera la fecha y la hora locales. La salida fue como se muestra a continuaci´on: william@Okinawa-00# ./helloPVM_master The master process runs on Okinawa-00 I found the following hosts in your virtual machine Okinawa-00 Okinawa-01 Okinawa-02 Okinawa-21 Okinawa-22 Comienzo intento con el servidor numero 0 Comienzo intento con el servidor numero 1 Comienzo intento con el servidor numero 2 Comienzo intento con el servidor numero 3 Comienzo intento con el servidor numero 4 Okinawa-00’s time is Thu Jan 19 16:15:45 2010 Okinawa-01’s time is Thu Jan 19 09:03:18 2010 Okinawa-02’s time is Thu Jan 19 09:01:34 2010 Okinawa-21’s time is Thu Jan 19 16:15:45 2010 Okinawa-22’s time is Thu Jan 19 16:15:46 2010

Universidad Industrial de Santander

39

Resultados del cap´ıtulo

2.2.3

Instalaci´ on de LAM-MPI

La instalaci´ on de LAM-MPI requiri´o, al igual que PVM, que cada una de las arquitecturas compile las librer´ıas y los ejecutables de la herramienta. Adicionalmente fue necesario modificar los archivos de configuraci´on de la herramienta que describen la organizaci´ on del cluster. Las instrucciones seguidas en este proceso se encuentran en http://www.lam-mpi.org y los detalles del mismo se encuentran en el Anexo A. Para comprobar el funcionamiento de esta herramienta se ejecut´ o un programa de prueba, que identifica a cada uno de los nodos del sistema. Su salida se muestra a continuaci´on: william@Okinawa-00# Hello, World. I am 0 Hello, World. I am 1 Hello, World. I am 3 Hello, World. I am 2 Hello, World. I am 4

2.2.4

mpiexec -configfile my_appfile of 2 of 5 of 5 of 5 of 5

Instalaci´ on de Ganglia

Como herramienta de monitorizaci´on se seleccion´ o Ganglia, debido a que este ha sido usado ampliamente en diferentes implementaciones de clusters. Esta herramienta ofrece la posibilidad de consultar via web el hist´orico de caracter´ısticas de los nodos del cluster como el porcentaje de uso de la cpu y la memoria. Su puesta en marcha requiri´o la instalaci´ on de un servidor web, php y algunas herramientas web en el nodo maestro. La apariencia de ganglia se muestra en la Figura 2.4

2.3

Resultados del cap´ıtulo

Mediante el procedimiento descrito en el presente cap´ıtulo se logr´o implementar una plataforma de c´omputo paralelo compuesta por nodos con procesadores x86 de prop´osito general y FPGAs con procesadores R PowerPC . Se han instalado y configurado las dos herramientas m´as populares para c´omputo en paralelo

en sistemas heterog´eneos: LAM-MPI y PVM. Su funcionamiento se comprob´ o mediante programas de ejemplo y finalmente se instal´o la herramienta de monitorizaci´on ganglia.

Universidad Industrial de Santander

40

Resultados del cap´ıtulo

Figura 2.4: Visualizaci´on de los nodos del sistema en ganglia.

Universidad Industrial de Santander

41

Cap´ıtulo

´ de los bitstreams Interpretacion El prop´osito del presente cap´ıtulo es inicialmente presentar los conceptos b´asicos sobre la configuraci´ on del FPGA y la arquitectura del mismo. Debido a que la documentaci´ on de los archivos de configuraci´ on y la arquitectura del FPGA no est´ a completa, fue necesario hacer un proceso de ingenier´ıa inversa para interpretar estos archivos. Para ello fue necesario emplear algunas herramientas existentes y generar algunas. Al final del documento se presentan los primeros resultados obtenidos m´as relevantes. La Figura 3.1 muestra la etapa que se est´ a adelantando dentro de la metodolog´ıa completa del proyecto. Es posible adelantar parte de la ejecuci´ on de esta tar´ea debido a que gran parte de la documentaci´ on se obtuvo del fabricante.

Figura 3.1: Pasos de la implementaci´ on del sistema.

3.1

Configuraci´ on del FPGA

Un FPGA es un dispositivo electr´onico que consta de recursos l´ ogicos y recursos de interconexi´on que le permiten implementar cualquier circuito digital, siempre que se disponga de la cantidad de elementos Universidad Industrial de Santander

42

3

Configuraci´ on del FPGA l´ ogicos necesarios. El proceso de configurar el FPGA consiste en descargar a este, la informaci´on sobre la interconexi´on y configuraci´ on de sus recursos l´ ogicos para hacer que ´este se comporte como circuito digital en particular. Esta informaci´on es almacenada en el FPGA de forma vol´ atil, debido a esto es necesario configurar el FPGA cada vez que se enciende. As´ı mismo, este proceso puede repetirse una vez el dispositivo est´e configurado para modificar completamente o parcialmente el circuito implementado.

3.1.1

M´ etodos de configuraci´ on

Al energizar el FPGA, este no tiene ning´ un circuito implementado. Su archivo de configuraci´ on inicial debe ser descargado y para ello se emplean los pines dedicados para ello, los cuales pueden trabajar bajo diferentes modos seg´ un el estado de los pines M[2:0]. Estos modos de trabajo permiten obtener la informaci´on de configuraci´ on desde diferentes dispositivos de almacenamiento como memorias (seriales, paralelas), procesadores u otro dispositivo digital. La Tabla 3.1 presenta los modos de configuraci´ on v´ alidos en los FPGA Virtex 5.

M [2 : 0] 000

Modo Master Serial

001

Master SPI

010

Master BPI-Up

011

Master BPI-Down

100

Master SelectMAP

101

JTAG

110

Slave SelectMAP

111

Slave Serial

Descripci´ on Interfaz serie s´ıncrona donde el FPGA es el maestro. Permite manejar memorias PROM R fabricadas por el fabricante Xilinx Interfaz serie s´ıncrona donde el FPGA es el maestro. Permite manejar memorias gen´ericas de cualquier fabricante que manejen el protocolo SPI Interfaz Paralela de 8 o 16 bits donde el FPGA es maestro. Interfaz Paralela de 8 o 16 bits donde el FPGA es maestro. Interfaz Paralela de 8 o 16 bits donde el FPGA es maestro. Interfaz serie s´ıncrona por medio del conocido protocolo JTAG Interfaz Paralela de 8 o 16 bits donde el FPGA es esclavo. Interfaz serie s´ıncrona donde el FPGA es esclavo.

Tabla 3.1: Modos de configuraci´ on del FPGA

La interfaz JTAG emplea pines dedicados para esta interfaz y puede ser empleada en cualquier momento, incluso sin necesidad de configurar los pines M [2 : 0] en unos niveles particulares. Al momento de activarse la interfaz JTAG, cualquier otro modo de configuraci´ on queda deshabilitado. Los otros modos

Universidad Industrial de Santander

43

Configuraci´ on del FPGA de configuraci´ on emplean pines que pueden ser utilizados como pines de prop´osito general una vez est´e configurado el FPGA. Durante el desarrollo del proyecto, se emple´ o el modo JTAG en los momentos que se estuvo depurando el sistema base. Mientras que cuando el hardware se deb´ıa mantener fijo, se descarg´o el archivo de configuraci´ on en las memorias PROM del sistema de desarrollo, las cuales pueden configurar el FPGA por medio de SelectMAP maestro.

3.1.2

Arquitectura del FPGA V5FX70

Los FPGA son dispositivos con gran cantidad de recursos l´ ogicos que permiten implementar sistemas digitales. Estos recursos van desde los elementales Look up tables (LUT) y Flip Flops, hasta bloques de procesamiento DSP, bloques de comunicaciones y procesadores de prop´osito general enteros. Cada familia de FPGA se caracteriza por tener determinados recursos que la especializan en cierto tipo de tareas espec´ıfica ( procesamiento de se˜ nales, transmisi´on de datos, procesamiento embebido, etc). Todos estos recursos comparten el ´ area del chip y tienen una organizaci´ on ya establecida. En el FPGA seleccionado para el proyecto, la organizaci´ on se presenta en la Figura 3.2. El bloque m´as grande que se aprecia es R el procesador PowerPC , el cual seg´ un las proporciones de la imagen ocupa aproximadamente el 7% del

´area del chip.

Figura 3.2: Arquitectura del FPGA Virtex 5 FX70, donde se aprecia la organizaci´ on en filas, columnas y elementos l´ ogicos. (Im´ agenes tomadas de PlanAhead.)

El FPGA XC5VFX70TFFG1136 est´ a segmentado en 8 filas, las cuales a su vez est´ an divididas en Universidad Industrial de Santander

44

Configuraci´ on del FPGA columnas donde cada columna tiene solo un tipo de recurso l´ ogico (CLBs, RAMBs, IOB, etc). Cada columna tiene organizados verticalmente una cantidad de bloques l´ ogicos que var´ıa seg´ un el tipo de recurso. Durante el desarrollo de esta tesis, se tom´ o como objetivo llegar a la configuraci´ on de los LUTs que est´ an contenidos dentro de los Slices que a su vez est´ an contenidos en los CLBs del FPGA.

3.1.3

Bitstreams

Los bitstreams son archivos, normalmente binarios, que contienen la informaci´on necesaria para configurar el FPGA. Los bitstreams pueden ser descargados al FPGA de varias formas, y est´ an compuestos basicamente por escrituras y lecturas de los registros de configuraci´ on. Finalmente lo que buscan es manipular la memoria de configuraci´ on del FPGA. Con el objetivo de realizar la configuraci´ on parcial, fue necesario conocer la estructura del bitstream y la memoria de configuraci´ on, donde los t´erminos frame y paquetes tipo I y II adquieren vital importancia. 3.1.3.1

Frames

Los frames corresponden a las secciones del FPGA m´as peque˜ nas que se pueden reconfigurar parcialmente. Est´an compuestos por 41 palabras de 32 bits. El archivo de configuraci´ on del FPGA V5FX70 est´ a compuesto por 21.080 frames, los cuales se pueden direccionar mediante una palabra de 32 bits, segmentada en los siguientes campos:

Figura 3.3: Campos de la direcci´on de un Frame (Adaptada de [3])

Tipo de Bloque: Este campo hace referencia a 4 posibles valores que diferencian entre 4 tipos de informaci´on de configuraci´ on: • Configuraci´ on o interconexi´on de alg´ un recurso l´ ogico. • Contenido de un bloque RAM. • Configuraci´ on o interconexi´on de recursos especiales. • frames de bloques RAM que no son de configuraci´ on. Fila Superior o Inferior: Permite saber si la fila a la que se hace referencia est´ a en la mitad superior o inferior del FPGA.

Universidad Industrial de Santander

45

Int´erprete de bitstream en Matlab Direcci´ on de la Fila: Hace referencia a una de las filas del FPGA, las cuales est´ an numeradas comenzando desde el centro con el n´ umero cero. Direcci´ on de la columna: En el interior de la fila, hace referencia a una de las columnas, las cuales est´ an numeradas de izquierda a derecha comenzando en cero. Minor Address: Mediante este dato se direcciona cada uno de los frames que conforman una columna. El m´aximo valor de este campo var´ıa seg´ un el tipo de recurso l´ ogico que compone la columna seg´ un lo muestra la Tabla 3.2. Tipo de recurso CLB DSP Bloque RAM Bloque IO Clock column

N´ umero de frames por columna 36 28 30 54 4

Tabla 3.2: N´ umero de frames que componen cada una de las columnas seg´ un el tipo de recurso

3.1.3.2

Estructura del bitstream

Un bitstream es una serie de comandos y datos que son aplicados sobre los registros y la memoria de configuraci´on. M´as espec´ıficamente, el bitstream se compone de paquetes tipo I, que corresponden a escrituras y lecturas de los registros de configuraci´ on y paquetes tipo II que se usan en combinaci´on de paquetes tipo I para escribir grandes vol´ umenes de informaci´on. Inicialmente el bitstream contiene informaci´on del archivo como la hora y fecha en la que fue generado. Posteriormente configura los registros e inicia la comprobaci´ on del CRC y finalmente escribe el contenido del archivo de configuraci´ on.

3.2

Int´ erprete de bitstream en Matlab

De forma paralela con el desarrollo de la tesis se fue elaborando un script en Matlab que permiti´o recopilar R la informaci´on obtenida de los documentos t´ecnicos de Xilinx sobre la configuraci´ on del FPGA, y de las

pruebas de ingenier´ıa inversa. El objetivo del script es interpretar un bitstream identificando sus partes y etiquetando cada uno de los comandos y los datos en un archivo ASCIIcon comentarios al final de cada l´ınea. El c´odigo fuente de este script se encuentra en el Anexo C. El script est´ a en capacidad de interpretar bitstream en formato binario y en formato ASCII modificando la variable tipodearchivo (1 en caso de ser ASCII, 2: en caso de ser binario). Universidad Industrial de Santander

46

Int´erprete de bitstream en Matlab

3.2.1

Organizaci´ on del script

Las fuentes del script se organizaron como se muestra en la Figura 3.4

Figura 3.4: Scripts de matlab para interpretar los bitstreams.

InterpretaBitstream(archivo): Este es el script principal y se encarga de abrir los archivos de entrada y de salida, identificar el tipo de archivo de entrada, leer el cabecero, entregar cada palabra del contenido del archivo a la rutina interpretaword y finalmente imprimir en el archivo de salida y cerrar los archivos. interpretaword(unaword): Esta rutina se encarga de interpretar cada una de las palabras del archivo de configuraci´ on. Estas palabras pueden representar comandos, cabeceros de paquetes tipo I y cabeceros de paquetes tipo II. analizoregistro(unaword): Cuando interpretaword ha leido un paquete tipo I y busca saber que efecto tendr´ a la modificaci´ on del registro en particular, entonces llama a esta rutina que devuelve una cadena de caracteres con un comentario sobre esta acci´on. interpretadirframe(unaword): Esta rutina segmenta la direcci´on de un frame en los campos seg´ un lo indica la Figura 3.3. identificaregistro(direccion): Rutina que devuelve el nombre de un registro en espec´ıfico. frameautoinc(framedirin): Esta rutina contiene la informaci´on acerca del orden en el que R Xilinx empaqueta los frames en un bitstream. De esta forma se puede saber cual es la

direcci´on del siguiente frame a partir de la direcci´on del actual. grep(archivo,patron,varargin): Permite tomar un archivo interpretado por InterpretaBitstream e imprimir u ´nicamente las l´ıneas que contengan la cadena definida por el patr´ on. Fue empleado para

Universidad Industrial de Santander

47

Int´erprete de bitstream en Matlab dejar u ´nicamente las l´ıneas impresas por interpretadirframe donde se evidencia el orden de los frames en un bitstream generado con la opci´on de debug. analizogrep(archivo): Toma como entrada el archivo generado por grep y genera otro archivo con un resumen donde indica la cantidad de frames que se encuentran de forma secuencial con todos sus campos id´enticos pero con diferente minor address.

3.2.2

Resultados obtenidos con Matlab

Al llevar a cabo el an´alisis del bitstream con matlab se logr´o validar la coherencia entre la documentaci´ on R de Xilinx y los bitstream generados por bitgen. Adem´ as se logr´o inferir el orden en el que est´ an dis-

puestos los diferentes tipos de recursos l´ ogicos en forma de columnas a lo largo de cada una de las filas del dispositivo XC5VFX70TFFG1136. Los resultados de esta inferencia fueron comparados satisfactoriamente con la representaci´ on gr´ afica que presentan PlanAhead y FPGA Editor. El resumen de esta organizaci´ on se presenta en la tabla 3.3.

Universidad Industrial de Santander

48

Int´erprete de bitstream en Matlab Tabla 3.3: Organizaci´on de los recursos del FPGA por columnas Major

Tipo de

N´ umero

Major

Tipo de

N´ umero

Address

Recurso

de Frames

Address

Recurso

de Frames

0

IOB

54

26

CLB

36

1

CLB

36

27

CLB

36

2

CLB

36

28

CLB

36

3

CLB

36

29

CLB

36

4

CLB

36

30

RAMB

30

5

RAMB

30

31

CLB

36

6

CLB

36

32

CLB

36

7

CLB

36

33

DSP

28

8

CLB

36

34

CLB

36

9

CLB

36

35

CLB

36

10

CLB

36

36

DSP

28

11

CLB

36

37

CLB

36

12

RAMB

30

38

CLB

36

13

CLB

36

39

RAMB

30

14

CLB

36

40

CLB

36

15

CLB

36

41

CLB

36

16

CLB

36

42

CLB

36

17

CLB

36

43

CLB

36

18

CLB

36

44

IOB

54

19

RAMB

30

45

CLB

36

20

CLB

36

46

CLB

36

21

CLB

36

47

CLB

36

22

CLB

36

48

CLB

36

23

CLB

36

49

RAMB

30

24

IOB

54

50

NoID

34

25

ClkCol

4

Esta organizaci´ on contiene impl´ıcita la informaci´on sobre el orden en el direccionamiento de los frames, el cual se convierte en otro resultado importante de este proceso.

Universidad Industrial de Santander

49

Cap´ıtulo

´ ´ parcial Periferico para la reconfiguracion En este cap´ıtulo se desarrolla el proceso mediante el cual se puso en funcionamiento el perif´erico que permiti´o manipular la configuraci´ on del FPGA y adem´ as el proceso que permiti´o identificar los bits que se deben modificar en la memoria de configuraci´ on para manipular el comportamiento de cada look-up table (LUT) del FPGA. La Figura 4.1 destaca las etapas que se documentan en este cap´ıtulo y la Figura 4.2 resalta los elementos del sistema involucrados.

Figura 4.1: Pasos de la implementaci´ on del sistema.

Para llevar a cabo estas tareas se requiri´o la implementaci´ on de dos perif´ericos en el sistema: uno para modificar la configuraci´ on del FPGA y otro reconfigurable de prueba para validar el funcionamiento del primero.

4.1

Modificaciones al sistema base

El sistema base al cual se le instal´o el sistema operativo tuvo que ser modificado para a˜ nadir los perif´ericos necesarios para la reconfiguraci´ on y para distribuir mejor los recursos l´ ogicos del sistema base y los recursos

Universidad Industrial de Santander

50

4

Modificaciones al sistema base

Figura 4.2: Diagrama general. Recursos empleados durante este cap´ıtulo.

l´ ogicos disponibles para ser reconfigurados.

4.1.1

Perif´ erico reconfigurable de prueba

Con el objetivo de poder llevar a la pr´actica los resultados del an´alisis de los bitstreams y la estructura del FPGA, se cre´o un perif´erico de prueba en el sistema base que lleva a cabo la operaci´ on l´ ogica AND bit a bit entre 6 palabras de 32 bits. La interfaz con el procesador se realiza mediante 6 registros como muestra la Figura 4.3 y la operaci´ on l´ ogica es realizada por medio de 32 LUTs. R despu´es de llevar a cabo La instanciaci´ on de las LUTs se realiz´ o mediante las primitivas de Xilinx

el asistente para la creaci´on de un nuevo perif´erico. Todo esto dentro del archivo user logic.vhd que genera EDK al final del asistente. El Cuadro de C´odigo 4.1 muestra la descripci´on de las LUTs.

LasLUTs : f o r xx i n 0 t o 31 g e n e r a t e begin I n s t : LUT6 g e n e r i c map ( INIT => I 0 and I 1 and I 2 p o r t map ( O => S ( xx ) , −− I 0 => s l v r e g 0 ( xx ) , −− I 1 => s l v r e g 1 ( xx ) , −− I 2 => s l v r e g 2 ( xx ) , −− I 3 => s l v r e g 3 ( xx ) , −− I 4 => s l v r e g 4 ( xx ) , −− I 5 => s l v r e g 5 ( xx ) −− ); end g e n e r a t e ;

and I 3 and I 4 and I 5 ) −− S p e c i f y LUT C o n t e n t s LUT LUT LUT LUT LUT LUT LUT

g e n e r a l output input input input input input input

Cuadro de C´ odigo 4.1: Implementaci´ on de las LUTs en el perif´erico de pruebas

Universidad Industrial de Santander

51

Modificaciones al sistema base

Figura 4.3: Estructura del perif´erico reconfigurable de pruebas.

El objetivo de implementar este perif´erico es realizar la reconfiguraci´ on parcial sobre las LUTs que lo componen y modificar la funci´on l´ ogica que lleva a cabo.

4.1.2

Perif´ erico para acceder a la configuraci´ on del FPGA

Dentro del sistema implementado era necesario ofrecer al sistema base la posibilidad de acceder a su configuraci´ on interna. Para llevar a cabo esta funci´on se debe emplear un recurso dentro del FPGA llamado Internal Configuration Access Port (ICAP). Inicialmente se estudi´o la posibilidad de crear el R perif´erico que contuviera el ICAP, pero dado que Xilinx ya ofrece un perif´erico que maneja este recurso

mediante una interfaz para el bus PLB, se opt´o por emplearlo en el sistema. 4.1.2.1

XPS HWICAP

R Este es el nombre del perif´erico creado por Xilinx que permite acceder a la configuraci´ on del FPGA.

Su estructura interna se basa en registros que modifican el comportamiento de una m´aquina de estados que finalmente maneja las se˜ nales del ICAP. Estos registros son accedidos por el procesador por medio de la interfaz PLB, la cual est´ a configurada para soportar el modo burst y aprovecha la memoria FIFO que tiene implementado el HWICAP. Entre los registros m´as relevantes dentro del funcionamiento del m´odulo HWICAP se encuentran los siguientes: Write FIFO Register (WF) y Read FIFO Register (RF): Permiten escribir y leer datos sobre las memorias FIFO implementadas sobre el HWICAP para lectura y escritura. Universidad Industrial de Santander

52

Modificaciones al sistema base Write FIFO Vacancy Register (WFV) y Read FIFO Occupancy Register (RFO): Estos registros permiten saber el nivel de datos que tienen las memorias FIFO. Control Register (CR) y Status Register (SR): Contienen informaci´on del estado actual del perif´erico y permiten manipular cada uno de los procesos que puede realizar el perif´erico. La adici´on del perif´erico al sistema se realiz´ o de la forma est´ andar que tiene EDK para ello, donde se le asigna un rango dentro del mapa de memoria junto a los otros perif´ericos del sistema (pr´ actica 2 de [9]).

4.1.3

Optimizaciones en la implementaci´ on mediante PlanAhead

Para poder realizar pruebas de la reconfiguraci´ on sobre el perif´erico de prueba, fue necesario restringir el dise˜ no del sistema base sobre un ´ area espec´ıfica. Para ello se emple´ o la herramienta PlanAhead 12.2, que facilita la manipulaci´ on de los par´ ametros de la implementaci´ on del circuito mediante una interfaz gr´ afica que permite la edici´on del archivo UCF de restricciones del dise˜ no. Por ello fue necesario intervenir el flujo de dise˜ no de EDK para a˜ nadir las restricciones del sistema. La Figura 4.4 muestra la forma en la que se llev´o a cabo este proceso. B´ asicamente durante este procedimiento, se deja que EDK realice las etapas para generar el bitstream system.bit, pero de forma paralela se importan los archivos NGC a PlanAhead para generar otro archivo system.bit, el cual se ha generado bajo unas nuevas condiciones de localizaci´ on de las primitivas del circuito. El nuevo archivo de configuraci´ on sustituye al que gener´ o EDK, sin que esto afecte el flujo de dise˜ no y de esa forma pueda finalmente configurarse el FPGA. 4.1.3.1

Objetivos de las restricciones de localizaci´ on

La localizaci´ on de los elementos del sistema base busca hacer una distribuci´ on de recursos del FPGA entre la secci´on fija del sistema (no reconfigurable), el perif´erico de prueba reconfigurable y los posibles perif´ericos adicionales que se puedan implementar. Para ello se tuvieron en cuenta los siguientes dos aspectos: • Se debe conocer la ubicaci´ on de las primitivas del perif´erico reconfigurable de prueba para que ´esta pueda ser llevada a cabo. • Con el objetivo de mejorar el uso de los recursos l´ ogicos y de favorecer la futura implementaci´ on de perif´ericos en el sistema, se destinar´ a la mayor cantidad posible de recursos para perif´ericos de c´omputo que implementen en hardware funciones espec´ıficas de algoritmos. Este u ´ltimo aspecto busca particularmente que queden la mayor parte de los recursos especiales del FPGA disponibles para dichos perif´ericos. Especialmente los bloques RAM y bloques DSP.

Universidad Industrial de Santander

53

Modificaciones al sistema base

Figura 4.4: Flujo de EDK modificado para emplear PlanAhead

Desde el punto de vista del sistema base, es necesario que el ´area que se sea asignada, contenga los recursos necesarios que exige el circuito y que su distribuci´ on permita que se puedan cumplir las restricciones de tiempo. Adicionalmente el controlador de la memoria DDR2 y el perif´erico de ethernet tienen exigencias particulares respecto a algunos recursos que reciben las se˜ nales directamente desde los pines, por lo cual es necesario que el ´ area asignada al sistema base contenga dichos recursos. La Figura 4.5 muestra el panorama de la localizaci´ on de los recursos requeridos por parte del sistema base.

Universidad Industrial de Santander

54

Modificaciones al sistema base

Figura 4.5: Restricciones del sistema base impuestas por EDK

´ Figura 4.6: Area reservada para el sistema base.

Por estas razones se ha seleccionado para el sistema base, un ´area que contiene los recursos circunR dantes al procesador PowerPC y que se extiende desde los pines requeridos para la memoria DDR2 hasta

la primera columna de bloques DSP. La Figura 4.6 muestra el ´area asignada al sistema base. Otras alternativas estudiadas se muestran en la Tabla 4.1. Se observa que cuadrado, la distribuci´ on seleccionada, da prioridad a la utilizaci´ on de los recursos que R rodean al procesador PowerPC . Esto ha permitido cumplir de mejor forma los requerimientos de tiempo.

Por otro lado se est´ an dejando completamente libre solamente 6 regiones de reloj del FPGA, lo cual es un inconveniente cuando se requiera implementar gran cantidad de perif´ericos con diferentes frecuencias de trabajo. De cualquier forma si la aplicaci´ on final lo requiriera, es posible seleccionar cualquiera de las alternativas presentadas, sin que esto afecte el funcionamiento del sistema base. En el Cuadro de C´odigo 4.2, se detallan las modificaciones al archivo UCF introducidas.

Universidad Industrial de Santander

55

Modificaciones al sistema base Tabla 4.1: Algunas distribuciones estudiadas para ser asignadas al sistema base Distribuci´ on

Ventajas

Desventajas

FranjaHorizontal

Recursos % de utilizaci´ on de recursos.

• Emplea de forma completa las regiones del reloj X0Y2:X0Y5, X1Y3:X1Y4 y parcialmente los X0Y1, X0Y6 sin involucrar los X0Y0, X0Y7, X1Y0:X1Y2, X1Y5:X1Y7. • Tiene la relaci´ on de recursos LUT y FFD m´ as alta.

LaF V2 • Al igual que en la FranjaHorizontal, esta configuraci´ on emplea completamente 6 regiones de reloj, de forma parcial 2 regiones y deja libres 8 regiones. • El ´ area libre est´ a en un solo bloque con una forma bastante regular. • La relaci´ on de bloques RAM y bloques DSP requeridos sobre los reservados mejora.

• Segmenta el ´ area libre en dos partes. • La relaci´ on de bloques de memoria requeridos sobre reservados es baja y la de los bloques DSP es la m´ as baja de todas las configuraciones.

• La relaci´ on de recursos requeridos sobre reservados se ha incrementado con respecto a la FranjaHorizontal. • Algunos pines reservados por EDK se encuentran alejados de la zona del sistema base, lo cual exige algunos recursos de enrutado en la zona libre. • La zona que rodea el proceR no es emsador PowerPC pleada. Esto hace que sea m´ as dif´ıcil cumplir los requerimientos de tiempos.

LaT V2

Rrequeridos Rreservados

12.877 15.040 = 86% 9.723 = 65% FFD = 15.040 25 BRAM = 50 = 50% BDSP = 13 32 = 41%

LUT =

% de utilizaci´ on de recursos. Rrequeridos Rreservados

12.877 15.360 = 84% 9.723 FFD = 15.360 = 64% 25 BRAM = 52 = 48% BDSP = 13 16 = 82%

LUT =

% de utilizaci´ on de recursos. • La zona del sistema base se hace m´ as compacta. • Al igual que en las versiones anteriores se tienen 8 regiones de reloj libres. • Contiene bloques DSP necesarios para la implementaci´ on de la unidad de punto flotante del R . PowerPC

• Tiene la menor eficiencia de utilizaci´ on de bloques RAM debido a que reserva 64 pero solo usa 25. • Es la distribuci´ on que m´ as recursos LUT y FFD reserva.

Universidad Industrial de Santander

Rrequeridos Rreservados

12.877 16.320 = 79% 9.723 = 60% FFD = 16.320 25 BRAM = 64 = 40% BDSP = 13 16 = 82%

LUT =

56

Modificaciones al sistema base Tabla 4.1 – continuaci´ on desde la p´ agina anterior Distribuci´ on

Ventajas

Desventajas

cuadrado

Recursos % de utilizaci´ on de recursos.

• Es la distribuci´ on que mejor rodea el procesador R PowerPC • Su ´ area, contiene los bloques DSP requeridos para la unidad de punto flotante.

INST INST INST INST INST INST INST INST INST INST INST INST INST INST INST INST INST INST INST INST INST INST INST INST

Rrequeridos Rreservados • Ocupa parcialmente mayor cantidad de regiones de reloj 12.877 16.000 = 81% 9.723 = 61% FFD = 16.000 25 BRAM = 40 = 63% BDSP = 13 16 = 82%

LUT =

” a p u f p u v i r t e x 5 0 ” AREA GROUP = ” s i s t e m a ” ; ” c l o c k g e n e r a t o r 0 ” AREA GROUP = ” s i s t e m a ” ; ”DDR2 SDRAM” AREA GROUP = ” s i s t e m a ” ; ” D I P S w i t c h e s 8 B i t ” AREA GROUP = ” s i s t e m a ” ; ” f c b v 2 0 0 ” AREA GROUP = ” s i s t e m a ” ; ” F L A S H u t i l b u s s p l i t 0 ” AREA GROUP = ” s i s t e m a ” ; ”FLASH” AREA GROUP = ” s i s t e m a ” ; ” Hard Ethernet MAC ” AREA GROUP = ” s i s t e m a ” ; ”IIC EEPROM” AREA GROUP = ” s i s t e m a ” ; ” j t a g p p c c n t l r 0 ” AREA GROUP = ” s i s t e m a ” ; ” LEDs 8Bit ” AREA GROUP = ” s i s t e m a ” ; ” L E D s P o s i t i o n s ” AREA GROUP = ” s i s t e m a ” ; ” p l b v 4 6 0 ” AREA GROUP = ” s i s t e m a ” ; ” p p c 4 4 0 0 ” AREA GROUP = ” s i s t e m a ” ; ” p r o c s y s r e s e t 0 ” AREA GROUP = ” s i s t e m a ” ; ” P u s h B u t t o n s 5 B i t ” AREA GROUP = ” s i s t e m a ” ; ” R S 2 3 2 U a r t 1 ” AREA GROUP = ” s i s t e m a ” ; ” SysACE CompactFlash ” AREA GROUP = ” s i s t e m a ” ; ” x p s b r a m i f c n t l r 1 b r a m ” AREA GROUP = ” s i s t e m a ” ; ” x p s b r a m i f c n t l r 1 ” AREA GROUP = ” s i s t e m a ” ; ” x p s h w i c a p 0 ” AREA GROUP = ” s i s t e m a ” ; ” x p s i n t c 0 ” AREA GROUP = ” s i s t e m a ” ; ” x p s t i m e b a s e w d t 1 ” AREA GROUP = ” s i s t e m a ” ; ” x p s t i m e r 1 ” AREA GROUP = ” s i s t e m a ” ;

AREA GROUP AREA GROUP AREA GROUP AREA GROUP AREA GROUP AREA GROUP

” sistema ” ” sistema ” ” sistema ” ” sistema ” ” sistema ” ” sistema ”

RANGE=SLICE X48Y60 : SLICE X55Y99 , SLICE X20Y40 : SLICE X47Y119 ; RANGE=SLICE X0Y20 : SLICE X19Y139 ; RANGE=DSP48 X0Y24 : DSP48 X0Y39 ; RANGE=RAMB36 X3Y12 : RAMB36 X3Y19 , RAMB36 X0Y8 : RAMB36 X2Y23 ; GROUP=CLOSED ; PLACE=CLOSED ;

Cuadro de C´ odigo 4.2: Restricciones impuestas al sistema en la configuraci´ on cuadrado.

4.1.3.2

Restricciones del perif´ erico reconfigurable.

El perif´erico de prueba fue creado con el objetivo de realizar pruebas reconfigurando su estructura para modificar su funci´on. Originalmente el perif´erico lleva a cabo la funci´on de la compuerta AND bit a bit Universidad Industrial de Santander

57

Modificaciones al sistema base entre 6 registros de 32 bits y arroja el resultado en un u ´ltimo registro; por ello su estructura est´ a basada en 32 LUTs de 6 entradas. Estas LUTs ser´an modificadas para llevar a cabo una funci´on l´ ogica d´ıferente y as´ı demostrar el funcionamiento de la reconfiguraci´ on. Para llevar a cabo esta tarea fue necesario restringir la ubicaci´ on de estas LUTs en el dise˜ no. Por ello se ha restringido tanto la ubicaci´ on de los elementos del perif´erico, como la ubicaci´ on espec´ıfica de estas LUTs. Las modificaciones a˜ nadidas al archivo de restricciones UCF se presentan en el cuadro de c´odigo 4.3. # R e s t r i c c i o n e s p a r a e l p e r i f ’ e r i c o de prueba compuesto p o r LUTs INST ” a n d s o b r e l u t s 0 / a n d s o b r e l u t s 0 /USER LOGIC I/LasLUTs [ 0 ] . I n s t ” BEL = A6LUT ; INST ” a n d s o b r e l u t s 0 / a n d s o b r e l u t s 0 /USER LOGIC I/LasLUTs [ 0 ] . I n s t ” LOC = SLICE X26Y20 ; INST ” a n d s o b r e l u t s 0 ” AREA GROUP = ”LUTS” ; AREA GROUP ”LUTS” RANGE=SLICE X26Y20 : SLICE X31Y39 ; AREA GROUP ”LUTS” GROUP=CLOSED ; AREA GROUP ”LUTS” PLACE=CLOSED ;

Cuadro de C´ odigo 4.3: Restricciones impuestas sobre las LUTs instanciadas en el perif´erico reconfigurable

4.1.3.3

Regreso de archivos a EDK

Una vez realizada la implementaci´ on en PlanAhead, se gener´ o el archivo bitstream system.bit, pero para empalmar nuevamente el flujo de dise˜ no de EDK se debe generar igualmente el archivo bmm como se mostr´ o en la Figura 4.4. Este archivo indica la ubicaci´ on f´ısica de los bloques de memoria que componen el perif´erico xps bram if cntlr 1. Este perif´erico contiene el c´odigo de m´aquina del prebootloader. Normalmente esta informaci´on es extraida autom´aticamente por EDK, pero cuando se manej´o la implementaci´ on con PlanAhead, fue necesario consultar all´ı mismo esta informaci´on. Para ello se emple´ o la l´ınea de comandos tcl que tiene implementado PlanAhead y se hizo el script del Anexo B. Este script, b´asicamente solicita reportes sobre la ubicaci´ on de las celdas (cells) despu´es de ejecutar par.exe (Place and Route) e imprime la informaci´on seg´ un la sintaxis del archivo bmm. Una vez generado este archivo, se emple´ o la aplicaci´ on data2mem que toma como entrada un bitstream y actualiza el contenido de los bloques RAM del FPGA. En este caso inserta el programa del prebootloader en los bloques RAM que empleo la implementaci´ on de PlanAhead generando el archivo download.bit que finalmente ser´a descargado al FPGA. La l´ınea de comando para usar data2mem fue la siguiente: EDK# data2mem -bm "implementation/system_bd" -bt \ "implementation/system.bit" -bd "u-boot/executable.elf" \ tag ppc440_0 -o b implementation/download.bit

Universidad Industrial de Santander

58

Driver del perif´erico XPS HWICAP

4.2

Driver del perif´ erico XPS HWICAP

Para llevar a cabo una aplicaci´ on software que emplee el perif´erico, es necesario hacer un driver dentro del sistema operativo que acceda correctamente el mismo. La implementaci´ on del driver se bas´ o en el driver R que Xilinx da para manejar el mismo desde EDK. Y fue llevado a lo largo de varias etapas para su

adaptaci´on al sistema operativo Linux. El proceso que se llev´o a cabo durante el desarrollo del proyecto, se espera quede como un lineamiento que pueda solucionar problemas similares en el futuro.

4.2.1

Driver de Xilinx del XPS HWICAP

R Una vez a˜ nadido el perif´erico XPS HWICAP, es posible manipularlo con la librer´ıa que Xilinx ofrece

junto al perif´erico. Esta librer´ıa fue fundamental en el desarrollo del proyecto, porque ofrece informaci´on sobre la configuraci´ on del FPGA y porque se tom´ o como base para el driver que funcion´ o sobre Linux. Con el objetivo de entender la forma en la que se relacionan las funciones que lo componen y con el objetivo de determinar una estrategia para compilarlo en el sistema operativo, se analiz´ o la dependencia de archivos y de funciones. De este an´alisis surgi´o la gr´ afica de la Figura 4.7, donde se exponen algunos archivos fuente del driver que contienen declaraciones de funciones. Cada flecha indica que una funci´on hace un llamado a otra. As´ı se identifican funciones en 4 niveles o capas.

R Figura 4.7: Dependencia en los archivos del c´odigo fuente del driver del HWICAP dado por Xilinx .

En la primera capa se encuentran las funciones b´asicas con las que inicia la plantilla de un perif´erico en EDK, mediante las cuales se puede acceder a un registro del perif´erico. Estas funciones se encuentran R en el archivo xhwicap l.h y emplean funciones b´asicas de Xilinx como lo son las que se encuentran

definidas en xio.h. Estas son: XHwIcap mWriteReg: y XHwIcap mReadReg: Permiten escribir y leer sobre un registro del perif´erico conociendo su baseaddress y su offset. Universidad Industrial de Santander

59

Driver del perif´erico XPS HWICAP En la segunda capa se encuentran funciones relacionadas con el funcionamiento del m´odulo HWICAP. Algunas de ellas relacionadas con la escritura y lectura de los registros del perif´erico, otras relacionadas con consultas del estado del perif´erico, transferencias de datos, etc. Estas funciones en algunos casos se encuentran definidas como macros y est´ an en su gran mayor´ıa en el archivo xhwicap.h. En esta capa se encuentran definidas dos funciones cuyo c´odigo fuente no se hizo p´ ublico por parte de R Xilinx , sino que se distribuyen como archivos objeto. Estas funciones son:

on XHwIcap SetClbBits y XHwIcap GetClbBits: Permiten modificar y leer los bits de configuraci´ de un CLB En la tercera capa se encuentran rutinas de tipo funcional, que involucran acciones de la capa dos. Entre estas rutinas se encuentran la escritura y lectura de datos mediante el perif´erico, pruebas de autodiagn´ostico, de reset, etc. Estas rutinas se encuentran declaradas en varios archivos: xhwicap.c, xhwicap srp.c, xhwicap selftest.c, xhwicap intr.c, xhwicap device read frame.c, xhwicap device write frame.c y xhwicap sinit.c. Entre las m´as importantes funciones se encuentran:

XHwIcap DeviceReadFrame y XHwIcap DeviceWriteFrame: Permiten leer y escribir un frame completo del FPGA indicando los par´ ametros de su direcci´on. XHwIcap selftest: Realiza una prueba habilitando y desabilitando la interupci´on en el dispositivo. Finalmente la cuarta capa es una capa de aplicaci´ on que se compone de ejemplos que emplean las funciones del driver de las capas inferiores. Entre estos ejemplos se encuentran los siguientes: xhwicap ff: Este ejemplo busca modificar el valor que almacena un flipflop espec´ıfico, al interior de un slice del FPGA. Solo se garantiza su funcionamiento en FPGA de la familia Virtex 4. xhwicap lut: Este ejemplo busca verificar que todos los posibles valores que admite una LUT pueden ser escritos y leidos. Su implementaci´ on se puede realizar sobre dispositivos Virtex 4, 5 y 6. xhwicap read frame polled example: Este ejemplo, lee un frame para demostrar el uso de la on funci´on XHwIcap DeviceReadFrame() de la capa 3. Este ejemplo soporta su implementaci´ en dispositivos de la familia Virtex 4, 5 y 6. La estructura descrita se ha mantenido en las 4 versiones que hab´ıan aparecido hasta el momento del an´alisis del driver. Al momento de a˜ nadir el perif´erico, se realizaron pruebas desde el entorno de EDK empleando la versi´on 2.01, la cual era la m´as moderna que hab´ıa sido distribuida con la versi´on 10.1 de Universidad Industrial de Santander

60

Driver del perif´erico XPS HWICAP EDK. Estas pruebas b´asicamente inclu´ıan la ejecuci´ on de la funci´on de inicializaci´on del perif´erico, el autodiagn´ostico (selftest) y la lectura de un frame, con su respectiva impresi´on en el terminal. Al momento de llevar el driver al entorno del sistema operativo, se decidi´ o implementar la versi´on 4, la cual era la u ´ltima que se hab´ıa distribuido hasta ese momento. En esta versi´on hay algunas correcciones realizadas sobre las versiones anteriores, principalmente permitiendo que los ejemplos que ellos otorgan puedan ser implementados sobre un mayor n´ umero de dispositivos. Aun as´ı, no todos los ejemplos de la distribuci´ on pueden ser compilados para el FPGA XC5VFX70TFFG1136.

4.2.2

Compilaci´ on en Linux desde el espacio del usuario

El proceso de adaptar un driver de EDK para que trabaje en el kernel de Linux se hizo en dos etapas. La primera etapa logr´o que las fuentes se pudieran compilar en Linux, supliendo todas las funciones de bajo nivel que EDK posee haciendo una implementaci´ on desde el espacio del usuario. Durante la segunda etapa se mejor´o la implementaci´ on al realizar las funciones de bajo nivel en el espacio del kernel. Para poder llevar las fuentes a Linux y compilarlas, es necesario revisar el diagrama de dependencias de R que son requeridas. La Figura 4.8 muestra la estrategia la Figura 4.7 e identificar las librer´ıas de Xilinx

empleada para compilar las fuentes teniendo en cuenta la dependencia de los archivos de la fuente. Se ha escogido una implementaci´ on mediante librer´ıas est´ aticas, pero puede ser modificada para que sean compartidas cuando varios drivers de EDK o varias aplicaciones requieran hacer uso de estas rutinas. Como resultado de esa compilaci´on se generaron las librer´ıas libxil assert.a y libxil io.a, que definen rutinas y tipos de datos propios de los drivers de EDK. Empleando los archivos propios del driver del HWICAP, surge la librer´ıa libxhwicap.a. Estas tres librer´ıas, junto a los cabeceros de las funciones son los requerimientos que tiene la compilaci´on de una aplicaci´ on, como los ejemplos del driver. R Para que este flujo se pueda llevar a cabo fue necesario modificar algunas de las fuentes de Xilinx

y durante la implementaci´ on se busc´ o que los cambios no afectaran las fuentes del HWICAP, sino que preferiblemente afectaran a las de bajo nivel como xil io y xil assert, para que de esta forma otros drivers se puedan migrar a Linux sin mayores modificaciones. Los cambios realizados sobre las fuentes se exponen en detalle en el Anexo D, pero se pueden resumir en los siguientes items: Funci´ on de impresi´ on: La mayor´ıa de los ejemplos contiene una l´ınea donde sustituye el printf de la librer´ıa est´ andar de C por xil printf. Esta definici´on debe ser comentada manualmente en cada Universidad Industrial de Santander

61

Driver del perif´erico XPS HWICAP

Figura 4.8: Compilaci´ on de las fuentes del driver y una aplicaci´ on sobre una fuente de ejemplo.

ejemplo. Traslado de fuentes de EDK al directorio de compilaci´ on en el SO: Algunas fuentes y definiciones es mejor tomarlas directamente del proyecto de EDK. Para este proyecto fue necesario traer las fuentes: • xstatus.h

• xintc l.h

• xreg440.h

• xintc.h

• xpseudo asm gcc.h

• xil types.h

• xpseudo asm.h

• xil io.h

• xpseudo asm.h

• xil io.c

• xio.h

• xil exception.h

• xio.c

• xil assert.h

• xil assert.c • xhwicap family.c • ppc-asm.h • xbasic types.c • xbasic types.h

Modificaci´ on de las funciones de escritura de registros: Los m´etodos que por defecto trae EDK para el acceso a los registros asumen que la aplicaci´ on que se desarrolla es la u ´nica que se est´ a ejecutando. Esta suposici´on no es v´ alida en el entorno que ofrece el sistema operativo, por lo tanto, los m´etodos que modifican y que leen los registros del perif´erico deben solicitarle al kernel el acceso a Universidad Industrial de Santander

62

Driver del perif´erico XPS HWICAP los mismos. Los m´etodos contenidos en las rutinas de EDK en los archivos xil io.h y xil io.c, fueron modificados para cumplir con los m´etodos de acceso del sistema operativo.

Durante esta primera etapa, se accedi´ o al mapa de memoria del perif´erico mediante el nodo /dev/mem, el cual ofrece un m´etodo sencillo y se puede llevar a cabo desde el espacio del usuario del sistema operativo. Los detalles de esta implementaci´ on se pueden observar en el Anexo E.

4.2.3

Ejemplos modificados y scripts de Linux hechos para pruebas

Mediante las modificaciones descritas en la secci´on anterior se logr´o compilar los ejemplos del driver que son compatibles con los FPGA Virtex 5. Algunos de estos ejemplos son bastante u ´tiles para recolectar informaci´on sobre el dispositivo y sobre la estructura del bitstream, por eso fueron modificados para ofrecer una mayor funcionalidad. A continuaci´on se presentan las modificaciones realizadas sobre los ejemplos y algunos scripts que los usan: 4.2.3.1

xhwicap read frame polled example args.c

Esta es una modificaci´ on del ejemplo xhwicap read frame polled example, la cual permite modificar la forma en la que se imprimen los frames y adem´ as permite introducir por l´ınea de comandos cual de los frames del FPGA se desea leer. Las opciones de visualizaci´ on se resumen en la Tabla 4.2.

Tabla 4.2: Opciones de visualizaci´ on de xhwicap read frame polled example args.c Opci´ on --debug

Descripci´ on Imprime cabeceros al inicio de cada frame que muestran los par´ ametros de su direcci´on como el tipo de bloque, top, fila, major y minor. Ejemplo: FRAME=> Block=0 Top=1 Hclk/Row=1 Major=1 Minor=20

--hex

Imprime en una columna la informaci´on del frame en hexadecimal. Ejemplo: 21000303

--bin

Imprime en una columna la informaci´on del frame en binario. Ejemplo: 00100001000000000000001100000011

--info

Imprime en frente de cada palabra del frame su ´ındice. Ejemplo: Frame Word 70 -> 21000303 Continua en la siguiente p´agina

Universidad Industrial de Santander

63

Driver del perif´erico XPS HWICAP Tabla 4.2 – continuaci´ on desde la p´ agina anterior Opci´ on

Descripci´ on

--quit null frame

No imprime un frame adicional que es leido siempre que se hace la lectura de un frame. Este frame es cero en su totalidad y no contiene informaci´on.

Este programa fue empleado como base para otros que requieren leer un frame en espec´ıfico. Su c´odigo fuente y una explicaci´on mas detallada de sus opciones se encuentra en la secci´on F.1. 4.2.3.2

leer frames de una columna.sh

En las pruebas realizadas y en la documentaci´ on referente al tema, se ha logrado identificar los frames que contienen la informaci´on de cada una de las columnas. Sin embargo la documentaci´ on no especifica exactamente cual frame contiene la informaci´on de cada uno de los recursos ubicados en las diferentes columnas. Por ello este script lee el contenido de los frames asociados a una columna completa del FPGA y lo imprime en consola. Su salida puede ser redireccionada a un archivo para posteriores comparaciones. Su c´odigo fuente y un ejemplo de uso se encuentra en la secci´ on F.2. 4.2.3.3

leer toda la configuracion.sh

Este script hace un recorrido por todo el rango de direcciones del FPGA y busca leer toda la configuraci´ on a almacenada la informaci´on sobre la cantidad de en tiempo de ejecuci´ on. En la variable num minors est´ frames que contiene cada columna del FPGA y de esa forma se realiza todo el recorrido por el rango de direcciones de los frames. Normalmente este script nunca llega a feliz t´ermino debido a que la lectura de ciertos frames hace que el sistema se bloquee y sea necesario reiniciar. La secci´on F.3 muestra el c´odigo fuente del script y su modo de uso. 4.2.3.4

w lee y escribe frame.c

Este programa se desarroll´ o basado en los ejemplos del driver, y empleando las funciones del mismo. Su objetivo es modificar solamente un bit de una palabra de un frame espec´ıfico. Por ello desde la l´ınea de comandos el programa puede recibir los campos de la direcci´ on del frame, el n´ umero de la palabra y el bit espec´ıfico que se quiere invertir. Para llevar a cabo esta acci´on se hace uso de las funciones del driver XHwIcap DeviceReadFrame y XHwIcap DeviceWriteFrame. El c´odigo fuente y una explicaci´on de cada una de las opciones de la funci´on se encuentra en el Anexo F.4. 4.2.3.5

w cambia cada bit de una columna.sh

Este script hace uso del programa w lee y escribe frame.c para recorrer cada uno de los bits de los frames de una columna, modific´ andolo y llev´andolo nuevamente a su estado original. Este script fue usado Universidad Industrial de Santander

64

Driver del perif´erico XPS HWICAP en conjunto con otros que permiten conocer el contenido de los LUTs para encontrar los bits exactos que modifican el comportamiento de la LUT. Su c´odigo fuente se encuentra en la secci´on F.5.

4.2.4

Identificaci´ on de los bits que afectan el comportamiento de las LUTs.

Con el driver funcionando desde el espacio del usuario, la experiencia del manejo del perif´erico desde el espacio del usuario y el conocimiento de la arquitectura del FPGA, se logr´o inferir ex´actamente cu´ ales bits son los que modifican el comportamiento de cada LUT del sistema. Pero para ello fue necesario hacer uso de las herramientas desarrolladas y crear un programa adicional que hace uso del perif´erico de prueba descrito en la secci´on 4.1.1. 4.2.4.1

Programa operaLUTs y operaLUTs verbose

Este programa tiene en cuenta la arquitectura del perif´erico reconfigurable de prueba y determina la tabla de verdad de cada una de las LUTs que lo componen. Su objetivo principal es determinar cuantas LUTs han sido modificadas y su resultado es mostrado en consola al ejecutar operaLUTs. El programa operaLUTs verbose imprime en consola la tabla de verdad de cada una de las tablas de verdad de los LUTs con un comentario adicional en caso de comportarse como una compuerta AND, NAND, OR o NOR. En el estado inicial del perif´erico reconfigurable, la salida de operaLUTs verbose es como se muestra en el Cuadro de C´ odigo 4.4 y su c´odigo fuente se encuentra en el Anexo F.6. El n´ umero 32 de la u ´ltima l´ınea indica que todas las LUTs mantienen su estado original. El c´odigo fuente de ambos programas es el mismo, pero para generar los dos ejecutables se modifica una definici´on del precompilador en el Makefile del Anexo D.2. 4.2.4.2

FPGA Editor

R FPGA Editor es una herramienta que Xilinx ofrece para acceder de forma bastante detallada a la

informaci´on de mapeo y de enrutamiento. Esta herramienta fue de gran importancia en el proceso de identificaci´on de los bits que definen el comportamiento de una LUT debido a los siguientes dos aportes: • Inicialmente permiti´o verificar que las restricciones impuestas al dise˜ no se estaban cumpliendo. Aqu´ı se observa la ubicaci´ on y la configuraci´ on de cada LUT empleada en el perif´erico de prueba, y adicionalmente se observa el orden de entrada de los bits a la LUT. • El aporte m´as importante del software fue el de realizar ingenier´ıa inversa, dado que no solo permite visualizar los resultados del par, sino que adem´ as permite modificarlo. Con esto se pudo realizar peque˜ nos cambios en la configuraci´ on de los LUTs y generar diferentes archivos bitstreams que fueron comparados.

Universidad Industrial de Santander

65

Driver del perif´erico XPS HWICAP

Okinawa −21: e t a p a 1 e s p a c i o u s u a r i o# Resultados : LUT00 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta LUT01 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta LUT02 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta LUT03 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta LUT04 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta LUT05 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta LUT06 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta LUT07 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta LUT08 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta LUT09 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta LUT10 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta LUT11 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta LUT12 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta LUT13 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta LUT14 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta LUT15 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta LUT16 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta LUT17 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta LUT18 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta LUT19 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta LUT20 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta LUT21 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta LUT22 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta LUT23 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta LUT24 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta LUT25 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta LUT26 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta LUT27 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta LUT28 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta LUT29 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta LUT30 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta LUT31 : 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Compuerta 32

. / prueba LUTs / operaLUTs / o p e r a L U T s v e r b o s e AND AND AND AND AND AND AND AND AND AND AND AND AND AND AND AND AND AND AND AND AND AND AND AND AND AND AND AND AND AND AND AND

de de de de de de de de de de de de de de de de de de de de de de de de de de de de de de de de

6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6

entradas entradas entradas entradas entradas entradas entradas entradas entradas entradas entradas entradas entradas entradas entradas entradas entradas entradas entradas entradas entradas entradas entradas entradas entradas entradas entradas entradas entradas entradas entradas entradas

Cuadro de C´ odigo 4.4: Implementaci´ on de las LUTs en el perif´erico de pruebas

4.2.4.3

Estrategia para identificar los bits del bitstream

Con el objetivo de establecer cu´ ales de los bits modifican el comportamiento de las LUTs del FPGA y poder de esta forma manipular el comportamiento de la tabla de verdad de las mismas se sigui´o la estrategia mostrada en la Figura 4.9. Partiendo del trabajo de ruteo realizado por Planahead, se tom´ o el archivo NCD enrutado y se manipul´ o con FPGA editor para en algunos casos invertir la salida de la funci´on l´ ogica de la LUT y en otros casos para convertirla en una compuerta OR. Esto con el objetivo de obtener la mayor cantidad de informaci´on de esta prueba. De esta forma se obtuvo un segundo archivo NCD. Estos dos archivos NCD se pasaron por el programa bitgen, el cual arroj´o como resultado un bitstream para cada uno de ellos, los cuales se analizaron mediante el script de matlab analizobitstream.m. Este script segmenta el cabecero y cada uno de los frames del bitstream y arroja como resultado un archivo de texto para cada archivo de entrada. Estos archivos de texto fueron comparados por la utilidad VimDiff que arroj´o las siguientes diferencias:

Universidad Industrial de Santander

66

Driver del perif´erico XPS HWICAP

Figura 4.9: Estrategia para identificar los bits que modifican el comporamiento de las LUT de un slice

• Fecha de creaci´on del archivo .bit. • Cambios en las primeras 16 palabras de los frames con block = 0, row = 2, top = 1, major = 16 y minor = 32 · · · 35. • Cambio en el valor del CRC. El primer y tercer cambio, se pueden predecir y no son relevantes. La segunda diferencia encontrada indica los bits exactos que determinan la tabla de verdad de la LUT. La cantidad de bits modificados durante la prueba fueron 32 × 16 × 4 = 2048 bits, y sabiendo que la cantidad de bits necesarios para establecer la tabla de verdad de 32 LUTs de 6 entradas es 26 × 32 = 2048 bits, pues fortaleci´ o la hip´ otesis de que estos bits son los que realmente modifican el comportamiento de las tablas de verdad. Ahora el siguiente paso fue establecer c´omo afecta cada uno de los bits la tabla de verdad de la LUT. Para ello se hizo uso de la implementaci´ on del driver en el sistema operativo desde el espacio del usuario y se puso a correr indefinidamente el programa operaLUTs que imprime la tabla de verdad de las 32 LUTs. Por otro lado, se us´ o la informaci´on de la ubicaci´ on de los bits que modifican el comportamiento de las LUTs, obtenida mediante VimDiff, y se ajustaron los par´ ametros del script w cambia cada bit de una columna.sh para crear el script w invierte LUTs de un slice.sh el cual s´ olamente cambia los bits de las LUTs.

Universidad Industrial de Santander

67

Driver del perif´erico XPS HWICAP Los efectos que realiza el script se van haciendo evidentes en la salida del programa operaLUTs y de esa forma mediante observaci´ on se pudo analizar el efecto de modificar cada bit de las LUTs. Al final de la prueba se tuvo como resultado que el comportamiento de cada LUT se hab´ıa invertido, como se esperaba. 4.2.4.4

An´ alisis de los resultados

Cruzando el orden en el que se modificaron los bits y la forma en la que fueron cambiando los bits en la tabla de verdad se puede en el futuro manipular m´as f´acilmente el comportamiento de las LUTs. Este orden se muestra en las Tablas 4.3 y 4.4. En la Tabla 4.3 se observa el orden en el que el script w invierte LUTs de un slice.sh manipul´ o los bits de los frames y en la Tabla 4.4 se observa el orden en el que fueron cambiando en la tabla de verdad.

minor word

bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9

8

7

6

5

4

3

2

1

0

32 32

0 1

32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33

33 33

0 1

96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97

34 34

0 1

160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161

35 35

0 1

224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225

Tabla 4.3: Orden en el que el script w invierte LUTs de un slice.sh manipul´ o los bits de los frames

LUT D C B A LUT D C B A

bits 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 49 113 241 177 114 50 178 242 51 115 243 179 116 52 180 244 53 117 245 181 118 54 182 246 55 119 247 183 120 56 184 248 33 97 225 161 98 34 162 226 35 99 227 163 100 36 164 228 37 101 229 165 102 38 166 230 39 103 231 167 104 40 168 232 17 81 209 145 82 18 146 210 19 83 211 147 84 20 148 212 21 85 213 149 86 22 150 214 23 87 215 151 88 24 152 216 1 65 193 129 66 2 130 194 3 67 195 131 68 4 132 196 5 69 197 133 70 6 134 198 7 71 199 135 72 8 136 200 bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 57 121 249 185 128 64 192 256 59 123 251 187 124 60 188 252 61 125 253 189 126 62 190 254 41 105 233 169 112 48 176 240 43 107 235 171 108 44 172 236 45 109 237 173 110 46 174 238 25 89 217 153 96 32 160 224 27 91 219 155 92 28 156 220 29 93 221 157 94 30 158 222 9 73 201 137 80 16 144 208 11 75 203 139 76 12 140 204 13 77 205 141 78 14 142 206

7 63 47 31 15

6 5 4 3 127 255 191 128 111 239 175 112 95 223 159 96 79 207 143 80

2 64 48 32 16

1 0 192 256 176 240 160 224 144 208

Tabla 4.4: Orden en el que el script manipul´ o los bits de las 4 LUTs del un slice

De estas tablas se han deducido las siguientes f´ormulas que permiten determinar el frame y los bits precisos para manipular un resultado de una LUT espec´ıfica dentro del FPGA. Con estas f´ormulas se implementaron las funciones calcula word, calcula bit y calcula frame minor contenidas en la fuente w escribe una LUT.c para posteriores etapas. La fuente del programa w escribe una LUT.c se encuentran en el Anexo F.7.

Universidad Industrial de Santander

68

Driver del perif´erico XPS HWICAP



 E B = 15 − + 16 [LU T (mod 2)] 4   LU T W = 2 [Sy (mod 10)] + 2

(4.1) (4.2)

m = 26 + 6 [Sx + 1(mod 2)] + Φ [E(mod 8)]

(4.3)

donde: E

→ Combinaci´on de entrada dentro de la LUT. Puede tomar valores entre 0 y 63.

LU T → N´ umero de la LUT al interior del Slice. Se ha codificado de la siguiente forma: A → 0, B → 1, C → 2 y D → 3. Sx

→ Coordenada x del slice seg´ un el sistema de coordenadas usado en los archivos ucf de restricciones.

Sy

→ Coordenada y del slice seg´ un el sistema de coordenadas usado en los archivos ucf de restricciones.

B

→ Indica cu´ al de los 32 bits de la palabra se debe modificar. El bit 0 es el LSB y el 31 el MSB.

W

→ Se˜ nala cu´ al palabra dentro del frame contiene el bit solicitado.

m

→ Indica el minor address del frame que contiene el bit solicitado.

Φ(x) → Es una funci´on definida de Z8 en Z4 as´ı:

4.2.5

• Φ(0) = 3

• Φ(2) = 0

• Φ(4) = 2

• Φ(6) = 1

• Φ(1) = 2

• Φ(3) = 1

• Φ(5) = 3

• Φ(7) = 0

Compilaci´ on en Linux desde el espacio del kernel

Una vez implementado el driver desde el espacio del usuario, se pudo obtener informaci´on importante sobre el funcionamiento del perif´erico y la arquitectura del FPGA. Adicionalmente se logr´o estructurar en gran parte el driver que finalmente quedar´a en la implementaci´ on final. Durante esta etapa, se implement´ o el driver que permite manipular el perif´erico XPS HWICAP desde el espacio del kernel. Mediante este driver, se busca tener una implementaci´ on con mejor desempe˜ no. La funci´on de un driver es generar los mecanismos de acceso a un recurso del sistema de c´omputo. En el caso de un perif´erico, esto implica el acceso a los registros que controlan su funcionamiento y los registros por medio de los cuales se intercambia informaci´on. Adicionalmente dentro del sistema operativo Linux, todos los recursos son abstraidos como archivos, por lo tanto el driver tambi´en tiene que llevar a Universidad Industrial de Santander

69

Driver del perif´erico XPS HWICAP cabo las acciones adecuadas en el momento que un usuario o un proceso acceda a dicho archivo. Desde el punto de vista del usuario, o de un proceso que corre en el sistema operativo, el perif´erico aparece como un archivo cuya longitud es la cantidad de registros del perif´erico y para su acceso se deben ejecutar los llamados al sistema open, close, write, read, lseek, etc. Estos llamados al sistema son funciones que solicitan al kernel ejercer una acci´on sobre los archivos, pero en el caso de un perif´erico, estas funciones son atendidas por el driver. De esta forma el creador del driver puede decidir la acci´on en el perfi´erico m´as adecuada seg´ un la operaci´ on solicitada desde el espacio del usuario. 4.2.5.1

Estructura de la implementaci´ on del driver desde el espacio del kernel

Para llevar a cabo la versi´on del driver desde el espacio del kernel, se opt´o por implementar u ´nicamente las funciones de bajo nivel del driver desarrollado en el espacio del usuario, de esta forma se obtiene el beneficio que ofrece llevar a cabo las operaciones de lectura y escritura de bajo nivel en el kernel, mientras que las operaciones de mas alto nivel como escribir y leer frames se realizan desde el espacio del usuario y pueden ser modificadas mas f´acilmente en futuras versiones. La nueva estructura del driver no cambi´o significativamente, pero si hay que hacer unas modificaciones en las fuentes y crear el driver que trabajar´a desde el espacio del kernel. 4.2.5.2

Desarrollo del m´ odulo del kernel

Con el objetivo de adquirir mayor destreza con el manejo de los datos en el espacio del kernel, el desarrollo del m´odulo se hizo de forma gen´erica para que pueda ser empleado para cualquier perif´erico y despu´es fue adaptado para el XPS HWICAP. Como resultado de este proceso ha quedado una plantilla para cualquier perif´erico basado en registros na gu´ıa para que conectados al bus, la cual se encuentra en el Anexo H. All´ı mismo se presenta una peque˜ pueda ser adaptado r´ apidamente a cualquier perif´erico. Este procedimiento fue aplicado sobre el perif´erico XPS HWICAP. El driver del perif´erico tiene a cargo las funciones de m´as bajo nivel, por lo tanto es muy similar a un driver gen´erico de cualquier perif´erico que se manipule mediante sus registros a˜ nadidos al bus principal del procesador. A continuaci´on se describen las acciones que el driver lleva a cabo en cada una de las rutinas implementadas. XPS HWICAP init: Esta funci´on es invocada cuando se lleva a cabo desde el espacio el usuario el comando insmod que a˜ nade al kernel el driver. En esta funci´on se realizan las siguientes funciones: • Reservar los n´ umeros major y minor para nuestro perif´erico. Universidad Industrial de Santander

70

Driver del perif´erico XPS HWICAP • Reservar memoria en el espacio del kernel para una estructura de tipo XPS HWICAP dev que contiene informaci´on del perif´erico y que es utilizada por todas las funciones del mismo. • Inicializar algunos campos de la estructura como un mutex que hace que el perif´erico solo sea abierto una vez. • Inicializar el tipo de dato cdev del perif´erico para posteriormente registrarlo en el kernel. • Poner en cero una bandera indicando que este perif´erico nunca ha sido abierto. XPS HWICAP exit: esta funci´on es llamada cuando se ejecuta el comando rmmod para retirar el driver del kernel. Esta funci´on debe deshacer todo lo que XPS HWICAP init hizo, por eso cumple las siguientes funciones: • Libera los n´ umero major y minor registrados anteriormente. • Remueve el cdev del kernel. • Libera la memoria reservada para mapear los registros. Esto se hace u ´nicamente si se ha ejecutado la rutina de open. Por lo cual se pregunta por la bandera desactivada en init y activada en open. • Libera la memoria reservada para la estructura XPS HWICAP dev. a asociada con el llamado al sistema open, el cual busca tener XPS HWICAP open: Esta rutina est´ acceso al dispositivo. En esta rutina se llevan a cabo las siguientes acciones: • Asignar el campo private data del puntero file con la estructura que contiene el cdev, de esta forma se tiene acceso a esta estructura desde cualquier funci´on del driver. • Se reserva el perif´erico activando el mutex. • En caso de ser la primera vez que se ejecuta el open, se inicializan los campos de la estructura XPS HWICAP dev, esto incluye hacer la reserva de memoria donde se mapean los registros del perif´erico. As´ı mismo se activa la bandera que indica que ya se inicializ´ o la estructura. • Se realiza el ioremap para acceder a los registros del perif´erico. XPS HWICAP release: Esta funci´on est´ a asociada con el llamado al sistema close. En esta funci´on se deshacen la mayor parte de las acciones de la funci´on XPS HWICAP open. Las acciones espec´ıficas son: • Libera la memoria y lo necesario para acceder a los registros del perif´erico. • Libera el perif´erico modificando el mutex.

Universidad Industrial de Santander

71

Driver del perif´erico XPS HWICAP XPS HWICAP write: Esta funci´on se asocia con el llamado al sistema write y busca traer datos desde el espacio del usuario hacia el espacio del kernel. Realiza las siguientes acciones: • Verifica que la cantidad de informaci´on que se va a escribir no sobrepasa la cantidad de registros del perif´erico. En caso de hacerlo, determina la cantidad de bytes que se pueden escribir. • usa la funci´on copy from user para traer la informaci´on desde el espacio del usuario. • Actualiza los datos que se quieren escribir en la estructura, como una copia de la informaci´on que se escribe en los registros. • Se escriben los datos en los registros mediante la funci´on iowrite32. • Se actualiza el puntero del archivo seg´ un la cantidad de datos escritos. • Se devuelve la cantidad de datos escritos. a asociada con el llamado al sistema read y busca devolver XPS HWICAP read: La funci´on read est´ informaci´on al usuario sobre los registros del perif´erico. Durante su ejecuci´ on se llevan a cabo las siguientes tareas: • Verifica que la cantidad de informaci´on solicitada se pueda dar, en caso de que no, solo da la informaci´on disponible. • Lee de los registros la cantidad de informaci´on solicitada. • Cambia el endianness a los datos leidos. • Env´ıa los datos al usuario por medio de la funci´on copy to user. • Actualiza el puntero del archivo seg´ un la cantidad de datos devueltos. XPS HWICAP llseek: Esta funci´on se encarga de cambiar la posici´on actual del puntero. Su implementaci´ on se hizo de forma est´ andar, debido a que no requiere ejercer ninguna acci´on particular en el perif´erico. un el perif´erico que XPS HWICAP iocntl: Esta funci´on permite ejecutar funciones personalizadas seg´ se est´ a manejando. En el caso del XPS HWICAP no se requiri´o alguna acci´on particular. 4.2.5.3

Modificaciones sobre las librer´ıas del espacio del usuario.

La librer´ıa xil io.c en esta versi´on tiene la funci´on de manipular el puntero dentro del archivo para que se dirija al registro espec´ıfico que se desea acceder y luego escribe o lee el dato. Adicionalmente se debe modificar las fuentes para que en alg´ un momento se ejecuten los llamados al sistema open y close. Inicialmente se llevaron a cabo estos llamados al sistema en las rutinas de la librer´ıa xil io.c pero esto es ineficiente debido a la gran cantidad de escrituras y lecturas que se deben hacer en el perif´erico para Universidad Industrial de Santander

72

Driver del perif´erico XPS HWICAP llevar a cabo una reconfiguraci´ on. Por ello se opt´o finalmente por hacer los llamados s´ olamente una vez en los archivos de mas alto nivel realizando las siguientes cuatro modificaciones: Adici´ on de librer´ıas: Con el objetivo de que las rutinas que escriben en los registros del perif´erico, puedan manipular el nodo /dev/periferico XPS HWICAP, es necesario incluir las siguientes librer´ıas #i n c l u d e < s t d l i b . h> #i n c l u d e < f c n t l . h>

Cuadro de C´odigo 4.5: Adici´ on de las librer´ıas stdlib.h y fcntl.h. Declaraci´ on del puntero del archivo: Es necesario que las funciones de bajo nivel reciban el puntero con el que deben manipular el archivo del perif´erico, el cual se obtiene del llamado al sistema open, por eso se debe declarar de forma global en el archivo de m´as alto nivel: size t

filedesc ;

Cuadro de C´odigo 4.6: Declaraci´on del puntero del archivo. Adici´ on de la funci´ on open: La funci´on open solo se debe hacer una vez para cada programa que use el perif´erico porque esto garantiza que solo ´el est´ a usando el perif´erico en este momento. Cualquier otro proceso que quiera acceder al perif´erico debe esperar a que el proceso que lo tiene ocupado pues lo libere mediante la funci´on close. Por ello se ubic´ o comenzando la funci´on principal del programa. f i l e d e s c = open ( ” / dev / Periferico XPS HWICAP ” ,O RDWR) ; /∗ En c a s o de no p o d e r a b r i r l o , e n t o n c e s s e t e r m i n a e l programa i f ( f i l e d e s c < 0) { p r i n t f ( ”No s e pudo a b r i r e l nodo / dev / Periferico XPS HWICAP \n” ) ; e x i t ( EXIT FAILURE ) ; }

∗/

Cuadro de C´odigo 4.7: Adici´ on del llamado al sistema open. Adici´ on de la funci´ on close: As´ı como la funci´on open, la funci´on close libera el perif´erico y se lleva a cabo al final de la funci´on principal del programa. /∗ Llamado a l s i s t e m a c l o s e i f ( c l o s e ( f i l e d e s c ) < 0) { p r i n t f ( ”No s e pudo c e r r a r e x i t ( EXIT FAILURE ) ; }

∗/ e l nodo / dev / Periferico XPS HWICAP \n” ) ;

Cuadro de C´odigo 4.8: Adici´ on del llamado al sistema close. 4.2.5.4

Nueva librer´ıa xil io.c

La librer´ıa xil io.c cambi´o completamente debido a que su forma de acceso al perif´erico cambi´o radicalmente. Su versi´on modificada se puede ver en el Anexo G. Ahora debe usar el puntero declarado en el archivo de mayor jerarqu´ıa para ajustarlo y escribir o leer adecuadamente los registros. Con el objetivo de mantener compatibilidad con las funciones de la versi´on que funcion´ o desde el espacio del usuario, el Universidad Industrial de Santander

73

Resultados del cap´ıtulo prototipo de las funciones Xil Out32 y Xil In32 no se modific´ o. Las funciones de lectura y escritura tienen una estructura similar. Inicialmente reciben la direcci´on a la que se desea escribir o leer, la cual es validada para garantizar que esta est´e en el rango del perif´erico. All´ı se calcula el offset del registro que se quiere acceder a partir del baseaddress del perif´erico. Posteriormente se ajusta el puntero del archivo mediante lseek y se hace la operaci´ on de lectura o escritura con write o read.

4.3

Resultados del cap´ıtulo

Al llevar a cabo el procedimiento del presente cap´ıtulo, se ha modificado el sistema base al a˜ nadirle dos perif´ericos nuevos. El primero es un perif´erico de prueba que permiti´o realizar pruebas de reconfiguraci´ on que finalmente determinaron los bits exactos que modifican el comportamiento de las LUTs del FPGA dentro de un archivo de configuraci´ on. Simult´ aneamente se requiri´o la implementaci´ on del perif´erico reconfigurable y de la puesta en marcha del driver que permiti´o hacer la reconfiguraci´ on del comportamiento de las LUTs. Con esto el sistema ML507 tiene los mecanismos para f´acilmente manpular el comportamiento de cada una de sus LUTs mediante reconfiguraci´ on parcial.

Universidad Industrial de Santander

74

Cap´ıtulo

Pruebas finales y conclusiones 5.1

Medici´ on del tiempo de reconfiguraci´ on

La estrategia empleada para la medici´ on del tiempo que tarda el proceso de reconfiguraci´ on se bas´ o en funciones que trabajan en el espacio del kernel. Otra alternativa consiste en el uso de funciones en el espacio del usuario que consultan la hora y fecha actuales del sistema, sin embargo estas funciones tienen mayor impacto sobre la medida del tiempo debido a que no tienen los privilegios de acceso que tienen las funciones del espacio del kernel. Adicionalmente la resoluci´ on de la medida en muchos casos no es menor a 1ms. En el espacio del kernel se seleccion´ o la funci´on get cycles() para hacer la medici´ on debido a que est´ a implementada con instrucciones de ensamblador propias del procesador y adem´ as obtiene la mejor resoluci´ on posible. Esta funci´on consulta la cantidad de ciclos de reloj que han sucedido desde que se encendi´ o el sistema. Conociendo los ciclos de reloj y teniendo en cuenta que la frecuencia de trabajo del procesador es de 400 M Hz, (´esto significa una resoluci´ on por ciclo de reloj de

1 400 M Hz

= 2, 5 ns), podemos

medir el tiempo empleado en la reconfiguraci´ on. Para llevar a cabo la medida se tom´ o una marca de tiempo al iniciar, en puntos intermedios y al terminar el proceso de reconfiguraci´ on. Gracias a que las aplicaciones que usan el driver se implementaron haciendo una u ´nica vez la apertura y el cierre del nodo /dev/Periferico XPS HWICAP, all´ı se tomaron las marcas de tiempo inicial y final. Para llevar a cabo las marcas de tiempo intermedias, fue necesario emplear el llamado al sistema ioctl desde el espacio del usuario para dar al programador la posibilidad de ordenar la toma de estas muestras desde el espacio del usuario. La aplicaci´on que se us´ o para hacer las mediciones fue w escribe una LUT Esto requiri´o algunas modificaciones sobre el c´odigo del driver y de la aplicaci´on w escribe una LUT

Universidad Industrial de Santander

75

5

Medici´ on del tiempo de reconfiguraci´ on que se detallan a continuaci´on:

5.1.1

Modificaciones a la aplicaci´ on w escribe una LUT.

Desde el espacio del usuario se modific´ o el archivo w escribe una LUT.c para agregar los llamados al sistema que imprimen las marcas de tiempo antes y despu´es de cada lectura o escritura de un frame. Debido a que son 4 frames los que se leen y se escriben para poder configurar una LUT, entonces se hicieron en total 16 llamados ioctl por cada ejecuci´ on de este programa. La adici´on del llamado ioctl fue necesaria porque en las rutinas contenidas en el driver es muy dif´ıcil identificar cuando han comenzado y finalizado los subprocesos que se llevan a cabo en la reconfiguraci´ on. El siguiente listado muestra la modificaci´ on al archivo: // Marca de tiempo i f ( i o c t l ( f i l e d e s c , COMANDO 0) //#i n c l u d e ” x i l t y p e s . h” //#i n c l u d e ” x i l a s s e r t . h” #i n c l u d e ” w e s c r i b e u n a L U T . c ” //#d e f i n e HWICAP DEVICEID

0

main ( ) { t i m e t now ; c h a r name [ 1 3 ] , b u f [ 6 0 ] ; int ptid ; i n t sy , l u t ; p t i d = pvm parent ( ) ; /∗ t h e ID o f t h e m a s t e r p r o c e s s ∗/ p v m s e t o p t ( PvmRoute , PvmRouteDirect ) ; g e t h o s t n a m e ( name , now=t i m e (NULL ) ;

64);

/∗ f i n d name o f machine ∗/ /∗ g e t t i m e ∗/

s t r c p y ( buf , name ) ; s t r c a t ( buf , ” ’ s t i m e i s ” ) ; s t r c a t ( buf , c t i m e (&now ) ) ;

/∗ put name i n t o

s t r i n g ∗/

/∗ add t i m e t o s t r i n g ∗/

p v m i n i t s e n d ( PvmDataDefault ) ; p vm p ks tr ( b u f ) ; pvm send ( p t i d , 2 ) ;

/∗ a l l o c a t e message b u f f e r ∗/ /∗ pack s t r i n g i n t o b u f f e r ∗/ /∗ s e n d b u f f e r t o m a s t e r ∗/

f o r ( s y =20; sy /root/.vimrc

Finalmente para activar el color al ejecutar ls, se puede modificar al archivo .bashrc agregando la l´ınea: /root/.bashrc 1 2

alias ls=’ls --color=always’

Universidad Industrial de Santander

91

servidor DNS y RDNS

A.3

servidor DNS y RDNS

El servidor DNS y RDNS permitir´ an relacionar el nombre en la red de un equipo con su IP. Es necesario instalar en el nodo maestro el sevicio que puede ser accedido desde la subred del cluster como se muestra en la Figura A.3.

Figura A.3: Elementos involucrados en la instalaci´on del servidor DNS y RDNS. Inicialmente en el servidor se debe instalar el paquete bind9: Okinawa-00# apt-get install bind9

se configura el archivo named.conf.options para que el servidor s´ olamente permita consultas dentro de la subred 192.168.16.0 /etc/named.conf.options 1 2 3

auth-nxdomain no; listen-on-v6 { any; };

4 5 6 7

version none; allow-query { 192.168.16.0/24; }; allow-transfer { none; };

Ahora debemos alimentar la base de datos del servidor de nombres de dominio para ello se crean los archivos db.okinawa.net y db.16.168.192 en la carpeta \etc\bind\

Universidad Industrial de Santander

92

servidor DNS y RDNS /etc/bind/db.okinawa.net 1 2 3 4 5 6 7 8 9

$TLL$ 24h okinawa.net. 2008042300 3h 30m 7d 3h )

IN SOA Okinawa-00.okinawa.net root.okinawa.net ( ; numero serial ; tiempo de refresco ; tiempo de reintento ; tiempo de "expire" ; negative caching ttl

10 11 12

; Nameservers okinawa.net. IN

NS

192.168.16.150.

13 14 15 16 17

; Hosts Okinawa-00.okinawa.net. Okinawa-01.okinawa.net. Okinawa-02.okinawa.net.

IN IN IN

A A A

192.168.16.150 192.168.16.151 192.168.16.152

/etc/bind/named.conf.local 1 2

$TTL$

24h

3 4 5 6 7 8 9 10

16.168.192.in-addr.arpa. IN SOA Okinawa-00.okinawa.net root.okinawa.net ( 2008042300 ; numero serial 3h ; tiempo de refresco 30m ; tiempo de reintento 7d ; tiempo de "expire" 3h ; negative caching ttl )

11 12 13

; NameServers 16.168.192.in-addr.arpa.

IN

NS

192.168.16.150.

; Hosts 150.16.168.192.in-addr.arpa. 151.16.168.192.in-addr.arpa. 152.16.168.192.in-addr.arpa.

IN IN IN

PTR PTR PTR

14 15 16 17 18

Okinawa-00.okinawa.net. Okinawa-01.okinawa.net. Okinawa-02.okinawa.net.

Posteriormente se referencian estos dos archivos creados dentro del archivo named.conf.local para que sean tenidos en cuenta al reiniciar el servicio DNS. /etc/bind/named.conf.local 1 2 3 4 5

zone "okinawa.net" { type master; file "/etc/bind/db.okinawa.net"; };

6 7 8 9 10

zone "16.168.192.in-addr.arpa" { type master; file "/etc/bind/db.116.168.192"; };

Universidad Industrial de Santander

93

Configuraci´ on el servidor DCHP en el nodo maestro En todos los equipos de la red es necesario configurar el archivo /etc/resolv.conf. /etc/resolv.conf

/etc/resolv.conf

1 2 3

1

search okinawa.net nameserver 192.168.16.150

2 3

search okinawa.net nameserver 192.168.16.150

Ahora es necesario reiniciar el servicio DNS mediante el comando: Okinawa-00# /etc/init.d/bind9 restart

Para comprobar el funcionamiento del servidor, podemos consultar el nombre de red de los equipos de la red y sus IP mediante el comando host. Okinawa-00# Okinawa-00# Okinawa-00# Okinawa-00#

host host host host

Okinawa-00 Okinawa-01 192.168.16.150 192.168.16.151

Okinawa-01# Okinawa-01# Okinawa-01# Okinawa-01#

host host host host

Okinawa-00 Okinawa-01 192.168.16.150 192.168.16.151

En caso de que no funcione, es recomendable revisar el contenido de los siguientes archivos: /etc/hosts 1 2 3

127.0.0.1 192.168.16.150

localhost Okinawa-00.okinawa.net

Okinawa-00

4 5 6 7 8 9 10 11

# The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ff02::3 ip6-allhosts /etc/hosts.allow

1 2

A.4

ALL: 192.168.16.0

Configuraci´ on el servidor DCHP en el nodo maestro

En caso de contar con un dispositvo de red que no tiene la funci´on de servidor DHCP, esta secci´on describe la instalaci´ on de un servidor en el nodo maestro. Este proceso se inicia mediante la instalaci´on del paquete dhcp3-server: Okinawa-00# apt-get install dhcp3-server

Posteriormente se edit´o el archivo /etc/dhcp3/dhcp.conf para realizar la configuraci´ on del servidor. El siguiente ejemplo muestra la configuraci´ on de un servidor, el cual es el encargado principal de asignar las direcciones en el segmento de red 192.168.16.0. Universidad Industrial de Santander

94

Configuraci´ on el servidor DCHP en el nodo maestro /etc/dhcp3/dhcp.conf 1 2

ddns-update-style none;

3 4 5

option domain-name "okinawa.net"; option domain-name-server 192.168.16.190;

6 7 8

default-lease-time 14400; max-lease-time 14400;

9 10

authoritative;

11 12

log-facility local7;

13 14 15 16 17

subnet 192.168.16.0 netmask 255.255.255.0 { option domain-name "okinawa.net"; deny unknown-clients; }

18 19 20 21

group { option routers 192.168.16.1; next-server 192.168.16.1;

22

host Okinawa-00.okinawa.net { hardware ethernet 00:16:CB:AE:C3:DD; fixed-address 192.168.16.150; option host-name "Okinawa-00"; }

23 24 25 26 27 28

host Okinawa-01.okinawa.net { hardware ethernet 00:0C:29:7E:BE:FD; fixed-address 192.168.16.151; option host-name "Okinawa-01"; }

29 30 31 32 33 34

host Okinawa-21.okinawa.net { hardware ethernet 00:0A:35:01:D7:4E; fixed-address 192.168.16.171; option host-name "Okinawa-21"; }

35 36 37 38 39 40

host Okinawa-22.okinawa.net { hardware ethernet 00:0A:35:01:D7:1D; fixed-address 192.168.16.172; option host-name "Okinawa-22"; }

41 42 43 44 45 46

}

Una vez modificado el archivo de configuraci´ on, se puede reiniciar el demonio DHCP mediante el comando: Okinawa-00# /etc/init.d/dhcp3-server restart

y se puede comprobar desde el nodo esclavo ejecutando: Universidad Industrial de Santander

95

Instalaci´on y configuraci´ on del servidor y los clientes NFS. Okinawa-01# dhclient

A.5

Instalaci´ on y configuraci´ on del servidor y los clientes NFS.

El primer paso fue instalar en el maestro y en el nodo los paquetes correspondientes: Okinawa-00# apt-get install nfs-common nfs-kernel-server

Okinawa-01# apt-get install nfs-common

Luego se cre´o el directorio que se comparti´ o y se le modificaron sus permisos. Okinawa-00# Okinawa-00# Okinawa-00# Okinawa-00#

mkdir mkdir chmod chmod

-p /compartido/x86 -p /compartido/powerpc 777 /compartido/x86 777 /compartido/powerpc

Se configur´ o el servidor NFS editando el archivo de configuraci´ on /etc/exports /etc/exports 1 2 3

/compartido/x86 192.168.16.0/255.255.255.0(sync,no_wdelay,subtree_check,rw) /compartido/powerpc 192.168.16.0/255.255.255.0(sync,no_wdelay,subtree_check,rw)

Se reinici´ o el servicio del servidor NFS. Okinawa-00# /etc/init.d/nfs-kernel-server restart

Se puede verificar su funcionamiento consultando los directorios que se est´ an exportando mediante el comando Okinawa-00# exportfs

En el cliente, se cre´o la carpeta donde mont´ o el directorio compartido y se modific´ o el archivo fstab donde se configuraron algunas propiedades de este directorio. Okinawa-01# mkdir -p /compartido/x86 /etc/fstab 1 2

192.168.16.150:/compartido/x86

/compartido/x86

nfs

defaults

0

0

finalmente se reinici´ o el servicio del cliente NFS Okinawa-01# /etc/init.d/nfs-common restart

Universidad Industrial de Santander

96

Configuraci´ on de SSH y los usuarios Tambi´en es posible solicitar a linux que monte las unidades indicadas en el archivo /etc/fstab mediante el comando Okinawa-01# mount -a

se puede verificar los sistemas de archivos montados mediante el comando Okinawa-01# mount

A.6

Configuraci´ on de SSH y los usuarios

La configuraci´ on de ssh es necesaria para la ejecuci´ on de herramientas en el cluster, adem´ as facilita el entorno de trabajo al permitir el acceso remoto a los nodos sin necesidad ubicarse f´ısicamente cerca de ´el. Las herramientas del cluster, exigen que los usuarios del cluster puedan iniciar sesiones remotas en los nodos del sistema sin la necesidad de password. Para iniciar el proceso es necesario instalar ssh en el maestro y en el nodo. Okinawa-00# apt-get install ssh

Okinawa-01# apt-get install ssh

con esto se debe tener la posibilidad de ejecutar comandos como ssh o ssh-keygen. Ahora proseguiremos con la configuraci´ on de los usuarios, para lo cual modificamos el archivo /etc/adduser.conf en el maestro y en el esclavo para modificar los par´ ametros de los nuevos usuarios en el sistema. Espec´ıficamente se modificar´an las siguientes l´ıneas para modificar la ubicaci´ on del directorio raiz e impedir la creaci´on de un grupo por cada usuario: /etc/adduser.conf 1 2 3

/etc/adduser.conf 1

DHOME=/compartido/home USERGROUPS=no

2 3

DHOME=/compartido/home USERGROUPS=no

Ahora creamos un usuario en el host y en el esclavo, e ingresamos las opciones por defecto. Okinawa-00# adduser william

Okinawa-01# adduser william

El siguiente paso busca crear las llaves p´ ublicas y privadas del usuario, para lo cual debemos ingresar al nodo maestro como el nuevo usuario y se ejecuta: Okinawa-00# su william william@Okinawa-00# cd william@Okinawa-00# ssh-keygen

Universidad Industrial de Santander

97

servidor TFTP Se deben dejar las opciones por defecto y no asignar ning´ un passphrase. Este comando debe crear los archivos id_rsa.pub y id_rsa dentro del directorio /compartido/comun/home/william/.ssh/. El contenido de la llave p´ ublica debe ser insertado en el archivo authorized_keys2 para que no se solicite la clave al mismo usuario. william@Okinawa-00# cd .ssh william@Okinawa-00# cat id_rsa.pub >> authorized_keys2

se le ajustan los permisos. william@Okinawa-00# chmod 600 authorized.keys2

Se puede comprobar que el proceso ha funcionado si al iniciar una sesi´on sobre el nodo esclavo con el mismo usuario, este no solicita la clave. william@Okinawa-00# ssh william@Okinawa-01

william@Okinawa-01# ssh william@Okinawa-00

A.7

servidor TFTP

El servidor TFTP permitir´ a descargar el kernel y los archivos de configuraci´ on durante el arranque de los FPGA. El servidor TFTP se instal´o en el nodo maestro, mediante el siguiente paquete: Okinawa-00# apt-get install tftpd-hpa

Ahora creamos el directorio que se compartir´a a los dem´ as nodos del sistema y se le dan permisos de solo lectura. El directorio Linuxboot es un subdirectorio del servidor donde se almacenar´an el kernel y la configuraci´ on de cada nodo basado en FPGA. Okinawa-00# mkdir -p /compartido/tftpboot/Linuxboot Okinawa-00# chmod 755 /compartido/tftpboot Okinawa-00# chmod 755 /compartido/tftpboot/Linuxboot

El archivo de configuraci´ on /etc/default/tftpd-hpa permite indicar el directorio que se va a compartir y el modo en el que el servidor se iniciar´a. Normalmente este servicio es iniciado por el servicio inet, pero para nuestro caso se iniciar´a como un servicio independiente, por lo cual se debe habilitar dicha opci´on en el archivo de configuraci´ on. /etc/default/tftpd-hpa 1 2 3

RUN_DAEMON="yes" OPTIONS="-l -s /compartido/tftpboot"

Universidad Industrial de Santander

98

Herramientas para compilaci´on cruzada Igualmente es necesario deshabilitar el servicio TFTP en el archivo de configuraci´ on inet, para lo cual se edita el archivo /etc/inetd.conf comentando la l´ınea relacionada con este servicio. Posteriormente se reinici´ o el servicio del servidor TFTP. Okinawa-00# /etc/init.d/tftpd-hpa restart

La verificaci´on se puede realizar mediante la revisi´ on de los procesos activos y de los puertos de escucha que abre el servicio TFTP. Para ello se pueden ejecutar los siguientes comandos: Okinawa-00# Okinawa-00#

ps aux | grep tftpd netstat -plun | grep tftp

Otra forma de verificaci´on es mediante la transferencia de un archivo de prueba a un nodo trabajador. El siguiente comando permite crear el archivo de prueba que se va a transmitir. Okinawa-00# echo "Hola prueba" >> /compartido/tftpboot/Linuxboot/testfile

En el cliente es necesario instalar el cliente TFTP, para lo cual se ejecuta Okinawa-01#

apt-get install tftp-hpa

Ahora el cliente debe solicitar el archivo de prueba y verificar su existencia mediante los siguientes comandos: Okinawa-01# Okinawa-01#

tftp Okinawa-00 -c get Linuxboot/testfile cat ./testfile

(Introducci´on para la segunda gu´ıa de usuario) Durante esta secci´on se instalar´ a el sistema operativo de los embedded system sobre los sistemas ML507, para lo cual es necesario configurar previamente un conjunto de herramientas para el desarrollo del mismo. La Figura A.4 presenta los elementos de la implementaci´ on f´ısica involucrados durante esta secci´on.

A.8

Herramientas para compilaci´ on cruzada

Dentro de las herramientas necesarias para la instalaci´on se encuentran los compiladores cruzados. Se ha seleccionado los que est´ an contenidos en la herramienta ELDK, los cuales se pueden descargar como una imagen iso desde la p´agina denx. Esta imagen se grab´ o en un DVD y se mont´ o en el sistema Linux del host con permisos de ejecuci´ on mediante el siguiente comando: Okinawa-00# mount -o exec /dev/cdrom /media/cdrom

Universidad Industrial de Santander

99

Instalaci´on del sistema base en la tarjeta

Figura A.4: Elementos involucrados en esta secci´on.

Ahora es posible ejecutar el script de instalaci´on ./install que se encuentra en el directorio raiz del DVD . Es necesario tener instalado gcc y los permisos de ejecuci´ on para efectuar esta tarea correctamente. Se destin´o el directorio /opt/ELDK/4.2 como la raiz de la instalaci´on del ELDK y se ha seleccionado la R arquitectura PowerPC 4xx con unidad de punto flotante.

Okinawa-00# cd /media/cdrom Okinawa-00# ./install -d /opt/ELDK/4.2 ppc_4xxFP

El siguiente paso fue ajustar las variables de entorno para los compiladores cruzados mediante el script eldk_init para la arquitectura ppc 4xxFP. Esto se debe hacer al inicio de cada sesi´on donde se empleen estos compiladores. Okinawa-00# cd /media/cdrom Okinawa-00# source eldk_init ppc_4xxFP

Adicionalmente los scripts ELDK_FIXOWNER y ELDK_MAKEDEV permiten ajustar los permisos y los propietarios de los archivos de desarrollo. Para ello ejecutamos las siguientes l´ıneas: Okinawa-00# /media/cdrom/ELDK_FIXOWNER -a ppc_4xxFP Okinawa-00# /media/cdrom/ELDK_MAKEDEV -a ppc_4xxFP

En los directorios /opt/ELDK/4.2/ppc_4xxFP y /opt/ELDK/4.2/usr/bin se pueden verificar los archivos que la herramienta ha instalado. All´ı deben aparecer un sistema de archivos para el embedded system y los archivos ejecutables del compilador cruzado, respectivamente.

A.9

Instalaci´ on del sistema base en la tarjeta

Durante esta etapa se implementa el sistema de c´omputo base sobre el FPGA como lo indica la Figura A.5. Universidad Industrial de Santander

100

Instalaci´on del sistema base en la tarjeta

Figura A.5: Elementos involucrados en la implementaci´ on del sistema base.

El sistema base corresponde al hardware b´asico del embedded system que contiene el bus sobre el cual est´ a el procesador, los perif´ericos y las memorias. El sistema base que se emple´ o se puede descargar desde el sitio del fabricante en la direcci´on: https://secure.xilinx.com/webreg/clickthrough.do?cid=111799. Este es un archivo comprimido que contiene un proyecto en EDK con el mapa de memoria mostrado en la tabla A.1: Elemento R Procesador PowerPC 440 Bloque RAM GPIO Leds GPIO Positions GPIO PushButtons GPIO DipSwitch IIC EEPROM Controlador de Interrupciones MAC HW Ethernet SysACE CompactFlash Temporizador Watchdog Temporizador Puerto Serie RS-232 RAM DDR2 Memoria Flash

Direcci´ on base

Tama˜ no Rango

0xFFFF0000 0x81400000 0x81420000 0x81440000 0x81460000 0x81600000 0x81800000 0x81C00000 0x83600000 0x83A00000 0x83C00000 0x83E00000 0x00000000 0xFC000000

64K 64K 64K 64K 64K 64K 64K 64K 64K 64K 64K 64K 256MB 32MB

Tabla A.1: Mapa de memoria del sistema base

Inicialmente solo se requiere descargar el proyecto al FPGA con las opciones por defecto, por lo tanto solo es necesario abrirlo y descargar el bitstream y comprobar su funcionamiento.

Universidad Industrial de Santander

101

Instalaci´on del Bootloader

A.10

Instalaci´ on del Bootloader

Durante esta secci´on se descargar´a la fuente del u-boot, se compilar´ a y se instalar´ a en la memoria Flash del sistema de desarrollo ML507. La Figura A.6 muestra de forma global el proceso.

Figura A.6: Elementos involucrados en la instalaci´on del bootloader. Inicialmente, crearemos el directorio donde se almacenar´ an las fuentes del u-boot y del kernel. Okinawa-00# mkdir -p /opt/SoftDev/Xilinx Okinawa-00# cd /opt/SoftDev/Xilinx

Ahora se debe descargar la fuente, para lo cual se proponen tres formas: mediante el comando git que sincroniza repositorios en internet, directamente con la url de la fuente o directamente en el navegador. R La fuente seleccionada es la que el grupo de trabajo de Xilinx ha adaptado para este sistema.

Obtenci´ on de la fuente mediante git (Recomendado) Okinawa-00# git clone git://git.xilinx.com/u-boot-xlnx.git Obtenci´ on de la fuente mediante wget Okinawa-00# wget http://git.xilinx.com/cgi-bin/gitweb.cgi?p=u-boot-xlnx Obtenci´ on de la fuente mediante el navegador ingresar a la p´ agina http://git.xilinx.com/cgi-bin/gitweb.cgi y luego seleccionar el tree del proyecto /u-boot-xlnx.git, donde se encuentra un enlace con el texto snapshot el cual descarga la fuente en un archivo comprimido u-boot-xlnx.git-HEAD.tar.gz

En caso de usar el modo gr´ afico, es necesario descomprimir en la carpeta /opt/SoftDev/Xilinx el archivo u-boot-xlnx.git-HEAD.tar.gz. Para ello se puede usar el siguiente comando que permite mantener los permisos de los archivos: Okinawa-00# tar xvfzp u-boot-xlnx.git-HEAD.tar.gz

Universidad Industrial de Santander

102

Instalaci´on del Bootloader Una vez obtenida la fuente, se adaptar´ a la misma a las especificaciones de la tarjeta. Hay que tener en cuenta que el bootloader est´ a hecho teniendo en cuenta el mapa de memoria del dise˜ no de referencia que R se encuentra en el sitio de Xilinx como se explic´o en la secci´on A.9; por lo tanto se debe confimar que el

archivo /opt/SoftDev/Xilinx/board/xilinx/ml507/xparameters.h de la fuente corresponda con el archivo xparameters.h del proyecto de EDK trabajado en la secci´on anterior. Adicionalmente es necesario realizar algunos cambios sobre la fuente en el archivo que permite configurar par´ ametros del u-boot como los comandos disponibles y las variables de entorno. Este archivo se encuentra en /opt/SoftDev/Xilinx/u-boot-xlnx.git/include/configs/ml507.h y las modificaciones fueron las siguientes: /opt/SoftDev/Xilinx/u-boot-xlnx.git/include/configs/ml507.h 1 2 3 4

// Opciones para habilitar la depuraci´ on de las acciones de u-boot #define DEBUG #define ET_DEBUG 1

5 6 7 8

// Temporizador y comando de arranque #define CONFIG_BOOTDELAY 2 #define CONFIG_BOOTCOMMAND "run bootnfs"

9 10 11 12 13 14 15 16

// Comandos ejecutados antes del conteo regresivo #define CONFIG_PREBOOT "echo ;" \ "echo Bootloader configurado por W;" \ "echo -------------------------;" \ "echo ;" \ "echo Arranque por defecto: $(bootcmd);" \ "echo"

17 18 19 20

// Opciones de la l´ ınea de comandos #define CONFIG_AUTO_COMPLETE #define CONFIG_CMDLINE_EDITING

21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

// Definici´ on de las variables de entorno #define CONFIG_EXTRA_ENV_SETTINGS \ "serverip=192.168.16.150\0" \ "ipaddr=192.168.16.172\0" \ "bootnfs=run loadkernel;run loaddtb;setenv ramimg_addr -;run runkernel\0" \ "boottftp=run loadkernel;run loadramimg;run loaddtb;run runkernel\0" \ "loadkernel=tftp $(kernel_addr) $(bootfile)\0" \ "kernel_addr=0x1c00000\0" \ "bootfile=Linuxboot/uImage\0" \ "loadramimg=tftp $(ramimg_addr) $(ramfile)\0" \ "ramimg_addr=0x1800000\0" \ "ramfile=Linuxboot/ramimg.gz\0" \ "loaddtb=tftp $(dtb_addr) $(dtbfile)\0" \ "dtb_addr=0x1000000\0" \ "dtbfile=Linuxboot/ml507.dtb\0" \ "runkernel=bootm $(kernel_addr) $(ramimg_addr) $(dtb_addr)\0"

Universidad Industrial de Santander

103

Instalaci´on del Bootloader Una vez est´ a lista la fuente, debemos asegurarnos de que las variables de entorno relacionadas con el compilador cruzado est´en correctamente. Para ello podemos ejecutar el comando: Okinawa-00# /opt/ELDK/4.2/eldk_init 4xx_FP

Ahora mediante el comando make compilamos el kernel en dos etapas: Okinawa-00# make ml507_config Okinawa-00# make

El primer comando se encarga de generar un archivo de configuraci´ on con las opciones de compilaci´ on que son tomadas por el segundo comando, el cual genera los archivos u-boot, u-boot.srec y u-boot.bin. El archivo u-boot.srec debe ser llevado al host que contiene EDK. Una vez se tiene el archivo srec del u-boot, este debe ser llevado a la memoria flash. Para ello se debe abrir el proyecto de referencia de EDK utilizado en la secci´ on A.9. Es importante que el sistema base sea implementado previamente mediante la opci´on Device Configuration > Download Bitstream mostrada en la Figura A.7.

Figura A.7: Funci´ on de EDK para descargar el bitstream del dise˜ no de referencia.

Universidad Industrial de Santander

104

Instalaci´on del Bootloader Ahora se debe descargar a la memoria Flash el bootloader mediante la opcion Device Configuration > Program Flash Memory como se muestra en la Figura A.8, donde se aprovecha el sistema base descargado en el FPGA para escribir sobre la memoria Flash el contenido del archivo u-boot.srec.

Figura A.8: Funci´ on de EDK para descargar un archivo a la memoria Flash. Adicionalmente EDK crea una aplicaci´ on que copia el bootloader desde la flash a la RAM y lo ejecuta desde all´ı. Los ajustes de los par´ ametros realizados se muestran en la Figura A.9 El paso anterior debe haber creado un proyecto en la pesta˜ na de software, el cual se debe editar para que se pueda desplegar la informaci´on por el puerto serie, para ello el archivo creado por ISE llamado bootloader.c se edita agregando las siguientes librer´ıas: bootloader.c 40 41 42

#include "xparameters.h" #include "xuartns550_l.h"

Al iniciar el main, es necesario configurar el puerto serie RS232 mediante las siguientes instrucciones: bootloader.c 95 96 97

XUartNs550_SetBaud(XPAR_RS232_UART_1_BASEADDR, XPAR_XUARTNS550_CLOCK_HZ, 9600); XUartNs550_mSetLineControlReg(XPAR_RS232_UART_1_BASEADDR, XUN_LCR_8_DATA_BITS);

Universidad Industrial de Santander

105

Instalaci´on del Bootloader

Figura A.9: Cuadro de di´alogo con la configuraci´ on para descargar u-boot a la Flash.

Si se desea un bootloader m´as ´ agil, es posible comentar la siguiente l´ınea que imprime algunos comentarios para la depuraci´on de la aplicaci´ on bootloader.c 48 49

#define VERBOSE

Para compilar las fuentes en C y descargar el sistema base, se puede ejecutar nuevamente la opci´on Device Configuration > Download Bitstream, con lo cual el sistema de desarrollo deber´ıa iniciar la aplicaci´on bootloader que permite el inicio del u-boot. Antes de continuar con la compilaci´on del kernel es aconsejable que el archivo de configuraci´ on generado en este proceso quede guardado en la memoria PROM de configuraci´ on del sistema de desarrollo para no tener que hacer uso de EDK cada vez que se R inicie la tarjeta. Para ello se pueden seguir las instrucciones del foro de Xilinx . Aunque las instrucciones

sugieren cambiar una de las opciones con las que se genera el archivo de configuraci´ on, esto no fue necesario durante la implementaci´ on. La ejecuci´ on de este procedimiento se muestra a continuaci´on y se inicia con la generaci´on del archivo para la memoria PROM. Para ello se inicia la aplicaci´on iMPACT y se selecciona la opci´on PROM File Formater como se muestra en la Figura A.10.

Universidad Industrial de Santander

106

Instalaci´on del Bootloader

Figura A.10: Aplicaci´ on iMPACT usada para generar el archivo de configuraci´ on de la PROM y programarla. Posteriormente se sigue el asistente para la creaci´on del archivo de configuraci´ on de la memoria PROM. El primer paso se muestra en la Figura A.11, donde se asigna el nombre del archivo y se indica el tipo de memoria que se va a programar.

Figura A.11: Di´ alogo donde se especifican los par´ ametros generales del archivo para la memoria PROM que se desea generar.

En el siguiente paso del asistente, se indica la forma en la que est´ a interconectada las memorias PROM. Universidad Industrial de Santander

107

Instalaci´on del Bootloader Para el sistema de desarrollo se debe dejar como lo muestra la Figura A.12. Se ha seleccionado en modo paralelo debido a que es m´as r´ apido que el modo serial y esto se ve reflejado en el tiempo de arranque del sistema.

Figura A.12: Di´ alogo donde se especifica si el archivo se va a cargar de forma serial o paralela.

La Figura A.13 nos muestra el di´alogo donde se especifican las referencias de las memorias instaladas en el sistema ML507. Y la Figura A.14 nos muestra un resumen de la informaci´on ingresada

Figura A.13: Di´ alogo donde se definen el tipo y la cantidad de memorias PROM disponibles.

Universidad Industrial de Santander

108

Instalaci´on del Bootloader

Figura A.14: Di´ alogo donde confirman los par´ ametros del archivo que se va a generar.

Al hacer click sobre Finish, aparece un cuadro de di´alogo donde se debe seleccionar el archivo de EDK implementation/download.bit. Se pueden ignorar algunos warnings que pueden aparecer indicando que solo se ha empleado una memoria PROM. Finalizada esta etapa, iMPACT muestra un diagrama con las memorias PROM y el FPGA que se va a configurar como se muestra en la Figura A.15.

Figura A.15: En la ventana se observan las memorias PROM que se van a usar y los archivos que se cargar´an en ellas.

Universidad Industrial de Santander

109

Instalaci´on del Bootloader All´ı se hace doble click sobre la opci´on Generate File..., lo cual iniciar´a el proceso de generaci´on del archivo .mcs; y si el proceso termina correctamente deber´ a enviar un mensaje como el de la Figura A.16.

Figura A.16: Aplicaci´ on iMPACT usada para generar el archivo de configuraci´ on de la PROM y programarla. Luego se abre la opci´ on de Boundary Scan en el cual aparecen los dispositivos que est´ an dentro de la cadena JTAG como se muestra en la Figura A.17.

Figura A.17: Aplicaci´ on iMPACT usada para generar el archivo de configuraci´ on de la PROM y programarla.

Universidad Industrial de Santander

110

Compilar el kernel Finalmente se asignan los archivos de configuraci´ on mcs y se configuran, asegurando que la opci´on Parallel Mode est´e activa como se muestra en la Figura A.18. Adicionalmente se debe tener en cuenta que los pines de configuraci´ on del FPGA deben estar en: M [2 : 0] = 100

Figura A.18: Aplicaci´ on iMPACT usada para generar el archivo de configuraci´ on de la PROM y programarla.

A.11

Compilar el kernel

Durante esta secci´on se compilar´ a el kernel, el cual quedar´a disponible en el servidor TFTP para que el bootloader pueda cargarlo. Al finalizar esta secci´on se podr´a iniciar Embedded Linux gracias al sistema de archivos generado por el ELDK. La Figura A.19 representa las etapas de este proceso: Para iniciar el proceso se debe obtener la fuente del kernel, de forma similar al u-boot. En esta ocasi´on se emple´ o la interfaz gr´ afica obteniendo el archivo linux-2.6-xlnx.git-HEAD.tar.gz. Posteriormente se descomprimi´o la fuente en el mismo directorio de trabajo de u-boot mediante el comando: Okinawa-00# tar xvfzp linux-2.6-xlnx.git-HEAD.tar.gz

Ahora se compil´o la fuente con las opciones por defecto para la virtex5 mediante los siguientes comandos:

Universidad Industrial de Santander

111

Compilar el kernel

Figura A.19: Elementos involucrados en la compilaci´on del kernel

Okinawa-00# ARCH=powerpc Okinawa-00# make ARCH=powerpc 44x/virtex5_defconfig Okinawa-00# make ARCH=powerpc uImage

Esto debe generar el archivo uImage, el cual es una imagen del kernel con un cabecero especial que emplea u-boot. El siguiente comando permite conocer el tipo de archivo que se gener´ o: Okinawa-00# file /opt/SoftDev/Xilinx/linux-2.6-xlnx.git/arch/powerpc/boot/uImage

El siguiente paso consiste en generar el archivo DTB modificando su fuente que es de extensi´ on DTS, el cual se compila mediante el compilador llamado DTC. El archivo DTB permite modificar algunas opciones del kernel sin necesidad de recompilarlo nuevamente, por ello se van a crear dos archivos DTB uno para iniciar Embedded Linux con el sistema de archivos del ELDK y otro para iniciar Debian con el sistema de archivos que generaremos en la secci´on A.12. Las modificaciones realizadas sobre el archivo DTS se muestran en los siguientes c´odigos para cada uno de los dos sistemas de archivos que se van a emplear, donde la diferencia est´ a en la asignaci´on de la variable nfsroot. Okinawa-00# mv \ /opt/SoftDev/Xilinx/linux-2.6-xlnx.git/arch/powerpc/boot/dts/virtex440-ml507.dts \ /opt/SoftDev/Xilinx/linux-2.6-xlnx.git/arch/powerpc/boot/dts/virtex440-ml507_debian.dts /opt/SoftDev/Xilinx/linux-2.6-xlnx.git/arch/powerpc/boot/dts/virtex440-ml507 debian.dts 1 2 3 4

bootargs = "console=ttyS0 ip=on root=/dev/nfs " \ "nfsroot=192.168.16.150:/opt/debian/ppc_4xx,tcp rw" local-mac-address = [ 00 0A 35 01 D7 4E ];

Okinawa-00# mv \ /opt/SoftDev/Xilinx/linux-2.6-xlnx.git/arch/powerpc/boot/dts/virtex440-ml507.dts \ /opt/SoftDev/Xilinx/linux-2.6-xlnx.git/arch/powerpc/boot/dts/virtex440-ml507_emlinux.dts

Universidad Industrial de Santander

112

Creaci´ on del sistema de archivos para debian /opt/SoftDev/Xilinx/linux-2.6-xlnx.git/arch/powerpc/boot/dts/virtex440-ml507 emlinux.dts 1 2 3 4

bootargs = "console=ttyS0 ip=on root=/dev/nfs " \ "nfsroot=192.168.16.150:/opt/ELDK/4.2/ppc_4xx,tcp rw" local-mac-address = [ 00 0A 35 01 D7 4E ];

ahora si compilar el archivo DTS para generar el archivo DTB Okinawa-00# /opt/SoftDev/Xilinx/linux-2.6-xlnx.git/arch/powerpc/boot/dtc \ -b 0 -V 17 -R 4 -S 0x3000 -I dts -O dtb -o ml507_debian.dtb \ -f arch/powerpc/boot/dts/virtex440-ml507_debian.dts

Okinawa-00# /opt/SoftDev/Xilinx/linux-2.6-xlnx.git/arch/powerpc/boot/dtc \ -b 0 -V 17 -R 4 -S 0x3000 -I dts -O dtb -o ml507_emlinux.dtb \ -f arch/powerpc/boot/dts/virtex440-ml507_emlinux.dts

copiar los archivos generados en la carpeta dentro del servidor TFTP, donde u-boot va a buscar sus archivos, es decir /compartido/tftpboot/Linuxboot/ Okinawa-00# cp /opt/SoftDev/Xilinx/linux-2.6-xlnx.git/arch/powerpc/boot/uImage \ /compartido/tftpboot/Linuxboot Okinawa-00# cp /opt/SoftDev/Xilinx/linux-2.6-xlnx.git/ml507_debian.dtb \ /compartido/tftpboot/Linuxboot Okinawa-00# cp /opt/SoftDev/Xilinx/linux-2.6-xlnx.git/ml507_emlinux.dtb \ /compartido/tftpboot/Linuxboot

Teniendo en cuenta el c´odigo de u-boot que inicia la tarjeta busca el archivo ml507.dtb, entonces se debe crear este archivo copi´andolo de ml507\_emlinux.dtb. Okinawa-00# cp /compartido/tftpboot/Linuxboot/ml507_emlinux.dtb \ /compartido/tftpboot/Linuxboot/ml507.dtb

Ahora el sistema est´ a listo para iniciar Embedded Linux, por lo tanto se puede energizar la tarjeta y se deber´ıa cargar u-boot y posteriormente el kernel y el sistema de archivos, donde al final se inicia el login de Linux.

A.12

Creaci´ on del sistema de archivos para debian

Durante esta secci´on se emplear´a Embedded Linux para crear y configurar el sistema de archivos de Debian. El proceso se ilustra en la Figura A.20. La creaci´on del sistema de archivos se hace en dos etapas: La primera descarga los paquetes y crea la base de la estructura de los directorios y se realiza mediante el siguiente comando, teniendo en cuenta que se ha planeado la implementaci´ on del sistema de archivos en el directorio /opt/debian/ppc_4xxFP/ Universidad Industrial de Santander

113

Creaci´ on del sistema de archivos para debian

Figura A.20: Elementos involucrados en la creaci´on del sistema de archivos para debian.

Okinawa-00# cp /compartido/tftpboot/Linuxboot/ml507_emlinux.dtb \ /compartido/tftpboot/Linuxboot/ml507.dtb

Ahora para ejecutar la segunda parte, debemos hacerlo desde la tarjeta, para lo cual debemos iniciar Embedded Linux y montar el sistema de archivos de debian en un directorio del de Embedded Linux as´ı: 192# 192# 192# 192#

mkdir mount mount mount

-p /root/debian -t proc proc /root/debian 192.168.16.150:/opt/debian/ppc_4xxFP /root/debian/ chroot /root/debian

Con el u ´ltimo comando se ha cambiado la raiz de nuestro sistema de archivos, por lo tanto podemos ejecutar la segunda etapa del debootstrap mediante el comando: 192# /debootstrap/debootstrap --second-stage

Ahora desde el frontend, podemos modificar los archivos de configuraci´ on del sistema de desarrollo. Principalmente los siguientes:

Universidad Industrial de Santander

114

Creaci´ on del sistema de archivos para debian /opt/debian/ppc 4xxFP/etc/hosts 1 2 3

127.0.0.1 192.168.16.172

localhost Okinawa-22.okinawa.net

Okinawa-22

4 5 6 7 8 9 10 11

# The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ff02::3 ip6-allhosts /opt/debian/ppc 4xxFP/etc/resolv.conf

1 2 3 4

#domain uis.edu.co search okinawa.net nameserver 192.168.16.150 /opt/debian/ppc 4xxFP/etc/network/interfaces

1 2 3

auto lo iface lo inet loopback

4 5 6 7 8 9 10 11 12 13 14

# Interfaz de red cableada auto eth0 iface eth0 inet static address 192.168.16.172 network 192.168.16.0 netmask 255.255.255.0 broadcast 192.168.16.255 gateway 192.168.16.1 dns-nameservers 192.168.19.2 #dns-search uis.edu.co /opt/debian/ppc 4xxFP/etc/hostname

1 2

Okinawa-22 /opt/debian/ppc 4xxFP/etc/fstab

1 2 3 4

proc tmpfs 192.168.16.150:/opt/debian/ppc_4xxFP/

/proc /tmp /

proc tmpfs nfs

defaults defaults defaults

0 0 0

0 0 0

Finalmente se ajusta el nombre del archivo DTB para que se inicie el sistema desde el sistema de archivos debian as´ı: Okinawa-00# mv /compartido/tftpboot/Linuxboot/ml507.dtb \ /compartido/tftpboot/Linuxboot/ml507_emlinux.dtb Okinawa-00# mv /compartido/tftpboot/Linuxboot/ml507_debian.dtb \ /compartido/tftpboot/Linuxboot/ml507.dtb

Universidad Industrial de Santander

115

Configuraci´ on del sistema operativo de la tarjeta Y finalmente se reinicia la tarjeta. Si el proceso se ha realizado correctamente, el sistema de desarrollo debe iniciar u-boot y posteriormente cargar el kernel y el sistema de archivos de debian para finalmente indicar en el terminal el login del sistema operativo.

A.13

Configuraci´ on del sistema operativo de la tarjeta

En esta secci´on se busca hacer la configuraci´ on del sistema operativo para que pueda ser parte del cluster. Inicialmente debemos configurar el repositorio del sistema operativo en el archivo /etc/apt/sources.list deb 1 http://ftp.debian.org/debian lenny main contrib non-free

Para indicar a la tarjeta ML507 cual es el servidor DNS al cual debe acceder, se debe editar el archivo /etc/resolv.conf de la siguiente forma #domain 1 uis.edu.co search 2 okinawa.net nameserver 3 192.168.16.150

Posteriormente consultamos la lista de paquetes disponibles y la actualizamos mediante el comando 192# apt-get update

Podemos instalar algunas herramientas que pueden ser de utilidad como 192# apt-get install ssh vim host

Debido a que el sistema de desarrollo no tiene un reloj que le permita actualizar la hora, puede ser necesario la configuraci´ on de un cliente Network Time Protocol(NTP) que le permita sincronizar la hora. Para ello instalamos el paquete ntp 192# apt-get install ntp

y ahora se inicia el servicio 192# /etc/init.d/ntp start

El no tener la hora del sistema ajustada, puede traer advertencias y errores que pueden ser dificiles de rastrear o incomodos. Por ejemplo que el sistema solicite el cambio de la clave de root cada vez que se accede a ´el.

Universidad Industrial de Santander

116

Configuraci´ on del directorio compartido en el cluster

A.14

Configuraci´ on del directorio compartido en el cluster

En este momento el frontend comparte su directorio /compartido/comun al nodo trabajador, el cual lo monta en la misma ubicaci´ on. Dentro de este directorio se encuentra el directorio home que contiene las carpetas de los usuarios del cluster. Es necesario que la tarjeta pueda acceder al contenido del directorio y que pueda crear los mismos usuarios configurados en el frontend y en el nodo trabajador. Se inicia entonces modificando el archivo /etc/fstab de la tarjeta para configurar el modo en el que el sistema monta la carpeta compartida. 1 2 3 4 5

/etc/fstab # proc /proc proc tmpfs /tmp tmpfs 192.168.16.150:/opt/debian/ppc_4xxFP/ / nfs 192.168.16,150:/compartido/comun/ /compartido/comun/

defaults 0 0 defaults 0 0 defaults 0 0 nfs defaults 0 0

Probablemente sea necesario instalar el cliente nfs llamado nfs-common, para lo cual se ejecuta Okinawa-22# apt-get nfs-common

Ahora montamos el directorio configurado en el archivo fstab mediante el comando Okinawa-22# mount -a

y podemos verificar que si lo hizo bien mediante el comando Okinawa-22# mount

Ahora, antes de crear los nuevos usuarios, debemos configurar el archivo que contiene la configuraci´ on de los nuevos usuarios de la misma forma que se hizo previamente en el cluster. Para ello modificamos el archivo /etc/adduser.conf. All´ı modificaremos las siguientes entradas: /etc/fstab 1 2

DHOME=/compartido/comun/home USERGROUPS=no

Ahora creamos los usuarios mediante el comando adduser, pero previamente debemos conocer el uid del usuario que vamos a crear. Para ello podemos observar el contenido del archivo /etc/passwd mediante el siguiente comando. Okinawa-22# cat /etc/passwd | grep sergio

dentro de la lista de datos que se imprime, el tercero es el userid. Para este caso es 1002. Ahora si ejecutamos adduser.

Universidad Industrial de Santander

117

Configuraci´ on de otros servicios Okinawa-22# adduser sergio --uid 1002

Esto crear´ a el usuario sergio para el sistema de desarrollo ML507, pero el sistema no modificar´a los archivos ya existentes.

A.15

Configuraci´ on de otros servicios

A.15.1

Servidor DNS

Es necesario tambi´en a˜ nadir este nodo al servidor DNS, para lo cual se modificar´an sus archivos de configuraci´ on. /etc/bind/db.16.168.192 1

$TTL

24h

2 3 4 5 6 7 8 9 10 11

16.168.192.in-addr.arpa. IN SOA Okinawa-00.okinawa.net 2008042300 ;numero serial 3h ; tiempo de refresco 30m ; tiempo de reintegro 7d ; tiempo de "expire" 3h ; negative caching ttl ) ; NameServers 16.168.192.in-addr.arpa. IN NS 192.168.16.150.

root.okinawa.net

12 13 14 15 16 17 18

; Hosts 150.16.168.192.in-addr.arpa. 151.16.168.192.in-addr.arpa. 152.16.168.192.in-addr.arpa. 171.16.168.192.in-addr.arpa. 172.16.168.192.in-addr.arpa.

IN IN IN IN IN

PTR PTR PTR PTR PTR

Okinawa-00.okinawa.net. Okinawa-01.okinawa.net. Okinawa-02.okinawa.net. Okinawa-21.okinawa.net. Okinawa-22.okinawa.net.

/etc/bind/db.okinawa.net 1 2 3 4 5 6 7 8

$TTL 24h okinawa.net. IN SOA Okinawa-00.okinawa.net 2008042300 ; numero serial 3h ; tiempo de refresco 30m ; tiempo de reintegro 7d ; tiempo de expire 3h ; negative caching ttl )

root.okinawa.net (

9 10 11

; NameServers okinawa.net. IN NS

192.168.16.150.

12 13 14 15 16 17 18

; Hosts Okinawa-00.okinawa.net. Okinawa-01.okinawa.net. Okinawa-02.okinawa.net. Okinawa-21.okinawa.net. Okinawa-22.okinawa.net.

IN IN IN IN IN

A A A A A

192.168.16.150 192.168.16.151 192.168.16.152 192.168.16.171 192.168.16.172

Universidad Industrial de Santander

118

(

Instalaci´on de PVM

A.16

Instalaci´ on de PVM

La instalaci´ on de PVM requiere que este sea compilado para varias arquitecturas y se iniciar´a con la del frontend, es decir la x86. Para ello descargamos la fuente desde el sitio http://www.netlib.org/pvm3/. El archivo fuente se ha ubicado en el directorio /compartido/comun y se ha descomprimido en el directorio /compartido/comun/pvm3 mediante los comandos Okinawa-22# cd /compartido/comun/ Okinawa-22# tar xvfz pvm3.4.6.tar.gz

Debido a que esta fuente ser´a accedida por varios usuarios y equipos, se pueden modificar sus propiedades. Para este caso se dar´ an todos los permisos mediante el siguiente comando Okinawa-22# chmod 777 -R /compartido/comun/pvm3

luego se procedi´ o a crear las variables de entorno que requeridas por la instalaci´on editando el archivo /etc/profile. Este script se ejecuta cada vez que se inicia sesi´on, por lo tanto estas variables estar´an disponibles en futuras ocaciones.

Universidad Industrial de Santander

119

Instalaci´on de PVM 1 2

/etc/profile # /etc/profile: system-wide .profile file for the Bourne shell (sh(1)) # and Bourne compatible shells (bash(1), ksh(1), ash(1), ...).

3 4 5 6 7 8

if [ "‘id -u‘" -eq 0 ]; then PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" else PATH="/usr/local/bin:/usr/bin:/bin:/usr/games" fi

9 10 11 12 13 14 15 16 17 18 19 20

if [ "$PS1" ]; then if [ "$BASH" ]; then PS1=’\u@\h:\w\$ ’ else if [ "‘id -u‘" -eq 0 ]; then PS1=’# ’ else PS1=’$ ’ fi fi fi

21 22

export PATH

23 24

umask 022

25 26

# contenido anadido para la instalacion de PVM

27 28 29 30 31

PVM_ROOT=/compartido/comun/pvm3 PVM_DPATH=$PVM_ROOT/lib/pvmd PATH=$PATH:$PVM_ROOT/lib export PVM_ROOT PVM_DPATH PATH

Finalmente reiniciamos la consola en la que estamos trabajando, vamos al directorio raiz de pvm y ejecutamos make Okinawa-22# cd $PVM_ROOT Okinawa-22# make

Con se han creado las las librer´ıas de PVM. Ahora debemos copiarlas a un sitio donde los compiladores las encuentren en cada uno de los nodos donde se piense realizar la compilaci´on. Para ello se cre´o el siguiente script. 1 2 3 4 5

/etc/profile for x in ‘cat machines‘ do ssh $x cp /compartido/comun/pvm3/lib/LINUX/*.a /usr/lib/ ssh $x cp /compartido/comun/pvm3/include/*.h /usr/include/ done

Universidad Industrial de Santander

120

Instalaci´on de PVM Este script, asume la existencia de un archivo machines que lista en cada l´ınea los nodos donde se desean copiar las librer´ıas. Ahora se proceder´a a ejecutar una prueba desde uno de los usuarios creados. Para cambiar de usuario se puede ejecutar el siguiente comando: Okinawa-22# su -l william

El primer paso para emplear PVM es configurarlo para que reconozca los nodos del sistema. Para ello abrimos la consola de la siguiente forma: william@Okinawa-22# pvm pvm> conf pvm> add Okinawa-00 pvm> add Okinawa-01 pvm> conf pvm> quit

Ahora creamos el archivo .rhost que indicar´a en la carpeta del usuario, a cuales nodos es posible acceder. 1 2

/compartido/comun/home/william/.rhost Okinawa-00 william Okinawa-01 william

Creamos un directorio donde haremos una prueba de hola mundo que imprime el nombre de cada uno de los nodos y la hora del sistema. En ella pondremos los archivos fuente helloPVM_master.c y helloPVM_slave.c. william@Okinawa-22# mkdir pruebaPVM william@Okinawa-22# cd pruebaPVM

Universidad Industrial de Santander

121

Instalaci´on de PVM 1 2 3

/compartido/comun/home/william/pruebaPVM/helloPVM master.c /* master program for the simple communication program */ /* which starts slaves just to get their names and the */ /* local time back */

4 5 6

#include #include

7 8 9

main() {

10

struct pvmhostinfo *hostp; int result, check, i, nhost, narch, stid; char buf[64]; pvm_setopt(PvmRoute, PvmRouteDirect); /* channel for communication */

11 12 13 14 15

gethostname(buf, 20); /* get name of master */ printf("The master process runs on %s \n", buf);

16 17 18

/* get and display configuration of the parallel machine */ pvm_config( &nhost, &narch, &hostp ); /* get configuration */ printf("I found the following hosts in your virtual machine\n"); for (i = 0; i < nhost; i++) { printf("\t%s\n", hostp[i].hi_name); }

19 20 21 22 23 24 25 26

for (i=0; in o m b r e p e r i f e r i c o , PERIFERICO NAME ) ; tamano = el PERIFERICO−>n u m e r o d e r e g i s t r o s ; el PERIFERICO−>i n t e r c a m b i o d e d a t o s = k m a l l o c ( tamano ∗ s i z e o f ( u n s i g n e d i n t ) ,GFP KERNEL ) ; f o r ( k =0;ki n t e r c a m b i o d e d a t o s [ k ] = 0 ; b an d e ra =1; #i f d e f depura

Universidad Industrial de Santander

197

Archivo periferico.c p r i n t k (PRINTK LEVEL ”PERIFERICO depura : PERIFERICO open : El m e n s a j e \ guardado en el PERIFERICO−>n o m b r e p e r i f e r i c o e s : %s \n” , \ el PERIFERICO−>n o m b r e p e r i f e r i c o ) ; #e n d i f } else { #i f d e f depura p r i n t k (PRINTK LEVEL ”PERIFERICO depura : PERIFERICO open : Ya e s t a b a \ i n i c i a l i z a d o : ) \ n” ) ; #e n d i f } /∗ R e s e r v a d e l p u e r t o . . . e s t o s e r e f l e j a i n m e d i a t a m e n t e en / p r o c / i o p o r t s ∗/ i f ( ! r e q u e s t r e g i o n (PERIFERICO BASEADDRESS, 4 , PERIFERICO NAME ) ) p r i n t k (PRINTK LEVEL ”PERIFERICO open : No s e pudo h a c e r e x i t o s a m e n t e e l \ r e q u e s t d e l p u e r t o PERIFERICO : ( \ n” ) ; /∗ Se mapea l a d i r e c c i ´ o n f ´ı s i c a d e l p u e r t o en l a p o r c i ´ o n de memoria t i p o ∗ I /O. El tama˜ n o de l a r e s e r v a e s de 64 b y t e s PERIFERICO iomem pointer=i ore map (PERIFERICO BASEADDRESS, 0 x00000040 ) ;

∗ ∗/

return 0; }

/∗ Funci´ o n PERIFERICO release : E s ta f u n c i ´ o n l i b e r a l o que l a f u n c i ´ on ∗ PERIFERICO open ha r e s e r v a d o . i n t PERIFERICO release ( s t r u c t i n o d e ∗ i n o d e 1 , s t r u c t f i l e ∗ p u n t e r o f i l e ) { s t r u c t PERIFERICO dev ∗el PERIFERICO = p u n t e r o f i l e −>p r i v a t e d a t a ; #i f d e f depura p r i n t k (PRINTK LEVEL ”PERIFERICO depura : PERIFERICO release : Estoy \ ejecutando la funci´ o n PERIFERICO release \n” ) ; #e n d i f /∗ l i b e r a c i o n de l a memoria I /O s o b r e l a que s e mapeo e l p u e r t o iounmap ( PERIFERICO iomem pointer ) ;

∗ ∗/

∗/

/∗ L i b e r a c i ´ on del puerto reservado r e l e a s e r e g i o n (PERIFERICO BASEADDRESS , 4 ) ;

∗/

/∗ L i b e r a e l s e m ´ aforo up(&el PERIFERICO−>sem ) ; return 0;

∗/

}

/∗ En e s t a e s t r u c t u r a s e d e f i n e n l a s o p e r a c i o n e s que s e van i m p l e m e n t a r en e l ∗ ∗ driver ∗/ s t r u c t f i l e o p e r a t i o n s PERIFERICO fops = { . owner = THIS MODULE, . l l s e e k = PERIFERICO llseek , . read = PERIFERICO read , . write = PERIFERICO write , . ioctl = PERIFERICO ioctl , . open = PERIFERICO open , . r e l e a s e = PERIFERICO release };

/∗ E s ta e s t r u c t u r a r e p r e s e n t a l o s d i s p o s i t i v o s PERIFERICO i m p l e m e n t a d o s . Para ∗ ∗ e s t e c a s o f u e s o l o uno . La memoria que emplea e s t e d i s p o s i t i v o e s ∗

Universidad Industrial de Santander

198

Archivo periferico.c ∗ r e s e r v a d a en PERIFERICO init s t r u c t PERIFERICO dev ∗my PERIFERICO dev ;

∗/

/∗ Funci´ o n PERIFERICO init : E s ta f u n c i ´ o n e s l l a m a d a cuando s e h a c e insmod y ∗ r e s e r v a l o s nu ´ meros major y minor y r e g i s t r a r e l d i s p o s i t i v o . s t a t i c i n t PERIFERICO init ( v o i d ) { /∗ V a r i a b l e usada p a r a r e c i b i r e l c ´ o d i g o de e r r o r de l a f u n c i ´ on cdev init int err ; #i f d e f depura /∗ V a r i a b l e d e l f o r que r e p i t e e l m e n s a j e de s a l u d o . int k ; #e n d i f /∗ V a r i a b l e que r e c i b e e l v a l o r de l a f u n c i ´ on alloc chrdev region int result ;

∗ ∗/ ∗/ ∗/ ∗/

/∗ R e s e r v a d i n ´ a m i c a de l o s n u ´ meros d e l d r i v e r . ∗/ r e s u l t = a l l o c c h r d e v r e g i o n (&mydev , f i r s t m i n o r , count , nombre ) ; #i f d e f depura i f ( r e s u l t ==0) p r i n t k (PRINTK LEVEL ”PERIFERICO depura : PERIFERICO init : Los n u ´ meros \ r e s e r v a d o s p a r a e l d r i v e r f u e r o n : \ n Major : %d\n Minor : %d\n” , MAJOR( mydev ) , \ MINOR( mydev ) ) ; else p r i n t k (PRINTK LEVEL ”PERIFERICO depura : PERIFERICO init : Hubo un e r r o r \ y l o s nu ´ meros no s e r e s e r v a r o n . El e r r o r f u e : %d\n ” , r e s u l t ) ; #e n d i f /∗ R e s e r v a memoria en e l e s p a c i o d e l k e r n e l p a r a PERIFERICO dev , e s ∗ d e c i r , que i n i c i a l i z a e l p u n t e r o my PERIFERICO dev my PERIFERICO dev = k m a l l o c ( s i z e o f ( s t r u c t PERIFERICO dev ) , GFP KERNEL ) ; #i f d e f depura i f ( my PERIFERICO dev==NULL) p r i n t k (PRINTK LEVEL ”PERIFERICO depura : PERIFERICO init : P a i l a s , t o c ´ o r e i n i c i a r , no pude r e s e r v a r memoria \n” ) ; else p r i n t k (PRINTK LEVEL ”PERIFERICO depura : PERIFERICO init : C o n g r a t u l a t i o n s , s o s un duro , r e s e r v a s t e memoria p a r a my PERIFERICO dev , no t o c ´ o r e i n i c i a r , se r e s e r v a r o n %d B y t e s \n ” , ( i n t ) s i z e o f ( s t r u c t PERIFERICO dev ) ) ; #e n d i f /∗ I n i c i a l i z a c i ´ o n del semaforo del p e r i f e r i c o init MUTEX(&my PERIFERICO dev−>sem ) ; /∗ M´ e todo p a r a r e s e r v a r l a memoria p a r a e l cdev . E s t e m´ e todo p e r m i t e que ∗ e l cdev s e a p a r t e de n u e s t r a e s t r u c t u r a p e s o n a l i z a d a my PERIFERICO c d e v i n i t (&my PERIFERICO dev−>cdev ,&PERIFERICO fops ) ; /∗ R e g i s t r o d e l d r i v e r en e l k e r n e l . E s t e m´ e todo no s e debe l l a m a r h a s t a ∗ no t e n e r t o d o l i s t o p a r a a t e n d e r c u a l q u i e r l l a m a d o e r r = c d e v a d d (&my PERIFERICO dev−>cdev , mydev , 1 ) ; /∗ I n i c i a l i z a a l g u n o s campos de l a e s t r u c t u r a my PERIFERICO dev my PERIFERICO dev−>cdev . owner = THIS MODULE ; my PERIFERICO dev−>cdev . op s = &PERIFERICO fops ;

∗ ∗/

\ \ \ ∗/ ∗ ∗/ ∗ ∗/ ∗/

#i f d e f depura i f ( e r r comm ) ; #e n d i f /∗ Se pone l a b an d e ra a c e r o p a r a i n d i c a r que e l ∗ inicializado b an d e ra =0;

d r i v e r nunca ha s i d o

Universidad Industrial de Santander

∗ ∗/

199

Archivo montar.sh return

result ;

}

/∗ Funci´ o n PERIFERICO exit : ∗ E s ta f u n c i ´ o n e s i n v o c a d a cuando s e e j e c u t a rmmod y debe ∗ ∗ l i b e r a r y d e s h a c e r l o que l a f u n c i ´ o n PERIFERICO init ha r e s e r v a d o ∗/ s t a t i c v o i d PERIFERICO exit ( v o i d ) { /∗ D e s r e g i s t r a l o s n u ´ meros major y minor que l e f u e r o n a s i g n a d o s de forma ∗ ∗ din´ a m i c a ∗/ u n r e g i s t e r c h r d e v r e g i o n ( mydev , c o u n t ) ; /∗ Remueve e l d i s p o s i t i v o d e l k e r n e l ∗/ c d e v d e l (&my PERIFERICO dev−>cdev ) ; /∗ L i b e r a e l e s p a c i o de memoria de l o s r e g i s t r o s d e l PERIFERICO ∗/ i f (&my PERIFERICO dev−>i n t e r c a m b i o d e d a t o s != NULL && b an d e ra==1) k f r e e ( my PERIFERICO dev−>i n t e r c a m b i o d e d a t o s ) ; /∗ L i b e r a l a memoria r e s e r v a d a p a r a e l s t r u c t PERIFERICO dev ∗/ k f r e e ( my PERIFERICO dev ) ; #i f d e f depura /∗ Mensaje de d e s p e d i d a ∗/ p r i n t k (PRINTK LEVEL ” PERIFERICO hello : PERIFERICO exit : Bye bye , Mundo\n” ) ; /∗ Prueba que p e r m i t e s a b e r c u a l p r o c e s o l o i n v o c a a uno ∗/ p r i n t k (PRINTK LEVEL ”PERIFERICO depura : PERIFERICO exit : He s i d o i n v o c a d o p o r : [ % i ] %s \n” , c u r r e n t −>pid , c u r r e n t #e n d i f } /∗ I n d i c a c u a l e s f u n c i o n e s s on l a s que s e deben e j e c u t a r ∗/ m o d u l e i n i t ( PERIFERICO init ) ; m o d u l e e x i t ( PERIFERICO exit ) ;

al

e j e c u t a r insmod y ∗

∗ rmmod .

/∗ I n f o r m a c i ´ o n a d i c i o n a l s o b r e e l m´ o dulo . ∗/ MODULE AUTHOR( ” W i l l i a m Salamanca y S e r g i o Abreo . ” ) ; MODULE ALIAS( ” PERIFERICO template ” ) ; MODULE DESCRIPTION( ” D r i v e r que maneja un PERIFERICO y que s i r v e como p l a n t i l l a \ p a r a c o n t r o l a d o r e s de o t r o t i p o de p e r i f ´ ericos .”);

Cuadro de C´ odigo H.2: Nueva librer´ıa xil io: Rutinas para escribir y leer datos de 32 bits en la memoria principal desde el espacio del usuario.

H.3

Archivo montar.sh

#! / b i n / sh # s e t −x module=” p e r i f e r i c o ” d e v i c e=” Periferico PERIFERICO ” mode=” 666 ” rm −f / dev / $ { d e v i c e } # i n v o k e insmod w i t h a l l arguments we g o t # and u s e a pathname , a s newer m o d u t i l s don ’ t l o o k i n / s b i n / insmod . / $module . ko $ ∗ | | e x i t 1 # remove s t a l e n o d e s rm −f / dev / $ { d e v i c e } # major=$ ( awk ”\ $2==\”$module \” major=$ ( c a t / p r o c / d e v i c e s | awk mknod / dev / $ { d e v i c e } c $major 0 #mknod / dev / $ { d e v i c e }1 c $major #mknod / dev / $ { d e v i c e }2 c $major #mknod / dev / $ { d e v i c e }3 c $major

. by d e f a u l t

{ p r i n t \ $1 }” / p r o c / d e v i c e s ) ’ { i f ( $2==” Periferico PERIFERICO ” ) p r i n t $1 ;

else

print

p a i l a s } ’ | g r e p −v p a i l a s

1 2 3

# g i v e a p p r o p r i a t e group / p e r m i s s i o n s , and change t h e group . # Not a l l d i s t r i b u t i o n s have s t a f f , some have ” w h e e l ” i n s t e a d . #group=” s t a f f ” #g r e p −q ’ ˆ s t a f f : ’ / e t c / group | | group=”w h e e l ” #c h g r p $group / dev / $ { d e v i c e } [ 0 − 3 ] chmod $mode / dev / $ { d e v i c e }

Cuadro de C´ odigo H.3: Nueva librer´ıa xil io: Rutinas para escribir y leer datos de 32 bits en la memoria principal desde el espacio del usuario.

Universidad Industrial de Santander

200

´ndice Ape

´ ´ de la plantilla). Modulo del kernel (Adaptacion El presente Anexo muestra el c´odigo fuente del m´odulo que se a˜ nadi´o al kernel para realizar las escrituras y lecturas de los registros del prerif´erico XPS HWICAP.

I.1

Archivo XPS HWICAP.h

/∗ L i b r e r´ı a con l a s #i f n d e f #d e f i n e

definiciones

del

perif´ e r i c o ∗/

XPS HWICAP H XPS HWICAP H

#i n c l u d e /∗ E s t r u c t u r a d e l d i s p o s i t i v o ∗/ s t r u c t XPS HWICAP dev { unsigned i n t baseaddress ; unsigned i n t numero de registros ; unsigned i n t ∗ intercambio de datos ; char n o m b r e p e r i f e r i c o [ 2 5 ] ; s t r u c t semaphore sem ; s t r u c t cdev cdev ; }; /∗ Datos d e l p e r i f ´ e r i c o LCD //#d e f i n e XPS HWICAP NUMERO REGISTROS 0 x46 #d e f i n e XPS HWICAP NUMERO REGISTROS 0 x47 #d e f i n e XPS HWICAP BASEADDRESS 0 x81480000 #d e f i n e XPS HWICAP NAME ” Periferico XPS HWICAP ”

∗/

/∗ Comandos d e l i o c t l ∗/ #d e f i n e XPS HWICAP MAGIC ’W’ #d e f i n e COMANDO 0 IO (XPS HWICAP MAGIC, 1 ) #d e f i n e COMANDO 1 IO (XPS HWICAP MAGIC, 2 ) #e n d i f

Cuadro de C´ odigo I.1: Nueva librer´ıa xil io: Rutinas para escribir y leer datos de 32 bits en la memoria principal desde el espacio del usuario.

I.2

Archivo XPS HWICAP.c

/∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗ D r i v e r p a r a un XPS HWICAP . E s t e a r c h i v o puede s e r v i r como p l a n t i l l a ∗ ∗ p a r a o t r o s d i s p o s i t i v o s a l o s que s e l e s q u i e r a i m p l e m e n t a r un d r i v e r . ∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗/

Universidad Industrial de Santander

201

I

Archivo XPS HWICAP.c

/∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗ L i b r e r´ı a s g e n e r a l e s ∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗/ /∗ S o p o r t e p a r a e s t a b l e c e r l a s f u n c i o n e s de i n i c i a l i z a c i ´ on y finalizaci´ on ∗ m e d i a n t e l o s macros m o d u l e i n i t m o d u l e e x i t #i n c l u d e

∗ ∗/

/∗ O b l i g a t o r i o p a r a c u a l q u i e r m´ o dulo #i n c l u d e

∗/

/∗ D e f i n i c i o n e s g e n e r a l e s y l a mayor´ıa de l o s macros que i n t e r a c t u a n con e l ∗ kernel #i n c l u d e

∗ ∗/

/∗ F u n c i o n e s r e l a c i o n a d a s con l a e s c r i t u r a d r i v e r s , a c ´ a estan l a s ∗ p a r a r e g i s t r a r l o s numeros de d i s p o s i t i v o s y l o s cdev #i n c l u d e

∗ ∗/

/∗ P e r m i t e i n s t a n c i a r y m a n i p u l a r l o s cdev #i n c l u d e

funciones

∗/

/∗ ?? ∗/ #i n c l u d e /∗ S o p o r t a c o p y t o u s e r y c o p y f r o m u s e r #i n c l u d e

∗/

/∗ S o p o r t e p a r a manejar l o s p u e r t o s #i n c l u d e

∗/

/∗ S o p o r t e p a r a l a s #i n c l u d e

∗/

f u n c i o n e s i n x outx

/∗ S o p o r t e p a r a l a s b a r r e r a s #i n c l u d e

∗/

/∗ S o p o r t e p a r a m s l e e p #i n c l u d e

∗/

/∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗ L i b r e r´ı a s p e r s o n a l i z a d a s ∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗/ /∗ D e f i n i c i o n e s p a r a e l XPS HWICAP #i n c l u d e ”XPS HWICAP . h”

∗/

/∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗ L i b r e r´ı a s p e r s o n a l i z a d a s ∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗/ /∗ Cantidad de c a r a c t e r e s que s e c o p i a n cada v e z que s e l l a m a l a s f u n c i o n e s ∗ ∗ XPS HWICAP write o XPS HWICAP read . ∗/ #d e f i n e XPS HWICAP MEMSPACE SIZE XPS HWICAP NUMERO REGISTROS∗4 // n r e g ∗ 4 b y t e s /∗ H a b i l i t a e l cambio de e n d i a n n e s s en l a #d e f i n e c a m b i o e n d i a n n e s s

escritura y lectura

∗/

/∗ H a b i l i t a l a i m p r e s i ´ o n de m e n s a j e s de d e p u r a c i ´ on mediante p r i n t k //#d e f i n e depura

∗/

/∗ N i v e l d e l p r i n t k p o r d e f e c t o #d e f i n e PRINTK LEVEL KERN INFO

∗/

/∗ Puntero d e v u e l t o p o r i ore map s t a t i c v o i d ∗ XPS HWICAP iomem pointer ;

∗/

/∗ L i c e n c i a b a j o l a c u a l s e d e s a r r o l l ´ o MODULE LICENSE( ” Dual BSD/GPL” ) ;

el

driver

∗/

/∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗ Par´ a m e t r o s a l momento de c a r g a r e l m´ o dulo ∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗/

Universidad Industrial de Santander

202

Archivo XPS HWICAP.c static static module module

c h a r ∗whom = int howmany = param (whom , param ( howmany ,

”Mundo” ; 1; charp , S IRUGO ) ; int , S IRUGO ) ;

/∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗ Par´ ametros d e l d r i v e r ∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗/ /∗ Nombre que a p a r e c e r ´ a en e l / p r o c / d e v i c e s s t a t i c c h a r ∗ nombre = XPS HWICAP NAME ; /∗ El p r i m e r minor number e s c e r o s t a t i c unsigned i n t f i r s t m i n o r = 0; /∗ I n d i c a c u a n t o s d e v i c e s XPS HWICAP e x i s t e n , p a r a r e s e r v a r ∗ minor numbers . s t a t i c unsigned i n t count = 1 ;

∗/ ∗/ i g u a l c a n t i d a d de ∗ ∗/

/∗ Dato de t i p o d e v t que s e u s a en l a s f u n c i o n e s XPS HWICAP init y ∗ XPS HWICAP exit y agrupa l o s major y minor numbers a s i g n a d o s a l ∗ d i s p o s i t i v o XPS HWICAP s t a t i c d e v t mydev ; /∗ I n d i c a s i e l d r i v e r ha s i d o i n i c i a l i z a d o , en o t r a s p a l a b r a s , s i a l g u n a v e z ∗ s e ha e j e c u t a d o l a f u n c i ´ o n open . s t a t i c c h a r b an d e ra ;

∗ ∗ ∗/

/∗ Funci´ o n c h a n g e e n d i a n n e s s : T i e n e como o b j e t i v o c amb i ar e l e n d i a n n e s s a un ∗ d a t o de 32 b i t s t i p o u32 . u32 c h a n g e e n d i a n n e s s ( u32 d a t o ) { u32 v a l r e t =0; ∗ ( ( ( u8 ∗ ) &v a l r e t )+3) = ∗ ( ( ( u8 ∗)& d a t o ) + 0 ) ; ∗ ( ( ( u8 ∗ ) &v a l r e t )+2) = ∗ ( ( ( u8 ∗)& d a t o ) + 1 ) ; ∗ ( ( ( u8 ∗ ) &v a l r e t )+1) = ∗ ( ( ( u8 ∗)& d a t o ) + 2 ) ; ∗ ( ( ( u8 ∗ ) &v a l r e t )+0) = ∗ ( ( ( u8 ∗)& d a t o ) + 3 ) ; return valret ; }

∗ ∗/

∗ ∗/

/∗ Funci´ o n XPS HWICAP llseek : ∗/ l o f f t XPS HWICAP llseek ( s t r u c t f i l e ∗ p u n t e r o f i l e , l o f f t o f f , i n t whence ) { /∗ V a r i a b l e que almacena e l v a l o r a d e v o l v e r ( nuevo p u n t e r o ) ∗/ l o f f t retval ; /∗ Conserva un p u n t e r o a l a e s t r u c t u r a de t i p o XPS HWICAP dev ∗/ s t r u c t XPS HWICAP dev ∗el XPS HWICAP = p u n t e r o f i l e −>p r i v a t e d a t a ; #i f d e f depura p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP llseek : Estoy e j e c u t a n d o #e n d i f s w i t c h ( whence ) { c a s e 0 : /∗ SEEK SET ∗/ retval = off ; #i f d e f depura p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP llseek : Estoy e j e c u t a n d o #e n d i f break ; c a s e 1 : /∗ SEEK CUR ∗/ r e t v a l = p u n t e r o f i l e −>f p o s + o f f ; #i f d e f depura p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP llseek : Estoy e j e c u t a n d o #e n d i f break ; c a s e 2 : /∗ SEEK END ∗/ r e t v a l = el XPS HWICAP−>n u m e r o d e r e g i s t r o s ∗4 + o f f ; #i f d e f depura p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP llseek : Estoy e j e c u t a n d o #e n d i f break ; d e f a u l t : /∗ c a n ´ t happen r e t u r n −EINVAL ; }

la funci´ o n XPS HWICAP llseek \

SEEK SET\n” ) ;

SEEK CUR\n” ) ;

SEEK END\n” ) ;

∗/

Universidad Industrial de Santander

203

Archivo XPS HWICAP.c

i f ( r e t v a l < 0 ) r e t u r n −EINVAL ; p u n t e r o f i l e −>f p o s = r e t v a l ; #i f d e f depura p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP llseek : S a l´ı b i e n de l a f u n c i ´ o n XPS HWICAP llseek \n” ) ; p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP llseek : El v a l o r d e v u e l t o e s : %d\n” , ( i n t ) r e t v a l ) ; #e n d i f return retval ; }

/∗ Funci´ o n XPS HWICAP read : El k e r n e l s o l i c i t a l e e r ” tamano ” b y t e s a l d r i v e r . ∗ ∗ El d r i v e r r e s p o n d e con l a c a n t i d a d de b y t e s l e i d o s o c e r o s i s e l l e g ´ o al ∗ ∗ f i n a l del archivo . ∗/ s s i z e t XPS HWICAP read ( s t r u c t f i l e ∗ p u n t e r o f i l e , c h a r user ∗ puntero usuario , \ s i z e t tamano , l o f f t ∗ p u n t e r o o f f s e t ) { /∗ V a r i a b l e que almacena e l v a l o r a d e v o l v e r ( B y t e s l e i d o s ) ∗/ ssize t retval ; /∗ Conserva un p u n t e r o a l a e s t r u c t u r a de t i p o XPS HWICAP dev ∗/ s t r u c t XPS HWICAP dev ∗el XPS HWICAP = p u n t e r o f i l e −>p r i v a t e d a t a ; /∗ Tama˜ no d e l b u f f e r c a l c l u a d o s e g u ´ n memoria de c a r a c t e r e s ∗/ i n t c a n t i d a d d e r e g i s t r o s = el XPS HWICAP−>n u m e r o d e r e g i s t r o s ; unsigned i n t l e i d o ; /∗ V a r i a b l e p a r a e l int k ;

f o r ∗/

#i f d e f depura p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP read : Estoy e j e c u t a n d o l a f u n c i ´ o n XPS HWICAP read\n” ) ; p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP read : Tamano = %d\n” , tamano ) ; p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP read : El c o n t e n i d o de p u n t e r o o f f s e t e s : %l u \n” , ( l o n g u n s i #e n d i f /∗ Dejamos en tamano e l menor e n t r e tamano y XPS HWICAP MEMSPACE SIZE ∗ ∗ p o r q u e e l d r i v e r no p i e n s a l e e r mas que e s o ( ´ e l es perezoso ) ∗/ i f ( tamano>XPS HWICAP MEMSPACE SIZE) tamano = XPS HWICAP MEMSPACE SIZE ; /∗ V e r i f i c a m o s s i s e puede s o b r e p a s a r e l tama˜ n o m´ aximo d e l b u f f e r y ∗ ∗ l i m i t a m o s l a c a n t i d a d de d a t o s l e i d o s en c a s o de s o b r e p a s a r n o s ∗/ i f ( ( ∗ p u n t e r o o f f s e t + tamano)>= c a n t i d a d d e r e g i s t r o s ∗ 4 ) { // S i s o b r e p a s a l´ı m i t e . . . r e t v a l = c a n t i d a d d e r e g i s t r o s ∗4 − ∗ p u n t e r o o f f s e t ; // Leeremos l o que podemos #i f d e f depura p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP read : Lo que n os \ p i d e n s o b r e p a s a l a c a n t i d a d de r e g i s t r o s d e l XPS HWICAP, a s´ı que s o l o l e e m o s \ l o que podemos h a s t a l l e g a r a l f i n a l . r e t v a l = %d\n” , r e t v a l ) ; #e n d i f } else { // S i no l o s o b r e p a s a . . . r e t v a l = tamano ; // Leemos l o que n os p i d e n #i f d e f depura p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP read : La c a n t i d a d \ de d a t o s s o l i c i t a d o s no e x c e d e e l numero de r e g i s t r o s d e l XPS HWICAP, a s´ı que \ l e e r e m o s l o s d a t o s s o l i c i t a d o s . r e t v a l = %d\n” , r e t v a l ) ; #e n d i f } #i f d e f depura p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP read : Voy a l e e r %d \ d a t o s \n” , r e t v a l ) ; #e n d i f i f ( r e t v a l > 0) { f o r ( k =0; ki n t e r c a m b i o d e d a t o s + ( ∗ p u n t e r o o f f s e t + k /4))= l e i d o ; }

/∗ Se r e a l i z a e l t r a s p a s o de l a i n f o r m a c i ´ on desde e l d r i v e r e l ∗ ∗ u s u a r i o . En c a s o de s a l i r mal e n t o n c e s s e e n v´ıa e l c ´ odigo del ∗ ∗ error . ∗/ i f ( c o p y t o u s e r ( p u n t e r o u s u a r i o , el XPS HWICAP−>i n t e r c a m b i o d e d a t o s + ( l o n g u n s i g n e d i n t ) ∗ p u n t e r o o f f s e t r e t v a l = −EFAULT; else { #i f d e f depura p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP read : Se \ l e y e r o n b i e n l o s d a t o s \n” ) ; #e n d i f /∗ En c a s o de que t o d o s a l g a b i e n e n t o n c e s s e a c t u a l i z a e l ∗ ∗ p u n t e r o con l o s d a t o s l e i d o s . ∗/ ∗ p u n t e r o o f f s e t += r e t v a l ; } #i f d e f depura p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP read : Al s a l i r de \ la funci´ o n , ∗ p u n t e r o o f f s e t = %l u \n\n” , ( l o n g u n s i g n e d i n t ) ∗ p u n t e r o o f f s e t ) ; #e n d i f } return retval ; }

/∗ Funci´ o n XPS HWICAP write : ∗ ∗ El k e r n e l s o l i c i t a e s c r i b i r tamano b y t e s a l d r i v e r . La ∗ ∗ funci´ o n e f e c t u a l a l e c t u r a y d e v u e l v e l a c a n t i d a d de b y t e s que pudo l e e r . ∗ ∗ Adem´ as a c t u a l i z a e l p u n t e r o d e l u s u a r i o p u n t e r o 3 s e g u ´n l o s bytes l e i d o s . ∗/ s s i z e t XPS HWICAP write ( s t r u c t f i l e ∗ p u n t e r o f i l e , c o n s t c h a r user ∗ puntero usuario , \ s i z e t tamano , l o f f t ∗ p u n t e r o o f f s e t ) { /∗ V a r i a b l e p a r a e l f o r ∗/ int k ; /∗ V a r i a b l e que almacena l o que s e va a e s c r i b i r en e l r e g d e l XPS HWICAP ∗/ u32 u n a p a l a b r a ; /∗ V a r i a b l e que almacena e l v a l o r a d e v o l v e r ( B y t e s e s c r i t o s ) ∗/ ssize t retval ; /∗ Conserva un p u n t e r o a l a e s t r u c t u r a de t i p o XPS HWICAP dev ∗/ s t r u c t XPS HWICAP dev ∗el XPS HWICAP = p u n t e r o f i l e −>p r i v a t e d a t a ; #i f d e f depura p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP write : Estoy e j e c u t a n d o \ la funci´ o n XPS HWICAP write\n” ) ; p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP write : Tamano = %d\n” , \ tamano ) ; p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP write : El c o n t e n i d o de \ p u n t e r o o f f s e t e s : %l u \n” , ( l o n g u n s i g n e d i n t ) ∗ p u n t e r o o f f s e t ) ; #e n d i f /∗ tamano e s l a c a n t i d a d de b y t e s que s e d e s e a n e s c r i b i r y ∗ ∗ XPS HWICAP MEMSPACE SIZE e s l a c a n t i d a d de r e g i s t r o s de 32 b i t s que s e ∗ ∗ pueden e s c r i b i r ∗/ i f ( tamano>XPS HWICAP MEMSPACE SIZE) r e t v a l = XPS HWICAP MEMSPACE SIZE ; else r e t v a l = tamano ; /∗ Se r e a l i z a

el

t r a s p a s o de l a i n f o r m a c i ´ on hacia e l

driver

el

usuario .

∗

∗ En c a s o de s a l i r mal e n t o n

∗/ i f ( c o p y f r o m u s e r ( el XPS HWICAP−>i n t e r c a m b i o d e d a t o s + ( l o n g u n s i g n e d i n t ) ∗ p u n t e r o o f f s e t ,

Universidad Industrial de Santander

205

puntero usuario ,

Archivo XPS HWICAP.c r e t u r n −EFAULT; #i f d e f depura p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP write : Se t r a j e r o n %d \ b y t e s d e s d e e l e s p a c i o d e l u s u a r i o a l d e l XPS HWICAP . \n” , r e t v a l ) ; p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP write : El v a l o r d e l \ p u n t e r o v i r t u a l d e l I /O P o r t a s I /O Memory b a s e e s : %p\n” , \ XPS HWICAP iomem pointer ) ; p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP write : Con e s t e \ p u n t e r o s e har´ a n t o d a s l a s e s c r i t u r a s a l XPS HWICAP\n” ) ; #e n d i f /∗ Ahora s e e n v i a r ´ a c a r a c t e r por c a r a c t e r f o r ( k =0; ki n t e r c a m b i o d e d a t o s + ( ∗ p u n t e r o o f f s e t + k / 4 ) ) ; /∗ E x p l i c a c i ´ o n de p o r q u e hay que c amb i ar e l e n d i a n n e s s a l d a t o ?? ∗/ cambio endianness una palabra = change endianness ( una palabra ) ;

#e n d i f i o w r i t e 3 2 ( u n a p a l a b r a , XPS HWICAP iomem pointer + ∗ p u n t e r o o f f s e t + k ) ; #i f d e f depura p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP write : E s c r i b i en \ l a d i r e c c i o n = %X\ r \n” , ( u n s i g n e d i n t ) XPS HWICAP iomem pointer + k ) ; p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP write : E s c r i b i e l \ v a l o r 0 t o 31 = 0x%08X\ r \n” , c h a n g e e n d i a n n e s s ( u n a p a l a b r a ) ) ; /∗ p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP write : E s c r i b i e l \ v a l o r 0 t o 31 = 0x %8.8X\ r \n ” , u n a p a l a b r a ) ; ∗/ #e n d i f }

#i f d e f depura p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP write : Se e s c r i b i e r o n b i e n l o s d a t o s en e l XPS HWICAP. \ n” ) #e n d i f /∗ En c a s o de que t o d o s a l g a b i e n e n t o n c e s s e a c t u a l i z a ∗ l o s datos l e i d o s . ∗ p u n t e r o o f f s e t += r e t v a l ;

e l p u n t e r o con

∗ ∗/

#i f d e f depura p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP write : El c o n t e n i d o de p u n t e r o o f f s e t #e n d i f return retval ; }

al

f i n a l de l a f u n c i

/∗ Funci´ o n XPS HWICAP ioctl : ∗/ i n t XPS HWICAP ioctl ( s t r u c t i n o d e ∗ i n o d e 1 , s t r u c t f i l e ∗ p u n t e r o 1 , u n s i g n e d i n t comando , u n s i g n e d l o n g p a r a m e t r o ) { #i f d e f depura p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP ioctl : Estoy e j e c u t a n d o l a f u n c i o ´ n XPS HWICAP ioctl\n” #e n d i f s w i t c h ( comando ) { c a s e COMANDO 0 : #i f d e f depura p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP ioctl : El comando f u e COMANDO 0\n” ) ;

Universidad Industrial de Santander

206

Archivo XPS HWICAP.c p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP ioctl : Pongo e l p e r i f ´ e r i c o como s a l i d a \n” ) ; p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP ioctl : E s c r i b o 0 x00000000 en s l v r e g 1 \n” ) ; #e n d i f i o w r i t e 3 2 ( 0 x00000000 , XPS HWICAP iomem pointer + 4 ) ; break ; c a s e COMANDO 1 : #i f d e f depura p r i n t k (PRINTK LEVEL ”XPS p r i n t k (PRINTK LEVEL ”XPS p r i n t k (PRINTK LEVEL ”XPS #e n d i f i o w r i t e 3 2 ( 0xFFFFFFFF , XPS break ;

HWICAP depura : XPS HWICAP ioctl : El comando f u e COMANDO 1\n” ) ; HWICAP depura : XPS HWICAP ioctl : Pongo e l p e r i f ´ e r i c o como e n t r a d a \n” ) ; HWICAP depura : XPS HWICAP ioctl : E s c r i b o 0xFFFFFFFF en s l v r e g 1 \n” ) ; HWICAP iomem pointer + 4 ) ;

default : r e t u r n −ENOTTY; } return 0; }

/∗ Funci´ o n XPS HWICAP open : ∗ ∗ E s ta f u n c i ´ o n s e l l a m a cuando a l g u ´n proceso del sistema ∗ ∗ o p e r a t i v o a b r e e l nodo / dev /XPS HWICAP como s i f u e r a un a r c h i v o . ∗/ i n t XPS HWICAP open ( s t r u c t i n o d e ∗ p u n t e r o i n o d e , s t r u c t f i l e ∗ p u n t e r o f i l e ) { /∗ E s t e p u n t e r o a l m a c e n a r ´ a e l p u n t e r o a l XPS HWICAP dev que d e v o l v e r ´ a la ∗ ∗ funci´ o n c o n t a i n e r o f y p o s t e r i o r m e n t e s e almacena en e l p u n t e r o f i l e ∗ ∗ p a r a que pueda s e r usado p o r l a s dem´ a s f u n c i o n e s d e l m´ o dulo ∗/ s t r u c t XPS HWICAP dev ∗el XPS HWICAP ; /∗ Almacenar´ a e l n´ u mero de r e g i s t r o s d e l XPS HWICAP ∗/ i n t tamano ; /∗ V a r i a b l e d e l f o r ∗/ int k ; #i f d e f depura p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP open : Estoy e j e c u t a n d o \ la funci´ o n XPS HWICAP open\n” ) ; #e n d i f /∗ E s ta f u n c i ´ o n b u s c a c u a l s t r u c t XPS HWICAP dev c o n t i e n e ∗ ∗ p u n t e r o i n o d e −>i c d e v , e l c u a l e s de t i p o cdev . ∗/ el XPS HWICAP = c o n t a i n e r o f ( p u n t e r o i n o d e −>i c d e v , s t r u c t XPS HWICAP dev , cdev ) ; /∗ V e r i f i c a m o s que seamos l o s u ´ n i c o s que han a b i e r t o e l XPS HWICAP . S i no ∗ ∗ debemos r e t o r n a r un e r r o r que haga que e l l l a m a d o a l s i s t e m a s e r e p i t a ∗/ i f ( d o w n i n t e r r u p t i b l e (&el XPS HWICAP−>sem ) ) r e t u r n −ERESTARTSYS ; /∗ El p u n t e r o f i l e l l e g a a t o d a s l a s f u n c i o n e s , p o r e l l o s e a p r o v e c h a e l ∗ ∗ campo p r i v a t e d a t a p a r a a l m a c e n a r e l p u n t e r o ∗/ p u n t e r o f i l e −>p r i v a t e d a t a = el XPS HWICAP ; /∗ P re gu n ta s i a l g u n a v e z ha s i d o i n v o c a d o e l open p a r a s a b e r s i debe ∗ ∗ a s i g n a r l o s par´ ametros d e l p e r i f ´ erico ∗/ i f ( b an d e ra==0) { el XPS HWICAP−>b a s e a d d r e s s = XPS HWICAP BASEADDRESS ; el XPS HWICAP−>n u m e r o d e r e g i s t r o s = XPS HWICAP NUMERO REGISTROS ; s t r c p y ( el XPS HWICAP−>n o m b r e p e r i f e r i c o , XPS HWICAP NAME ) ; tamano = el XPS HWICAP−>n u m e r o d e r e g i s t r o s ; el XPS HWICAP−>i n t e r c a m b i o d e d a t o s = k m a l l o c ( tamano ∗ s i z e o f ( u n s i g n e d i n t ) ,GFP KERNEL ) ; f o r ( k =0;ki n t e r c a m b i o d e d a t o s [ k ] = 0 ; b an d e ra =1; #i f d e f depura p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP open : El m e n s a j e \ guardado en el XPS HWICAP−>n o m b r e p e r i f e r i c o e s : %s \n” , \ el XPS HWICAP−>n o m b r e p e r i f e r i c o ) ; #e n d i f } else { #i f d e f depura p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP open : Ya e s t a b a \ i n i c i a l i z a d o : ) \ n” ) ;

Universidad Industrial de Santander

207

Archivo XPS HWICAP.c #e n d i f } /∗ R e s e r v a d e l p u e r t o . . . e s t o s e r e f l e j a i n m e d i a t a m e n t e en / p r o c / i o p o r t s ∗/ i f ( ! r e q u e s t r e g i o n (XPS HWICAP BASEADDRESS, 4 ,XPS HWICAP NAME) ) p r i n t k (PRINTK LEVEL ”XPS HWICAP open : No s e pudo h a c e r e x i t o s a m e n t e e l \ r e q u e s t d e l p u e r t o XPS HWICAP : ( \ n” ) ; /∗ Se mapea l a d i r e c c i ´ o n f ´ı s i c a d e l p u e r t o en l a p o r c i ´ o n de memoria t i p o ∗ I /O. El tama˜ n o de l a r e s e r v a e s de 64 b y t e s XPS HWICAP iomem pointer=i ore map (XPS HWICAP BASEADDRESS, 0 x00000040 ) ;

∗ ∗/

return 0; }

/∗ Funci´ o n XPS HWICAP release : E s ta f u n c i ´ o n l i b e r a l o que l a f u n c i ´ on ∗ XPS HWICAP open ha r e s e r v a d o . i n t XPS HWICAP release ( s t r u c t i n o d e ∗ i n o d e 1 , s t r u c t f i l e ∗ p u n t e r o f i l e ) { s t r u c t XPS HWICAP dev ∗el XPS HWICAP = p u n t e r o f i l e −>p r i v a t e d a t a ; #i f d e f depura p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP release : Estoy \ ejecutando la funci´ o n XPS HWICAP release \n” ) ; #e n d i f /∗ l i b e r a c i o n de l a memoria I /O s o b r e l a que s e mapeo e l p u e r t o iounmap ( XPS HWICAP iomem pointer ) ;

∗ ∗/

∗/

/∗ L i b e r a c i ´ on del puerto reservado r e l e a s e r e g i o n (XPS HWICAP BASEADDRESS , 4 ) ;

∗/

/∗ L i b e r a e l s e m ´ aforo up(&el XPS HWICAP−>sem ) ; return 0;

∗/

}

/∗ En e s t a e s t r u c t u r a s e d e f i n e n l a s o p e r a c i o n e s que s e van i m p l e m e n t a r en e l ∗ ∗ driver ∗/ s t r u c t f i l e o p e r a t i o n s XPS HWICAP fops = { . owner = THIS MODULE, . l l s e e k = XPS HWICAP llseek , . read = XPS HWICAP read , . write = XPS HWICAP write , . ioctl = XPS HWICAP ioctl , . open = XPS HWICAP open , . r e l e a s e = XPS HWICAP release };

/∗ E s ta e s t r u c t u r a r e p r e s e n t a l o s d i s p o s i t i v o s XPS HWICAP i m p l e m e n t a d o s . Para ∗ ∗ e s t e c a s o f u e s o l o uno . La memoria que emplea e s t e d i s p o s i t i v o e s ∗ ∗ r e s e r v a d a en XPS HWICAP init ∗/ s t r u c t XPS HWICAP dev ∗my XPS HWICAP dev ;

Universidad Industrial de Santander

208

Archivo XPS HWICAP.c

/∗ Funci´ o n XPS HWICAP init : E s ta f u n c i ´ o n e s l l a m a d a cuando s e h a c e insmod y ∗ r e s e r v a l o s nu ´ meros major y minor y r e g i s t r a r e l d i s p o s i t i v o . s t a t i c i n t XPS HWICAP init ( v o i d ) { /∗ V a r i a b l e usada p a r a r e c i b i r e l c ´ o d i g o de e r r o r de l a f u n c i ´ on cdev init int err ; #i f d e f depura /∗ V a r i a b l e d e l f o r que r e p i t e e l m e n s a j e de s a l u d o . int k ; #e n d i f /∗ V a r i a b l e que r e c i b e e l v a l o r de l a f u n c i ´ on alloc chrdev region int result ;

∗ ∗/ ∗/ ∗/ ∗/

/∗ R e s e r v a d i n ´ a m i c a de l o s n u ´ meros d e l d r i v e r . ∗/ r e s u l t = a l l o c c h r d e v r e g i o n (&mydev , f i r s t m i n o r , count , nombre ) ; #i f d e f depura i f ( r e s u l t ==0) p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP init : Los n u ´ meros \ r e s e r v a d o s p a r a e l d r i v e r f u e r o n : \ n Major : %d\n Minor : %d\n” , MAJOR( mydev ) , \ MINOR( mydev ) ) ; else p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP init : Hubo un e r r o r \ y l o s nu ´ meros no s e r e s e r v a r o n . El e r r o r f u e : %d\n ” , r e s u l t ) ; #e n d i f /∗ R e s e r v a memoria en e l e s p a c i o d e l k e r n e l p a r a XPS HWICAP dev , e s ∗ d e c i r , que i n i c i a l i z a e l p u n t e r o my XPS HWICAP dev my XPS HWICAP dev = k m a l l o c ( s i z e o f ( s t r u c t XPS HWICAP dev ) , GFP KERNEL ) ; #i f d e f depura i f ( my XPS HWICAP dev==NULL) p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP init : P a i l a s , t o c ´ o r e i n i c i a r , no pude r e s e r v a r memoria \n” ) ; else p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP init : C o n g r a t u l a t i o n s , s o s un duro , r e s e r v a s t e memoria p a r a my XPS HWICAP dev , no t o c ´ o r e i n i c i a r , se r e s e r v a r o n %d B y t e s \n ” , ( i n t ) s i z e o f ( s t r u c t XPS HWICAP dev ) ) ; #e n d i f /∗ I n i c i a l i z a c i ´ o n del semaforo del p e r i f e r i c o init MUTEX(&my XPS HWICAP dev−>sem ) ; /∗ M´ e todo p a r a r e s e r v a r l a memoria p a r a e l cdev . E s t e m´ e todo p e r m i t e que ∗ e l cdev s e a p a r t e de n u e s t r a e s t r u c t u r a p e s o n a l i z a d a my XPS HWICAP c d e v i n i t (&my XPS HWICAP dev−>cdev ,&XPS HWICAP fops ) ; /∗ R e g i s t r o d e l d r i v e r en e l k e r n e l . E s t e m´ e todo no s e debe l l a m a r h a s t a ∗ no t e n e r t o d o l i s t o p a r a a t e n d e r c u a l q u i e r l l a m a d o e r r = c d e v a d d (&my XPS HWICAP dev−>cdev , mydev , 1 ) ; /∗ I n i c i a l i z a a l g u n o s campos de l a e s t r u c t u r a my XPS HWICAP dev my XPS HWICAP dev−>cdev . owner = THIS MODULE ; my XPS HWICAP dev−>cdev . op s = &XPS HWICAP fops ;

∗ ∗/

\ \ \ ∗/ ∗ ∗/ ∗ ∗/ ∗/

#i f d e f depura i f ( e r r comm ) ; #e n d i f /∗ Se pone l a b an d e ra a c e r o p a r a i n d i c a r que e l ∗ inicializado b an d e ra =0; return re s u lt ;

d r i v e r nunca ha s i d o

∗ ∗/

} /∗ Funci´ o n XPS HWICAP exit : E s ta f u n c i ´ o n e s i n v o c a d a cuando s e e j e c u t a rmmod y debe ∗ l i b e r a r y d e s h a c e r l o que l a f u n c i ´ o n XPS HWICAP init ha r e s e r v a d o s t a t i c v o i d XPS HWICAP exit ( v o i d ) {

Universidad Industrial de Santander

∗ ∗ ∗/

209

Archivo XPS HWICAP.c

/∗ D e s r e g i s t r a l o s n u ´ meros major y minor que l e f u e r o n a s i g n a d o s de forma ∗ ∗ din´ a m i c a ∗/ u n r e g i s t e r c h r d e v r e g i o n ( mydev , c o u n t ) ; /∗ Remueve e l d i s p o s i t i v o d e l k e r n e l ∗/ c d e v d e l (&my XPS HWICAP dev−>cdev ) ; /∗ L i b e r a e l e s p a c i o de memoria de l o s r e g i s t r o s d e l XPS HWICAP ∗/ i f (&my XPS HWICAP dev−>i n t e r c a m b i o d e d a t o s != NULL && b an d e ra==1) k f r e e ( my XPS HWICAP dev−>i n t e r c a m b i o d e d a t o s ) ; /∗ L i b e r a l a memoria r e s e r v a d a p a r a e l s t r u c t XPS HWICAP dev ∗/ k f r e e ( my XPS HWICAP dev ) ; #i f d e f depura /∗ Mensaje de d e s p e d i d a ∗/ p r i n t k (PRINTK LEVEL ”XPS HWICAP hello : XPS HWICAP exit : Bye bye , Mundo\n” ) ; /∗ Prueba que p e r m i t e s a b e r c u a l p r o c e s o l o i n v o c a a uno ∗/ p r i n t k (PRINTK LEVEL ”XPS HWICAP depura : XPS HWICAP exit : He s i d o i n v o c a d o p o r : [ % i ] %s \n” , c u r r e n t −>pid , c u r r e n t #e n d i f } /∗ I n d i c a c u a l e s f u n c i o n e s s on l a s que s e deben e j e c u t a r ∗/ m o d u l e i n i t ( XPS HWICAP init ) ; m o d u l e e x i t ( XPS HWICAP exit ) ;

al

e j e c u t a r insmod y ∗

∗ rmmod .

/∗ I n f o r m a c i ´ o n a d i c i o n a l s o b r e e l m´ o dulo . ∗/ MODULE AUTHOR( ” W i l l i a m Salamanca y S e r g i o Abreo . ” ) ; MODULE ALIAS( ”XPS HWICAP template” ) ; MODULE DESCRIPTION( ” D r i v e r que maneja un XPS HWICAP y que s i r v e como p l a n t i l l a \ p a r a c o n t r o l a d o r e s de o t r o t i p o de p e r i f ´ ericos .”);

Cuadro de C´ odigo I.2: Nueva librer´ıa xil io: Rutinas para escribir y leer datos de 32 bits en la memoria principal desde el espacio del usuario.

Universidad Industrial de Santander

210