MICROCHIP PIC64GX Guía de usuario do microprocesador de catro núcleos RISC-V de 64 bits

Proceso de arranque
1. Compoñentes de software implicados no arranque
  O proceso de arranque do sistema implica os seguintes compoñentes de software:
  - Hart Software Services (HSS): Un cero-stage cargador de arranque, monitor do sistema e provedor de servizos de execución para aplicacións.
2. Fluxo de arranque
  A secuencia do fluxo de arranque do sistema é a seguinte:
  1. Inicialización de Hart Software Services (HSS)
  2. Execución do cargador de arranque
  3. Inicio da aplicación
Cans vixiantes
1. PIC64GX Watchdog
  O PIC64GX dispón dunha función de control para supervisar o funcionamento do sistema e activar accións en caso de fallos do sistema.
Modo de bloqueo
O modo de bloqueo está deseñado para clientes que requiren un control total sobre as accións do sistema despois do arranque. Limita as funcionalidades do monitor do sistema E51.

FAQ

P: Cal é o propósito dos servizos de software Hart (HSS)?
R: O HSS serve como cero-stage cargador de arranque, monitor do sistema e provedor de servizos de execución para aplicacións durante o proceso de inicio.
P: Como funciona a función watchdog PIC64GX?
R: O control PIC64GX supervisa o funcionamento do sistema e pode tomar accións predefinidas en caso de fallos do sistema para garantir a fiabilidade do sistema.

Introdución

Este documento branco explica como o Microchip PIC64GX inicia as cargas de traballo das aplicacións e describe o proceso de inicio do sistema, que funciona igual para SMP e AMP cargas de traballo. Ademais, cobre como funciona un reinicio para SMP e AMP cargas de traballo, vixiantes no PIC64GX e un modo de bloqueo especial para sistemas nos que os clientes desexan un control total para limitar as accións do monitor do sistema E51 despois do inicio do sistema.

Proceso de arranque

Vexamos os distintos compoñentes de software implicados no arranque do sistema, seguido dunha ollada máis detallada á secuencia do propio fluxo de inicio do sistema.

Compoñentes de software implicados no arranque
Os seguintes compoñentes están implicados no proceso de arranque do sistema:

Figura 1.1. Compoñentes de arranque

Servizos de software Hart (HSS)
O Hart Software Services (HSS) é un cerotagun cargador de arranque, un monitor de sistema e un provedor de servizos de execución para aplicacións. O HSS admite a configuración inicial do sistema, a formación DDR e a inicialización/configuración de hardware. Funciona principalmente no E51s, cunha pequena cantidade de funcións de nivel de modo máquina en cada U54. Arranca un ou máis contextos cargando a "carga útil" da aplicación desde o medio de arranque e ofrece Platform Runtime Services/Supervisor Execution Environment (SEE) para os núcleos do sistema operativo. Admite o arranque seguro e é un compoñente importante para garantir a partición/separación do hardware AMP contextos.

Das U-Boot (U-Boot)
Das U-Boot (U-Boot) é un cargador de arranque universal con scripts de código aberto. Soporta unha CLI sinxela que pode recuperar a imaxe de arranque desde unha variedade de fontes (incluíndo unha tarxeta SD e a rede). U-Boot carga Linux. Pode proporcionar un ambiente UEFI se é necesario. Xeralmente está rematado e fóra do camiño unha vez que se iniciou Linux; noutras palabras, non permanece residente despois do arranque.
Núcleo de Linux
O núcleo de Linux é o núcleo do sistema operativo máis popular do mundo. Combinado cunha zona de usuarios de aplicacións, forma o que comunmente se denomina sistema operativo Linux. Un sistema operativo Linux ofrece API POSIX ricas e un ambiente de desenvolvedor, por exemploample, linguaxes e ferramentas como Python, Perl, Tcl, Rust, C/C++ e Tcl; bibliotecas como OpenSSL, OpenCV, OpenMP, OPC/UA e OpenAMP (RPmsg e RemoteProc).
Yocto e Buildroot son creadores de sistemas Linux, é dicir, pódense usar para xerar sistemas Linux personalizados. Yocto saca unha distribución Linux cun rich
conxunto de aplicacións, ferramentas e bibliotecas e xestión de paquetes opcional. Buildroot produce unha raíz máis mínima filesistema e pode dirixirse a sistemas que non requiren almacenamento persistente pero que se executan enteiramente desde a RAM (usando o soporte de iniciais de Linux, por exemploample).

Céfiro
Zephyr é un pequeno sistema operativo en tempo real (RTOS) de código aberto. Ofrece un marco de baixo custo en tempo real, con canles de comunicación RPMsg-lite para Linux. Inclúe un núcleo, bibliotecas, controladores de dispositivos, pilas de protocolos, filesistemas, mecanismos para actualizacións de firmware, etc., e é ideal para os clientes que queren unha experiencia máis sen metal en PIC64GX.

Fluxo de arranque
PIC64GX inclúe un coreplex RISC-V cun hart de monitor de sistema E64 de 51 bits e 4 harts de aplicación U64 de 54 bits. Na terminoloxía RISC-V, un hart é un contexto de execución RISC-V que contén un conxunto completo de rexistros e que executa o seu código de forma independente. Podes pensar nel como un fío de hardware ou unha única CPU. Un grupo de cervos dentro dun só núcleo adoita chamarse complexo. Este tema describe os pasos para inicializar o coreplex PIC64GX, incluíndo os monitores do sistema E51 e as aplicacións Harts U54.

