MICROCHIP PIC64GX Microprocessador de quatre nuclis RISC-V de 64 bits
Informació del producte
Especificacions:
- Nom del producte: Microxip PIC64GX
- Procés d'arrencada: SMP i AMP càrregues de treball suportades
- Característiques especials: Suport de vigilància, mode de bloqueig
Instruccions d'ús del producte
- Procés d'arrencada
- 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.
- Flux d'arrencada
La seqüència del flux d'arrencada del sistema és la següent:- Inicialització dels serveis de programari Hart (HSS)
- Execució del carregador d'arrencada
- Inici de l'aplicació
- Components de programari implicats en l'arrencada
- Gossos de vigilància
- PIC64GX Watchdog
El PIC64GX inclou una funció de control per supervisar el funcionament del sistema i activar accions en cas de fallades del sistema.
- PIC64GX Watchdog
- 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.
Totes les altres marques comercials esmentades aquí són propietat de les seves respectives empreses. © 2024, Microchip Technology Incorporated i les seves filials. Tots els drets reservats.
- 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 | 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 |
© 2024 Microchip Technology Inc. i les seves filials.
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 |