MICROCHIP PIC64GX 64-bit RISC-V Quad-Core mikroprocessor brugervejledning

Bootproces
1. Softwarekomponenter involveret i opstart
  Systemopstartsprocessen involverer følgende softwarekomponenter:
  - Hart Software Services (HSS): Et nul-stage boot-loader, systemmonitor og udbyder af runtime-tjenester til applikationer.
2. Boot Flow
  Rækkefølgen af systemets bootflow er som følger:
  1. Initialisering af Hart Software Services (HSS)
  2. Udførelse af bootloader
  3. Opstart af applikation
Vagthunde
1. PIC64GX Watchdog
  PIC64GX har en overvågningsfunktion til at overvåge systemdrift og udløse handlinger i tilfælde af systemfejl.
Låsetilstand
Låsetilstanden er designet til kunder, der kræver fuldstændig kontrol over systemhandlinger efter opstart. Det begrænser E51-systemmonitorens funktionaliteter.

FAQ

Q: Hvad er formålet med Hart Software Services (HSS)?
A: HSS fungerer som et nullertage boot-loader, systemmonitor og udbyder af runtime-tjenester til applikationer under opstartsprocessen.
Q: Hvordan fungerer PIC64GX vagthund-funktionen?
A: PIC64GX-vagthunden overvåger systemets drift og kan foretage foruddefinerede handlinger i tilfælde af systemfejl for at sikre systemets pålidelighed.

Indledning

Dette hvidbog forklarer, hvordan Microchip PIC64GX starter applikationsarbejdsbelastninger og beskriver systemstartprocessen, som fungerer på samme måde for SMP og AMP arbejdsbyrder. Derudover dækker det, hvordan en genstart fungerer for SMP og AMP arbejdsbelastninger, vagthunde på PIC64GX og en speciel lockdown-tilstand til systemer, hvor kunderne ønsker fuldstændig kontrol for at begrænse handlingerne fra E51-systemmonitoren efter systemstart.

Bootproces

Lad os tage et kig på de forskellige softwarekomponenter, der er involveret i systemopstart, efterfulgt af et mere detaljeret kig på sekvensen af selve systemstartflowet.

Softwarekomponenter involveret i opstart
Følgende komponenter er involveret i systemstartprocessen:

Figur 1.1. Opstartskomponenter

Hart Software Services (HSS)
Hart Software Services (HSS) er et nul-taltage boot loader, en systemmonitor og en udbyder af runtime-tjenester til applikationer. HSS understøtter tidlig systemopsætning, DDR-træning og hardwareinitialisering/konfiguration. Den kører for det meste på E51'erne, med en lille mængde maskintilstandsfunktionalitet, der kører på hver U54'er. Den starter en eller flere kontekster ved at indlæse applikationens "payload" fra opstartsmediet og leverer Platform Runtime Services/Supervisor Execution Environment (SEE) til operativsystemkerner. Den understøtter sikker opstart og er en vigtig komponent til at sikre hardwarepartitionering/adskillelse for AMP sammenhænge.

Das U-Boot (U-Boot)
Das U-Boot (U-Boot) er en open source universel scriptbar opstartsindlæser. Den understøtter en simpel CLI, der kan hente boot-billedet fra en række forskellige kilder (inklusive et SD-kort og netværket). U-Boot indlæser Linux. Det kan give et UEFI-miljø, hvis det er nødvendigt. Det er generelt færdigt og ude af vejen, når Linux er startet op – med andre ord, det forbliver ikke hjemme efter opstart.
Linux-kerne
Linux-kernen er verdens mest populære styresystemkerne. Kombineret med et brugerland af applikationer danner det, hvad der almindeligvis omtales som et Linux-operativsystem. Et Linux-operativsystem giver rige POSIX API'er og udviklermiljø, f.eksample, sprog og værktøjer såsom Python, Perl, Tcl, Rust, C/C++ og Tcl; biblioteker såsom OpenSSL, OpenCV, OpenMP, OPC/UA og OpenAMP (RPmsg og RemoteProc).
Yocto og Buildroot er Linux-systembyggere, det vil sige, de kan bruges til at generere skræddersyede tilpassede Linux-systemer. Yocto udsender en Linux-distribution med en rig
sæt applikationer, værktøjer og biblioteker og valgfri pakkehåndtering. Buildroot udsender en mere minimal rod filesystem og kan målrette mod systemer, der ikke kræver vedvarende lagring, men udelukkende kører fra RAM (ved hjælp af Linuxs initialer support, f.eks.ample).

Zephyr
Zephyr er et lille, open source Real-Time Operating System (RTOS). Det giver et Real-Time Low-Overhead Framework med RPMsg-lite kommunikationskanaler til Linux. Det inkluderer en kerne, biblioteker, enhedsdrivere, protokolstakke, filesystemer, mekanismer til firmwareopdateringer og så videre, og er fantastisk til kunder, der ønsker en mere bare-metal-lignende oplevelse på PIC64GX.

Boot Flow
PIC64GX inkluderer en RISC-V coreplex med et 64-bit E51 system monitor hart og 4 64-bit U54 applikations harts. I RISC-V-terminologi er en hart en RISC-V-udførelseskontekst, der indeholder et komplet sæt registre, og som udfører sin kode uafhængigt. Du kan tænke på det som en hardwaretråd eller en enkelt CPU. En gruppe af harts inden for en enkelt kerne kaldes ofte et kompleks. Dette emne beskriver trinene til initialisering af PIC64GX coreplex, inklusive E51-systemet overvåger hjerte- og U54-applikationsharts.

Tænd for PIC64GX coreplex.
Ved opstart frigives alle harts i RISC-V coreplex fra nulstilling af sikkerhedscontrolleren.
Kør HSS-koden fra on-chip eNVM flash-hukommelsen.
Til at begynde med begynder hvert hjerte at køre HSS-koden fra on-chip eNVM flash-hukommelsen. Denne kode får alle U54 applikationshjerte til at spinde, venter på instruktioner, og lader E51 monitorhjerte begynde at køre kode for at initialisere og få systemet frem.

