MICROCHIP PIC64GX 64-bitars RISC-V Quad-Core mikroprocessor användarhandbok

Startprocess
1. Programvarukomponenter som är involverade i uppstart
  Systemstartprocessen innefattar följande programvarukomponenter:
  - Hart Software Services (HSS): En noll-stage starthanterare, systemövervakare och leverantör av runtime-tjänster för applikationer.
2. Boot Flow
  Sekvensen för systemstartflödet är som följer:
  1. Initiering av Hart Software Services (HSS)
  2. Körning av bootloader
  3. Appstart
Vakthundar
1. PIC64GX Watchdog
  PIC64GX har en övervakningsfunktion för att övervaka systemets funktion och utlösa åtgärder vid systemfel.
Låsningsläge
Låsningsläget är designat för kunder som kräver fullständig kontroll över systemåtgärder efter uppstart. Det begränsar funktionerna hos E51-systemmonitorn.

FAQ

F: Vad är syftet med Hart Software Services (HSS)?
S: HSS fungerar som nollortage starthanterare, systemövervakare och leverantör av runtime-tjänster för applikationer under uppstartsprocessen.
F: Hur fungerar PIC64GX watchdog-funktionen?
S: PIC64GX watchdog övervakar systemets funktion och kan vidta fördefinierade åtgärder vid systemfel för att säkerställa systemets tillförlitlighet.

Introduktion

Detta whitepaper förklarar hur Microchip PIC64GX startar applikationsarbetsbelastningar och beskriver systemstartprocessen, som fungerar på samma sätt för SMP och AMP arbetsbelastningar. Dessutom täcker det hur en omstart fungerar för SMP och AMP arbetsbelastningar, vakthundar på PIC64GX och ett speciellt låsläge för system där kunder önskar fullständig kontroll för att begränsa åtgärderna för E51-systemmonitorn efter systemstart.

Startprocess

Låt oss ta en titt på de olika programvarukomponenterna som är involverade i systemstart, följt av en mer detaljerad titt på sekvensen för själva systemstartflödet.

Programvarukomponenter som är involverade i uppstart
Följande komponenter är involverade i systemets startprocess:

Figur 1.1. Uppstartskomponenter

Hart Software Services (HSS)
Hart Software Services (HSS) är en nollatagen starthanterare, en systemövervakare och en leverantör av runtime-tjänster för applikationer. HSS stöder tidig systeminstallation, DDR-utbildning och hårdvaruinitiering/konfiguration. Den körs mestadels på E51s, med en liten mängd maskinlägesnivåfunktioner som körs på varje U54. Den startar ett eller flera sammanhang genom att ladda applikationens "nyttolast" från startmediet och tillhandahåller Platform Runtime Services/Supervisor Execution Environment (SEE) för operativsystemets kärnor. Den stöder säker start och är en viktig komponent för att säkerställa hårdvarupartitionering/separation för AMP sammanhang.

Das U-Boot (U-Boot)
Das U-Boot (U-Boot) är en universell skriptbar starthanterare med öppen källkod. Den stöder en enkel CLI som kan hämta startbilden från en mängd olika källor (inklusive ett SD-kort och nätverket). U-Boot laddar Linux. Den kan tillhandahålla en UEFI-miljö om det behövs. Det är i allmänhet färdigt och ur vägen när Linux har startat upp – med andra ord, det stannar inte kvar efter uppstart.
Linux kärna
Linuxkärnan är världens mest populära operativsystemkärna. I kombination med ett användarland av applikationer bildar det vad som vanligtvis kallas ett Linux-operativsystem. Ett Linux-operativsystem tillhandahåller rika POSIX API:er och utvecklarmiljö, till exempelample, språk och verktyg som Python, Perl, Tcl, Rust, C/C++ och Tcl; bibliotek som OpenSSL, OpenCV, OpenMP, OPC/UA och OpenAMP (RPmsg och RemoteProc).
Yocto och Buildroot är Linux-systembyggare, det vill säga de kan användas för att skapa skräddarsydda anpassade Linux-system. Yocto matar ut en Linux-distribution med en rich
uppsättning applikationer, verktyg och bibliotek och valfri pakethantering. Buildroot ger en mer minimal rot filesystem och kan rikta in sig på system som inte kräver beständig lagring utan körs helt från RAM (med hjälp av Linuxs initialer stöd, t.ex.ample).

Zephyr
Zephyr är ett litet realtidsoperativsystem (RTOS) med öppen källkod. Den tillhandahåller ett Real-Time Low-Overhead Framework, med RPMsg-lite kommunikationskanaler till Linux. Den innehåller en kärna, bibliotek, drivrutiner, protokollstackar, filesystem, mekanismer för firmwareuppdateringar och så vidare, och är bra för kunder som vill ha en mer barmetall-liknande upplevelse på PIC64GX.

Boot Flow
PIC64GX inkluderar en RISC-V-coreplex med en 64-bitars E51-systemövervakarharts och 4 64-bitars U54-applikationshjärter. I RISC-V-terminologi är en hart en RISC-V-exekveringskontext som innehåller en fullständig uppsättning register och som exekverar sin kod oberoende. Du kan tänka på det som en hårdvarutråd eller en enda CPU. En grupp av harts inom en enda kärna kallas ofta ett komplex. Det här avsnittet beskriver stegen för att initiera PIC64GX coreplex, inklusive E51-systemet övervakar hjärtat och U54-applikationshjärtarna.

Slå på PIC64GX coreplex.
Vid start frigörs alla hjärtor i RISC-V-coreplex från återställning av säkerhetskontrollern.
Kör HSS-koden från eNVM-flashminnet på chipet.
Inledningsvis börjar varje hjärta köra HSS-koden från eNVM-flashminnet på kretsen. Den här koden får alla U54-applikationshjärtar att snurra i väntan på instruktioner och låter E51-monitorhjärten börja köra kod för att initiera och ta fram systemet.

