Uživatelská příručka pro čtyřjádrový mikroprocesor MICROCHIP PIC64GX 64bitový RISC-V

Proces spouštění
1. Softwarové komponenty zapojené do bootování
  Proces spouštění systému zahrnuje následující softwarové součásti:
  - Hart Software Services (HSS): Nula-stagBootloader, systémový monitor a poskytovatel runtime služeb pro aplikace.
2. Boot Flow
  Posloupnost spouštění systému je následující:
  1. Inicializace Hart Software Services (HSS)
  2. Spuštění bootloaderu
  3. Spuštění aplikace
Hlídací psi
1. Hlídací pes PIC64GX
  PIC64GX je vybaven funkcí hlídacího psa pro monitorování provozu systému a spouštění akcí v případě selhání systému.
Režim uzamčení
Režim uzamčení je určen pro zákazníky, kteří po spuštění vyžadují úplnou kontrolu nad akcemi systému. Omezuje funkce monitoru systému E51.

FAQ

Otázka: Jaký je účel služeb Hart Software Services (HSS)?
Odpověď: HSS slouží jako nulatagZavaděč, monitor systému a poskytovatel runtime služeb pro aplikace během procesu spouštění.
Otázka: Jak funguje funkce watchdog PIC64GX?
A: Watchdog PIC64GX monitoruje provoz systému a může provádět předdefinované akce v případě selhání systému, aby byla zajištěna spolehlivost systému.

Zavedení

Tento dokument vysvětluje, jak Microchip PIC64GX spouští pracovní zátěž aplikací, a popisuje proces spouštění systému, který funguje stejně pro SMP a AMP pracovní zátěže. Kromě toho popisuje, jak funguje restart pro SMP a AMP pracovní zátěže, hlídací stanice na PIC64GX a speciální režim uzamčení pro systémy, kde zákazníci požadují úplnou kontrolu, aby omezili akce systémového monitoru E51 po spuštění systému.

Proces spouštění

Podívejme se na různé softwarové komponenty, které se podílejí na spouštění systému, a poté se podrobněji podíváme na sekvenci samotného zavádění systému.

Softwarové komponenty zapojené do bootování
Na procesu spouštění systému se podílejí následující součásti:

Obrázek 1.1. Spouštěcí komponenty

Hart Software Services (HSS)
Hart Software Services (HSS) je nulatagBootloader, systémový monitor a poskytovatel runtime služeb pro aplikace. HSS podporuje včasné nastavení systému, školení DDR a inicializaci/konfiguraci hardwaru. Většinou běží na E51s, s malým množstvím funkcí na úrovni stroje běží na každém U54. Zavádí jeden nebo více kontextů načtením „užitné zátěže“ aplikace ze spouštěcího média a poskytuje jádra operačního systému Platform Runtime Services/Supervisor Execution Environment (SEE). Podporuje bezpečné spouštění a je důležitou součástí při zajišťování rozdělení/oddělení hardwaru AMP kontexty.

Das U-Boot (U-Boot)
Das U-Boot (U-Boot) je univerzální skriptovatelný zavaděč s otevřeným zdrojovým kódem. Podporuje jednoduché CLI, které dokáže načíst spouštěcí obraz z různých zdrojů (včetně SD karty a sítě). U-Boot načte Linux. V případě potřeby může poskytnout prostředí UEFI. Po zavedení Linuxu je obecně hotový a nefunkční – jinými slovy, nezůstává po startu rezidentní.
Linuxové jádro
Linuxové jádro je celosvětově nejpopulárnějším jádrem operačního systému. V kombinaci s uživatelskou zemí aplikací tvoří to, čemu se běžně říká operační systém Linux. Operační systém Linux poskytuje bohaté POSIX API a vývojářské prostředí, napřample, jazyky a nástroje jako Python, Perl, Tcl, Rust, C/C++ a Tcl; knihovny jako OpenSSL, OpenCV, OpenMP, OPC/UA a OpenAMP (RPmsg a RemoteProc).
Yocto a Buildroot jsou tvůrci linuxových systémů, to znamená, že je lze použít ke generování přizpůsobených linuxových systémů na míru. Yocto vydává linuxovou distribuci s bohatým
sada aplikací, nástrojů a knihoven a volitelná správa balíčků. Buildroot poskytuje minimální kořen filesystém a může cílit na systémy, které nevyžadují trvalé úložiště, ale běží výhradně z paměti RAM (pomocí podpory iniciál Linuxu, např.ample).

Vánek
Zephyr je malý open-source operační systém reálného času (RTOS). Poskytuje rámec Real-Time Low-Overhead Framework s komunikačními kanály RPMsg-lite do Linuxu. Zahrnuje jádro, knihovny, ovladače zařízení, zásobníky protokolů, filesystémy, mechanismy pro aktualizace firmwaru a tak dále a je skvělý pro zákazníky, kteří chtějí mít na PIC64GX více holé prostředí.

Boot Flow
PIC64GX obsahuje RISC-V coreplex s 64bitovým monitorem systému E51 a 4 64bitovými aplikačními porty U54. V terminologii RISC-V je hart kontext provádění RISC-V, který obsahuje úplnou sadu registrů a který provádí svůj kód nezávisle. Můžete si to představit jako hardwarové vlákno nebo jeden procesor. Skupina jelenů v rámci jednoho jádra se často nazývá komplex. Toto téma popisuje kroky k inicializaci coreplexu PIC64GX, včetně systémových monitorů srdce E51 a aplikačních hartů U54.

Zapněte coreplex PIC64GX.
Při zapnutí jsou všechny harty v coreplexu RISC-V uvolněny z resetu bezpečnostním ovladačem.
Spusťte HSS kód z flash paměti eNVM na čipu.
Zpočátku každé srdce spustí kód HSS z flash paměti eNVM na čipu. Tento kód způsobí, že se všechny aplikační harty U54 roztočí, čekají na pokyny, a umožní monitoru E51 spustit kód pro inicializaci a spuštění systému.

