MICROCHIP PIC64GX 64 bites RISC-V négymagos mikroprocesszor felhasználói útmutató

Boot folyamat
1. A rendszerindításban részt vevő szoftverösszetevők
  A rendszerindítási folyamat a következő szoftverösszetevőket tartalmazza:
  - Hart Software Services (HSS): A nulláktage rendszertöltő, rendszerfigyelő és futásidejű szolgáltatások szolgáltatója alkalmazásokhoz.
2. Boot Flow
  A rendszerindítási folyamat sorrendje a következő:
  1. A Hart Software Services (HSS) inicializálása
  2. Bootloader végrehajtása
  3. Alkalmazás indítása
Őrzőkutyák
1. PIC64GX Watchdog
  A PIC64GX egy watchdog funkcióval rendelkezik, amely figyeli a rendszer működését, és rendszerhiba esetén műveleteket indít el.
Zárolási mód
A zárolási módot azoknak az ügyfeleknek tervezték, akiknek teljes körű ellenőrzésre van szükségük a rendszerindítás után. Ez korlátozza az E51 rendszermonitor funkcióit.

GYIK

K: Mi a Hart Software Services (HSS) célja?
V: A HSS nullákként szolgáltage rendszertöltő, rendszerfigyelő és futásidejű szolgáltatások szolgáltatója az alkalmazásokhoz a rendszerindítási folyamat során.
K: Hogyan működik a PIC64GX watchdog funkció?
V: A PIC64GX watchdog figyeli a rendszer működését, és előre meghatározott műveleteket hajthat végre rendszerhiba esetén a rendszer megbízhatóságának biztosítása érdekében.

Bevezetés

Ez a tanulmány elmagyarázza, hogyan indítja el a Microchip PIC64GX az alkalmazások munkaterheléseit, és leírja a rendszerindítási folyamatot, amely ugyanúgy működik az SMP és a AMP munkaterhelések. Ezenkívül bemutatja, hogyan működik az újraindítás az SMP és AMP munkaterhelések, figyelők a PIC64GX-en és egy speciális zárolási mód olyan rendszerek számára, ahol az ügyfelek teljes irányításra vágynak, hogy korlátozzák az E51 rendszerfigyelő tevékenységét a rendszerindítás után.

Boot folyamat

Vessünk egy pillantást a rendszerindításban részt vevő különféle szoftverösszetevőkre, majd magát a rendszerindítási folyamatot tekintsük részletesebben.

A rendszerindításban részt vevő szoftverösszetevők
A következő összetevők vesznek részt a rendszerindítási folyamatban:

1.1. ábra. Indító komponensek

Hart Software Services (HSS)
A Hart Software Services (HSS) nullatage rendszertöltő, rendszerfigyelő és futásidejű szolgáltatások szolgáltatója alkalmazásokhoz. A HSS támogatja a rendszer korai beállítását, a DDR képzést és a hardver inicializálását/konfigurálását. Leginkább az E51-eken fut, és minden U54-en fut egy kis gépi szintű funkció. Egy vagy több környezetet úgy indít el, hogy betölti az alkalmazás „payloadját” a rendszerindító adathordozóról, és Platform Runtime Services/Supervisor Execution Environment (SEE) szolgáltatást biztosít az operációs rendszermagokhoz. Támogatja a biztonságos rendszerindítást, és fontos összetevője a hardver particionálásának/leválasztásának AMP összefüggésekben.

Das U-Boot (U-Boot)
A Das U-Boot (U-Boot) egy nyílt forráskódú univerzális szkriptelhető rendszertöltő. Támogatja az egyszerű CLI-t, amely számos forrásból (beleértve az SD-kártyát és a hálózatot) lekérheti a rendszerindító lemezképet. Az U-Boot betölti a Linuxot. Szükség esetén UEFI környezetet tud biztosítani. A Linux rendszerindítása után általában kész, és nincs útban – más szóval, a rendszerindítás után sem marad állandóan.
Linux Kernel
A Linux kernel a világ legnépszerűbb operációs rendszermagja. Az alkalmazások felhasználói területével kombinálva létrehozza azt, amit általában Linux operációs rendszernek neveznek. A Linux operációs rendszer gazdag POSIX API-kat és fejlesztői környezetet biztosít, plample, nyelvek és eszközök, például Python, Perl, Tcl, Rust, C/C++ és Tcl; olyan könyvtárak, mint az OpenSSL, OpenCV, OpenMP, OPC/UA és OpenAMP (RPmsg és RemoteProc).
A Yocto és a Buildroot Linux rendszerépítők, vagyis testre szabott Linux rendszerek létrehozására használhatók. A Yocto egy Linux disztribúciót ad ki gazdagon
alkalmazások, eszközök és könyvtárak készlete, valamint az opcionális csomagkezelés. A Buildroot egy minimális gyökeret ad ki filerendszert, és megcélozhatja azokat a rendszereket, amelyek nem igényelnek állandó tárhelyet, de teljes egészében RAM-ból futnak (a Linux kezdőbetűinek támogatásával, pl.ample).

Zefír
A Zephyr egy kicsi, nyílt forráskódú valós idejű operációs rendszer (RTOS). Valós idejű Low-Overhead keretrendszert biztosít RPMsg-lite kommunikációs csatornákkal a Linux felé. Tartalmaz egy kernelt, könyvtárakat, eszközillesztőket, protokoll veremeket, filerendszerek, firmware-frissítési mechanizmusok és így tovább, és kiválóan alkalmas azoknak az ügyfeleknek, akik a PIC64GX-en egy fémjellegűbb élményt szeretnének.

Boot Flow
A PIC64GX tartalmaz egy RISC-V coreplexet egy 64 bites E51 rendszermonitorral és 4 darab 64 bites U54 alkalmazásharttal. A RISC-V terminológiában a hart egy RISC-V végrehajtási környezet, amely regiszterek teljes készletét tartalmazza, és amely önállóan hajtja végre a kódját. Gondolhatod hardveres szálnak vagy egyetlen CPU-nak. A szarvasok egy magon belüli csoportját gyakran komplexnek nevezik. Ez a témakör a PIC64GX coreplex inicializálásának lépéseit írja le, ideértve az E51 rendszer szívfigyelőit és az U54 alkalmazáshartokat.