Dekomprimer HSS-koden fra eNVM til L2-Scratch-hukommelse.
Afhængigt af dens opbygningstidskonfiguration er HSS normalt større end kapaciteten af selve eNVM-flashhukommelsen, og så det første, som HSS-koden kører på E51 gør, er at dekomprimere sig selv fra eNVM til L2-Scratch-hukommelse, som vist i figuren 1.2 og figur 1.3.
Figur 1.2. HSS Dekomprimerer fra eNVM til L2 Scratch
Figur 1.3. HSS-hukommelseskort under dekompression
Hop fra eNVM til L2-Scratch til en eksekverbar som vist i følgende figur.
Figur 1.4. HSS hopper fra eNVM til kode nu i L2Scratch efter dekompression
Den eksekverbare består af tre komponenter:
- Hardwareabstraktionslaget (HAL), kode på lavt niveau og bare metal-drivere
- En lokal HSS-gaffel af RISC-V OpenSBI (modificeret lidt fra opstrøms på PIC64GX for AMP formål)
- HSS runtime-tjenesterne (tilstandsmaskiner kører i en super loop)
Initialiser hardware- og datastrukturerne, der bruges af OpenSBI.
HSS-tjenesten "Startup" er ansvarlig for denne initialisering.

Hent billedet af programmets arbejdsbelastning (payload.bin) fra eksternt lager. Dette er vist i figur 1.5 og figur 1.6
Vigtigt: I tilfælde af PIC64GX Curiosity Kit, vil dette være fra et SD-kort.
Figur 1.5. Henter payload.bin Workload-billede fra eksternt lager
Figur 1.6. HSS-hukommelseskort efter hentning af payload.bin
Kopier de forskellige sektioner fra payload.bin til deres eksekveringstidsdestinationer. Den payload.bin er et formateret billede, som konsoliderer forskellige applikationsbilleder til SMP eller AMP arbejdsbyrder. Det inkluderer kode-, data- og deskriptortabeller, som gør det muligt for HSS at placere kode- og datasektionerne på passende måde, hvor de er nødvendige for at køre de forskellige applikationsarbejdsbelastninger.
Figur 1.7. payload.bin er kopieret til destinationsadresser

Instruer relevante U54'ere til at hoppe til deres startadresser for udførelse. Disse startadresseoplysninger er indeholdt i payload.bin.
Start U54 Application harts og eventuelle anden-stage opstartsindlæsere. F.eksample, U-Boot bringer Linux op.

Genstart

Relateret til begrebet systemopstart er behovet for at genstarte. Når du tænker på PIC64GX-applikationsarbejdsbelastninger, skal genstart tage hensyn til både symmetrisk multiprocessing (SMP) og asymmetrisk multiprocessing (AMP) scenarier:

I tilfælde af et SMP-system kan en genstart sikkert kold-genstarte hele systemet, da der ikke er yderligere arbejdsbelastninger i en anden sammenhæng at overveje.

I tilfælde af en AMP system, kan en arbejdsbelastning muligvis kun få lov til at genstarte sig selv (og ikke forstyrre nogen anden kontekst), eller den kan være privilegeret til at kunne udføre en fuld systemgenstart.

Genstart og AMP
For at aktivere SMP og AMP genstartsscenarier, understøtter HSS koncepterne med varm og kold genstartsprivilegier, som kan tildeles en kontekst. En kontekst med rettigheder til varm genstart er kun i stand til at genstarte sig selv, og en kontekst med rettigheder til kold genstart kan udføre en fuld systemgenstart. F.eksampovervej følgende sæt af repræsentative scenarier.

En enkelt kontekst SMP-arbejdsbelastning, som har tilladelse til at anmode om en fuld systemgenstart
I dette scenarie tillades konteksten kold genstartsprivilegium.
En to-kontekst AMP arbejdsbelastning, hvor kontekst A har lov til at anmode om en fuld systemgenstart (påvirker alle kontekster), og kontekst B kun må genstarte sig selv
I dette scenarie er kontekst A tilladt kold genstart privilegium, og kontekst B er tilladt varm genstart privilegium.
En to-kontekst AMP arbejdsbyrde, hvor kontekst A og B kun har lov til at genstarte sig selv (og ikke påvirker den anden kontekst)
I dette scenarie tillades begge sammenhænge kun varme genstartsprivilegier.
En to-kontekst AMP arbejdsbelastning, hvor kontekst A og B begge har lov til at anmode om fuld systemgenstart
I dette scenarie tillades begge kontekster kold genstartsprivilegier.
Ydermere er det muligt for HSS'en på byggetidspunktet altid at tillade privilegium for kold genstart og aldrig at tillade privilegium for kold genstart.

Relevante HSS Kconfig-indstillinger
Kconfig er et software build konfigurationssystem. Det bruges almindeligvis til at vælge byggetidsindstillinger og til at aktivere eller deaktivere funktioner. Det stammer fra Linux-kernen, men har nu fundet anvendelse i andre projekter ud over Linux-kernen, inklusive U-Boot, Zephyr og PIC64GX HSS.

HSS'en indeholder to Kconfig-indstillinger, der styrer genstartsfunktionaliteten fra HSS-perspektivet:

CONFIG_ALLOW_COLD GENSTART
Hvis dette er aktiveret, tillader det globalt en kontekst at udsende et koldt genstartkald. Hvis deaktiveret, vil kun varme genstarter blive tilladt. Ud over at aktivere denne mulighed skal tilladelse til at udstede en kold genstart gives til en kontekst gennem nyttelastgeneratoren YAML file eller følgende Kconfig-indstilling.
CONFIG_ALLOW_COLD REBOOT_ALWAYS
- Hvis den er aktiveret, tillader denne funktion globalt, at alle kontekster udsteder en kold genstart ECAA, uanset payload.bin flagrettighederne.
- Derudover kan selve payload.bin indeholde et per-kontekstflag, der indikerer, at en bestemt kontekst er berettiget til at udstede kolde genstarter:
  - For at tillade en kontekst varm genstart en anden kontekst, kan vi tilføje muligheden tillad-genstart: varm i YAML beskrivelsen file bruges til at oprette payload.bin
  - For at tillade en kontekst kold genstart af hele systemet, kan vi tilføje muligheden tillad-genstart: kold. Som standard, uden at angive tillad-genstart, er en kontekst kun tilladt varm genstart i sig selv. Uanset indstillingen af dette flag, hvis CONFIG_ALLOW_COLDREBOOT ikke er aktiveret i HSS, vil HSS omarbejde alle kolde genstartsanmodninger til varme (per-kontekst) genstarter .

Genstart i detaljer
Dette afsnit beskriver, hvordan genstarten fungerer i detaljer - startende med OpenSBI-laget (det laveste M-mode-lag) og diskuterer derefter, hvordan denne OpenSBI-lagfunktionalitet udløses fra en RTOS-applikation eller et rigt OS som Linux.

OpenSBI Genstart opkald

RISC-V Supervisor Binary Interface (SBI)-specifikationen beskriver et standardiseret hardwareabstraktionslag til platforminitialisering og firmware-runtime-tjenester. Hovedformålet med SBI er at muliggøre portabilitet og kompatibilitet på tværs af forskellige RISC-V-implementeringer.
OpenSBI (Open Source Supervisor Binary Interface) er et open source-projekt, der giver en referenceimplementering af SBI-specifikationen. OpenSBI leverer også runtime-tjenester, herunder afbrydelseshåndtering, timerstyring og konsol-I/O, som kan bruges af softwarelag på højere niveau.
OpenSBI er inkluderet som en del af HSS og kører på maskintilstandsniveau. Når operativsystemet eller applikationen forårsager en fælde, vil den blive videregivet til OpenSBI for at håndtere den. OpenSBI eksponerer en bestemt systemopkaldstype funktionalitet for de øverste lag af softwaren gennem en særlig fældemekanisme kaldet et opkald.

Systemnulstilling (EID 0x53525354) giver en omfattende systemopkaldsfunktion, der gør det muligt for det øverste lags software at anmode om genstart eller lukning på systemniveau. Når først dette opkald er påkaldt af en U54, fanges det af HSS-softwaren, der kører i maskintilstand på den U54, og en tilsvarende genstartsanmodning sendes til E51 for at genstarte enten konteksten eller hele systemet, afhængigt af rettighederne for sammenhæng.

