Como usar o PetaLinux: do XSA ao seu primeiro aplicativo Linux no Zynq

Se você está tendo dificuldades com o PetaLinux, não se preocupe: você não está sozinho. curva de aprendizado íngremeMas existe um caminho claro para entender como o Vivado, o PetaLinux e o Vitis funcionam juntos e qual o papel de cada componente. Aqui você encontrará uma explicação prática e organizada para ajudá-lo a ir de um projeto do Vivado à execução de sua primeira aplicação no Vitis. Linux sobre Zynq ou Zynq UltraScale+ sem morrer na tentativa.

Muitas pessoas se perguntam se é possível "viver" sozinho dentro de Vitis. Você precisa do PetaLinux para o kernel, a árvore de dispositivos e o sistema de arquivos raiz.O fluxo de trabalho típico que você verá em sistemas reais é: gerar o arquivo .xsa no Vivado, criar e configurar o projeto PetaLinux (às vezes a partir de um BSP), compilar e empacotar a imagem (WIC para SD) e, em seguida, exportar o diretório raiz do sistema para desenvolver o aplicativo no Vitis ou com uma cadeia de ferramentas externa. Mais adiante, explicarei alternativas, dicas para evitar reconstruções intermináveis ​​e o que fazer com ferramentas como o FPGA Manager ou o TCF Agent.

O que é PetaLinux e o que ele inclui por padrão?

O PetaLinux é uma distribuição de referência da AMD projetada para seus SoCs e MPSoCs, oferecendo um ambiente Linux pronto para personalização. carregadores de Bota e kernel otimizadoInclui bibliotecas e utilitários, suporte a C/C++ e ferramentas de depuração. Além disso, oferece opções de multithreading, suporte a FPU e um servidor de administração baseado na web para facilitar a configuração de rede e firmware.

Os BSPs oficiais geralmente vêm com imagens de inicialização e configuração pré-configuradas. implantar e inicializar os binários em Hardwares real ou em QEMUO emulador de sistema completo que acompanha o PetaLinux acelera os testes iniciais e é ideal para verificar se o projeto inicia corretamente antes de se aprofundar nos detalhes. Aplicativos o Drivers.

Fluxos de trabalho recomendados de hardware e software

Em ambientes profissionais, são utilizadas duas variantes do fluxo de trabalho Linux: uma focada na linha de... comandos da PetaLinux, e outra que integra o Vitis para desenvolvimento de aplicações. Gerando o arquivo .xsa e, se aplicável, o fluxo de bits.

Posso fazer tudo no Vitis? No Linux, não. Vitis é ótimo para criar plataformas. Quando você precisa de um kernel, árvore de dispositivos e sistema de arquivos raiz personalizados, a abordagem usual é: usar o PetaLinux para construir o sistema e exportar o SDK/sysroot; e utilizar o Vitis ou uma cadeia de ferramentas externa para compilar e depurar sua aplicação.

Do XSA ao sistema de inicialização

O itinerário mínimo viável geralmente se parece com isto: Você gera o arquivo .xsa no Vivado.Você cria o projeto com o petalinux-create (ou a partir de um BSP), atualiza o hardware no PetaLinux com o arquivo .xsa e ajusta a configuração (kernel, device tree e rootfs). Em seguida, compila, empacota no formato .wic e grava no cartão SD.

Com o sistema em funcionamento, é hora de fazer a inscrição. Exporte o sysroot/SDK do PetaLinux No Vitis, você cria uma plataforma a partir do arquivo .xsa. A partir daí, você gera seu projeto de aplicativo C/C++ apontando para o sysroot para vincular corretamente às bibliotecas do rootfs e executa o aplicativo no destino com o tcf-agent, gdbserver ou seu método preferido.

Um pequeno aviso da vida real: Versões Vivado/Vitis/PetaLinux Eles têm suas peculiaridades. Por exemplo, foi relatado um problema no Vitis Unified 2023.2 que impede a conexão com o tcf-agent, e a solução rápida foi atualizar para a versão 2024.1. Sempre verifique as notas de versão e, se possível, congele o conjunto de ferramentas durante um projeto.