Encienda o coreplex PIC64GX.
Ao acender, o controlador de seguranza libera todos os harts do coreplex RISC-V.
Execute o código HSS desde a memoria flash eNVM no chip.
Inicialmente, cada corazón comeza a executar o código HSS da memoria flash eNVM no chip. Este código fai que todas as aplicacións U54 xiren, esperando instrucións e permite que o monitor E51 comece a executar código para inicializar e abrir o sistema.

Descomprime o código HSS de eNVM á memoria L2-Scratch.
Dependendo da súa configuración de tempo de compilación, o HSS adoita ser maior que a capacidade da propia memoria flash eNVM, polo que o primeiro que fai o código HSS que se executa no E51 é descomprimirse de eNVM á memoria L2-Scratch, como se mostra na figura. 1.2 e Figura 1.3.
Figura 1.2. HSS descomprime de eNVM a L2 Scratch
Figura 1.3. Mapa de memoria HSS durante a descompresión
Salta de eNVM a L2-Scratch a un executable como se mostra na seguinte figura.
Figura 1.4. HSS salta de eNVM ao código agora en L2Scratch despois da descompresión
O executable consta de tres compoñentes:
- Capa de abstracción de hardware (HAL), código de baixo nivel e controladores bare metal
- Unha bifurcación HSS local de RISC-V OpenSBI (modificada lixeiramente desde ascendente en PIC64GX para AMP fins)
- Os servizos de execución de HSS (as máquinas de estado execútanse nun super loop)
Inicializa o hardware e as estruturas de datos utilizadas por OpenSBI.
O servizo HSS "Startup" é o responsable desta inicialización.

Obtén a imaxe da carga de traballo da aplicación (payload.bin) do almacenamento externo. Isto móstrase na Figura 1.5 e na Figura 1.6
Importante: no caso do PIC64GX Curiosity Kit, será desde unha tarxeta SD.
Figura 1.5. Obtendo a imaxe de carga de traballo de payload.bin do almacenamento externo
Figura 1.6. Mapa de memoria HSS despois de recuperar payload.bin
Copie as distintas seccións do payload.bin aos seus destinos de execución. O payload.bin é unha imaxe formatada, que consolida varias imaxes de aplicacións para SMP ou AMP cargas de traballo. Inclúe táboas de código, datos e descritores que permiten ao HSS colocar adecuadamente o código e as seccións de datos, onde son necesarios para executar as distintas cargas de traballo da aplicación.
Figura 1.7. payload.bin cópiase nos enderezos de destino

Instruír aos U54 relevantes para que salten aos seus enderezos de inicio de execución. Esta información de enderezo de inicio está contida no payload.bin.
Inicia a aplicación U54 harts e calquera segundotage cargadores de arranque. Por example, U-Boot abre Linux.

Reinicie

Relacionado co concepto de arranque do sistema está a necesidade de reiniciar. Cando se pensa nas cargas de traballo das aplicacións PIC64GX, o reinicio debe considerar tanto o multiprocesamento simétrico (SMP) como o multiprocesamento asimétrico (AMP) escenarios:

No caso dun sistema SMP, un reinicio pode reiniciar todo o sistema de forma segura xa que non hai cargas de traballo adicionais noutro contexto a considerar.

No caso dun AMP sistema, é posible que unha carga de traballo só poida reiniciarse por si mesma (e non interferir con ningún outro contexto) ou que teña privilexios para poder realizar un reinicio completo do sistema.

Reinicie e AMP
Para activar o SMP e AMP escenarios de reinicio, o HSS admite os conceptos de privilexios de reinicio en frío e en calor, que se poden asignar a un contexto. Un contexto con privilexio de reinicio en frío só pode reiniciarse por si mesmo, e un contexto con privilexio de reinicio en frío pode realizar un reinicio completo do sistema. Por example, considere o seguinte conxunto de escenarios representativos.

Unha única carga de traballo SMP de contexto, que se permite solicitar un reinicio completo do sistema
Neste escenario, permítese o contexto o privilexio de reinicio en frío.
Un dobre contexto AMP carga de traballo, onde o contexto A pode solicitar un reinicio completo do sistema (que afecta a todos os contextos) e o contexto B só se permite reiniciarse
Neste escenario, o contexto A ten privilexio de reinicio en frío e o contexto B ten privilexio de reinicio en frío.
Un dobre contexto AMP carga de traballo, onde os contextos A e B só poden reiniciarse por si mesmos (e non afectan ao outro contexto)
Neste escenario, só se permiten os dous contextos privilexios de reinicio en caliente.
Un dobre contexto AMP carga de traballo, onde os contextos A e B teñen permiso para solicitar o reinicio completo do sistema
Neste escenario, ambos contextos teñen privilexios de reinicio en frío.
Ademais, é posible que o HSS no tempo de compilación permita sempre o privilexio de reinicio en frío e nunca permita o privilexio de reinicio en frío.

Opcións HSS Kconfig relevantes
Kconfig é un sistema de configuración de compilación de software. Úsase habitualmente para seleccionar opcións de tempo de construción e para activar ou desactivar funcións. Orixinouse co núcleo de Linux, pero agora atopou uso noutros proxectos ademais do núcleo de Linux, incluíndo U-Boot, Zephyr e o PIC64GX HSS.

O HSS contén dúas opcións de Kconfig que controlan a funcionalidade de reinicio desde a perspectiva do HSS:

CONFIG_ALLOW_REINICIO EN FRÍO
Se isto está activado, globalmente permite que un contexto emita unha chamada de reinicio en frío. Se está desactivado, só se permitirán reinicios en caliente. Ademais de habilitar esta opción, débese conceder permiso para emitir un reinicio en frío a un contexto a través do xerador de carga útil YAML file ou a seguinte opción de Kconfig.
CONFIG_ALLOW_REBOOT_ALWAYS EN FRÍO
- Se está activada, esta función permite que todos os contextos emitan un ECAA de reinicio en frío, independentemente dos dereitos de marca payload.bin.
- Ademais, o propio payload.bin pode conter unha marca por contexto, que indica que un contexto particular ten dereito a reiniciar en frío:
  - Para permitir que un contexto reinicie en caliente outro contexto, podemos engadir a opción allow-reboot: warm na descrición de YAML file usado para crear o payload.bin
  - Para permitir un reinicio en frío contextual de todo o sistema, podemos engadir a opción allow-reboot: cold. De forma predeterminada, sen especificar allow-reboot, só se permite o reinicio en caliente dun contexto Independentemente da configuración desta marca, se CONFIG_ALLOW_COLDREBOOT non está habilitado no HSS, o HSS reelaborará todas as solicitudes de reinicio en frío para reiniciar en quente (por contexto) .

Reinicie en detalle
Esta sección describe como funciona o reinicio en detalle, comezando pola capa OpenSBI (a capa de modo M máis baixa) e despois discutindo como se activa esta funcionalidade da capa OpenSBI desde unha aplicación RTOS ou un sistema operativo rico como Linux.

OpenSBI Reboot ecall

A especificación RISC-V Supervisor Binary Interface (SBI) describe unha capa de abstracción de hardware estandarizada para a inicialización da plataforma e os servizos de execución de firmware. O obxectivo principal de SBI é permitir a portabilidade e compatibilidade entre diferentes implementacións RISC-V.
OpenSBI (Open Source Supervisor Binary Interface) é un proxecto de código aberto que proporciona unha implementación de referencia da especificación SBI. OpenSBI tamén ofrece servizos de execución, incluíndo o manexo de interrupcións, a xestión do temporizador e a E/S da consola, que poden ser utilizados por capas de software de nivel superior.
OpenSBI inclúese como parte do HSS e execútase a nivel do modo máquina. Cando o sistema operativo ou a aplicación cause unha trampa, pasarase a OpenSBI para que o manexa. OpenSBI expón unha determinada funcionalidade de tipo de chamada de sistema ás capas superiores do software a través dun mecanismo de captura particular chamado ecall.

O restablecemento do sistema (EID 0x53525354) ofrece unha función completa de chamada ao sistema que permite que o software da capa superior solicite o reinicio ou o apagado a nivel do sistema. Unha vez que esta chamada é invocada por un U54, é atrapada polo software HSS que se executa en Modo Máquina nese U54, e envíase unha solicitude de reinicio correspondente ao E51 para reiniciar o contexto ou todo o sistema, dependendo dos dereitos do usuario. contexto.

