Olimex CS-EP9302. Guia rápido

Transcrição

1 Olimex CS-EP9302 Guia rápido Manuel Ferreira Março 2012

2 Índice 1. Introdução Utilização Imagem do kernel inexistente Montar um disco USB Arranque a partir de um disco USB Actualização do sistema e gestor de pacotes Compilar e executar um programa Aplicação executada no arranque do sistema Criar uma nova ramdisk Compilação do kernel...11 A. Inittab...12

3 1. Introdução A placa de desenvolvimento CS-EP9302, comercializada pela Olimex, tem instalada uma distribuição Linux. A placa dispõe de um microprocessador ARM da Cirrus Logic, o EP9302, da família ARM920T, funcionando a 200 MHz, tem duas portas USB, duas portas RS232, Ethernet a 100 Mbps, suporte para cartões de memória SD, 16 Mbyte de NOR Flash, 32 Mbyte de SDRAM, um transceiver IrDA e conectores (JTAG, UEXT, EXT e ADC) para periféricos adicionais. Este documento pretende ser um guia para a utilização da CS-EP9302, dando indicações como comunicar com o Sistema Operativo Linux instalado, como compilar e instalar imagens do kernel e novas aplicações. A escrita deste documento partiu do principio de que o leitor tem conhecimentos mínimos sobre hardware de microprocessadores e de Linux. A abordagem é directa, ou seja, para uma determinada situação é apresentada uma solução prática, não se dando explicações ou soluções alternativas. 2. Utilização Para uma melhor comunicação com a placa e de forma a minimizar possíveis incompatibilidades e problemas, é recomendado que se utilize um computador ou máquina virtual com Sistema Operativo Linux. Recomenda-se o Ubuntu LTS, que é opensource, logo disponibilizado sem quaisquer custos para o utilizador. Para comunicação com a placa, é necessário um PC com uma porta série RS232 ou um adaptador USB/RS232. No Linux os dispositivos são referenciados através de ficheiros, normalmente presentes no directório /dev. No caso do conversor USB/RS232 no Ubuntu LTS, a porta RS232 é referenciada pelo ficheiro /dev/ttyusb0. Outras possibilidades são /dev/usb0 e /dev/tty0, dependendo do tipo de ligação e distribuição de Linux. Para ser possível a comunicação com a placa é necessário instalar um software de comunicação série. A escolha recaiu sobre o PuTTY, mas outras opções são possíveis. O putty pode ser instalado no Ubuntu através do Gestor de Pacotes Synaptic (System Administration Synaptic Package Manager), ou através da linha de comandos, escrevendo sudo apt-get install putty. Uma vez instalado, o PuTTY tem de ser configurado. A figura 1 mostra a configuração utilizando um conversor USB/RS232 para uma distribuição Ubuntu LTS. Figura 1- Configuração do PuTTy para um conversor USB/RS232 em Ubuntu LTS O computador e a placa são ligados por RS232 através de cabo null modem. A placa necessita de ser ligada a 1

4 um fonte de alimentação de 5 V que forneça pelo menos 0,5 A. O processo de arranque inicia com a execução do bootloader RedBoot (Red Hat Embedded Debug and Bootstrap) residente na memória Flash. Para que o sistema funcione é necessário que o Redboot esteja devidamente configurado e que existam imagens válidas de um kernel Linux e de um file system na memória Flash. Caso falhe alguma destas condições, o sistema não arranca e terá de ser utilizado um dos métodos de recuperação. 3. Imagem do kernel inexistente Caso não exista uma distribuição Linux válida, o RedBoot inicia do modo mostrado na figura 2. A partir desta figura pode ser retirada alguma informação relevante: 32 Mbyte (0x ) de SDRAM com início no endereço Mbyte (0x ) de NOR Flash com início no endereço 0x Endereço IP/máscara de subrede: / Gateway por omissão: Servidor de DNS: Servidor por omissão: Figura 2- Arranque do sistema sem imagem de Linux. É possível descarregar para a placa as imagens do kernel Linux e do file system através da rede, utilizando um servidor TFTP. Para isso, os endereços IP da placa têm de ser configurados utilizando o comando fconfig. A figura 3 mostra uma possível configuração; os valores terão de ser adaptados para a rede onde o sistema irá ser ligado. 2

