Linux e zephyr conversando no mesmo SoC

Linux e Zephyr "conversando"
no mesmo SoC
Diego Sueiro, Sepura / Embarcados
www.embarcados.com.br
Webinar Embarcados Experience

Agenda
Aplicações Real-Time com Processadores Híbridos
Introdução ao Zephyr
Introdução ao OpenAMP
Introdução ao RPMsg
Introdução ao RPMsg-lite
Habilitando o RPMsg no Linux
Habilitando o RPMsg-lite no Zephyr
Setup de comunicação entre o Linux e Zephyr
Demo
Trabalhos Futuros

Preâmbulo
● Processador NXP i.MX7 é a plataforma de hardware de referência;
● O OpenAMP “full” não será utilizado nessa apresentação;
● Até o momento no Zephyr, apenas uma família de SoC (LPC54114) suporta a
implementação “full” do OpenAMP para comunicação entre cores Cortex M0 e M4;
● Este trabalho não está no mainline do Linux kernel e Zephyr ainda, mas é open source ;-)

Aplicações Real-Time com HMP
● a.k.a: AMP (Asymmetric Multiprocessing);
● No mesmo SoC temos diferentes combinações e arquiteturas de CPU:
○ Core de aplicação, e.x.: ARM Cortex A9;
○ Digital Signal Processing, e.x.: Texas Instruments DSP C6000;
○ Poder de Processamento, e.x.: Xilinx FPGA Artix-7;
○ Low Power e performance Real-time: ARM Cortex M4;
○ ...
● Algumas aplicações podem requerer:
○ Performance real-time;
○ Otimização de performance;
○ Baixo consumo de energia;
○ Boot rápido;
○ Integridade do sistema;
○ Segurança do sistemas;
○ Soluções de software certificadas;
○ Reuso de software legado.

● Linux kernel (e.x. PREEMPT_RT) pode alcançar alguns desses requisitos mas
otimizar, customizar, estender, debugar, manter e atualizar tem alto custo em termos
de conhecimento, tempo e dinheiro;
● O HMP é uma possível solução que pode trazer:
○ Isolamento e particionamento de domínios de software;
○ HUB de sensores e atuadores;
○ Redução de custo da BOM.
● Mas o HMP tem alguns desafios:
○ SIncronização e Comunicação intra-processadores;
○ Gerenciamento de energia eficiente;
○ Isolamento e proteção de recursos compartilhados;
○ Gerenciamento de cache coherency.
● Fabricante de SoC vêm lançando uma grande variedade de HMPs para diferentes
mercados.

Como um HMP se parece:

Como um HMP se parece:
OS 1
App Core App Core
Cache Cache
RAM
RTOS
RT Core
RAM
AMP/Heterogêneo
SMP/Homogêneo
App Core RT Core
Bus Fabric
Slave
Device
Slave
Device
Topologia de Barramento Compartilhado
IRQ
App Core RT Core
Interrupções de Periféricos compartilhadas

Como um HMP se parece: e.x. NXP i.MX7S

● Gerenciado pela The Linux Foundation: www.zephyrproject.org;
● Licença Apache 2.0;
● Sistema Operacional de Tempo Real (RTOS) para microcontroladores com recursos
de memória e processamento limitados;
● Suporta arquiteturas como ARM Cortex-M, Intel x86, ARC, NIOS II, Tensilica Xtensa e
RISC-V 32;
● Mais 100 placas suportadas (e.x: Arduino 101, Due, Zero, NXP FRDM-K64F, ST
Nucleo, SoM Colibri i.MX7 etc);
● Emulação com Qemu para x86, ARM Cortex M3, NIOS II, Xtensa e RISC-V 32;
● Extensa documentação;
● Suportado por empresas como: Intel, NXP, Nordic, TI, Linaro;

● Github: github.com/zephyrproject-rtos/zephyr;
● Compatível com MISRA-C 2012 (em progresso);
● Releases a cada 3 meses;
● Desenvolvimento em ambientes Linux, Windows e macOS;
● Prove um SDK com toolchain para compilação;
● Combinação de Kconfig com CMake para configuração e compilação;
● Integração com pyOCD, gdb e SEGGER SystemView para debugging e tracing;
● Integração com Eclipse;
● Fácil integração com códigos fonte externos;