Para obter máis información, consulte o Especificación da interface binaria do supervisor RISC-V particularmente Extensión de restablecemento do sistema (EID #0x53525354 “SRST”).

Reiniciar Linux

Como ex. específicoampNeste caso, en Linux, o comando shutdown úsase para deter ou reiniciar o sistema. O comando normalmente ten moitos alias, é dicir, parar, apagar e reiniciar. Estes alias especifican se debe deter a máquina ao apagar, apagar a máquina ao apagar ou reiniciar a máquina ao apagar.

Estes comandos de espazo de usuario emiten unha chamada de sistema de reinicio a Linux, que está atrapado polo núcleo e interfunciona cunha chamada de SBI.
Hai varios niveis de reinicio - REBOOT_WARM, REBOOT_COLD, REBOOT_HARD - estes pódense pasar como argumentos de liña de comandos ao núcleo (por exemploample, reboot=w[arm] para REBOOT_WARM). Para obter máis información sobre o código fonte do núcleo de Linux, consulte Documentación/admin-guide/kernel-paramters.txt.
Alternativamente, se /sys/kernel/reboot está activado, pódense ler os controladores debaixo para obter a configuración actual de reinicio do sistema e escribir para alterala. Para obter máis información sobre o código fonte do núcleo de Linux, consulte Documentación/ABI/testing/sysfs-kernel-reboot.

Cans vixiantes

Outro concepto relacionado co arranque e reinicio do sistema é o da recuperación do sistema ao disparar un temporizador de control. Os temporizadores Watchdog utilízanse amplamente nos sistemas integrados para recuperarse automaticamente de fallos transitorios de hardware e evitar que o software errante ou malévolo perturbe o funcionamento do sistema.
PIC64GX inclúe soporte de control de hardware para supervisar os cervos individuais cando o sistema está en execución. Os vixiantes aseguran que os cervos poden reiniciarse se non responden debido a erros de software irrecuperables.
PIC64GX inclúe cinco instancias de bloques de hardware do temporizador de vixilancia utilizados para detectar bloqueos do sistema, un para cada un dos cervos. Para facilitar o multiprocesamento asimétrico mixto (AMP) cargas de traballo, o HSS admite a monitorización e a reacción ante o disparo dos watchdogs.

PIC64GX Watchdog

O HSS encárgase de iniciar as aplicacións harts ao encendelas e de reinicialas (individualmente ou colectivamente) en calquera momento.tage, se fose necesario ou desexado. Como consecuencia diso, o HSS xestiona a reacción ante eventos de control no PIC64GX.
Implícase un monitor de "vixilancia virtual" como servizo de máquina de estado HSS, e as súas responsabilidades son supervisar o estado de cada un dos monitores individuais de hardware de vigilancia U54. Cando un destes vixiantes do U54 se dispara, o HSS detecta isto e reiniciará o U54 segundo corresponda. Se o U54 forma parte dun contexto SMP, considérase todo o contexto para o reinicio, dado que o contexto ten privilexios de reinicio en caliente. Todo o sistema reiniciarase se o contexto ten privilexio de reinicio en frío.

Opcións de Kconfig relevantes

O soporte de Watchdog inclúese por defecto nas compilacións HSS publicadas. Se desexa crear un HSS personalizado, esta sección describirá o mecanismo de configuración para garantir que o soporte de Watchdog está activado.

O HSS está configurado mediante o sistema de configuración Kconfig. Un .config de nivel superior file é necesario para seleccionar que servizos se compilan dentro ou fóra da compilación HSS.
En primeiro lugar, a opción de nivel superior CONFIG_SERVICE_WDOG debe estar activada ("Compatible con Virtual Watchdog" a través de make config).

Isto expón as seguintes subopcións que dependen do soporte de Watchdog:

CONFIG_SERVICE_WD OG_DEBUG
Activa a compatibilidade con mensaxes informativas/depuradoras do servizo de vixilancia virtual.
CONFIG_SERVICE_WD OG_DEBUG_TIMEOUT_SECS
Determina a periodicidade (en segundos) que enviarán as mensaxes de depuración de Watchdog polo HSS.
CONFIG_SERVICE_WD OG_ENABLE_E51
Activa o control do corazón dos monitores E51 ademais dos U54, protexendo o funcionamento do propio HSS.

Cando o watchdog E51 está activado, o HSS escribirá periodicamente no Watchdog para actualizalo e evitar que se dispare. Se, por algún motivo, o corazón do E51 se bloquea ou falla e o control do E51 está activado, isto sempre restablecerá todo o sistema.

Operación Watchdog
O hardware de control implementa contadores descendentes. Pódese crear unha xanela de actualización prohibida configurando o valor máximo de vixilancia ata o que se permite a actualización (MVRP).

Cando o valor actual do temporizador do watchdog é maior que o valor MVRP, está prohibido actualizar o watchdog. Se tentas actualizar o temporizador de control na xanela prohibida, activarase unha interrupción do tempo de espera.

Ao actualizar o can de garda entre o valor MVRP e o valor de activación (TRIG) actualizarase correctamente o contador e evitará que se dispare.
Unha vez que o valor do temporizador do watchdog conta por debaixo do valor TRIG, o watchdog dispararase.

Watchdog State Machine

A máquina de estado de watchdog é moi sinxela: comeza configurando o watchdog para o E51, se está activada, e despois pasa por un estado inactivo para a supervisión. Cada vez que rodea o superloop, invócase este estado de vixilancia, que comproba o estado de cada un dos vixiantes do U54.

A máquina de estado de watchdog interactúa coa máquina de estado de arranque para reiniciar un hart (e calquera outro hart que estea no seu conxunto de inicio), se detecta que o hart non conseguiu actualizar o seu watchdog a tempo.

Modo de bloqueo

Normalmente (especialmente con AMP aplicacións), espérase que o HSS permaneza residente no modo M, nun U54, para permitir o reinicio por contexto (é dicir, reiniciar só un contexto, sen reinicio de chip completo) e para permitir que o HSS supervise o estado ( ECC, bits de estado de bloqueo, erros de bus, erros de SBI, violacións de PMP, etc.).

Para proporcionar capacidades de reinicio nunAMP base do contexto (sen esixir que todo o sistema reinicie), o E51 normalmente ten acceso á memoria privilexiada a todo o espazo de memoria do sistema. Non obstante, pode haber situacións nas que isto non é desexable e o cliente pode preferir restrinxir o que fai o firmware E51 HSS unha vez que o sistema se iniciou correctamente. Neste caso, é posible poñer o HSS en modo de bloqueo unha vez iniciado o U54 Application Harts.

Isto pódese activar mediante a opción HSS Kconfig CONFIG_SERVICE_LOCKDOWN.
O servizo de bloqueo pretende permitir a restrición das actividades do HSS despois de iniciar a aplicación U54 Harts.

Figura 4.2. Modo de bloqueo HSS

Unha vez que se inicia o modo de bloqueo, detén a execución de todas as outras máquinas de estado do servizo HSS. Chama dúas funcións débilmente ligadas:

e51_pmp_lockdown(), e
e51_lockdown()

Estas funcións están destinadas a ser anuladas por código específico da placa. O primeiro é unha función de activación configurable para permitir que un BSP personalice o bloqueo do E51 das cargas útiles da aplicación neste momento. A implementación predeterminada con límite débil desta función está baleira. A segunda é a funcionalidade que se executa a partir dese momento. A implementación predeterminada ligada débilmente dá servizo ao watchdog neste punto do E51 e reiniciarase se se dispara un watchdog U54. Para obter máis información, consulte o código fonte HSS en services/lockdown/lockdown_service.c file.

Apéndice

Formato HSS payload.bin

Esta sección describe o payload.bin file formato e a imaxe utilizada polo HSS para iniciar o PIC64GX SMP e AMP aplicacións.
O payload.bin é un binario formateado (Figura A.10) que consta dunha cabeceira, varias táboas de descritores e varios anacos que conteñen o código e as seccións de datos de cada parte da carga de traballo da aplicación. Un anaco pódese considerar como un bloque contiguo de tamaño arbitrario de memoria.

Figura A.10. payload.bin Formato

A parte da cabeceira (mostrada na Figura A.11) contén un valor máxico usado para identificar o payload.bin e algunha información de limpeza, xunto con detalles da imaxe que se pretende executar en cada un dos
Códigos de aplicación U54. Describe como arrincar cada hart U54 individual e o conxunto de imaxes de arranque en xeral. Na súa información de mantemento, ten apuntadores a varias táboas de descritores para permitir que o tamaño da cabeceira creza.

Figura A.11. payload.bin Cabeceira

O código e os datos constantes inicializados considéranse de só lectura e almacénanse nunha sección de só lectura, á que sinalan os descritores de cabeceira.
As variables de datos inicializados distintos de cero son datos de lectura-escritura pero teñen os seus valores de inicialización copiados do fragmento de só lectura ao inicio. Estes tamén se almacenan na sección de só lectura.

A sección de datos de carga útil de só lectura descríbese mediante unha táboa de descritores de código e fragmentos de datos. Cada descritor de fragmentos desta táboa contén un "propietario do cervo" (o cervo principal no contexto ao que se dirixe
at), unha compensación de carga (offset dentro do payload.bin) e un enderezo de execución (enderezo de destino na memoria PIC64GX), xunto cun tamaño e suma de verificación. Isto móstrase na Figura A.12.

Figura A.12. Descriptor de fragmentos de só lectura e datos de fragmentos de carga útil

Ademais dos anacos mencionados anteriormente, tamén hai anacos de memoria correspondentes a variables de datos que se inicializan a cero. Estes non se almacenan como datos no payload.bin, senón que son un conxunto especial de descritores de fragmentos inicializados con cero, que especifican un enderezo e lonxitude de memoria RAM para poñer en cero durante o inicio. Isto móstrase na Figura A.13.

Figura A.13. ZI Anacos

xerador de carga útil hss
A ferramenta HSS Payload Generator crea unha imaxe de carga útil formateada para os zero-s de Hart Software Servicetage cargador de arranque en PIC64GX, dada unha configuración file e un conxunto de ELF files e/ou binarios. A configuración file úsase para mapear os binarios ELF ou os blobs binarios aos harts de aplicacións individuais (U54).

Figura B.14. fluxo xerador de carga útil hss

A ferramenta realiza comprobacións básicas de cordura na estrutura da configuración file en si e nas imaxes ELF. As imaxes ELF deben ser executables RISC-V.

Example Corre

Para executar a ferramenta hss-payload-generator co sampconfiguración do le file e ELF files:
$ ./hss-payload-generator -c test/config.yaml output.bin
Para imprimir diagnósticos sobre unha imaxe preexistente, use:
$ ./hss-payload-generator -d saída.bin

Para activar a autenticación de arranque segura (mediante a sinatura de imaxes), use -p para especificar a localización dunha chave privada X.509 para a curva elíptica P-384 (SECP384r1):
$ ./hss-payload-generator -c test/config.yaml payload.bin -p /path/to/private.pem

Para obter máis información, consulte a documentación de Secure Boot Authentication.

Config File Example

En primeiro lugar, podemos definir opcionalmente un nome para a nosa imaxe, se non, crearase un de forma dinámica:
nome-conxunto: 'PIC64-HSS::TestImage'
A continuación, definiremos os enderezos dos puntos de entrada para cada corazón, como segue:
hart-entry-points: {u54_1: ‘0x80200000’, u54_2: ‘0x80200000’, u54_3: ‘0xB0000000′, u54_4:’0x80200000’}

As imaxes de orixe ELF poden especificar un punto de entrada, pero queremos ser capaces de admitir puntos de entrada secundarios para harts se é necesario, por exemploample, se se pretende que varios harts arrinquen a mesma imaxe, poden ter puntos de entrada individuais. Para apoiar isto, especificamos os enderezos reais dos puntos de entrada na configuración file en si.

Agora podemos definir algunhas cargas útiles (fonte ELF files, ou blobs binarios) que se colocarán en determinadas rexións da memoria. A sección de carga útil defínese coa palabra clave cargas útiles e, a continuación, unha serie de descritores de carga útil individual. Cada carga útil ten un nome (camiño ao seu file), un cervo propietario e, opcionalmente, de 1 a 3 cervos secundarios.

Ademais, unha carga útil ten un modo de privilexios no que comezará a executarse. Os modos de privilexio válidos son PRV_M, PRV_S e PRV_U, onde se definen como:

PRV_M Modo máquina
PRV_S Modo supervisor
PRV_U Modo usuario

No seguinte exampLe:

Suponse que test/zephyr.elf é unha aplicación Zephyr que se executa en U54_3 e espera iniciarse no modo de privilexios PRV_M.
test/u-boot-dtb.bin é a aplicación do cargador de arranque de Das U-Boot e execútase en U54_1, U54_2 e U54_4. Espera comezar no modo de privilexios PRV_S.

Importante:
A saída de U-Boot crea un ELF file, pero normalmente non antepón a extensión .elf. Neste caso, utilízase o binario creado por CONFIG_OF_SEPARATE, que engade un blob de árbore de dispositivos ao binario U-Boot.

Aquí está o example Configuración de cargas útiles 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', propietario-hart: u54_1, secundario-hart: u54_2, secundario-hart: u54_4, priv-mode: prv_s}

Importante:
O caso só importa para o file nomes de camiños, non as palabras clave. Así, por exemplo, u54_1 considérase o mesmo que U54_1 e exec-addr considérase o mesmo que EXEC-ADDR. Se hai unha extensión.elf ou .bin, debe incluírse na configuración file.

Para unha aplicación simple que non quere preocuparse por OpenSBI, a opción skip-opens, se é verdadeira, fará que se invoque a carga útil nese corazón mediante un simple mret.
que unha chamada OpenSBI sbi_init(). Isto significa que o corazón comezará a executar o código bare metal independentemente de calquera consideración de OpenSBI HSM. Teña en conta que isto tamén significa que o corazón non pode usar
e chama para invocar a funcionalidade de OpenSBI. A opción skip-opens é opcional e por defecto é false.

Para permitir un reinicio en caliente do contexto doutro contexto, podemos engadir a opción permitir o reinicio: quente. Para permitir un reinicio en frío contextual de todo o sistema, podemos engadir a opción allow-reboot: cold. De forma predeterminada, sen especificar allow-reboot, un contexto só está autorizado para quentar o reinicio.
Tamén é posible asociar datos auxiliares a cada carga útil, por exemploample, un Blob DeviceTree (DTB) file, especificando os datos auxiliares filenome do seguinte xeito:
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, datos auxiliares : test/pic64gx.dtb }
Estes datos auxiliares incluiranse na carga útil (colocada inmediatamente despois do principal file no executable
espazo), e o seu enderezo pasarase a OpenSBI no campo next_arg1 (pasado no rexistro $a1 á imaxe no momento do arranque).