5 Figura 3 - Configuração dos endereços IP no RedBoot É necessário instalar um servidor de TFTP no Ubuntu; recomenda-se a instalação do tftpd-hpa existente no gestor de aplicações. Por omissão, os ficheiros para upload são colocados no directório /var/lib/tftpboot, no entanto, esta localização pode ser alterada editando o ficheiro /etc/default/tftpd-hpa. Se a localização dos ficheiros for alterada é necessário reiniciar o serviço com o comando sudo service tftpd-hpa restart. É necessário copiar para este directório a imagens do kernel Linux e do file system. Vão ser utilizados os ficheiros zimage9302_ e ramdisk.gz disponíveis no CD-ROM que acompanha a placa. Como primeiro passo, a memória Flash é inicializada com o comando fis init -f. A opção -f garante que a imagem do RedBoot presente na Flash não é apagada. As imagens do kernel e do file system são primeiro descarregadas para a memória SDRAM e só depois copiadas para a memória Flash. O comando load permite descarregar ficheiros para a memória SDRAM. A forma utilizada é a seguinte: RedBoot> load -r -v -b location -h server-ip-address filename -r indica informação binária. -b indica o endereço na SDRAM onde a informação será colocada. -v mostra um indicador de progresso. -h server-ip-address indica o endereço do servidor TFTP. Se o Default server IP Address foi correctamente configurada no comando fconfig, esta opção não é necessária. A sequência de comandos para descarregar as imagens para a SDRAM e sua posterior cópia para a Flash é: RedBoot> RedBoot> RedBoot> RedBoot> load -r -v fis create load -r -v fis create -b 0x ramdisk.gz ramdisk -b 0x zimage9302_ zimage O ficheiro ramdisk.gz com a imagem do file system é copiado para o endereço 0x e o ficheiro zimage9302_ com a imagem do kernel é copiado para o endereço 0x O comando fis create permite criar ficheiros na memória Flash a partir de informação previamente guardada na memória SDRAM. A figura 4 mostra a sequência de acções no RedBoot. O comando fis list permite visualizar o conteúdo da memória Flash. 3

6 Figura 4 - Descarregamento e cópia para a Flash a partir de um servidor TFTP das imagens do kernel e do file system. O comando fis load filename copia um ficheiro da memória flash para a memória SDRAM. O comando exec executa um kernel. RedBoot> exec -r ramdisk_address -s ramdisk_length -b load_address -l load_length -c kernel_command_line -r -s -b -l -c ramdisk_address Endereço da ramdisk do tipo initrd passado ao kernel. ramdisk_length Dimensão da imagem da ramdisk. load_address Endereço da imagem do kernel. load_length Dimensão da imagem do kernel. kernel_command_line Linha de comandos passada ao kernel. Em seguida é necessário definir, através do comando fconfig, o script para o RedBoot executar durante o arranque do sistema. A sequência de comandos do script é: >> fis load ramdisk >> fis load zimage >> exec -r 0x s 0x b 0x l 0x c "root=/dev/ram console=ttyam0" A figura 5 mostra a sequência completa das acções a efectuar no RedBoot. A opção Run script at Boot do comando fconfig tem de ter o valor true de modo a garantir a execução do script quando o sistema arranca. O comando fis list mostra a estrutura de ficheiros da Flash. 4