● Listas de discussão: lists.zephyrproject.org/g/main/subgroups;
● Canal IRC: irc.freenode.net/zephyrproject;
● Slack: zephyrproject.slack.com;
● Issues: github.com/zephyrproject-rtos/zephyr/issues;
● Roadmap: github.com/zephyrproject-rtos/zephyr/projects/9;

Principais Características:
● Serviços do kernel:
○ Multitarefa: API compatível com pthreads do POSIX;
○ Interrupções;
○ Alocação de Memória;
○ Sincronização e troca de dados entre tarefas;
○ Gerenciamento de energia.
● Múltiplos algoritmos de escalonamento:
○ Preemptivo e cooperativo;
○ EDF;
○ ISRs com “bottom half” ou “tasklet”;
○ Proteção contra inversão de prioridade.
● Proteção de Memória;
● Trusted Execution para ARMv8-M (em progresso);

Principais Características (cont):
● Stack para USB Device;
● Suporte de rede nativo;
● Bluetooth Low Energy 5.0;
● Sistema de arquivos FAT e NFFS;
● Device tree para descrição e configuração do hardware;
● Flexível sistema de logging;
● Shell com comandos pré-definidos e dinâmicos;
● Compatível com o bootloader MCUboot;
● Framework para updates;
● Opção de uso de API compatível com CMSIS RTOS v1.

Arquitetura

OpenAMP: padrão controlado pela MCA (The Multicore Association) implementado no
mainline do Linux kernel e Zephyr:
● Operações de ciclo de vida via Remoteproc (Remote Processor): Framework que
permite que um mestre controle/gerencie processadores remotos (power on/off, reset,
carregamento de firmware);
● Mensagens via RPMsg (Remote Processor Messaging): Framework que provê
comunicação intra-processadores (IPC) usando VirtIO (componente padrão de
virtualização no Linux) para gerenciamento de memória compartilhada quando
enviando/recebendo dados do/para mestre/remoto;
● Operações de Proxy: Acesso remoto a serviços de sistema, como sistema de arquivos
(“_open", "_close", "_read", and "_write"). Uma interface transparente a contextos
remotos para aplicações em user space no Linux rodando no processador mestre;

● Gerenciador de recursos, rproc_srm, composto por recursos de sistema
compartilhados entre cores mestre e remoto como clocks, energia, reset e memória, e
recursos de periféricos designados e controlados pelos cores mestre e remoto sem
conflito entre eles. Proposto pela ST e ainda em discussão.
● Depende da libmetal atuando como camada de abstração de hardware e de ambiente
do Sistema Operacional;
● Trabalho em progresso para desacoplar o Remoteproc e RPMsg permitindo que
possam ser usados independentemente;

Remoteproc: a.k.a. Componente LCM (Life Cycle Management)

Remoteproc:
● Restrição: Criação de dispositivos VirtIO em tempo de execução para o RPMsg não
está implementado para os dispositivos i.MX no driver do remoteproc usando os dados
da tabela de recursos;
● Em contrapartida, NXP implementou a criação de dispositivos VirtIO devices, rings e
queues usando dados do device tree diretamente no driver do RPMsg.

Camadas do Protocolo RPMsg:

Camada Física do RPMsg – Memória Compartilhada:
NXP i.MX7S/D/ULP and i.MX6SX

Camada MAC do RPMsg - VirtIO:
● Usado para transferir os dados do usuário em memória compartilhada através da
técnica de single-writer single-reader com buffer circular;
● 2 ring buffers (Used/Available) para cada direção (tx,rx);
● Ring buffers contém o endereço da memória compartilhada que contém os dados do
RPMsg;
● Implementação do RPMsg usando Virtio na wiki do OpenAMP;
● Mais detalhes sobre as estruturas do VirtIO e vrings na wiki do OpenAMP.

Camada MAC do RPMsg - VirtIO:
● Apresentações relacionadas com mais detalhes:
○ Implementation details of RPMsg on Linux: Asymmetric Multiprocessing and
Embedded Linux - Marek Novak & Dušan Červenka, NXP Semiconductor - ELCE
2017 - video, slides;
○ An Introduction to Asymmetric Multiprocessing: When this Architecture can be a
Game Changer and How to Survive It - Nicola La Gloria & Laura Nao, Kynetics -
ELC 2018 - video, slides.

Camada de Transporte do RPMsg:
● A mensagem RPMsg está localizada na memória compartilhada e seu endereço é
armazenado no descritor do vring;

Camada de Transporte do RPMsg:

RPMsg-lite: https://github.com/NXPmicro/rpmsg-lite
● Criado e mantido por Marek Novak;
● Simplificação da extensa API implementada pelo OpenAMP;
● Footprint menor comparado a implementação do RPMsg no OpenAMP;
● Opção de uso de API estática (sem mallocs) para redução de tamanho de código;
● Desacoplado do remoteproc;
● Provê funções de no-copy-send no-copy-receive que elimina o custo de cópia de
dados de/para aplicação para/de o buffer do RPMsg;

RPMsg-lite:
● 2 sub-componente opcionais:
○ Queue: API de recebimento bloqueante que é comumente encontrada em ambientes de
tempo real e requer uma implementação na camada de adaptação do ambiente;
○ Name Service: que está presente na implementação do RPMsg no Linux kernel. Permite que
ambos os nós enviem anúncios sobre o canal de comunicação.

RPMsg-lite: Arquitetura

RPMsg-lite: Implementação

Código fonte do Linux kernel da NXP para o SoC i.MX7 no branch 4.9-1.0.x-imx:
● Kconfis automaticamente selecionados quando CONFIG_SOC_IMX7 é processado:
○ CONFIG_HAVE_IMX_MU=y
○ CONFIG_HAVE_IMX_RPMSG=y
○ CONFIG_RPMSG=y
○ CONFIG_RPMSG_VIRTIO=y
○ CONFIG_IMX_RPMSG_PINGPONG=m
○ CONFIG_IMX_RPMSG_TTY=m
● Driver do i.MX MU em: arch/arm/mach-imx/mu.c
● Driver do i.MX RPMsg em: drivers/rpmsg/imx_rpmsg.c
● Driver do i.MX RPMsg tty em: drivers/rpmsg/imx_rpmsg_tty.c

Código fonte do Linux kernel da NXP para o SoC i.MX7 no branch 4.9-1.0.x-imx:
● Nós do device tree:
arch/arm/boot/dts/imx7s.dtsi:
mu: mu@30aa0000 {
compatible = "fsl,imx7d-mu", "fsl,imx6sx-mu";
reg = <0x30aa0000 0x10000>;
interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX7D_MU_ROOT_CLK>;
clock-names = "mu";
status = "okay";
};
rpmsg: rpmsg{
compatible = "fsl,imx7d-rpmsg";
status = "disabled";
};

NXP Linux kernel source tree in 4.9-1.0.x-imx branch for i.MX7 Soc:
● Nós do device tree (cont):
arch/arm/boot/dts/imx7s-warp.dts:
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;
rpmsg_reserved: rpmsg@8fff0000 {
No-map;
reg = <0x8fff0000 0x10000>;
};
};
&rpmsg {
vdev-nums = <1>;
reg = <0x8fff0000 0x10000>;
status = "okay";
};
arch/arm/boot/dts/imx7s-warp.dts (cont):
&uart2 {
status = "disabled";
};