Kapcsolja be a PIC64GX coreplexet.
Bekapcsoláskor a RISC-V coreplexben lévő összes hartot feloldja a visszaállítás alól a biztonsági vezérlő.
Futtassa a HSS kódot a chipen lévő eNVM flash memóriából.
Kezdetben minden szív elkezdi futtatni a HSS kódot a chipen lévő eNVM flash memóriából. Ez a kód arra készteti az összes U54 alkalmazást, hogy az utasításokra várva forog, és lehetővé teszi az E51 monitor hart számára, hogy elindítsa a kód futtatását a rendszer inicializálásához és előhívásához.

Tömörítse ki a HSS kódot az eNVM-ből az L2-Scratch memóriába.
A beépítési idő konfigurációjától függően a HSS általában nagyobb, mint maga az eNVM flash memória kapacitása, így az E51-en futó HSS kód első dolga, hogy kicsomagolja magát az eNVM-ből L2-Scratch memóriába, amint az az ábrán látható. 1.2 és 1.3 ábra.
1.2. ábra. A HSS kibontása az eNVM-ből L2 Scratch-be
1.3. ábra. HSS memóriatérkép dekompresszió során
Ugorjon az eNVM-ről az L2-Scratch-re egy végrehajtható fájlba, ahogy az a következő ábrán látható.
1.4. ábra. A HSS az eNVM-ből a Code Now-ba ugrik az L2Scratch-ben a kibontást követően
A végrehajtható fájl három összetevőből áll:
- Hardveres absztrakciós réteg (HAL), alacsony szintű kód és csupasz fém meghajtók
- A RISC-V OpenSBI helyi HSS villája (a PIC64GX-en kissé módosított AMP célokra)
- A HSS futásidejű szolgáltatások (az állapotgépek szuperhurokban futnak)
Inicializálja az OpenSBI által használt hardvert és adatstruktúrákat.
A HSS „Startup” szolgáltatás felelős ezért az inicializálásért.

Töltse le az alkalmazás munkaterhelésének (payload.bin) képfájlját a külső tárolóról. Ez az 1.5. és az 1.6. ábrán látható
Fontos: A PIC64GX Curiosity Kit esetében ez SD kártyáról történik.
1.5. ábra. A payload.bin munkaterhelési kép lekérése a külső tárhelyről
1.6. ábra. HSS memóriatérkép a payload.bin lekérése után
Másolja a különböző szakaszokat a payload.bin fájlból a végrehajtási idő célpontjaiba. A payload.bin egy formázott kép, amely egyesíti a különböző alkalmazásképeket az SMP ill AMP munkaterhelések. Tartalmaz olyan kód-, adat- és leíró táblákat, amelyek lehetővé teszik a HSS számára, hogy megfelelően elhelyezze a kód- és adatszakaszokat ott, ahol a különböző alkalmazási terhelések futtatásához szükségesek.
1.7. ábra. A payload.bin a célcímekre másolódik

Utasítsa a megfelelő U54-eket, hogy ugorjanak a végrehajtás kezdőcímére. Ezt a kezdőcím-információt a payload.bin tartalmazza.
Indítsa el az U54 Application harts-ot és a másodpercekettage rendszerbetöltők. Plample, az U-Boot előhozza a Linuxot.

Indítsa újra

A rendszerindítás fogalmához kapcsolódik az újraindítás szükségessége. Amikor a PIC64GX alkalmazások munkaterhelésére gondolunk, az újraindításkor figyelembe kell venni mind a szimmetrikus többfeldolgozást (SMP), mind az aszimmetrikus többfeldolgozást (AMP) forgatókönyvek:

SMP rendszer esetén az újraindítás biztonságosan hidegen újraindíthatja a teljes rendszert, mivel nincs további számításba vehető munkaterhelés egy másik környezetben.

Abban az esetben, ha egy AMP rendszer, akkor előfordulhat, hogy egy munkaterhelés csak önmagát indíthatja újra (és nem zavarhat semmilyen más környezetet), vagy kiváltságos lehet a teljes rendszer újraindítása.

Újraindítás és AMP
Az SMP engedélyezéséhez és AMP Újraindítási forgatókönyvek esetén a HSS támogatja a meleg és hideg újraindítási jogosultságok koncepcióját, amelyek egy környezethez rendelhetők. A meleg újraindítási jogosultsággal rendelkező környezet csak önmagát tudja újraindítani, a hideg újraindítási jogosultsággal rendelkező környezet pedig teljes rendszer-újraindítást hajthat végre. Plample, vegye figyelembe a következő reprezentatív forgatókönyveket.

Egyetlen kontextusú SMP-munkaterhelés, amely lehetővé teszi a rendszer teljes újraindítását
Ebben a forgatókönyvben a környezet hideg újraindítási jogosultsággal rendelkezik.
Két kontextus AMP munkaterhelés, ahol az A kontextus kérheti a rendszer teljes újraindítását (az összes kontextust érintve), és a B kontextus csak önmagát indíthatja újra
Ebben a forgatókönyvben az A kontextus hideg újraindítási jogosultsággal, a B kontextus pedig meleg újraindítási jogosultsággal rendelkezik.
Két kontextus AMP munkaterhelés, ahol az A és B kontextus csak saját magát indíthatja újra (és nem befolyásolja a másik kontextust)
Ebben a forgatókönyvben mindkét környezet csak meleg újraindítási jogosultságokkal rendelkezik.
Két kontextus AMP munkaterhelés, ahol az A és B kontextus egyaránt kérheti a rendszer teljes újraindítását
Ebben a forgatókönyvben mindkét környezet hideg újraindítási jogosultsággal rendelkezik.
Ezenkívül lehetséges, hogy a HSS az összeállításkor mindig engedélyezze a hideg újraindítási jogosultságot, és soha ne engedje meg a hideg újraindítási jogosultságot.

Releváns HSS Kconfig beállítások
A Kconfig egy szoftveres konfigurációs rendszer. Általában az építési idő opcióinak kiválasztására és a funkciók engedélyezésére vagy letiltására használják. A Linux kernelből származik, de mára a Linux kernelen kívül más projektekben is alkalmazták, beleértve az U-Boot-ot, a Zephyr-t és a PIC64GX HSS-t.