7 Figura 5 - Configuração do script de arranque do sistema no RedBoot. 4. Montar um disco USB Insere-se o disco numa das fichas USB existentes. Passado pouco tempo o Linux detecta o disco e envia para a consola a informação que pode ser vista na figura 6. Fica-se a saber que o nome do device através do qual se interagirá com o dispositivo é sda1, que corresponde ao ficheiro /dev/sda1. Para se saber um pouco mais à cerca do dispositivo, pode-se executar o comando fdisk -l, cujo resultado pode também ser visto na figura 6. Fica-se a saber que o disco tem 2,002 MB, trata-se portanto de um disco USB de 2 GB. Sabe-se também que o disco tem um sistema de ficheiros FAT32, o habitual em Windows. Figura 6 - Resposta do sistema depois de detectado um disco USB. Antes de usar o disco há que o montar. No processo, há que estabelecer qual a directoria do sistema de ficheiros da placa sobre a qual ficará montado o sistema de ficheiros do disco. Opta-se por montar o disco na directoria /media/usbdisk. Esta directoria em princípio não existe. Cria-se através do comando mkdir /media/usbdisk. Para montar o disco executa-se o comando mount /dev/sda1 /media/usbdisk, que não retorna 5

8 informação para a consola em caso de sucesso. Executando o comando df -h obtém-se informação acerca dos discos montados no sistema. O disco só deve ser removido da ficha USB depois de desmontado. Para isso, executa-se o comando umount /media/usbdisk. A sequência de acções encontra-se demonstrada na figura 7. Figura 7 - Montagem e desmontagem de um disco USB. 5. Arranque a partir de um disco USB Para ser possível arrancar o sistema a partir de um disco USB é necessário: Uma imagem válida de um kernel na Flash. Um disco USB com um sistema de ficheiros reconhecido pelo kernel. O script de arranque do sistema no RedBoot tem de indicar ao kernel que o sistema de ficheiros montado no arranque do sistema encontra-se no disco USB. O sistema tem predefinido o utilizador root com password olimex. O sistema de ficheiros a instalar no disco USB está armazenado no ficheiro rootdir.gz, que se encontra no CD-ROM que acompanha a placa. Como primeiro passo, é necessário formatar o disco USB em ext3 e depois descompactar os ficheiros para a raiz do disco USB. 1. É necessário saber o nome do device associado ao disco USB e desmontá-lo. Na figura 8 encontra-se representada a sequência de operações. Primeiro, com o comando sudo fdisk -l, obtém-se a referência do device associado ao disco USB, que é /dev/sdb1. Em seguida, com o comando umount /dev/sdb1, desmonta-se o disco. 6

9 Figura 8 - Nome do dispositivo associado ao disco e como o desmontar. 2. O comando mke2fs permite criar um sistema de ficheiros numa partição de um disco. sudo mke2fs -j -L USB-root /dev/sdb1 -j Formata a partição com um sistema de ficheiros do tipo ext3. -L Label da partição depois de formatada. 3. Monta-se o disco o disco USB em /media/usb-root com o comando mount. sudo mkdir /media/usb-root sudo mount /dev/sdb1 /media/usb-root 4. Copia-se o ficheiro rootdir.tgz para disco USB e em seguida descompacta-se com o comando tar. O comando sync sincroniza o conteúdo da cache com o disco. cd /media/usb-root cp ~/CD-Olimex/rootdir.tgz sudo tar zxf rootdir.tgz sync cd.. umount /media/usb-root rmdir /media/usb-root 5. Finalmente é configurado o script de arranque do kernel no RedBoot. O kernel demora algum tempo a reconhecer o disco USB. A opção rootdelay=5 atrasa 5 segundos a montagem do sistema de ficheiros. >> fis load zimage >> exec -c "root=/dev/sda1 console=ttyam0 rootdelay=5" 6. Actualização do sistema e gestor de pacotes O sistema de ficheiros montado no disco USB é uma distribuição Debian. Uma das vantagens desta distribuição é a gestão de pacotes. Todas as aplicações em Debian são primeiro empacotadas e só depois instaladas. O gestor de pacotes APT (Advanced Package Tool) torna possível instalar, remover e actualizar as aplicações. Um pacote é um ficheiro que contém os ficheiros necessários para a instalação de uma aplicação. No entanto, a aplicação pode necessitar de outros pacotes de modo a puder ser executada. A estes pacotes chama-se dependências. O gestor de pacotes resolve automaticamente as dependências, faz o download e a instalação dos pacotes necessários. Para a sua execução, o gestor de pacotes necessita de privilégios de root. Benefícios: 7