Dekomprimujte HSS kód z eNVM do paměti L2-Scratch.
V závislosti na konfiguraci doby sestavení je HSS obvykle větší než kapacita samotné flash paměti eNVM, takže první věc, kterou HSS kód běžící na E51 dělá, je dekomprimovat se z eNVM do paměti L2-Scratch, jak je znázorněno na obrázku 1.2 a Obrázek 1.3.
Obrázek 1.2. HSS Dekomprimuje z eNVM na L2 Scratch
Obrázek 1.3. Mapa paměti HSS během dekomprese
Přeskočte z eNVM na L2-Scratch do spustitelného souboru, jak je znázorněno na následujícím obrázku.
Obrázek 1.4. HSS skočí z eNVM do Code Now v L2Scratch po dekompresi
Spustitelný soubor se skládá ze tří komponent:
- Hardwarová abstraktní vrstva (HAL), nízkoúrovňový kód a holé kovové ovladače
- Lokální HSS vidlice RISC-V OpenSBI (mírně upravená z upstream na PIC64GX pro AMP účely)
- Runtime služby HSS (stavové stroje běží v super smyčce)
Inicializujte hardwarové a datové struktury používané OpenSBI.
Za tuto inicializaci je zodpovědná služba HSS „Startup“.

Načtěte obrázek pracovní zátěže aplikace (payload.bin) z externího úložiště. To je znázorněno na obrázku 1.5 a obrázku 1.6
Důležité: V případě PIC64GX Curiosity Kit to bude z SD karty.
Obrázek 1.5. Načítání obrazu pracovní zátěže payload.bin z externího úložiště
Obrázek 1.6. Mapa paměti HSS po načtení payload.bin
Zkopírujte různé sekce z payload.bin do jejich cílů doby provádění. Payload.bin je formátovaný obrázek, který sdružuje různé obrázky aplikací pro SMP resp AMP pracovní zátěže. Zahrnuje kódové, datové a deskriptorové tabulky, které umožňují HSS vhodně umístit kódové a datové sekce tam, kde jsou potřebné pro spouštění různých aplikačních úloh.
Obrázek 1.7. payload.bin je zkopírován do cílových adres

Instruujte příslušné U54, aby skočily na jejich adresy zahájení provádění. Tyto informace o počáteční adrese jsou obsaženy v souboru payload.bin.
Spusťte aplikaci U54 harts a jakékoli sekundytage zavaděče. Napřample, U-Boot přináší Linux.

Restartujte

S konceptem bootování systému souvisí nutnost restartu. Když přemýšlíte o pracovní zátěži aplikace PIC64GX, restartování musí vzít v úvahu jak symetrický multiprocesing (SMP), tak asymetrický multiprocessing (AMP) scénáře:

V případě systému SMP může restart bezpečně restartovat celý systém, protože v jiném kontextu není třeba uvažovat o žádné další zátěži.

V případě AMP systému, může být pracovní zátěži povoleno, aby se sama restartovala (a nezasahovala do žádného jiného kontextu), nebo může mít oprávnění provést úplný restart systému.

Restartujte a AMP
Chcete-li povolit SMP a AMP scénáře restartu podporuje HSS koncepty oprávnění pro teplý a studený restart, které lze přiřadit kontextu. Kontext s oprávněním pro teplý restart se může restartovat pouze sám a kontext s oprávněním pro studený restart může provést úplný restart systému. Napřample, zvažte následující sadu reprezentativních scénářů.

Jedno kontextové zatížení SMP, které může vyžadovat úplné restartování systému
V tomto scénáři je kontextu povoleno oprávnění pro studený restart.
Dva kontexty AMP pracovní zátěž, kde kontextu A je povoleno požadovat úplné restartování systému (ovlivňuje všechny kontexty) a kontextu B je povoleno restartovat se pouze sám
V tomto scénáři je kontextu A povoleno oprávnění studeného restartu a kontextu B je povoleno oprávnění teplého restartu.
Dva kontexty AMP pracovní zátěž, kde se kontexty A a B mohou restartovat pouze samy (a neovlivňují ostatní kontext)
V tomto scénáři mají oba kontexty povolena pouze oprávnění teplého restartu.
Dva kontexty AMP pracovní zátěž, kde kontexty A i B mohou vyžadovat úplné restartování systému
V tomto scénáři mají oba kontexty povolena oprávnění pro studený restart.
Navíc je možné, aby HSS v době sestavení vždy povolila oprávnění studeného restartu a nikdy nepovolila oprávnění studeného restartu.

Příslušné možnosti HSS Kconfig
Kconfig je konfigurační systém sestavení softwaru. Běžně se používá k výběru možností doby sestavení a k povolení nebo zakázání funkcí. Pochází z linuxového jádra, ale nyní našel využití v jiných projektech mimo linuxové jádro, včetně U-Boot, Zephyr a PIC64GX HSS.

HSS obsahuje dvě možnosti Kconfig, které řídí funkci restartu z pohledu HSS:

CONFIG_ALLOW_COLD REBOOT
Pokud je toto povoleno, globálně to kontextu umožňuje vydat volání studeného restartu. Pokud je zakázáno, budou povoleny pouze teplé restarty. Kromě povolení této možnosti musí být kontextu uděleno oprávnění k provedení studeného restartu prostřednictvím generátoru užitečného zatížení YAML file nebo následující možnost Kconfig.
CONFIG_ALLOW_COLD REBOOT_ALWAYS
- Je-li tato funkce povolena, umožňuje globálně všem kontextům vydat ECAA pro studený restart bez ohledu na oprávnění příznaku payload.bin.
- Kromě toho může samotný payload.bin obsahovat příznak pro každý kontext, který označuje, že konkrétní kontext je oprávněn provést studené restarty:
  - Chcete-li povolit kontextový teplý restart v jiném kontextu, můžeme přidat možnost allow-reboot: warm v popisu YAML file slouží k vytvoření payload.bin
  - Abychom umožnili kontextový studený restart celého systému, můžeme přidat volbu allow-reboot: cold. Ve výchozím nastavení, bez zadání allow-reboot, je kontext povolen pouze samotný teplý restart Bez ohledu na nastavení tohoto příznaku, pokud CONFIG_ALLOW_COLDREBOOT není povoleno v HSS, HSS přepracuje všechny požadavky na studený restart na teplé restarty (podle kontextu). .