A HSS két Kconfig-beállítást tartalmaz, amelyek az újraindítási funkciókat a HSS szemszögéből vezérlik:

CONFIG_ALLOW_COLD ÚJRAINDÍTÁS
Ha ez be van kapcsolva, akkor globálisan lehetővé teszi a környezet számára hideg újraindítási ecall kiadását. Ha le van tiltva, csak meleg újraindítás engedélyezett. Amellett, hogy engedélyezi ezt az opciót, a YAML hasznosadat-generátoron keresztül engedélyezni kell a hideg újraindítást. file vagy a következő Kconfig beállítást.
CONFIG_ALLOW_COLD REBOOT_ALWAYS
- Ha engedélyezve van, ez a szolgáltatás globálisan lehetővé teszi, hogy minden környezet hideg-újraindítási ECAA-t adjon ki, függetlenül a payload.bin jelző jogosultságaitól.
- Ezenkívül maga a payload.bin tartalmazhat egy kontextusonkénti jelzőt, amely azt jelzi, hogy egy adott környezet jogosult hideg újraindításra:
  - Egy kontextus meleg újraindításának engedélyezéséhez a YAML leírásában felvehetjük az allow-reboot: meleg opciót. file a payload.bin létrehozásához használt
  - A teljes rendszer kontextusban történő hidegindításának engedélyezéséhez hozzáadhatjuk az allow-reboot: cold opciót. Alapértelmezés szerint a kontextus csak a meleg újraindítást engedélyezi. A jelző beállításától függetlenül, ha a CONFIG_ALLOW_COLDREBOOT nincs engedélyezve a HSS-ben, a HSS minden hideg újraindítási kérést átdolgozza meleg (kontextusonkénti) újraindításra. .

Indítsa újra részletesen
Ez a rész részletesen leírja, hogyan működik az újraindítás – kezdve az OpenSBI-réteggel (a legalacsonyabb M-módú réteg), majd megvitatjuk, hogy ez az OpenSBI-réteg-funkció hogyan váltható ki egy RTOS-alkalmazásból vagy egy gazdag operációs rendszerből, például a Linuxból.

OpenSBI Reboot ecall

A RISC-V Supervisor Binary Interface (SBI) specifikációja szabványos hardveres absztrakciós réteget ír le a platform inicializálásához és a firmware futásidejű szolgáltatásokhoz. Az SBI fő célja, hogy lehetővé tegye a hordozhatóságot és a kompatibilitást a különböző RISC-V implementációk között.
Az OpenSBI (Open Source Supervisor Binary Interface) egy nyílt forráskódú projekt, amely az SBI-specifikáció referencia megvalósítását biztosítja. Az OpenSBI futásidejű szolgáltatásokat is nyújt, beleértve a megszakításkezelést, az időzítő kezelést és a konzol I/O-t, amelyeket magasabb szintű szoftverrétegek is használhatnak.
Az OpenSBI a HSS része, és a gépi mód szintjén fut. Ha az operációs rendszer vagy alkalmazás csapdát okoz, azt az OpenSBI-nak kell átadni, hogy kezelje. Az OpenSBI egy bizonyos rendszerhívás típusú funkcionalitást tesz elérhetővé a szoftver felső rétegei számára egy speciális csapdamechanizmuson keresztül, amelyet e-hívásnak neveznek.

A rendszer-visszaállítás (EID 0x53525354) átfogó rendszerhívási funkciót biztosít, amely lehetővé teszi a felsőbb rétegbeli szoftver számára, hogy rendszerszintű újraindítást vagy leállítást kérjen. Ha ezt az ecall-t egy U54 hívja meg, a gépi módban futó HSS-szoftver csapdába ejti az U54-en, és a megfelelő újraindítási kérelmet küldi az E51-nek a kontextus vagy a teljes rendszer újraindításához, a rendszer jogosultságaitól függően. kontextus.

