Guia d'usuari del microprocessador de quatre nuclis RISC-V MICROCHIP PIC64GX de 64 bits

Procés d'arrencada
1. Components de programari implicats en l'arrencada
  El procés d'arrencada del sistema implica els components de programari següents:
  - Hart Software Services (HSS): un zero-stage carregador d'arrencada, monitor del sistema i proveïdor de serveis d'execució per a aplicacions.
2. Flux d'arrencada
  La seqüència del flux d'arrencada del sistema és la següent:
  1. Inicialització dels serveis de programari Hart (HSS)
  2. Execució del carregador d'arrencada
  3. Inici de l'aplicació
Gossos de vigilància
1. PIC64GX Watchdog
  El PIC64GX inclou una funció de control per supervisar el funcionament del sistema i activar accions en cas de fallades del sistema.
Mode de bloqueig
El mode de bloqueig està dissenyat per als clients que requereixen un control complet sobre les accions del sistema després de l'arrencada. Limita les funcionalitats del monitor del sistema E51.

Preguntes freqüents

P: Quin és l'objectiu dels serveis de programari Hart (HSS)?
R: L'HSS serveix com a zero-stage carregador d'arrencada, monitor del sistema i proveïdor de serveis d'execució per a aplicacions durant el procés d'arrencada.
P: Com funciona la funció de control PIC64GX?
R: El vigilant PIC64GX supervisa el funcionament del sistema i pot prendre accions predefinides en cas de fallades del sistema per garantir la fiabilitat del sistema.

Introducció

Aquest document blanc explica com el Microchip PIC64GX arrenca les càrregues de treball de l'aplicació i descriu el procés d'arrencada del sistema, que funciona igual per a SMP i AMP càrregues de treball. A més, cobreix com funciona un reinici per a SMP i AMP càrregues de treball, controls al PIC64GX i un mode de bloqueig especial per als sistemes on els clients desitgen un control complet per limitar les accions del monitor del sistema E51 després de l'arrencada del sistema.

Procés d'arrencada

Fem una ullada als diferents components del programari implicats en l'arrencada del sistema, seguit d'una visió més detallada de la seqüència del propi flux d'arrencada del sistema.

Components de programari implicats en l'arrencada
Els components següents participen en el procés d'arrencada del sistema:

Figura 1.1. Components d'arrencada

Serveis de programari Hart (HSS)
Els serveis de programari Hart (HSS) són zero-stagun carregador d'arrencada, un monitor del sistema i un proveïdor de serveis d'execució per a aplicacions. L'HSS admet la configuració primerenca del sistema, la formació DDR i la inicialització/configuració de maquinari. S'executa principalment als E51, amb una petita quantitat de funcionalitats a nivell de mode màquina que s'executa a cada U54. Engega un o més contextos carregant la "càrrega útil" de l'aplicació des del mitjà d'arrencada i proporciona serveis de temps d'execució de la plataforma/entorn d'execució del supervisor (SEE) per als nuclis del sistema operatiu. Admet l'arrencada segura i és un component important per garantir la partició/separació del maquinari AMP contextos.

