Tema 4. ARM Linux

SISTEMAS DIGITALESMaster en Inteligencia Ambiental

ARM Linux

Sistemas empotrados


Introducción

2

ARM (Advanced RISC Machines) es una

arquitectura de 32 bits desarrollada por ARM

Holdings.

• Arquitectura RISC.

• Su simplicidad la hace ideal para aplicaciones de bajo

consumo.

• 2005: 98% de procesadores de teléfonos móviles usan al

menos un procesador ARM.

• Los procesadores ARM los desarrolla ARM y también

todos aquellos que sean titulares de su licencia.

• En la actualidad ARM no hace procesadores. Sólo los

diseña y licencia sus diseños a fabricantes.


Características

3

Características del ARM:1. Arquitectura Load/store.

• La memoria sólo es accesible mediante instrucciones

de load/store.

• El resto de instrucciones sólo manejan registros

internos.

2. Memoria alineada, los datos deben estar en posiciones

consecutivas.

3. 16 registros idénticos de 32 bits.

4. Juego de instrucciones RISC, con tamaño fijo de 32 bits.

5. La mayor parte de instrucciones se ejecutan en un sólo

ciclo.

6. Ejecución condicional de las instrucciones.

7. Desplazador de barril de 32 bits.

8. Registro de retorno.


Introducción

4

Gestión de

procesos

Gestión de

memoria

Sistema de

archivos

Control de

dispositivos

Gestión de red

Código

dependiente

de la

arquitectura

Gestor de

memoria

Sistemas de

ficheros

Dispositivos

de carácter

Subsistema de

red

Dispositivos

de bloque

Drivers de

tarjetas

Interfaz de llamadas al sistema (API, del sistema operativo)

Programas de usuario


Soporte para punto flotante (1)

• Muchas arquitecturas y plataformas ARM no tienen la unidad de punto

flotante. En ese caso hay que indicar al crear el kernel qué se va a hacer para

poder hacer operaciones con números reales.

• Hay dos soluciones para la emulación:

– Hard float: Permitir que los binarios en el espacio de usuario usen

instrucciones de punto flotante, y emular en el kernel el comportamiento de

dichas instrucciones mediante el uso de la excepción “illegal instruction”.

– Soft float: Añadir la emulación en el espacio de usuario en el momento de

la compilación, usando la opción del compilador -msoft-float.

• La solución habitual en Linux es “hard float”.

• La emulación “hard float” es lenta debido al manejo de excepciones y el

cambio de contexto implicado.


• En Linux hay dos emuladores “hard float” disponibles:

• NWFPE, NetWinder Floating Point Emulator

CONFIG_FPE_NWFPE

• FastFPE, más rápido pero no tan completo, no

adecuado para aplicaciones científicas

CONFIG_FPE_FASTFPE

• Algunas familias SÍ pueden realizar operaciones en punto

flotante usando el coprocesador matemático VFP.

• VFP está disponible en las familias ARM10,

ARM11 y Cortex.

• ARM proporciona soporte para el uso del VFP.

Soporte para punto flotante (2)


Mezclando hard y soft float

• La razón de soportar la emulación en el Kernel es que los

binarios pueden usar las ventajas del hardware en el

momento que esté disponible, sin necesidad de recompilar

(el kernel está preparado tanto para la emulación como

para el uso del coprocesador real).

• Por desgracia, dadas las restricciones impuestas por el

Application Binary Interface (ABI) no es posible mezclar

ambas emulaciones en el ABI normal.

• Una aplicación y todas sus librerías deben ser compiladas para uno

u otro caso.

• Afortunadamente las nuevas especificaciones EABI

resuelven el problema.


EABI (1)

• Embedded-ABI (EABI) es el nuevo

estándar ABI para la plataforma ARM.• EABI especifica formatos estándar par conversión de

ficheros, tipos de datos, uso de registros, organización de la pila, y paso de parámetros a funciones en programasempotrados.

• Ventajas:

• Posibilidad de mezclar código hard y soft float.

• Permite usar los binarios creados por otros

compiladores.

• Soporte para Thumb.


EABI (2)

Otros cambios en EABI:

• La estructura en el empaquetamiento y el alineamiento ha cambiado. No hay

alineamiento mínimo en estructuras.

• El stack para una función está alineado a 8 bytes en lugar de 4.

• El alineamiento para los enteros de 64 bits son 8 bytes.

• System call interface:

• El numero de la system call se pasa como parte de la instrucción SWI.

• El kernel lee y decodifica la instrucción SWI contaminando la cache de datos con

instrucciones.

• El numero de la llamada al sistema se pasa en el registro r7.

• Los argumentos de 64 bits son alineados a un número par en lugar de usar la

siguiente posición libre.


EABI en gcc y Linux

• El soporte para EABI se añadió en la version GCC 4.1.0.

• Buildroot permite seleccionar el ABI del sistema objetivo (si se va

a usar ABI o EABI al construir el kernel).

• El soporte EABI se añadió en la version del kernel de Linux 2.6.16

– CONFIG_AEABI

•Añade el soporte EABI en el kernel del Linux de

forma que las aplicaciones puedan ser compiladas

con el nuevo EABI.

– CONFIG_OABI_COMPAT

•En un kernel EABI-able, proporciona soporte para el

viejo ABI.

•Solo funciona para binarios no Thumb.

• Ejecutar un Binario EABI en un Kernel NO EABY no

funciona.


Introducción a Thumb

•Introducción a Thumb


Dos juegos de instrucciones

• Modo por defecto en ARM: instrucciones de 32 bits

• Con la revisión ARMV4T ISA, un nuevo juego de

instrucciones de 16 bits fue añadido : Thumb mode

– ARMV4T ISA se usa en ARM7TDMI, ARM9TDMI, ARM7x0T, ARM9xxT

– La ‘T’ en el nombre indica que esa arquitectura puede usar Thumb.

• Cuando un microprocesador está en modo ‘Thumb’, usa el

juego de instrucciones reducido Thumb.

• Son instrucciones de 16 bits.

• La mayoría se mapean directamente como instrucciones ARM.

• En la revisión ARMV5TE ISA, se añadieron mejoras para la

conmutación entre modos ARM y Thumb.

• Las instrucciones de 16 bits son útiles para aumentar la

densidad del código y disminuir el tamaño de los ejecutables.


Compilar con Thumb

• Cualquier toolchain para ARM es capaz de

generar binario que usan Thumb

• Opción -mthumb del compilador GNU C (gcc)

int bar(int c, int d)

{

return c + d;

}

int foo(int a, int b)

{

a += 3;

b -= 2;

return bar(b, a);

}

arm-linux-gcc -mthumb -c

arm-linux-objdump -S

0000000 <bar>:

0: b580 push {r7, lr}

2: b082 sub sp, #8

4: af00 add r7, sp, #0

6: 1d3b adds r3, r7, #4

