MICROCHIP PIC64GX Ghid de utilizare pentru microprocesor RISC-V Quad-Core pe 64 de biți

Procesul de pornire
1. Componente software implicate în pornire
  Procesul de pornire a sistemului implică următoarele componente software:
  - Hart Software Services (HSS): Un zero-stage încărcător de pornire, monitor de sistem și furnizor de servicii de rulare pentru aplicații.
2. Fluxul de pornire
  Secvența fluxului de pornire a sistemului este următoarea:
  1. Inițializarea serviciilor Hart Software (HSS)
  2. Execuția bootloader-ului
  3. Pornirea aplicației
Câini de pază
1. PIC64GX Watchdog
  PIC64GX dispune de o funcție watchdog pentru a monitoriza funcționarea sistemului și a declanșa acțiuni în cazul defecțiunilor sistemului.
Modul de blocare
Modul de blocare este conceput pentru clienții care au nevoie de control complet asupra acțiunilor sistemului după pornire. Limitează funcționalitățile monitorului de sistem E51.

FAQ

Î: Care este scopul Hart Software Services (HSS)?
R: HSS servește ca zero-uritage încărcător de pornire, monitor de sistem și furnizor de servicii de rulare pentru aplicații în timpul procesului de pornire.
Î: Cum funcționează funcția watchdog PIC64GX?
R: Watchdog-ul PIC64GX monitorizează funcționarea sistemului și poate întreprinde acțiuni predefinite în cazul defecțiunilor sistemului pentru a asigura fiabilitatea sistemului.

Introducere

Această lucrare explică modul în care Microchip PIC64GX pornește sarcinile de lucru ale aplicației și descrie procesul de pornire a sistemului, care funcționează la fel pentru SMP și AMP sarcinile de lucru. În plus, acoperă modul în care funcționează o repornire pentru SMP și AMP sarcini de lucru, watchdogs pe PIC64GX și un mod special de blocare pentru sistemele în care clienții doresc control complet pentru a limita acțiunile monitorului de sistem E51 după pornirea sistemului.

Procesul de pornire

Să aruncăm o privire la diferitele componente software implicate în pornirea sistemului, urmată de o privire mai detaliată asupra secvenței fluxului de pornire a sistemului în sine.

Componente software implicate în pornire
Următoarele componente sunt implicate în procesul de pornire a sistemului:

Figura 1.1. Componente de pornire

Hart Software Services (HSS)
Hart Software Services (HSS) este un zero-stagun încărcător de pornire, un monitor de sistem și un furnizor de servicii de rulare pentru aplicații. HSS acceptă configurarea timpurie a sistemului, instruirea DDR și inițializarea/configurarea hardware-ului. În mare parte, rulează pe E51s, cu o cantitate mică de funcționalități la nivel de mașină care rulează pe fiecare U54. Pornește unul sau mai multe contexte prin încărcarea „sarcinii utile” a aplicației de pe mediul de pornire și oferă Platform Runtime Services/Supervisor Execution Environment (SEE) pentru nucleele sistemului de operare. Acceptă boot securizat și este o componentă importantă în asigurarea partiționării/separarii hardware pentru AMP contexte.

Das U-Boot (U-Boot)
Das U-Boot (U-Boot) este un încărcător de pornire universal cu scripturi open-source. Acceptă un CLI simplu care poate prelua imaginea de pornire dintr-o varietate de surse (inclusiv un card SD și rețea). U-Boot încarcă Linux. Poate oferi un mediu UEFI dacă este necesar. În general, este terminat și în afara drumului odată ce Linux a pornit - cu alte cuvinte, nu rămâne rezident după pornire.
Kernel Linux
Nucleul Linux este cel mai popular nucleu de sistem de operare din lume. Combinat cu o zonă de utilizatori de aplicații, formează ceea ce este denumit în mod obișnuit un sistem de operare Linux. Un sistem de operare Linux oferă API-uri POSIX bogate și mediu de dezvoltator, de example, limbaje și instrumente precum Python, Perl, Tcl, Rust, C/C++ și Tcl; biblioteci precum OpenSSL, OpenCV, OpenMP, OPC/UA și OpenAMP (RPmsg și RemoteProc).
Yocto și Buildroot sunt constructori de sisteme Linux, adică pot fi utilizați pentru a genera sisteme Linux personalizate la comandă. Yocto scoate o distribuție Linux cu un rich
set de aplicații, instrumente și biblioteci și gestionarea pachetelor opționale. Buildroot produce o rădăcină mai minimă filesistem și poate viza sisteme care nu necesită stocare persistentă, dar rulează în întregime din RAM (folosind suportul pentru inițialele Linux, de exempluample).

Zefir
Zephyr este un sistem de operare în timp real (RTOS) mic, open-source. Oferă un cadru de supraîncărcare redusă în timp real, cu canale de comunicație RPMsg-lite către Linux. Include un nucleu, biblioteci, drivere de dispozitiv, stive de protocoale, filesisteme, mecanisme pentru actualizări de firmware și așa mai departe și este grozav pentru clienții care doresc o experiență de tip bare-metal pe PIC64GX.

Fluxul de pornire
PIC64GX include un coreplex RISC-V cu un sistem de monitorizare hart E64 pe 51 de biți și 4 aplicații Hart U64 pe 54 de biți. În terminologia RISC-V, un hart este un context de execuție RISC-V care conține un set complet de registre și care își execută codul în mod independent. Vă puteți gândi la el ca la un fir hardware sau la un singur CPU. Un grup de cerbi dintr-un singur nucleu este adesea numit complex. Acest subiect descrie pașii de inițializare a coreplexului PIC64GX, inclusiv sistemul E51, monitorizează inima și aplicația U54.