Projeto de hardware em Vivado (Zynq-7000 e Zynq UltraScale+)

Sua base tecnológica está no Block Design do Vivado. Adicione o bloco “Sistema de Processamento ZYNQ7” (ou seu equivalente em ZynqMP) e execute o Run Block Automation para conectar a DRAM e o clock. A partir daí, ajuste o que for necessário.

• Habilitar interrupções externas: Na personalização do PS, ative as interrupções PS-PL e as interrupções compartilhadas se você planeja compartilhar linhas de IRQ entre periféricos PL.
• Sincronizar os clocks: uma prática comum é conectar FCLK_CLK0 à porta M_AXI_GP0_ACLK para que o clock do barramento AXI seja consistente com o clock do PS.

Com os IPs PL, conte com a automação. Executar Automação de Conexão Ele fornece interconexões e arbitragem AXI, mas observe: ele não conecta interrupções nem todas as árvores de clock. Para IRQs, ele usa um bloco de concatenação e direciona sua saída para o PS.

• Conecte cada linha IRQ dos seus IPs periféricos ao bloco Concat.
• Conecte a saída Concat à entrada de interrupção PS.

Se você precisar de memória rápida na PL, adicione BRAM. Controlador BRAM e gerador de memória em bloco integrados, define o número de portas, a largura e a capacidade e, muito importante, verifica seu mapeamento no Editor de Endereços.

• Verifique e ajuste o mapa de endereços: não pode haver sobreposição de intervalos; caso haja, o Vivado destacará o conflito em vermelho.
• Considere outros processadores mestre (por exemplo, um coprocessador na PL). A atribuição de endereços é obrigatória para evitar falhas na síntese.

Para finalizar o projeto, crie o wrapper HDL para o arquivo .bd, sintetize-o e implemente-o. Geração de fluxo de bits Pode demorar bastante, e quando terminar, exporta o hardware, incluindo o bit, caso você queira programar a PL desde a inicialização.

Algumas considerações úteis: Exponha os sinais PS à PL com EMIO. Para GPIO ou I2C, isso é muito prático se, por exemplo, você for usar um shield PYNQ. Tenha cuidado com periféricos integrados: eles geralmente são conectados a pinos fixos no dispositivo e nem sempre é possível substituí-los por IPs da malha sem alterar as conexões. Se a implementação falhar, verifique as restrições (XDC) e as atribuições.

Árvore de dispositivos e mapeamento de hardware

A pergunta de um milhão de dólares: até que ponto o Linux abstrai você? Árvore de Dispositivos Esta seção descreve os endereços dos dispositivos, as IRQs e as compatibilidades. Este mapeamento não é "dinâmico" na inicialização, a menos que você use overlays; normalmente é estático e deriva do Editor de Endereços do Vivado e do DTS gerado pelo PetaLinux.

A parte de controle (registros) e a parte de dados (por exemplo, acessos DMA) devem ser separadas conceitualmente e fisicamente. intervalos “reg” e linhas de interrupçãoO driver (ou UIO) usará essas informações para mapear a memória e a lógica de interrupção. O tamanho e o alinhamento dos intervalos devem corresponder ao que você definiu no Vivado.

Se você compilar com PetaLinux, os fragmentos DTS geralmente são gerados automaticamente a partir do arquivo .xsa. Atualize o arquivo .xsa Ao alterar o hardware (novos IPs ou endereços), é necessário recompilar pelo menos a árvore de dispositivos e o kernel. O arquivo rootfs nem sempre precisa ser alterado e, portanto, o arquivo sysroot ainda pode ser usado se as bibliotecas do usuário não tiverem sido modificadas.

Opções para acessar hardware a partir de C/C++

Não existe uma única maneira; escolha de acordo com o estágio do seu projeto e o esforço que deseja dedicar aos motoristas. / dev / mem para mapeamento MMIO, mas não é recomendado em produção devido a questões de segurança, portabilidade e interrupções.