Das U-Boot (U-Boot)
Das U-Boot (U-Boot) és un carregador d'arrencada universal amb scripts de codi obert. Admet una CLI senzilla que pot recuperar la imatge d'arrencada des de diverses fonts (incloent-hi una targeta SD i la xarxa). U-Boot carrega Linux. Pot proporcionar un entorn UEFI si cal. En general, està acabat i fora del camí un cop arrencat Linux, és a dir, no es manté com a resident després de l'arrencada.
Nucli de Linux
El nucli Linux és el nucli del sistema operatiu més popular del món. Combinat amb un territori d'aplicacions d'usuaris, forma el que comunament es coneix com a sistema operatiu Linux. Un sistema operatiu Linux ofereix API POSIX riques i un entorn de desenvolupador, per exempleample, llenguatges i eines com Python, Perl, Tcl, Rust, C/C++ i Tcl; biblioteques com OpenSSL, OpenCV, OpenMP, OPC/UA i OpenAMP (RPmsg i RemoteProc).
Yocto i Buildroot són creadors de sistemes Linux, és a dir, es poden utilitzar per generar sistemes Linux personalitzats a mida. Yocto produeix una distribució Linux amb un ric
conjunt d'aplicacions, eines i biblioteques, i gestió de paquets opcional. Buildroot genera una arrel més mínima filesistema i pot orientar sistemes que no requereixen emmagatzematge persistent però que s'executen completament des de la memòria RAM (utilitzant el suport d'inicials de Linux, per exempleample).

Zèfir
Zephyr és un petit sistema operatiu en temps real (RTOS) de codi obert. Proporciona un marc de baix cost general en temps real, amb canals de comunicació RPMsg-lite a Linux. Inclou un nucli, biblioteques, controladors de dispositius, piles de protocols, filesistemes, mecanismes per a actualitzacions de microprogramari, etc., i és ideal per als clients que volen una experiència més semblant a un metall nu al PIC64GX.

Flux d'arrencada
PIC64GX inclou un coreplex RISC-V amb un hart de monitor del sistema E64 de 51 bits i 4 harts d'aplicacions U64 de 54 bits. En terminologia RISC-V, un hart és un context d'execució RISC-V que conté un conjunt complet de registres i que executa el seu codi de manera independent. Podeu pensar-ho com un fil de maquinari o una sola CPU. Un grup de cers dins d'un sol nucli sovint s'anomena complex. Aquest tema descriu els passos per inicialitzar el coreplex PIC64GX, inclòs el sistema E51 que monitoritza el cor i l'aplicació U54.

Enceneu el coreplex PIC64GX.
A l'encesa, tots els harts del coreplex RISC-V són alliberats del restabliment pel controlador de seguretat.
Executeu el codi HSS des de la memòria flash eNVM del xip.
Inicialment, cada cor comença a executar el codi HSS des de la memòria flash eNVM del xip. Aquest codi fa que tots els harts d'aplicacions U54 girin, esperant instruccions i permet que l'E51 monitor hart comenci a executar el codi per inicialitzar i mostrar el sistema.

Descomprimiu el codi HSS d'eNVM a la memòria L2-Scratch.
Depenent de la seva configuració en temps de compilació, l'HSS sol ser més gran que la capacitat de la memòria flaix d'eNVM i, per tant, el primer que fa el codi HSS que s'executa a l'E51 és descomprimir-se d'eNVM a la memòria L2-Scratch, tal com es mostra a la figura. 1.2 i figura 1.3.
Figura 1.2. HSS descomprimeix d'eNVM a Scratch L2
Figura 1.3. Mapa de memòria HSS durant la descompressió
Salta d'eNVM a L2-Scratch a un executable tal com es mostra a la figura següent.
Figura 1.4. HSS salta d'eNVM al codi ara a L2Scratch després de la descompressió
L'executable consta de tres components:
- La capa d'abstracció de maquinari (HAL), codi de baix nivell i controladors de metall nu
- Una bifurcació HSS local de RISC-V OpenSBI (modificada lleugerament des de aigües amunt a PIC64GX per AMP finalitats)
- Els serveis d'execució HSS (les màquines d'estat s'executen en un súper bucle)
Inicialitzar el maquinari i les estructures de dades utilitzades per OpenSBI.
El servei HSS "Startup" és el responsable d'aquesta inicialització.

Obteniu la imatge de càrrega de treball de l'aplicació (payload.bin) de l'emmagatzematge extern. Això es mostra a la figura 1.5 i la figura 1.6
Important: en el cas del kit de curiositat PIC64GX, serà d'una targeta SD.
Figura 1.5. S'està obtenint la imatge de càrrega de treball de payload.bin des d'emmagatzematge extern
Figura 1.6. Mapa de memòria HSS després d'obtenir payload.bin
Copieu les diferents seccions de payload.bin a les seves destinacions d'execució. El payload.bin és una imatge formatada, que consolida diverses imatges d'aplicacions per a SMP o AMP càrregues de treball. Inclou taules de codi, dades i descriptors que permeten a l'HSS col·locar adequadament el codi i les seccions de dades, on es necessiten per executar les diferents càrregues de treball de l'aplicació.
Figura 1.7. payload.bin es copia a les adreces de destinació

Doneu instruccions als U54 rellevants perquè saltin a les adreces d'inici de l'execució. Aquesta informació de l'adreça inicial es troba a payload.bin.
Inicieu l'aplicació U54 harts i qualsevol segontage carregadors d'arrencada. Per example, U-Boot fa aparèixer Linux.

Reinicieu

Relacionat amb el concepte d'arrencada del sistema, hi ha la necessitat de reiniciar. Quan es pensa en les càrregues de treball de l'aplicació PIC64GX, el reinici ha de tenir en compte tant el multiprocessament simètric (SMP) com el multiprocessament asimètric (AMP) escenaris:

En el cas d'un sistema SMP, un reinici pot reiniciar en fred tot el sistema de manera segura, ja que no hi ha càrregues de treball addicionals a tenir en compte en un altre context.

En el cas d'un AMP sistema, es pot permetre que una càrrega de treball només es reiniciï (i no interfereixi amb cap altre context), o pot tenir privilegis per poder realitzar un reinici complet del sistema.

Reinicieu i AMP
Per habilitar l'SMP i AMP escenaris de reinici, l'HSS admet els conceptes de privilegis de reinici en calent i en fred, que es poden assignar a un context. Un context amb privilegi de reinici en calent només es pot reiniciar, i un context amb privilegi de reinici en fred pot realitzar un reinici complet del sistema. Per exampi, considereu el següent conjunt d'escenaris representatius.

Una única càrrega de treball SMP de context, que es permet sol·licitar un reinici complet del sistema
En aquest escenari, el context té el privilegi de reinici en fred.
Un dos context AMP càrrega de treball, on el context A pot sol·licitar un reinici complet del sistema (afectant tots els contextos) i el context B només es pot reiniciar.
En aquest escenari, el context A té el privilegi de reinici en fred i el context B té el privilegi de reinici en calent.
Un dos context AMP càrrega de treball, on els contextos A i B només poden reiniciar-se (i no afectar l'altre context)
En aquest escenari, ambdós contextos només es permeten privilegis de reinici en calent.
Un dos context AMP càrrega de treball, on els contextos A i B poden sol·licitar el reinici complet del sistema
En aquest escenari, ambdós contextos tenen privilegis de reinici en fred.
A més, és possible que l'HSS en temps de construcció permeti sempre el privilegi de reinici en fred i mai no permeti el privilegi de reinici en fred.

Opcions HSS Kconfig rellevants
Kconfig és un sistema de configuració de creació de programari. S'utilitza habitualment per seleccionar opcions de temps de creació i per habilitar o desactivar funcions. Es va originar amb el nucli de Linux, però ara ha trobat ús en altres projectes més enllà del nucli de Linux, com ara U-Boot, Zephyr i el PIC64GX HSS.

L'HSS conté dues opcions de Kconfig que controlen la funcionalitat de reinici des de la perspectiva de l'HSS:

CONFIG_ALLOW_COLD RESTART
Si està habilitat, permet que un context emeti una trucada de reinici en fred de manera global. Si està desactivat, només es permetran els reinicis en calent. A més d'habilitar aquesta opció, cal concedir permís per emetre un reinici en fred a un context mitjançant el generador de càrrega útil YAML file o l'opció Kconfig següent.
CONFIG_ALLOW_COLD REBOOT_ALWAYS
- Si està activada, aquesta funció permet que tots els contextos emetin un ECAA de reinici en fred, independentment dels drets de senyalització payload.bin.
- A més, el propi payload.bin pot contenir una marca per context, que indica que un context determinat té dret a emetre reinicis en fred:
  - Per permetre que un context reinicia un altre context, podem afegir l'opció allow-reboot: warm a la descripció de YAML file utilitzat per crear el payload.bin
  - Per permetre un reinici en fred context de tot el sistema, podem afegir l'opció allow-reboot: cold. De manera predeterminada, sense especificar allow-reboot, un context només es permet el reinici en calent Independentment de la configuració d'aquesta marca, si CONFIG_ALLOW_COLDREBOOT no està habilitat a l'HSS, l'HSS tornarà a treballar totes les sol·licituds de reinici en fred per reiniciar en calent (per context) .

Reinicieu amb detall
Aquesta secció descriu com funciona el reinici en detall, començant per la capa OpenSBI (la capa de mode M més baixa) i després discutint com s'activa aquesta funcionalitat de la capa OpenSBI des d'una aplicació RTOS o un sistema operatiu ric com Linux.

OpenSBI Reboot ecall

L'especificació RISC-V Supervisor Binary Interface (SBI) descriu una capa d'abstracció de maquinari estandarditzada per a la inicialització de la plataforma i els serveis d'execució del microprogramari. L'objectiu principal de SBI és permetre la portabilitat i la compatibilitat entre diferents implementacions RISC-V.
OpenSBI (Open Source Supervisor Binary Interface) és un projecte de codi obert que proporciona una implementació de referència de l'especificació SBI. OpenSBI també ofereix serveis de temps d'execució, com ara el maneig d'interrupcions, la gestió del temporitzador i l'E/S de la consola, que poden ser utilitzats per capes de programari de nivell superior.
OpenSBI s'inclou com a part de l'HSS i s'executa al nivell del mode màquina. Quan el sistema operatiu o l'aplicació provoqui una trampa, es passarà a OpenSBI per gestionar-la. OpenSBI exposa una determinada funcionalitat de tipus de trucada del sistema a les capes superiors del programari mitjançant un mecanisme de trampa particular anomenat ecall.

El restabliment del sistema (EID 0x53525354) proporciona una funció de trucada completa del sistema que permet que el programari de la capa superior sol·liciti el reinici o l'aturada a nivell del sistema. Un cop invocada aquesta trucada per un U54, és atrapada pel programari HSS que s'executa en mode màquina en aquest U54, i s'envia una sol·licitud de reinici corresponent a l'E51 per reiniciar el context o tot el sistema, depenent dels drets de l'UXNUMX. context.

Per a més informació, consulteu el Especificació de la interfície binària del supervisor RISC-V particularment Extensió de restabliment del sistema (EID #0x53525354 "SRST").

Reinici de Linux

Com a exampD'això, a Linux, l'ordre shutdown s'utilitza per aturar o reiniciar el sistema. L'ordre normalment té molts àlies, és a dir, aturar, apagar i reiniciar. Aquests àlies especifiquen si s'ha d'aturar la màquina quan s'apaga, si s'ha d'apagar o si es reinicia quan s'apaga.

Aquestes ordres de l'espai d'usuari emeten una trucada de reinici del sistema a Linux, que queda atrapada pel nucli i es connecta a una crida SBI.
Hi ha diversos nivells de reinici: REBOOT_WARM, REBOOT_COLD, REBOOT_HARD, aquests es poden passar com a arguments de línia d'ordres al nucli (per exempleample, reboot=w[arm] per a REBOOT_WARM). Per obtenir més informació sobre el codi font del nucli de Linux, vegeu Documentation/admin-guide/kernel-paramters.txt.
Alternativament, si /sys/kernel/reboot està habilitat, es poden llegir els controladors que hi ha a sota per obtenir la configuració actual de reinici del sistema i escriure'ls per modificar-lo. Per obtenir més informació sobre el codi font del nucli de Linux, vegeu Documentació/ABI/testing/sysfs-kernel-reboot.

Gossos de vigilància

Un altre concepte relacionat amb l'arrencada i el reinici del sistema és el de la recuperació del sistema després de l'activació d'un temporitzador de control. Els temporitzadors Watchdog s'utilitzen àmpliament en sistemes integrats per recuperar-se automàticament de fallades de maquinari transitories i per evitar que el programari errant o malèvol interrompi el funcionament del sistema.
PIC64GX inclou suport de control de maquinari per supervisar els harts individuals quan el sistema s'està executant. Els vigilants asseguren que els harts es puguin reiniciar si no responen a causa d'errors de programari irrecuperables.
El PIC64GX inclou cinc instàncies de blocs de maquinari del temporitzador de vigilància que s'utilitzen per detectar bloquejos del sistema: un per a cadascun dels harts. Per facilitar el multiprocessament asimètric mixt (AMP) càrregues de treball, l'HSS admet la supervisió i la reacció davant l'acomiadament dels vigilants.

PIC64GX Watchdog

L'HSS és responsable d'arrencar les aplicacions harts a l'encesa i de reiniciar-les (individualment o col·lectivament) en qualsevol moment.tage, si és necessari o desitjat. Com a conseqüència d'això, l'HSS gestiona la reacció als esdeveniments de control al PIC64GX.
Un monitor de "vigilància virtual" s'implementa com a servei de màquina d'estat HSS, i les seves responsabilitats són supervisar l'estat de cadascun dels monitors de maquinari de control individual U54. Quan un d'aquests vigilants de l'U54 es dispara, l'HSS ho detecta i reiniciarà l'U54 segons correspongui. Si l'U54 forma part d'un context SMP, es considera tot el context per al reinici, atès que el context té privilegi de reinici en calent. Tot el sistema es reiniciarà si el context té privilegi de reinici en fred.

Opcions de Kconfig rellevants

El suport de Watchdog s'inclou de manera predeterminada a les compilacions HSS llançades. Si voleu crear un HSS personalitzat, aquesta secció descriurà el mecanisme de configuració per assegurar-vos que el suport de Watchdog estigui habilitat.

L'HSS es configura mitjançant el sistema de configuració Kconfig. Un .config de nivell superior file és necessari per seleccionar quins serveis es compilen dins o fora de la compilació HSS.
En primer lloc, l'opció CONFIG_SERVICE_WDOG de nivell superior ha d'estar habilitada ("Compatibilitat amb Virtual Watchdog" mitjançant make config).

Aleshores, s'exposaran les subopcions següents que depenen del suport de Watchdog:

CONFIG_SERVICE_WD OG_DEBUG
Habilita el suport per a missatges informatius/depuració del servei de vigilància virtual.
CONFIG_SERVICE_WD OG_DEBUG_TIMEOUT_SECS
Determina la periodicitat (en segons) amb què l'HSS enviarà els missatges de depuració de Watchdog.
CONFIG_SERVICE_WD OG_ENABLE_E51
Habilita el gos vigilant per als monitors del cor E51 a més dels U54, protegint el funcionament del propi HSS.

Quan el watchdog E51 està habilitat, l'HSS escriurà periòdicament al Watchdog per actualitzar-lo i evitar que es dispari. Si, per algun motiu, el cor de l'E51 es bloqueja o s'estavella i el gos de control de l'E51 està habilitat, això sempre restablirà tot el sistema.

Operació de vigilant
El maquinari de control implementa comptadors avall. Es pot crear una finestra d'actualització prohibida configurant el valor màxim de control fins al qual es permet l'actualització (MVRP).

Quan el valor actual del temporitzador del gos vigilant és superior al valor MVRP, es prohibeix l'actualització del gos de vigilància. Si intenteu actualitzar el temporitzador de control a la finestra prohibida, s'afirmarà una interrupció del temps d'espera.

Actualitzar el gos de vigilància entre el valor MVRP i el valor de disparador (TRIG) actualitzarà correctament el comptador i evitarà que el gos de vigilància s'activi.
Una vegada que el valor del temporitzador del gos guardià compta per sota del valor TRIG, el gos guardià s'activarà.

Màquina d'estat de Watchdog

La màquina d'estat del gos de vigilància és molt senzilla: s'inicia configurant el gos de vigilància per a l'E51, si està habilitada, i després passa per un estat inactiu a la supervisió. Cada cop al voltant del superloop, s'invoca aquest estat de supervisió, que comprova l'estat de cadascun dels vigilants de l'U54.

La màquina d'estat del gos de vigilància interactua amb la màquina d'estat d'arrencada per reiniciar un hart (i qualsevol altre hart que estigui al seu conjunt d'arrencada), si detecta que l'hart no ha aconseguit actualitzar el seu gos de vigilància a temps.

Mode de bloqueig

Normalment (especialment amb AMP aplicacions), s'espera que l'HSS es mantingui resident en mode M, en un U54, per permetre el reinici per context (és a dir, reiniciar només un context, sense reinici de xip complet) i per permetre que l'HSS controli la salut ( ECC, bits d'estat de bloqueig, errors de bus, errors SBI, violacions de PMP, etc.).

Per tal de proporcionar capacitats de reinici de manera per-AMP En base al context (sense requerir que tot el sistema es reiniciï), l'E51 normalment té accés privilegiat a la memòria a tot l'espai de memòria del sistema. Tanmateix, pot haver-hi situacions en què això no sigui desitjable i el client pot preferir restringir el que fa el microprogramari E51 HSS un cop el sistema s'hagi arrencat correctament. En aquest cas, és possible posar l'HSS en mode de bloqueig un cop arrencat l'U54 Application Harts.

Això es pot activar mitjançant l'opció HSS Kconfig CONFIG_SERVICE_LOCKDOWN.
El servei de bloqueig està pensat per permetre la restricció de les activitats de l'HSS després d'iniciar l'aplicació U54 Harts.

Figura 4.2. Mode de bloqueig HSS

Un cop s'inicia el mode de bloqueig, atura totes les altres màquines d'estat del servei HSS. Crida dues funcions feblement lligades:

e51_pmp_lockdown(), i
e51_lockdown()

Aquestes funcions estan pensades per ser anul·lades pel codi específic de la placa. La primera és una funció d'activació configurable per permetre que un BSP personalitzi el bloqueig de l'E51 de les càrregues útils de l'aplicació en aquest moment. La implementació predeterminada amb un enllaç dèbil d'aquesta funció està buida. La segona és la funcionalitat que s'executa a partir d'aquest moment. La implementació predeterminada amb un límit feble serveix al gos de vigilància en aquest punt de l'E51 i es reiniciarà si s'activa un gos de vigilància U54. Per obtenir més informació, consulteu el codi font HSS a services/lockdown/lockdown_service.c file.

Apèndix

Format HSS payload.bin

Aquesta secció descriu el fitxer payload.bin file format i la imatge utilitzada per l'HSS per arrencar PIC64GX SMP i AMP aplicacions.
El payload.bin és un format binari (figura A.10) format per un capçalera, diverses taules de descriptors i diversos fragments que contenen el codi i les seccions de dades de cada part de la càrrega de treball de l'aplicació. Un tros es pot considerar com un bloc de memòria contigu de mida arbitrària.

Figura A.10. format payload.bin

La part de la capçalera (mostrada a la figura A.11) conté un valor màgic que s'utilitza per identificar el payload.bin i una mica d'informació de neteja, juntament amb detalls de la imatge que es vol executar a cadascun dels
Codis d'aplicació U54. Descriu com arrencar cada hart U54 individual i el conjunt d'imatges d'arrencada en general. A la seva informació de neteja, té punters a diverses taules de descriptors per permetre que la mida de la capçalera creixi.

Figura A.11. payload.bin Capçalera

El codi i les dades constants inicialitzades es consideren de només lectura i s'emmagatzemen en una secció de només lectura, a la qual assenyalen els descriptors de capçalera.
Les variables de dades inicialitzades diferents de zero són dades de lectura i escriptura, però tenen els seus valors d'inicialització copiats del fragment de només lectura a l'inici. També s'emmagatzemen a la secció de només lectura.

La secció de dades de càrrega útil només de lectura es descriu mitjançant una taula de descriptors de codi i fragments de dades. Cada descriptor de fragments d'aquesta taula conté un "propietari del hart" (el hart principal en el context al qual s'orienta
at), un desplaçament de càrrega (desplaçament dins de payload.bin) i una adreça d'execució (adreça de destinació a la memòria PIC64GX), juntament amb una mida i una suma de control. Això es mostra a la figura A.12.