További információkért lásd a RISC-V Supervisor bináris interfész specifikációja különösen Rendszer-visszaállítási bővítmény (EID #0x53525354 „SRST”).

Linux újraindítás

Mint konkrét exampEbből a Linuxban a shutdown parancs a rendszer leállítására vagy újraindítására szolgál. A parancsnak általában sok álneve van, nevezetesen leállítás, kikapcsolás és újraindítás. Ezek az álnevek határozzák meg, hogy leállításkor le kell-e állítani a gépet, leállításkor le kell-e kapcsolni, vagy leállításkor újra kell indítani a gépet.

Ezek a felhasználói térbeli parancsok újraindító rendszerhívást adnak ki a Linuxnak, amelyet a kernel csapdába ejt, és együttműködik egy SBI ecall-tal.
Az újraindításnak többféle szintje van – REBOOT_WARM, REBOOT_COLD, REBOOT_HARD – ezek parancssori argumentumként adhatók át a kernelnek (pl.ample, reboot=w[arm] for REBOOT_WARM). A Linux kernel forráskódjával kapcsolatos további információkért lásd: Documentation/admin-guide/kernel-paramters.txt.
Alternatív megoldásként, ha a /sys/kernel/reboot engedélyezve van, az alatta lévő kezelők beolvashatók a rendszer aktuális újraindítási konfigurációjának lekéréséhez, és beírhatók annak megváltoztatásához. A Linux kernel forráskódjával kapcsolatos további információkért lásd: Dokumentáció/ABI/testing/sysfs-kernel-reboot.

Őrzőkutyák

A rendszerindításhoz és a rendszer újraindításához kapcsolódó további koncepció a rendszer-helyreállítás a watchdog időzítő elindításakor. A Watchdog időzítőket széles körben használják a beágyazott rendszerekben, hogy automatikusan helyreálljanak az átmeneti hardverhibák után, és megakadályozzák, hogy a hibás vagy rosszindulatú szoftverek megzavarják a rendszer működését.
A PIC64GX hardveres watchdog támogatást is tartalmaz, hogy figyelje az egyes hartokat, amikor a rendszer fut. A felügyelők gondoskodnak arról, hogy a harts újraindítható legyen, ha helyrehozhatatlan szoftverhiba miatt nem reagálnak.
A PIC64GX öt példányt tartalmaz watchdog időzítő hardverblokkból, amelyek a rendszer lefagyások észlelésére szolgálnak – egyet minden páncélhoz. A vegyes aszimmetrikus többszörös feldolgozás megkönnyítése érdekében (AMP) munkaterhelések esetén a HSS támogatja a figyelőkutyák tüzelését és az arra való reagálást.

PIC64GX Watchdog

A HSS felelős az alkalmazás harts rendszerindításáért a bekapcsoláskor, és azok újraindításáért (egyénileg vagy együttesen) bármely stage, ha szükséges vagy kívánatos. Ennek következtében a PIC64GX-en a watchdog eseményekre való reagálást a HSS kezeli.
A „virtuális watchdog” monitort HSS állapotgép-szolgáltatásként valósítják meg, és feladata az egyes U54-es hardverfigyelők állapotának figyelése. Amikor az egyik ilyen U54-es őrzőkutya leold, a HSS észleli ezt, és szükség szerint újraindítja az U54-et. Ha az U54 egy SMP-környezet része, akkor a rendszer a teljes kontextust veszi figyelembe az újraindításhoz, mivel a környezet meleg újraindítási jogosultsággal rendelkezik. A teljes rendszer újraindul, ha a környezet hideg újraindítási jogosultsággal rendelkezik.

Releváns Kconfig-beállítások

A Watchdog támogatás alapértelmezés szerint benne van a kiadott HSS buildekben. Ha egyéni HSS-t szeretne építeni, ez a szakasz leírja a konfigurációs mechanizmust, amely biztosítja, hogy a Watchdog támogatás engedélyezve legyen.

A HSS konfigurálása a Kconfig konfigurációs rendszerrel történik. Egy felső szintű .config file szükséges annak kiválasztásához, hogy milyen szolgáltatások legyenek lefordítva a HSS buildben vagy azon kívül.
Először is engedélyezni kell a legfelső szintű CONFIG_SERVICE_WDOG opciót („Virtuális Watchdog támogatás” a make config segítségével).

Ez azután a Watchdog támogatásától függő következő albeállításokat teszi elérhetővé:

CONFIG_SERVICE_WD OG_DEBUG
Lehetővé teszi a virtuális figyelőszolgálat információs/hibakereső üzeneteinek támogatását.
CONFIG_SERVICE_WD OG_DEBUG_TIMEOUT_SECS
Meghatározza azt a periodicitást (másodpercben), amelyet a Watchdog hibakeresési üzenetek a HSS kiadnak.
CONFIG_SERVICE_WD OG_ENABLE_E51
Lehetővé teszi az E51 monitorok szívét az U54-ek mellett, védve magát a HSS működését.

Ha az E51 watchdog engedélyezve van, a HSS rendszeresen ír a Watchdognak, hogy frissítse és megakadályozza a tüzelést. Ha valamilyen oknál fogva az E51 szív leblokkol vagy összeomlik, és az E51 watchdog engedélyezve van, ez mindig visszaállítja a teljes rendszert.

Watchdog művelet
A watchdog hardver lefelé mutató számlálókat valósít meg. Frissítéstől tilos ablak hozható létre a watchdog Maximális érték, ameddig a frissítés engedélyezett (MVRP) beállításával.

Ha a watchdog időzítő aktuális értéke nagyobb, mint az MVRP érték, a watchdog frissítése tilos. Ha megpróbálja frissíteni a watchdog időzítőt a tiltott ablakban, az időtúllépési megszakítást fog érvényesíteni.

A watchdog frissítése az MVRP érték és a trigger érték (TRIG) között sikeresen frissíti a számlálót, és megakadályozza a watchdog tüzelését.
Amint a watchdog időzítő értéke a TRIG érték alá csökken, a watchdog tüzelni kezd.

Watchdog államgép

A watchdog állapot gépe nagyon egyszerű – az E51 watchdog konfigurálásával indul, ha engedélyezve van, majd készenléti állapoton át a felügyeletbe. A szuperhurok körül minden alkalommal ezt a megfigyelési állapotot hívják meg, amely ellenőrzi az egyes U54 őrzőkutyák állapotát.

A watchdog állapot gép kölcsönhatásba lép a rendszerindító állapotú géppel, hogy újraindítsa a hartot (és minden más, a rendszerindító készletében lévő hartot), ha azt észleli, hogy a hart nem tudta időben frissíteni a watchdogját.

Zárolási mód

Általában (főleg azzal AMP alkalmazások), várható, hogy a HSS M-módban marad U54-en, hogy lehetővé tegye a kontextusonkénti újraindítást (azaz csak egy kontextus újraindítását, teljes chipes újraindítás nélkül), és lehetővé tegye a HSS számára az állapot figyelését ( ECC-k, zárállapot-bitek, buszhibák, SBI-hibák, PMP-sértések stb.).

Az újraindítási lehetőségek biztosítása érdekébenAMP környezeti alapon (a teljes rendszer újraindítása nélkül) az E51 rendszerint kiváltságos memória-hozzáféréssel rendelkezik a rendszer teljes memóriaterületéhez. Előfordulhatnak azonban olyan helyzetek, amikor ez nem kívánatos, és az ügyfél inkább korlátozhatja az E51 HSS firmware tevékenységét, miután a rendszer sikeresen elindult. Ebben az esetben lehetséges a HSS zárolási módba állítása, miután az U54 Application Harts elindult.

Ez a HSS Kconfig CONFIG_SERVICE_LOCKDOWN beállításával engedélyezhető.
A zárolási szolgáltatás célja, hogy lehetővé tegye a HSS tevékenységeinek korlátozását az U54 Harts alkalmazás elindítása után.

4.2. ábra. HSS zárolási mód

Amint a Lezárási mód elindul, leállítja az összes többi HSS szolgáltatás állapotú gép futását. Két gyengén kötött függvényt hív meg:

e51_pmp_lockdown(), és
e51_lockdown()

Ezeket a funkciókat a kártya-specifikus kód felülírja. Az első egy konfigurálható trigger funkció, amely lehetővé teszi a BSP számára, hogy testreszabhassa az E51 zárolását az alkalmazás hasznos terheitől ezen a ponton. Ennek a függvénynek a gyengén kötött alapértelmezett megvalósítása üres. A második az a funkcionalitás, amely ettől kezdve fut. A gyengén kötött alapértelmezett implementáció ezen a ponton szolgálja ki a watchdogot az E51-ben, és újraindul, ha egy U54 watchdog beindul. További információkért tekintse meg a HSS-forráskódot a services/lockdown/lockdown_service.c oldalon file.

Függelék

HSS payload.bin formátum

Ez a rész a payload.bin fájlt írja le file formátum és a HSS által használt kép a PIC64GX SMP és AMP alkalmazások.
A payload.bin egy formázott bináris fájl (A.10. ábra), amely egy fejből, különböző leírótáblákból és különböző darabokból áll, amelyek az alkalmazás munkaterhelésének egyes részeinek kód- és adatrészeit tartalmazzák. Egy darab tetszőleges méretű összefüggő memóriablokknak tekinthető.

ábra A.10. payload.bin Formátum

A fejléc rész (az A.11. ábrán látható) a payload.bin azonosítására használt mágikus értéket és néhány háztartási információt tartalmaz, valamint az egyes
U54 alkalmazási kódok. Leírja, hogyan kell minden egyes U54 hartot indítani, és a rendszerindító képek összességét. A háztartási információkban mutatókat tartalmaz különböző leírótáblázatokra, amelyek lehetővé teszik a fejléc méretének növekedését.

ábra A.11. payload.bin Fejléc

A kód és az inicializált konstans adatok csak olvashatónak minősülnek, és egy csak olvasható szakaszban tárolódnak, amelyre fejlécleírók mutatnak rá.
A nullától eltérő inicializált adatváltozók olvasási-írási adatok, de inicializálási értékeiket az indításkor a csak olvasható részből másolják. Ezek is a csak olvasható részben vannak tárolva.

A csak olvasható hasznos adatszakaszt egy kód- és adatcsonk-leíró táblázat írja le. Ebben a táblázatban minden darableíró tartalmaz egy "hart tulajdonost" (a fő hart abban a kontextusban, amelyet megcéloz
at), egy terheléseltolás (eltolás a payload.bin-en belül) és egy végrehajtási cím (célcím a PIC64GX memóriában), valamint egy méret és ellenőrző összeg. Ezt mutatja az A.12. ábra.

ábra A.12. Csak olvasható darableíró és hasznos terhelési darabadatok

A fent említett darabokon kívül vannak olyan adatváltozóknak megfelelő memóriadarabok is, amelyek nullára vannak inicializálva. Ezeket nem tárolja adatként a payload.bin, hanem egy speciális nulla inicializált darableíró készlet, amely megadja a RAM címét és hosszát, amelyet az indításkor nullára kell állítani. Ez az A.13. ábrán látható.

ábra A.13. ZI Darabok

hss-payload-generator
A HSS Payload Generator eszköz formázott rakományképet hoz létre a Hart Software Service nullák számáratage rendszerbetöltő PIC64GX-en, adott konfigurációban file és egy készlet ELF files és/vagy binárisok. A konfiguráció file az ELF binárisok vagy bináris blobok leképezésére szolgál az egyedi alkalmazás hartokhoz (U54s).

B.14. ábra. hss-payload-generator Flow

Az eszköz alapvető józansági ellenőrzéseket végez a konfiguráció szerkezetén file magán és az ELF-képeken. Az ELF-képeknek RISC-V végrehajtható fájloknak kell lenniük.

Example Run

A hss-payload-generator eszköz futtatásához az s-velample konfigurációt file és ELF files:
$ ./hss-payload-generator -c test/config.yaml output.bin
Egy már meglévő kép diagnosztikájának kinyomtatásához használja:
$ ./hss-payload-generator -d output.bin

A biztonságos rendszerindítási hitelesítés engedélyezéséhez (képaláírással) a -p billentyűvel adja meg a P-509 elliptikus görbe (SECP384r384) X.1 privát kulcsának helyét:
$ ./hss-payload-generator -c test/config.yaml payload.bin -p /path/to/private.pem

További információkért tekintse meg a Secure Boot Authentication dokumentációját.

Konfig File Example

Először opcionálisan megadhatunk egy nevet a képünknek, ellenkező esetben dinamikusan jön létre:
set-name: 'PIC64-HSS::TestImage'
Ezután minden szívhez meghatározzuk a belépési pontok címét, az alábbiak szerint:
hart-entry-points: {u54_1: ‘0x80200000’, u54_2: ‘0x80200000’, u54_3: ‘0xB0000000′, u54_4:’0x80200000’}

Az ELF forrásképek megadhatnak belépési pontot, de szükség esetén támogatni szeretnénk a harts másodlagos belépési pontjait, pl.ample, ha több hart ugyanazt a képet kívánja indítani, akkor külön belépési pontjaik lehetnek. Ennek alátámasztására a konfigurációban megadjuk a tényleges belépési pont címeket file maga.

Most már meghatározhatunk néhány hasznos terhet (forrás ELF files vagy bináris blobok), amelyek a memória bizonyos régióira kerülnek. A hasznos teher szakaszt a payloads kulcsszó határozza meg, majd néhány egyedi rakományleíró. Minden rakománynak van neve (útvonala file), egy tulajdonos-hart és opcionálisan 1-3 másodlagos hart.

Ezen túlmenően a hasznos teher rendelkezik egy jogosultsági móddal, amelyben elindítja a végrehajtást. Az érvényes jogosultsági módok a PRV_M, PRV_S és PRV_U, ahol ezek a következők:

PRV_M Gépi mód
PRV_S Felügyelő mód
PRV_U Felhasználói mód

A következőben plample:

Feltételezzük, hogy a test/zephyr.elf egy Zephyr alkalmazás, amely U54_3 alatt fut, és várhatóan PRV_M jogosultsági módban indul.
A test/u-boot-dtb.bin a Das U-Boot rendszerbetöltő alkalmazás, amely U54_1, U54_2 és U54_4 rendszeren fut. Várhatóan PRV_S jogosultsági módban indul.

Fontos:
Az U-Boot kimenete ELF-et hoz létre file, de általában nem fűzi az .elf kiterjesztést. Ebben az esetben a CONFIG_OF_SEPARATE által létrehozott binárist használják, amely egy eszközfa blobot fűz hozzá az U-Boot binárishoz.

Itt van az example Payloads konfiguráció file:

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

Fontos:
Az eset csak a file elérési útneveket, nem a kulcsszavakat. Így például az u54_1 ugyanaz, mint az U54_1, az exec-addr pedig az EXEC-ADDR. Ha van an.elf vagy .bin kiterjesztés, akkor azt szerepeltetni kell a konfigurációban file.

Egy csupasz fém alkalmazásnál, amely nem akar foglalkozni az OpenSBI-val, a skip-open opció, ha igaz, az adott szív hasznos terhét egy egyszerű mret segítségével hívja meg.
mint egy OpenSBI sbi_init() hívás. Ez azt jelenti, hogy a szív elkezdi futtatni a csupasz fém kódot, függetlenül az OpenSBI HSM megfontolásától. Vegye figyelembe, hogy ez azt is jelenti, hogy a szív nem tudja használni
meghívja az OpenSBI funkciót. A skip-opens opció nem kötelező, és alapértelmezés szerint false.

Egy másik kontextus kontextusból történő meleg újraindításának engedélyezéséhez hozzáadhatjuk az enable reboot: warm opciót. A teljes rendszer kontextusban történő hidegindításának engedélyezéséhez hozzáadhatjuk az allow-reboot: cold opciót. Alapértelmezés szerint az enable-reboot megadása nélkül a kontextus csak önmagát melegíti újra.
Lehetőség van kiegészítő adatok társítására is minden hasznos adathoz, plample, egy DeviceTree Blob (DTB) file, a járulékos adatok megadásával filea következő néven:
test/u-boot.bin: { exec-addr: '0x80200000', tulajdonos-hart: u54_1, másodlagos-hart: u54_2, másodlagos-hart: u54_3, másodlagos-hart: u54_4, priv-mode: prv_s, kiegészítő adatok : test/pic64gx.dtb }
Ezek a járulékos adatok bekerülnek a hasznos terhelésbe (közvetlenül a fő után file a végrehajtható fájlban
space), és a címe az OpenSBI-nak kerül átadásra a next_arg1 mezőben (az $a1 regiszterben a rendszerindításkor átadva a képfájlnak).

Ha meg szeretné akadályozni, hogy a HSS automatikusan elindítson egy kontextust (például ha ehelyett egy kontextusra szeretnénk delegálni a vezérlést a remoteProc segítségével), használja a skip-autoboot jelzőt:
test/zephyr.elf: {exec-addr: '0xB0000000', tulajdonos-hart: u54_3, priv-mode: prv_m, skip-opensbi: true, skip-autoboot: true}
Végül opcionálisan felülírhatjuk az egyes rakományok neveit a payload-name opció használatával. Plample:
test/u-boot.bin: { exec-addr: '0x80200000', tulajdonos-hart: u54_1, másodlagos-hart: u54_2, másodlagos-hart: u54_3, másodlagos-hart: u54_4, priv-mode: prv_s, kiegészítő adatok : test/pic64gx.dtb, hasznos adat: 'u-boot' }

Ne feledje, hogy a Yocto és a Buildroot Linux-készítők felállítják, konfigurálják és futtatják a hss-payload-
generátort, ha szükséges az alkalmazásképek generálásához. Ezenkívül a pic64gx-curiosity-kit-amp A Yocto gépi célpontja a hss-payload-generator eszközzel egy alkalmazásképet generál, amely bemutatja AMP, a Linux 3 harton fut, a Zephyr pedig 1 harton.

Revíziótörténet
A felülvizsgálati előzmények leírják a dokumentumban végrehajtott változtatásokat. A változtatások átdolgozásonként vannak felsorolva, a legfrissebb kiadványtól kezdve.

Felülvizsgálat	Dátum	Leírás
A	07/2024	Kezdeti felülvizsgálat

Mikrochip információk

A Mikrochip Webtelek
A Microchip online támogatást nyújt a mi oldalunkon keresztül webwebhely a címen www.microchip.com/. Ez webkészítésére használják az oldalt files és információk könnyen elérhetők az ügyfelek számára. A rendelkezésre álló tartalom egy része a következőket tartalmazza:

Terméktámogatás – Adatlapok és hibák, alkalmazási megjegyzések és sample programokat, tervezési forrásokat, felhasználói kézikönyveket és hardvertámogató dokumentumokat, legújabb szoftverkiadásokat és archivált szoftvereket

Általános műszaki támogatás – Gyakran Ismételt Kérdések (GYIK), technikai támogatási kérések, online vitacsoportok, Microchip tervezői partnerek listája
A Microchip üzletága – Termékválasztó és rendelési útmutatók, legújabb Microchip sajtóközlemények, szemináriumok és események listája, a Microchip értékesítési irodáinak, forgalmazóinak és gyári képviselőinek listája

Termékváltoztatásértesítő szolgáltatás

A Microchip termékváltoztatási értesítési szolgáltatása segít az ügyfeleknek naprakészen tartani a Microchip termékeit. Az előfizetők e-mailben értesítést kapnak, ha egy adott termékcsaláddal vagy fejlesztőeszközzel kapcsolatban változás, frissítés, átdolgozás vagy hiba történik.

A regisztrációhoz menjen a címre www.microchip.com/pcn és kövesse a regisztrációs utasításokat.

Ügyfélszolgálat
A Microchip termékek felhasználói több csatornán keresztül kaphatnak segítséget:

Forgalmazó vagy képviselő
Helyi Értékesítési Iroda
Embedded Solutions Engineer (ESE)
Műszaki támogatás

Az ügyfeleknek a forgalmazójukhoz, képviselőjükhöz vagy az ESE-hez kell fordulniuk támogatásért. A helyi értékesítési irodák is rendelkezésre állnak, hogy segítsenek az ügyfeleknek. Az értékesítési irodák és helyszínek listája ebben a dokumentumban található.
A technikai támogatás a következőn keresztül érhető el webwebhely a következő címen: www.microchip.com/support.

Mikrochip eszközök kódvédelmi funkciója
Vegye figyelembe a Microchip termékek kódvédelmi funkciójának alábbi részleteit:

A Microchip termékek megfelelnek az adott Microchip Adatlapon található előírásoknak.
A Microchip úgy véli, hogy termékcsaládja biztonságos, ha rendeltetésszerűen, a működési előírásokon belül és normál körülmények között használják.

A Microchip értékeli és agresszíven védi szellemi tulajdonjogait. A Microchip termékek kódvédelmi funkcióinak megsértésére irányuló kísérletek szigorúan tilosak, és sérthetik a Digital Millennium Copyright Act-et.
Sem a Microchip, sem más félvezetőgyártó nem tudja garantálni kódja biztonságát. A kódvédelem nem jelenti azt, hogy garantáljuk a termék „törhetetlenségét”. A kódvédelem folyamatosan fejlődik. A Microchip elkötelezett amellett, hogy folyamatosan fejlessze termékei kódvédelmi funkcióit.

Jogi közlemény
Ez a kiadvány és az itt található információk csak Microchip termékekkel használhatók, ideértve a Microchip termékek tervezését, tesztelését és integrálását az alkalmazással. Ezen információk bármilyen más módon történő felhasználása sérti ezeket a feltételeket. Az eszközalkalmazásokkal kapcsolatos információk csak az Ön kényelmét szolgálják, és frissítések válthatják fel azokat. Az Ön felelőssége annak biztosítása, hogy alkalmazása megfeleljen az előírásoknak. További támogatásért forduljon a helyi Microchip értékesítési irodához, vagy kérjen további támogatást a következő címen www.microchip.com/en-us/support/design-help/client-support-services.

EZT AZ INFORMÁCIÓT A MICROCHIP „AHOGY VAN”. A MICROCHIP NEM NYILATKOZAT SEMMILYEN KIFEJEZETT VAGY VÉLEMEZTETETT, ÍRÁSBAN VAGY SZÓBELI, TÖRVÉNYI VAGY EGYÉBEN AZ INFORMÁCIÓKAL KAPCSOLATOS GARANCIÁT, BELEÉRTVE, DE NEM KIZÁRÓLAG BÁRMILYEN VÉLEMEZTETT GARANCIÁT. MEGHATÁROZOTT CÉLRA VALÓ ALKALMAZÁS, VAGY ÁLLAPOTÁHOZ, MINŐSÉGÉVEL VAGY TELJESÍTMÉNYÉVEL KAPCSOLATOS GARANCIA.

A Microchip semmilyen esetben sem felel meg bármilyen közvetett, különleges, büntető, véletlenszerű vagy következményes veszteségért, kárért, költségeiért vagy költségeiért, amelyek az információkhoz vagy annak felhasználásához kapcsolódnak, még akkor is, ha a mikrochipnek tanácsot adtak a A LEHETŐSÉG VAGY A KÁROK ELŐRE ELÉRHETŐK. A TÖRVÉNY ÁLTAL ENGEDÉLYEZETT TELJES MÉRTÉKÉBEN A MICROCHIP TELJES FELELŐSSÉGE AZ INFORMÁCIÓKAL VAGY FELHASZNÁLÁSÁVAL KAPCSOLATOS ÖSSZES KÖVETELÉSRE VONATKOZÓAN NEM MEGTÖLTI AZOKAT DÍJAK SZÁMÁT, AMENNYIBEN VAN VAN, AMELYEKET ÖN AZ MICROFORMÁTUMÉRT FIZETETT.

A Microchip eszközök életfenntartó és/vagy biztonsági alkalmazásokban történő használata teljes mértékben a vevő kockázatára történik, és a vevő vállalja, hogy megvédi, kártalanítja és ártalmatlanná teszi a Microchipet az ilyen használatból eredő minden kárral, követeléssel, perrel vagy kiadással szemben. A Microchip szellemi tulajdonjogai alapján semmilyen licencet nem adnak át, sem hallgatólagosan, sem más módon, hacsak másként nem rendelkeznek.

Védjegyek
A Microchip neve és logója, a Microchip logó, Adaptec, AVR, AVR logó, AVR Freaks, BesTime, BitCloud, CryptoMemory, CryptoRF, dsPIC, flexPWR, HELDO, IGLOO, JukeBlox, KeeLoq, Kleer, LANCheck, LinklusMD, maXTouchty, MediaLB, megaAVR, Microsemi, Microsemi logó, MOST, MOST logó, MPLAB, OptoLyzer, PIC, picoPower, PICSTART, PIC32 logó, PolarFire, Prochip Designer, QTouch, SAM-BA, SenGenuity, SpyNIC, SST, SST logó, SupercomFlash, Symmetri , SyncServer, Tachyon, TimeSource, tinyAVR, UNI/O, Vectron és XMEGA a Microchip Technology Incorporated bejegyzett védjegyei az Egyesült Államokban és más országokban.

AgileSwitch, ClockWorks, The Embedded Control Solutions Company, EtherSynch, Flashtec, Hyper Speed Control, HyperLight Load, Libero, motorpad, mTouch, Powermite 3, Precision Edge, ProASIC, ProASIC Plus, ProASIC Plus logó, Quiet-Wire, SmartWFusion, SyncWorld, , TimeCesium, TimeHub, TimePictra, TimeProvider és ZL a Microchip Technology Incorporated bejegyzett védjegyei az Egyesült Államokban

Szomszédos kulcsok elnyomása, AKS, analóg a digitális korhoz, bármilyen kondenzátor, AnyIn, AnyOut, kiterjesztett kapcsolás, BlueSky, BodyCom, Clockstudio, CodeGuard, CryptoAuthentication, CryptoAutomotive, CryptoCompanion, CryptoController, A Dynamics, ADP-CDEM, ddds. , DAM, ECAN, Espresso T1S, EtherGREEN, EyeOpen, GridTime, IdealBridge,
IGaT, In-Circuit soros programozás, ICSP, INICnet, Intelligens párhuzamosítás, IntelliMOS, Inter-Chip Connectivity, JitterBlocker, Knob-on-Display, MarginLink, maxCrypto, max.View, memBrain, Mindi, MiWi, MPASM, MPF, MPLAB Certified logó, MPLIB, MPLINK, mSiC, MultiTRAK, NetDetach, Mindentudó kódgenerálás, PICDEM, PICDEM.net, PICkit, PICtail, Power MOS IV, Power MOS 7, PureS PowerSmart, , QMatrix, REAL ICE, Ripple Blocker, RTAX, RTG4, SAM-ICE, Soros Quad I/O, egyszerű térkép, SimpliPHY, SmartBuffer, SmartHLS, SMART-IS, storClad, SQI, SuperSwitcher, SuperSwitcher II, Switchtec, SynchroPHY, Total Endurance, Trusted Time, TSHARC, Turing, USBCheck, VariSense, VectorBlox, VeriPHY, ViewA Span, WiperLock, XpressConnect és ZENA a Microchip Technology Incorporated védjegyei az Egyesült Államokban és más országokban.

Az SQTP a Microchip Technology Incorporated szolgáltatási védjegye az Egyesült Államokban
Az Adaptec logó, a Frequency on Demand, a Silicon Storage Technology és a Symmcom a Microchip Technology Inc. bejegyzett védjegyei más országokban.
A GestIC a Microchip Technology Germany II GmbH & Co. KG, a Microchip Technology Inc. leányvállalatának más országokban bejegyzett védjegye.

ISBN: 978-1-6683-4890-1

Minőségirányítási rendszer
A Microchip minőségirányítási rendszereivel kapcsolatos információkért látogasson el a weboldalra www.microchip.com/quality.

Értékesítés és szerviz világszerte

AMERIKA

ÁZSIA/CSENDES-óceáni térség

EURÓPA

Társasági Hivatal

2355 West Chandler Blvd. Chandler, AZ 85224-6199

Tel: 480-792-7200

Fax: 480-792-7277

Technikai támogatás: www.microchip.com/support

Web Cím: 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

Ausztrália – Sydney

Tel: 61-2-9868-6733

Kína – Peking

Tel: 86-10-8569-7000

Kína – Csengdu

Tel: 86-28-8665-5511

Kína – Chongqing

Tel: 86-23-8980-9588

Kína – Dongguan

Tel: 86-769-8702-9880

Kína – Kanton

Tel: 86-20-8755-8029

Kína – Hangzhou

Tel: 86-571-8792-8115

Kína – Hong Kong SAR

Tel: 852-2943-5100

Kína – Nanjing

Tel: 86-25-8473-2460

Kína – Qingdao

Tel: 86-532-8502-7355

Kína – Sanghaj

Tel: 86-21-3326-8000

Kína – Shenyang

Tel: 86-24-2334-2829

Kína – Sencsen

Tel: 86-755-8864-2200

Kína – Suzhou

Tel: 86-186-6233-1526

Kína – Vuhan

Tel: 86-27-5980-5300

Kína – Xian

Tel: 86-29-8833-7252

Kína – Xiamen

Tel: 86-592-2388138

Kína – Zhuhai

Tel: 86-756-3210040

India – Bangalore

Tel: 91-80-3090-4444

India – Újdelhi

Tel: 91-11-4160-8631

India – Pune

Tel: 91-20-4121-0141

Japán – Osaka

Tel: 81-6-6152-7160

Japán – Tokió

Tel: 81-3-6880-3770

Korea – Daegu

Tel: 82-53-744-4301

Korea – Szöul

Tel: 82-2-554-7200

Malajzia – Kuala Lumpur

Tel: 60-3-7651-7906

Malajzia – Penang

Tel: 60-4-227-8870

Fülöp-szigetek – Manila

Tel: 63-2-634-9065

Szingapúr

Tel: 65-6334-8870

Tajvan – Hsin Chu

Tel: 886-3-577-8366

Tajvan – Kaohsiung

Tel: 886-7-213-7830

Tajvan – Tajpej

Tel: 886-2-2508-8600

Thaiföld – Bangkok

Tel: 66-2-694-1351

Vietnam – Ho Si Minh

Tel: 84-28-5448-2100

Ausztria – Wels

Tel: 43-7242-2244-39

Fax: 43-7242-2244-393

Dánia – Koppenhága

Tel: 45-4485-5910

Fax: 45-4485-2829

Finnország – Espoo

Tel: 358-9-4520-820

Franciaország – Párizs

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

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

Németország – garching

Tel: 49-8931-9700

Németország – Haan

Tel: 49-2129-3766400

Németország – Heilbronn

Tel: 49-7131-72400

Németország – Karlsruhe

Tel: 49-721-625370

Németország – München

Tel: 49-89-627-144-0

Fax: 49-89-627-144-44

Németország – Rosenheim

Tel: 49-8031-354-560

Izrael – Hod Hasaron

Tel: 972-9-775-5100

Olaszország – Milánó

Tel: 39-0331-742611

Fax: 39-0331-466781

Olaszország – Padova

Tel: 39-049-7625286

Hollandia – Drunen

Tel: 31-416-690399

Fax: 31-416-690340

Norvégia – Trondheim

Tel: 47-72884388

Lengyelország – Varsó

Tel: 48-22-3325737

Románia – Bukarest

Tel: 40-21-407-87-50

Spanyolország – Madrid

Tel: 34-91-708-08-90

Fax: 34-91-708-08-91

Svédország – Göteborg

Tel: 46-31-704-60-40

Svédország – Stockholm

Tel: 46-8-5090-4654

Egyesült Királyság – Wokingham

Tel: 44-118-921-5800

Fax: 44-118-921-5820

Dokumentumok / Források

MICROCHIP PIC64GX 64 bites RISC-V négymagos mikroprocesszor [pdf] Felhasználói útmutató
PIC64GX, PIC64GX 64 bites RISC-V négymagos mikroprocesszor, 64 bites RISC-V négymagos mikroprocesszor, RISC-V négymagos mikroprocesszor, négymagos mikroprocesszor, mikroprocesszor

Hivatkozások

Felhasználói kézikönyv

MICROCHIP PIC64GX 64 bites RISC-V négymagos mikroprocesszor

Termékinformáció

A termék használati útmutatója