Porniți coreplexul PIC64GX.
La pornire, toate harturile din coreplexul RISC-V sunt eliberate de la resetare de către controlerul de securitate.
Rulați codul HSS din memoria flash eNVM de pe cip.
Inițial, fiecare inimă începe să ruleze codul HSS din memoria flash eNVM de pe cip. Acest cod face ca toate aplicațiile U54 să se rotească, așteptând instrucțiuni și permite monitorului E51 să înceapă să ruleze codul pentru a inițializa și a deschide sistemul.

Decomprimați codul HSS din eNVM în memoria L2-Scratch.
În funcție de configurația sa în timpul construirii, HSS este de obicei mai mare decât capacitatea memoriei flash eNVM în sine și, prin urmare, primul lucru pe care îl face codul HSS care rulează pe E51 este să se decomprima din eNVM în memoria L2-Scratch, așa cum se arată în figură. 1.2 și Figura 1.3.
Figura 1.2. HSS decomprimă de la eNVM la L2 Scratch
Figura 1.3. Harta memoriei HSS în timpul decompresiei
Treceți de la eNVM la L2-Scratch într-un executabil, așa cum se arată în figura următoare.
Figura 1.4. HSS trece de la eNVM în cod acum în L2Scratch după decompresie
Executabilul este format din trei componente:
- Stratul de abstractizare hardware (HAL), codul de nivel scăzut și driverele bare metal
- O furcă locală HSS a RISC-V OpenSBI (modificat ușor din amonte pe PIC64GX pentru AMP scopuri)
- Serviciile de rulare HSS (mașinile de stat rulează într-o super buclă)
Inițializați hardware-ul și structurile de date utilizate de OpenSBI.
Serviciul HSS „Startup” este responsabil pentru această inițializare.

Preluați imaginea încărcăturii de lucru a aplicației (payload.bin) din stocarea externă. Acest lucru este prezentat în Figura 1.5 și Figura 1.6
Important: În cazul kit-ului PIC64GX Curiosity, acesta va fi de pe un card SD.
Figura 1.5. Preluare imagine payload.bin Workload din stocarea externă
Figura 1.6. Harta memoriei HSS după preluarea payload.bin
Copiați diferitele secțiuni din payload.bin la destinațiile lor de timp de execuție. Payload.bin este o imagine formatată, care consolidează diverse imagini de aplicație pentru SMP sau AMP sarcinile de lucru. Acesta include tabele de cod, date și descriptori care permit HSS să plaseze în mod corespunzător codul și secțiunile de date, acolo unde sunt necesare pentru a rula diferitele sarcini de lucru ale aplicației.
Figura 1.7. payload.bin este copiat la adresele de destinație

Instruiți U54-urile relevante să sară la adresele de început ale execuției. Aceste informații despre adresa de pornire sunt conținute în payload.bin.
Porniți aplicația U54 harts și orice secundetage încărcătoare de încărcare. De example, U-Boot aduce Linux.

Reporniți

Legat de conceptul de pornire a sistemului este necesitatea de a reporni. Când vă gândiți la sarcinile de lucru ale aplicației PIC64GX, repornirea trebuie să ia în considerare atât multiprocesarea simetrică (SMP) cât și multiprocesarea asimetrică (AMP) scenarii:

În cazul unui sistem SMP, o repornire poate reporni în siguranță întregul sistem, deoarece nu există încărcături suplimentare de lucru într-un alt context de luat în considerare.

În cazul unui AMP sistem, o sarcină de lucru ar putea fi permisă doar să se repornească singură (și să nu interfereze cu niciun alt context) sau ar putea avea privilegiul de a putea efectua o repornire completă a sistemului.

Reporniți și AMP
Pentru a activa SMP și AMP scenarii de repornire, HSS acceptă conceptele de privilegii de repornire la cald și la rece, care sunt atribuibile unui context. Un context cu privilegiu de repornire la cald se poate reporni numai singur, iar un context cu privilegii de repornire la rece poate efectua o repornire completă a sistemului. De example, luați în considerare următorul set de scenarii reprezentative.

O sarcină de lucru SMP unică de context, care poate solicita o repornire completă a sistemului
În acest scenariu, contextului i se permite privilegiul de repornire la rece.
Un context în două AMP sarcină de lucru, unde contextul A are permisiunea să solicite o repornire completă a sistemului (care afectează toate contextele), iar contextul B are permisiunea să se repornească singur.
În acest scenariu, contextul A are privilegiul de repornire la rece, iar contextul B este permis privilegiul de repornire la cald.
Un context în două AMP sarcină de lucru, în care contextele A și B au voie doar să se repornească singure (și să nu afecteze celălalt context)
În acest scenariu, ambelor contexte sunt permise numai privilegii de repornire la cald.
Un context în două AMP sarcina de lucru, unde contextele A și B au permisiunea de a solicita repornirea completă a sistemului
În acest scenariu, ambelor contexte sunt permise privilegii de repornire la rece.
În plus, este posibil ca HSS la momentul construirii să permită întotdeauna privilegiul de repornire la rece și să nu permită niciodată privilegiul de repornire la rece.

Opțiuni relevante HSS Kconfig
Kconfig este un sistem de configurare a versiunii software. Este folosit în mod obișnuit pentru a selecta opțiunile de construcție și pentru a activa sau dezactiva funcțiile. A apărut cu nucleul Linux, dar acum și-a găsit utilizare în alte proiecte dincolo de nucleul Linux, inclusiv U-Boot, Zephyr și PIC64GX HSS.

HSS conține două opțiuni Kconfig care controlează funcționalitatea de repornire din perspectiva HSS:

CONFIG_ALLOW_REBOOTARE LA RECE
Dacă aceasta este activată, la nivel global permite unui context să emită un apel de repornire la rece. Dacă este dezactivată, vor fi permise doar repornirile la cald. Pe lângă activarea acestei opțiuni, permisiunea de a emite o repornire la rece trebuie acordată unui context prin generatorul de sarcină utilă YAML file sau următoarea opțiune Kconfig.
CONFIG_ALLOW_REPORNITARE LA RECE ÎNTOTDEAUNA
- Dacă este activată, această caracteristică la nivel global permite tuturor contextelor să emită o repornire la rece ECAA, indiferent de drepturile de semnalizare payload.bin.
- În plus, payload.bin în sine poate conține un semnalizator per context, care indică faptul că un anumit context are dreptul să emită reporniri la rece:
  - Pentru a permite un context repornire la cald, un alt context, putem adăuga opțiunea allow-reboot: warm în descrierea YAML file folosit pentru a crea payload.bin
  - Pentru a permite o repornire la rece în context a întregului sistem, putem adăuga opțiunea allow-reboot: cold. În mod implicit, fără a specifica allow-reboot, un context este permis doar repornirea la cald în sine Indiferent de setarea acestui flag, dacă CONFIG_ALLOW_COLDREBOOT nu este activat în HSS, HSS va relua toate solicitările de repornire la rece pentru a reporni la cald (per-context) .

Reporniți în detaliu
Această secțiune descrie modul în care funcționează repornirea în detaliu – începând cu stratul OpenSBI (cel mai de jos strat de mod M) și apoi discutând modul în care această funcționalitate a stratului OpenSBI este declanșată dintr-o aplicație RTOS sau un sistem de operare bogat precum Linux.

OpenSBI Reboot ecall

Specificația RISC-V Supervisor Binary Interface (SBI) descrie un strat de abstractizare hardware standardizat pentru inițializarea platformei și serviciile de rulare a firmware-ului. Scopul principal al SBI este de a permite portabilitatea și compatibilitatea între diferite implementări RISC-V.
OpenSBI (Open Source Supervisor Binary Interface) este un proiect open-source care oferă o implementare de referință a specificației SBI. OpenSBI oferă, de asemenea, servicii de rulare, inclusiv gestionarea întreruperilor, managementul temporizatorului și I/O consolă, care pot fi utilizate de straturi software de nivel superior.
OpenSBI este inclus ca parte a HSS și rulează la nivelul Machine Mode. Când sistemul de operare sau aplicația provoacă o capcană, aceasta va fi transmisă la OpenSBI pentru a o gestiona. OpenSBI expune o anumită funcționalitate de tip de apel de sistem la straturile superioare ale software-ului printr-un mecanism de capcană special numit ecall.

Resetarea sistemului (EID 0x53525354) oferă o funcție cuprinzătoare de apel de sistem care permite software-ului de nivel superior să solicite repornirea sau oprirea la nivel de sistem. Odată ce acest apel este invocat de un U54, acesta este blocat de software-ul HSS care rulează în modul Machine pe acel U54 și o solicitare de repornire corespunzătoare este trimisă către E51 pentru a reporni fie contextul, fie întregul sistem, în funcție de drepturile context.

