Beagleboard- OMAP 3530

Alexandre Augusto Giron- UNIOESTE

João Angelo Martini- UEM

Marcio Seiji Oyamada- UNIOESTE

http://www.inf.unioeste.br/~marcio

UNIOESTE – Universidade Estadual do Oeste do Paraná

Curso de Ciência da Computação

Cascavel - Brasil

Tópicos

Beagleboard

– Características

OMAP 3530

– ARM Cortex A8

– DSP C64x+

Exemplos práticos

Beagleboard

Kit de desenvolvimento utilizando a plataforma

OMAP

– www.beagleboard.org

BeagleBoard C4: ARM+ DSP (US$ 125)

BeagleBoard XM: ARM +DSP (US$ 149)

BeagleBone: ARM (US$ 89)

BeagleBoard C4

Beagleboard C4

Beagleboard

Sistemas Operacionais suportados

– Angstrom

– Debian (sem atualização)

– Ubuntu (constantes atualizações)

– Android

Beagleboard XM

ARM 1Ghz

512 MB RAM

Portas USB

Porta Ethernet

OMAP 3530

OMAP 3530

Plataforma OMAP3

– Aplicações alvo:

• Audio

• Telecom

• Eletrônicos

• Industrial

• Médico,

• Segurança

• Avionicos e defesa

• Vídeo e imagem

OMAP 3530- Esquemático

Dispositivos utilizando o OMAP3xxx

Device TYPE MPSoC

Touch Book Netbook OMAP 3530

Pandora Portable Video

Game OMAP 3530

DevKit8000 Evaluation Kit OMAP 3530

BeagleBoard Evaluation Kit OMAP 3530

Motorola

Milestone Smartphone OMAP 3430

Nokia N9000 Smartphone OMAP 3430

Samsung i8910 Smartphone OMAP 3430

Galaxy S Smartphone OMAP 3630

Droid 2 Smartphone OMAP 3630

Milestone 2 Smartphone OMAP 3630

ARM Cortex A8

Pipeline de 3 estágios

– Busca(3 cycles)

– Decodificação (4 cycles)

– Execução (6 cycle)

ARM- Diferenças em relação ao RISC

Instruções com ciclos de execução diferentes

Pré-processamento de operandos

Conjunto de instruções Thumb 16-bit

Execução condicional

Instruções especializadas

Load/Store múltiplos

DSP

Arquitetura com recursos para extrair o máximo

desempenho em algoritmos de processamento de

sinais

Realizar as operações em paralelo

– ci * x(n -1)

C64x+

Processador de sinais digitais da TI- Texas

Instruments

VLIW – Very long instruction

– 8 instruções por ciclo

– Empacotamento de instruções para execução sequencial

ou paralela

– Suporte a tipos de dados de 8, 16 e 32 bits

– Suporte a saturação e normalização

C64x+

Experimentos práticos

Instalando a distribuição Linux [3]

Download de uma imagem pré-compilada

– http://rcn-ee.net/deb/rootfs/oneiric/ubuntu-11.10-r9-

minimal-armel.tar.xz

Script de Instalação

– De acordo com a plataforma: sudo ./setup_sdcard.sh --

mmc /dev/mmcblk0 --uboot “board”

– Opções “board”: beagle_cx, beagle_xm

BeagleBoard Networking

Através de um cabo USB-OTG

– ssh, interface usb0

Cabo “par-trançado” (BeagleBoard XM apenas)

Adaptador Wifi USB

Ubuntu – Instalando aplicações

Sudo apt-get update

Sudo apt-get install gcc

Exemplo hello_world.c

Exemplo MiBench -> jpeg decoder

Alterando a frequência no ARM

cpufreq-info

cpufreq-set -g performance

cpufreq-set -f 800MHz

cpufreq-set –f 300MHz

BeagleBoard GUI - Ubuntu

Gdm xubuntu-desktop

BeagleBoard GUI - Ubuntu

xfce

BeagleBoard GUI – Debian

Debian gdm

BeagleBoard – Desenvolvimento ARM+DSP

O programador deve implementar explicitamente o

código no ARM e no DSP

Baseada na criação de DSP Nodes

Requisitos:

– Compilador arm-linux-gnueabi-gcc

– DSP toolchain: C6x CGT compiler

– doffbuild tools

Comunicação efetuada através da troca de

mensagens entre os processadores

BeagleBoard – Ambientes de desenvolvimento

Ferramentas:

– Hard-style: vi + makefile (arm e dsp)

• Programador fica desamparado

• Depuração heterogênea comprometida

– Soft-Style: utilizar um ambiente de programação

• Ex: Code Composer Studio – CCS*

– Suporte à várias plataformas

– Análise de performance e comportamento

– Hardware Debugging

* http://processors.wiki.ti.com/index.php/Category:Code_Composer_Studio_v5

Code Composer Studio

Code Composer Studio

BeagleBoard – Comunicação

Messaging:

– API para troca de mensagens síncronas

• DSP_Node_PutMessage, DSPNode_GetMessage

– Capacidade assíncrona: mecanismo de notificação

• DSPNode_RegisterNotify, DSPManager_WaitForEvents

BeagleBoard – Tipos de Comunicação

Estrutura de Componentes

DSP/Bridge Project: http://www.omappedia.org/wiki/DSPBridge_Project

Componentes

Da perspectiva ARM-Side

Gerenciamento de Recursos

– Instancia dinamicamente os DSP nodes

– Monitoramento dos recursos DSP

– Carregar dinamicamente código DSP conforme a

necessidade

– Políticas para gerenciar os recursos DSP

Componentes

Gerenciador de Plataforma

– Inicia/Finaliza execução do DSP

– Implementa streaming de dados

– Carrega estaticamente o bridgedriver (baseImage)

DSP link driver para comunicação baixo-nível

Componentes DSP

Da perspectiva do lado DSP (DSP/BIOS)

Servidor de Gerenciamento de Recursos

– DSP/BIOS se comunica com o lado ARM através do link

driver

– Permite a criação, execução e término dos DSP task nodes

• DSP Task Nodes: threads independentes de execução

no DSP, suportam I/O stream entre si e com o ARM

– Responde aos comandos do Gerenciador de Recursos

(lado ARM)

O modelo DSP-dummy

Disponível em:

– http://gitorious.org/vjaquez-beagleboard/dsp-samples

Basicamente, divide-se em três partes: o código

voltado ao processador ARM, o código voltado ao

DSP e o código para as chamadas ao DSP Bridge

Etapas da Execução (ARM)

Primeiro, é iniciado o controlador do DSP Bridge

Em seguida, reserva-se os recursos do lado ARM

para controle de um processador DSP

Etapas da Execução (ARM)

Agora, o nodo DSP pode ser alocado:

Etapas da Execução (ARM)

A função dsp_node_create é responsável por criar o

nó dsp alocado. Após criado, ele é executado

Executando:

• A partir do momento que o DSP node está em execução,

o processador ARM pode trocar mensagens ou realizar

streaming de buffers de dados com o nodo

Etapas da Execução (ARM)

No exemplo, um input e um output buffer.

• A referência para os buffers (arg1 e arg2) é passada ao

DSP: dsp_node_put_message

Com a posse dos buffers, o DSP aguarda a

mensagem para iniciar o processamento (cmd = 1)

Etapas da Execução (Perspectiva DSP)

O DSP espera a mensagem do ARM

– Com cmd = 0, DSP recebe as referências dos buffers

Etapas da Execução (Perspectiva DSP)

Então aguarda pela mensagem de início do

processamento (cmd = 1)

– Ao iniciar o processamento, nesse caso, o lado ARM fica

bloqueado esperando a resposta do DSP.

Etapas da Execução (ARM)

Assim que termina o processamento por parte do

DSP, o nodo pode ser finalizado e então liberado da

memória.

Liberando nodo:

Interações ARM-Bridge-DSP

Interações ARM-Bridge-DSP

Interações ARM-Bridge-DSP

Exemplos

Soma de vetores:

– Soma simples: Execução no DSP

– Execução em torno de 50 ms

Exemplos

Soma de vetores:

– Soma otimizada: através de instruções específicas DSP

– Execução em torno de 10 ms

Referências

V. M. J. LEAL, “The DSP/BIOS Bridge”, Igalia

Company. Slides disponíveis em:

– [1] http://people.igalia.com/vjaquez/talks/bridgedriver-

omap3-fosdem-2010.pdf

BeagleBoard Sites:

– [2] http://beagleboard.org/

– [3] http://elinux.org/BeagleBoardUbuntu

– [4] http://elinux.org/BeagleBoard/DSP_Howto

Manuais de Referência da Texas Instruments:

– OMAP 3530, ARM Cortex-A8, DSP C64x+