10 Existem ferramentas para a instalação, actualização, remoção e gestão de pacotes. Permite a instalação e actualização de aplicações através da rede. Indica a que pacote em particular pertence um ficheiro ou que ficheiros contém um pacote. Mantém uma Base de Dados dos pacotes instalados no sistema e o seu estado. Permite saber que pacotes (e respectivas versões) estão instalados. Fornece verificação de dependências. Fornece ferramentas para verificação de assinaturas digitais. Existem ferramentas para a construção de pacotes. Os pacotes são guardados on-line em bases de dados referidas como repositórios. O APT tem uma lista de repositórios que se encontram no ficheiro /etc/apt/sources.list. É necessário editar este ficheiro com o comando nano sources.list e onde estiver stable, alterar para oldstable. Para actualizar o sistema executa-se o comando apt-get update. Ter em atenção que a execução deste comando requer uma ligação à Internet e que a sua execução pode ser demorada. Para a instalação da aplicação wget utiliza-se o comando apt-get install wget. Um cliente TFTP pode ser instalado com o comando apt-get install tftp. 7. Compilar e executar um programa Para se compilar e executar um programa na placa de desenvolvimento é necessário um cross compiler ARM instalado no PC. O cross compiler recomendado é o compilador gnu versão que se encontra em Recomenda-se a utilização deste compilador porque outras versões podem não ser compatíveis. Depois de descompactado para a directoria /usr/local/arm, actualiza-se a variável de ambiente PATH. Esta alteração só é válida para a consola onde é executada. PATH=/usr/local/arm/3.4.1/bin:PATH O programa a ser executado, que se apresenta de seguida, está guardado no ficheiro hello.c. include <stdio.h> int main(void) { printf("ep9302 says: Hello world!\n"); return 0; } O programa é compilado com o comando: arm-linux-gcc -o hello hello.c Onde: arm-linux-gcc é o compilador, hello.c o ficheiro a compilar e a opção -o indica que o nome do executável é hello. Para a execução do programa é necessário copiá-lo para a placa de desenvolvimento. Das várias hipóteses possíveis recomenda-se uma das duas seguintes: 1. Instalar um servidor de TFTP no PC. Copiar o ficheiro hello para /var/lib/tftpboot. Na placa de desenvolvimento utilizar o comando TFTP para copiar o ficheiro. 2. Instalar o servidor Apache no PC. Copiar o ficheiro hello para /var/www Na placa de desenvolvimento utilizar o comando wget para copiar o ficheiro. Depois de copiado, o programa tem de ter privilégios de execução, para isso faz-se, 8

11 chmod u+x hello Finalmente, para se executar o programa faz-se,./hello 8. Aplicação executada no arranque do sistema Para se executar uma aplicação durante o arranque do sistema é becessário copiá-la para a imagem da ramdisk e escalonar a sua execução no ficheiro inittab. 1. É necessário descompactar a imagem da ramdisk e em seguida montá-la. Vai ser utilizado a ramdisk que se encontra no CD-ROM que acompanha a placa. sudo su cp../cd\ Olimex/linux-2.6\ images/ramdisk.gz./ gzip -d ramdisk.gz mkdir ram mount -o loop ramdisk ram 2. Copia-se a aplicação previamente compilada para uma directoria da ramdisk. cp hello ram/bin 3. Edita-se o ficheiro etc/inittab da ramdisk e coloca-se a linha null::once/bin/hello, como mostrado na figura 8. gedit ram/etc/inittab Figura 9 - Definição no ficheiro /etc/bin da aplicação hello executada no arranque do sistema. 4. Desmonta-se a ramdisk e compacta-se a imagem. umount ram gzip ramdisk 5. Copia-se a imagem compactada para a directoria /var/lib/tftpboot cp ramdisk.gz /var/lib/tftpboot 9