Para evitar que o HSS inicie automaticamente un contexto (por exemplo, se queremos delegar o control deste a un contexto mediante remoteProc), use a marca skip-autoboot:
test/zephyr.elf: {exec-addr: '0xB0000000', owner-hart: u54_3, priv-mode: prv_m, skip-opensbi: true, skip-autoboot: true}
Finalmente, opcionalmente podemos anular os nomes das cargas útiles individuais, usando a opción payload-name. Por exampLe:
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, datos auxiliares : test/pic64gx.dtb, nome da carga útil: 'u-boot' }

Teña en conta que os creadores Yocto e Buildroot Linux construirán, configurarán e executarán o hss-payload-
xerador segundo sexa necesario para xerar imaxes da aplicación. Ademais, o pic64gx-curiosity-kit-amp O destino da máquina en Yocto xerará unha imaxe de aplicación usando a ferramenta hss-payload-generator que demostra AMP, con Linux funcionando en 3 harts e Zephyr en 1 hart.

Historial de revisións
O historial de revisións describe os cambios que se implementaron no documento. Os cambios están listados por revisión, comezando pola publicación máis recente.

Revisión	Data	Descrición
A	07/2024	Revisión inicial

Información do microchip

O Microchip Websitio
Microchip ofrece soporte en liña a través do noso websitio en www.microchip.com/. Isto websitio úsase para facer files e información facilmente dispoñible para os clientes. Algúns dos contidos dispoñibles inclúen:

Apoio ao produto – Fichas técnicas e erratas, notas de aplicación e sample programas, recursos de deseño, guías de usuario e documentos de soporte de hardware, últimas versións de software e software arquivado

Soporte técnico xeral - Preguntas frecuentes (FAQ), solicitudes de soporte técnico, grupos de discusión en liña, lista de membros do programa de socios de deseño de Microchip
Negocio de Microchip - Selector de produtos e guías de pedidos, últimos comunicados de prensa de Microchip, unha lista de seminarios e eventos, listados de oficinas de vendas, distribuidores e representantes de fábrica de Microchip

Servizo de notificación de cambios de produto

O servizo de notificación de cambios de produtos de Microchip axuda a manter os clientes ao día dos produtos de Microchip. Os subscritores recibirán unha notificación por correo electrónico sempre que haxa cambios, actualizacións, revisións ou erratas relacionadas cunha familia de produtos especificada ou ferramenta de desenvolvemento de interese.

Para rexistrarte, vai a www.microchip.com/pcn e siga as instrucións de rexistro.

Atención ao cliente
Os usuarios de produtos Microchip poden recibir asistencia a través de varias canles:

Distribuidor ou Representante
Oficina local de vendas
Enxeñeiro de solucións integradas (ESE)
Soporte técnico

Os clientes deben contactar co seu distribuidor, representante ou ESE para obter asistencia. As oficinas de vendas locais tamén están dispoñibles para axudar aos clientes. Neste documento inclúese unha lista de oficinas de vendas e locais.
O soporte técnico está dispoñible a través de websitio en: www.microchip.com/support.

Función de protección de código de dispositivos de microchip
Teña en conta os seguintes detalles da función de protección de código nos produtos Microchip:

Os produtos de microchip cumpren as especificacións contidas na súa ficha de datos de microchip.
Microchip considera que a súa familia de produtos é segura cando se usa da forma prevista, dentro das especificacións de funcionamento e en condicións normais.

Microchip valora e protexe agresivamente os seus dereitos de propiedade intelectual. Os intentos de incumprir as funcións de protección do código dos produtos Microchip están estrictamente prohibidos e poden infrinxir a Digital Millennium Copyright Act.
Nin Microchip nin ningún outro fabricante de semicondutores poden garantir a seguridade do seu código. A protección do código non significa que esteamos garantindo que o produto sexa "irrompible". A protección do código está en constante evolución. Microchip comprométese a mellorar continuamente as funcións de protección do código dos nosos produtos.