● Driver do i.MX MU, PR 8527, ainda em reviso no Zephyr:
○ Fork do Zephyr criado em github.com/diegosueiro/zephyr/tree/rpmsglite-imx:
■ Incluí o driver do i.MX MU, mudanças no soc e board para suportar o i.MX7 e WaRP7
● Tentativa de incluir o RPMsg-lite no Zephyr: PRs 6153 e 5960. Mas o TSC do Zephyr
escolheu suportar apenas a implementação do OpenAMP como o mecanismo de IPC
padrão;
● Fork do RPMsg-lite para suporte ao Zephyr em
github.com/diegosueiro/rpmsg-lite/tree/zephyr-support:
○ Adicionado suporte aos processadores i.MX7;
○ Adicionada aplicação de exemplo remote echo.

Driver do i.MX MU no Zephyr
● Impletmenta API definida em: zephyr/include/ipm.h
● Código do driver em: zephyr/drivers/ipm/ipm_imx.c
○ Opção para configurar o tamanho do dado: 4, 8 ou 16 bytes;
○ Alinhado com o Linux, RPMsg usa 4 bytes (índice 1 do registrador de dado do MU) para
controle de direção da mensagem (bit 16).
● Device tree define o mapa dos registradores, número da interrupção e as permissões
do RDC
○ Declarado em zephyr/dts/bindings/arm/nxp,imx-mu.yaml
○ Definido em zephyr/dts/arm/nxp/nxp_imx7d_m4.dtsi
○ Habilitado em zephyr/boards/arm/warp7_m4/warp7_m4.dts

