Slik bruker du PetaLinux: fra XSA til din første Linux-app på Zynq

Hvis du sliter med PetaLinux, ikke bekymre deg: du er ikke alene. Det har en bratt læringskurve , men det finnes en klar vei til å forstå hvordan Vivado, PetaLinux og Vitis fungerer sammen, og hvilken rolle hver komponent spiller. Her finner du en praktisk og organisert forklaring som hjelper deg med å gå fra et Vivado-design til å kjøre ditt første Linux- program på Zynq eller Zynq UltraScale+ uten å miste forstanden.

Mange lurer på om det er mulig å "leve" utelukkende i Vitis. Du trenger PetaLinux for kjernen, enhetstreet og rootfs . Den typiske arbeidsflyten du vil se på virkelige systemer er: generer .xsa-filen i Vivado, opprett og konfigurer PetaLinux-prosjektet (noen ganger fra en BSP), kompiler og pakk imaget (WIC for SD), og eksporter deretter sysroot-filen for å utvikle appen i Vitis eller med en ekstern verktøykjede. Senere skal jeg forklare alternativer, tips for å unngå endeløse gjenoppbygginger, og hva du skal gjøre med ting som FPGA Manager eller TCF Agent.

Hva er PetaLinux, og hva inkluderer det som standard?

PetaLinux er AMDs referansedistribusjon designet for deres SoC-er og MPSoC-er, og tilbyr et Linux-miljø som er klart til å tilpasses med optimaliserte oppstartslastere og kjerner , biblioteker og verktøy, C/C++-støtte og feilsøkingsverktøy. Den inkluderer også trådingsalternativer, FPU-støtte og en nettbasert administrasjonsserver for enkel nettverks- og fastvarekonfigurasjon.

Offisielle BSP-er kommer vanligvis med forhåndslagde oppstarts- og konfigurasjonsbilder. Distribuer og kjør binærfilene på ekte maskinvare eller i QEMU , den komplette systememulatoren som følger med PetaLinux. Dette fremskynder innledende testing og er ideelt for å bekrefte at prosjektet starter opp før du begynner å jobbe med apper eller drivere.

Anbefalte maskinvare-programvare-arbeidsflyter

I profesjonelle miljøer brukes to versjoner av Linux-arbeidsflyten: én fokusert på PetaLinux -kommandolinjen , og en annen som integrerer Vitis for applikasjonsutvikling, og genererer .xsa-filen og, hvis aktuelt, bitstrømmen.

Kan jeg gjøre alt i Vitis? For Linux, nei. Vitis er flott for å bygge plattformer når du trenger en tilpasset kjerne, enhetstre og rootfs. Den vanlige tilnærmingen er: PetaLinux for å bygge systemet og eksportere SDK/sysroot; og Vitis eller en ekstern verktøykjede for å kompilere og feilsøke applikasjonen din.

Fra XSA til oppstartssystemet

Minimumsrutinen er vanligvis som følger: du genererer .xsa-filen i Vivado , oppretter prosjektet med petalinux-create (eller starter fra en BSP), oppdaterer maskinvaren i PetaLinux med den .xsa-filen og justerer konfigurasjonen (kjerne, enhetstre og rootfs). Deretter kompilerer du, pakker til .wic-format og flasher SD-kortet.

Når systemet starter opp, er det på tide å legge til applikasjonen. Du eksporterer sysroot/SDK fra PetaLinux og oppretter en plattform fra .xsa-filen i Vitis. Derfra genererer du C/C++-applikasjonsprosjektet ditt som peker til sysroot for å koble den riktig til rootfs-bibliotekene, og kjører appen på målsystemet ved hjelp av tcf-agent, gdbserver eller din foretrukne metode.

En liten advarsel fra virkeligheten: Vivado/Vitis/PetaLinux-versjoner har sine særegenheter. For eksempel ble det rapportert et problem i Vitis Unified 2023.2 som forhindret tilkobling til tcf-agent, og den raske løsningen var å oppgradere til 2024.1. Sjekk alltid utgivelsesnotatene, og frys om mulig verktøystakken din under et prosjekt.