Aviso Legal
Esta publicación e a información que aparece aquí só poden usarse con produtos Microchip, incluso para deseñar, probar e integrar produtos Microchip coa súa aplicación. O uso desta información de calquera outra forma viola estes termos. A información relativa ás aplicacións do dispositivo ofrécese só para a súa comodidade e pode ser substituída por actualizacións. É a súa responsabilidade asegurarse de que a súa aplicación cumpra coas súas especificacións. Póñase en contacto coa súa oficina local de vendas de Microchip para obter asistencia adicional ou obtén soporte adicional en www.microchip.com/en-us/support/design-help/client-support-services.

ESTA INFORMACIÓN ESTÁ PROPORCIONADA POR MICROCHIP "TAL CUAL". MICROCHIP NON OFRECE REPRESENTACIÓNS OU GARANTÍAS DE NINGÚN TIPO, XA EXPRESA OU IMPLÍCITA, ESCRITA OU ORAL, LEGAL OU DE OUTRO MODO, RELACIONADA COA INFORMACIÓN, INCLUÍENDO PERO NON LIMITADO A NINGÚN TIPO DE GARANTÍAS IMPLÍCITAS DE NON INFRACCIÓN, COMERCIABILIDADE, COMERCIABILIDADE E COMERCIALIZACIÓN. GARANTÍAS RELACIONADAS CO SEU ESTADO, CALIDADE OU RENDEMENTO.

EN NINGÚN CASO MICROCHIP SERÁ RESPONSABLE DE NINGÚN TIPO DE PERDA, DANO, CUSTO OU GASTO INDIRECTO, ESPECIAL, PUNITIVO, INCIDENTAL OU CONSECUENCIAL DE NINGÚN TIPO RELACIONADO COA INFORMACIÓN OU O SEU USO, AÍNDA QUE SE SEXA O CAUSADO QUE SEXA O SEU ADVERTENCIA. A POSIBILIDADE OU OS DANOS SON PREVISIBLES. NA MÁXIMA MEDIDA PERMITIDA POLA LEI, A RESPONSABILIDADE TOTAL DE MICROCHIP SOBRE TODAS LAS RECLAMACIONS DE CALQUERA FORMA RELACIONADAS COA INFORMACIÓN OU O SEU USO NON SUPERARÁ O NÚMERO DE TAXAS, SE HOXE, QUE PAGOU DIRECTAMENTE A MICROCHIP POLA INFORMACIÓN.

O uso de dispositivos Microchip en aplicacións de soporte vital e/ou de seguridade corre totalmente a risco do comprador, e o comprador comprométese a defender, indemnizar e eximir a Microchip de todos os danos, reclamacións, demandas ou gastos derivados de tal uso. Non se transmite ningunha licenza, implícita ou doutra forma, baixo ningún dereito de propiedade intelectual de Microchip a menos que se indique o contrario.

Marcas comerciais
O nome e o logotipo de Microchip, o logotipo de Microchip, Adaptec, AVR, logotipo de AVR, AVR Freaks, BesTime, BitCloud, CryptoMemory, CryptoRF, dsPIC, flexPWR, HELDO, IGLOO, JukeBlox, KeeLoq, Kleer, LANCheck, LinkMD, maXStyluuchs, MediaLB, megaAVR, Microsemi, Microsemi logo, MOST, MOST logo, MPLAB, OptoLyzer, PIC, picoPower, PICSTART, PIC32 logo, PolarFire, Prochip Designer, QTouch, SAM-BA, SenGenuity, SpyNIC, SST, SST Logo, SuperFlash, Symmetricom , SyncServer, Tachyon, TimeSource, tinyAVR, UNI/O, Vectron e XMEGA son marcas rexistradas de Microchip Technology Incorporated nos EUA e noutros países.

AgileSwitch, ClockWorks, The Embedded Control Solutions Company, EtherSynch, Flashtec, Hyper Speed Control, HyperLight Load, Libero, motor bench, mTouch, Powermite 3, Precision Edge, ProASIC, ProASIC Plus, logo ProASIC Plus, Quiet-Wire, SmartFusion, SyncWorld , TimeCesium, TimeHub, TimePictra, TimeProvider e ZL son marcas rexistradas de Microchip Technology Incorporated nos EUA

Supresión de teclas adxacentes, AKS, Analog-for-the-Digital Age, Any Capacitor, AnyIn, AnyOut, Augmented Switching, BlueSky, BodyCom, Clockstudio, CodeGuard, CryptoAuthentication, CryptoAutomotive, CryptoCompanion, CryptoController, dsPICDEM, dsPICDEM Averagenet, Dynamic Matching. , DAM, ECAN, Espresso T1S, EtherGREEN, EyeOpen, GridTime, IdealBridge,
IGaT, programación en serie en circuito, ICSP, INICnet, paralelismo intelixente, IntelliMOS, conectividade entre chips, JitterBlocker, Knob-on-Display, MarginLink, maxCrypto, maxView, memBrain, Mindi, MiWi, MPASM, MPF, MPLAB Certified logo, MPLIB, MPLINK, mSiC, MultiTRAK, NetDetach, Omniscient Code Generation, PICDEM, PICDEM.net, PICkit, PICtail, Power MOS IV, Power MOS 7, PowerSmart, PureSilicon , QMatrix, REAL ICE, Ripple Blocker, RTAX, RTG4, SAM-ICE, Serial Quad I/O, 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 e ZENA son marcas comerciais de Microchip Technology Incorporated nos EUA e noutros países.