Alternativa intermediária: UIO (E/S do espaço do usuário) Permite mapear regiões IP no espaço do usuário e gerenciar interrupções com select/poll. Requer a adição dos nós UIO à árvore de dispositivos, mas evita a necessidade de escrever um driver completo.

A opção profissional é criar um driver de personagem ou um driver de plataforma para sua propriedade intelectual. motorista de personagem Você obtém controle preciso sobre DMA, IRQ, energia e uma interface estável em /dev, além de melhor integração com o ecossistema do kernel. Se seu IP usa AXI-DMA ou frameworks padrão, utilize os drivers existentes.

Em relação ao conjunto de ferramentas: você pode usar o Vitis ou compilar com o SDK exportado pelo PetaLinux. petalinux-build –sdk e vincule seu projeto a esse sysroot para garantir que você esteja vinculando às mesmas bibliotecas do rootfs do alvo. O Vitis simplifica a criação do sistema a partir do arquivo .xsa e o início da depuração remota.

Depuração e execução remota

Para executar o aplicativo no dispositivo de destino, você tem várias opções. agente tcf Funciona bem para iniciar e depurar a partir do Vitis, desde que o agente esteja instalado no sistema de arquivos raiz (adicione-o com o comando `petalinux-config -c rootfs`) e não haja conflito de versões.

Alternativamente, servidor gdb É simples e robusto. Você copia seu binário para o destino, executa `gdbserver :port ./yourapp` e se conecta a partir do host usando o gdb multiarquitetura. Muitas equipes combinam o gdbserver com o VS Code Remote ou com scripts do Python.

Para ir além do printf, explore as técnicas de criação de perfil e rastreamento do kernel. Criação de perfis e rastreamentos do kernel A comunidade Zynq compartilhou as melhores práticas para uma depuração eficiente que lhe poupará tempo quando os erros não forem óbvios.

Atualize o hardware sem precisar reconstruir tudo.

É normal pensar que uma mudança na Política Monetária nos obriga a "refazer o mundo", mas há espaço para manobras. interfaces visíveis para o kernel (Endereços, IRQs, compatibilidade), o rootfs e o sysroot geralmente permanecem ativos. Nesse caso, você pode reprogramar o PL e estará tudo pronto.

Para carregar fluxos de bits dinamicamente, o Linux oferece o framework FPGA Manager. fpgautil ou a interface sysfs/configfs para programar a PL a partir do espaço do usuário. Isso evita a regeneração de imagens inteiras e acelera as iterações lógicas.

Se a alteração de hardware introduzir novos IPs ou modificar intervalos/IRQs, então sim: reconstrói a árvore de dispositivos e regenera o BOOT.BIN/image. Mesmo assim, aproveita o cache sstate para que a compilação não repita tarefas já concluídas.

Dicas para acelerar construções e obter estabilidade

O melhor remédio contra a ideia de "reconstruir tudo" é prestígio e ordem. Espelho estatal e um diretório de Download Compartilhado para Yocto/PetaLinux; isso evita a recompilação de pacotes que não foram alterados. Isso faz uma grande diferença em sistemas grandes e ambientes internos.

Garantir a reprodutibilidade: versões âncora do Vivado/Vitis/PetaLinux E documente as correções. Se possível, não altere as versões no meio do projeto, a menos que seja para corrigir um bug crítico confirmado. E antes de migrar para uma nova versão, teste-a em uma branch.

QEMU é seu aliado. QEMU Inicialize a imagem no QEMU para verificar se o sistema de arquivos raiz e o kernel estão funcionando corretamente sem precisar gravar a imagem no cartão SD. Isso não substitui o hardware físico, mas economiza ciclos de inicialização.

Depois de tudo isso, a imagem já não parece um quebra-cabeça. Distribuição de referência completa (bootloader, kernel, rootfs e ferramentas)O Vivado define o mapa físico e o Vitis acelera o ciclo de desenvolvimento e depuração de aplicativos. A partir daí, o uso do Device Tree, da UIO ou dos drivers faz toda a diferença entre um simples "Olá, Mundo!" e um aplicativo robusto que utiliza seu hardware de forma integrada.