Udhëzues përdorimi i mikroprocesorit me katër bërthama MICROCHIP PIC64GX 64-bit RISC-V

Procesi i nisjes
1. Komponentët e softuerit të përfshirë në nisje
  Procesi i nisjes së sistemit përfshin komponentët e mëposhtëm të softuerit:
  - Hart Software Services (HSS): Një zero-stagngarkues i nisjes, monitor i sistemit dhe ofrues i shërbimeve të kohës së funksionimit për aplikacionet.
2. Boot Flow
  Sekuenca e rrjedhës së nisjes së sistemit është si më poshtë:
  1. Inicializimi i Shërbimeve Hart Software (HSS)
  2. Ekzekutimi i ngarkuesit
  3. Fillimi i aplikacionit
Rojet
1. PIC64GX Watchdog
  PIC64GX përmban një funksion mbikëqyrës për të monitoruar funksionimin e sistemit dhe për të shkaktuar veprime në rast të dështimeve të sistemit.
Modaliteti i bllokimit
Modaliteti i bllokimit është krijuar për klientët që kërkojnë kontroll të plotë mbi veprimet e sistemit pas nisjes. Ai kufizon funksionalitetet e monitorit të sistemit E51.

FAQ

Pyetje: Cili është qëllimi i Shërbimeve Softuerike Hart (HSS)?
Përgjigje: HSS shërben si zero-stagngarkues i nisjes, monitor i sistemit dhe ofrues i shërbimeve të kohës së funksionimit për aplikacionet gjatë procesit të nisjes.
Pyetje: Si funksionon funksioni mbikëqyrës PIC64GX?
A: Mbikëqyrësi PIC64GX monitoron funksionimin e sistemit dhe mund të ndërmarrë veprime të paracaktuara në rast të dështimeve të sistemit për të siguruar besueshmërinë e sistemit.

Hyrje

Kjo letër e bardhë shpjegon se si Microchip PIC64GX nis ngarkesat e punës së aplikacionit dhe përshkruan procesin e nisjes së sistemit, i cili funksionon njësoj për SMP dhe AMP ngarkesat e punës. Për më tepër, ai mbulon se si funksionon një rindezje për SMP dhe AMP ngarkesat e punës, rojet në PIC64GX dhe një modalitet i veçantë bllokimi për sistemet ku klientët dëshirojnë kontroll të plotë për të kufizuar veprimet e monitorit të sistemit E51 pas nisjes së sistemit.

Procesi i nisjes

Le të hedhim një vështrim në komponentët e ndryshëm të softuerit të përfshirë në nisjen e sistemit, të ndjekur nga një vështrim më i detajuar në sekuencën e vetë rrjedhës së nisjes së sistemit.

Komponentët e softuerit të përfshirë në nisje
Komponentët e mëposhtëm përfshihen në procesin e nisjes së sistemit:

Figura 1.1. Komponentët e nisjes

Shërbimet softuerike Hart (HSS)
Shërbimet Softuerike Hart (HSS) janë zero-stage ngarkues i nisjes, një monitor sistemi dhe një ofrues i shërbimeve të kohës së funksionimit për aplikacionet. HSS mbështet konfigurimin e hershëm të sistemit, trajnimin DDR dhe inicializimin/konfigurimin e harduerit. Kryesisht funksionon në E51s, me një sasi të vogël funksionaliteti të nivelit të modalitetit të makinës që funksionon në çdo U54. Nis një ose më shumë kontekste duke ngarkuar "payload" të aplikacionit nga mediumi i nisjes dhe ofron Shërbimet e Platformës Runtime/Mjedisin e Ekzekutimit të Mbikëqyrësit (SEE) për kernelët e sistemit operativ. Ai mbështet nisjen e sigurt dhe është një komponent i rëndësishëm në sigurimin e ndarjes/ndarjes së harduerit për AMP kontekstet.

Das U-Boot (U-Boot)
Das U-Boot (U-Boot) është një ngarkues universal me skriptim me burim të hapur. Ai mbështet një CLI të thjeshtë që mund të marrë imazhin e nisjes nga një shumëllojshmëri burimesh (duke përfshirë një kartë SD dhe Rrjetin). U-Boot ngarkon Linux. Mund të sigurojë një mjedis UEFI nëse është e nevojshme. Në përgjithësi, ai përfundon dhe nuk funksionon pasi Linux të jetë nisur - me fjalë të tjera, ai nuk qëndron rezident pas nisjes.
Kernel Linux
Kerneli Linux është kerneli më i popullarizuar i sistemit operativ në botë. I kombinuar me një tokë përdoruesi të aplikacioneve, ai formon atë që zakonisht quhet një sistem operativ Linux. Një Sistem Operativ Linux ofron API të pasura POSIX dhe mjedis zhvilluesish, p.shample, gjuhë dhe mjete të tilla si Python, Perl, Tcl, Rust, C/C++ dhe Tcl; bibliotekat si OpenSSL, OpenCV, OpenMP, OPC/UA dhe OpenAMP (RPmsg dhe RemoteProc).
Yocto dhe Buildroot janë ndërtues të sistemit Linux, domethënë, ato mund të përdoren për të gjeneruar sisteme Linux të personalizuara me porosi. Yocto nxjerr një shpërndarje Linux me një të pasur
grup aplikacionesh, veglash dhe bibliotekash dhe menaxhimi opsional i paketave. Buildroot nxjerr një rrënjë më minimale filesistem dhe mund të synojë sisteme që nuk kërkojnë ruajtje të vazhdueshme, por funksionojnë tërësisht nga RAM (duke përdorur mbështetjen e inicialeve të Linux, p.sh.ample).

Zefiri
Zephyr është një sistem operativ i vogël, me burim të hapur në kohë reale (RTOS). Ai siguron një kornizë në kohë reale me kosto të ulët, me kanale komunikimi RPMsg-lite në Linux. Ai përfshin një kernel, biblioteka, drejtues pajisjesh, pirgje protokolli, filesistemet, mekanizmat për përditësimet e firmuerit, e kështu me radhë, dhe është e shkëlqyeshme për klientët që dëshirojnë një përvojë më të ngjashme me metalin e zhveshur në PIC64GX.

Boot Flow
PIC64GX përfshin një koreplex RISC-V me një hart monitorues të sistemit E64 51-bit dhe 4 harta aplikacioni U64 54-bit. Në terminologjinë RISC-V, një hart është një kontekst ekzekutimi RISC-V që përmban një grup të plotë regjistrash dhe që ekzekuton kodin e tij në mënyrë të pavarur. Ju mund ta mendoni atë si një fije harduerike ose një CPU të vetme. Një grup zemrash brenda një bërthame të vetme shpesh quhet kompleks. Kjo temë përshkruan hapat për të inicializuar koreplexin PIC64GX, duke përfshirë sistemin E51 të monitorimit të zemrës dhe hartat e aplikacionit U54.