Figura A.12. Descriptor de fragments de només lectura i dades de fragments de càrrega útil

A més dels fragments esmentats, també hi ha trossos de memòria corresponents a variables de dades que s'inicien a zero. Aquests no s'emmagatzemen com a dades al payload.bin, sinó que són un conjunt especial de descriptors de fragments inicialitzats zero, que especifiquen una adreça i una longitud de RAM per posar a zero durant l'inici. Això es mostra a la figura A.13.

Figura A.13. ZI Trossos

generador de càrrega útil hss
L'eina HSS Payload Generator crea una imatge de càrrega útil amb format per als zero-s de Hart Software Servicetage carregador d'arrencada a PIC64GX, donada una configuració file i un conjunt d'ELF files i/o binaris. La configuració file s'utilitza per assignar els binaris ELF o els blobs binaris als harts d'aplicacions individuals (U54s).

Figura B.14. Flux del generador de càrrega útil hss

L'eina realitza comprovacions bàsiques de seny sobre l'estructura de la configuració file mateix i a les imatges ELF. Les imatges ELF han de ser executables RISC-V.

Exampel Run

Per executar l'eina hss-payload-generator amb el sampconfiguració del le file i ELF files:
$ ./hss-payload-generator -c test/config.yaml output.bin
Per imprimir diagnòstics sobre una imatge preexistent, utilitzeu:
$ ./hss-payload-generator -d output.bin