Camada de portabilidade do ambiente do Zephyr para o RPMsg-lite:
● API de ambiente definida em: rpmsg-lite/lib/include/rpmsg_env.h;
● Implementada em:
rpmsg-lite/lib/rpmsg_lite/porting/environment/rpmsg_env_zephyr.c;
Camada de portabilidade da plataforma i.MX7 do Zephyr para o RPMsg-lite:
● Definições globais e da API em:
rpmsg-lite/lib/include/platform/imx7d_m4/rpmsg_platform.h;
● Implementada em:
rpmsg-lite/lib/rpmsg_lite/porting/platform/imx7d_m4/rpmsg_platform_zephyr_ipm.c;

Compilação do Zephyr com RPMsg-lite
● Necessita a seleção do subsistema Inter-processor Mailbox (CONFIG_IPM) e do driver
baixo nível (e.x. CONFIG_IPM_IMX);
● Seleção do RPMsg-lite: CONFIG_IPC_RPMSG_LITE;
● Compilado juntamente com a aplicação usando Kconfig, prj.conf e
CMakeLists.txt:
rpmsg-lite/zephyr/samples/subsys/ipc/rpmsg_lite/remote_echo/
├── CMakeLists.txt
├── Kconfig
├── prj.conf
├── prj_warp7_m4.conf
├── sample.yaml
└── src
└── main_remote_echo.c

Setup de comunicação entre o Linux e Zephyr
U-boot carrega e inicializa o
Zephyr e Linux Kernel
Driver RPMsg cria as
virtqueues e endpoint locais
Aplicação RPMsg cria as
virtqueues
Driver RPMsg espera o
anúncio do name service
Espera pelo link estar ativo
Aplicação cria o endpoint e
envia o anúncio do name
service
Notifica o core remoto
Envio/Recebimento de
mensagens
Envio/Recebimento de
mensagens
Linux - Mestre Zephyr - Remoto

WaRP7
RPMsg
Demo
● Diagrama Simplificado:
PC Host
Mestre/Linux
(A7)
Remoto/Zephyr
(M4)
MU
Memória
Compart.
UART 1
UART 2

Demo
● Fontes do lado M4:
○ Zephyr: github.com/diegosueiro/zephyr/tree/rpmsglite-imx
○ RPMsg-lite: github.com/diegosueiro/rpmsg-lite/tree/zephyr-support
Fonte do Demo: rpmsg-lite/zephyr/samples/subsys/ipc/rpmsg_lite/remote_echo
● Fontes do lado A7:
○ Distribuição Linux (baseado no Yocto): github.com/diegosueiro/meta-ipc/tree/sumo
○ Linux Kernel: github.com/diegosueiro/linux-fslc/tree/4.9-1.0.x-imx
○ U-boot: github.com/diegosueiro/u-boot-fslc/commits/2018.07+fslc
● Instruções de compilação e gravação:
○ Distro Linux: github.com/diegosueiro/meta-ipc/wiki/Yocto-Distribution-Build-and-Flash-Instructions
○ Imagem do Zephyr: github.com/diegosueiro/rpmsg-lite/wiki

Demo
RPMsg-lite remote echo sample
rpmsg-lite/zephyr/samples/subsys/ipc/rpmsg_lite/remote_echo/src/main_remote_echo.c:
<...>
#define APP_TASK_STACK_SIZE (1024)
#define LOCAL_EPT_ADDR (30)
#ifdef CONFIG_SOC_SERIES_IMX7_M4
/* Settings bellow aligned with Linux i.MX RPMsg side */
#define RPMSG_MAX_SIZE 256
#define RPMSG_LITE_LINK_ID (RL_PLATFORM_IMX7D_M4_LINK_ID)
#define RPMSG_LITE_SHMEM_BASE (0x8FFF0000)
#define RPMSG_LITE_NS_USED (1)
#define RPMSG_LITE_NS_ANNOUNCE_STRING "rpmsg-openamp-demo-channel"
#endif