Restartujte podrobně
Tato část podrobně popisuje, jak restartování funguje – počínaje vrstvou OpenSBI (nejnižší vrstva M-mode) a poté diskutující o tom, jak se tato funkce vrstvy OpenSBI spouští z aplikace RTOS nebo bohatého operačního systému, jako je Linux.

OpenSBI Reboot ecall

Specifikace RISC-V Supervisor Binary Interface (SBI) popisuje standardizovanou hardwarovou abstraktní vrstvu pro inicializaci platformy a služby za běhu firmwaru. Hlavním účelem SBI je umožnit přenositelnost a kompatibilitu napříč různými implementacemi RISC-V.
OpenSBI (Open Source Supervisor Binary Interface) je open-source projekt, který poskytuje referenční implementaci specifikace SBI. OpenSBI také poskytuje runtime služby, včetně obsluhy přerušení, správy časovače a konzolových I/O, které mohou využívat vyšší softwarové vrstvy.
OpenSBI je součástí HSS a běží na úrovni Machine Mode. Když operační systém nebo aplikace způsobí past, bude předána OpenSBI, aby ji zpracovala. OpenSBI zpřístupňuje určitou funkcionalitu typu systémového volání horním vrstvám softwaru prostřednictvím zvláštního mechanismu pasti zvaného ecal.

Obnovení systému (EID 0x53525354) poskytuje komplexní funkci systémového volání, která umožňuje softwaru vyšší vrstvy požadovat restart nebo vypnutí na úrovni systému. Jakmile je toto volání vyvoláno U54, je zachyceno softwarem HSS běžícím na tomto U54 v režimu Stroj a na E51 je odeslán odpovídající požadavek na restart, aby se restartoval buď kontext, nebo celý systém, v závislosti na oprávněních zařízení. kontext.