Per habilitar l'autenticació d'arrencada segura (mitjançant la signatura d'imatges), utilitzeu -p per especificar la ubicació d'una clau privada X.509 per a la corba el·líptica P-384 (SECP384r1):
$ ./hss-payload-generator -c test/config.yaml payload.bin -p /path/to/private.pem

Per obtenir més informació, consulteu la documentació d'autenticació d'arrencada segura.

Config File Example

En primer lloc, opcionalment podem definir un nom per a la nostra imatge, en cas contrari, se'n crearà un de forma dinàmica:
nom-conjunt: 'PIC64-HSS::TestImage'
A continuació, definirem les adreces dels punts d'entrada per a cada cor, de la següent manera:
hart-entry-points: {u54_1: ‘0x80200000’, u54_2: ‘0x80200000’, u54_3: ‘0xB0000000′, u54_4:’0x80200000’}

Les imatges font d'ELF poden especificar un punt d'entrada, però volem ser capaços de suportar punts d'entrada secundaris per a harts si cal, per exempleampsi hi ha diversos harts per arrencar la mateixa imatge, poden tenir punts d'entrada individuals. Per donar suport a això, especifiquem les adreces de punt d'entrada reals a la configuració file mateix.

Ara podem definir algunes càrregues útils (font ELF files, o taques binaris) que es col·locaran en determinades regions de la memòria. La secció de càrrega útil es defineix amb la paraula clau càrregues útils i, després, una sèrie de descriptors de càrrega útil individuals. Cada càrrega útil té un nom (camí al seu file), un propietari-hart i, opcionalment, d'1 a 3 harts secundaris.

A més, una càrrega útil té un mode de privilegis en què començarà l'execució. Els modes de privilegi vàlids són PRV_M, PRV_S i PRV_U, on es defineixen com:

PRV_M Mode màquina
PRV_S Mode supervisor
PRV_U Mode d'usuari

En el següent exampLI:

Se suposa que test/zephyr.elf és una aplicació Zephyr que s'executa a U54_3 i que s'espera que s'iniciï en el mode de privilegi PRV_M.
test/u-boot-dtb.bin és l'aplicació del carregador d'arrencada Das U-Boot i s'executa a U54_1, U54_2 i U54_4. S'espera que s'iniciï en el mode de privilegi PRV_S.

Important:
La sortida d'U-Boot crea un ELF file, però normalment no anteposa l'extensió .elf. En aquest cas, s'utilitza el binari creat per CONFIG_OF_SEPARATE, que afegeix un blob d'arbre de dispositiu al binari U-Boot.

Aquí teniu l'example Configuració de càrregues útils file:

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

Important:
El cas només importa per al file noms de camí, no les paraules clau. Així, per exemple, u54_1 es considera el mateix que U54_1 i exec-addr es considera el mateix que EXEC-ADDR. Si hi ha una extensió.elf o .bin, s'ha d'incloure a la configuració file.

Per a una aplicació de metall nu que no vol preocupar-se per OpenSBI, l'opció skip-opens, si és cert, farà que la càrrega útil d'aquest cor s'invoqui amb un simple mret en lloc de
que una crida OpenSBI sbi_init(). Això significa que el cor començarà a executar el codi de metall nu, independentment de qualsevol consideració d'OpenSBI HSM. Tingueu en compte que això també significa que el cor no pot utilitzar-lo
ecalls per invocar la funcionalitat OpenSBI. L'opció d'obrir per salt és opcional i el valor predeterminat és fals.

Per permetre un reinici calent del context d'un altre context, podem afegir l'opció allow reboot: warm. Per permetre un reinici en fred context de tot el sistema, podem afegir l'opció allow-reboot: cold. De manera predeterminada, sense especificar allow-reboot, un context només es pot reiniciar en calent.
També és possible associar dades auxiliars amb cada càrrega útil, per exempleample, un DeviceTree Blob (DTB) file, especificant les dades auxiliars filenom de la següent manera:
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, dades auxiliars : test/pic64gx.dtb }
Aquestes dades auxiliars s'inclouran a la càrrega útil (ubicada just després de la principal file a l'executable
espai), i la seva adreça es passarà a l'OpenSBI al camp next_arg1 (s'ha passat al registre $a1 a la imatge en el moment de l'arrencada).