Pentru mai multe informații, consultați Specificația interfeței binare Supervisor RISC-V în special Extensia de resetare a sistemului (EID #0x53525354 „SRST”).

Repornire Linux

Ca un ex. specificampÎn acest caz, în Linux, comanda de închidere este utilizată pentru a opri sau reporni sistemul. Comanda are de obicei multe aliasuri, și anume oprire, oprire și repornire. Aceste alias-uri specifică dacă să oprească mașina la oprire, să o oprești la oprire sau să repornești mașina la oprire.

Aceste comenzi din spațiul utilizatorului lansează un apel de repornire a sistemului Linux, care este blocat de kernel și interfuncționat la un apel SBI.
Există diferite niveluri de repornire – REBOOT_WARM, REBOOT_COLD, REBOOT_HARD – acestea pot fi transmise ca argumente de linie de comandă către kernel (de exempluample, reboot=w[arm] pentru REBOOT_WARM). Pentru mai multe informații despre codul sursă al nucleului Linux, consultați Documentație/admin-guide/kernel-paramters.txt.
Alternativ, dacă /sys/kernel/reboot este activat, handlerele de dedesubt pot fi citite pentru a obține configurația curentă de repornire a sistemului și scrise pentru a o modifica. Pentru mai multe informații despre codul sursă al nucleului Linux, consultați Documentație/ABI/testing/sysfs-kernel-reboot.

Câini de pază

Un alt concept legat de pornirea sistemului și repornirea sistemului este acela de recuperare a sistemului la declanșarea unui timer watchdog. Temporizatoarele Watchdog sunt utilizate pe scară largă în sistemele încorporate pentru a recupera automat defecțiunile hardware tranzitorii și pentru a preveni ca software-ul rătăcit sau răuvoitor să perturbe funcționarea sistemului.
PIC64GX include suport hardware watchdog pentru a monitoriza fiecare hart atunci când sistemul rulează. Cainii de pază se asigură că hart-urile pot fi repornite dacă nu răspund din cauza erorilor software irecuperabile.
PIC64GX include cinci instanțe de blocuri hardware timer-dog utilizate pentru a detecta blocările sistemului - câte unul pentru fiecare hart. Pentru a facilita multi-procesarea asimetrică mixtă (AMP) încărcături de lucru, HSS acceptă monitorizarea și reacția la tragerea câinilor de pază.

PIC64GX Watchdog

HSS este responsabil pentru pornirea aplicației harts la pornire și pentru repornirea lor (individual sau colectiv) la orice moment.tage, dacă este necesar sau dorit. Ca o consecință a acestui fapt, reacția la evenimentele watchdog de pe PIC64GX este gestionată de HSS.
Un monitor „virtual watchdog” este implementat ca un serviciu al mașinii de stare HSS, iar responsabilitățile sale sunt de a monitoriza starea fiecăruia dintre monitoarele hardware individuale de watchdog U54. Când unul dintre acești câini de pază U54 se declanșează, HSS detectează acest lucru și va reporni U54 după caz. Dacă U54 face parte dintr-un context SMP, întregul context este luat în considerare pentru repornire, având în vedere că contextul are privilegiul de repornire la cald. Întregul sistem va fi repornit dacă contextul are privilegiul de repornire la rece.

Opțiuni Kconfig relevante

Suportul Watchdog este inclus în mod implicit în versiunile HSS lansate. Dacă doriți să construiți un HSS personalizat, această secțiune va descrie mecanismul de configurare pentru a vă asigura că suportul Watchdog este activat.

HSS este configurat folosind sistemul de configurare Kconfig. Un .config de nivel superior file este necesar pentru a selecta ce servicii sunt compilate în sau în afara versiunii HSS.
În primul rând, opțiunea de nivel superior CONFIG_SERVICE_WDOG trebuie să fie activată („Suport Virtual Watchdog” prin make config).

Aceasta expune apoi următoarele subopțiuni care depind de suportul Watchdog:

CONFIG_SERVICE_WD OG_DEBUG
Activează suport pentru mesaje informative/de depanare din serviciul de supraveghere virtuală.
CONFIG_SERVICE_WD OG_DEBUG_TIMEOUT_SECS
Determină periodicitatea (în secunde) cu care mesajele de depanare Watchdog vor fi transmise de HSS.
CONFIG_SERVICE_WD OG_ENABLE_E51
Activează watchdog-ul pentru E51 monitorizează inima în plus față de U54, protejând funcționarea HSS în sine.

Când Watchdog-ul E51 este activat, HSS-ul va scrie periodic Watchdog-ului pentru a-l reîmprospăta și a preveni declanșarea acestuia. Dacă, dintr-un motiv oarecare, inima E51 se blochează sau se prăbușește, iar watchdog-ul E51 este activat, acest lucru va reseta întotdeauna întregul sistem.

Operațiunea de supraveghere
Hardware-ul watchdog implementează contoare inverse. O fereastră de reîmprospătare interzisă poate fi creată prin configurarea valorii maxime până la care este permisă reîmprospătarea (MVRP).

Când valoarea curentă a temporizatorului watchdog este mai mare decât valoarea MVRP, reîmprospătarea watchdog-ului este interzisă. Încercarea de a reîmprospăta temporizatorul watchdog în fereastra interzisă va afirma o întrerupere de timeout.

Reîmprospătarea watchdog-ului între valoarea MVRP și Trigger Value (TRIG) va reîmprospăta cu succes contorul și va împiedica watchdog-ul să declanșeze.
Odată ce valoarea timer-ului watchdog contează sub valoarea TRIG, watchdog-ul va declanșa.

Watchdog State Machine

Mașina de stare watchdog este foarte simplă – pornește prin configurarea watchdog-ului pentru E51, dacă este activată, apoi trece printr-o stare inactivă în monitorizare. De fiecare dată în jurul superbuclei, această stare de monitorizare este invocată, care verifică starea fiecăruia dintre watchdog-urile U54.

Mașina de stare watchdog interacționează cu mașina de stare de pornire pentru a reporni un hart (și orice alt hart care se află în setul său de boot), dacă detectează că hart nu a reușit să-și reîmprospăteze watchdog-ul la timp.

Modul de blocare

În mod normal (mai ales cu AMP aplicații), este de așteptat ca HSS să rămână rezident în modul M, pe un U54, pentru a permite repornirea per-context (adică repornirea unui singur context, fără repornire completă a cipului) și pentru a permite HSS să monitorizeze starea de sănătate ( ECC-uri, biți de stare de blocare, erori de magistrală, erori SBI, încălcări PMP etc.).

Pentru a oferi capabilități de repornire pe o per-AMP pe baza contextului (fără a necesita repornirea întregului sistem), E51 are în mod normal acces privilegiat la memorie la întregul spațiu de memorie al sistemului. Cu toate acestea, pot exista situații în care acest lucru nu este de dorit, iar clientul poate prefera să restricționeze ceea ce face firmware-ul E51 HSS odată ce sistemul a pornit cu succes. În acest caz, este posibil să puneți HSS-ul în modul de blocare odată ce aplicația U54 Harts a fost pornită.

Acest lucru poate fi activat utilizând opțiunea HSS Kconfig CONFIG_SERVICE_LOCKDOWN.
Serviciul de blocare este destinat să permită restricționarea activităților HSS după ce pornește aplicația U54 Harts.

Figura 4.2. Modul de blocare HSS

Odată ce pornește modul Lockdown, oprește rularea tuturor celorlalte mașini de stare a serviciului HSS. Ea denumește două funcții slab legate:

e51_pmp_lockdown() și
e51_lockdown()

Aceste funcții sunt destinate să fie înlocuite de codul specific plăcii. Prima este o funcție de declanșare configurabilă pentru a permite unui BSP să personalizeze blocarea E51 de la încărcăturile utile ale aplicației în acest moment. Implementarea implicită slab legată a acestei funcții este goală. Al doilea este funcționalitatea care este rulată din acel punct înainte. Implementarea implicită slab legată deservește watchdog-ul în acest moment al E51 și va reporni dacă se declanșează un watchdog U54. Pentru mai multe informații, consultați codul sursă HSS în servicii/lockdown/lockdown_service.c file.

Apendice

Format HSS payload.bin

Această secțiune descrie payload.bin file format și imaginea folosită de HSS pentru a porni PIC64GX SMP și AMP aplicatii.
Payload.bin este un binar formatat (Figura A.10) format dintr-un cap, diverse tabele de descriptori și diverse bucăți care conțin codul și secțiunile de date ale fiecărei părți a volumului de lucru al aplicației. O bucată poate fi considerată ca un bloc de memorie de dimensiuni arbitrare.

Figura A.10. payload.bin Format

Porțiunea antet (prezentată în Figura A.11) conține o valoare magică folosită pentru a identifica payload.bin și unele informații de întreținere, împreună cu detaliile imaginii care urmează să fie rulată pe fiecare dintre
coduri de aplicație U54. Descrie cum să pornești fiecare hart U54 individual și setul de imagini bootabile în general. În informațiile sale de întreținere, are indicatoare către diferite tabele de descriptori pentru a permite creșterea dimensiunii antetului.

Figura A.11. payload.bin Antet

Codul și datele constante inițializate sunt considerate doar pentru citire și stocate într-o secțiune doar pentru citire, care este indicată de descriptorii de antet.
Variabilele de date inițializate diferite de zero sunt date de citire-scriere, dar valorile lor de inițializare sunt copiate din fragmentul de numai citire la pornire. Acestea sunt stocate și în secțiunea numai pentru citire.

Secțiunea de date de încărcare utilă numai în citire este descrisă de un tabel de descriptori de cod și de fragmente de date. Fiecare descriptor de bucată din acest tabel conține un „proprietar hart” (principalul hart în contextul în care este vizat
at), un offset de încărcare (offset în payload.bin) și o adresă de execuție (adresă de destinație în memoria PIC64GX), împreună cu o dimensiune și o sumă de control. Acest lucru este prezentat în Figura A.12.

Figura A.12. Descriptor de fragmente numai pentru citire și date despre fragmente de încărcare utilă

În plus față de bucățile menționate mai sus, există și bucăți de memorie corespunzătoare variabilelor de date care sunt inițializate la zero. Acestea nu sunt stocate ca date în payload.bin, ci sunt în schimb un set special de descriptori de bucăți inițializați cu zero, care specifică o adresă și lungimea RAM pentru a se seta la zero în timpul pornirii. Acest lucru este prezentat în Figura A.13.

Figura A.13. ZI Bucăți

hss-generator de sarcină utilă
Instrumentul HSS Payload Generator creează o imagine formatată a sarcinii utile pentru Hart Software Service zero-stage bootloader pe PIC64GX, având o configurație file și un set de ELF files și/sau binare. Configurația file este folosit pentru a mapa binarele ELF sau blob-urile binare la aplicațiile individuale (U54s).

Figura B.14. Fluxul generatorului de sarcină utilă hss

Instrumentul efectuează verificări de bază asupra structurii configurației file în sine și pe imaginile ELF. Imaginile ELF trebuie să fie executabile RISC-V.

Example Run

Pentru a rula instrumentul hss-payload-generator cu sampconfigurația fișierului file și ELF files:
$ ./hss-payload-generator -c test/config.yaml output.bin
Pentru a imprima diagnostice despre o imagine preexistentă, utilizați:
$ ./hss-payload-generator -d output.bin

Pentru a activa autentificarea securizată de pornire (prin semnarea imaginii), utilizați -p pentru a specifica locația unei chei private X.509 pentru curba eliptică P-384 (SECP384r1):
$ ./hss-payload-generator -c test/config.yaml payload.bin -p /path/to/private.pem

Pentru mai multe informații, consultați documentația Secure Boot Authentication.

Config File Example

În primul rând, putem seta opțional un nume pentru imaginea noastră, în caz contrar, unul va fi creat dinamic:
set-name: 'PIC64-HSS::TestImage'
În continuare, vom defini adresele punctelor de intrare pentru fiecare inimă, după cum urmează:
hart-entry-points: {u54_1: ‘0x80200000’, u54_2: ‘0x80200000’, u54_3: ‘0xB0000000′, u54_4:’0x80200000’}

Imaginile sursă ELF pot specifica un punct de intrare, dar dorim să fim capabili să acceptăm puncte de intrare secundare pentru harts dacă este necesar, de exempluample, dacă mai multe hart-uri sunt destinate să pornească aceeași imagine, acestea ar putea avea puncte de intrare individuale. Pentru a sprijini acest lucru, specificăm adresele reale ale punctelor de intrare în configurație file în sine.

Putem defini acum câteva sarcini utile (sursa ELF files, sau blob-uri binare) care vor fi plasate în anumite regiuni din memorie. Secțiunea de încărcare utilă este definită cu cuvântul cheie încărcături utile și apoi un număr de descriptori individuali a sarcinii utile. Fiecare sarcină utilă are un nume (calea către file), un proprietar-hart și, opțional, 1 până la 3 secundare.

În plus, o sarcină utilă are un mod de privilegii în care va începe execuția. Modurile de privilegii valide sunt PRV_M, PRV_S și PRV_U, unde acestea sunt definite ca:

PRV_M Mod mașină
PRV_S Mod supervizor
PRV_U Mod utilizator

În examppe:

test/zephyr.elf se presupune a fi o aplicație Zephyr care rulează în U54_3 și se așteaptă să pornească în modul de privilegiu PRV_M.
test/u-boot-dtb.bin este aplicația de bootloader Das U-Boot și rulează pe U54_1, U54_2 și U54_4. Se așteaptă să înceapă în modul de privilegiu PRV_S.

Important:
Ieșirea U-Boot creează un ELF file, dar de obicei nu pune înaintea extensiei .elf. În acest caz, este utilizat binarul creat de CONFIG_OF_SEPARATE, care adaugă un blob arbore de dispozitiv la binarul U-Boot.

Iata example Configurarea sarcinilor utile file:

test/zephyr.elf:
{exec-addr: '0xB0000000', owner-hart: u54_3, priv-mode: prv_m, skip-opensbi: true}
test/u-boot-dtb.bin:
{exec-addr: '0x80200000', proprietar-hart: u54_1, secundar-hart: u54_2, secundar-hart: u54_4,priv-mode: prv_s}

Important:
Cazul contează doar pentru file numele căilor, nu cuvintele cheie. Deci, de exemplu, u54_1 este considerat la fel cu U54_1, iar exec-addr este considerat la fel cu EXEC-ADDR. Dacă este prezentă o extensie.elf sau .bin, aceasta trebuie inclusă în configurație file.

Pentru o aplicație bare metal care nu dorește să fie preocupată de OpenSBI, opțiunea skip-opens, dacă este adevărată, va face ca sarcina utilă de pe acea inimă să fie invocată folosind un simplu mret, mai degrabă
decât un apel OpenSBI sbi_init(). Aceasta înseamnă că inima va începe să ruleze codul bare metal, indiferent de orice considerente OpenSBI HSM. Rețineți că acest lucru înseamnă, de asemenea, că inima nu poate utiliza
ecalls pentru a invoca funcționalitatea OpenSBI. Opțiunea skip-deschide este opțională și implicit este false.

Pentru a permite o repornire la cald în context a altui context, putem adăuga opțiunea permite repornire: cald. Pentru a permite o repornire la rece în context a întregului sistem, putem adăuga opțiunea allow-reboot: cold. În mod implicit, fără a specifica allow-reboot, unui context i se permite doar să repornească la cald.
De asemenea, este posibil să se asocieze date auxiliare cu fiecare sarcină utilă, de example, un DeviceTree Blob (DTB) file, prin precizarea datelor auxiliare filedenumește după cum urmează:
test/u-boot.bin: { exec-addr: '0x80200000', owner-hart: u54_1, secondary-hart: u54_2, secondary-hart: u54_3, secondary-hart: u54_4, priv-mode: prv_s, date auxiliare : test/pic64gx.dtb }
Aceste date auxiliare vor fi incluse în sarcina utilă (plasată imediat după cea principală file în executabil
space), iar adresa sa va fi transmisă la OpenSBI în câmpul next_arg1 (tresată în registrul $a1 imaginii la momentul pornirii).

Pentru a împiedica HSS să pornească automat un context (de exemplu, dacă în schimb dorim să delegăm controlul acestuia unui context folosind remoteProc), utilizați steag-ul skip-autoboot:
test/zephyr.elf: {exec-addr: '0xB0000000', owner-hart: u54_3, priv-mode: prv_m, skip-opensbi: true, skip-autoboot: true}
În cele din urmă, putem opțional suprascrie numele sarcinilor utile individuale, utilizând opțiunea nume de încărcare. De examppe:
test/u-boot.bin: { exec-addr: '0x80200000', owner-hart: u54_1, secondary-hart: u54_2, secondary-hart: u54_3, secondary-hart: u54_4, priv-mode: prv_s, date auxiliare : test/pic64gx.dtb, nume-încărcare: „u-boot” }

Rețineți că constructorii Yocto și Buildroot Linux vor construi, configura și rula hss-payload-
generator după cum este necesar pentru a genera imagini ale aplicației. În plus, pic64gx-curiosity-kit-amp ținta mașinii din Yocto va genera o imagine a aplicației folosind instrumentul hss-payload-generator care demonstrează AMP, cu Linux rulând pe 3 hart și Zephyr rulând pe 1 hart.

Istoricul revizuirilor
Istoricul revizuirilor descrie modificările care au fost implementate în document. Modificările sunt listate după revizuire, începând cu cea mai recentă publicație.

Revizuire	Data	Descriere
A	07/2024	Revizuirea inițială

Informații despre microcip

Microcipul Website-ul
Microcip oferă suport online prin intermediul nostru website la www.microchip.com/. Acest website-ul este folosit pentru a face files și informații ușor accesibile clienților. Unele dintre conținuturile disponibile includ:

Suport pentru produse – Fișe de date și errate, note de aplicare și sampprogramele, resursele de proiectare, ghidurile utilizatorului și documentele de suport hardware, cele mai recente versiuni de software și software arhivat

Suport tehnic general – Întrebări frecvente (FAQs), solicitări de asistență tehnică, grupuri de discuții online, lista de membri ai programului de parteneri de design Microchip
Afacerea Microcipului – Selector de produse și ghiduri de comandă, ultimele comunicate de presă Microchip, o listă de seminarii și evenimente, liste cu birouri de vânzări, distribuitori și reprezentanți ai fabricii Microchip

Serviciul de notificare privind schimbările de produs

Serviciul de notificare de modificare a produselor Microchip ajută la menținerea clienților la curent cu produsele Microchip. Abonații vor primi notificări prin e-mail ori de câte ori apar modificări, actualizări, revizuiri sau erori legate de o anumită familie de produse sau instrument de dezvoltare de interes.

Pentru a vă înscrie, accesați www.microchip.com/pcn și urmați instrucțiunile de înregistrare.

Asistență pentru clienți
Utilizatorii produselor Microchip pot primi asistență prin mai multe canale:

Distribuitor sau Reprezentant
Biroul local de vânzări
Inginer de soluții integrate (ESE)
Suport tehnic

Clienții trebuie să-și contacteze distribuitorul, reprezentantul sau ESE pentru asistență. Birourile de vânzări locale sunt, de asemenea, disponibile pentru a ajuta clienții. O listă a birourilor și locațiilor de vânzări este inclusă în acest document.
Suportul tehnic este disponibil prin intermediul website la: www.microchip.com/support.

Caracteristica de protecție a codului dispozitivelor cu microcip
Rețineți următoarele detalii despre caracteristica de protecție a codului de pe produsele Microcip:

Produsele cu microcip îndeplinesc specificațiile conținute în fișa lor specială pentru microcip.
Microchip consideră că familia sa de produse este sigură atunci când este utilizată în modul prevăzut, în cadrul specificațiilor de funcționare și în condiții normale.

Microcipul apreciază și își protejează în mod agresiv drepturile de proprietate intelectuală. Încercările de a încălca funcțiile de protecție prin cod ale produselor Microchip sunt strict interzise și pot încălca Digital Millennium Copyright Act.
Nici Microcip și nici alt producător de semiconductori nu poate garanta securitatea codului său. Protecția prin cod nu înseamnă că garantăm că produsul este „incasibil”. Protecția prin cod este în continuă evoluție. Microchip se angajează să îmbunătățească continuu caracteristicile de protecție prin cod ale produselor noastre.

Aviz legal
Această publicație și informațiile de aici pot fi utilizate numai cu produsele Microchip, inclusiv pentru proiectarea, testarea și integrarea produselor Microchip cu aplicația dumneavoastră. Utilizarea acestor informații în orice alt mod încalcă acești termeni. Informațiile referitoare la aplicațiile dispozitivului sunt furnizate numai pentru confortul dvs. și pot fi înlocuite de actualizări. Este responsabilitatea dumneavoastră să vă asigurați că aplicația dumneavoastră corespunde specificațiilor dumneavoastră. Contactați biroul local de vânzări Microchip pentru asistență suplimentară sau obțineți asistență suplimentară la www.microchip.com/en-us/support/design-help/client-support-services.

ACESTE INFORMAȚII ESTE FURNIZATE DE MICROCHIP „CA AȘA ESTE”. MICROCHIP NU OFERĂ DECLARAȚII SAU GARANȚII DE NICIUN FEL, EXPRESE SAU IMPLICITE, SCRISE SAU ORALE, LEGALE SAU DE ALTE ALTE, LEGATE DE INFORMAȚII INCLUSIVĂ, DAR FĂRĂ A SE LIMITA LA NICIO GARANȚIE IMPLICITĂ DE NEÎNCĂLCARE, COMERCIALITATE ȘI PARTICIBILITATE, PENTRU O PUBLICABILITATE. GARANȚII LEGATE DE STARE, CALITATE SAU PERFORMANȚĂ.

MICROCHIP NU VA FI RESPONSABIL ÎN NICIUN CAZ PENTRU PIERDERI INDIRECTE, SPECIALE, PUNITIVE, INCIDENTALE SAU CONSECUȚIONALE, DAUNE, COST SAU CHELTUIELI DE NICIUN FEL LEGATE DE INFORMAȚII SAU DE UTILIZAREA ACESTELOR, ORICARE CAUZATE, CHIAR DACĂ FUN ASPECT. POSIBILITATEA SAU DAUNEI SUNT PREVIZIBILE. ÎN MĂSURA TOTALĂ PERMISĂ DE LEGE, RESPONSABILITATEA TOTALĂ A MICROCHIP PENTRU TOATE RECLAȚIILE ÎN ORICE MOD LEGATE DE INFORMAȚII SAU DE UTILIZAREA EI NU VA DEPĂȘI NUMĂRUL DE TAXE, DACĂ CAZ, PE CARE LE-AȚI PLATIT DIRECT LA MICROCHIP PENTRU INFORMAȚII.

Utilizarea dispozitivelor Microcip în aplicații de susținere a vieții și/sau de siguranță este în întregime pe riscul cumpărătorului, iar cumpărătorul este de acord să apere, să despăgubească și să țină inofensiv Microchip de toate daunele, pretențiile, procesele sau cheltuielile rezultate din această utilizare. Nicio licență nu este transmisă, implicit sau în alt mod, în baza niciunui drept de proprietate intelectuală Microchip, cu excepția cazului în care se specifică altfel.

Mărci comerciale
Numele și sigla Microcipului, sigla Microcipului, Adaptec, AVR, sigla AVR, AVR Freaks, BesTime, BitCloud, CryptoMemory, CryptoRF, dsPIC, flexPWR, HELDO, IGLOO, JukeBlox, KeeLoq, Kleer, LANCheck, LinkMD, maXStyluuchs, MediaLB, megaAVR, Microsemi, sigla Microsemi, MOST, sigla MOST, MPLAB, OptoLyzer, PIC, picoPower, PICSTART, sigla PIC32, PolarFire, Prochip Designer, QTouch, SAM-BA, SenGenuity, SpyNIC, SST, SST Logo, SuperFlash, Symmetricom , SyncServer, Tachyon, TimeSource, tinyAVR, UNI/O, Vectron și XMEGA sunt mărci comerciale înregistrate ale Microchip Technology Incorporated în SUA și în alte țări.

AgileSwitch, ClockWorks, The Embedded Control Solutions Company, EtherSynch, Flashtec, Hyper Speed Control, HyperLight Load, Libero, banc motor, mTouch, Powermite 3, Precision Edge, ProASIC, ProASIC Plus, logo-ul ProASIC Plus, Quiet-Wire, SmartFusion, SyncWorld , TimeCesium, TimeHub, TimePictra, TimeProvider și ZL sunt mărci comerciale înregistrate ale Microchip Technology Incorporated în SUA

Suprimarea tastelor adiacente, AKS, Analog-for-the-Digital Age, Any Capacitor, AnyIn, AnyOut, Augmented Switching, BlueSky, BodyCom, Clockstudio, CodeGuard, CryptoAuthentication, CryptoAutomotive, CryptoCompanion, CryptoController, dsPICDEM, dsPICDEM Averagenet, Dynamic Media Matching. , DAM, ECAN, Espresso T1S, EtherGREEN, EyeOpen, GridTime, IdealBridge,
IGaT, programare serială în circuit, ICSP, INICnet, paralelizare inteligentă, IntelliMOS, conectivitate între cipuri, JitterBlocker, buton pe afișaj, MarginLink, maxCrypto, maxView, memBrain, Mindi, MiWi, MPASM, MPF, sigla MPLAB Certified, 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, hartă simplă, SimpliPHY, SmartBuffer, SmartHLS, SMART-IS, storClad, SQI, SuperSwitcher, SuperSwitcher II, Switchtec, SynchroPHY, Total Rezistență, Timp de încredere, TSHARC, Turing, USBCheck, VariSense, VectorBlox, VeriPHY, ViewSpan, WiperLock, XpressConnect și ZENA sunt mărci comerciale ale Microchip Technology Incorporated în SUA și în alte țări.

SQTP este o marcă de serviciu a Microchip Technology Incorporated din SUA
Sigla Adaptec, Frequency on Demand, Silicon Storage Technology și Symmcom sunt mărci comerciale înregistrate ale Microchip Technology Inc. în alte țări.
GestIC este o marcă înregistrată a Microchip Technology Germany II GmbH & Co. KG, o subsidiară a Microchip Technology Inc., în alte țări.

ISBN: 978-1-6683-4890-1

Sistemul de management al calității
Pentru informații despre sistemele de management al calității Microchip, vă rugăm să vizitați www.microchip.com/quality.

Vânzări și service la nivel mondial

AMERICII

ASIA/PACIFIC

EUROPA

Corporativ Birou

2355 West Chandler Blvd. Chandler, AZ 85224-6199

Tel: 480-792-7200

Fax: 480-792-7277

Suport tehnic: www.microchip.com/support

Web Adresa: www.microchip.com

Atlanta

Duluth, GA

Tel: 678-957-9614

Fax: 678-957-1455

Austin, TX

Tel: 512-257-3370

Boston

Westborough, MA Tel: 774-760-0087

Fax: 774-760-0088

Chicago

Itasca, IL

Tel: 630-285-0071

Fax: 630-285-0075

Dallas

Addison, TX

Tel: 972-818-7423

Fax: 972-818-2924

Detroit

Novi, MI

Tel: 248-848-4000

Houston, TX

Tel: 281-894-5983

Indianapolis

Noblesville, IN Tel: 317-773-8323

Fax: 317-773-5453

Tel: 317-536-2380

Los Angeles

Mission Viejo, CA Tel: 949-462-9523

Fax: 949-462-9608

Tel: 951-273-7800

Raleigh, NC

Tel: 919-844-7510

New York, NY

Tel: 631-435-6000

San Jose, CA

Tel: 408-735-9110

Tel: 408-436-4270

Canada – Toronto

Tel: 905-695-1980

Fax: 905-695-2078

Australia – Sydney

Tel: 61-2-9868-6733

China – Beijing

Tel: 86-10-8569-7000

China – Chengdu

Tel: 86-28-8665-5511

China – Chongqing

Tel: 86-23-8980-9588

China – Dongguan

Tel: 86-769-8702-9880

China – Guangzhou

Tel: 86-20-8755-8029

China – Hangzhou

Tel: 86-571-8792-8115

China – Hong Kong SAR

Tel: 852-2943-5100

China – Nanjing

Tel: 86-25-8473-2460

China – Qingdao

Tel: 86-532-8502-7355

China – Shanghai

Tel: 86-21-3326-8000

China – Shenyang

Tel: 86-24-2334-2829

China – Shenzhen

Tel: 86-755-8864-2200

China – Suzhou

Tel: 86-186-6233-1526

China – Wuhan

Tel: 86-27-5980-5300

China – Xian

Tel: 86-29-8833-7252

China – Xiamen

Tel: 86-592-2388138

China – Zhuhai

Tel: 86-756-3210040

India – Bangalore

Tel: 91-80-3090-4444

India – New Delhi

Tel: 91-11-4160-8631

India – Pune

Tel: 91-20-4121-0141

Japonia – Osaka

Tel: 81-6-6152-7160

Japonia – Tokyo

Tel: 81-3-6880- 3770

Coreea – Daegu

Tel: 82-53-744-4301

Coreea – Seul

Tel: 82-2-554-7200

Malaezia – Kuala Lumpur

Tel: 60-3-7651-7906

Malaezia – Penang

Tel: 60-4-227-8870

Filipine – Manila

Tel: 63-2-634-9065

Singapore

Tel: 65-6334-8870

Taiwan – Hsin Chu

Tel: 886-3-577-8366

Taiwan – Kaohsiung

Tel: 886-7-213-7830

Taiwan – Taipei

Tel: 886-2-2508-8600

Tailanda – Bangkok

Tel: 66-2-694-1351

Vietnam – Ho Chi Minh

Tel: 84-28-5448-2100

Austria – Wels

Tel: 43-7242-2244-39

Fax: 43-7242-2244-393

Danemarca – Copenhaga

Tel: 45-4485-5910

Fax: 45-4485-2829

Finlanda – Espoo

Tel: 358-9-4520-820

Franţa – Paris

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

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

Germania – Garching

Tel: 49-8931-9700

Germania – Haan

Tel: 49-2129-3766400

Germania – Heilbronn

Tel: 49-7131-72400

Germania – Karlsruhe

Tel: 49-721-625370

Germania – Munchen

Tel: 49-89-627-144-0

Fax: 49-89-627-144-44

Germania – Rosenheim

Tel: 49-8031-354-560

Israel – Hod Hasharon

Tel: 972-9-775-5100

Italia – Milano

Tel: 39-0331-742611

Fax: 39-0331-466781

Italia – Padova

Tel: 39-049-7625286

Olanda – Drunen

Tel: 31-416-690399

Fax: 31-416-690340

Norvegia – Trondheim

Tel: 47-72884388

Polonia – Varșovia

Tel: 48-22-3325737

România – Bucureşti

Tel: 40-21-407-87-50

Spania – Madrid

Tel: 34-91-708-08-90

Fax: 34-91-708-08-91

Suedia – Göteborg

Tel: 46-31-704-60-40

Suedia – Stockholm

Tel: 46-8-5090-4654

Marea Britanie – Wokingham

Tel: 44-118-921-5800

Fax: 44-118-921-5820

Documente/Resurse

MICROCHIP PIC64GX Microprocesor Quad-Core RISC-V pe 64 de biți [pdfGhid de utilizare
PIC64GX, PIC64GX Microprocesor Quad-Core RISC-V pe 64 de biți, Microprocesor Quad-Core RISC-V pe 64 de biți, Microprocesor Quad-Core RISC-V, Microprocesor Quad-Core, Microprocesor

Referințe

Manual de utilizare

MICROCHIP PIC64GX Microprocesor Quad-Core RISC-V pe 64 de biți

Informații despre produs

Instrucțiuni de utilizare a produsului