12 6. Finalmente, copia-se a imagem da ramdisk para a placa utilizando o procedimento definido em Imagem do kernel inexistente 9. Criar uma nova ramdisk. Para se criar uma nova imagem de uma ramdisk, é necessário um dispositivo de bloco disponível. Neste caso, vai ser utilizado o dispositivo /dev/ram0. 1. Uma ramdisk de 10 MB é criada escrevendo zeros no device escolhido. A inicialização com zeros permite maximizar a taxa de compressão da imagem. dd if=/dev/zero of=/dev/ram0 bs=1k count=10240 O comando dd copia um ficheiro, convertendo a informação de acordo com uma série de operandos. if=file Lê do ficheiro file em vez de stdin. /dev/zero Uma leitura a device retorna caracteres nulos (0x00). of=file Escreve no ficheiro file em vez de stdout. bs=nbytes Lê e escreve nbytes de cada vez. count=nblocks Define o número de blocos a copiar. 2. Formata-se a nova ramdisk com um sistema de ficheiros ext3. mke2fs -jm0 /dev/ram O comando mke2fs cria um file system ext2, ext3 ou ext4. -j Cria um sistema de ficheiros ext3. -m Especifica a percentagem do sistema de ficheiros reservado para o utilizador root Número de blocos do device. 3. Na directoria ramdisk, criam-se as directorias old-ramdisk e new-ramdisk. mkdir ramdisk cd ramdisk mkdir old-ramdisk mkdir new-ramdisk 4. É necessário copiar para a nova ramdisk um sistema de ficheiros. Vai ser utilizado o conteúdo da ramdisk que se encontra no CD-ROM. sudo su cp../cd\ Olimex/linux-2.6\ images/ramdisk.gz./ 5. Descompacta-se e monta-se a imagem da ramdisk na directoria old-ramdisk. gzip -d ramdisk.gz mount -o loop ramdisk old-ramdisk 6. Compacta-se o conteúdo da ramdisk e em seguida esta é desmontada. O sistema de ficheiros da imagem da ramdisk encontra-se agora em ramdisk.tar.bz2. cd old-disk tar jcf../ramdisk.tar.bz2. cd.. umount old-ramdisk 7. Monta-se a nova ramdisk na directoria new-ramdisk. Em seguida, descompacta-se o sistema de ficheiros presente em ramdisk.tar.bz2. mount /dev/ram0 new-ramdisk cd new-ramdisk 10

13 tar jxf../new-ramdisk.tar.bz2 8. Finalmente, desmonta-se a ramdisk e comprime-se a sua imagem para new-ramdisk.gz. umount old-ramdisk dd if=/dev/ram0 bs=1k count=10240 gzip -9 > new-ramdisk.gz cd.. rmdir old-ramdisk rmdir new-ramdisk 10. Compilação do kernel Para se compilar o kernel com suporte para cartões de memória SD, é necessário: Cross compiler ARM. Código fonte do kernel Linux (foi utilizado o kernel rc7). http//at91sam9263tools.googlecode.com/files/linux tar.bz2 Patch para o kernel rc Para a instalação do cross compiler ARM efectua-se o procedimento descrito na secção Compilar e executar um programa 2. Depois de efectuado o download do código fonte do kernel e do respectivo patch, o código fonte do kernel é descompactado. Em seguida é aplicado o patch. wget wget tar -jxf linux tar.bz2 cd linux zcat../linux rc7_ep93xx_mmc.patch.gz patch -p1 3. O patch instala o ficheiro cs-e9302_kernel_config na raiz do código fonte do kernel. Este ficheiro contém as configurações necessárias para se compilar um kernel com as características adequadas à placa. Este ficheiro terá de ser copiado para o ficheiro.config utilizado para a parametrização da compilação. cp cs-e9302_kernel_config.config PATH=/usr/local/arm/ t/bin:PATH make ARCH=arm oldconfig make ARCH=arm CROSS_COMPILE=arm-linux- zimage 4. A imagem encontra-se na directoria arch/arm/boot do código fonte. cp arc/arm/boot/zimage /var/lib/tftpboot/zimage