Další informace naleznete na Specifikace binárního rozhraní RISC-V Supervisor zejména Rozšíření pro obnovení systému (EID #0x53525354 „SRST“).

Restartování Linuxu

Jako konkrétní exampV Linuxu se příkaz shutdown používá k zastavení nebo restartování systému. Příkaz má obvykle mnoho aliasů, jmenovitě zastavit, vypnout a restartovat. Tyto aliasy určují, zda se má stroj při vypnutí zastavit, vypnout při vypnutí nebo restartovat při vypnutí.

Tyto příkazy v uživatelském prostoru vydávají systémové volání restartu do Linuxu, které je zachyceno jádrem a propojeno s voláním SBI.
Existují různé úrovně restartu – REBOOT_WARM, REBOOT_COLD, REBOOT_HARD – tyto lze předat jako argumenty příkazového řádku jádru (např.ample, reboot=w[arm] pro REBOOT_WARM). Další informace o zdrojovém kódu linuxového jádra viz Documentation/admin-guide/kernel-paramters.txt.
Alternativně, pokud je povoleno /sys/kernel/reboot, lze číst níže uvedené obslužné rutiny, abyste získali aktuální konfiguraci restartu systému, a zapsat ji, abyste ji změnili. Další informace o zdrojovém kódu linuxového jádra viz Dokumentace/ABI/testing/sysfs-kernel-reboot.

Hlídací psi

Dalším konceptem souvisejícím se zaváděním systému a restartováním systému je obnovení systému po spuštění hlídacího časovače. Časovače Watchdog jsou široce používány ve vestavěných systémech k automatické obnově z přechodných hardwarových poruch a k zabránění chybnému nebo zlovolnému softwaru narušit provoz systému.
PIC64GX obsahuje podporu hardwarového hlídacího psa pro monitorování jednotlivých hartů, když je systém spuštěn. Hlídací psi zajišťují, že harty mohou být restartovány, pokud nereagují kvůli neodstranitelným softwarovým chybám.
PIC64GX obsahuje pět instancí hardwarových bloků hlídacího časovače používaných k detekci zablokování systému – jednu pro každý z hartů. Pro usnadnění smíšeného asymetrického vícenásobného zpracování (AMP) pracovní zátěže, HSS podporuje sledování a reakci na střelbu hlídacích psů.

Hlídací pes PIC64GX

HSS je odpovědný za spouštění aplikací harts při zapnutí a za jejich opětovné spuštění (individuálně nebo společně) kdykolitage, pokud by to bylo potřeba nebo žádoucí. V důsledku toho je reakce na hlídací události na PIC64GX řešena HSS.
Monitor „virtuálního hlídače“ je implementován jako služba stavového stroje HSS a jeho odpovědností je sledovat stav každého z jednotlivých hardwarových monitorů hlídacího psa U54. Když se jeden z těchto hlídacích psů U54 vypne, HSS to detekuje a podle potřeby restartuje U54. Pokud je U54 součástí kontextu SMP, celý kontext je považován za restart, protože kontext má právo teplého restartu. Celý systém bude restartován, pokud má kontext oprávnění pro studený restart.

Příslušné možnosti Kconfig

Podpora Watchdog je standardně zahrnuta ve vydaných sestaveních HSS. Pokud si přejete vytvořit vlastní HSS, tato část popíše konfigurační mechanismus, který zajistí, že je povolena podpora Watchdog.

HSS se konfiguruje pomocí konfiguračního systému Kconfig. Soubor .config nejvyšší úrovně file je potřeba k výběru toho, jaké služby se budou kompilovat do nebo z sestavení HSS.
Nejprve je třeba povolit možnost CONFIG_SERVICE_WDOG nejvyšší úrovně („Podpora virtuálního hlídacího psa“ prostřednictvím make config).

To pak odhalí následující dílčí možnosti, které jsou závislé na podpoře Watchdog:

CONFIG_SERVICE_WD OG_DEBUG
Umožňuje podporu informačních/ladících zpráv ze služby virtuálního hlídacího psa.
CONFIG_SERVICE_WD OG_DEBUG_TIMEOUT_SECS
Určuje periodicitu (v sekundách), po kterou budou HSS vydávat ladicí zprávy Watchdog.
CONFIG_SERVICE_WD OG_ENABLE_E51
Umožňuje hlídacího psa pro monitory srdce E51 kromě U54, čímž chrání provoz samotného HSS.

Když je povolen hlídací obvod E51, HSS bude pravidelně zapisovat do hlídacího psa, aby jej obnovil a zabránil jeho spuštění. Pokud se z nějakého důvodu srdce E51 zablokuje nebo zhroutí a je povolen hlídací pes E51, vždy se resetuje celý systém.

Provoz hlídacího psa
Hardware hlídacího psa implementuje čítače dolů. Okno se zákazem obnovení lze vytvořit konfigurací maximální hodnoty hlídače, do které je povoleno obnovení (MVRP).

Když je aktuální hodnota hlídacího časovače větší než hodnota MVRP, obnovování hlídacího obvodu je zakázáno. Při pokusu o obnovení hlídacího časovače v zakázaném okně dojde k přerušení časového limitu.

Obnovení hlídacího obvodu mezi hodnotou MVRP a spouštěcí hodnotou (TRIG) úspěšně obnoví počítadlo a zabrání spuštění hlídacího zařízení.
Jakmile hodnota časovače hlídacího obvodu klesne pod hodnotu TRIG, hlídací obvod se spustí.

Státní stroj hlídacího psa

Stavový automat hlídacího psa je velmi přímočarý – spustí se konfigurací hlídacího obvodu pro E51, je-li povolen, a poté přejde přes klidový stav do monitorování. Pokaždé kolem supersmyčky je vyvolán tento stav monitorování, který kontroluje stav každého z hlídacích psů U54.

Stavový stroj watchdog interaguje se stavovým strojem zavádění a restartuje zařízení hart (a jakékoli další zařízení hart, které jsou v jeho zaváděcí sadě), pokud zjistí, že zařízení hart nestihlo obnovit svůj hlídací pes včas.

Režim uzamčení

Normálně (zejména s AMP aplikací), očekává se, že HSS zůstane rezidentní v M-režimu na U54, aby bylo možné restartovat podle kontextu (tj. restartovat pouze jeden kontext bez restartu celého čipu) a umožnit HSS monitorovat stav ( ECC, bity stavu zámku, chyby sběrnice, chyby SBI, narušení PMP atd.).

Aby bylo možné poskytnout možnosti restartu naAMP kontextu (bez nutnosti restartování celého systému), má E51 normálně privilegovaný přístup do paměti k celému paměťovému prostoru systému. Mohou však nastat situace, kdy to není žádoucí a zákazník může preferovat omezení toho, co firmware E51 HSS dělá, jakmile systém úspěšně nabootuje. V tomto případě je možné po zavedení U54 Application Harts uvést HSS do režimu uzamčení.

To lze povolit pomocí možnosti HSS Kconfig CONFIG_SERVICE_LOCKDOWN.
Služba uzamčení má umožnit omezení aktivit HSS poté, co nabootuje aplikaci Harts U54.

Obrázek 4.2. Režim uzamčení HSS

Jakmile se režim Lockdown spustí, zastaví provoz všech ostatních strojů v servisním stavu HSS. Volá dvě slabě vázané funkce:

e51_pmp_lockdown() a
e51_lockdown()

Tyto funkce jsou určeny k tomu, aby byly přepsány kódem specifickým pro desku. První je konfigurovatelná spouštěcí funkce, která umožňuje BSP přizpůsobit uzamčení E51 z aplikačních dat v tomto bodě. Slabě vázaná výchozí implementace této funkce je prázdná. Druhým je funkce, která se spouští od tohoto bodu dopředu. Slabě vázaná výchozí implementace obsluhuje hlídacího psa v tomto bodě E51 a restartuje se, pokud se spustí hlídací pes U54. Další informace naleznete ve zdrojovém kódu HSS na webu services/lockdown/lockdown_service.c file.

Dodatek

Formát užitečného zatížení HSS.bin

Tato část popisuje soubor payload.bin file formát a obrázek používaný HSS k bootování PIC64GX SMP a AMP aplikací.
Payload.bin je formátovaný binární soubor (obrázek A.10) sestávající z hlavičky, různých tabulek deskriptorů a různých částí, které obsahují části kódu a dat každé části pracovní zátěže aplikace. Blok lze považovat za souvislý blok paměti libovolné velikosti.

Obrázek A.10. formát payload.bin

Část záhlaví (zobrazená na obrázku A.11) obsahuje magickou hodnotu používanou k identifikaci payload.bin a některých informací o údržbě, spolu s podrobnostmi o obrázku, který se má spustit na každém z
Aplikační kódy U54. Popisuje, jak zavést každý jednotlivý hart U54 a sadu zaváděcích obrazů celkově. Ve svých provozních informacích má ukazatele na různé tabulky deskriptorů, které umožňují zvětšit velikost záhlaví.

Obrázek A.11. hlavička payload.bin

Kód a inicializovaná konstantní data jsou považována za pouze pro čtení a jsou uložena v sekci pouze pro čtení, na kterou odkazují deskriptory záhlaví.
Nenulové inicializované datové proměnné jsou data pro čtení i zápis, ale jejich inicializační hodnoty jsou při spuštění zkopírovány z bloku pouze pro čtení. Ty jsou také uloženy v sekci pouze pro čtení.

Sekce dat užitečného zatížení pouze pro čtení je popsána tabulkou deskriptorů kódu a datových bloků. Každý deskriptor bloku v této tabulce obsahuje „vlastníka hart“ (hlavní hart v kontextu, na který je zaměřen
at), offset zatížení (offset v rámci payload.bin) a prováděcí adresa (cílová adresa v paměti PIC64GX) spolu s velikostí a kontrolním součtem. To je znázorněno na obrázku A.12.

Obrázek A.12. Deskriptor bloku pouze pro čtení a data bloku datového zatížení

Kromě výše zmíněných částí existují také části paměti odpovídající datovým proměnným, které jsou inicializovány na nulu. Ty nejsou uloženy jako data v payload.bin, ale místo toho jsou speciální sadou nulou inicializovaných deskriptorů bloků, které určují adresu a délku paměti RAM, která se má během spouštění nastavit na nulu. To je znázorněno na obrázku A.13.

Obrázek A.13. ZI kusy

hss-payload-generator
Nástroj HSS Payload Generator vytvoří naformátovaný obraz užitečného zatížení pro nulové body služby Hart Software Servicetage bootloader na PIC64GX s konfigurací file a soubor ELF files a/nebo binární soubory. Konfigurace file se používá k mapování binárních souborů ELF nebo binárních objektů BLOB na jednotlivé aplikace harts (U54s).

Obrázek B.14. hss-payload-generator Flow

Nástroj provádí základní kontroly zdravého rozumu ve struktuře konfigurace file sám a na obrázcích ELF. Obrazy ELF musí být spustitelné soubory RISC-V.

Example Run

Chcete-li spustit nástroj hss-payload-generator pomocí sampkonfigurace souboru file a ELF files:
$ ./hss-payload-generator -c test/config.yaml output.bin
Chcete-li vytisknout diagnostiku již existujícího obrazu, použijte:
$ ./hss-payload-generator -d output.bin

Chcete-li povolit bezpečné ověřování spouštění (prostřednictvím podepisování obrazu), použijte -p k zadání umístění privátního klíče X.509 pro Elliptic Curve P-384 (SECP384r1):
$ ./hss-payload-generator -c test/config.yaml payload.bin -p /path/to/private.pem

Další informace naleznete v dokumentaci Secure Boot Authentication.

Konfigurace File Example

Nejprve můžeme volitelně nastavit název pro náš obrázek, jinak bude vytvořen dynamicky:
set-name: 'PIC64-HSS::TestImage'
Dále definujeme adresy vstupních bodů pro každé srdce následovně:
hart-entry-points: {u54_1: ‘0x80200000’, u54_2: ‘0x80200000’, u54_3: ‘0xB0000000′, u54_4:’0x80200000’}

Zdrojové obrázky ELF mohou specifikovat vstupní bod, ale v případě potřeby chceme být schopni podporovat sekundární vstupní body pro jeleny, např.ampPokud je pro spuštění stejného obrazu určeno více hartů, mohou mít jednotlivé vstupní body. Abychom to podpořili, specifikujeme v konfiguraci skutečné adresy vstupních bodů file sám.

Nyní můžeme definovat některé užitečné zatížení (zdroj ELF files nebo binární blob), které budou umístěny v určitých oblastech v paměti. Sekce užitečného zatížení je definována klíčovým slovem užitečné zatížení a poté řadou jednotlivých deskriptorů užitečného zatížení. Každý náklad má jméno (cesta k němu file), vlastník-hart a volitelně 1 až 3 sekundární jeleni.

Kromě toho má datová část režim oprávnění, ve kterém se spustí. Platné režimy oprávnění jsou PRV_M, PRV_S a PRV_U, kde jsou definovány jako:

PRV_M Strojový režim
Režim dohledu PRV_S
PRV_U Uživatelský režim

V následujícím exampten:

test/zephyr.elf se považuje za aplikaci Zephyr, která běží v U54_3 a očekává se, že bude spuštěna v režimu oprávnění PRV_M.
test/u-boot-dtb.bin je zavaděč Das U-Boot a běží na U54_1, U54_2 a U54_4. Očekává spuštění v režimu oprávnění PRV_S.

Důležité:
Výstup U-Bootu vytvoří ELF file, ale obvykle nepředstavuje příponu .elf. V tomto případě se použije binární soubor vytvořený pomocí CONFIG_OF_SEPARATE, který k binárnímu souboru U-Boot připojí blob stromu zařízení.

Tady je example Konfigurace užitečného zatížení file:

test/zephyr.elf:
{exec-addr: '0xB0000000', vlastník-hart: u54_3, priv-mode: prv_m, skip-opensbi: true}
test/u-boot-dtb.bin:
{exec-addr: '0x80200000', vlastník-hart: u54_1, sekundární-hart: u54_2, sekundární-hart: u54_4,priv-mode: prv_s}

Důležité:
Případ záleží pouze na file názvy cest, nikoli klíčová slova. Takže například u54_1 je považováno za stejné jako U54_1 a exec-addr je považováno za stejné jako EXEC-ADDR. Pokud je přítomna přípona .elf nebo .bin, je třeba ji zahrnout do konfigurace file.

Pro aplikaci z holého kovu, která se nechce zabývat OpenSBI, možnost skip-opens, je-li pravdivá, způsobí, že užitečné zatížení tohoto srdce bude vyvoláno spíše pomocí jednoduchého mret
než volání OpenSBI sbi_init(). To znamená, že srdce spustí kód holého kovu bez ohledu na jakékoli úvahy OpenSBI HSM. Všimněte si, že to také znamená, že srdce nemůže používat
volání vyvolá funkci OpenSBI. Možnost skip-opens je volitelná a výchozí je false.

Chcete-li povolit kontextový teplý restart jiného kontextu, můžeme přidat možnost povolit restart: teplý. Abychom umožnili kontextový studený restart celého systému, můžeme přidat volbu allow-reboot: cold. Ve výchozím nastavení, bez zadání allow-reboot, je kontextu povoleno pouze teplé restartování.
Ke každému užitečnému zatížení je také možné přiřadit doplňková data, napřample, DeviceTree Blob (DTB) file, uvedením pomocných údajů filejméno takto:
test/u-boot.bin: { exec-addr: '0x80200000', vlastník-hart: u54_1, sekundární-hart: u54_2, sekundární-hart: u54_3, sekundární-hart: u54_4, priv-mode: prv_s, pomocná-data : test/pic64gx.dtb }
Tato pomocná data budou zahrnuta do užitečného zatížení (umístěna hned za hlavní file ve spustitelném souboru
space) a jeho adresa bude předána OpenSBI v poli next_arg1 (předáno v registru $a1 do obrazu při bootování).

Chcete-li zabránit HSS v automatickém spouštění kontextu (například pokud místo toho chceme delegovat řízení kontextu pomocí remoteProc), použijte příznak skip-autoboot:
test/zephyr.elf: {exec-addr: '0xB0000000', vlastník-hart: u54_3, priv-mode: prv_m, skip-opensbi: true, skip-autoboot: true}
Nakonec můžeme volitelně přepsat názvy jednotlivých datových částí pomocí volby payload-name. Napřampten:
test/u-boot.bin: { exec-addr: '0x80200000', vlastník-hart: u54_1, sekundární-hart: u54_2, sekundární-hart: u54_3, sekundární-hart: u54_4, priv-mode: prv_s, pomocná-data : test/pic64gx.dtb, payload-name: 'u-boot' }

Všimněte si, že tvůrci Yocto a Buildroot Linux vytvoří, nakonfigurují a spustí hss-payload-
generátor podle potřeby pro generování obrazů aplikace. Navíc pic64gx-curiosity-kit-amp strojový cíl v Yocto vygeneruje obraz aplikace pomocí nástroje hss-payload-generator, který demonstruje AMP, přičemž Linux běží na 3 hartech a Zephyr běží na 1 hartu.

Historie revizí
Historie revizí popisuje změny, které byly v dokumentu implementovány. Změny jsou uvedeny podle revizí, počínaje nejnovější publikací.

Revize	Datum	Popis
A	07/2024	Počáteční revize

Informace o mikročipu

Mikročip Webmísto
Microchip poskytuje online podporu prostřednictvím našeho webmísto na www.microchip.com/. Tento webmísto se používá k výrobě files a informace snadno dostupné zákazníkům. Některý dostupný obsah zahrnuje:

Podpora produktu – Technické listy a errata, aplikační poznámky a sampprogramy, zdroje návrhů, uživatelské příručky a dokumenty podpory hardwaru, nejnovější verze softwaru a archivovaný software

Obecná technická podpora – Často kladené otázky (FAQ), požadavky na technickou podporu, online diskusní skupiny, seznam členů programu Microchip design partnera
Podnikání mikročipu – Průvodce pro výběr produktů a objednávky, nejnovější tiskové zprávy Microchip, seznam seminářů a akcí, seznamy prodejních kanceláří Microchip, distributorů a zástupců továren

Služba upozornění na změnu produktu

Služba oznamování změn produktů společnosti Microchip pomáhá zákazníkům udržovat aktuální informace o produktech společnosti Microchip. Předplatitelé obdrží e-mailové upozornění, kdykoli dojde ke změnám, aktualizacím, revizím nebo chybám souvisejícím s konkrétní produktovou řadou nebo vývojovým nástrojem, který je zajímá.

Chcete-li se zaregistrovat, přejděte na www.microchip.com/pcn a postupujte podle pokynů k registraci.

Zákaznická podpora
Uživatelé produktů Microchip mohou získat pomoc prostřednictvím několika kanálů:

Distributor nebo zástupce
Místní prodejní kancelář
Embedded Solutions Engineer (ESE)
Technická podpora

Zákazníci by měli kontaktovat svého distributora, zástupce nebo ESE se žádostí o podporu. Zákazníkům jsou k dispozici také místní prodejní kanceláře. Seznam prodejních kanceláří a míst je součástí tohoto dokumentu.
Technická podpora je k dispozici prostřednictvím webmísto na: www.microchip.com/support.

Funkce ochrany kódem zařízení Microchip
Všimněte si následujících podrobností o funkci ochrany kódu na produktech Microchip:

Produkty Microchip splňují specifikace obsažené v jejich konkrétním datovém listu Microchip.
Společnost Microchip věří, že její řada produktů je bezpečná, pokud se používají zamýšleným způsobem, v rámci provozních specifikací a za normálních podmínek.

Microchip si cení a agresivně chrání svá práva duševního vlastnictví. Pokusy o porušení funkcí ochrany kódu produktů Microchip jsou přísně zakázány a mohou porušovat zákon Digital Millennium Copyright Act.
Společnost Microchip ani žádný jiný výrobce polovodičů nemůže zaručit bezpečnost svého kódu. Ochrana kódem neznamená, že garantujeme, že produkt je „nerozbitný“. Ochrana kódu se neustále vyvíjí. Společnost Microchip se zavázala neustále zlepšovat funkce ochrany kódu našich produktů.

Právní upozornění
Tato publikace a zde uvedené informace mohou být použity pouze s produkty Microchip, včetně návrhu, testování a integrace produktů Microchip s vaší aplikací. Použití těchto informací jakýmkoli jiným způsobem porušuje tyto podmínky. Informace týkající se aplikací zařízení jsou poskytovány pouze pro vaše pohodlí a mohou být nahrazeny aktualizacemi. Je vaší odpovědností zajistit, aby vaše aplikace splňovala vaše specifikace. Obraťte se na místní obchodní zastoupení Microchip pro další podporu nebo získejte další podporu na www.microchip.com/en-us/support/design-help/client-support-services.

TYTO INFORMACE POSKYTUJE SPOLEČNOST MICROCHIP „TAK JAK JSOU“. MICROCHIP NEPOSKYTUJE ŽÁDNÁ PROHLÁŠENÍ ANI ZÁRUKY JAKÉHOKOLI DRUHU, AŤ UŽ VÝSLOVNÉ ČI PŘEDPOKLÁDANÉ, PÍSEMNÉ NEBO ÚSTNÍ, ZÁKONNÉ NEBO JINÉ, TÝKAJÍCÍ SE INFORMACÍ VČETNĚ, ALE NE OMEZENÍ, JAKÝCHKOLI PŘEDPOKLÁDANÝCH ZÁRUK, ZÁRUK NEPORUŠENÍ TNCH OBCHODU KONKRÉTNÍ ÚČEL NEBO ZÁRUKY VZTAHUJÍCÍ SE K JEHO STAVU, KVALITĚ NEBO VÝKONU.

V ŽÁDNÉM PŘÍPADĚ NEBUDE MICROCHIP ODPOVĚDNÁ ZA ŽÁDNÉ NEPŘÍMÉ, ZVLÁŠTNÍ, TRESTNÉ, NÁHODNÉ NEBO NÁSLEDNÉ ZTRÁTY, ŠKODY, NÁKLADY NEBO NÁKLADY JAKÉHOKOLI DRUHU, JAKKOLI SOUVISEJÍCÍ S INFORMACÍ NEBO JEJICH POUŽITÍM, JAKKOLI BY BYLO UVEDENO, JAK BY BYLO ZPŮSOBeno, MOŽNOST NEBO ŠKODY JSOU PŘEDVÍDAJÍCÍ. CELKOVÁ ODPOVĚDNOST SPOLEČNOSTI MICROCHIP ZA VŠECHNY NÁROKY SOUVISEJÍCÍ S INFORMACÍ NEBO JEJICH POUŽITÍM NEPŘEKROČÍ V NEJVYŠŠÍM ROZSAHU POVOLENÉM ZÁKONEM, KTERÉ JSTE ZA INFORMACE ZAPLATILI PŘÍMO SPOLEČNOSTI MICROCHIP.

Použití zařízení Microchip v aplikacích pro podporu života a/nebo v bezpečnostních aplikacích je zcela na riziko kupujícího a kupující souhlasí s tím, že bude Microchip bránit, odškodnit a chránit před všemi škodami, nároky, žalobami nebo výdaji vyplývajícími z takového použití. Žádné licence nejsou poskytovány, implicitně ani jinak, v rámci jakýchkoli práv duševního vlastnictví společnosti Microchip, pokud není uvedeno jinak.

ochranné známky
Název a logo Microchip, logo Microchip, Adaptec, AVR, logo AVR, AVR Freaks, BesTime, BitCloud, CryptoMemory, CryptoRF, dsPIC, flexPWR, HELDO, IGLOO, JukeBlox, KeeLoq, Kleer, LANCheck, LinkMD, maxXTouch MediaLB, megaAVR, Microsemi, logo Microsemi, MOST, logo MOST, MPLAB, OptoLyzer, PIC, picoPower, PICSTART, logo PIC32, PolarFire, Prochip Designer, QTouch, SAM-BA, SenGenuity, SpyNIC, SST, Logo SST, SuperFlash, Symmetricom , SyncServer, Tachyon, TimeSource, tinyAVR, UNI/O, Vectron a XMEGA jsou registrované ochranné známky společnosti Microchip Technology Incorporated v USA a dalších zemích.

AgileSwitch, ClockWorks, The Embedded Control Solutions Company, EtherSync, Flashtec, Hyper Speed Control, HyperLight Load, Libero, motorová lavice, mTouch, Powermite 3, Precision Edge, ProASIC, ProASIC Plus, logo ProASIC Plus, Quiet-Wire, SmartFusion, SyncWorld , TimeCesium, TimeHub, TimePictra, TimeProvider a ZL jsou registrované ochranné známky společnosti Microchip Technology Incorporated v USA

Přilehlé potlačení klíče, AKS, Analog-for-the-Digital Age, Libovolný kondenzátor, AnyIn, AnyOut, Augmented Switching, BlueSky, BodyCom, Clockstudio, CodeGuard, CryptoAuthentication, CryptoAutomotive, CryptoCompanion, CryptoCompanion, CryptoCDEM Average, MatdsPI , DAM, ECAN, Espresso T1S, EtherGREEN, EyeOpen, GridTime, IdealBridge,
IGaT, In-Circuit Serial Programming, ICSP, INICnet, Intelligent Paralleling, IntelliMOS, Inter-Chip Connectivity, JitterBlocker, Knob-on-Display, MarginLink, maxCrypto, max.View, 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, PowerSilicon, PowerSilicon, PowerSilicon, , QMatrix, REAL ICE, Ripple Blocker, RTAX, RTG4, SAM-ICE, Serial Quad I/O, jednoduchá mapa, 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 a ZENA jsou ochranné známky společnosti Microchip Technology Incorporated v USA a dalších zemích.

SQTP je servisní značka společnosti Microchip Technology Incorporated v USA
Logo Adaptec, Frequency on Demand, Silicon Storage Technology a Symmcom jsou registrované ochranné známky společnosti Microchip Technology Inc. v jiných zemích.
GestIC je registrovaná ochranná známka společnosti Microchip Technology Germany II GmbH & Co. KG, dceřiné společnosti Microchip Technology Inc., v jiných zemích.

ISBN: 978-1-6683-4890-1

Systém managementu kvality
Informace týkající se systémů řízení kvality společnosti Microchip naleznete na adrese www.microchip.com/quality.

Celosvětový prodej a servis

AMERIKY

ASIE/PACIFIK

EVROPA

Firemní Kancelář

2355 West Chandler Blvd. Chandler, AZ 85224-6199

tel: 480-792-7200

Fax: 480-792-7277

Technická podpora: www.microchip.com/support

Web Adresa: www.microchip.com

Atlanta

Duluth, GA

tel: 678-957-9614

Fax: 678-957-1455

Austin, TX

tel: 512-257-3370

Boston

Westborough, MA Tel: 774-760-0087

Fax: 774-760-0088

Chicago

Itasca, IL

tel: 630-285-0071

Fax: 630-285-0075

Dallas

Addison, TX

tel: 972-818-7423

Fax: 972-818-2924

Detroit

Novi, MI

tel: 248-848-4000

Houston, TX

tel: 281-894-5983

Indianapolis

Noblesville, IN Tel: 317-773-8323

Fax: 317-773-5453

tel: 317-536-2380

Los Angeles

Mission Viejo, CA Tel: 949-462-9523

Fax: 949-462-9608

tel: 951-273-7800

Raleigh, NC

tel: 919-844-7510

New York, NY

tel: 631-435-6000

San jose, CA

tel: 408-735-9110

tel: 408-436-4270

Kanada – Toronto

tel: 905-695-1980

Fax: 905-695-2078

Austrálie – Sydney

Tel: 61-2-9868-6733

Čína – Peking

Tel: 86-10-8569-7000

Čína – Čcheng-tu

Tel: 86-28-8665-5511

Čína – Chongqing

Tel: 86-23-8980-9588

Čína – Dongguan

Tel: 86-769-8702-9880

Čína – Guangzhou

Tel: 86-20-8755-8029

Čína – Chang-čou

Tel: 86-571-8792-8115

Čína – Hong Kong SAR

Tel: 852-2943-5100

Čína – Nanjing

Tel: 86-25-8473-2460

Čína – Čching-tao

Tel: 86-532-8502-7355

Čína – Šanghaj

Tel: 86-21-3326-8000

Čína – Shenyang

Tel: 86-24-2334-2829

Čína – Shenzhen

Tel: 86-755-8864-2200

Čína – Suzhou

Tel: 86-186-6233-1526

Čína – Wuhan

Tel: 86-27-5980-5300

Čína – Xian

Tel: 86-29-8833-7252

Čína – Xiamen

Tel: 86-592-2388138

Čína – Zhuhai

Tel: 86-756-3210040

Indie – Bangalore

Tel: 91-80-3090-4444

Indie – Nové Dillí

Tel: 91-11-4160-8631

Indie – Pune

Tel: 91-20-4121-0141

Japonsko – Ósaka

Tel: 81-6-6152-7160

Japonsko – Tokio

Tel: 81-3-6880- 3770

Korea – Daegu

Tel: 82-53-744-4301

Korea – Soul

Tel: 82-2-554-7200

Malajsie – Kuala Lumpur

Tel: 60-3-7651-7906

Malajsie – Penang

Tel: 60-4-227-8870

Filipíny – Manila

Tel: 63-2-634-9065

Singapur

Tel: 65-6334-8870

Tchaj-wan – Hsin Chu

Tel: 886-3-577-8366

Tchaj-wan – Kaohsiung

Tel: 886-7-213-7830

Tchaj -wan - Tchaj -pej

Tel: 886-2-2508-8600

Thajsko – Bangkok

Tel: 66-2-694-1351

Vietnam – Ho Či Min

Tel: 84-28-5448-2100

Rakousko – Wels

Tel: 43-7242-2244-39

Fax: 43-7242-2244-393

Dánsko – Kodaň

Tel: 45-4485-5910

Fax: 45-4485-2829

Finsko – Espoo

Tel: 358-9-4520-820

Francie – Paříž

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

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

Německo – garching

Tel: 49-8931-9700

Německo – Haan

Tel: 49-2129-3766400

Německo – Heilbronn

Tel: 49-7131-72400

Německo – Karlsruhe

Tel: 49-721-625370

Německo – Mnichov

Tel: 49-89-627-144-0

Fax: 49-89-627-144-44

Německo – Rosenheim

Tel: 49-8031-354-560

Izrael – Hod Hasharon

Tel: 972-9-775-5100

Itálie – Milán

Tel: 39-0331-742611

Fax: 39-0331-466781

Itálie – Padova

Tel: 39-049-7625286

Nizozemsko – Drunen

Tel: 31-416-690399

Fax: 31-416-690340

Norsko – Trondheim

Tel: 47-72884388

Polsko – Varšava

Tel: 48-22-3325737

Rumunsko – Bukurešť

Tel: 40-21-407-87-50

Španělsko - Madrid

Tel: 34-91-708-08-90

Fax: 34-91-708-08-91

Švédsko – Göteborg

Tel: 46-31-704-60-40

Švédsko – Stockholm

Tel: 46-8-5090-4654

Velká Británie – Wokingham

Tel: 44-118-921-5800

Fax: 44-118-921-5820

Dokumenty / zdroje

MICROCHIP PIC64GX 64bitový RISC-V čtyřjádrový mikroprocesor [pdfUživatelská příručka
PIC64GX, PIC64GX 64bitový čtyřjádrový mikroprocesor RISC-V, 64bitový čtyřjádrový mikroprocesor RISC-V, čtyřjádrový mikroprocesor RISC-V, čtyřjádrový mikroprocesor, mikroprocesor

Reference

Uživatelská příručka

MICROCHIP PIC64GX 64bitový RISC-V čtyřjádrový mikroprocesor

Informace o produktu

Návod k použití produktu