Aktivizoni coreplex PIC64GX.
Në momentin e ndezjes, të gjitha hartat në koreplexin RISC-V çlirohen nga rivendosja nga Kontrolluesi i Sigurisë.
Ekzekutoni kodin HSS nga memoria flash eNVM në çip.
Fillimisht, çdo zemër fillon të ekzekutojë kodin HSS nga memoria flash eNVM në çip. Ky kod bën që të gjithë hartat e aplikacionit U54 të rrotullohen, duke pritur për udhëzime dhe lejon që harta e monitorit E51 të fillojë të ekzekutojë kodin për të inicializuar dhe shfaqur sistemin.

Dekompresoni kodin HSS nga eNVM në memorie L2-Scratch.
Në varësi të konfigurimit të tij në kohën e ndërtimit, HSS zakonisht është më i madh se kapaciteti i vetë memories flash eNVM dhe kështu gjëja e parë që bën kodi HSS që funksionon në E51 është dekompozimi i vetvetes nga memoria eNVM në L2-Scratch, siç tregohet në figurë. 1.2 dhe Figura 1.3.
Figura 1.2. HSS Dekompreson nga eNVM në L2 Scratch
Figura 1.3. Harta e memories HSS gjatë dekompresimit
Kaloni nga eNVM në L2-Scratch në një ekzekutues siç tregohet në figurën e mëposhtme.
Figura 1.4. HSS kërcen nga eNVM në Code Now në L2Scratch Pas Dekompresimit
Ekzekutuesi përbëhet nga tre komponentë:
- Shtresa e abstraksionit të harduerit (HAL), kodi i nivelit të ulët dhe drejtuesit e metalit të zhveshur
- Një pirun lokal HSS i RISC-V OpenSBI (i modifikuar pak nga rrjedha e sipërme në PIC64GX për AMP qëllime)
- Shërbimet e kohës së funksionimit HSS (makinat e gjendjes funksionojnë në një lak super)
Inicializoni strukturat e harduerit dhe të të dhënave të përdorura nga OpenSBI.
Shërbimi HSS "Startup" është përgjegjës për këtë inicializim.

Merr imazhin e ngarkesës së punës së aplikacionit (payload.bin) nga ruajtja e jashtme. Kjo është paraqitur në Figurën 1.5 dhe Figura 1.6
E rëndësishme: Në rastin e PIC64GX Curiosity Kit, kjo do të jetë nga një kartë SD.
Figura 1.5. Po merr imazhin e ngarkesës payload.bin nga hapësira ruajtëse e jashtme
Figura 1.6. Harta e memories HSS pas marrjes së payload.bin
Kopjoni seksionet e ndryshme nga payload.bin në destinacionet e tyre të kohës së ekzekutimit. Payload.bin është një imazh i formatuar, i cili konsolidon imazhe të ndryshme aplikacioni për SMP ose AMP ngarkesat e punës. Ai përfshin kodin, të dhënat dhe tabelat e përshkruesve të cilat i mundësojnë HSS të vendosë në mënyrë të përshtatshme seksionet e kodit dhe të të dhënave, ku ato nevojiten për të ekzekutuar ngarkesat e ndryshme të punës së aplikacionit.
Figura 1.7. payload.bin kopjohet në adresat e destinacionit

Udhëzoni U54-të përkatës të hidhen në adresat e tyre të fillimit të ekzekutimit. Ky informacion i adresës së fillimit gjendet në payload.bin.
Filloni hartat e aplikacionit U54 dhe çdo sekondëtage ngarkuesit e nisjes. Për shembullampLe, U-Boot sjell Linux.

Rindizni

E lidhur me konceptin e nisjes së sistemit është nevoja për rindezje. Kur mendoni për ngarkesat e punës së aplikacionit PIC64GX, rindezja duhet të marrë në konsideratë si shumëpërpunimin simetrik (SMP) ashtu edhe shumëpërpunimin asimetrik (AMP) skenarët:

Në rastin e një sistemi SMP, një rindezje mund të rindizet në mënyrë të sigurtë të gjithë sistemin pasi nuk ka ngarkesa shtesë pune në një kontekst tjetër për t'u marrë parasysh.

Në rastin e një AMP sistemi, një ngarkesë pune mund të lejohet vetëm të rindizet vetë (dhe të mos ndërhyjë në ndonjë kontekst tjetër), ose mund të jetë e privilegjuar të jetë në gjendje të kryejë një rindezje të plotë të sistemit.

Rinisni dhe AMP
Për të aktivizuar SMP dhe AMP Skenarët e rindezjes, HSS mbështet konceptet e privilegjeve të rindezjes së ngrohtë dhe të ftohtë, të cilat mund të caktohen në një kontekst. Një kontekst me privilegjin e rindezjes së ngrohtë mund të rindizet vetëm vetë, dhe një kontekst me privilegj të rindezjes së ftohtë mund të kryejë një rindezje të plotë të sistemit. Për shembullample, merrni parasysh grupin e mëposhtëm të skenarëve përfaqësues.

Një ngarkesë pune SMP me kontekst të vetëm, e cila lejohet të kërkojë një rindezje të plotë të sistemit
Në këtë skenar, kontekstit i lejohet privilegji i rindezjes së ftohtë.
Një me dy kontekste AMP ngarkesa e punës, ku konteksti A lejohet të kërkojë një rindezje të plotë të sistemit (duke prekur të gjitha kontekstet), dhe Konteksti B lejohet të rindizet vetëm vetë
Në këtë skenar, konteksti A lejohet privilegji i rindezjes së ftohtë dhe konteksti B lejohet privilegji i rindezjes së ngrohtë.
Një me dy kontekste AMP ngarkesa e punës, ku kontekstet A dhe B lejohen vetëm të rinisin vetë (dhe të mos ndikojnë në kontekstin tjetër)
Në këtë skenar, të dy kontekstet lejohen vetëm të privilegjet e rindezjes së ngrohtë.
Një me dy kontekste AMP ngarkesa e punës, ku kontekstet A dhe B lejohen të kërkojnë rinisje të plotë të sistemit
Në këtë skenar, të dy kontekstet lejohen të privilegjet e rindezjes së ftohtë.
Për më tepër, është e mundur që HSS në kohën e ndërtimit të lejojë gjithmonë privilegjin e rindezjes së ftohtë dhe të mos lejojë kurrë privilegjin e rindezjes së ftohtë.

Opsionet përkatëse të HSS Kconfig
Kconfig është një sistem konfigurimi i softuerit. Zakonisht përdoret për të zgjedhur opsionet e kohës së ndërtimit dhe për të aktivizuar ose çaktivizuar veçoritë. Filloi me kernelin Linux, por tani ka gjetur përdorim në projekte të tjera përtej kernelit Linux, duke përfshirë U-Boot, Zephyr dhe PIC64GX HSS.