14 Anexos A. Inittab The inittab file describes which processes are started at bootup and during normal operation (e.g. /etc/init.d/boot, /etc/init.d/rc, gettys...). Init(8) distinguishes multiple runlevels, each of which can have its own set of processes that are started. Valid runlevels are 0-6 plus A, B, and C for ondemand entries. An entry in the inittab file has the following format: id:runlevels:action:process Lines beginning with are ignored. id is a unique sequence of 1-4 characters which identifies an entry in inittab. Note: For gettys or other login processes, the id field should be the tty suffix of the corresponding tty, e.g. 1 for tty1. Otherwise, the login accounting might not work correctly. runlevels lists the runlevels for which the specified action should be taken. action describes which action should be taken. process specifies the process to be executed. If the process field starts with a + character, init will not do utmp and wtmp accounting for that process. This is needed for gettys that insist on doing their own utmp/wtmp housekeeping. This is also a historic bug. The runlevels field may contain multiple characters for different runlevels. For example, 123 specifies that the process should be started in runlevels 1, 2, and 3. The runlevels for ondemand entries may contain an A, B, or C. The runlevels field of sysinit, boot, and bootwait entries are ignored. When the system runlevel is changed, any running processes that are not specified for the new runlevel are killed, first with SIGTERM, then with SIGKILL. Valid actions for the action field are: respawn The process will be restarted whenever it terminates (e.g. getty). wait The process will be started once when the specified runlevel is entered and init will wait for its termination. once The process will be executed once when the specified runlevel is entered. boot The process will be executed during system boot. The runlevels field is ignored. bootwait The process will be executed during system boot, while init waits for its termination (e.g. /etc/rc). The runlevels field is ignored. off This does nothing. ondemand A process marked with an ondemand runlevel will be executed whenever the specified ondemand runlevel is called. However, no runlevel change will occur (ondemand runlevels are a, b, and c). initdefault 12

15 An initdefault entry specifies the runlevel which should be entered after system boot. If none exists, init will ask for a runlevel on the console. The process field is ignored. sysinit The process will be executed during system boot. It will be executed before any boot or bootwait entries. The runlevels field is ignored. powerwait The process will be executed when the power goes down. Init is usually informed about this by a process talking to a UPS connected to the computer. Init will wait for the process to finish before continuing. powerfail As for powerwait, except that init does not wait for the process's completion. powerokwait This process will be executed as soon as init is informed that the power has been restored. powerfailnow This process will be executed when init is told that the battery of the external UPS is almost empty and the power is failing (provided that the external UPS and the monitoring process are able to detect this condition). ctrlaltdel The process will be executed when init receives the SIGINT signal. This means that someone on the system console has pressed the CTRL-ALT-DEL key combination. Typically one wants to execute some sort of shutdown either to get into single-user level or to reboot the machine. kbrequest The process will be executed when init receives a signal from the keyboard handler that a special key combination was pressed on the console keyboard. Examples This is an example of a inittab which resembles the old Linux inittab: inittab for linux id:1:initdefault: rc::bootwait:/etc/rc 1:1:respawn:/etc/getty 2:1:respawn:/etc/getty 3:1:respawn:/etc/getty 4:1:respawn:/etc/getty tty1 tty2 tty3 tty4 This inittab file executes /etc/rc during boot and starts gettys on tty1-tty4. A more elaborate inittab with different runlevels (see the comments inside): Level to run in id:2:initdefault: System initialization before anything else. si::sysinit:/etc/rc.d/bcheckrc Runlevel 0,6 is halt and reboot, 1 is maintenance mode. l0:0:wait:/etc/rc.d/rc.halt l1:1:wait:/etc/rc.d/rc.single l2:2345:wait:/etc/rc.d/rc.multi l6:6:wait:/etc/rc.d/rc.reboot What to do at the "3 finger salute". ca::ctrlaltdel:/sbin/shutdown -t5 -rf now 13

16 Runlevel 2&3: getty on console, level 3 also getty on modem port. 1:23:respawn:/sbin/getty tty1 VC linux 2:23:respawn:/sbin/getty tty2 VC linux 3:23:respawn:/sbin/getty tty3 VC linux 4:23:respawn:/sbin/getty tty4 VC linux S2:3:respawn:/sbin/uugetty ttys2 M