O aparecimento das arquiteturas multicore permitiu aos sistemas operativos tirar o proveito da paralelização dos cores para um melhores escalonamento das suas tarefas. Com isto, permitiu a introdução de novas configurações nos sistemas operativos. É neste contexto que é abordado dois tipo de ideologias de arquiteturas usadas nos sistemas operativos multicore: AMP (asymmetric multiprocessing) e SMP (symmetric multiprocessing).
2.3.1
Asymmetric multiprocessing
Na arquitetura AMP (figura 2.11) cada core tem o seu próprio sistema operativo, promovendo múltiplos ambientes de execução em paralelo semelhante a de um sistema singlecore. Neste sentido, cada core é independente e cada um tem o seu propósito específico. A fácil compreensão dos programadores neste sistema, deve- se a cada core comportar-se como um sistema operativo singlecore, no sentido em que cada um tem os seus próprios processos, escalonamento e gestão de memória. Esta arquitetura pode ser considerada homogénea no caso do sistema operativo
que é executado em cada core é o mesmo, ou pode ser considerada heterogéneo no caso da execução de sistemas operativos diferentes em cada core.
O ambiente homogéneo permite ao utilizador escolher em qual dos cores pretende executar a aplicação enquanto que comunica via IPC com os outros serviços do sistema (ex:device drivers) que estão presente nos outros cores. Este sistema per- mite que o cores não estejam sobrecarregados. No caso do ambiente heterogéneo como sistemas operativos serem diferentes em cada core, os utilizadores devem ter cuidado pois poderá ser necessário reformular o IPC entre os sistemas operativos. Outros dos possíveis conflitos destes ambiente está no acesso aos recursos. Um dos possíveis métodos para resolver, está em normalizar os mecanismos de acesso ao
hardware [9, 23].
Aplicação 1 Aplicação 2 Aplicação N
OS 1 OS 2 OS N
CPU 1 CPU 2 CPU N
Interconexão do sistema
Memória SO 1 Memória SO 2
... Memória SO N I/O I/O I/O I/O
Contolador de Memória
...
Figura 2.11: Arquitetura AMP
2.3.2
Symmetric multiprocessing
Na arquitetura SMP (figura 2.12), por outro lado, apenas um sistema operativo controla os vários cores dos sistema. O SO considera todos os cores de forma homogénea sendo que cada um tem acesso a memória comum. Deste modo, não restringe os cores dando-lhes a possibilidade de poderem partilhar os diferentes processos do SO. Este tratamento de igualdade, permite que cada core seja in-
dependente, dando a ideia que são vários singlecores a trabalharem em sintonia para um mesmo propósito. Esta arquitetura, permite que o código ser possa ser visto e ser processado em qualquer core, promovendo um paralelismo atraente e transparente para o programador. Contudo, os cores não são livres de fazer o que querem. Devido à concorrência dos cores, que os sistema operativo SMP utilizas- sem novos métodos controlo e de sincronização para o acesso aos seus recursos e novos métodos de escalonamento, permitindo distribuir da melhor forma as tarefas pelos diversos cores possibilitando um aumento da performance do sistema.
Aplicação OS
CPU 1 CPU 2 CPU N
Interconexão do sistema
Memória SO I/O I/O I/O I/O
Contolador de Memória
...
Figura 2.12: Arquitetura SMP
A generalidade dos sistemas de tempo-real tem primeiramente o requisito obter a capacidade de resposta rápida e só depois interessa a capacidade de transferência. Contudo, isto varia consoante as aplicações. Estas podem exigir mais throughput dando ênfase ao multicore do que propriamente capacidade de resposta rápida. Entretanto conjugar maior throughput com a característica de resposta rápida nas arquiteturas SMP pode ser considerado um dos maiores desafios para os progra- madores de sistemas operativos [9, 23].
2.4
Soluções de RTOS
A lista de RTOS existentes ultrapassa a centena. Nesta subsecção serão apresen- tadas e descritas sucintamente três das mais relevantes soluções.
2.4.1
µC/OS-II
O µC-OS/II, desenvolvido por Jean J.Labrosse, é um RTOS open-source com um kernel implementado em ANSI C e com apenas algumas linhas de código em
assembly, permitindo assim que este RTOS seja portável para vários processadores.
Este, derivado a sua arquitetura pode correr nos microprocessadores de 8-bit, 16- bit, 32 e 64-bit ou até mesmo em microcontroladores e DSPs. Contudo estes microprocessadores têm que disponibilizar o acesso ao stack pointer e aos registos do CPU de forma que seja possível fazer os push e os pop da stack.
O propósito deste RTOS está em aplicações embebidas, é personalizável pois é possível eliminar os serviços que não são necessários permitindo assim uma redução do footprint de memória. É um RTOS que pode executar 64 tarefas diferente mas que 8 pertencem ao sistema, restando assim outras 56 tarefas para aplicações. O seu algoritmo de escalonamento tem por base no HPF (Highest Priority First) e também viabiliza mecanismos de preemtividade possibilitando que as tarefas de maior prioridade interrompam tarefas de menor prioridade. Por esse motivo, neste RTOS, cada tarefa tem uma prioridade única. Contudo a tarefa de maior prioridade pode ser interrompida na ocorrência de um evento assíncrono (ISR), sendo esta logo executada no fim da interrupção.
O µC-OS/II contém serviços como mailbox, queues, semáforos, partições de memó- ria, etc. A simplicidade e o pequeno kernel ajusta-se perfeitamente para sistemas embebidos que requerem uma alta performance. Contudo, a possibilidade de usar 56 tarefas e cada uma com prioridade única são algumas das limitações apontadas [16, 22].
2.4.2
µTKernel
A empresa T-Engine Forum é a responsável pelo desenvolvimento do µT-Kernel. Este é um sistema operativo de tempo-real que conta com duas versões 1.0 e 2.0 para singlecore e outras duas para multicore, o SMP T-Kernel e o AMP T- Kernel. Este RTOS, desenvolvido com finalidade comercial e educacional, está implementado em C permitindo ser adaptado para várias plataformas que tenham arquiteturas até 32-bits. Este RTOS apresenta um vasto leque de API com três tipo de finalidades: funções relacionadas com o sistema operativo, funções relacionadas com a gestão do hardware e, por último, para dar apoio ao debug do sistema.
A configuração neste sistema permite adicionar alguns recursos sendo só preciso fazer uma pequena recompilação, ou então fazer uma pequena mudança. O seu escalonamento é baseado no HPF, no caso de existir duas ou mais tarefas com a mesma prioridade, a política de desempate é o FCFS (First-Come First-Served). Contudo, estas tarefas podem ser interrompidas de duas formas: por interrupções ou por exceções de tarefas. Estas exceções permitem que estas tarefas sejam tratadas como interrupções por software, caso contrário, as interrupções provêm de eventos do hardware.
Como o RTOS anterior, este também contém os serviços mailbox, queque, semáfo- ros, partição de memória, etc. Contudo, como desvantagem deste RTOS relativa- mente a outros, esta está no maior uso de memória ROM [3, 6, 17].
2.4.3
FreeRTOS
O FreeRTOS é um RTOS open-source e desenvolvido por Richard Barry. Neste momento este RTOS dá suporte a vinte sete diferentes arquiteturas e permite licença para uso educacional e comercial tendo tido 107000 downloads no ano de 2013 [24]. É um RTOS implementado em C e com um kernel de tamanho máximo de 9k bytes. Possui uma quantidade razoável de API para acesso ao sistema e a serviços como semáforos (binários e contadores), semáforos recursivos,
queqes, mutexes. O escalonamento é baseado em prioridades e no caso da existência
de tarefas com a mesma prioridade, a política de desempate é o Round Robin. Este RTOS está dividido em duas camadas: a camada “hardware independent” e “portable layer ”. A primeira camada, hardware independent, está responsável pela implementação da maior parte das funções do sistema operativo. A segunda camada, portable layer, está responsável pelo software específico da arquitetura, como por exemplo, o context switching [19].
Resumindo, é um RTOS com o intuito de ser simples e pequeno, perdendo em re- lação a outros RTOS na quantidade de serviços disponibilizados [6]. Contudo, este RTOS não tem limites execuções de tarefas, o que pode ser considerado vantajoso em comparação ao µC-OS/II.
Capítulo 3
Especificação do Sistema
Este capítulo tem como objetivo apresentar a especificação do RT-ARM(M)OS desenvolvido e as ferramentas necessárias para a sua realização. Para isso, este capítulo está dividido em três subcapítulos. Primeiramente é abordado a arquite- tura do hardware para que foi desenvolvido o RT-ARM(M)OS. Inicia-se com uma introdução geral às arquiteturas ARM e seguidamente é realizada uma descrição mais focada no processador Cortex-A9. Depois disto, é descrito o ambiente e as ferramentas usadas no desenvolvimento e depuração/simulação do software. Por último, são apresentadas as especificações do RT-ARM(M)OS, começando com a apresentação dos serviços que irão ser implementados e terminando com os meca- nismos necessários, que permitirão o seu funcionamento tanto em singlecore como em multicore.
3.1
Arquitetura da ARM
3.1.1
Introdução
Hoje em dia, grande parte dos sistemas embebidos de 32-bit são acompanhados por processadores com arquiteturas ARM. A ARM proveniente das siglas Advanced
RISC Machine, é uma empresa cujo o seu principal objetivo não é fazer o seu
próprio chip, mas sim vender as especificações e a propriedade intelectual às outras empresas, como, STMicroelectronics, Intel, Nvidia, Texas Instruments e Samsung, sendo que estas representam mais de mil milhões de processadores produzidos até os dias de hoje [25][26].
O principal objetivo da arquitetura da ARM é um design simples mas poderoso e adotando uma filosofia aproximada ao RISC (Reduce Instruction Set Compu-
ter ). A arquitetura RISC tem por base fornecer um reduzido número de simples
e poderosas instruções, que possam ser executadas num único ciclo de relógio.
Atualmente, a ARM adotou dividir as suas arquiteturas em três familias Cortex: Cortex-A, Cortex-R e Cortex-M [7][26].
• A família Cortex-A são orientados para aplicações genéricas e com requisito de performance. Normalmente permitem a execução de GPOS (como o Linux e Windows), de forma a disponibilizarem poderosas interfaces gráficas ao utilizador. Estes são geralmente usados nos smartphones, tablets, PDA ou
laptops.
• A família Cortex-R são orientados para sistemas de tempo-real. Estes, em comparação à família Cortex-A, oferecem menores latências a pedidos de interrupções e são mais determinísticos nos tempos de resposta. Geralmente são usados para controlar sistemas críticos que exigem tempo de resposta rápida.
• A família Cortex-M são orientados para sistemas que requerem baixo con- sumo. Operam com uma frequência de relógio menor que as outras duas famílias, e geralmente são usados em micro-controladores que desempenham funções com múltiplas entradas e saídas. Estes podem ser encontrados em robôs ou em aparelhos eletrónicos de consumo.
3.1.2
ARM Cortex-A9
Em 2008 a ARM lançou o processador Cortex-A9. Este processador ganhou popu- laridade por manter o equilíbrio entre alta performance e consumo de energia. O Cortex-A9 contêm um ciclo de relógio aproximado a 1GHz, originando um aumento superior a 50% em relação ao anterior processador, o Cortex-A8 [7]. Baseado na arquitetura ARMv7, este processador pode ser configurado até quatro cores, possi- bilitando o aumento da fluidez de execução das aplicações. Aqui são apresentadas algumas das suas características:
• Caches de nível 1(L1) associative-way de 16, 32 ou 64KB. • Tecnologia NEON para processamento multimédia.
• Unidade de Floating-point.
• Controlador de interrupções - Generic Interrupt Controller (GIC). • 9 a 12 estados do pipeline.
• Snoop Control Unit (SCU).
• Accelerator Coherency Port (ACP).
• Tecnologia ARM CoreSight Multicore Debug e Trace
ARM Cortex-A9 Core 4 Core 3 Core 2 Core 1 ARMv7 32b CPU 16-64k I-Cache 16-64k D-Cache NEON Data Engine Floating Point Unit
ARM CoreSight Multicore Debug and TRACE
ACP SCU
Dual 64-bit AMBA 3 AXI Generic Interrupt Controller
Figura 3.1: Processador Cortex-A9
Modos
Existem vários modos de execução dos processadores na arquitetura ARM, dei- xando o programador escolher o modo mais adequado para as suas aplicações. A utilização dos diferentes modos está associada às suas limitações. Para isso, os modos foram caracterizados por conterem, ou não, privilégios a determinadas operações, como por exemplo, o acesso à MMU. No total existem nove modos na ar- quitetura ARM. Destes modos, oito deles são caracterizados por terem privilégios
(abort, fast interrupt request, interrupt request, supervisor, monitor, hypervisor,
system e undfined), e apenas um sem privilégios (user ) [7]. A tabela 3.1 sumariza
as funcionalidades destes modos.
Tabela 3.1: Modos de execução do processador Cortex-A9
Modo Funcionalidade
Supervisor
(SVC)
Entra no modo na ocorrência de reset ou quando uma instrução SVC é executada.
FIQ Entra no modo na ocorrência de uma fast interrupt. IRQ Entra no modo na ocorrência de uma interrupt.
Abort (ABT) Entra no modo na ocorrência uma violação no acesso a memória.
Undefined Entra no modo na ocorrência de uma execução de uma instrução.
não definida
Monitor (MON) Modo para acesso ter acesso ao mundo seguro (TrustZone).
Hypervisor (HYP) Modo para a extensão de suporte à virtualização. Acedido com
a execução da instrução HVS(Hypervisor ).
System (SYS) Modo privilegiado obtendo os mesmos registos do modo user.
User (USR) Modo não privilegiado, onde ocorrem a maior parte das aplicações.
Register
O register file da arquitetura ARM é composto por dezoito registos de 32-bits: dezasseis deles são registos de dados, enquanto que os outros dois pertencem ao estado do processador. Conforme as especificações do EABI (embedded application
binary interface), dos dezasseis registos de dados referidos, normalmente os quatro
primeiros (R0-R3) são usados para os argumentos das funções. Caso esses registos não sejam suficientes para os argumentos, então estes devem ser guardados na
stack. Outra função que é atribuída ao registo R0 é o valor de retorno da função. Na
ocorrência do valor retorno ser superior aos 32-bits, este será distribuído também ao registo R1. Os registos R4 a R12 tipicamente são registos de uso geral, ou seja, podem ser usados para qualquer tipo de cálculos. Os três últimos registos de dados (R13, R14, R15) têm uma função especializada, nesse sentido, são atribuídas labels de forma a se poderem diferenciar dos restantes registos. As funções desses registos são os seguintes:
• O R13, denominado por stack pointer (sp), desempenha como função apon- tar para o topo da stack pertencente ao modo à que está em execução o processador;
• O R14, denominado por link register (lr), desempenha a função de guardar o endereço de retorno na chamada de uma sub-rotina;
• O R15, denominado por program counter (pc), desempenha a função de con- ter o endereço da próxima instrução a ser executada pelo processador.
R0 R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13 (sp) R14 (lr) R15 (pc) R10 R11 R12 R13 (sp) R14 (lr) User mode R0- R7,R15 e CPSR R8 R9 R13 (sp) R14 (lr) User mode R0- R12,R15 e CPSR R13 (sp) R14 (lr) User mode R0- R12,R15 e CPSR R13 (sp) R14 (lr) User mode R0- R12,R15 e CPSR R13 (sp) R14 (lr) User mode R0- R12,R15 e CPSR CPSR SPSR SPSR SPSR SPSR SPSR User and System
FIQ IRQ ABT SVC UND
R13 (sp) R14 (lr) User mode R0- R12,R15 e CPSR SPSR MON R13 (sp) User mode R0- R12,R15 e CPSR SPSR HYP
Figura 3.2: Conjunto dos registos ARM
Contudo, o uso dos registos depende do modo como o software está a ser processado e se o modo permite o seu uso. Por outras palavras, certos registos estão alocados fisicamente em diferente áreas, sendo eles restritos ao modo a que pertencem, não permitindo que sejam visíveis a outros modos. A figura 3.2 mostra todos os registos existentes e separados pelos seus modos. Como é possível ver, grande parte dos primeiros registos (r0-r12) e r15 são partilhados pelos vários modos, com exceção do modo FIQ, onde só é partilhado do r0-r7 e o r15. Por outro lado, os registos que estão de cor cinza, são os registos únicos e só visíveis ao próprio modo.
Os registos CPSR e SPSR presentes na figura 3.2, são os registos de acesso ao estado do processador (PSR), denominados de Current Program Status Register (CPSR) e de Save Program Status Register (SPSR). O CPSR é um registo que apresenta os valores do PSR durante a execução do processo, enquanto o SPSR é
um registo que consiste no valor do PSR que será carregado quando existir uma troca de modos do processador. O PSR (program status register ) está dividido em quatro campos de oito bits: flags, estado, extensão e controlo. No atual design, o campo da extensão e do estado são reservados para uso futuro, enquanto que o campo das flags destina-se às condition flags (negative, carry, zero, overflow), e o campo de controlo contém o modo do processador, o estado e os bits de máscara de interrupções (figura 3.3), [7][25][26]. N Z C V I F T MODE 31 30 29 28 7 6 5 4 0 Bit Campo Função
Flags Estado Extenção Controlo
Condição de Flags Máscaras de Interrupções Estado Thumb Modo do Processador
Figura 3.3: Program status register (PSR).
Generic Interrupt Controller
A arquitetura do GIC (Generic Interrupt Controller ) foi desenhada com o pro- pósito de cumprir com os requisitos propostos pelos perfis das arquitetura ARM A e R . Ele define quais os recursos de hardware que gerem as interrupções num sistema single ou multicore [27]. Os seus registos mapeados em memória pos- sibilitam a configuração das fontes de interrupções e dos seus comportamentos: ativar/desativar interrupções e atribuição de prioridades (em hardware).
A sua arquitetura apresenta-se em dois grandes blocos funcionais:
• Distributor: Possui os registos que controla as prioridades individuais de cada interrupção e decide, num sistema multicore, para qual das CPU Inter-
face deve ser enviado a interrupção.
• CPU Interface: Existe uma CPU Interface para cada core e é responsável por receber as suas interrupções. Os seus registos são acessíveis por software e permitem identificar e controlar o estado das interrupções recebidas.
As fontes de interrupções são identificadas por um ID único, onde cada core pode aceder até a um máximo de 1020 interrupções. As interrupções são divididas em três tipos:
• SGI (Software Generated Interrupt:) São interrupções geradas por
software. Na generalidade são utilizadas para a comunicação entre cores,
onde podem ser destinadas para qualquer core ou grupo específico. Os IDs reservados para estas interrupções vão desde 0 até 15.
• PPI (Private Peripheral Interrupt:) São interrupções geradas por pe- riféricos privados do core. Os IDs reservados para estas interrupções vão desde 16 até 31.
• SPI (Shared Peripheral Interrupt:) São interrupções geradas por peri- féricos partilhados por todos o cores presentes no hardware. Os IDs reserva- dos para estas interruções vão desde 32 até 1019.
3.2
Ambiente de Desenvolvimento
Este subcapítulo tem como finalidade descrever as ferramentas utilizadas para o desenvolvimento do software. Inicialmente são abordadas as ferramentas de edição, compilação e emulação, e seguidamente, são abordadas abordado as ferramentas de simulação física (plataforma e o seu SoC).
3.2.1
Xillinx ISE Desing Suite
A Xilinx oferece um grande conjunto de ferramentas de desenvolvimento desig- nado de Integrated Software Environment (ISE) Design Suite. Este conjunto está dividido em 3 edições: Logic Edition, Embedded Edition e DSP Edition. Neste sentido, só é abordada a edição (Embedded Edition) que foi utilizada para a reali- zação desta dissertação. Nesta edição, é adicionado ao EDK todas as ferramentas e capacidades da Logic Edition.
Embedded Development Kit (EDK)
O Embedded Development Kit (EDK) é um ambiente de desenvolvimento para de sistemas embebidos. Este integra as seguintes ferramentas:
• Xilinx Plataform Studio (XPS), para o desenvolvimento e configura- ção de componentes de hardware presentes numa arquitetura de um sistema embebido;
• Software Development Kit (SDK), é uma ambiente de desenvolvimento integrado para complemento do XPS para criação e verificação de aplicações embebidas. Baseado na framework Eclipse open-source que utiliza o compi- lador e depurador GNU C/C++, [31][32][33].
3.2.2
ARM Fast Models
Uma das formas para validar a aplicação criada proveniente do SDK, é a utiliza- ção da framework Fast Models. O Fast Models é um ambiente de fácil criação de modelos virtuais de plataformas e que permite rápidas simulações. As platafor- mas geradas são equipadas com o Cycle Accurate Debug Interface (CADI) onde disponibiliza uma API que permite às plataformas serem executadas de forma independente.
Os Versatile Express (VE) Fixed Virtual Platforms (FVP) são executáveis for- necidos pela ARM de modelos de plataformas virtuais estáticas, ou seja, não é possível personalizá-las. Estas contêm virtualmente a implementação de mother-
board, daughterboards cada uma com um processador ARM e estão associados por
inter-conectores como pode ser visto na figura 3.4.
System Canvas
O System Canvas é um GUI (Graphical User Interface) que permite a representa- ção gráfica do modelo, visualizando os componentes do sistema, portas externas e internos, conexões com esses portos. A natureza gráfica do System Canvas é uma ajuda para uma criação rápida e configuração de componentes ou sistemas que consistem em múltiplos componentes. Além disso, a partir da API fornecida pelo CADI do modelo, o System Canvas permite fazer o debug passo a passo, dando
Figura 3.4: Diagrama de blocos do modelo FVP_VE Cortex-A9x2
uma representação gráfica de todos os valores dos registos presentes no modelo [34][35][36].