HSS përmban dy opsione Kconfig që kontrollojnë funksionalitetin e rindezjes nga perspektiva HSS:

CONFIG_ALLOW_COLD RINDIZIM
Nëse kjo është e aktivizuar, ajo lejon globalisht një kontekst të lëshojë një thirrje për rindezje të ftohtë. Nëse çaktivizohet, do të lejohen vetëm rindezjet e ngrohta. Përveç aktivizimit të këtij opsioni, leja për të lëshuar një rindezje të ftohtë duhet t'i jepet një konteksti përmes gjeneratorit të ngarkesës YAML file ose opsionin e mëposhtëm Kconfig.
CONFIG_ALLOW_FTOH RIBOOT_GJITHMONË
- Nëse aktivizohet, kjo veçori globalisht i lejon të gjitha kontekstet të lëshojnë një ECAA rindezjeje të ftohtë, pavarësisht nga të drejtat e flamurit payload.bin.
- Për më tepër, vetë payload.bin mund të përmbajë një flamur për kontekst, duke treguar se një kontekst i veçantë ka të drejtë të lëshojë rindezje të ftohta:
  - Për të lejuar një rindezje të ngrohtë të kontekstit një kontekst tjetër, mund të shtojmë opsionin lejoj-reboot: ngrohtë në përshkrimin YAML file përdoret për të krijuar payload.bin
  - Për të lejuar një rindezje të ftohtë në kontekst të të gjithë sistemit, mund të shtojmë opsionin lejoj-rindez: ftohtë. Si parazgjedhje, pa specifikuar leje-rindezjen, një kontekst lejohet vetëm vetë rindezja e ngrohtë Pavarësisht nga cilësimi i këtij flamuri, nëse CONFIG_ALLOW_COLDREBOOT nuk është i aktivizuar në HSS, HSS do të ripunojë të gjitha kërkesat e rindezjes së ftohtë për rindezje të ngrohta (për kontekst). .

Rinisni në detaje
Ky seksion përshkruan në detaje se si funksionon rindezja - duke filluar me shtresën OpenSBI (shtresa më e ulët e modalitetit M) dhe më pas duke diskutuar se si ky funksionalitet i shtresës OpenSBI aktivizohet nga një aplikacion RTOS ose një OS i pasur si Linux.

OpenSBI Reboot ecall

Specifikimi i Ndërfaqes Binare të Mbikëqyrësit RISC-V (SBI) përshkruan një shtresë të standardizuar të abstraksionit të harduerit për inicializimin e platformës dhe shërbimet e funksionimit të firmuerit. Qëllimi kryesor i SBI është të mundësojë transportueshmëri dhe përputhshmëri në zbatime të ndryshme RISC-V.
OpenSBI (Open Source Supervisor Binary Interface) është një projekt me burim të hapur që ofron një zbatim referimi të specifikimeve SBI. OpenSBI ofron gjithashtu shërbime të kohës së funksionimit, duke përfshirë trajtimin e ndërprerjeve, menaxhimin e kohëmatësit dhe hyrjen/daljen e konsolës, të cilat mund të përdoren nga shtresat e softuerit të nivelit më të lartë.
OpenSBI përfshihet si pjesë e HSS dhe funksionon në nivelin e Makinerisë. Kur sistemi operativ ose aplikacioni shkakton një kurth, ai do t'i kalohet OpenSBI për ta trajtuar atë. OpenSBI ekspozon një funksionalitet të caktuar të llojit të thirrjes së sistemit në shtresat e sipërme të softuerit përmes një mekanizmi të veçantë kurthi të quajtur ecall.

Rivendosja e sistemit (EID 0x53525354) ofron një funksion gjithëpërfshirës të thirrjes së sistemit që lejon softuerin e shtresës së sipërme të kërkojë rindezjen ose mbylljen e nivelit të sistemit. Pasi kjo thirrje thirret nga një U54, ajo bllokohet nga softueri HSS që funksionon në modalitetin e makinës në atë U54 dhe një kërkesë përkatëse për rindezje i dërgohet E51 për të rindezur ose kontekstin ose të gjithë sistemin, në varësi të të drejtave të kontekst.