Demo
Exemplo RPMsg-lite remote echo
rpmsg-lite/zephyr/samples/subsys/ipc/rpmsg_lite/remote_echo/src/main_remote_echo.c (cont):
<...>
void app_task(void *arg1, void *arg2, void *arg3)
{
<...>
char buf[RPMSG_MAX_SIZE];
char rsp[RPMSG_MAX_SIZE];
int len;
volatile unsigned long remote_addr;
struct rpmsg_lite_endpoint *volatile rl_endpoint;
volatile rpmsg_queue_handle rl_queue;
struct rpmsg_lite_instance *volatile rl_instance;
#ifdef RPMSG_LITE_NS_USED
volatile rpmsg_ns_handle ns_handle;
#endif /*RPMSG_LITE_NS_USED*/

Demo
/* Initialize RPMsg Core and create virtqueues */
rl_instance = rpmsg_lite_remote_init((void *)RPMSG_LITE_SHMEM_BASE,
RPMSG_LITE_LINK_ID, RL_NO_FLAGS);
printk("Waiting for Master.rn");
while (!rpmsg_lite_is_link_up(rl_instance)){}
rl_queue = rpmsg_queue_create(rl_instance);
rl_endpoint = rpmsg_lite_create_ept(rl_instance, LOCAL_EPT_ADDR, rpmsg_queue_rx_cb,
rl_queue);
#ifdef RPMSG_LITE_NS_USED
ns_handle = rpmsg_ns_bind(rl_instance, app_nameservice_isr_cb, NULL);
rpmsg_ns_announce(rl_instance, rl_endpoint, RPMSG_LITE_NS_ANNOUNCE_STRING,
RL_NS_CREATE);
printk("Nameservice announce sent.rn");
#endif /*RPMSG_LITE_NS_USED*/

Demo
while(1)
{
rpmsg_queue_recv(rl_instance, rl_queue, (unsigned long*)&remote_addr,
(char*)buf, sizeof(buf), &recved, RL_BLOCK);
printk("nFrom endpoint 0x%X received %d bytes:n",
(unsigned int)remote_addr, recved);
buf[recved] = '0';
printk("%sn",buf);
/* Format the echo response */
len = snprintf(rsp, sizeof(rsp), "echo: %srn", buf);
printk("Sending %d bytes to endpoint 0x%X:n", len, (int)remote_addr);
printk("%s",rsp);
rpmsg_lite_send(rl_instance, rl_endpoint, remote_addr, rsp, len,
RL_BLOCK);
}
}
<...>

Trabalhos Futuros
● Precisam ser incluídos no mainline
○ Linux kernel:
■ Driver remoteproc do i.MX criando os VirtIO queues para RPMsg com os dados da
tabela de recursos do firmware remote;
■ Driver i.MX RPMsg - patchwork;
○ OpenAMP:
■ Desacoplamento do Remoteproc e RPMsg - issue.
○ Zephyr:
■ Driver i.MX MU - issue;
■ Uso do RPMsg-lite como alternativa ao OpenAMP.
● Medições de latência na transmissão das mensagens variando:
○ Tipo de memória compartilhada (interna e externa)
○ Alocação estática de dinâmica de memória
○ Mecanismos de copy e no-copy
○ Tamanho do buffer da mensagem
○ Número de buffers

Referências
● Asymmetric Multiprocessing and Embedded Linux - Marek Novak & Dušan Červenka,
NXP Semiconductor - ELCE 2017 - video, slides.
● An Introduction to Asymmetric Multiprocessing: When this Architecture can be a Game
Changer and How to Survive It - Nicola La Gloria & Laura Nao, Kynetics - ELC 2018 -
video, slides.
● Heterogeneous Software Architecture with OpenAMP - Shaun Purvis, Xilinx - ESC
Boston 2017 - Slides.
● An Introduction to Heterogeneous Multiprocessing (ARM® Cortex®-A + CortexM) on
Next-Generation i.MX Applications Processors - Glen Wienecke, NXP - FTF 2014 -
Slides.
● i.MX 7Solo Applications Processor Reference Manual - IMX7SRM.

Referências
● Wiki do OpenAMP no Github:
○ OpenAMP Components and Capabilities
○ OpenAMP Life Cycle Management
○ RPMsg Messaging Protocol
○ OpenAMP RPMsg Virtio Implementation

OBRIGADO !!!!
Perguntas?
Diego Sueiro, Embarcados
www.embarcados.com.br
diego.sueiro@embarcados.com.br
linkedin.com/in/diegosueiro/
Webinar Embarcados Experience

Linux e zephyr conversando no mesmo SoC

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Linux e zephyr conversando no mesmo SoC

Semelhante a Linux e zephyr conversando no mesmo SoC (20)

Mais de Embarcados

Mais de Embarcados (20)

Linux e zephyr conversando no mesmo SoC