Maskinvaredesign i Vivado (Zynq-7000 og Zynq UltraScale+)

Teknologibasen din er i Vivados Block Design. Legg til blokken «ZYNQ7 Processing System» (eller tilsvarende i ZynqMP) og kjør Run Block Automation for å koble til DRAM og klokken. Derfra justerer du det du trenger.

• Aktiver eksterne avbrudd: I PS-tilpasning aktiverer du PS-PL-avbrudd og delte avbrudd hvis du planlegger å dele IRQ-linjer mellom PL-periferienheter.
• Synkroniser klokker: Vanlig praksis er å koble FCLK_CLK0 til M_AXI_GP0_ACLK-porten slik at AXI-bussklokken er konsistent med PS-klokken.

Med PL IP-er, stol på automatisering. Kjør tilkoblingsautomatisering etablerer AXI-sammenkoblinger og arbitrering, men vær oppmerksom på: den kobler ikke til avbrudd eller alle klokketrær. For IRQ-er, bruk en concat-blokk og rute utgangen til PS.

• Koble hver IRQ-linje for dine perifere IP-adresser til Concat-blokken.
• Koble Concat-utgangen til PS-avbruddsinngangen.

Hvis du trenger raskt minne i PL-en, legg til BRAM. Sett inn BRAM-kontrolleren og blokkminnegeneratoren , definer antall porter, bredde og kapasitet, og, aller viktigst, sjekk tilordningen i adresseredigereren.

• Sjekk og juster adressekartet: det kan ikke være noen overlappende områder; hvis det er det, farger Vivado konflikten i rødt.
• Vurder andre mastere (for eksempel en koprosessor i PL-en). Tildeling av adresser er obligatorisk for å forhindre at syntesen feiler.

For å fullføre designet, lag HDL-wrapperen for .bd-filen, syntetiser den og implementer den. Generering av bitstrømmen kan ta litt tid, og når den er ferdig, eksporter maskinvaren, inkludert biten hvis du vil programmere PL-en fra oppstart.

Noen nyttige punkter: Det er veldig praktisk å eksponere PS-signaler for PL med EMIO for GPIO eller I2C hvis du for eksempel skal bruke et PYNQ-skjold. Vær forsiktig med integrerte periferienheter: de er vanligvis fastkoblet til faste pinner på enheten, og det er ikke alltid mulig å erstatte dem med IP-er på strukturnivå uten å endre tilkoblinger. Hvis implementeringen mislykkes, sjekk restriksjoner (XDC) og tildelinger.

Enhetstre og maskinvaretilordning

Million-dollar-spørsmålet: hvor langt abstraherer Linux deg? Enhetstreet beskriver enhetsadresser, IRQ-er og kompatibiliteter. Denne kartleggingen er ikke "dynamisk" ved oppstart med mindre du bruker overlegg; den er vanligvis statisk og stammer fra Vivados adresseredigerer og DTS-en generert av PetaLinux.

Kontrolldelen (registre) og datadelen (f.eks. DMA-tilganger) bør være atskilt konseptuelt og fysisk. Bruk "reg"-områder og avbruddslinjer . Driveren (eller UIO) vil bruke denne informasjonen til å tilordne minne og avbruddslogikk. Størrelsen og justeringen av områdene må samsvare med det du definerte i Vivado.

Hvis du kompilerer med PetaLinux, genereres DTS-fragmentene vanligvis automatisk fra .xsa-filen. Oppdater .xsa-filen når du endrer maskinvaren (nye IP-adresser eller IP-adresser), og gjenoppbygg i det minste enhetstreet og kjernen. Rootfs-filen trenger ikke alltid endringer, så sysroot-filen kan fortsatt fungere selv om brukerbibliotekene ikke har blitt endret.

Alternativer for tilgang til maskinvare fra C/C++

Det finnes ingen én måte; velg basert på prosjektets stadium og innsatsen du er villig til å bruke på drivere. /dev/mem brukes til MMIO-tilordninger, men anbefales ikke i produksjon på grunn av sikkerhet, portabilitet og potensielle avbrudd.