Për më shumë informacion, shihni Specifikimi i ndërfaqes binare të mbikëqyrësit RISC-V veçanërisht Shtesa e rivendosjes së sistemit (EID #0x53525354 "SRST").

Rinisja e Linux

Si një ish specifikampNga kjo, në Linux, komanda shutdown përdoret për të ndalur ose rindezur sistemin. Komanda zakonisht ka shumë pseudonime, përkatësisht ndalimin, fikjen dhe rindezjen. Këto pseudonime përcaktojnë nëse do të ndalet makineria në mbyllje, për të fikur pajisjen në mbyllje ose për të rindezur pajisjen në mbyllje.

Këto komanda të hapësirës së përdoruesit lëshojnë një thirrje të sistemit të rindezjes në Linux, i cili bllokohet nga kerneli dhe ndërvepron në një thirrje SBI.
Ekzistojnë nivele të ndryshme të rindezjes - REBOOT_WARM, REBOOT_COLD, REBOOT_HARD - këto mund të kalojnë si argumente të linjës së komandës në kernel (për shembullample, reboot=w[arm] për REBOOT_WARM). Për më shumë informacion mbi kodin burimor të kernelit Linux, shihni Documentation/admin-guide/kernel-paramters.txt.
Përndryshe, nëse /sys/kernel/reboot është i aktivizuar, mbajtësit poshtë mund të lexohen për të marrë konfigurimin aktual të rindezjes së sistemit dhe të shkruhen për ta ndryshuar atë. Për më shumë informacion mbi kodin burimor të kernelit Linux, shihni Dokumentacioni/ABI/testimi/sysfs-kernel-reboot.

Rojet

Një koncept i mëtejshëm që lidhet me nisjen e sistemit dhe rindezjen e sistemit është ai i rikuperimit të sistemit pas ndezjes së një timer roje. Kohëmatësit Watchdog përdoren gjerësisht në sistemet e integruara për të rikuperuar automatikisht nga gabimet kalimtare të harduerit dhe për të parandaluar që softueri i gabuar ose keqdashës të prishë funksionimin e sistemit.
PIC64GX përfshin mbështetjen e mbikëqyrësit të harduerit për të monitoruar kartë individuale kur sistemi është në punë. Mbikëqyrësit sigurojnë që hartat mund të rifillojnë nëse nuk përgjigjen për shkak të gabimeve të softuerit të pariparueshëm.
PIC64GX përfshin pesë raste të blloqeve harduerike të kohëmatësit mbikëqyrës të përdorur për të zbuluar bllokimet e sistemit - një për secilin prej hartave. Për të lehtësuar shumëpërpunimin asimetrik të përzier (AMP) ngarkesat e punës, HSS mbështet monitorimin dhe reagimin ndaj gjuajtjes së rojeve.

PIC64GX Watchdog

HSS është përgjegjëse për nisjen e hartave të aplikacionit gjatë ndezjes dhe për rinisjen e tyre (individualisht ose kolektivisht) në çdo momenttage, nëse është e nevojshme apo e dëshiruar. Si pasojë e kësaj, reagimi ndaj ngjarjeve të vëzhguesve në PIC64GX trajtohet nga HSS.
Një monitor 'mbrojtës virtual' zbatohet si një shërbim makinerie shtetërore HSS dhe përgjegjësitë e tij janë të monitorojë statusin e secilit prej monitorëve të harduerit individual të vëzhguesit U54. Kur një nga këta vëzhgues U54 udhëton, HSS e zbulon këtë dhe do të rindez U54 sipas rastit. Nëse U54 është pjesë e një konteksti SMP, i gjithë konteksti konsiderohet për rindezje, duke pasur parasysh se konteksti ka privilegjin e rindezjes së ngrohtë. I gjithë sistemi do të rindizet nëse konteksti ka privilegjin e rindezjes së ftohtë.

Opsionet përkatëse të Kconfig

Mbështetja Watchdog përfshihet si parazgjedhje në ndërtimet e lëshuara HSS. Nëse dëshironi të ndërtoni një HSS të personalizuar, ky seksion do të përshkruajë mekanizmin e konfigurimit për të siguruar që mbështetja e Watchdog është e aktivizuar.

HSS është konfiguruar duke përdorur sistemin e konfigurimit Kconfig. Një nivel i lartë .config file është e nevojshme për të zgjedhur se cilat shërbime do të përpilohen brenda ose jashtë ndërtimit të HSS.
Së pari, opsioni i nivelit të lartë CONFIG_SERVICE_WDOG duhet të aktivizohet ("Mbështetje Virtual Watchdog" përmes make config).

Kjo më pas ekspozon nën-opsionet e mëposhtme të cilat varen nga mbështetja e Watchdog:

CONFIG_SERVICE_WD OG_DEBUG
Aktivizon mbështetjen për mesazhet informative/debuguese nga shërbimi virtual i mbikëqyrësit.
CONFIG_SERVICE_WD OG_DEBUG_TIMEOUT_SECS
Përcakton periodicitetin (në sekonda) që mesazhet e korrigjimit të Watchdog do të dalin nga HSS.
CONFIG_SERVICE_WD OG_ENABLE_E51
Aktivizon vëzhguesin për zemrën e monitorit E51 përveç U54, duke mbrojtur funksionimin e vetë HSS.

Kur monitoruesi E51 është i aktivizuar, HSS do t'i shkruajë periodikisht Watchdog-it për ta rifreskuar atë dhe për të parandaluar ndezjen e tij. Nëse, për ndonjë arsye, zemra E51 bllokohet ose rrëzohet dhe monitoruesi E51 është i aktivizuar, kjo do të rivendosë gjithmonë të gjithë sistemin.

Operacioni Mbrojtës
Pajisja e mbikëqyrësit zbaton sportelet poshtë. Një dritare e ndaluar nga rifreskimi mund të krijohet duke konfiguruar vlerën maksimale të vëzhguesit deri në të cilën lejohet rifreskimi (MVRP).

Kur vlera aktuale e kohëmatësit të rojës është më e madhe se vlera MVRP, rifreskimi i rojës është i ndaluar. Përpjekja për të rifreskuar kohëmatësin rojtar në dritaren e ndaluar do të konfirmojë një ndërprerje të skadimit.

Rifreskimi i rojes midis vlerës MVRP dhe vlerës së këmbëzimit (TRIG) do të rifreskojë me sukses numëruesin dhe do të parandalojë ndezjen e rojës.
Sapo vlera e kohëmatësit të rojës të llogaritet nën vlerën TRIG, monitoruesi do të shkrepë.

Makina Shtetërore Mbikëqyrëse

Makina e gjendjes së mbikëqyrjes është shumë e drejtpërdrejtë - fillon duke konfiguruar mbikëqyrësin për E51, nëse është i aktivizuar, pastaj kalon përmes një gjendjeje joaktive në monitorim. Çdo herë rreth superloop-it, thirret kjo gjendje monitorimi, e cila kontrollon statusin e secilit prej vëzhguesve U54.

Makina e gjendjes mbikëqyrëse ndërvepron me makinën e gjendjes së nisjes për të rindezur një hart (dhe çdo hart tjetër që është në grupin e tij të nisjes), nëse zbulon se harta nuk ka arritur të rifreskojë në kohë monitorin e tij.

Modaliteti i bllokimit

Normalisht (sidomos me AMP aplikacionet), pritet që HSS të qëndrojë rezident në modalitetin M, në një U54, për të lejuar rindezjen sipas kontekstit (dmth. rindezni vetëm një kontekst, pa rindezje të plotë të çipit) dhe për të lejuar HSS të monitorojë shëndetin ( ECC-të, Bitet e statusit të kyçjes, gabimet e autobusit, gabimet e SBI, shkeljet e PMP, etj).

Për të ofruar aftësi të rindezjes në njëAMP bazën e kontekstit (pa kërkuar që i gjithë sistemi të rindizet), E51 normalisht ka akses të privilegjuar të memories në të gjithë hapësirën e memories së sistemit. Megjithatë, mund të ketë situata ku kjo nuk është e dëshirueshme dhe klienti mund të preferojë të kufizojë atë që bën firmware E51 HSS pasi sistemi të jetë nisur me sukses. Në këtë rast, është e mundur të vendosni HSS në modalitetin e bllokimit pasi të jenë nisur U54 Application Harts.

Kjo mund të aktivizohet duke përdorur opsionin HSS Kconfig CONFIG_SERVICE_LOCKDOWN.
Shërbimi i bllokimit ka për qëllim të lejojë kufizimin e aktiviteteve të HSS pasi të nisë aplikacionin U54 Harts.

Figura 4.2. Modaliteti i mbylljes HSS

Pasi të fillojë modaliteti i bllokimit, ai ndalon funksionimin e të gjitha makinerive të tjera të gjendjes së shërbimit HSS. Ai thërret dy funksione të lidhura dobët:

e51_pmp_lockdown(), dhe
e51_lockdown()

Këto funksione synohen të anashkalohen nga kodi specifik i bordit. E para është një funksion aktivizues i konfigurueshëm për të lejuar një BSP të personalizojë mbylljen e E51 nga ngarkesat e aplikacionit në këtë pikë. Implementimi i paracaktuar me lidhje të dobët i këtij funksioni është bosh. E dyta është funksionaliteti që drejtohet nga ajo pikë e tutje. Implementimi i parazgjedhur me lidhje të dobët i shërben mbikëqyrësit në këtë pikë në E51 dhe do të rindizet nëse ndizet një mbikëqyrës U54. Për më shumë informacion, shihni kodin burimor HSS në shërbimet/lockdown/lockdown_service.c file.

Shtojca

Formati HSS payload.bin

Ky seksion përshkruan payload.bin file formatin dhe imazhin e përdorur nga HSS për të nisur PIC64GX SMP dhe AMP aplikacionet.
Payload.bin është një binar i formatuar (Figura A.10) i përbërë nga një kokë, tabela të ndryshme përshkruesish dhe pjesë të ndryshme që përmbajnë kodin dhe seksionet e të dhënave të secilës pjesë të ngarkesës së punës së aplikacionit. Një copë mund të konsiderohet si një bllok i vazhdueshëm i kujtesës me madhësi arbitrare.

Figura A.10. payload.bin Format

Pjesa e kokës (treguar në figurën A.11) përmban një vlerë magjike të përdorur për të identifikuar payload.bin dhe disa informacione për mbajtjen e shtëpisë, së bashku me detajet e imazhit që synohet të ekzekutohet në secilën prej
Kodet e aplikimit U54. Ai përshkruan se si të nisni çdo hart individual U54 dhe grupin e imazheve të bootable në përgjithësi. Në informacionin e tij të mbajtjes së shtëpisë, ai ka tregues për tabela të ndryshme të përshkruesve për të lejuar rritjen e madhësisë së kokës.

Figura A.11. ngarkesa.koka e koshit

Kodi dhe të dhënat konstante të inicializuara konsiderohen vetëm për lexim dhe ruhen në një seksion vetëm për lexim, i cili tregohet nga përshkruesit e kokës.
Variablat e të dhënave të inicializuara jo-zero janë të dhëna shkrim-leximi, por vlerat e tyre të inicializimit kopjohen nga pjesa vetëm për lexim në fillim. Këto ruhen gjithashtu në seksionin vetëm për lexim.

Seksioni i të dhënave të ngarkesës vetëm për lexim përshkruhet nga një tabelë e kodit dhe përshkruesve të pjesëve të të dhënave. Çdo përshkrues i pjesës në këtë tabelë përmban një 'pronar të hart' (hart kryesor në kontekstin që synohet
në), një kompensim ngarkese (kompensimi brenda payload.bin) dhe një adresë ekzekutimi (adresa e destinacionit në memorien PIC64GX), së bashku me një madhësi dhe shumë kontrolli. Kjo është paraqitur në figurën A.12.

Figura A.12. Përshkruesi i pjesëve vetëm për lexim dhe të dhënat e pjesëve të ngarkesës

Përveç pjesëve të lartpërmendura, ka edhe pjesë të memories që korrespondojnë me variablat e të dhënave që janë inicializuar në zero. Këto nuk ruhen si të dhëna në payload.bin, por në vend të kësaj janë një grup i veçantë përshkruesish të pjesëve të inicializuara zero, të cilët specifikojnë adresën dhe gjatësinë e RAM-it për t'u vendosur në zero gjatë nisjes. Kjo është paraqitur në figurën A.13.

Figura A.13. Copa ZI

hss-payload-generator
Mjeti i gjeneratorit të ngarkesës HSS krijon një imazh të formatuar të ngarkesës për shërbimin softuer Hart zero-stage bootloader në PIC64GX, duke pasur një konfigurim file dhe një grup ELF files dhe/ose binare. Konfigurimi file përdoret për të hartuar binarët ELF ose blobs binare në hartat individuale të aplikacionit (U54s).

Figura B.14. hss-payload-generator Flow

Mjeti kryen kontrolle bazë të shëndetit në strukturën e konfigurimit file vetë dhe në imazhet ELF. Imazhet ELF duhet të jenë të ekzekutueshme RISC-V.

Example Run

Për të ekzekutuar veglën hss-payload-generator me sampkonfigurimin le file dhe ELF files:
$ ./hss-payload-generator -c test/config.yaml output.bin
Për të printuar diagnostifikimin rreth një imazhi para-ekzistues, përdorni:
$ ./hss-payload-generator -d output.bin

Për të mundësuar vërtetimin e sigurt të nisjes (nëpërmjet nënshkrimit të imazhit), përdorni -p për të specifikuar vendndodhjen e një çelësi privat X.509 për Kurbën Elliptike P-384 (SECP384r1):
$ ./hss-payload-generator -c test/config.yaml payload.bin -p /path/to/private.pem

Për më shumë informacion, shihni dokumentacionin e Autentifikimit të Sigurt Boot.

Konfigurimi File Example

Së pari, ne mund të vendosim opsionalisht një emër për imazhin tonë, përndryshe, një do të krijohet në mënyrë dinamike:
emri i grupit: 'PIC64-HSS::TestImage'
Më pas, ne do të përcaktojmë adresat e pikave të hyrjes për secilën zemër, si më poshtë:
hart-entry-points: {u54_1: ‘0x80200000’, u54_2: ‘0x80200000’, u54_3: ‘0xB0000000′, u54_4:’0x80200000’}

Imazhet e burimit ELF mund të specifikojnë një pikë hyrjeje, por ne duam të jemi në gjendje të mbështesim pikat e hyrjes dytësore për hartat nëse është e nevojshme, p.sh.ampMegjithatë, nëse harta të shumta synojnë të nisin të njëjtin imazh, ato mund të kenë pika hyrëse individuale. Për ta mbështetur këtë, ne specifikojmë adresat aktuale të pikave të hyrjes në konfigurim file vetë.

Tani mund të përcaktojmë disa ngarkesa (burimi ELF files, ose blobs binare) që do të vendosen në rajone të caktuara në memorie. Seksioni i ngarkesës përcaktohet me fjalën kyçe payloads, dhe më pas një numër përshkruesish individualë të ngarkesës. Çdo ngarkesë ka një emër (rruga drejt saj file), një pronar-hart, dhe opsionalisht 1 deri në 3 hartë dytësore.

Për më tepër, një ngarkesë ka një modalitet privilegji në të cilin do të fillojë ekzekutimi. Mënyrat e vlefshme të privilegjit janë PRV_M, PRV_S dhe PRV_U, ku këto përcaktohen si:

Modaliteti i makinës PRV_M
PRV_S Modaliteti mbikëqyrës
PRV_U Modaliteti i përdoruesit

Në shembullin e mëposhtëmampe:

test/zephyr.elf supozohet të jetë një aplikacion Zephyr që funksionon në U54_3 dhe pret të fillojë në modalitetin e privilegjit PRV_M.
test/u-boot-dtb.bin është aplikacioni i ngarkuesit Das U-Boot dhe funksionon në U54_1, U54_2 dhe U54_4. Ai pret të fillojë në modalitetin e privilegjit PRV_S.

E rëndësishme:
Prodhimi i U-Boot krijon një ELF file, por në mënyrë tipike ajo nuk parashtron shtrirjen .elf. Në këtë rast, përdoret binar i krijuar nga CONFIG_OF_SEPARATE, i cili shton një njollë peme të pajisjes në binarin U-Boot.

Këtu është ishampkonfigurimin e ngarkesës file:

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

E rëndësishme:
Rasti ka rëndësi vetëm për file emrat e shtigjeve, jo fjalët kyçe. Pra, për shembull, u54_1 konsiderohet i njëjtë me U54_1, dhe exec-addr konsiderohet i njëjtë si EXEC-ADDR. Nëse ekziston shtrirja an.elf ose .bin, ajo duhet të përfshihet në konfigurim file.

Për një aplikacion metalik të zhveshur që nuk dëshiron të merret me OpenSBI, opsioni kapërce-hapet, nëse është i vërtetë, do të bëjë që ngarkesa në atë zemër të thirret duke përdorur një mret të thjeshtë.
sesa një thirrje OpenSBI sbi_init(). Kjo do të thotë se zemra do të fillojë të ekzekutojë kodin metalik të zhveshur, pavarësisht nga çdo konsideratë OpenSBI HSM. Vini re se kjo gjithashtu do të thotë se zemra nuk mund të përdorë
bën thirrje për të thirrur funksionalitetin OpenSBI. Opsioni kapërce-hap është opsional dhe është i paracaktuar në false.

Për të lejuar një rindezje të ngrohtë të kontekstit të një konteksti tjetër, mund të shtojmë opsionin lejoj rindezjen: ngrohtë. Për të lejuar një rindezje të ftohtë në kontekst të të gjithë sistemit, mund të shtojmë opsionin lejoj-rindez: ftohtë. Si parazgjedhje, pa specifikuar leje-rindezjen, një kontekst lejohet vetëm të ngrohë vetë rindezjen.
Është gjithashtu e mundur të lidhen të dhënat ndihmëse me çdo ngarkesë, për shembullample, një blob Device Tree (DTB) file, duke specifikuar të dhënat ndihmëse fileemri si më poshtë:
test/u-boot.bin: { exec-addr: '0x80200000', owner-hart: u54_1, secondary-hart: u54_2, secondary-hart: u54_3, secondary-hart: u54_4, priv-mode: prv_s, ancilliary-data : test/pic64gx.dtb }
Këto të dhëna ndihmëse do të përfshihen në ngarkesën (e vendosur menjëherë pas kryesore file në ekzekutuesin
hapësirë), dhe adresa e tij do t'i kalohet OpenSBI-së në fushën next_arg1 (e kaluar në regjistrin $a1 në imazh në kohën e nisjes).

Për të parandaluar që HSS të nis automatikisht një kontekst (për shembull, nëse në vend të kësaj duam ta delegojmë kontrollin e kësaj në një kontekst duke përdorur remoteProc), përdorni flamurin skip-autoboot:
test/zephyr.elf: {exec-addr: '0xB0000000', pronar-hart: u54_3, priv-mode: prv_m, skip-opensbi: true, skip-autoboot: true}
Më në fund, mund të anashkalojmë në mënyrë opsionale emrat e ngarkesave individuale, duke përdorur opsionin payload-name. Për shembullampe:
test/u-boot.bin: { exec-addr: '0x80200000', owner-hart: u54_1, secondary-hart: u54_2, secondary-hart: u54_3, secondary-hart: u54_4, priv-mode: prv_s, ancilliary-data : test/pic64gx.dtb, payload-name: 'u-boot' }

Vini re se ndërtuesit e Yocto dhe Buildroot Linux do të ndërtojnë, konfigurojnë dhe ekzekutojnë hss-payload-
gjenerator sipas nevojës për të gjeneruar imazhe të aplikacionit. Për më tepër, pic64gx-curiosity-kit-amp objektivi i makinës në Yocto do të gjenerojë një imazh aplikacioni duke përdorur mjetin e gjeneratorit të ngarkesës hss që demonstron AMP, me Linux që funksionon në 3 harts dhe Zephyr në 1 hart.

Historia e rishikimit
Historia e rishikimit përshkruan ndryshimet që janë zbatuar në dokument. Ndryshimet renditen me rishikim, duke filluar nga publikimi më aktual.

Rishikim	Data	Përshkrimi
A	07/2024	Rishikimi fillestar

Informacioni i mikroçipit

Mikroçipi Webfaqe
Microchip ofron mbështetje në internet nëpërmjet tonë webfaqe në www.microchip.com/. Kjo webfaqe përdoret për të bërë files dhe informacione lehtësisht të disponueshme për klientët. Disa nga përmbajtjet e disponueshme përfshijnë:

Mbështetja e produktit – Fletët e të dhënave dhe gabimet, shënimet e aplikimit dhe sampprogramet, burimet e dizajnit, udhëzuesit e përdoruesit dhe dokumentet mbështetëse të harduerit, versionet më të fundit të softuerit dhe softueri i arkivuar

Mbështetja e Përgjithshme Teknike – Pyetjet e bëra më shpesh (FAQ), kërkesat për mbështetje teknike, grupet e diskutimit në internet, listimi i anëtarëve të programit të partnerit të projektimit të mikroçipit
Biznesi i mikroçipit – Udhëzues për përzgjedhësin e produktit dhe porositje, njoftimet më të fundit për shtyp të Microchip, një listë seminaresh dhe ngjarjesh, listime të zyrave të shitjes së Microchip, shpërndarësve dhe përfaqësuesve të fabrikës

Shërbimi i njoftimit për ndryshimin e produktit

Shërbimi i njoftimit për ndryshimin e produktit të Microchip ndihmon për t'i mbajtur klientët aktualë në produktet Microchip. Abonentët do të marrin njoftim me email sa herë që ka ndryshime, përditësime, rishikime ose gabime në lidhje me një familje të caktuar produkti ose mjet zhvillimi me interes.

Për t'u regjistruar, shkoni te www.microchip.com/pcn dhe ndiqni udhëzimet e regjistrimit.

Mbështetja e klientit
Përdoruesit e produkteve Microchip mund të marrin ndihmë përmes disa kanaleve:

Distributor ose Përfaqësues
Zyra Lokale e Shitjeve
Inxhinier i zgjidhjeve të integruara (ESE)
Mbështetje Teknike

Konsumatorët duhet të kontaktojnë shpërndarësin, përfaqësuesin ose ESE-në e tyre për mbështetje. Zyrat lokale të shitjeve janë gjithashtu në dispozicion për të ndihmuar klientët. Një listë e zyrave të shitjeve dhe vendndodhjeve është përfshirë në këtë dokument.
Mbështetja teknike është në dispozicion përmes webfaqe në: www.microchip.com/support.

Veçori e mbrojtjes së kodit të pajisjeve me mikroçip
Vini re detajet e mëposhtme të veçorisë së mbrojtjes së kodit në produktet Microchip:

Produktet me mikroçip plotësojnë specifikimet e përfshira në fletën e tyre të të dhënave të mikroçipit.
Microchip beson se familja e tij e produkteve është e sigurt kur përdoret në mënyrën e synuar, brenda specifikimeve të funksionimit dhe në kushte normale.

Mikroçipi vlerëson dhe mbron në mënyrë agresive të drejtat e tij të pronësisë intelektuale. Përpjekjet për të shkelur veçoritë e mbrojtjes së kodit të produkteve Microchip janë rreptësisht të ndaluara dhe mund të shkelin Aktin e të Drejtave të Autorit të Mijëvjeçarit Dixhital.
As Microchip dhe as ndonjë prodhues tjetër gjysmëpërçues nuk mund të garantojë sigurinë e kodit të tij. Mbrojtja e kodit nuk do të thotë që ne garantojmë se produkti është "i pathyeshëm". Mbrojtja e kodit po zhvillohet vazhdimisht. Microchip është i përkushtuar të përmirësojë vazhdimisht veçoritë e mbrojtjes së kodit të produkteve tona.

Njoftim Ligjor
Ky publikim dhe informacioni këtu mund të përdoren vetëm me produktet Microchip, duke përfshirë për të dizajnuar, testuar dhe integruar produktet Microchip me aplikacionin tuaj. Përdorimi i këtij informacioni në çdo mënyrë tjetër shkel këto kushte. Informacioni në lidhje me aplikacionet e pajisjes ofrohet vetëm për lehtësinë tuaj dhe mund të zëvendësohet nga përditësimet. Është përgjegjësia juaj të siguroheni që aplikacioni juaj të plotësojë specifikimet tuaja. Kontaktoni zyrën tuaj lokale të shitjeve të Microchip për mbështetje shtesë ose merrni mbështetje shtesë në www.microchip.com/en-us/support/design-help/client-support-services.

KY INFORMACION SIGUROHET NGA MIKROCHIP "AS IS". MICROCHIP NUK BËN ASNJË PËRFAQËSIM OSE GARANCI TË ASNJË LLOJI, TË SHPREHUR APO TË nënkuptuara, SHKRUARA APO GOJAL, STATUTOR APO TË NDRYSHME, LIDHUR ME INFORMACIONIN QË PËRFSHIRË POR JO TË KUFIZUARA TË KUFIZUARA MOS SHKELJA, TREGTUESHMËRIA DHE PËRSHTATSHMËRIA PËR NJË QËLLIM TË VEÇANTË, OSE GARANCI LIDHUR ME GJENDJEN, CILËSINË APO PERFORMANCËN E SAJ.

NË ASNJË RAST MIKROCHIP DO TË JETË PËRGJEGJËS PËR ASNJË HUMBJE, DËM, KOST OSE PAJISJE TË INDIREKTE, TË VEÇANTA, NDËSHKUESE, INCIDENTALE APO PAJISJELE, TË ÇFARË TË LLOJI TË LIDHUR ME SH.B.A.N. IP ESHTE KESHILLUAR NGA MUNDËSIA APO DËMET JANË TË PARASHIKUESHME. NE SHTESIN MË TË PLOTË TË LEJUAR NGA LIGJI, PËRGJEGJËSIA TOTALE E MIKROÇIPIT PËR TË GJITHA KËRKESAT NË NDONJË MËNYRË LIDHUR ME INFORMACIONIN APO PËRDORIMIN E TIJ NUK DO TË KAJTËROJË NUMRIN E TARIFAVE, NËSE KA NDONJË, QË NJOHNI TË MIRA TË JUAJ.

Përdorimi i pajisjeve të mikroçipit në aplikacionet e mbështetjes së jetës dhe/ose të sigurisë është tërësisht në rrezik të blerësit dhe blerësi pranon të mbrojë, zhdëmtojë dhe mbajë mikroçipin e padëmshëm nga të gjitha dëmet, pretendimet, paditë ose shpenzimet që rezultojnë nga një përdorim i tillë. Asnjë licencë nuk transmetohet, në mënyrë të nënkuptuar ose ndryshe, sipas asnjë të drejte të pronësisë intelektuale të Microchip, përveç nëse përcaktohet ndryshe.

Markat tregtare
Emri dhe logoja e Microchip, logoja e Microchip, Adaptec, AVR, logo AVR, AVR Freaks, BesTime, BitCloud, CryptoMemory, CryptoRF, dsPIC, flexPWR, HELDO, IGLOO, JukeBlox, KeeLoq, Kleer, Linktys, maXe MediaLB, megaAVR, Microsemi, logoja Microsemi, logoja MOST, MOST, MPLAB, OptoLyzer, PIC, picoPower, PICSTART, logoja PIC32, PolarFire, Prochip Designer, QTouch, SAM-BA, SenGenuity, SpyNIC, SST, SST Logoymricom, , SyncServer, Tachyon, TimeSource, tinyAVR, UNI/O, Vectron dhe XMEGA janë marka tregtare të regjistruara të Microchip Technology Incorporated në SHBA dhe vende të tjera.

AgileSwitch, ClockWorks, The Embedded Control Solutions Company, EtherSynch, Flashtec, Hyper Speed Control, HyperLight Load, Libero, stol motorik, mTouch, Powermite 3, Precision Edge, ProASIC, ProASIC Plus, logoja ProASIC Plus, Quiet-Wire, SyncFord , TimeCesium, TimeHub, TimePictra, TimeProvider dhe ZL janë marka tregtare të regjistruara të Microchip Technology Incorporated në SHBA

Mbyllja e çelësit ngjitur, AKS, Analog-për-Moshës Dixhitale, Çdo Kondensator, AnyIn, AnyOut, Ndërrimi i shtuar, BlueSky, BodyCom, Clockstudio, CodeGuard, CryptoAuthentication, CryptoAutomotive, CryptoAutomotive, CryptoAutomotive, CryptoCompanion gërvishtje , DAM, ECAN, Espresso T1S, EtherGREEN, EyeOpen, GridTime, IdealBridge,
IGaT, programim serial në qark, ICSP, INICnet, paralelizimi inteligjent, IntelliMOS, Lidhshmëria me çipa, JitterBlocker, Knob-on-Display, MarginLink, maxCrypto, maxView, memBrain, Mindi, MiWi, MPASM, MPF, MPLAB Logo e çertifikuar, MPLIB, MPLINK, mSiC, MultiTRAK, NetDetach, Gjenerimi i kodeve të gjithëdijshme, PICDEM, PICDEM.net, PICkit, PICtail, Power MOS IV, Power MOS 7, PowerSureSmart, , QMatrix, REAL ICE, Ripple Blocker, RTAX, RTG4, SAM-ICE, Serial Quad I/O, hartë e thjeshtë, SimpliPHY, SmartBuffer, SmartHLS, SMART-IS, storClad, SQI, SuperSwitcher, SuperSwitcher II, Switchtec, TotalPHY, Synchro Qëndrueshmëri, Koha e Besuar, TSHARC, Turing, USBCheck, VariSense, VectorBlox, VeriPHY, ViewSpan, WiperLock, XpressConnect dhe ZENA janë marka tregtare të Microchip Technology Incorporated në SHBA dhe vende të tjera.

SQTP është një markë shërbimi e Microchip Technology Incorporated në SHBA
Logoja Adaptec, Frequency on Demand, Silicon Storage Technology dhe Symmcom janë marka tregtare të regjistruara të Microchip Technology Inc. në vende të tjera.
GestIC është një markë e regjistruar e Microchip Technology Germany II GmbH & Co. KG, një filial i Microchip Technology Inc., në vende të tjera.

ISBN: 978-1-6683-4890-1

Sistemi i Menaxhimit të Cilësisë
Për informacion në lidhje me Sistemet e Menaxhimit të Cilësisë të Microchip, ju lutemi vizitoni www.microchip.com/quality.

Shitjet dhe shërbimi në mbarë botën

AMERIKA

AZI/PACIFIK

EVROPA

Korporata Zyra

2355 West Chandler Blvd. Chandler, AZ 85224-6199

Tel: 480-792-7200

Faksi: 480-792-7277

Mbështetje Teknike: www.microchip.com/support

Web Adresa: www.microchip.com

Atlanta

Duluth, GA

Tel: 678-957-9614

Faksi: 678-957-1455

Austin, Teksas

Tel: 512-257-3370

Boston

Westborough, MA Tel: 774-760-0087

Faksi: 774-760-0088

Çikago

Itasca, IL

Tel: 630-285-0071

Faksi: 630-285-0075

Dallas

Addison, TX

Tel: 972-818-7423

Faksi: 972-818-2924

Detroit

Novi, MI

Tel: 248-848-4000

Hjuston, TX

Tel: 281-894-5983

Indianapolis

Noblesville, IN Tel: 317-773-8323

Faksi: 317-773-5453

Tel: 317-536-2380

Los Anxhelos

Mission Viejo, CA Tel: 949-462-9523

Faksi: 949-462-9608

Tel: 951-273-7800

Raleigh, NC

Tel: 919-844-7510

Nju Jork, NY

Tel: 631-435-6000

San Jose, CA

Tel: 408-735-9110

Tel: 408-436-4270

Kanadaja – Toronto

Tel: 905-695-1980

Faksi: 905-695-2078

Australi – Sidnej

Tel: 61-2-9868-6733

Kinë – Pekin

Tel: 86-10-8569-7000

Kinë – Chengdu

Tel: 86-28-8665-5511

Kinë - Chongqing

Tel: 86-23-8980-9588

Kinë – Dongguan

Tel: 86-769-8702-9880

Kinë – Guangzhou

Tel: 86-20-8755-8029

Kinë – Hangzhou

Tel: 86-571-8792-8115

Kinë – Hong Kong SAR

Tel: 852-2943-5100

Kinë – Nanjing

Tel: 86-25-8473-2460

Kinë – Qingdao

Tel: 86-532-8502-7355

Kinë – Shanghai

Tel: 86-21-3326-8000

Kinë – Shenyang

Tel: 86-24-2334-2829

Kinë – Shenzhen

Tel: 86-755-8864-2200

Kinë – Suzhou

Tel: 86-186-6233-1526

Kinë – Wuhan

Tel: 86-27-5980-5300

Kinë – Xian

Tel: 86-29-8833-7252

Kinë – Xiamen

Tel: 86-592-2388138

Kinë – Zhuhai

Tel: 86-756-3210040

Indi – Bangalore

Tel: 91-80-3090-4444

Indi – Nju Delhi

Tel: 91-11-4160-8631

Indi – Pune

Tel: 91-20-4121-0141

Japonia – Osaka

Tel: 81-6-6152-7160

Japonia – Tokio

Tel: 81-3-6880- 3770

Korea – Daegu

Tel: 82-53-744-4301

Kore - Seul

Tel: 82-2-554-7200

Malajzi – Kuala Lumpur

Tel: 60-3-7651-7906

Malajzi – Penang

Tel: 60-4-227-8870

Filipinet – Manila

Tel: 63-2-634-9065

Singapor

Tel: 65-6334-8870

Tajvani – Hsin Çu

Tel: 886-3-577-8366

Tajvan – Kaohsiung

Tel: 886-7-213-7830

Tajvan – Taipei

Tel: 886-2-2508-8600

Tajlandë – Bangkok

Tel: 66-2-694-1351

Vietnam – Ho Chi Minh

Tel: 84-28-5448-2100

Austria – Wels

Tel: 43-7242-2244-39

Faksi: 43-7242-2244-393

Danimarka – Kopenhagen

Tel: 45-4485-5910

Faks: 45-4485-2829

Finlanda – Espoo

Tel: 358-9-4520-820

Franca – Parisi

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

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

Gjermania – Garning

Tel: 49-8931-9700

Gjermania – Haan

Tel: 49-2129-3766400

Gjermania – Heilbronn

Tel: 49-7131-72400

Gjermania – Karlsruhe

Tel: 49-721-625370

Gjermania – Mynihu

Tel: 49-89-627-144-0

Fax: 49-89-627-144-44

Gjermania – Rosenheim

Tel: 49-8031-354-560

Izrael – Hod Hasharon

Tel: 972-9-775-5100

Itali – Milano

Tel: 39-0331-742611

Faks: 39-0331-466781

Itali – Padova

Tel: 39-049-7625286

Holandë – Drunen

Tel: 31-416-690399

Faks: 31-416-690340

Norvegjia – Trondheim

Tel: 47-72884388

Polonia – Varshavë

Tel: 48-22-3325737

Rumania – Bukuresht

Tel: 40-21-407-87-50

Spanjë - Madrid

Tel: 34-91-708-08-90

Fax: 34-91-708-08-91

Suedi – Goteborg

Tel: 46-31-704-60-40

Suedi – Stokholm

Tel: 46-8-5090-4654

MB - Wokingham

Tel: 44-118-921-5800

Faksi: 44-118-921-5820

Dokumentet / Burimet

Mikroprocesor me katër bërthama MICROCHIP PIC64GX 64-bit RISC-V [pdfUdhëzuesi i përdoruesit
PIC64GX, PIC64GX 64-bit RISC-V mikroprocesor me katër bërthama, 64-bit RISC-V me katër bërthama, mikroprocesor RISC-V me katër bërthama, mikroprocesor me katër bërthama, mikroprocesor

Referencat

Manuali i Përdoruesit

Mikroprocesor me katër bërthama MICROCHIP PIC64GX 64-bit RISC-V

Informacioni i produktit

Udhëzimet e përdorimit të produktit