Per evitar que l'HSS arrenqui automàticament un context (per exemple, si en canvi volem delegar el control d'aquest a un context mitjançant remoteProc), utilitzeu el senyalador skip-autoboot:
test/zephyr.elf: {exec-addr: '0xB0000000', owner-hart: u54_3, priv-mode: prv_m, skip-opensbi: true, skip-autoboot: true}
Finalment, opcionalment podem substituir els noms de les càrregues útils individuals, utilitzant l'opció payload-name. Per exampLI:
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, dades auxiliars : test/pic64gx.dtb, nom de càrrega útil: 'u-boot'}

Tingueu en compte que els constructors Yocto i Buildroot Linux construiran, configuraran i executaran la càrrega útil hss-
generador segons sigui necessari per generar imatges d'aplicació. A més, el pic64gx-curiosity-kit-amp L'objectiu de la màquina a Yocto generarà una imatge d'aplicació mitjançant l'eina hss-payload-generator que demostra AMP, amb Linux amb 3 harts i Zephyr amb 1 hart.

Historial de revisions
L'historial de revisions descriu els canvis que es van implementar al document. Els canvis s'enumeren per revisió, començant per la publicació més actual.

Revisió	Data	Descripció
A	07/2024	Revisió inicial

Informació del microxip

El Microxip Weblloc
Microxip ofereix suport en línia a través del nostre weblloc a www.microchip.com/. Això weblloc s'utilitza per fer filei informació fàcilment disponible per als clients. Alguns dels continguts disponibles inclouen:

Suport al producte – Fitxes i errates, notes d'aplicació i sampprogrames, recursos de disseny, guies d'usuari i documents de suport de maquinari, últimes versions de programari i programari arxivat

Suport tècnic general - Preguntes freqüents (FAQ), sol·licituds d'assistència tècnica, grups de discussió en línia, llista de membres del programa de socis de disseny de Microchip
Negoci de Microxip – Selector de productes i guies de comandes, darrers comunicats de premsa de Microxip, una llista de seminaris i esdeveniments, llistats d'oficines de vendes, distribuïdors i representants de fàbrica de Microxip

Servei de notificació de canvis de producte

El servei de notificació de canvis de producte de Microchip ajuda a mantenir els clients al dia dels productes de Microchip. Els subscriptors rebran una notificació per correu electrònic sempre que hi hagi canvis, actualitzacions, revisions o errates relacionades amb una família de productes o una eina de desenvolupament especificada d'interès.

Per registrar-se, aneu a www.microchip.com/pcn i seguiu les instruccions de registre.

Atenció al client
Els usuaris dels productes Microxip poden rebre assistència a través de diversos canals:

Distribuïdor o representant
Oficina local de vendes
Enginyer de solucions integrades (ESE)
Suport tècnic

Els clients han de contactar amb el seu distribuïdor, representant o ESE per obtenir assistència. Les oficines de vendes locals també estan disponibles per ajudar els clients. En aquest document s'inclou una llista d'oficines de vendes i ubicacions.
El suport tècnic està disponible a través de weblloc a: www.microchip.com/support.

Funció de protecció de codi de dispositius de microxip
Tingueu en compte els detalls següents de la funció de protecció del codi als productes Microxip:

Els productes de microxip compleixen les especificacions contingudes a la seva fitxa de dades particular de microxip.
Microxip creu que la seva família de productes és segura quan s'utilitza de la manera prevista, dins de les especificacions de funcionament i en condicions normals.

Microxip valora i protegeix de manera agressiva els seus drets de propietat intel·lectual. Els intents d'infringir les funcions de protecció del codi dels productes Microxip estan estrictament prohibits i poden infringir la Llei de drets d'autor de Digital Millennium.
Ni Microchip ni cap altre fabricant de semiconductors poden garantir la seguretat del seu codi. La protecció del codi no vol dir que estem garantint que el producte sigui "irrompible". La protecció del codi està en constant evolució. Microxip es compromet a millorar contínuament les funcions de protecció del codi dels nostres productes.

Avís Legal
Aquesta publicació i la informació que s'hi inclou només es poden utilitzar amb els productes Microxip, inclòs per dissenyar, provar i integrar productes Microxip amb la vostra aplicació. L'ús d'aquesta informació de qualsevol altra manera viola aquests termes. La informació sobre les aplicacions del dispositiu només es proporciona per a la vostra comoditat i pot ser substituïda per actualitzacions. És la vostra responsabilitat assegurar-vos que la vostra aplicació compleix les vostres especificacions. Poseu-vos en contacte amb l'oficina local de vendes de Microxip per obtenir assistència addicional o, per obtenir assistència addicional a www.microchip.com/en-us/support/design-help/client-support-services.

AQUESTA INFORMACIÓ ÉS PROPORCIONADA PER MICROCHIP "TAL CUAL". MICROCHIP NO FA REPRESENTACIONS NI GARANTIES DE CAP TIPUS, JA SIGUI EXPRESSES O IMPLÍCITES, ESCRITS O ORALS, LEGALS O D'ALTRE ALTRE, RELACIONATS AMB LA INFORMACIÓ INCLOSA, PERÒ NO LIMITADA A CAP GARANTIA IMPLÍCITA DE NO INFRACCIÓ, COMERCIABILITAT I COMERCIALITZACIÓ, COMERCIALITZACIÓ I COMERCIALITZACIÓ. GARANTIES RELACIONATS AMB EL SEU ESTAT, QUALITAT O RENDIMENT.

EN CAP CAS, MICROCHIP SERÀ RESPONSABLE DE CAP PÈRDUA INDIRECTA, ESPECIAL, PUNITIVA, INCIDENTAL O CONSEQUENTAL, DANNY, COST O DESPESA DE QUALSEVOL TIPUS RELACIONATS AMB LA INFORMACIÓ O EL SEU ÚS, SEGUI QUE SIEMPRE CAUSAT, FINS I TOT QUÈ SIGUI AIXÒ. LA POSSIBILITAT O ELS DANYS SÓN PREVISIBLES. EN LA MÀXIMA MESURA PERMETIDA PER LA LLEI, LA RESPONSABILITAT TOTAL DE MICROCHIP EN TOTES LES RECLAMACIONS RELACIONATS DE QUALSEVOL MANERA AMB LA INFORMACIÓ O EL SEU ÚS NO SUPERARÀ EL NOMBRE DE TARIFES, SI ENS HA, QUE HEU PAGAT DIRECTAMENT A MICROCHIP PER LA INFORMACIÓ.

L'ús de dispositius Microxip en aplicacions de suport vital i/o seguretat és totalment a risc del comprador, i el comprador es compromet a defensar, indemnitzar i excloure Microxip de tots els danys, reclamacions, demandes o despeses derivades d'aquest ús. No es transmet cap llicència, implícita o d'una altra manera, sota cap dret de propietat intel·lectual de Microxip tret que s'indiqui el contrari.

Marques comercials
El nom i el logotip de Microxip, el logotip de Microxip, Adaptec, AVR, logotip d'AVR, AVR Freaks, BesTime, BitCloud, CryptoMemory, CryptoRF, dsPIC, flexPWR, HELDO, IGLOO, JukeBlox, KeeLoq, Kleer, LANCheck, LinkMD, maXStyluuchs, MediaLB, megaAVR, Microsemi, logotip de Microsemi, MOST, logotip MOST, MPLAB, OptoLyzer, PIC, picoPower, PICSTART, logotip PIC32, PolarFire, Prochip Designer, QTouch, SAM-BA, SenGenuity, SpyNIC, SST, SST Logo, SuperFlash, Symmetricom , SyncServer, Tachyon, TimeSource, tinyAVR, UNI/O, Vectron i XMEGA són marques registrades de Microchip Technology Incorporated als EUA i altres països.

AgileSwitch, ClockWorks, The Embedded Control Solutions Company, EtherSynch, Flashtec, Hyper Speed Control, HyperLight Load, Libero, banc de motors, mTouch, Powermite 3, Precision Edge, ProASIC, ProASIC Plus, logotip de ProASIC Plus, Quiet-Wire, SmartFusion, SyncWorld , TimeCesium, TimeHub, TimePictra, TimeProvider i ZL són marques registrades de Microchip Technology Incorporated als EUA.

Supressió de claus adjacents, AKS, Analog-for-the-Digital Age, Qualsevol condensador, AnyIn, AnyOut, Augmented Switching, BlueSky, BodyCom, Clockstudio, CodeGuard, CryptoAuthentication, CryptoAutomotive, CryptoCompanion, CryptoController, dsPICDEM, dsPICDEM Average Net. , DAM, ECAN, Espresso T1S, EtherGREEN, EyeOpen, GridTime, IdealBridge,
IGaT, programació en sèrie en circuit, ICSP, INICnet, paral·lelització intel·ligent, IntelliMOS, connectivitat entre xips, JitterBlocker, Knob-on-Display, MarginLink, maxCrypto, maxView, memBrain, Mindi, MiWi, MPASM, MPF, logotip de 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, mapa simple, 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 i ZENA són marques comercials de Microchip Technology Incorporated als EUA i altres països.