For mere information, se RISC-V Supervisor Binær Interface Specifikation især Systemnulstillingsudvidelse (EID #0x53525354 "SRST").

Linux genstart

Som et specifikt exampI Linux bruges shutdown-kommandoen til at stoppe eller genstarte systemet. Kommandoen har typisk mange aliaser, nemlig stop, sluk og genstart. Disse aliaser angiver, om maskinen skal standses ved nedlukning, slukke for maskinen ved nedlukning eller genstarte maskinen ved nedlukning.

Disse brugerrumskommandoer udsender et genstartsystemkald til Linux, som er fanget af kernen og samvirket med et SBI-kald.
Der er forskellige niveauer af genstart – REBOOT_WARM, REBOOT_COLD, REBOOT_HARD – disse kan sendes som kommandolinjeargumenter til kernen (f.eks.ample, genstart=w[arm] for REBOOT_WARM). For mere information om Linux-kernens kildekode, se Documentation/admin-guide/kernel-paramters.txt.
Alternativt, hvis /sys/kernel/reboot er aktiveret, kan handlerne nedenunder læses for at få den aktuelle systemgenstartskonfiguration og skrives for at ændre den. For mere information om Linux-kernens kildekode, se Dokumentation/ABI/testing/sysfs-kernel-reboot.

Vagthunde

Et yderligere koncept relateret til systemstart og systemgenstart er systemgendannelse ved affyring af en vagthund-timer. Watchdog-timere bruges i vid udstrækning i indlejrede systemer til automatisk at gendanne forbigående hardwarefejl og for at forhindre fejlagtig eller ondsindet software i at forstyrre systemdriften.
PIC64GX inkluderer hardware watchdog support til at overvåge de individuelle harts, når systemet kører. Vagthundene sikrer, at hjerterne kan genstartes, hvis de ikke reagerer på grund af uoprettelige softwarefejl.
PIC64GX inkluderer fem forekomster af watchdog-timer-hardwareblokke, der bruges til at detektere systemlåsninger - en for hver af hjerterne. For at lette blandet asymmetrisk multi-behandling (AMP) arbejdsbelastninger, understøtter HSS overvågning og reaktion på vagthundens affyring.

PIC64GX Watchdog

HSS er ansvarlig for at starte applikationshartene ved opstart og for at genstarte dem (individuelt eller samlet) på et hvilket som helst tidspunkttage, hvis det er nødvendigt eller ønsket. Som en konsekvens af dette håndteres reaktion på vagthundehændelser på PIC64GX af HSS.
En 'virtuel vagthund'-monitor er implementeret som en HSS-tilstandsmaskineservice, og dens ansvar er at overvåge status for hver af U54 individuelle vagthund-hardwaremonitorer. Når en af disse U54 vagthunde tripper, registrerer HSS dette og vil genstarte U54 efter behov. Hvis U54 er en del af en SMP-kontekst, overvejes hele konteksten til genstart, da konteksten har varme genstartsrettigheder. Hele systemet vil blive genstartet, hvis konteksten har privilegium for kold genstart.

Relevante Kconfig-indstillinger

Watchdog-support er inkluderet som standard i frigivne HSS-builds. Hvis du ønsker at bygge en brugerdefineret HSS, vil dette afsnit beskrive konfigurationsmekanismen for at sikre, at Watchdog-understøttelse er aktiveret.

HSS konfigureres ved hjælp af Kconfig-konfigurationssystemet. En toplevel .config file er nødvendig for at vælge, hvilke tjenester der skal kompileres i eller ud af HSS-builden.
For det første skal indstillingen CONFIG_SERVICE_WDOG på øverste niveau aktiveres ("Virtuel Watchdog-understøttelse" gennem make config).

Dette afslører derefter følgende underindstillinger, som er afhængige af Watchdog-support:

CONFIG_SERVICE_WD OG_DEBUG
Aktiverer understøttelse af informations-/fejlretningsmeddelelser fra den virtuelle vagthund-tjeneste.
CONFIG_SERVICE_WD OG_DEBUG_TIMEOUT_SECS
Bestemmer den periodicitet (i sekunder), som Watchdog-fejlretningsmeddelelser vil blive udsendt af HSS.
CONFIG_SERVICE_WD OG_ENABLE_E51
Aktiverer vagthunden for E51 monitorer hjerte ud over U54s, beskytter driften af HSS selv.

Når E51 vagthunden er aktiveret, vil HSS med jævne mellemrum skrive til vagthunden for at opdatere den og forhindre den i at skyde. Hvis E51-hjertet af en eller anden grund låser sig eller går ned, og E51-vagthunden er aktiveret, vil dette altid nulstille hele systemet.

Watchdog Operation
Watchdog-hardwaren implementerer nedtællere. Et vindue med forbud mod opdatering kan oprettes ved at konfigurere den maksimale overvågningsværdi, op til hvilken opdatering er tilladt (MVRP).

Når den aktuelle værdi af watchdog-timeren er større end MVRP-værdien, er det forbudt at opdatere watchdog. Forsøg på at opdatere watchdog-timeren i det forbudte vindue vil påstå en timeout-afbrydelse.

Opdatering af vagthunden mellem MVRP-værdien og triggerværdien (TRIG) vil med succes opdatere tælleren og forhindre vagthunden i at skyde.
Når vagthundens timerværdi tæller under TRIG-værdien, vil vagthunden fyre.

Watchdog State Machine

Watchdog-tilstandsmaskinen er meget ligetil - starter op ved at konfigurere vagthunden til E51, hvis den er aktiveret, og derefter gå gennem en inaktiv tilstand til overvågning. Hver gang rundt om superloopen aktiveres denne overvågningstilstand, som kontrollerer status for hver af U54-vagthundene.

Watchdog-tilstandsmaskinen interagerer med opstartstilstandsmaskinen for at genstarte en hart (og eventuelle andre harts, der er i dens opstartssæt), hvis den registrerer, at harten ikke har formået at genopfriske sin watchdog i tide.

Låsetilstand

Normalt (især med AMP applikationer), forventes det, at HSS'en forbliver i M-mode, på en U54, for at tillade genstart pr. kontekst (dvs. genstart kun én kontekst, uden genstart med fuld chip), og for at tillade HSS'en at overvåge helbred ( ECC'er, låsestatusbits, busfejl, SBI-fejl, PMP-overtrædelser osv.).

For at give genstartsfunktioner på en per-AMP kontekstbasis (uden at hele systemet skal genstartes), har E51 normalt privilegeret hukommelsesadgang til hele systemets hukommelsesplads. Der kan dog være situationer, hvor dette ikke er ønskeligt, og kunden foretrækker måske at begrænse, hvad E51 HSS-firmwaren gør, når først systemet er startet op. I dette tilfælde er det muligt at sætte HSS i lockdown-tilstand, når U54 Application Harts er blevet startet.

Dette kan aktiveres ved at bruge HSS Kconfig-indstillingen CONFIG_SERVICE_LOCKDOWN.
Lockdown-tjenesten er beregnet til at tillade begrænsning af HSS'ens aktiviteter, efter at den har startet U54-applikationen Harts.

Figur 4.2. HSS-låsetilstand

Når låsetilstanden starter, stopper den alle andre HSS-servicetilstandsmaskiner i at køre. Det kalder to svagt bundne funktioner:

e51_pmp_lockdown(), og
e51_lockdown()

Disse funktioner er beregnet til at blive tilsidesat af tavlespecifik kode. Den første er en konfigurerbar triggerfunktion, der gør det muligt for en BSP at tilpasse låsning af E51'en fra applikationens nyttelast på dette tidspunkt. Den svagt bundne standardimplementering af denne funktion er tom. Den anden er den funktionalitet, der køres fra det tidspunkt og fremad. Den svagt bundne standardimplementering betjener vagthunden på dette tidspunkt i E51, og vil genstarte, hvis en U54 vagthund fyrer. For mere information, se HSS-kildekoden i services/lockdown/lockdown_service.c file.

Tillæg

HSS payload.bin Format

Dette afsnit beskriver payload.bin file format og det billede, der bruges af HSS til at starte PIC64GX SMP og AMP applikationer.
Payload.bin er en formateret binær (Figur A.10) bestående af et hoved, forskellige deskriptortabeller og forskellige bidder, der indeholder kode- og datasektionerne for hver del af applikationens arbejdsbelastning. En del kan betragtes som en sammenhængende hukommelsesblok i vilkårlig størrelse.

Figur A.10. payload.bin-format

Overskriftsdelen (vist i figur A.11) indeholder en magisk værdi, der bruges til at identificere payload.bin og nogle husholdningsoplysninger sammen med detaljer om det billede, der skal køre på hver af
U54 applikationskoder. Den beskriver, hvordan man starter hver enkelt U54-hart, og det samlede sæt af bootbare billeder. I sin husholdningsinformation har den henvisninger til forskellige tabeller med deskriptorer for at tillade overskriftstørrelsen at vokse.

Figur A.11. payload.bin Header

Kode og initialiserede konstantdata betragtes som skrivebeskyttede og lagres i en skrivebeskyttet sektion, som peges på af header-deskriptorer.
Ikke-nul initialiserede datavariable er læse-skrive-data, men har deres initialiseringsværdier kopieret fra skrivebeskyttet chunk ved opstart. Disse er også gemt i skrivebeskyttet sektion.

Den skrivebeskyttede nyttelastdatasektion er beskrevet af en tabel med kode- og datachunk-beskrivelser. Hver chunk-deskriptor i denne tabel indeholder en 'harte-ejer' (hovedharten i den kontekst, den er målrettet mod
at), en belastningsforskydning (offset inden for payload.bin) og en udførelsesadresse (destinationsadresse i PIC64GX-hukommelsen) sammen med en størrelse og kontrolsum. Dette er vist i figur A.12.

Figur A.12. Read-One Chunk Descriptor og Payload Chunk Data

Ud over de førnævnte bidder er der også bidder af hukommelse svarende til datavariabler, der er initialiseret til nul. Disse gemmes ikke som data i payload.bin, men er i stedet et særligt sæt nul-initialiserede chunk-deskriptorer, som angiver en adresse og længde på RAM, der skal indstilles til nul under opstart. Dette er vist i figur A.13.

Figur A.13. ZI Chunks

hss-nyttelast-generator
HSS Payload Generator-værktøjet opretter et formateret nyttelastbillede til Hart Software Service-nullernetage bootloader på PIC64GX, givet en konfiguration file og et sæt ELF files og/eller binære filer. Konfigurationen file bruges til at kortlægge ELF-binære filer eller binære klatter til de individuelle applikationsharts (U54s).

Figur B.14. hss-nyttelast-generator Flow

Værktøjet udfører grundlæggende sundhedstjek på strukturen af konfigurationen file sig selv og på ELF-billederne. ELF-billeder skal være RISC-V-eksekverbare.

Example Løb

For at køre hss-payload-generator-værktøjet med sample konfiguration file og ELF files:
$ ./hss-payload-generator -c test/config.yaml output.bin
For at udskrive diagnostik om et allerede eksisterende billede skal du bruge:
$ ./hss-nyttelast-generator -d output.bin

For at aktivere sikker opstartsgodkendelse (via billedsignering), skal du bruge -p til at angive placeringen af en X.509 privat nøgle til den elliptiske kurve P-384 (SECP384r1):
$ ./hss-payload-generator -c test/config.yaml payload.bin -p /path/to/private.pem

For mere information, se Secure Boot Authentication-dokumentationen.

Konfig File Example

For det første kan vi valgfrit angive et navn til vores billede, ellers vil et blive oprettet dynamisk:
sætnavn: 'PIC64-HSS::TestImage'
Dernæst definerer vi indgangsadresserne for hvert hjerte som følger:
hart-entry-points: {u54_1: ‘0x80200000’, u54_2: ‘0x80200000’, u54_3: ‘0xB0000000′, u54_4:’0x80200000’}

ELF-kildebillederne kan angive et indgangspunkt, men vi ønsker at kunne understøtte sekundære indgangspunkter for harts, hvis det er nødvendigt, f.eks.ample, hvis flere harts er beregnet til at starte det samme billede, kan de have individuelle indgangspunkter. For at understøtte dette angiver vi de faktiske indgangspunkter i konfigurationen file sig selv.

Vi kan nu definere nogle nyttelaster (kilde ELF files eller binære klatter), der vil blive placeret i bestemte områder i hukommelsen. Nyttelastafsnittet er defineret med nøgleordet nyttelast og derefter et antal individuelle nyttelastdeskriptorer. Hver nyttelast har et navn (sti til dens file), en ejer-hart og eventuelt 1 til 3 sekundære harts.

Derudover har en nyttelast en privilegietilstand, hvor den vil starte eksekvering. Gyldige privilegietilstande er PRV_M, PRV_S og PRV_U, hvor disse er defineret som:

PRV_M Maskintilstand
PRV_S Supervisor-tilstand
PRV_U Brugertilstand

I det følgende exampdet:

test/zephyr.elf antages at være en Zephyr-applikation, der kører i U54_3, og forventer at starte i PRV_M-privilegietilstanden.
test/u-boot-dtb.bin er Das U-Boot bootloader-applikationen, og den kører på U54_1, U54_2 og U54_4. Den forventer at starte i PRV_S privilegietilstand.

Vigtig:
Outputtet af U-Boot skaber en ELF file, men typisk står den ikke foran .elf-udvidelsen. I dette tilfælde bruges binæren oprettet af CONFIG_OF_SEPARATE, som tilføjer en enhedstræ-blob til U-Boot-binæren.

Her er ex'enample Nyttelast konfiguration file:

test/zephyr.elf:
{exec-addr: '0xB0000000', ejer-hart: u54_3, priv-mode: prv_m, skip-opensbi: sand}
test/u-boot-dtb.bin:
{exec-addr: '0x80200000', ejer-hart: u54_1, sekundær-hart: u54_2, sekundær-hart: u54_4, priv-mode: prv_s}

Vigtig:
Sagen har kun betydning for file stinavne, ikke nøgleordene. Så f.eks. betragtes u54_1 som det samme som U54_1, og exec-addr betragtes som det samme som EXEC-ADDR. Hvis en.elf- eller .bin-udvidelse er til stede, skal den inkluderes i konfigurationen file.

For en bare metal-applikation, der ikke ønsker at være bekymret over OpenSBI, vil muligheden for spring-opens, hvis den er sand, forårsage, at nyttelasten på det hjerte bliver påkaldt ved hjælp af en simpel mret snarere
end et OpenSBI sbi_init()-kald. Dette betyder, at hjertet vil begynde at køre bar metal-koden uanset OpenSBI HSM overvejelser. Bemærk, at dette også betyder, at hjertet ikke kan bruge
opkald for at påberåbe sig OpenSBI-funktionalitet. Indstillingen spring-åbner er valgfri og er som standard falsk.

For at tillade en kontekst varm genstart af en anden kontekst, kan vi tilføje muligheden tillad genstart: varm. For at tillade en kontekst kold genstart af hele systemet, kan vi tilføje muligheden tillad-genstart: kold. Som standard, uden at angive tillad-genstart, er en kontekst kun tilladt at varme genstarte sig selv.
Det er også muligt at tilknytte hjælpedata til hver nyttelast, f.eksample, en DeviceTree Blob (DTB) file, ved at specificere hjælpedataene filenavn som følger:
test/u-boot.bin: { exec-addr: '0x80200000', ejer-hart: u54_1, sekundær-hart: u54_2, sekundær-hart: u54_3, sekundær-hart: u54_4, priv-mode: prv_s, accessoriske-data : test/pic64gx.dtb }
Disse hjælpedata vil blive inkluderet i nyttelasten (placeret lige efter den primære file i den eksekverbare
space), og dens adresse vil blive videregivet til OpenSBI i feltet next_arg1 (overført i $a1-registret til billedet ved opstart).

For at forhindre HSS i automatisk at starte en kontekst (for eksempel, hvis vi i stedet ønsker at uddelegere kontrol over denne til en kontekst ved hjælp af remoteProc), skal du bruge skip-autoboot flaget:
test/zephyr.elf: {exec-addr: '0xB0000000', ejer-hart: u54_3, priv-mode: prv_m, skip-opensbi: sand, skip-autoboot: sand}
Endelig kan vi valgfrit tilsidesætte navnene på individuelle nyttelaster ved at bruge muligheden for nyttelastnavn. F.eksampdet:
test/u-boot.bin: { exec-addr: '0x80200000', ejer-hart: u54_1, sekundær-hart: u54_2, sekundær-hart: u54_3, sekundær-hart: u54_4, priv-mode: prv_s, accessoriske-data : test/pic64gx.dtb, nyttelast-navn: 'u-boot' }

Bemærk, at Yocto- og Buildroot Linux-builderne vil bygge, konfigurere og køre hss-payload-
generator efter behov for at generere applikationsbilleder. Derudover er pic64gx-curiosity-kit-amp maskinmål i Yocto vil generere et applikationsbillede ved hjælp af værktøjet hss-payload-generator, der demonstrerer AMP, med Linux kører på 3 harts og Zephyr kører på 1 hart.

Revisionshistorie
Revisionshistorikken beskriver de ændringer, der blev implementeret i dokumentet. Ændringerne er listet efter revision, startende med den seneste publikation.

Revision	Dato	Beskrivelse
A	07/2024	Indledende revision

Mikrochip information

Mikrochippen Webwebsted
Microchip yder online support via vores website kl www.microchip.com/. Denne website bruges til at lave files og information let tilgængelig for kunderne. Noget af det tilgængelige indhold inkluderer:

Produktsupport – Datablade og errata, ansøgningsnotater og sample-programmer, designressourcer, brugervejledninger og hardwaresupportdokumenter, seneste softwareudgivelser og arkiveret software

Generel teknisk support – Ofte stillede spørgsmål (FAQ), anmodninger om teknisk support, online diskussionsgrupper, medlemsliste for Microchip-designpartnerprogram
Microchips virksomhed – Produktvælger- og bestillingsvejledninger, seneste Microchip-pressemeddelelser, en liste over seminarer og arrangementer, lister over Microchip salgskontorer, distributører og fabriksrepræsentanter

Produktændringsmeddelelsesservice

Microchips underretningstjeneste for produktændringer hjælper med at holde kunderne opdateret på Microchip-produkter. Abonnenter vil modtage e-mail-meddelelser, når der er ændringer, opdateringer, revisioner eller fejl relateret til en specificeret produktfamilie eller udviklingsværktøj af interesse.

For at registrere, gå til www.microchip.com/pcn og følg registreringsvejledningen.

Kundesupport
Brugere af Microchip-produkter kan modtage assistance gennem flere kanaler:

Distributør eller repræsentant
Lokalt salgskontor
Embedded Solutions Engineer (ESE)
Teknisk support

Kunder bør kontakte deres distributør, repræsentant eller ESE for at få support. Lokale salgskontorer er også tilgængelige for at hjælpe kunder. En liste over salgskontorer og lokationer er inkluderet i dette dokument.
Teknisk support er tilgængelig via webwebsted på: www.microchip.com/support.

Mikrochip-enheder kodebeskyttelsesfunktion
Bemærk følgende detaljer om kodebeskyttelsesfunktionen på Microchip-produkter:

Microchip-produkter opfylder specifikationerne i deres særlige Microchip-datablad.
Microchip mener, at dens familie af produkter er sikre, når de bruges på den tilsigtede måde, inden for driftsspecifikationerne og under normale forhold.

Microchip værdsætter og beskytter aggressivt sine intellektuelle ejendomsrettigheder. Forsøg på at bryde kodebeskyttelsesfunktionerne i Microchip-produkter er strengt forbudt og kan være i strid med Digital Millennium Copyright Act.
Hverken Microchip eller nogen anden halvlederproducent kan garantere sikkerheden af deres kode. Kodebeskyttelse betyder ikke, at vi garanterer, at produktet er "ubrydeligt". Kodebeskyttelse er i konstant udvikling. Microchip er forpligtet til løbende at forbedre kodebeskyttelsesfunktionerne i vores produkter.

Juridisk meddelelse
Denne publikation og oplysningerne heri må kun bruges med Microchip-produkter, herunder til at designe, teste og integrere Microchip-produkter med din applikation. Brug af disse oplysninger på anden måde overtræder disse vilkår. Oplysninger om enhedsapplikationer gives kun for din bekvemmelighed og kan blive afløst af opdateringer. Det er dit ansvar at sikre, at din ansøgning lever op til dine specifikationer. Kontakt dit lokale Microchip salgskontor for yderligere support, eller få yderligere support på www.microchip.com/en-us/support/design-help/client-support-services.

DISSE OPLYSNINGER LEVERES AF MICROCHIP "SOM DE ER". MICROCHIP GIVER INGEN REPRÆSENTATIONER ELLER GARANTIER AF NOGEN ART, HVERKEN UDTRYKKELIGE ELLER UNDERFORSTÅEDE, SKRIFTLIGE ELLER mundtlige, LOVBESTEMMET ELLER ANDEN MÅDE, RELATET TIL OPLYSNINGERNE, INKLUSIVE MEN IKKE BEGRÆNSET TIL NOGEN STILTIENDE GARANTIER, GARANTIER OG GARANTIER. EGNETHED TIL ET BESTEMT FORMÅL ELLER GARANTIER RELATET TIL DETS TILSTAND, KVALITET ELLER YDELSE.

I INGEN OMSTÆNDIGHEDER ER MICROCHIP ANSVARLIG FOR NOGEN INDIREKTE, SÆRLIGE, STRAFFENDE, TILFÆLDELIGE ELLER FØLGETAB, SKADER, OMKOSTNINGER ELLER UDGIFTER AF NOGEN ART, DER ER RELATET TIL OPLYSNINGERNE ELLER DERES BRUG, UANSET ANDEN ELLER AGS. MULIGHEDEN ELLER SKADERNE ER FORUDSUELIGE. I DET FULDSTÆNDIGE OMFANG LOVEN TILLADER, VIL MICROCHIPS SAMLEDE ANSVAR PÅ ALLE KRAV PÅ NOGEN MÅDE RELATERET TIL INFORMATIONEN ELLER DERES BRUG IKKE OVERstige ANTALLET AF GEBYRER, HVIS NØDVENDE, SOM DU HAR BETALT DIREKTE TIL INFORMATIONOCHIPPET.

Brug af Microchip-enheder i livsstøtte- og/eller sikkerhedsapplikationer er helt på købers risiko, og køberen indvilliger i at forsvare, holde Microchip skadesløs og holde Microchip skadesløs for alle skader, krav, sager eller udgifter som følge af sådan brug. Ingen licenser videregives, implicit eller på anden måde, under nogen af Microchips intellektuelle ejendomsrettigheder, medmindre andet er angivet.

Varemærker
Mikrochipnavnet og logoet, mikrochiplogoet, Adaptec, AVR, AVR-logoet, AVR Freaks, BesTime, BitCloud, CryptoMemory, CryptoRF, dsPIC, flexPWR, HELDO, IGLOO, JukeBlox, KeeLoq, Kleer, LANCheck, LinkMD, maXStylus, maXTouch, MediaLB, megaAVR, Microsemi, Microsemi logo, MOST, MOST logo, MPLAB, OptoLyzer, PIC, picoPower, PICSTART, PIC32 logo, PolarFire, Prochip Designer, QTouch, SAM-BA, SenGenuity, SpyNIC, SST, SST Logo, SuperFlash, Symmetricom , SyncServer, Tachyon, TimeSource, tinyAVR, UNI/O, Vectron og XMEGA er registrerede varemærker tilhørende Microchip Technology Incorporated i USA og andre lande.

AgileSwitch, ClockWorks, The Embedded Control Solutions Company, EtherSynch, Flashtec, Hyper Speed Control, HyperLight Load, Libero, motorbænk, mTouch, Powermite 3, Precision Edge, ProASIC, ProASIC Plus, ProASIC Plus-logo, Quiet-Wire, SmartFusion, SyncWorld , TimeCesium, TimeHub, TimePictra, TimeProvider og ZL er registrerede varemærker tilhørende Microchip Technology Incorporated i USA

Adjacent Key Suppression, AKS, Analog-for-the-Digital Age, Any Capacitor, AnyIn, AnyOut, Augmented Switching, BlueSky, BodyCom, Clockstudio, CodeGuard, CryptoAuthentication, CryptoAutomotive, CryptoCompanion, CryptoController, dsPICDEM, dsPICDEM.net, Dynamic Average Matching, Dynamic , DAM, ECAN, Espresso T1S, EtherGREEN, EyeOpen, GridTime, IdealBridge,
IGAT, In-Circuit Seriel Programmering, ICSP, INICnet, Intelligent Paralleling, IntelliMOS, Inter-Chip Connectivity, JitterBlocker, Knob-on-Display, MarginLink, maxCrypto, max.View, memBrain, Mindi, MiWi, MPASM, MPF, MPLAB Certified logo, MPLIB, MPLINK, mSiC, MultiTRAK, NetDetach, Omniscient Code Generation, PICDEM, PICDEM.net, PICkit, PICtail, Power MOS IV, Power MOS 7, PowerSmart, PureSilicon , QMatrix, REAL ICE, Ripple Blocker, RTAX, RTG4, SAM-ICE, Serial Quad I/O, simpelt kort, SimpliPHY, SmartBuffer, SmartHLS, SMART-IS, storClad, SQI, SuperSwitcher, SuperSwitcher II, Switchtec, SynchroPHY, Total Endurance, Trusted Time, TSHARC, Turing, USBCheck, VariSense, VectorBlox, VeriPHY, ViewSpan, WiperLock, XpressConnect og ZENA er varemærker tilhørende Microchip Technology Incorporated i USA og andre lande.

SQTP er et servicemærke tilhørende Microchip Technology Incorporated i USA
Adaptec-logoet, Frequency on Demand, Silicon Storage Technology og Symmcom er registrerede varemærker tilhørende Microchip Technology Inc. i andre lande.
GestIC er et registreret varemærke tilhørende Microchip Technology Germany II GmbH & Co. KG, et datterselskab af Microchip Technology Inc., i andre lande.

ISBN: 978-1-6683-4890-1

Kvalitetsstyringssystem
For information om Microchips kvalitetsstyringssystemer, besøg venligst www.microchip.com/quality.

Verdensomspændende salg og service

AMERIKA

ASIEN/PACIFIK

EUROPA

Corporate Kontor

2355 West Chandler Blvd. Chandler, AZ 85224-6199

Tlf.: 480-792-7200

Fax: 480-792-7277

Teknisk support: www.microchip.com/support

Web Adresse: www.microchip.com

Atlanta

Duluth, GA

Tlf.: 678-957-9614

Fax: 678-957-1455

Austin, TX

Tlf.: 512-257-3370

Boston

Westborough, MA Tlf.: 774-760-0087

Fax: 774-760-0088

Chicago

Itasca, IL

Tlf.: 630-285-0071

Fax: 630-285-0075

Dallas

Addison, TX

Tlf.: 972-818-7423

Fax: 972-818-2924

Detroit

Novi, MI

Tlf.: 248-848-4000

Houston, TX

Tlf.: 281-894-5983

Indianapolis

Noblesville, IN Tlf.: 317-773-8323

Fax: 317-773-5453

Tlf.: 317-536-2380

Los Angeles

Mission Viejo, CA Tlf.: 949-462-9523

Fax: 949-462-9608

Tlf.: 951-273-7800

Raleigh, NC

Tlf.: 919-844-7510

New York, NY

Tlf.: 631-435-6000

San Jose, CA

Tlf.: 408-735-9110

Tlf.: 408-436-4270

Canada – Toronto

Tlf.: 905-695-1980

Fax: 905-695-2078

Australien – Sydney

Tlf.: 61-2-9868-6733

Kina – Beijing

Tlf.: 86-10-8569-7000

Kina – Chengdu

Tlf.: 86-28-8665-5511

Kina – Chongqing

Tlf.: 86-23-8980-9588

Kina – Dongguan

Tlf.: 86-769-8702-9880

Kina – Guangzhou

Tlf.: 86-20-8755-8029

Kina – Hangzhou

Tlf.: 86-571-8792-8115

Kina – Hong Kong SAR

Tlf.: 852-2943-5100

Kina – Nanjing

Tlf.: 86-25-8473-2460

Kina – Qingdao

Tlf.: 86-532-8502-7355

Kina – Shanghai

Tlf.: 86-21-3326-8000

Kina – Shenyang

Tlf.: 86-24-2334-2829

Kina – Shenzhen

Tlf.: 86-755-8864-2200

Kina – Suzhou

Tlf.: 86-186-6233-1526

Kina – Wuhan

Tlf.: 86-27-5980-5300

Kina – Xian

Tlf.: 86-29-8833-7252

Kina – Xiamen

Tlf.: 86-592-2388138

Kina – Zhuhai

Tlf.: 86-756-3210040

Indien – Bangalore

Tlf.: 91-80-3090-4444

Indien – New Delhi

Tlf.: 91-11-4160-8631

Indien – Pune

Tlf.: 91-20-4121-0141

Japan – Osaka

Tlf.: 81-6-6152-7160

Japan – Tokyo

Tlf.: 81-3-6880- 3770

Korea – Daegu

Tlf.: 82-53-744-4301

Korea – Seoul

Tlf.: 82-2-554-7200

Malaysia – Kuala Lumpur

Tlf.: 60-3-7651-7906

Malaysia – Penang

Tlf.: 60-4-227-8870

Filippinerne – Manila

Tlf.: 63-2-634-9065

Singapore

Tlf.: 65-6334-8870

Taiwan – Hsin Chu

Tlf.: 886-3-577-8366

Taiwan – Kaohsiung

Tlf.: 886-7-213-7830

Taiwan - Taipei

Tlf.: 886-2-2508-8600

Thailand – Bangkok

Tlf.: 66-2-694-1351

Vietnam – Ho Chi Minh

Tlf.: 84-28-5448-2100

Østrig – Wels

Tlf.: 43-7242-2244-39

Fax: 43-7242-2244-393

Danmark – København

Tlf.: 45-4485-5910

Fax: 45-4485-2829

Finland – Espoo

Tlf.: 358-9-4520-820

Frankrig – Paris

Tel: 33-1-69-53-63-20

Fax: 33-1-69-30-90-79

Tyskland – garching

Tlf.: 49-8931-9700

Tyskland – Haan

Tlf.: 49-2129-3766400

Tyskland – Heilbronn

Tlf.: 49-7131-72400

Tyskland – Karlsruhe

Tlf.: 49-721-625370

Tyskland – München

Tel: 49-89-627-144-0

Fax: 49-89-627-144-44

Tyskland – Rosenheim

Tlf.: 49-8031-354-560

Israel – Hod Hasharon

Tlf.: 972-9-775-5100

Italien – Milano

Tlf.: 39-0331-742611

Fax: 39-0331-466781

Italien – Padova

Tlf.: 39-049-7625286

Holland – Drunen

Tlf.: 31-416-690399

Fax: 31-416-690340

Norge – Trondheim

Tlf.: 47-72884388

Polen – Warszawa

Tlf.: 48-22-3325737

Rumænien – Bukarest

Tel: 40-21-407-87-50

Spanien - Madrid

Tel: 34-91-708-08-90

Fax: 34-91-708-08-91

Sverige – Gøteborg

Tel: 46-31-704-60-40

Sverige – Stockholm

Tlf.: 46-8-5090-4654

Storbritannien – Wokingham

Tlf.: 44-118-921-5800

Fax: 44-118-921-5820

Dokumenter/ressourcer

MICROCHIP PIC64GX 64-bit RISC-V quad-core mikroprocessor [pdfBrugervejledning
PIC64GX, PIC64GX 64-bit RISC-V quad-core mikroprocessor, 64-bit RISC-V quad-core mikroprocessor, RISC-V quad-core mikroprocessor, quad-core mikroprocessor, mikroprocessor

Referencer

Brugermanual

MICROCHIP PIC64GX 64-bit RISC-V quad-core mikroprocessor

Produktinformation

Produktbrugsvejledning