SQTP é unha marca de servizo de Microchip Technology Incorporated nos EUA
O logotipo de Adaptec, Frequency on Demand, Silicon Storage Technology e Symmcom son marcas rexistradas de Microchip Technology Inc. noutros países.
GestIC é unha marca rexistrada de Microchip Technology Germany II GmbH & Co. KG, unha subsidiaria de Microchip Technology Inc., noutros países.

ISBN: 978-1-6683-4890-1

Sistema de Xestión da Calidade
Para obter información sobre os sistemas de xestión da calidade de Microchip, visite www.microchip.com/quality.

Vendas e servizo no mundo

AMÉRICAS

ASIA/PACÍFICO

EUROPA

Corporativo Oficina

2355 West Chandler Blvd. Chandler, AZ 85224-6199

Tel: 480-792-7200

Fax: 480-792-7277

Soporte técnico: www.microchip.com/support

Web Enderezo: www.microchip.com

Atlanta

Duluth, GA

Tel: 678-957-9614

Fax: 678-957-1455

Austin, TX

Tel: 512-257-3370

Boston

Westborough, MA Teléfono: 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

Os Ánxeles

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 Xosé, CA

Tel: 408-735-9110

Tel: 408-436-4270

Canadá – Toronto

Tel: 905-695-1980

Fax: 905-695-2078

Australia - Sidney

Teléfono: 61-2-9868-6733

China - Pequín

Teléfono: 86-10-8569-7000

China - Chengdu

Teléfono: 86-28-8665-5511

China - Chongqing

Teléfono: 86-23-8980-9588

China - Dongguan

Teléfono: 86-769-8702-9880

China - Guangzhou

Teléfono: 86-20-8755-8029

China - Hangzhou

Teléfono: 86-571-8792-8115

China – Hong Kong SAR

Teléfono: 852-2943-5100

China - Nanjing

Teléfono: 86-25-8473-2460

China - Qingdao

Teléfono: 86-532-8502-7355

China - Shanghai

Teléfono: 86-21-3326-8000

China - Shenyang

Teléfono: 86-24-2334-2829

China - Shenzhen

Teléfono: 86-755-8864-2200

China - Suzhou

Teléfono: 86-186-6233-1526

China - Wuhan

Teléfono: 86-27-5980-5300

China - Xian

Teléfono: 86-29-8833-7252

China - Xiamen

Teléfono: 86-592-2388138

China - Zhuhai

Teléfono: 86-756-3210040

India – Bangalore

Teléfono: 91-80-3090-4444

India - Nova Deli

Teléfono: 91-11-4160-8631

India – Pune

Teléfono: 91-20-4121-0141

Xapón – Osaka

Teléfono: 81-6-6152-7160

Xapón – Tokio

Teléfono: 81-3-6880- 3770

Corea - Daegu

Teléfono: 82-53-744-4301

Corea - Seúl

Teléfono: 82-2-554-7200

Malaisia - Kuala Lumpur

Teléfono: 60-3-7651-7906

Malaisia - Penang

Teléfono: 60-4-227-8870

Filipinas – Manila

Teléfono: 63-2-634-9065

Singapur

Teléfono: 65-6334-8870

Taiwán – Hsin Chu

Teléfono: 886-3-577-8366

Taiwán – Kaohsiung

Teléfono: 886-7-213-7830

Taiwán – Taipei

Teléfono: 886-2-2508-8600

Tailandia -Bangkok

Teléfono: 66-2-694-1351

Vietnam - Ho Chi Minh

Teléfono: 84-28-5448-2100

Austria – Wels

Teléfono: 43-7242-2244-39

Fax: 43-7242-2244-393

Dinamarca – Copenhague

Teléfono: 45-4485-5910

Fax: 45-4485-2829

Finlandia – Espoo

Teléfono: 358-9-4520-820

Francia – París

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

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

Alemaña – garching

Teléfono: 49-8931-9700

Alemaña – Haan

Teléfono: 49-2129-3766400

Alemaña – Heilbronn

Teléfono: 49-7131-72400

Alemaña – Karlsruhe

Teléfono: 49-721-625370

Alemaña – Múnic

Tel: 49-89-627-144-0

Fax: 49-89-627-144-44

Alemaña – Rosenheim

Teléfono: 49-8031-354-560

Israel – Hod Hasharon

Teléfono: 972-9-775-5100

Italia - Milán

Teléfono: 39-0331-742611

Fax: 39-0331-466781

Italia - Padua

Teléfono: 39-049-7625286

Países Baixos - Drunen

Teléfono: 31-416-690399

Fax: 31-416-690340

Noruega – Trondheim

Teléfono: 47-72884388

Polonia - Varsovia

Teléfono: 48-22-3325737

Romanía – Bucarest

Tel: 40-21-407-87-50

España – Madrid

Tel: 34-91-708-08-90

Fax: 34-91-708-08-91

Suecia - Gotemburgo

Tel: 46-31-704-60-40

Suecia - Estocolmo

Teléfono: 46-8-5090-4654

Reino Unido - Wokingham

Teléfono: 44-118-921-5800

Fax: 44-118-921-5820

Documentos/Recursos

MICROCHIP PIC64GX Microprocesador de catro núcleos RISC-V de 64 bits [pdfGuía do usuario
PIC64GX, PIC64GX Microprocesador de catro núcleos RISC-V de 64 bits, Microprocesador de catro núcleos RISC-V de 64 bits, Microprocesador de catro núcleos RISC-V, Microprocesador de catro núcleos, Microprocesador

Referencias

Manual de usuario

MICROCHIP PIC64GX Microprocesador de catro núcleos RISC-V de 64 bits

Información do produto

Instrucións de uso do produto