SQTP és una marca de servei de Microchip Technology Incorporated als EUA
El logotip d'Adaptec, Frequency on Demand, Silicon Storage Technology i Symmcom són marques registrades de Microchip Technology Inc. a altres països.
GestIC és una marca comercial registrada de Microchip Technology Germany II GmbH & Co. KG, una filial de Microchip Technology Inc., a altres països.

ISBN: 978-1-6683-4890-1

Sistema de gestió de la qualitat
Per obtenir informació sobre els sistemes de gestió de la qualitat de Microchip, visiteu www.microchip.com/quality.

Vendes i servei a tot el món

AMÈRICES

ASIA/PACÍFIC

EUROPA

Corporativa Oficina

2355 West Chandler Blvd. Chandler, AZ 85224-6199

Tel: 480-792-7200

Fax: 480-792-7277

Suport tècnic: www.microchip.com/support

Web Adreça: 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

Indianàpolis

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

Nova York, NY

Tel: 631-435-6000

San Jose, CA

Tel: 408-735-9110

Tel: 408-436-4270

Canadà – Toronto

Tel: 905-695-1980

Fax: 905-695-2078

Austràlia - Sydney

Tel: 61-2-9868-6733

Xina - Pequín

Tel: 86-10-8569-7000

Xina - Chengdu

Tel: 86-28-8665-5511

Xina - Chongqing

Tel: 86-23-8980-9588

Xina - Dongguan

Tel: 86-769-8702-9880

Xina - Guangzhou

Tel: 86-20-8755-8029

Xina - Hangzhou

Tel: 86-571-8792-8115

Xina – Hong Kong SAR

Tel: 852-2943-5100

Xina - Nanjing

Tel: 86-25-8473-2460

Xina - Qingdao

Tel: 86-532-8502-7355

Xina - Xangai

Tel: 86-21-3326-8000

Xina - Shenyang

Tel: 86-24-2334-2829

Xina - Shenzhen

Tel: 86-755-8864-2200

Xina - Suzhou

Tel: 86-186-6233-1526

Xina - Wuhan

Tel: 86-27-5980-5300

Xina - Xian

Tel: 86-29-8833-7252

Xina - Xiamen

Tel: 86-592-2388138

Xina - Zhuhai

Tel: 86-756-3210040

Índia – Bangalore

Tel: 91-80-3090-4444

Índia - Nova Delhi

Tel: 91-11-4160-8631

Índia – Pune

Tel: 91-20-4121-0141

Japó – Osaka

Tel: 81-6-6152-7160

Japó – Tòquio

Tel: 81-3-6880-3770

Corea - Daegu

Tel: 82-53-744-4301

Corea - Seül

Tel: 82-2-554-7200

Malàisia – Kuala Lumpur

Tel: 60-3-7651-7906

Malàisia - Penang

Tel: 60-4-227-8870

Filipines – Manila

Tel: 63-2-634-9065

Singapur

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

Tailàndia - Bangkok

Tel: 66-2-694-1351

Vietnam - Ho Chi Minh

Tel: 84-28-5448-2100

Àustria – Wels

Tel: 43-7242-2244-39

Fax: 43-7242-2244-393

Dinamarca – Copenhaguen

Tel: 45-4485-5910

Fax: 45-4485-2829

Finlàndia – Espoo

Tel: 358-9-4520-820

França – París

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

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

Alemanya – garching

Tel: 49-8931-9700

Alemanya – Haan

Tel: 49-2129-3766400

Alemanya – Heilbronn

Tel: 49-7131-72400

Alemanya – Karlsruhe

Tel: 49-721-625370

Alemanya – Munic

Tel: 49-89-627-144-0

Fax: 49-89-627-144-44

Alemanya – Rosenheim

Tel: 49-8031-354-560

Israel – Hod Hasharon

Tel: 972-9-775-5100

Itàlia - Milà

Tel: 39-0331-742611

Fax: 39-0331-466781

Itàlia - Pàdua

Tel: 39-049-7625286

Països Baixos – Drunen

Tel: 31-416-690399

Fax: 31-416-690340

Noruega – Trondheim

Tel: 47-72884388

Polònia – Varsòvia

Tel: 48-22-3325737

Romania – Bucarest

Tel: 40-21-407-87-50

Espanya – Madrid

Tel: 34-91-708-08-90

Fax: 34-91-708-08-91

Suècia – Göteborg

Tel: 46-31-704-60-40

Suècia - Estocolm

Tel: 46-8-5090-4654

Regne Unit - Wokingham

Tel: 44-118-921-5800

Fax: 44-118-921-5820

Documents/Recursos

MICROCHIP PIC64GX Microprocessador de quatre nuclis RISC-V de 64 bits [pdfGuia de l'usuari
PIC64GX, PIC64GX Microprocessador de quatre nuclis RISC-V de 64 bits, Microprocessador de quatre nuclis RISC-V de 64 bits, Microprocessador de quatre nuclis RISC-V, Microprocessador de quatre nuclis, Microprocessador

Referències

Manual d'usuari

MICROCHIP PIC64GX Microprocessador de quatre nuclis RISC-V de 64 bits

Informació del producte

Instruccions d'ús del producte