8: 6018 str r0, [r3, #0]

a: 1c3b adds r3, r7, #0

c: 6019 str r1, [r3, #0]

e: 1d3b adds r3, r7, #4

10: 1c3a adds r2, r7, #0

12: 6819 ldr r1, [r3, #0]

[...]


Ganancia en tamaño

int bar(int c, int d)

{

return c + d;

}

int foo(int a, int b)

{

a += 3;

b -= 2;

return bar(b, a);

}

• Las instrucciones en Thumb ocupan la mitad de espacio.

• Ganancia en tamaño en un pequeño ejemplo no representativo:

• Reducción de 28 bytes, 22% de reducción de código

arm-linux-gcc -c

arm-linux-gcc -c -mthumb

test.arm.o

test.thumb.o

$ sizediff test.arm.o test.thumb.o

text data bss dec hex filename

124 0 0 124 7c test.arm.o

96 0 0 96 60 test.thumb.o

-28 0 0 -28 -1C +/-


Codificación

001 10 Rd 8-bit immediate

15 0Instrucción Thumb

1110 001 0 Rd 0000 8-bit immediate01001 0 Rd

31 0

Instrucción ARM

Major opcode indica

format 3move/compare/add/sub

with immediate value

Minor opcode indica

add instructionRegistros destino y fuente Valor inmediato

Condición: siempreEl procesador sólo tiene un juego de instrucciones (ARM).

Cuando está usando Thumb el procesador (mediante un

hardware dedicado, con lo que no se pierde tiempo)

expande las instrucciones Thumb de 16 bits almacenadas

en memoria a 32 bits, antes de irlas ejecutando.


Diferencias ARM - Thumb

• En modo Thumb se usa un conjunto de registros reducido.

• En modo Thumb algunas instrucciones, tales como branch o link, precisan 2 instrucciones.

• Algunas operaciones no se pueden realizar en Thumb: por ejemplo, acceder a los coprocesadores o al registro de estado.

0000000 <bar>:

0: b580 push {r7, lr}

[...]

00000020 <foo>:

[...]

4e: f7ff fffe bl 0 <bar>

[...]


Por diversas razones es necesario poder combinar código ARM y código

Thumb juntos:

Código Thumb que quiere hacer alguna operación que no se puede hacer

en modo Thumb.

Código crítico que precisa acceder a todo el espacio de memoria

codificado en ARM.

Código que usa librerías compiladas en modo ARM.

El compilador GNU Compiler proporciona un mecanismo transparente

denominado interworking que permite la mezcla de código ARM y

Thumb.

La arquitectura ARM proporciona instrucciones para pasar de un modo a

otro.

bx y blx, El bit más bajo de la dirección determina la conmutación:

Si bit[0] es 0, el procesador pasa o permanece en modo ARM.

Si bit[0] es 1, se pasa a modo Thumb.

Thumb y ARM interworking


Interworking

000081c4 <main>:

81c4: b580 push {r7, lr}

81c6: af00 add r7, sp, #0

[...]

81cc: f005 fb30 bl d830 <__foo_from_thumb>

[...]

00008220 <foo>:

8220: e1a0c00d mov ip, sp

8224: e92dd800 push {fp, ip, lr, pc}

[...]

8254: e12fff1e bx lr

0000d830 <__foo_from_thumb>:

d830: 4778 bx pc

d832: 46c0 nop (mov r8, r8)

0000d834 <__foo_change_to_arm>:

d834: eaffea79 b 8220 <foo>

Función main(), compilada en modo

Thumb, llama a foo()en modo ARM.

GCC genera

“wrappers” alrededor

de foo() para cambiar

de modo

PC es un registro de 16

bits usado como

contador de programa

LR es el link register y

almacena la dirección

de retorno


Interworking

Dos instrucciones “b” en Thumb. Almacenan dirección de retorno en lr.

lr = pc + (immediate << 12)

pc = lr + (immediate)lr = addr of next instruction | 1

Cambiar a modo ARM

pc tiene el bit mas bajo a 0 para pasar a modo ARM

Llamar a la función

Retornar al modo Thumb

lr tiene el bit mas bajo a 1 para pasar a modo

Thumb

f005 fb30

bl d830 <__foo_from_thumb>

4478 bx pc

eaffea79 b 8220 <foo>

e12fff1e bx lr


Interworking en nuestro sistema

Posibilidades:

Modos ARM y Thumb independientes en el kernel y en el

espacio de usuario.

Se puede usar un kernel en modo ARM con un

programa en Thumb. La ABI (interfaz kernel –

programa) permanece igual.

Modo completo Thumb en el espacio de usuario,

incluyendo libc.

uClibc Parece que no soporta el modo Thumb de

forma correcta.

Thumb en el espacio de usuario, excluyendo glib.


Generar toolchain

La toolchain que se utiliza para generar el código debe ser

capaz de trabajar con interwork, para ello se han de usar las

opciones:

--enable-interwork en la configuracion de la binutils

--enable-interwork en la configuración de gcc

Para habilitar el mecanismo interworking se utiliza la opción

-mthumb-interwork al generar el código.

En Uclibc hay que hacer lo siguiente:

-mthumb-interwork

USE_BX en la opción de configuración


Compilación de las aplicaciones

Manualmente

Añadir la opción -mthumb al comando de compilación.

CFLAGS+=-mthumb


Linux empotrado

Hasta ahora hemos visto qué se necesita para crear un sistema empotrado.

…

pero

…

¿Qué se hace realmente para crearlo?


Usar una distribución

• Una distribución proporciona paquetes binarios preparados

para usar.

• Hay distribuciones como Debian que están disponibles

para arquitecturas empotradas (ARM, MIPS, PowerPC).

• Esto hace relativamente fácil conseguir un sistema

funcional pero:

– El mantenedor del sistema ha realizado una serie de opciones de

configuración que pueden o no pueden coincidir con las opciones

necesarias para el usuario (soft float vs. hard float, EABI vs

OABI,…)

– No se dispone de control sobre la integración. (inicialización,

dependencias…)

– Si se desea integrar un parche o cambiar algo es necesario

reconstruir el paquete. No hay mecanismos que automaticen esto.


Manualmente

• Es posible compilar, configurar e instalar todos los

componentes que precisa tu sistema Linux

manualmente.

• Esto da flexibilidad, pero:

–Es preciso conocer las dependencias entre componentes.

–La compilación cruzada es una tarea tediosa.

–No hay un mecanismo automatizado para reconstruir el

sistema si se desea añadir o corregir algo.


Usar métodos de construcción

• Hay métodos de construcción que facilitan la tarea de crear un

sistema Linux empotrado.

• Se automatiza el proceso de descarga, configuración,

compilación e instalación de los paquetes.

• Método sistemático para reconstruir el sistema.

• Facilita la integración de parches o añadir nuevas funcionalidades.

• El sistema de construcción conoce la mayoría de los paquetes

de código abierto disponibles:

– Las dependencias son gestionadas y los problemas de la compilación

cruzada están resueltos.


Buildroot

Buildroot < http://www.buildroot.net/ > es un conjunto

de makefiles que automatizan el proceso de construir una

toolchain cruzada y un sistema Linux empotrado.

• Inicialmente esta herramienta se creó orientada para

uClibc.

• Durante mucho tiempo la herramienta ha estado sin

mantenedor.

• Pero desde enero de 2009 tienen un mantenedor oficial, Peter

Korsgaard.

• Se libera una nueva versión cada 3 meses.


Usuarios de Buildroot

• Actualmente estan usado esta

herramienta:

– ATMEL para AVR32 development

kit

– Gumstix

– Armadeus (ARM boards with FPGA)

– Calao Systems

http://www.calao-systems.com/

http://www.calao-systems.com/


Configuración de Buildroot

• Buildroot usa el

sistem Kconfig

configuration

system

• Ofrece un

interfaz

menuconfig-like

• Salva la

configuracion en

un fichero

.config


• Arquitecturas Target:

• arm, armeb, avr32, cris, i386, mips, mipsel, powerpc, superh, superh64,

x86_64

• Variantes de arquitecturas:

• Para ARM, por ejemplo: Generica, ARM7TDMI, ARM610, ARM710,

ARM720T, ARM920T, Xscale, etc.

• ABI selection:

• Para ARM, EABI or OABI

• Opciones para Target:

• Opciones de construcción:

• Herramientas que se deben usar, directorios

• ¿Documentación de instalación?, ¿símbolos de depuración?, ¿nivel de

optimización?

Configuración de Buildroot


Configuración de la Toolchain

• Buildroot puede crear una toolchain (limitada a toolchains en

uClibc) o usar otra toolchain externa (de un conjunto de

toolchains compatibles)

• En el caso de crear la toolchain, Buildroot permite seleccionar

cosas como:

– Versión de Kernel headers

– Versión de uClibc y configuración

– Versión de GCC y opciones

(Fortran, C++, Java, Objective C, …)

– Versión de GDB y opciones

(gdbserver, gdb on the target, cross-gdb on the host)

– Opciones generales de configuración de la toolchain

(large file support, RPC support, IPv6 support, locale support, etc.)


Selección de paquetes

• Varios cientos de paquetes están disponibles.

• Dependencias entre paquetes son gestionadas.

• Paquetes pincipales: busybox, bash, bzip2, diffutils, flex,

native toolchain, grep, bootutils, cups, at, beecrypt, dash,

file, gamin, less, lsof, ltrace, memstat, module-init-tools,

procps, psmisc, screen, strace, sudo, syslogd, klogd, util-

linux, which, etc.

• Librerias básicas : libconfig, libconfuse, libdaemon,

libelf, libevent, libgcrypt, libiconv, libidn, liblockfile,

liboil, libsysfs, etc.


• Base de datos: MySQL client, sqlite

• Editores : ed, nano, uemacs, vim

• Networking: argus, avahi, axel, boa, bind, bridge-utils, DHCP

support, dnsmasq, dropbear, ethtool, haserl, ifplugd, iperf, iproute2,

ipsec-tools, iptables, kismet, l2tp, lighttpd, linkns, lrzsz,

mDNSresponder, mii-diag, mrouted, nbd, ncftp, netcat, netkitbase,

netkittelnet, netplug, netsnmp, nfs-utils, ntp, openntpd, openssh,

openssl, openvpn, portmap, pppd, pppoe, pptp-linux, proftpd, quagga,

isisd, samba, rsync, stunnel, tcpdump, tftpd, thttpd, vsftpd, wireless

tools, etc.

• Hardware/system tools: dm, dmraid, e2fsprogs, fis, libfuse, hal,

hdparm, hotplug, i2c-tools, input-tools, iostat, libaio, libraw1394,

libusb, lm-sensors, lvm2, mdadm, mtd utils, pciutils, setserial, udev,

usbutils, etc.



• Audio/video: aumix, flac, gstreamer with plugins, libmad,

libmpd, libogg, libtheora, libvorbis, madplay, mpg123,

mplayer, speex, vlc, festival

• Librerías gráficas: ncurses, slang, dialog, DirectFB,

imagemagick, jpeg, libpng, libungif, pixman, SDL, QT

Embedded, Gtk (atk, cairo, pango, glib), fontconfig,

Freetype, Matchbox, X.org Kdrive and a few X applications

(window managers, etc.)

• Compresores

• Gestor de paquetes: ipkg, portage, rpm

• Interpretes, leguajes: lua, microperl, python, ruby, tcl, php

• Misc: Librerías XML , Java, juegos



Filesystem y kernel

• Selección del formato del sistema de ficheros raíz

(root filesystem):

–cramfs, cloop, ext2, jffs2, ubifs, squashfs, tar, cpio,

initramfs, romfs.

–También es posible crear un “raw root filesystem”

(sistema de ficheros raíz sin formato).

• Configuración del Bootloader

–U-Boot soportado

• Configuración del kernel

–Versión, configuración, parches y formato binario

pueden ser especificados (uImage, zImage, bzImage)

SISTEMAS DIGITALESMaster en Inteligencia Ambiental 36

Ejemplo de construcción


Jerarquia de directorios

• En los fuentes

– docs/, documentation

– package/, the configuration items and Makefiles for building the

userspace packages

– project/, the configuration items and Makefiles for the project concept

(several projects in the same Buildroot tree)

– scripts/ various utilities

– target/linux/, building the Linux kernel

– target/<fstype>/, generating the root filesystem image

– target/device/, ready-made configuration for supported boards

– target/generic/target_skeleton/, the default root filesystem skeleton

– toolchain/, building a cross-compiling toolchain


Using Buildroot in a nutshell

• Descargar última versión estable y obtenerla del

repositorio SVN

• make menuconfig

• Make

• raw root filesystem se crea en

project_build_ARCH/PROJECT/root/

• Imagen root filesystem y kernel se crea en

binaries/PROJECT/

• La localización de los directorios de salida se

puede cambiar usando O=/path/to


Directorios generados

• build_ARCH

– Un directorio para cada paquete que se crea

– staging_dir, donde se encuentra la toolchain y donde los paquetes

son instalados

• project_build_ARCH/PROJECT

– autotools_stamps, gestión de dependencias

– buildroot-config, Ficheros de cabecera relacionados con Buildroot

– root, El sistema root filesystem para el objetivo

• toolchain_build_ARCH

– Donde la toolchain es configurada y creada


Alternativas

• Similares a Buildroot

– PTXdist, Pengutronixhttp://www.pengutronix.de/software/ptxdist/index_en.html

– LTIB, Freescale.Buen soporta para las placas de Freescale http://www.bitshrine.org/

• Aproximaciones diferentes

– OpenEmbedded, Mas flexible pero más compleja http://www.openembedded.org

– Gentoo Embeddedhttp://www.gentoo.org/proj/en/base/embedded/handbook/

http://www.pengutronix.de/software/ptxdist/index_en.html

http://www.bitshrine.org/

http://www.openembedded.org/

http://www.gentoo.org/proj/en/base/embedded/handbook/

SISTEMAS DIGITALESMaster en Inteligencia Ambiental 41

Bootloaders


Bootloaders

• El bootloader es el software responsable de:

• La inicialización básica del hardware.

• Cargar una aplicación binaria (el kernel, en nuestro caso)

desde la flash, red, o dispositivo no volátil en la memoria.

• Ejecutar la aplicación.

• Además de estas funciones básicas la mayoría de los

bootloader proporcionan un shell básico con diversos

comandos, para la ejecución de diferentes operaciones:

• Inspección de memoria

• Carga de dispositivos

• Diagnosis hardware …


Bootloaders en x86

• En los sistemas x86 la placa posee la BIOS

• Este programa se ejecuta automáticamente en la CPU

después de un reset y es el responsable de:

• La inicialización básica del sistema.

• Cargar un pequeño programa en memoria (primer sector del

disco duro) para el arranque del sistema operativo.

• Esta pieza de software es el primer cargador de

arranque, que inicia el cargador propiamente dicho

(grub, lilo)


Bootloaders en arquitecturas embebidas

• En las arquitecturas embebidas el arranque de bajo nivel es muy

dependiente del procesador y de la placa de desarrollo.

• Algunas placas tienen NOR flash de las cuales la CPU carga las primeras

instrucciones después de un reset. En este caso el cargador de arranque se “flasea”

en la memoria NOR en la posición adecuada.

• Algunas CPU tienen integrada un cargador en una ROM interna que

automáticamente permite el arranque de un pequeño programa almacenado en

NAND flash. En este caso se usa un cargador de dos etapas. El primero que se

encuentra en la flash en la posición preprogramada arranca al cargador principal.

• El cargador en la arquitectura embebidas se ejecuta

inmediatamente después de un reset. Por lo tanto será el

encargado de inicializar todos los dispositivos, incluida la

memoria DRAM.

• El vendedor debe proporcionar la información ya que el cargador

es muy dependiente de la placa.


• Cargadores de código abierto mas populares en

la actualidad

• U-Boot, the universal bootloader de Denx

• Es el más usado en ARM, también se puede usar en PPC, MIPS, x86, m68k, NIOS, etc.

http://www.denx.de/wiki/U-Boot

– RedBoot, basado en RedHat eCos

http://sources.redhat.com/redboot/

– uMon: MicroMonitor general purpose, multi-OS bootloader

http://microcross.com/html/micromonitor.html

Bootloaders en arquitecturas embebidas


http://sources.redhat.com/redboot/

http://microcross.com/html/micromonitor.html


U-Boot

• U-Boot es un proyecto de software libre

• Disponible en http://www.denx.de/wiki/U-Boot

• Documentación disponible en

http://www.denx.de/wiki/U-Boot/Documentation

• Los últimos desarrollos están disponibles a través la

herramienta git: http://git.denx.de/cgi-

bin/gitweb.cgi?p=u-boot.git;a=summary

• La lista de discusión se encuentra en

http://lists.denx.de/pipermail/u-boot/

• Desde el 2008 se libera una nueva versión (release)

cada 2 meses. Las versiones son identificadas por el

nombre, que contiene el mes y el año YYYY.MM.


http://www.denx.de/wiki/U-Boot/Documentation

http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=summary

http://lists.denx.de/pipermail/u-boot/


Compilar U-Boot (1)

• Obtener el código fuente y descomprimir

• El directorio include/configs/ contienen un fichero de

configuración para cada una de las arquitecturas

soportadas:

• Se definen CPU, periféricos, configuración de periféricos,

mapeo de memoria, características de U-Boot que se deben

incluir, etc..

• Hay un fichero .h que determina las constantes de

preproceso. Leer el fichero README

• Si la placa es soportada por U-boot, debería haber un

fichero correspondiente a la placa concreta. Por

ejemplo include/configs/omap2420h4.h.


Compilar U-Boot (2)

• U-Boot debe ser configurado antes de compilar

–make BOARDNAME_config

–Donde BOARDNAME es el nombre del fichero .h (de

configuración) en el directorio include/configs/, sin el .h

• Una vez configurado U-Boot, hay que asegurarse de

que el compilador cruzado está disponible en el PATHexport PATH=/usr/local/uclibc-0.9.29-2/arm/bin/:$PATH

• Finalmente, se compila U-Boot, con el prefijo

adecuado a la arquitectura en la que se quiere realizar

la carga:

• Ejemplo Si es arm-linux-gcc:

make CROSS_COMPILE=arm-linux-


Instalar U-Boot

• U-Boot debe ser instalado en la memoria flash para

poder ser ejecutado por el hardware. Dependiendo del

hardware, la instalación varía

• En placas con algún monitor específico de carga, que

permite instalar en la flash un segundo bootloader, es preciso

usar la documentación de la placa así como las herramientas

recomendadas por el fabricante.

• Si ya está instalado es posible substituir U-boot por una

nueva versión. Ojo al actualizar: Si se produce un problema

la placa puede quedar inutilizada.

• Si la placa dispone de un interfaz JTAG que permite modificar

remotamente la memoria flash sin ningún sistema de apoyo es

posible recuperar la placa.


U-boot prompt

• Cargado el U-Boot, es posible conectar el sistema remoto

al host a través de una consola serie.

• Realizada la conexión, al encender la placa en la consola

serie se verá algo como esto:

U-Boot 1.1.2 (Aug 3 2004 - 17:31:20)

RAM Configuration:

Bank #0: 00000000 8 MB

Flash: 2 MB

In: serial

Out: serial

Err: serial

u-boot #

• El shell del U-Boot ofrece un conjunto de comandos. A

continuación veremos los más importantes.


Comandos de información• U-Boot> flinfo

DataFlash:AT45DB021

Nb pages: 1024

Page Size: 264

Size= 270336 bytes

Logical address: 0xC0000000

Area 0: C0000000 to C0001FFF (RO) Bootstrap

Area 1: C0002000 to C0003FFF Environment

Area 2: C0004000 to C0041FFF (RO) U-Boot

• U-Boot> nand info

Device 0: NAND 256MiB 3,3V 8-bit, sector size 128 KiB

• U-Boot> version

U-Boot 2009.08 (Nov 15 2009 - 14:48:35)

Información

sobre la flash

Información

flash NAND

Información U-

Boot

Esta información cambia de una placa a otra

(en función de la configuración de compilación)


Variables de entorno (1)

• U-Boot puede ser configurado a través de variables de entorno

que afectan al comportamiento de los comandos.

• Mirar la documentación para la lista completa.

• El comando printenv muestra todas las variables de entorno, o

una sola:u-boot # printenv

baudrate=19200

ethaddr=00:40:95:36:35:33

netmask=255.255.255.0

ipaddr=10.0.0.11

serverip=10.0.0.1

stdin=serial

stdout=serial

stderr=serial

u-boot # printenv serverip

serverip=10.0.0.2

Configuración de red

Para mostrar una sóla variable


Variables de entorno (2)

• El valor de las variables de entorno puede ser cambiado

mediante el comando setenv :

u-boot # setenv serverip 10.0.0.2

• Las variables de entorno son almacenadas en la flash usando

el comando saveenv. La localización en la flash es definida

en tiempo de compilación a través del fichero de

configuración.

• Se pueden usar pequeños scripts para modificar las variables

:

setenv myscript 'tftp 0x21400000 uImage ; bootm

0x21400000'

• Para ejecutar el script:

run myscript


Transferencia de ficheros hacia el target

• U-Boot es usado principalmente para la carga y arranque de una

imagen del kernel, pero permite cambiar la imagen y el root

filesystem almacenados en la flash.

• Los ficheros pueden ser intercambiados entre el host y el target.

• Mediante una conexión de red. U-Boot contienen un driver Ethernet para

esto. El protocolo TFTP puede ser usado para ello.

• A través de una conexión serie si no es posible una conexión Ethernet.

Target Host

U-Boot TFTP

cliente

TFTP

servidor

Ethernet


Configurar TFTP

• En un sistema GNU/Linux basado en Debian

• Instalar el paquete tftpd-hpa (tftp server):

• Reiniciar el superservidor inetd :

sudo /etc/init.d/openbsd-inetd restart

• Copiar los ficheros al directorio root del servidor TFTP.

Ejemplo:

cp arch/arm/boot/uImage /var/lib/tftpboot

• Para comprobar que el servidor funciona instalar el cliente

TFTP:

apt-get install tftp-hpa

• Usar para descargar un fichero

tftp localhost

> get uImage


U-boot mkimage

• La imagen del kernel que U-boot carga debe estar preparada. Es

necesario añadir una cabecera especial específica para U-Boot.

• Esto se hace mediante la herramienta que proporciona Uboot,

mkimage

• En Debian / Ubuntu: basta con instalar el paquete uboot-

mkimage.

• O, en su defecto, crearla a partir de los fuentes.

• La imagen especial para el sistema target uImage, creada a

partir de un Makefile de los fuentes del kernel, puede ser usada

para crear la imagen adecuada para U-Boot.


Flasheando una imagen del kernel

• Compilar el kernel y generar U-Boot header (debe estar instalada mkimage).

• Ejecutar make uImage

• Copiar la nueva imagen al directorio raíz del servidor TFTP

• En la placa, mediante el shell de U-Boot, descargar la nueva imagen a memoria

(8000 posición hexadecimal donde se deposita el fichero):

u-boot # tftp 8000 uImage

• Desproteger NOR flash

u-boot # protect off 1:0-4

• Borrar NOR flash

u-boot # erase 1:0-4

• Copiar a NOR flash (0x01000000: first sector)

u-boot # cp.b ${fileaddr} 1000000 ${filesize}

• Restaurar protección NOR :

u-boot # protect on 1:0-4


boot commands

• Parámetros específicos de arranque del

kernel :

u-boot # setenv bootargs mem=64M \

console=ttyS0,115200 init=/sbin/init \

root=/dev/mtdblock0

• Ejecutar el kernel almacenado en una

posición física

(RAM o flash):

bootm 0x01030000

Misma línea

Tema 4. ARM Linux

Documents

Transcript of Tema 4. ARM Linux