Dekomprimera HSS-koden från eNVM till L2-Scratch-minne.
Beroende på dess byggtidskonfiguration är HSS vanligtvis större än kapaciteten för själva eNVM-flashminnet och så det första HSS-koden som körs på E51 gör är att dekomprimera sig själv från eNVM till L2-Scratch-minne, som visas i figuren 1.2 och figur 1.3.
Figur 1.2. HSS Dekomprimerar från eNVM till L2 Scratch
Figur 1.3. HSS-minneskarta under dekompression
Hoppa från eNVM till L2-Scratch till en körbar fil som visas i följande figur.
Figur 1.4. HSS hoppar från eNVM till kod nu i L2Scratch efter dekompression
Den körbara filen består av tre komponenter:
- Hårdvaruabstraktionslagret (HAL), lågnivåkod och drivrutiner för ren metall
- En lokal HSS-gaffel av RISC-V OpenSBI (modifierad något från uppströms på PIC64GX för AMP syften)
- HSS-runtime-tjänsterna (tillståndsmaskiner körs i en superloop)
Initiera hårdvaran och datastrukturerna som används av OpenSBI.
HSS-tjänsten "Startup" ansvarar för denna initiering.

Hämta bilden av programmets arbetsbelastning (payload.bin) från extern lagring. Detta visas i figur 1.5 och figur 1.6
Viktigt: När det gäller PIC64GX Curiosity Kit kommer detta att vara från ett SD-kort.
Figur 1.5. Hämtar payload.bin Arbetsbelastningsbild från extern lagring
Figur 1.6. HSS Minneskarta efter att ha hämtat payload.bin
Kopiera de olika avsnitten från payload.bin till deras exekveringstidsdestinationer. Payload.bin är en formaterad bild som konsoliderar olika applikationsbilder för SMP eller AMP arbetsbelastningar. Den innehåller kod-, data- och deskriptortabeller som gör det möjligt för HSS att på lämpligt sätt placera kod- och datasektionerna där de behövs för att köra de olika applikationsarbetsbelastningarna.
Figur 1.7. payload.bin kopieras till destinationsadresser

Instruera relevanta U54:or att hoppa till deras startadresser för körning. Denna startadressinformation finns i payload.bin.
Starta U54 Application harts och eventuella andra-stage boot loaders. Till exempelample, U-Boot tar upp Linux.

Starta om

Relaterat till konceptet med systemstart är behovet av att starta om. När du tänker på PIC64GX-applikationsarbetsbelastningar måste omstarten ta hänsyn till både symmetrisk multiprocessing (SMP) och asymmetrisk multiprocessing (AMP) scenarier:

I fallet med ett SMP-system kan en omstart säkert kallstarta hela systemet eftersom det inte finns några ytterligare arbetsbelastningar i ett annat sammanhang att ta hänsyn till.

I fallet med en AMP system, kanske en arbetsbelastning bara tillåts starta om sig själv (och inte störa någon annan kontext), eller så kan den vara privilegierad att kunna utföra en fullständig omstart av systemet.

Starta om och AMP
För att aktivera SMP och AMP omstartsscenarier, stöder HSS koncepten för varm och kall omstartsprivilegier, som kan tilldelas till ett sammanhang. En kontext med behörighet för varm omstart kan bara starta om sig själv, och en kontext med behörighet för kall omstart kan utföra en fullständig omstart av systemet. Till exempelample, överväga följande uppsättning representativa scenarier.

En SMP-arbetsbelastning för enstaka sammanhang, som tillåts begära en fullständig omstart av systemet
I det här scenariot tillåts sammanhanget kall omstartsprivilegium.
En tvåkontext AMP arbetsbelastning, där sammanhang A tillåts begära en fullständig omstart av systemet (som påverkar alla sammanhang), och sammanhang B endast tillåts starta om sig själv
I det här scenariot tillåts kontext A kall omstartsprivilegium och sammanhang B tillåts varm omstartsprivilegium.
En tvåkontext AMP arbetsbelastning, där sammanhang A och B endast tillåts starta om sig själva (och inte påverkar det andra sammanhanget)
I det här scenariot tillåts båda sammanhangen endast varma omstartsprivilegier.
En tvåkontext AMP arbetsbelastning, där sammanhang A och B båda tillåts begära fullständiga omstarter av systemet
I det här scenariot tillåts båda sammanhangen kall omstartsprivilegier.
Dessutom är det möjligt för HSS vid byggtid att alltid tillåta kall omstartsprivilegium och aldrig tillåta kall omstartsprivilegium.

Relevanta HSS Kconfig-alternativ
Kconfig är ett mjukvarubyggt konfigurationssystem. Det används ofta för att välja byggtidsalternativ och för att aktivera eller inaktivera funktioner. Den har sitt ursprung i Linux-kärnan men har nu hittat användning i andra projekt utöver Linux-kärnan, inklusive U-Boot, Zephyr och PIC64GX HSS.

HSS innehåller två Kconfig-alternativ som styr omstartsfunktionen från HSS-perspektiv:

CONFIG_ALLOW_COLD OMBOTA
Om detta är aktiverat tillåter det globalt att ett sammanhang skickar ett kall omstartsanrop. Om den är inaktiverad kommer endast varma omstarter att tillåtas. Förutom att aktivera det här alternativet måste behörighet att utfärda en kall omstart ges till ett sammanhang via nyttolastgeneratorn YAML file eller följande Kconfig-alternativ.
CONFIG_ALLOW_COLD REBOOT_ALWAYS
- Om den är aktiverad tillåter den här funktionen globalt att alla sammanhang utfärdar en kall omstart ECAA, oavsett flaggbehörigheterna payload.bin.
- Dessutom kan själva payload.bin innehålla en per-kontext-flagga, som indikerar att en viss kontext har rätt att utfärda kalla omstarter:
  - För att tillåta en kontext varm omstart ett annat sammanhang, kan vi lägga till alternativet tillåt-omstart: varm i YAML-beskrivningen file används för att skapa payload.bin
  - För att tillåta en kontext kall omstart av hela systemet kan vi lägga till alternativet tillåt-omstart: kall. Som standard, utan att ange tillåt-omstart, tillåts en kontext endast varm omstart själv. Oavsett inställningen av denna flagga, om CONFIG_ALLOW_COLDREBOOT inte är aktiverat i HSS, kommer HSS att omarbeta alla kall omstartsbegäranden för att värma (per sammanhang) omstarter .

Starta om i detalj
Det här avsnittet beskriver hur omstarten fungerar i detalj – börja med OpenSBI-lagret (det lägsta M-mode-lagret) och sedan diskutera hur denna OpenSBI-lagerfunktionalitet utlöses från en RTOS-applikation eller ett rikt OS som Linux.

OpenSBI Starta om anrop

RISC-V Supervisor Binary Interface (SBI)-specifikationen beskriver ett standardiserat hårdvaruabstraktionslager för plattformsinitiering och firmware runtime-tjänster. Huvudsyftet med SBI är att möjliggöra portabilitet och kompatibilitet över olika RISC-V-implementeringar.
OpenSBI (Open Source Supervisor Binary Interface) är ett öppen källkodsprojekt som tillhandahåller en referensimplementering av SBI-specifikationen. OpenSBI tillhandahåller också runtime-tjänster, inklusive avbrottshantering, timerhantering och konsol-I/O, som kan användas av mjukvarulager på högre nivå.
OpenSBI ingår som en del av HSS och körs på maskinlägesnivå. När operativsystemet eller applikationen orsakar en fälla kommer den att skickas till OpenSBI för att hantera den. OpenSBI exponerar en viss systemanropsfunktion för de övre skikten av programvaran genom en speciell fällmekanism som kallas ett uppringning.

Systemåterställningen (EID 0x53525354) tillhandahåller en omfattande systemanropsfunktion som gör att programvaran för det övre lagret kan begära omstart eller avstängning på systemnivå. När detta anrop anropas av en U54, fångas det av HSS-mjukvaran som körs i maskinläge på den U54:an, och en motsvarande omstartsbegäran skickas till E51 för att starta om antingen sammanhanget eller hela systemet, beroende på rättigheterna för sammanhang.