Et mellomliggende alternativ: UIO (Userspace I/O) lar deg kartlegge IP-regioner i brukerområdet og håndtere avbrudd med select/poll. Det krever at UIO-nodene legges til i enhetstreet, men unngår å skrive en komplett driver.

Det profesjonelle alternativet er å lage en tegndriver eller en plattformdriver for IP-adressen din. En tegndriver gir deg god kontroll over DMA, IRQ, strømforsyning og et stabilt grensesnitt i /dev, samt bedre integrasjon med kjerneøkosystemet. Hvis IP-adressen din bruker AXI-DMA eller standardrammeverk, bør du stole på eksisterende drivere.

Angående verktøykjeden: du kan bruke Vitis eller kompilere med SDK-en eksportert av PetaLinux. Kjør `petalinux-build --sdk` og lenk prosjektet ditt til den sysroot-filen for å sikre at du lenker til de samme bibliotekene som i målets rootfs. Vitis forenkler byggingen av plattformen fra .xsa-filen og oppstart av ekstern feilsøking.

Feilsøking og fjernkjøring

For å kjøre appen på målet har du flere alternativer. tcf-agent fungerer bra for oppstart og feilsøking fra Vitis, forutsatt at agenten er installert i rootfs (legg den til fra petalinux-config -c rootfs) og du ikke har en versjonskonflikt.

Alternativt er gdbserver enkel og robust. Du kopierer binærfilen til målet, kjører `gdbserver :port ./yourapp` og kobler til fra verten ved hjelp av multiarkitekturen gdb. Mange team kombinerer gdbserver med VS Code Remote eller Python- skript.

For å gå lenger enn printf, ta en titt på kjerneprofilering og sporingsteknikker. Zynq -fellesskapet har delt beste praksis for effektiv feilsøking som vil spare deg tid når feilene ikke er åpenbare.

Oppgrader maskinvare uten å bygge alt om

Det er normalt å tro at en endring i PL-filen krever at man «fornyer verden», men det er handlingsrom. Grensesnitt som er synlige for kjernen (adresser, IRQ-er, kompatibilitet), rootfs og sysroot forblir vanligvis på plass. I så fall kan du omprogrammere PL-filen, og så er du klar.

For å laste bitstrømmer på forespørsel tilbyr Linux FPGA Manager-rammeverket ( fpgautil) eller sysfs/configfs-grensesnittet for programmering av PL-en fra brukerområdet. Dette unngår å regenerere hele bilder og fremskynder logikkiterasjoner.

Hvis maskinvareendringen introduserer nye IP-adresser eller endrer områder/IRQ-er, ja: gjenoppbygg enhetstreet og regenerer BOOT.BIN/image. Bruk likevel sstate-hurtigbufferen for å forhindre at kompileringen gjentar oppgaver som allerede er fullført.

Tips for å få fart på byggingen og få stabilitet

Det beste middelet mot å "gjenoppbygge alt" er mellomlagring og organisering. Bruk et sstate-speil og en delt nedlastingskatalog for Yocto/PetaLinux; dette hindrer deg i å kompilere pakker på nytt som ikke har endret seg. Dette utgjør en stor forskjell på store systemer og interne miljøer.

Oppretthold reproduserbarhet: forankre Vivado/Vitis/PetaLinux-versjoner og dokumentpatcher. Unngå versjonsendringer midt i prosjektet hvis mulig, med mindre det skyldes en bekreftet kritisk feil. Og før du hopper til en ny versjon, test på en gren.

QEMU er din allierte. Start opp imaget i QEMU for å bekrefte at rootfs og kjernen fungerer som forventet uten å måtte flashe SD-kortet. Det erstatter ikke selve maskinvaren, men det sparer oppstartssykluser.

Etter alt det ovennevnte virker ikke bildet lenger som et puslespill. Med en komplett referansedistro (bootloader, kernel, rootfs og verktøy) definerer Vivado det fysiske kartet, og Vitis akselererer appen og feilsøkingssyklusen. Derfra utgjør utnyttelse av enhetstre, UIO eller drivere forskjellen mellom et "Hello World" og et robust program som sømløst bruker maskinvaren din.