För mer information, se RISC-V Supervisor Binary Interface Specification särskilt Systemåterställningstillägg (EID #0x53525354 "SRST").

Linux omstart

Som ett specifikt exampAv detta, i Linux, används shutdown-kommandot för att stoppa eller starta om systemet. Kommandot har vanligtvis många alias, nämligen stopp, stäng av och starta om. Dessa alias anger om maskinen ska stoppas vid avstängning, stänga av maskinen vid avstängning eller starta om maskinen vid avstängning.

Dessa användarutrymmeskommandon utfärdar ett systemanrop för omstart till Linux, som fångas av kärnan och samverkar med ett SBI-anrop.
Det finns olika nivåer av omstart – REBOOT_WARM, REBOOT_COLD, REBOOT_HARD – dessa kan skickas som kommandoradsargument till kärnan (t.ex.ample, reboot=w[arm] för REBOOT_WARM). För mer information om Linux-kärnans källkod, se Documentation/admin-guide/kernel-paramters.txt.
Alternativt, om /sys/kernel/reboot är aktiverat, kan hanterarna nedan läsas för att få den aktuella systemets omstartskonfiguration och skrivas för att ändra den. För mer information om Linux-kärnans källkod, se Dokumentation/ABI/testing/sysfs-kernel-reboot.

Vakthundar

Ett ytterligare koncept relaterat till systemstart och systemomstart är systemåterställning vid avfyrning av en watchdog-timer. Watchdog-timers används ofta i inbyggda system för att automatiskt återställa från övergående hårdvarufel och för att förhindra felaktig eller illvillig programvara från att störa systemets funktion.
PIC64GX inkluderar hårdvaruövervakningsstöd för att övervaka individuella hjärter när systemet körs. Vakthundarna ser till att harts kan startas om om de inte svarar på grund av oåterställbara programvarufel.
PIC64GX innehåller fem instanser av watchdog-timerhårdvarublock som används för att upptäcka systemlåsningar - en för var och en av hjärterna. För att underlätta blandad asymmetrisk multibearbetning (AMP) arbetsbelastningar, stöder HSS övervakning och reagerar på vakthundens avfyrning.

PIC64GX Watchdog

HSS ansvarar för att starta applikationshjärtarna vid uppstart och för att starta om dem (individuellt eller kollektivt) när som helsttage, om det behövs eller önskas. Som en konsekvens av detta hanteras reaktionen på övervakningshändelser på PIC64GX av HSS.
En "virtuell vakthund"-monitor implementeras som en HSS-tillståndsmaskintjänst, och dess ansvar är att övervaka statusen för var och en av U54:s individuella övervakningshårdvarumonitorer. När en av dessa U54-vakthundar trippar, upptäcker HSS detta och kommer att starta om U54 vid behov. Om U54 är en del av en SMP-kontext, övervägs hela sammanhanget för omstart, förutsatt att sammanhanget har varm omstartsprivilegium. Hela systemet kommer att startas om om sammanhanget har kallstartsrättigheter.

Relevanta Kconfig-alternativ

Watchdog-stöd ingår som standard i släppta HSS-byggen. Om du vill bygga en anpassad HSS kommer detta avsnitt att beskriva konfigurationsmekanismen för att säkerställa att Watchdog-stödet är aktiverat.

HSS konfigureras med hjälp av Kconfig-konfigurationssystemet. En toppnivå .config file behövs för att välja vilka tjänster som ska kompileras i eller ut ur HSS-bygget.
För det första måste alternativet CONFIG_SERVICE_WDOG på översta nivån vara aktiverat (”Virtual Watchdog support” genom make config).

Detta visar sedan följande underalternativ som är beroende av Watchdog-stöd:

CONFIG_SERVICE_WD OG_DEBUG
Möjliggör stöd för informations-/felsökningsmeddelanden från den virtuella watchdog-tjänsten.
CONFIG_SERVICE_WD OG_DEBUG_TIMEOUT_SECS
Bestämmer periodiciteten (i sekunder) som Watchdog-felsökningsmeddelanden kommer att matas ut av HSS.
CONFIG_SERVICE_WD OG_ENABLE_E51
Aktiverar vakthunden för E51 övervakar hjärtat förutom U54s, vilket skyddar driften av själva HSS.

När E51 watchdog är aktiverad kommer HSS regelbundet att skriva till Watchdog för att uppdatera den och förhindra att den avfyras. Om E51-hjärtat av någon anledning låser sig eller kraschar och E51-vakthunden är aktiverad kommer detta alltid att återställa hela systemet.

Vakthundsoperation
Watchdog-hårdvaran implementerar nedräknare. Ett uppdateringsförbjudet fönster kan skapas genom att konfigurera övervakningshundens maximala värde upp till vilket uppdatering är tillåten (MVRP).

När det aktuella värdet för watchdog-timern är större än MVRP-värdet, är det förbjudet att uppdatera watchdog. Ett försök att uppdatera watchdog-timern i det förbjudna fönstret kommer att utlösa ett timeout-avbrott.

Om du uppdaterar vakthunden mellan MVRP-värdet och triggervärdet (TRIG) uppdateras räknaren framgångsrikt och förhindrar vakthunden från att skjuta.
När watchdog-timerns värde räknas under TRIG-värdet, kommer watchdog att avfyras.

Watchdog State Machine

Watchdog-tillståndsmaskinen är mycket enkel – startar genom att konfigurera watchdog för E51, om den är aktiverad, och sedan gå igenom ett viloläge till övervakning. Varje gång runt superloopen anropas detta övervakningstillstånd, vilket kontrollerar statusen för var och en av U54-vakthundarna.

Watchdog-tillståndsmaskinen interagerar med starttillståndsmaskinen för att starta om en harts (och alla andra harts som finns i dess startuppsättning), om den upptäcker att hartsen inte har lyckats uppdatera sin watchdog i tid.

Låsningsläge

Normalt (särskilt med AMP applikationer), förväntas det att HSS kommer att stanna kvar i M-läge, på en U54, för att tillåta omstart per sammanhang (dvs. starta om endast ett sammanhang, utan full-chip-omstart), och för att tillåta HSS att övervaka hälsan ( ECC, låsstatusbitar, bussfel, SBI-fel, PMP-överträdelser, etc).

För att tillhandahålla omstartsmöjligheter på en per-AMP kontextbaserad (utan att hela systemet måste startas om) har E51 normalt privilegierad minnesåtkomst till hela systemets minnesutrymme. Det kan dock finnas situationer där detta inte är önskvärt, och kunden kanske föredrar att begränsa vad E51 HSS-firmware gör när systemet väl har startat. I det här fallet är det möjligt att sätta HSS i låst läge när U54 Application Harts har startats.

Detta kan aktiveras med HSS Kconfig-alternativet CONFIG_SERVICE_LOCKDOWN.
Lockdown-tjänsten är avsedd att tillåta begränsning av HSS:s aktiviteter efter att den har startat upp U54-applikationen Harts.

Figur 4.2. HSS-låsningsläge

När låsningsläget startar stoppar det alla andra HSS-tjänsttillståndsmaskiner från att köras. Den anropar två svagt bundna funktioner:

e51_pmp_lockdown(), och
e51_lockdown()

Dessa funktioner är avsedda att åsidosättas av kortspecifik kod. Den första är en konfigurerbar triggerfunktion för att tillåta en BSP att anpassa låsning av E51 från applikationens nyttolaster vid denna tidpunkt. Den svagt bundna standardimplementeringen av denna funktion är tom. Den andra är den funktionalitet som körs från den punkten och framåt. Den svagt bundna standardimplementeringen servar vakthunden vid denna tidpunkt i E51, och kommer att starta om om en U54 vakthund avfyrar. För mer information, se HSS-källkoden i services/lockdown/lockdown_service.c file.

Bilaga

HSS payload.bin-format

Det här avsnittet beskriver payload.bin file format och bilden som används av HSS för att starta PIC64GX SMP och AMP applikationer.
Payload.bin är en formaterad binärfil (Figur A.10) som består av ett huvud, olika deskriptortabeller och olika bitar som innehåller koden och datasektionerna för varje del av applikationens arbetsbelastning. En bit kan betraktas som ett sammanhängande minnesblock av godtycklig storlek.

Figur A.10. payload.bin-format

Rubrikdelen (visas i figur A.11) innehåller ett magiskt värde som används för att identifiera payload.bin och viss hushållsinformation, tillsammans med detaljer om bilden som är avsedd att köras på var och en av
U54 applikationskoder. Den beskriver hur man startar upp varje enskild U54-hart, och uppsättningen av startbara bilder överlag. I sin hushållsinformation har den pekare till olika tabeller med deskriptorer för att tillåta rubrikstorleken att växa.

Figur A.11. payload.bin Header

Kod och initialiserade konstantdata anses vara skrivskyddade och lagras i en skrivskyddad sektion, som pekas på av rubrikbeskrivningar.
Initialiserade datavariabler som inte är noll är läs-skrivdata men har sina initialiseringsvärden kopierade från den läsbara delen vid uppstart. Dessa lagras också i skrivskyddad sektion.

Den läsbara nyttolastdatasektionen beskrivs av en tabell med kod- och dataklumpsbeskrivningar. Varje delbeskrivning i den här tabellen innehåller en "hjärtägare" (huvudhjärten i det sammanhang den är riktad mot
at), en lastoffset (offset inom payload.bin) och en exekveringsadress (destinationsadress i PIC64GX-minnet), tillsammans med en storlek och kontrollsumma. Detta visas i figur A.12.

Figur A.12. Skrivskyddad delbeskrivning och data för nyttolast

Utöver de tidigare nämnda bitarna finns det även minnesbitar som motsvarar datavariabler som initieras till noll. Dessa lagras inte som data i payload.bin, utan är istället en speciell uppsättning nollinitierade chunk-deskriptorer, som anger en adress och längd på RAM-minnet som ska ställas in på noll under uppstart. Detta visas i figur A.13.

Figur A.13. ZI Chunks

hss-nyttolast-generator
HSS Payload Generator-verktyget skapar en formaterad nyttolastbild för Hart Software Service nollortage bootloader på PIC64GX, givet en konfiguration file och en uppsättning ELF files och/eller binärer. Konfigurationen file används för att mappa ELF-binärerna eller binära blubbarna till de individuella applikationshjärtarna (U54s).

Bild B.14. hss-nyttolast-generator Flöde

Verktyget utför grundläggande hälsokontroller av konfigurationens struktur file sig själv och på ELF-bilderna. ELF-bilder måste vara RISC-V-körbara filer.

Example Run

För att köra verktyget hss-nyttolastgenerator med sample konfiguration file och ELF files:
$ ./hss-payload-generator -c test/config.yaml output.bin
För att skriva ut diagnostik om en redan existerande bild, använd:
$ ./hss-nyttolast-generator -d output.bin

För att aktivera säker startautentisering (via bildsignering), använd -p för att ange platsen för en X.509 Privat nyckel för den elliptiska kurvan P-384 (SECP384r1):
$ ./hss-payload-generator -c test/config.yaml payload.bin -p /path/to/private.pem

För mer information, se Secure Boot Authentication-dokumentationen.

Konfig File Example

Först kan vi valfritt ange ett namn för vår bild, annars kommer en att skapas dynamiskt:
set-name: 'PIC64-HSS::TestImage'
Därefter kommer vi att definiera ingångsadresserna för varje hjärta, enligt följande:
hart-entry-points: {u54_1: ‘0x80200000’, u54_2: ‘0x80200000’, u54_3: ‘0xB0000000′, u54_4:’0x80200000’}

ELF-källbilderna kan ange en ingångspunkt, men vi vill kunna stödja sekundära ingångspunkter för harts om det behövs, t.ex.ample, om flera harts är avsedda att starta samma bild, kan de ha individuella ingångspunkter. För att stödja detta anger vi de faktiska ingångsadresserna i konfigurationen file sig.

Vi kan nu definiera några nyttolaster (källa ELF files, eller binära blobbar) som kommer att placeras i vissa områden i minnet. Nyttolastsektionen definieras med nyckelordet nyttolaster och sedan ett antal individuella nyttolastdeskriptorer. Varje nyttolast har ett namn (sökväg till dess file), en ägare-hart och eventuellt 1 till 3 sekundära harts.

Dessutom har en nyttolast ett privilegieläge där den börjar köra. Giltiga behörighetslägen är PRV_M, PRV_S och PRV_U, där dessa definieras som:

PRV_M Maskinläge
PRV_S Arbetsledare läge
PRV_U Användarläge

I följande exampde:

test/zephyr.elf antas vara en Zephyr-applikation som körs i U54_3 och förväntar sig att starta i PRV_M-privilegieläget.
test/u-boot-dtb.bin är Das U-Boot bootloader-applikationen och den körs på U54_1, U54_2 och U54_4. Den förväntar sig att starta i PRV_S privilegieläge.

Viktig:
Utgången av U-Boot skapar en ELF file, men vanligtvis står det inte före .elf-tillägget. I det här fallet används binären som skapats av CONFIG_OF_SEPARATE, som lägger till en enhetsträdblob till U-Boot-binären.

Här är exetample Payloads-konfiguration 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', ägare-hart: u54_1, sekundär-hart: u54_2, sekundär-hart: u54_4, priv-läge: prv_s}

Viktig:
Fallet har bara betydelse för file sökvägsnamn, inte nyckelord. Så till exempel, u54_1 anses vara detsamma som U54_1, och exec-addr anses vara detsamma som EXEC-ADDR. Om ett.elf- eller .bin-tillägg finns måste det inkluderas i konfigurationen file.

För en blankmetallapplikation som inte vill bry sig om OpenSBI, kommer alternativet skip-opens, om det är sant, att göra att nyttolasten på det hjärtat anropas med en enkel mret snarare
än ett OpenSBI sbi_init()-anrop. Detta innebär att hjärtat kommer att börja köra barmetallkoden oavsett OpenSBI HSM-överväganden. Observera att detta också betyder att hjärtat inte kan använda
anrop för att anropa OpenSBI-funktionalitet. Alternativet hoppa över öppnas är valfritt och är som standard falskt.

För att tillåta en kontext varm omstart av ett annat sammanhang, kan vi lägga till alternativet tillåt omstart: varm. För att tillåta en kontext kall omstart av hela systemet kan vi lägga till alternativet tillåt-omstart: kall. Som standard, utan att ange tillåt-omstart, tillåts en kontext endast att varmstarta sig själv.
Det är också möjligt att associera tilläggsdata till varje nyttolast, t.example, en DeviceTree Blob (DTB) file, genom att ange sidodata filenamn enligt följande:
test/u-boot.bin: { exec-addr: '0x80200000', ägare-hart: u54_1, sekundär-hart: u54_2, sekundär-hart: u54_3, sekundär-hart: u54_4, priv-läge: prv_s, ancilliary-data : test/pic64gx.dtb }
Dessa tilläggsdata kommer att inkluderas i nyttolasten (placeras direkt efter main file i den körbara filen
space), och dess adress kommer att skickas till OpenSBI i nästa_arg1-fältet (passas i $a1-registret till bilden vid uppstart).

För att förhindra att HSS automatiskt startar upp ett sammanhang (till exempel om vi istället vill delegera kontroll över detta till ett sammanhang med hjälp av remoteProc), använd skip-autoboot-flaggan:
test/zephyr.elf: {exec-addr: '0xB0000000', owner-hart: u54_3, priv-mode: prv_m, skip-opensbi: true, skip-autoboot: true}
Slutligen kan vi valfritt åsidosätta namnen på individuella nyttolaster genom att använda alternativet nyttolastnamn. Till exempelampde:
test/u-boot.bin: { exec-addr: '0x80200000', ägare-hart: u54_1, sekundär-hart: u54_2, sekundär-hart: u54_3, sekundär-hart: u54_4, priv-läge: prv_s, ancilliary-data : test/pic64gx.dtb, nyttolast-namn: 'u-boot' }

Observera att Yocto- och Buildroot Linux-byggarna kommer att bygga, konfigurera och köra hss-payload-
generator efter behov för att generera applikationsbilder. Dessutom, pic64gx-curiosity-kit-amp maskinmål i Yocto kommer att generera en applikationsbild med hjälp av verktyget hss-payload-generator som demonstrerar AMP, med Linux som körs på 3 harts och Zephyr körs på 1 hart.

Revisionshistorik
Revisionshistoriken beskriver de ändringar som implementerades i dokumentet. Ändringarna listas efter revidering, med början i den senaste publikationen.

Revision	Datum	Beskrivning
A	07/2024	Inledande revision

Information om mikrochip

Mikrochippet Webplats
Microchip tillhandahåller onlinesupport via vår webplats på www.microchip.com/. Detta webwebbplats används för att göra files och information lätt tillgänglig för kunder. En del av det tillgängliga innehållet inkluderar:

Produktsupport – Datablad och errata, applikationsnoteringar och sample-program, designresurser, användarhandböcker och hårdvarustöddokument, senaste programvaruversioner och arkiverad programvara

Allmän teknisk support – Vanliga frågor (FAQs), teknisk supportförfrågningar, diskussionsgrupper online, medlemslista för Microchip-designpartnerprogram
Microchips verksamhet – Produktväljare och beställningsguider, senaste pressmeddelanden från Microchip, en lista över seminarier och evenemang, listor över Microchips försäljningskontor, distributörer och fabriksrepresentanter

Produktändringsmeddelandetjänst

Microchips meddelandetjänst för produktändringar hjälper till att hålla kunderna uppdaterade om Microchips produkter. Prenumeranter kommer att få e-postmeddelanden närhelst det finns ändringar, uppdateringar, revideringar eller fel relaterade till en specificerad produktfamilj eller utvecklingsverktyg av intresse.

För att registrera dig, gå till www.microchip.com/pcn och följ registreringsanvisningarna.

Kundsupport
Användare av Microchip-produkter kan få hjälp via flera kanaler:

Distributör eller representant
Lokalt försäljningskontor
Embedded Solutions Engineer (ESE)
Teknisk support

Kunder bör kontakta sin distributör, representant eller ESE för support. Lokala försäljningskontor finns också tillgängliga för att hjälpa kunder. En lista över försäljningskontor och platser ingår i detta dokument.
Teknisk support är tillgänglig via webwebbplats på: www.microchip.com/support.

Mikrochip-enheter kodskyddsfunktion
Observera följande detaljer om kodskyddsfunktionen på Microchip-produkter:

Microchip-produkter uppfyller specifikationerna i deras specifika Microchip-datablad.
Microchip anser att dess familj av produkter är säkra när de används på avsett sätt, inom driftsspecifikationer och under normala förhållanden.

Microchip värdesätter och skyddar aggressivt dess immateriella rättigheter. Försök att bryta mot kodskyddsfunktionerna i Microchip-produkter är strängt förbjudna och kan bryta mot Digital Millennium Copyright Act.
Varken Microchip eller någon annan halvledartillverkare kan garantera säkerheten för sin kod. Kodskydd betyder inte att vi garanterar att produkten är "okrossbar". Kodskyddet utvecklas ständigt. Microchip har åtagit sig att kontinuerligt förbättra kodskyddsfunktionerna i våra produkter.

Rättsligt meddelande
Denna publikation och informationen häri får endast användas med Microchip-produkter, inklusive för att designa, testa och integrera Microchip-produkter med din applikation. Användning av denna information på något annat sätt bryter mot dessa villkor. Information om enhetsapplikationer tillhandahålls endast för din bekvämlighet och kan ersättas av uppdateringar. Det är ditt ansvar att se till att din ansökan uppfyller dina specifikationer. Kontakta ditt lokala Microchip-försäljningskontor för ytterligare support eller få ytterligare support på www.microchip.com/en-us/support/design-help/client-support-services.

DENNA INFORMATION TILLHANDAHÅLLS AV MICROCHIP "I BEFINTLIGT SKICK". MICROCHIP GÖR INGA UTSÄTTNINGAR ELLER GARANTIER AV NÅGOT SLAG, VARKEN UTTRYCKLIGA ELLER UNDERFÖRSTÅDDA, SKRIFTLIGA ELLER MUNTLIGA, LAGSTÄMNADE ELLER ANNAT SÄTT, RELATERADE TILL INFORMATIONEN INKLUSIVE MEN INTE BEGRÄNSADE TILL NÅGRA UNDERFÖRSTÅDDA GARANTIER, OCH GARANTIER, LÄMPLIGHET FÖR ETT SÄRSKILT ÄNDAMÅL ELLER GARANTIER RELATERADE TILL DESS SKICK, KVALITET ELLER PRESTANDA.

UNDER INGA OMSTÄNDIGHETER KOMMER MICROCHIP ANSVARIGT FÖR NÅGON INDIREKTA, SÄRSKILDA, STRAFFANDE, OAVSIKTLIGA ELLER FÖLJDLIG FÖRLUST, SKADA, KOSTNAD ELLER KOSTNADER AV NÅGOT SLAG SOM HELST SAMMANFATTAS TILL INFORMATIONEN ELLER DESS ANVÄNDNING, OAVSETT OAVSETT OAVSETT MÖJLIGHETEN ELLER SKADOR ÄR FÖRUTSÅBARA. I FULLSTÄNDIG UTSTRÄCKNING SOM TILLÅTS AV LAGEN KOMMER MICROCHIPS TOTALA ANSVAR PÅ ALLA ANSVAR PÅ NÅGOT SÄTT relaterade till INFORMATIONEN ELLER DESS ANVÄNDNING INTE ÖVERSKRIVA ANTALET AV AVGIFTER, OM NÅGRA, SOM DU HAR BETALAT DIREKT FÖR INFORMATIONOCHIPEN.

Användning av Microchip-enheter i livsuppehållande och/eller säkerhetsapplikationer sker helt och hållet på köparens risk, och köparen samtycker till att försvara, gottgöra och hålla Microchip ofarligt från alla skador, anspråk, stämningar eller utgifter som härrör från sådan användning. Inga licenser överförs, vare sig underförstått eller på annat sätt, under några Microchips immateriella rättigheter om inte annat anges.

Varumärken
Mikrochipets namn och logotyp, Microchip-logotypen, Adaptec, AVR, AVR-logotypen, AVR Freaks, BesTime, BitCloud, CryptoMemory, CryptoRF, dsPIC, flexPWR, HELDO, IGLOO, JukeBlox, KeeLoq, Kleer, LANCheck, LinkMD, maXStylus, maXTouch, MediaLB, megaAVR, Microsemi, Microsemi logotyp, MOST, MOST logotyp, MPLAB, OptoLyzer, PIC, picoPower, PICSTART, PIC32 logotyp, PolarFire, Prochip Designer, QTouch, SAM-BA, SenGenuity, SpyNIC, SST, SST Logo, SuperFlash, Symmetricom , SyncServer, Tachyon, TimeSource, tinyAVR, UNI/O, Vectron och XMEGA är registrerade varumärken som tillhör Microchip Technology Incorporated i USA och andra länder.

AgileSwitch, ClockWorks, The Embedded Control Solutions Company, EtherSynch, Flashtec, Hyper Speed Control, HyperLight Load, Libero, motorbänk, mTouch, Powermite 3, Precision Edge, ProASIC, ProASIC Plus, ProASIC Plus logotyp, Quiet-Wire, SmartFusion, SyncWorld , TimeCesium, TimeHub, TimePictra, TimeProvider och ZL är registrerade varumärken som tillhör Microchip Technology Incorporated i USA

Adjacent Key Suppression, AKS, Analog-for-the-Digital Age, Any Capacitor, AnyIn, AnyOut, Augmented Switching, BlueSky, BodyCom, Clockstudio, CodeGuard, CryptoAuthentication, CryptoAutomotive, CryptoCompanion, CryptoController, dsPICDEM, dsPICDEM.net, Dynamic Average Matching, Dynamic , DAM, ECAN, Espresso T1S, EtherGREEN, EyeOpen, GridTime, IdealBridge,
IGaT, seriell programmering i kretslopp, ICSP, INICnet, Intelligent Paralleling, IntelliMOS, Inter-Chip Connectivity, JitterBlocker, Knob-on-Display, MarginLink, maxCrypto, maxView, memBrain, Mindi, MiWi, MPASM, MPF, MPLAB Certified logotyp, 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, enkel karta, SimpliPHY, SmartBuffer, SmartHLS, SMART-IS, storClad, SQI, SuperSwitcher, SuperSwitcher II, Switchtec, SynchroPHY, Totalt Endurance, Trusted Time, TSHARC, Turing, USBCheck, VariSense, VectorBlox, VeriPHY, ViewSpan, WiperLock, XpressConnect och ZENA är varumärken som tillhör Microchip Technology Incorporated i USA och andra länder.

SQTP är ett servicemärke som tillhör Microchip Technology Incorporated i USA
Adaptec-logotypen, Frequency on Demand, Silicon Storage Technology och Symmcom är registrerade varumärken som tillhör Microchip Technology Inc. i andra länder.
GestIC är ett registrerat varumärke som tillhör Microchip Technology Germany II GmbH & Co. KG, ett dotterbolag till Microchip Technology Inc., i andra länder.

ISBN: 978-1-6683-4890-1

Kvalitetsledningssystem
För information om Microchips kvalitetsledningssystem, besök www.microchip.com/quality.

Världsomspännande försäljning och service

AMERIKA

ASIEN/Stillahavsområdet

EUROPA

Företags Kontor

2355 West Chandler Blvd. Chandler, AZ 85224-6199

Tel: 480-792-7200

Fax: 480-792-7277

Teknisk support: www.microchip.com/support

Web Adress: www.microchip.com

Atlanta

Duluth, GA

Tel: 678-957-9614

Fax: 678-957-1455

Austin, TX

Tel: 512-257-3370

Boston

Westborough, MA Tel: 774-760-0087

Fax: 774-760-0088

Chicago

Itasca, IL

Tel: 630-285-0071

Fax: 630-285-0075

Dallas

Addison, TX

Tel: 972-818-7423

Fax: 972-818-2924

Detroit

Novi, MI

Tel: 248-848-4000

Houston, TX

Tel: 281-894-5983

Indianapolis

Noblesville, IN Tel: 317-773-8323

Fax: 317-773-5453

Tel: 317-536-2380

Los Angeles

Mission Viejo, CA Tel: 949-462-9523

Fax: 949-462-9608

Tel: 951-273-7800

Raleigh, NC

Tel: 919-844-7510

New York, NY

Tel: 631-435-6000

San Jose, CA

Tel: 408-735-9110

Tel: 408-436-4270

Kanada – Toronto

Tel: 905-695-1980

Fax: 905-695-2078

Australien – Sydney

Tel: 61-2-9868-6733

Kina – Peking

Tel: 86-10-8569-7000

Kina – Chengdu

Tel: 86-28-8665-5511

Kina – Chongqing

Tel: 86-23-8980-9588

Kina – Dongguan

Tel: 86-769-8702-9880

Kina – Guangzhou

Tel: 86-20-8755-8029

Kina – Hangzhou

Tel: 86-571-8792-8115

Kina – Hong Kong SAR

Tel: 852-2943-5100

Kina – Nanjing

Tel: 86-25-8473-2460

Kina – Qingdao

Tel: 86-532-8502-7355

Kina – Shanghai

Tel: 86-21-3326-8000

Kina – Shenyang

Tel: 86-24-2334-2829

Kina – Shenzhen

Tel: 86-755-8864-2200

Kina – Suzhou

Tel: 86-186-6233-1526

Kina – Wuhan

Tel: 86-27-5980-5300

Kina – Xian

Tel: 86-29-8833-7252

Kina – Xiamen

Tel: 86-592-2388138

Kina – Zhuhai

Tel: 86-756-3210040

Indien – Bangalore

Tel: 91-80-3090-4444

Indien – New Delhi

Tel: 91-11-4160-8631

Indien – Pune

Tel: 91-20-4121-0141

Japan – Osaka

Tel: 81-6-6152-7160

Japan – Tokyo

Tel: 81-3-6880- 3770

Korea – Daegu

Tel: 82-53-744-4301

Korea – Seoul

Tel: 82-2-554-7200

Malaysia – Kuala Lumpur

Tel: 60-3-7651-7906

Malaysia – Penang

Tel: 60-4-227-8870

Filippinerna – Manila

Tel: 63-2-634-9065

Singapore

Tel: 65-6334-8870

Taiwan – Hsin Chu

Tel: 886-3-577-8366

Taiwan – Kaohsiung

Tel: 886-7-213-7830

Taiwan - Taipei

Tel: 886-2-2508-8600

Thailand – Bangkok

Tel: 66-2-694-1351

Vietnam – Ho Chi Minh

Tel: 84-28-5448-2100

Österrike – Wels

Tel: 43-7242-2244-39

Fax: 43-7242-2244-393

Danmark – köpenhamn

Tel: 45-4485-5910

Fax: 45-4485-2829

Finland – Esbo

Tel: 358-9-4520-820

Frankrike – Paris

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

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

Tyskland – Garcher

Tel: 49-8931-9700

Tyskland – Haan

Tel: 49-2129-3766400

Tyskland – Heilbronn

Tel: 49-7131-72400

Tyskland – Karlsruhe

Tel: 49-721-625370

Tyskland – München

Tel: 49-89-627-144-0

Fax: 49-89-627-144-44

Tyskland – Rosenheim

Tel: 49-8031-354-560

Israel – Hod Hasharon

Tel: 972-9-775-5100

Italien – Milano

Tel: 39-0331-742611

Fax: 39-0331-466781

Italien – Padova

Tel: 39-049-7625286

Nederländerna – Drunen

Tel: 31-416-690399

Fax: 31-416-690340

Norge – Trondheim

Tel: 47-72884388

Polen – Warszawa

Tel: 48-22-3325737

Rumänien – Bukarest

Tel: 40-21-407-87-50

Spanien - Madrid

Tel: 34-91-708-08-90

Fax: 34-91-708-08-91

Sverige – Göteborg

Tel: 46-31-704-60-40

Sverige – Stockholm

Tel: 46-8-5090-4654

Storbritannien – Wokingham

Tel: 44-118-921-5800

Fax: 44-118-921-5820

Dokument/resurser

MICROCHIP PIC64GX 64-bitars RISC-V fyrkärnig mikroprocessor [pdf] Användarhandbok
PIC64GX, PIC64GX 64-bitars RISC-V fyrkärnig mikroprocessor, 64-bitars RISC-V fyrkärnig mikroprocessor, RISC-V fyrkärnig mikroprocessor, fyrkärnig mikroprocessor, mikroprocessor

Referenser

Användarmanual

MICROCHIP PIC64GX 64-bitars RISC-V fyrkärnig mikroprocessor

Produktinformation

Produktanvändningsinstruktioner