MICROCHIP PIC64GX 64 bitu RISC-V četrkodolu mikroprocesora lietotāja rokasgrāmata

Sāknēšanas process
1. Programmatūras komponenti, kas saistīti ar sāknēšanu
  Sistēmas sāknēšanas process ietver šādus programmatūras komponentus:
  - Hart Software Services (HSS): nullestage sāknēšanas ielādētājs, sistēmas monitors un lietojumprogrammu izpildlaika pakalpojumu nodrošinātājs.
2. Sāknēšanas plūsma
  Sistēmas sāknēšanas plūsmas secība ir šāda:
  1. Hart programmatūras pakalpojumu (HSS) inicializācija
  2. Bootloader izpilde
  3. Lietojumprogrammas palaišana
Sargsuņi
1. PIC64GX sargsuns
  PIC64GX ir sargsuņa funkcija, lai uzraudzītu sistēmas darbību un aktivizētu darbības sistēmas kļūmju gadījumā.
Bloķēšanas režīms
Bloķēšanas režīms ir paredzēts klientiem, kuriem nepieciešama pilnīga kontrole pār sistēmas darbībām pēc sāknēšanas. Tas ierobežo E51 sistēmas monitora funkcijas.

FAQ

J: Kāds ir Hart programmatūras pakalpojumu (HSS) mērķis?
A: HSS kalpo kā nullestage sāknēšanas ielādētājs, sistēmas monitors un izpildlaika pakalpojumu nodrošinātājs lietojumprogrammām sāknēšanas procesa laikā.
J: Kā darbojas sargsuņa PIC64GX funkcija?
A: PIC64GX sargsuns uzrauga sistēmas darbību un var veikt iepriekš noteiktas darbības sistēmas kļūmju gadījumā, lai nodrošinātu sistēmas uzticamību.

Ievads

Šajā dokumentā ir izskaidrots, kā Microchip PIC64GX sāknēt lietojumprogrammu darba slodzi, un aprakstīts sistēmas sāknēšanas process, kas darbojas tāpat kā SMP un AMP darba slodzes. Turklāt tajā ir aprakstīts, kā SMP un SMP atsāknēšana darbojas AMP darba slodzes, sargsuņi uz PIC64GX un īpašs bloķēšanas režīms sistēmām, kurās klienti vēlas pilnīgu kontroli, lai ierobežotu E51 sistēmas monitora darbības pēc sistēmas sāknēšanas.

Sāknēšanas process

Apskatīsim dažādus programmatūras komponentus, kas iesaistīti sistēmas sāknēšanas procesā, un pēc tam detalizētāk aplūkosim pašas sistēmas sāknēšanas plūsmas secību.

Programmatūras komponenti, kas saistīti ar sāknēšanu
Sistēmas sāknēšanas procesā ir iesaistīti šādi komponenti:

1.1.attēls. Sāknēšanas komponenti

Hart programmatūras pakalpojumi (HSS)
Hart Software Services (HSS) ir nulletage sāknēšanas ielādētājs, sistēmas monitors un lietojumprogrammu izpildlaika pakalpojumu sniedzējs. HSS atbalsta agrīnu sistēmas iestatīšanu, DDR apmācību un aparatūras inicializāciju/konfigurēšanu. Tas galvenokārt darbojas ar E51s, ar nelielu daudzumu mašīnas režīma līmeņa funkcionalitātes, kas darbojas katrā U54. Tas sāknēt vienu vai vairākus kontekstus, ielādējot lietojumprogrammas “lietderīgo slodzi” no sāknēšanas datu nesēja, un nodrošina platformas izpildlaika pakalpojumus/uzrauga izpildes vidi (SEE) operētājsistēmas kodoliem. Tā atbalsta drošu sāknēšanu un ir svarīga sastāvdaļa, lai nodrošinātu aparatūras sadalīšanu/atdalīšanu AMP kontekstos.

Das U-Boot (U-Boot)
Das U-Boot (U-Boot) ir atvērtā koda universāls skriptējams sāknēšanas ielādētājs. Tā atbalsta vienkāršu CLI, kas var izgūt sāknēšanas attēlu no dažādiem avotiem (ieskaitot SD karti un tīklu). U-Boot ielādē Linux. Ja nepieciešams, tas var nodrošināt UEFI vidi. Pēc Linux sāknēšanas tas parasti ir pabeigts un vairs netiek izmantots, citiem vārdiem sakot, pēc sāknēšanas tas nepaliek nemainīgs.
Linux kodols
Linux kodols ir pasaulē populārākais operētājsistēmas kodols. Apvienojumā ar lietojumprogrammu lietotāju zemi tā veido to, ko parasti dēvē par Linux operētājsistēmu. Linux operētājsistēma nodrošina bagātīgas POSIX API un izstrādātāju vidi, piemēramample, valodas un rīki, piemēram, Python, Perl, Tcl, Rust, C/C++ un Tcl; bibliotēkas, piemēram, OpenSSL, OpenCV, OpenMP, OPC/UA un OpenAMP (RPmsg un RemoteProc).
Yocto un Buildroot ir Linux sistēmu veidotāji, tas ir, tos var izmantot, lai ģenerētu pēc pasūtījuma pielāgotas Linux sistēmas. Yocto izvada Linux izplatīšanu ar bagātīgu
lietojumprogrammu, rīku un bibliotēku komplekts, kā arī izvēles pakotņu pārvaldība. Buildroot izvada minimālāku sakni filesistēma un var mērķēt uz sistēmām, kurām nav nepieciešama pastāvīga krātuve, bet kuras darbojas tikai no RAM (izmantojot Linux iniciāļu atbalstu, piemēram,ample).

Zefīrs
Zephyr ir maza, atvērtā koda reāllaika operētājsistēma (RTOS). Tas nodrošina reāllaika zemas slodzes sistēmu ar RPMsg-lite saziņas kanāliem uz Linux. Tas ietver kodolu, bibliotēkas, ierīču draiverus, protokolu stekus, filesistēmas, programmaparatūras atjaunināšanas mehānismi un tā tālāk, un tas ir lieliski piemērots klientiem, kuri vēlas izmantot PIC64GX vienkāršāku pieredzi.

Sāknēšanas plūsma
PIC64GX ietver RISC-V kodolu ar 64 bitu E51 sistēmas monitoru un 4 64 bitu U54 lietojumprogrammu korpusiem. RISC-V terminoloģijā harts ir RISC-V izpildes konteksts, kas satur pilnu reģistru kopu un kas izpilda savu kodu neatkarīgi. Varat to uzskatīt par aparatūras pavedienu vai vienu centrālo procesoru. Harts grupu vienā kodolā bieži sauc par kompleksu. Šajā tēmā ir aprakstītas darbības, lai inicializētu PIC64GX coreplex, tostarp E51 sistēmas monitorus sirds un U54 lietojumprogrammu harts.

Ieslēdziet PIC64GX kodolu.
Ieslēdzot, drošības kontrolieris atbrīvo visus RISC-V kodola blokus no atiestatīšanas.
Palaidiet HSS kodu no mikroshēmas eNVM zibatmiņas.
Sākotnēji katra sirds sāk palaist HSS kodu no mikroshēmas eNVM zibatmiņas. Šis kods liek visām U54 lietojumprogrammām griezties, gaidot norādījumus, un ļauj E51 monitoram sākt palaist kodu, lai inicializētu un atvērtu sistēmu.

Atspiediet HSS kodu no eNVM uz L2-Scratch atmiņu.
Atkarībā no tā izveides laika konfigurācijas HSS parasti ir lielāka par pašas eNVM zibatmiņas ietilpību, tāpēc pirmā lieta, ko dara HSS kods, kas darbojas uz E51, ir atspiest sevi no eNVM uz L2-Scratch atmiņu, kā parādīts attēlā. 1.2. un 1.3. attēlu.
1.2.attēls. HSS tiek atspiests no eNVM uz L2 Scratch
1.3.attēls. HSS atmiņas karte dekompresijas laikā
Pārejiet no eNVM uz L2-Scratch uz izpildāmo failu, kā parādīts nākamajā attēlā.
1.4.attēls. HSS pāriet no eNVM uz Code Now L2Scratch pēc dekompresijas
Izpildāmais fails sastāv no trim komponentiem:
- Aparatūras abstrakcijas slānis (HAL), zema līmeņa kods un tukša metāla draiveri
- RISC-V OpenSBI lokālā HSS dakša (nedaudz pārveidota no PIC64GX augšpuses AMP mērķiem)
- HSS izpildlaika pakalpojumi (stāvokļa mašīnas darbojas superciklā)
Inicializējiet OpenSBI izmantoto aparatūru un datu struktūras.
HSS pakalpojums “Startup” ir atbildīgs par šo inicializāciju.

Ienesiet lietojumprogrammas darba slodzes (payload.bin) attēlu no ārējās krātuves. Tas parādīts 1.5. un 1.6. attēlā
Svarīgi: PIC64GX Curiosity Kit gadījumā tas būs no SD kartes.
1.5.attēls. Notiek payload.bin darba slodzes attēla iegūšana no ārējās krātuves
1.6.attēls. HSS atmiņas karte pēc payload.bin ielādes
Kopējiet dažādas sadaļas no payload.bin uz to izpildes laika galamērķiem. Payload.bin ir formatēts attēls, kas apvieno dažādus lietojumprogrammu attēlus SMP vai AMP darba slodzes. Tajā ir iekļautas kodu, datu un deskriptoru tabulas, kas ļauj HSS atbilstoši ievietot koda un datu sadaļas, kur tās ir nepieciešamas dažādu lietojumprogrammu darba slodzes palaišanai.
1.7.attēls. payload.bin ir kopēts uz galamērķa adresēm

Uzdodiet attiecīgajiem U54 pāriet uz izpildes sākuma adresēm. Šī sākuma adreses informācija ir ietverta failā payload.bin.
Sāciet U54 Application harts un jebkuru second-stage boot loaders. Piemēram,ample, U-Boot parādīs Linux.

Reboot

Saistībā ar sistēmas sāknēšanas jēdzienu ir nepieciešamība pārstartēt. Domājot par PIC64GX lietojumprogrammu darba slodzēm, pārstartējot ir jāņem vērā gan simetriskā daudzprocesuālā apstrāde (SMP), gan asimetriskā daudzprocesuālā apstrāde (AMP) scenāriji:

SMP sistēmas gadījumā atsāknēšana var droši atsāknēt visu sistēmu, jo citā kontekstā nav jāņem vērā papildu darba slodze.

Gadījumā, ja AMP sistēma, darba slodzei var būt atļauts tikai pašai atsāknēt (un netraucēt citu kontekstu), vai arī tai var būt priviliģēta iespēja veikt pilnu sistēmas atsāknēšanu.

Reboot un AMP
Lai iespējotu SMP un AMP atsāknēšanas scenārijos, HSS atbalsta siltās un aukstās atsāknēšanas privilēģiju koncepcijas, kas ir piešķiramas kontekstam. Konteksts ar siltās atsāknēšanas privilēģiju var atsāknēties tikai pats, un konteksts ar aukstās atsāknēšanas privilēģiju var veikt pilnu sistēmas atsāknēšanu. Piemēram,ampapsveriet šādu reprezentatīvu scenāriju kopu.

Viena konteksta SMP darba slodze, kurai ir atļauts pieprasīt pilnu sistēmas atsāknēšanu
Šajā scenārijā kontekstam ir atļauta aukstās atsāknēšanas privilēģija.
Divu kontekstu AMP darba slodze, kur kontekstam A ir atļauts pieprasīt pilnu sistēmas atsāknēšanu (ietekmē visus kontekstus), un kontekstam B ir atļauts tikai pašam pārstartēt
Šajā scenārijā kontekstam A ir atļauta aukstās atsāknēšanas privilēģija, un kontekstam B ir atļauta siltās atsāknēšanas privilēģija.
Divu kontekstu AMP darba slodze, kur kontekstam A un B ir atļauts tikai pašiem atsāknēties (un tas neietekmē citu kontekstu)
Šajā scenārijā abos kontekstos ir atļautas tikai siltās atsāknēšanas privilēģijas.
Divu kontekstu AMP darba slodze, kur kontekstam A un B ir atļauts pieprasīt pilnu sistēmas atsāknēšanu
Šajā scenārijā abos kontekstos ir atļautas aukstās atsāknēšanas privilēģijas.
Turklāt HSS izveides laikā vienmēr var atļaut aukstās atsāknēšanas privilēģiju un nekad neatļaut aukstās atsāknēšanas privilēģiju.

Attiecīgās HSS Kconfig opcijas
Kconfig ir programmatūras izveides konfigurācijas sistēma. To parasti izmanto, lai atlasītu izveides laika opcijas un iespējotu vai atspējotu funkcijas. Tas radās ar Linux kodolu, bet tagad ir atradis pielietojumu citos projektos ārpus Linux kodola, tostarp U-Boot, Zephyr un PIC64GX HSS.

HSS satur divas Kconfig opcijas, kas kontrolē atsāknēšanas funkcionalitāti no HSS viedokļa:

CONFIG_ALLOW_COLD REBOOT
Ja tas ir iespējots, tas globāli ļauj kontekstam izdot aukstās atsāknēšanas izsaukumu. Ja tas ir atspējots, būs atļauta tikai siltā atsāknēšana. Papildus šīs opcijas iespējošai, atļauja veikt aukstu atsāknēšanu ir jāpiešķir kontekstam, izmantojot lietderīgās slodzes ģeneratoru YAML file vai šo Kconfig opciju.
CONFIG_ALLOW_COLD REBOOT_ALWAYS
- Ja šī funkcija ir iespējota, šī funkcija visā pasaulē ļauj visiem kontekstiem izdot aukstās atsāknēšanas ECAA neatkarīgi no karodziņa payload.bin tiesībām.
- Turklāt failā payload.bin var būt ietverts konteksta karodziņš, kas norāda, ka konkrētam kontekstam ir tiesības izdot aukstās atsāknēšanas reizes:
  - Lai atļautu konteksta atsāknēšanu citā kontekstā, YAML aprakstā varam pievienot opciju allow-reboot: warm. file izmanto, lai izveidotu lietderīgo slodzi.bin
  - Lai atļautu visas sistēmas konteksta auksto atsāknēšanu, mēs varam pievienot opciju allow-reboot: cold. Pēc noklusējuma, nenorādot atļauju-reboot, kontekstam ir atļauta tikai siltā atsāknēšana. Neatkarīgi no šī karoga iestatījuma, ja HSS nav iespējots CONFIG_ALLOW_COLDREBOOT, HSS pārstrādās visus aukstās atsāknēšanas pieprasījumus, lai tie būtu silti (atkarībā no konteksta). .

Restartējiet detalizēti
Šajā sadaļā ir sīki aprakstīts, kā notiek atsāknēšana, sākot ar OpenSBI slāni (zemākais M režīma slānis) un pēc tam apspriežot, kā šī OpenSBI slāņa funkcionalitāte tiek aktivizēta no RTOS lietojumprogrammas vai bagātinātas OS, piemēram, Linux.

OpenSBI Reboot ezvans

RISC-V Supervisor Binary Interface (SBI) specifikācijā ir aprakstīts standartizēts aparatūras abstrakcijas slānis platformas inicializēšanai un programmaparatūras izpildlaika pakalpojumiem. SBI galvenais mērķis ir nodrošināt pārnesamību un savietojamību dažādās RISC-V implementācijās.
OpenSBI (Open Source Supervisor Binary Interface) ir atvērtā koda projekts, kas nodrošina SBI specifikācijas atsauces ieviešanu. OpenSBI nodrošina arī izpildlaika pakalpojumus, tostarp pārtraukumu apstrādi, taimera pārvaldību un konsoles I/O, ko var izmantot augstāka līmeņa programmatūras slāņos.
OpenSBI ir iekļauts kā daļa no HSS un darbojas mašīnas režīma līmenī. Ja operētājsistēma vai lietojumprogramma izraisa slazdu, tā tiks nodota OpenSBI, lai to apstrādātu. OpenSBI pakļauj noteiktu sistēmas izsaukuma tipa funkcionalitāti programmatūras augšējiem slāņiem, izmantojot īpašu slazdošanas mehānismu, ko sauc par izsaukumu.

Sistēmas atiestatīšana (EID 0x53525354) nodrošina visaptverošu sistēmas izsaukuma funkciju, kas ļauj augšējā slāņa programmatūrai pieprasīt sistēmas līmeņa atsāknēšanu vai izslēgšanu. Kad U54 ir izsaucis šo ezvanu, HSS programmatūra, kas darbojas mašīnas režīmā šajā U54 ierīcē, tiek ieslodzīta, un uz E51 tiek nosūtīts atbilstošs atsāknēšanas pieprasījums, lai atsāknētu kontekstu vai visu sistēmu atkarībā no ierīces tiesībām. kontekstā.

Lai iegūtu papildinformāciju, skatiet RISC-V supervizora binārās saskarnes specifikācija īpaši Sistēmas atiestatīšanas paplašinājums (EID #0x53525354 “SRST”).

Linux atsāknēšana

Kā konkrēts bijušaisampŠajā gadījumā operētājsistēmā Linux izslēgšanas komanda tiek izmantota, lai apturētu vai atsāknētu sistēmu. Komandai parasti ir daudz aizstājvārdu, proti, apturēšana, izslēgšana un atsāknēšana. Šie aizstājvārdi norāda, vai apturēt iekārtu izslēgšanas brīdī, izslēgt iekārtu, izslēdzot, vai restartēt iekārtu izslēgšanas brīdī.

Šīs lietotāja vietas komandas izdod atsāknēšanas sistēmas izsaukumu uz Linux, kuru kodols ieslodzīja un sadarbojas ar SBI izsaukumu.
Ir dažādi atsāknēšanas līmeņi – REBOOT_WARM, REBOOT_COLD, REBOOT_HARD – tos var nodot kā komandrindas argumentus kodolam (piem.ample, reboot=w[arm] priekš REBOOT_WARM). Papildinformāciju par Linux kodola pirmkodu skatiet sadaļā Documentation/admin-guide/kernel-paramters.txt.
Alternatīvi, ja ir iespējots /sys/kernel/reboot, zemāk esošos apdarinātājus var nolasīt, lai iegūtu pašreizējo sistēmas atsāknēšanas konfigurāciju, un rakstīt, lai to mainītu. Papildinformāciju par Linux kodola pirmkodu skatiet sadaļā Dokumentācija/ABI/testēšana/sysfs-kernel-reboot.

Sargsuņi

Vēl viens jēdziens, kas saistīts ar sistēmas sāknēšanu un sistēmas atsāknēšanu, ir sistēmas atkopšana pēc sargsuņa taimera palaišanas. Watchdog taimerus plaši izmanto iegultās sistēmās, lai automātiski atjaunotos pēc īslaicīgām aparatūras kļūmēm un novērstu kļūdainas vai ļaunprātīgas programmatūras traucējumus sistēmas darbībā.
PIC64GX ietver aparatūras sargsuņa atbalstu, lai uzraudzītu atsevišķus hartus, kad sistēma darbojas. Sargi nodrošina, ka harts var restartēt, ja tās nereaģē neatgriezenisku programmatūras kļūdu dēļ.
PIC64GX ietver piecus sargsuņa taimera aparatūras bloku gadījumus, ko izmanto sistēmas bloķēšanas noteikšanai — viens katram no tiem. Lai atvieglotu jauktu asimetrisku daudzkārtēju apstrādi (AMP) darba slodzes, HSS atbalsta uzraudzību un reaģēšanu uz sargsuņu šaušanu.

PIC64GX sargsuns

HSS ir atbildīgs par lietojumprogrammu harts sāknēšanu ieslēgšanas brīdī un par to atkārtotu palaišanu (individuāli vai kolektīvi) jebkurā stage, ja tas ir vajadzīgs vai vēlams. Tā rezultātā reaģēšanu uz sargsuņa notikumiem PIC64GX apstrādā HSS.
“Virtuālais sargsuņa” monitors tiek ieviests kā HSS stāvokļa mašīnas pakalpojums, un tā pienākumi ir uzraudzīt katra U54 individuālā sargsuņa aparatūras monitora statusu. Kad kāds no šiem U54 sargsuņiem ieslēdzas, HSS to konstatē un pēc vajadzības pārstartēs U54. Ja U54 ir daļa no SMP konteksta, viss konteksts tiek apsvērts atkārtotai palaišanai, jo kontekstam ir siltās atsāknēšanas privilēģija. Visa sistēma tiks atsāknēta, ja kontekstam ir aukstās atsāknēšanas privilēģija.

Attiecīgās Kconfig opcijas

Izlaistajos HSS būvējumos pēc noklusējuma ir iekļauts Watchdog atbalsts. Ja vēlaties izveidot pielāgotu HSS, šajā sadaļā ir aprakstīts konfigurācijas mehānisms, lai nodrošinātu, ka ir iespējots Watchdog atbalsts.

HSS ir konfigurēts, izmantojot Kconfig konfigurācijas sistēmu. Augšējā līmeņa .config file ir nepieciešams, lai atlasītu pakalpojumus, kas tiek apkopoti HSS būvniecībā vai ārpus tā.
Pirmkārt, ir jāiespējo augstākā līmeņa opcija CONFIG_SERVICE_WDOG (“Virtual Watchdog atbalsts”, izmantojot make config).

Pēc tam tiek parādītas šādas apakšopcijas, kas ir atkarīgas no Watchdog atbalsta:

CONFIG_SERVICE_WD OG_DEBUG
Iespējo atbalstu informatīvajiem/atkļūdošanas ziņojumiem no virtuālā sargsuņa pakalpojuma.
CONFIG_SERVICE_WD OG_DEBUG_TIMEOUT_SECS
Nosaka periodiskumu (sekundēs), kādā HSS izvadīs Watchdog atkļūdošanas ziņojumus.
CONFIG_SERVICE_WD OG_ENABLE_E51
Iespējo sargsuni E51 monitoriem papildus U54s, aizsargājot paša HSS darbību.

Kad E51 sargsuns ir iespējots, HSS periodiski rakstīs sargsuni, lai to atsvaidzinātu un novērstu tā palaišanu. Ja kāda iemesla dēļ E51 sirds bloķējas vai avarē un E51 sargsuns ir iespējots, tas vienmēr atiestatīs visu sistēmu.

Sargsuņa darbība
Sargsuņa aparatūra ievieš leju skaitītājus. Atsvaidzināšanai aizliegtu logu var izveidot, konfigurējot sargsuņa maksimālo vērtību, līdz kurai ir atļauta atsvaidzināšana (MVRP).

Ja pašreizējā sargsuņa taimera vērtība ir lielāka par MVRP vērtību, sargsuņa atsvaidzināšana ir aizliegta. Mēģinot atsvaidzināt sargsuņa taimeri aizliegtajā logā, tiks noteikts taimauta pārtraukums.

Sargsuņa atsvaidzināšana starp MVRP vērtību un trigera vērtību (TRIG) veiksmīgi atsvaidzinās skaitītāju un neļaus sargsuni izšaut.
Tiklīdz sargsuņa taimera vērtība ir zemāka par TRIG vērtību, sargsuns aktivizēsies.

Watchdog State Machine

Watchdog stāvokļa iekārta ir ļoti vienkārša — palaišana, konfigurējot sargsuni E51, ja tas ir iespējots, pēc tam pārejot dīkstāves stāvoklī uz uzraudzību. Katru reizi ap supercilpu tiek izsaukts šis uzraudzības stāvoklis, kas pārbauda katra U54 sargsuņa statusu.

Sargsuņa stāvokļa mašīna mijiedarbojas ar sāknēšanas stāvokļa mašīnu, lai restartētu hartu (un visas citas tās sāknēšanas komplektā esošās ierīces), ja tā konstatē, ka uzraugam nav izdevies laikus atsvaidzināt savu sargsuni.

Bloķēšanas režīms

Parasti (īpaši ar AMP lietojumprogrammas), ir sagaidāms, ka HSS paliks M-režīmā U54, lai atļautu atsāknēšanu atkarībā no konteksta (ti, atsāknēšana tikai vienā kontekstā, bez pilnas mikroshēmas atsāknēšanas) un ļautu HSS pārraudzīt stāvokli ( ECC, bloķēšanas statusa biti, kopnes kļūdas, SBI kļūdas, PMP pārkāpumi utt.).

Lai nodrošinātu atsāknēšanas iespējasAMP kontekstā (neprasot visai sistēmai pārstartēt), E51 parasti ir priviliģēta piekļuve atmiņai visai sistēmas atmiņas telpai. Tomēr var būt situācijas, kad tas nav vēlams, un klients var izvēlēties ierobežot E51 HSS programmaparatūras darbību, tiklīdz sistēma ir veiksmīgi sāknēta. Šādā gadījumā HSS var pārslēgt bloķēšanas režīmā, tiklīdz U54 lietojumprogramma Harts ir sāknēta.

To var iespējot, izmantojot HSS Kconfig opciju CONFIG_SERVICE_LOCKDOWN.
Bloķēšanas pakalpojums ir paredzēts, lai ļautu ierobežot HSS darbības pēc tam, kad tā ir sāknējusi U54 lietojumprogrammu Harts.

Attēls 4.2. HSS bloķēšanas režīms

Kad tiek sākts bloķēšanas režīms, tas aptur visu citu HSS pakalpojumu stāvokļa mašīnu darbību. Tas izsauc divas vāji saistītas funkcijas:

e51_pmp_lockdown(), un
e51_lockdown()

Šīs funkcijas ir paredzēts ignorēt ar plates specifisko kodu. Pirmā ir konfigurējama sprūda funkcija, kas ļauj BSP šajā brīdī pielāgot E51 bloķēšanu no lietojumprogrammas kravām. Šīs funkcijas vāji saistītā noklusējuma ieviešana ir tukša. Otrais ir funkcionalitāte, kas tiek darbināta no šī brīža uz priekšu. Vāji saistītā noklusējuma ieviešana apkalpo sargsuni šajā E51 punktā un tiks atsāknēta, ja tiks aktivizēts U54 sargsuns. Lai iegūtu papildinformāciju, skatiet HSS avota kodu vietnē services/lockdown/lockdown_service.c file.

Pielikums

HSS payload.bin formāts

Šajā sadaļā ir aprakstīts payload.bin file formātā un attēlu, ko izmanto HSS, lai sāknētu PIC64GX SMP un AMP lietojumprogrammas.
Payload.bin ir formatēts binārs (attēls A.10), kas sastāv no galvas, dažādām deskriptoru tabulām un dažādām daļām, kas satur katras lietojumprogrammas darba slodzes daļas kodu un datu sadaļas. Daļu var uzskatīt par patvaļīga izmēra blakus esošu atmiņas bloku.

Attēls A.10. payload.bin Formāts

Galvenes daļa (parādīta A.11. attēlā) satur maģisku vērtību, ko izmanto, lai identificētu payload.bin, un zināmu mājturības informāciju, kā arī detalizētu informāciju par attēlu, ko paredzēts palaist katrā no
U54 pieteikuma kodi. Tajā ir aprakstīts, kā ielādēt katru atsevišķu U54 hart, un kopumā sāknējamo attēlu kopu. Savā uzkopšanas informācijā ir norādes uz dažādām deskriptoru tabulām, lai ļautu palielināt galvenes izmēru.

A.11. attēls. payload.bin galvene

Kods un inicializētie konstantie dati tiek uzskatīti par tikai lasāmiem un tiek glabāti tikai lasāmā sadaļā, uz kuru norāda galvenes deskriptori.
Nenulles inicializētie datu mainīgie ir lasīšanas un rakstīšanas dati, taču to inicializācijas vērtības tiek kopētas no tikai lasāmā gabala palaišanas laikā. Tie tiek saglabāti arī tikai lasīšanas sadaļā.

Tikai lasāmās derīgās slodzes datu sadaļa ir aprakstīta koda un datu gabalu deskriptoru tabulā. Katrs gabala deskriptors šajā tabulā satur 'hart īpašnieks' (galvenais gabals kontekstā, uz kuru tas ir mērķēts
at), slodzes nobīde (nobīde failā payload.bin) un izpildes adrese (galamērķa adrese PIC64GX atmiņā), kā arī izmērs un kontrolsumma. Tas parādīts A.12. attēlā.

Attēls A.12. Tikai lasāms gabalu deskriptors un lietderīgās slodzes daļas dati

Papildus iepriekšminētajiem gabaliem ir arī atmiņas gabali, kas atbilst datu mainīgajiem, kas inicializēti līdz nullei. Tie netiek saglabāti kā dati failā payload.bin, bet tā vietā ir īpašs nulles inicializētu gabala deskriptoru kopums, kas norāda adresi un RAM garumu, kas startēšanas laikā jāiestata uz nulli. Tas parādīts A.13. attēlā.

Attēls A.13. ZI gabaliņi

hss-payload-generator
HSS Payload Generator rīks izveido formatētu lietderīgās slodzes attēlu Hart Software Service nullēmtage sāknēšanas ielādētājs uz PIC64GX, ņemot vērā konfigurāciju file un ELF komplekts files un/vai binārie faili. Konfigurācija file tiek izmantots, lai kartētu ELF bināros failus vai bināros blobus ar atsevišķām lietojumprogrammām (U54).

Attēls B.14. hss-payload-generator Flow

Šis rīks veic konfigurācijas struktūras pamata saprāta pārbaudes file pati un uz ELF attēliem. ELF attēliem jābūt RISC-V izpildāmiem failiem.

Example Run

Lai palaistu hss-payload-generator rīku ar sample konfigurācija file un ELF files:
$ ./hss-payload-generator -c test/config.yaml output.bin
Lai izdrukātu diagnostiku par jau esošu attēlu, izmantojiet:
$ ./hss-payload-generator -d output.bin

Lai iespējotu drošu sāknēšanas autentifikāciju (izmantojot attēla parakstīšanu), izmantojiet -p, lai norādītu eliptiskās līknes P-509 (SECP384r384) X.1 privātās atslēgas atrašanās vietu:
$ ./hss-payload-generator -c test/config.yaml payload.bin -p /path/to/private.pem

Papildinformāciju skatiet drošās sāknēšanas autentifikācijas dokumentācijā.

Konfig File Example

Pirmkārt, mēs pēc izvēles varam iestatīt attēla nosaukumu, pretējā gadījumā tas tiks izveidots dinamiski:
set-name: 'PIC64-HSS::TestImage'
Tālāk mēs definēsim katras sirds ieejas punktu adreses šādi:
hart-entry-points: {u54_1: ‘0x80200000’, u54_2: ‘0x80200000’, u54_3: ‘0xB0000000′, u54_4:’0x80200000’}

ELF avota attēli var norādīt ieejas punktu, bet mēs vēlamies, lai vajadzības gadījumā varētu atbalstīt sekundāros ieejas punktus harts, piemēram,ampJa viena attēla sāknēšanai ir paredzētas vairākas harts, tām var būt atsevišķi ieejas punkti. Lai to atbalstītu, mēs konfigurācijā norādām faktiskās ieejas punktu adreses file pati par sevi.

Tagad mēs varam definēt dažas lietderīgās slodzes (avots ELF files jeb binārie blobi), kas tiks ievietoti noteiktos atmiņas apgabalos. Kravas sadaļa tiek definēta ar atslēgvārdu lietderīgās kravas un pēc tam vairākiem atsevišķiem lietderīgās kravas deskriptoriem. Katrai kravai ir nosaukums (ceļš uz to file), īpašnieks-hart un pēc izvēles 1 līdz 3 sekundārās hartas.

Turklāt kravai ir privilēģiju režīms, kurā tā sāks izpildi. Derīgi privilēģiju režīmi ir PRV_M, PRV_S un PRV_U, kur tie ir definēti kā:

PRV_M Mašīnas režīms
PRV_S Uzraudzītāja režīms
PRV_U Lietotāja režīms

Nākamajā eksample:

Tiek pieņemts, ka test/zephyr.elf ir Zephyr lietojumprogramma, kas darbojas operētājsistēmā U54_3, un tā sāk darboties PRV_M privilēģiju režīmā.
test/u-boot-dtb.bin ir Das U-Boot sāknēšanas ielādētāja lietojumprogramma, un tā darbojas uz U54_1, U54_2 un U54_4. Paredzams, ka tas sāksies PRV_S privilēģiju režīmā.

Svarīgi:
U-Boot izvade rada ELF file, taču parasti tas nepievieno paplašinājumu .elf. Šajā gadījumā tiek izmantots CONFIG_OF_SEPARATE izveidotais binārs, kas U-Boot bināram pievieno ierīces koka lāse.

Šeit ir bijušaisample Kravu konfigurācija file:

test/zephyr.elf:
{exec-addr: '0xB0000000', īpašnieks-harts: u54_3, priv-mode: prv_m, skip-opensbi: true}
test/u-boot-dtb.bin:
{exec-addr: '0x80200000', īpašnieks-hart: u54_1, sekundārais-hart: u54_2, sekundārais-hart: u54_4, priv-mode: prv_s}

Svarīgi:
Lietam ir nozīme tikai file ceļu nosaukumi, nevis atslēgvārdi. Tātad, piemēram, u54_1 tiek uzskatīts par tādu pašu kā U54_1, un exec-addr tiek uzskatīts par tādu pašu kā EXEC-ADDR. Ja ir paplašinājums an.elf vai .bin, tas ir jāiekļauj konfigurācijā file.

Metāla lietojumprogrammai, kas nevēlas būt saistīta ar OpenSBI, izlaišanas-atvēršanas opcija, ja tā ir patiesa, izraisīs šīs sirds lietderīgās slodzes izsaukšanu, izmantojot vienkāršu mret.
nekā OpenSBI sbi_init() izsaukums. Tas nozīmē, ka sirds sāks palaist tukšā metāla kodu neatkarīgi no OpenSBI HSM apsvērumiem. Ņemiet vērā, ka tas arī nozīmē, ka sirds nevar izmantot
izsauc, lai izsauktu OpenSBI funkcionalitāti. Atvēršanas izlaišanas opcija nav obligāta, un tās noklusējuma vērtība ir nepatiesa.

Lai atļautu cita konteksta atsāknēšanu kontekstā, mēs varam pievienot opciju atļaut atsāknēšanu: silts. Lai atļautu visas sistēmas konteksta auksto atsāknēšanu, mēs varam pievienot opciju allow-reboot: cold. Pēc noklusējuma, nenorādot atļauju-reboot, kontekstam ir atļauts tikai uzsildīt pašu atsāknēšanu.
Ir iespējams arī saistīt papildu datus ar katru lietderīgo kravu, piemēram,ample, DeviceTree Blob (DTB) file, norādot palīgdatus filenosaukumu šādi:
test/u-boot.bin: { exec-addr: '0x80200000', īpašnieks-hart: u54_1, sekundārā-hart: u54_2, sekundārā-hart: u54_3, sekundārā-hart: u54_4, priv-mode: prv_s, palīgdati : test/pic64gx.dtb }
Šie papildu dati tiks iekļauti lietderīgajā kravā (novietoti tieši aiz galvenā file izpildāmajā failā
telpa), un tā adrese tiks nodota OpenSBI laukā next_arg1 (nodota $a1 reģistrā attēlam sāknēšanas laikā).

Lai novērstu HSS automātisku konteksta sāknēšanu (piemēram, ja mēs tā vietā vēlamies deleģēt tā kontroli kontekstam, izmantojot remoteProc), izmantojiet skip-autoboot karogu:
test/zephyr.elf: {exec-addr: '0xB0000000', īpašnieks-hart: u54_3, priv-mode: prv_m, skip-opensbi: true, skip-autoboot: true}
Visbeidzot, mēs varam pēc izvēles ignorēt atsevišķu lietderīgo kravu nosaukumus, izmantojot opciju lietderīgās kravas nosaukums. Piemēram,ample:
test/u-boot.bin: { exec-addr: '0x80200000', īpašnieks-hart: u54_1, sekundārā-hart: u54_2, sekundārā-hart: u54_3, sekundārā-hart: u54_4, priv-mode: prv_s, palīgdati : test/pic64gx.dtb, slodzes nosaukums: 'u-boot' }

Ņemiet vērā, ka Yocto un Buildroot Linux veidotāji veidos, konfigurēs un palaidīs hss-payload-
ģenerators, ja nepieciešams, lai ģenerētu lietojumprogrammas attēlus. Turklāt pic64gx-curiosity-kit-amp mašīnas mērķis programmā Yocto ģenerēs lietojumprogrammas attēlu, izmantojot hss-payload-generator rīku, kas demonstrē AMP, kurā Linux darbojas uz 3 harts un Zephyr darbojas uz 1 hart.

Pārskatīšanas vēsture
Pārskatīšanas vēsturē ir aprakstītas izmaiņas, kas tika ieviestas dokumentā. Izmaiņas ir uzskaitītas pēc pārskatīšanas, sākot ar jaunāko publikāciju.

Pārskatīšana	Datums	Apraksts
A	07/2024	Sākotnējā pārskatīšana

Informācija par mikroshēmu

Mikroshēma Webvietne
Microchip nodrošina tiešsaistes atbalstu, izmantojot mūsu webvietne plkst www.microchip.com/. Šis webvietne tiek izmantota, lai izveidotu files un informācija ir viegli pieejama klientiem. Daļa pieejamā satura ietver:

Produktu atbalsts – Datu lapas un kļūdas, pieteikuma piezīmes un sample programmas, dizaina resursi, lietotāja rokasgrāmatas un aparatūras atbalsta dokumenti, jaunākie programmatūras laidieni un arhivētā programmatūra

Vispārējais tehniskais atbalsts - Bieži uzdotie jautājumi (BUJ), tehniskā atbalsta pieprasījumi, tiešsaistes diskusiju grupas, Microchip dizaina partneru programmas dalībnieku saraksts
Microchip bizness - Produktu atlases un pasūtīšanas ceļveži, jaunākie Microchip preses relīzes, semināru un pasākumu saraksts, Microchip tirdzniecības biroju, izplatītāju un rūpnīcu pārstāvju saraksti

Produkta izmaiņu paziņošanas pakalpojums

Microchip produktu izmaiņu paziņošanas pakalpojums palīdz klientiem nodrošināt jaunāko informāciju par Microchip produktiem. Abonenti saņems e-pasta paziņojumus ikreiz, kad tiks veiktas izmaiņas, atjauninājumi, labojumi vai kļūdas saistībā ar noteiktu produktu saimi vai interesējošo izstrādes rīku.

Lai reģistrētos, dodieties uz www.microchip.com/pcn un izpildiet reģistrācijas norādījumus.

Klientu atbalsts
Microchip produktu lietotāji var saņemt palīdzību vairākos kanālos:

Izplatītājs vai pārstāvis
Vietējais tirdzniecības birojs
Iegulto risinājumu inženieris (ESE)
Tehniskais atbalsts

Lai saņemtu atbalstu, klientiem jāsazinās ar savu izplatītāju, pārstāvi vai ESE. Vietējie tirdzniecības biroji ir arī pieejami, lai palīdzētu klientiem. Šajā dokumentā ir iekļauts pārdošanas biroju un atrašanās vietu saraksts.
Tehniskais atbalsts ir pieejams, izmantojot webvietne: www.microchip.com/support.

Mikroshēmu ierīču koda aizsardzības līdzeklis
Ņemiet vērā šādu informāciju par koda aizsardzības līdzekli Microchip produktiem:

Mikročipu izstrādājumi atbilst specifikācijām, kas ietvertas to konkrētajā mikroshēmas datu lapā.
Microchip uzskata, ka tā produktu saime ir droša, ja to izmanto paredzētajā veidā, saskaņā ar darbības specifikācijām un normālos apstākļos.

Mikroshēma novērtē un agresīvi aizsargā savas intelektuālā īpašuma tiesības. Mēģinājumi pārkāpt Microchip produktu koda aizsardzības funkcijas ir stingri aizliegti, un tie var pārkāpt Digitālās tūkstošgades autortiesību likumu.
Ne Microchip, ne kāds cits pusvadītāju ražotājs nevar garantēt sava koda drošību. Koda aizsardzība nenozīmē, ka mēs garantējam, ka produkts ir “nesalaužams”. Koda aizsardzība pastāvīgi attīstās. Microchip ir apņēmies nepārtraukti uzlabot mūsu produktu koda aizsardzības funkcijas.

Juridisks paziņojums
Šo publikāciju un tajā esošo informāciju var izmantot tikai ar Microchip produktiem, tostarp, lai izstrādātu, pārbaudītu un integrētu Microchip produktus ar jūsu lietojumprogrammu. Šīs informācijas izmantošana jebkādā citā veidā pārkāpj šos noteikumus. Informācija par ierīces lietojumprogrammām tiek sniegta tikai jūsu ērtībām, un to var aizstāt ar atjauninājumiem. Jūs esat atbildīgs par to, lai jūsu pieteikums atbilstu jūsu specifikācijām. Sazinieties ar vietējo Microchip pārdošanas biroju, lai saņemtu papildu atbalstu, vai saņemiet papildu atbalstu vietnē www.microchip.com/en-us/support/design-help/client-support-services.

ŠO INFORMĀCIJA TIEK SNIEGTA MICROCHIP “KĀDA IR”. MICROCHIP NESNIEDZ NEKĀDA VEIDA TIEŠAS VAI NETIEŠAS, RAKSTISKAS VAI MUTISKAS, STRUKTŪRAS VAI CITĀDI GARANTIJAS, KAS SAISTĪTAS AR INFORMĀCIJU, IESKAITOT, BET NEAPROBEŽOTIES, AR JEBKĀDĀM NETIEŠĀM GARANTIJĀM. PIEMĒROTĪBA KONKRĒTAM MĒRĶIEM VAI GARANTIJĀS, KAS SAISTĪTAS AR TĀ STĀVOKLI, KVALITĀTI VAI DARBĪBU.

Nekādā gadījumā mikroshēma nebūs atbildīga par jebkādiem netiešiem, īpašiem, soda, nejaušiem vai izrietošiem zaudējumiem, bojājumiem, izmaksām vai izmaksām, kas ir saistīti ar informāciju vai tās izmantošanu, lai arī cik izraisīt IESPĒJAS VAI BOJĀJUMI IR PAREDZĀMI. CIKLĀ LIKUMĀ ATĻAUTAJĀ MĪRĀ, MICROCHIP KOPĒJĀS ATBILDĪBAS PAR VISĀM PRASĪBĀM, KAS NEKādā VEIDS SAISTĪTAS AR INFORMĀCIJU VAI TĀS IZMANTOŠANU, NEPĀRSNIEDZ TO MAKSĀJUMU SKAITS, JA TĀDAS IR, KAS JŪS BŪT SAMAKSĀJĀT PAR MICROIPION.

Microchip ierīču izmantošana dzīvības uzturēšanas un/vai drošības lietojumos ir pilnībā pakļauta pircēja riskam, un pircējs piekrīt aizsargāt, atlīdzināt un turēt nekaitīgu Microchip no visiem bojājumiem, prasībām, prasībām vai izdevumiem, kas izriet no šādas lietošanas. Saskaņā ar Microchip intelektuālā īpašuma tiesībām licences netiek nodotas, netieši vai citādi, ja vien nav norādīts citādi.

Preču zīmes
Mikročipa nosaukums un logotips, Microchip logotips, Adaptec, AVR, AVR logotips, AVR Freaks, BesTime, BitCloud, CryptoMemory, CryptoRF, dsPIC, flexPWR, HELDO, IGLOO, JukeBlox, KeeLoq, Kleer, LANCheck, LinklusMD, maxTouchty, MediaLB, megaAVR, Microsemi, Microsemi logotips, MOST, MOST logotips, MPLAB, OptoLyzer, PIC, picoPower, PICSTART, PIC32 logotips, PolarFire, Prochip Designer, QTouch, SAM-BA, SenGenuity, SpyNIC, SST, SST logotips, SuperFlash, Sym , SyncServer, Tachyon, TimeSource, tinyAVR, UNI/O, Vectron un XMEGA ir Microchip Technology Incorporated reģistrētas preču zīmes ASV un citās valstīs.

AgileSwitch, ClockWorks, The Embedded Control Solutions Company, EtherSynch, Flashtec, Hyper Speed Control, HyperLight Load, Libero, motora stends, mTouch, Powermite 3, Precision Edge, ProASIC, ProASIC Plus, ProASIC Plus logotips, Quiet-Wire, SmartWFusion, SyncWorld, , TimeCesium, TimeHub, TimePictra, TimeProvider un ZL ir Microchip Technology Incorporated reģistrētas preču zīmes ASV.

Blakus esošu taustiņu nomākšana, AKS, analogais digitālajam vecumam, jebkurš kondensators, AnyIn, AnyOut, paplašinātā pārslēgšana, BlueSky, BodyCom, Clockstudio, CodeGuard, kriptoautentifikācija, kriptogrāfijas automobiļi, kriptokompanjons, kriptovalsts, dinamiskais komplekts, kriptogrāfijas kontrolieris, APICDEM, dds. , 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, maxView, memBrain, Mindi, MiWi, MPASM, MPF, MPLAB sertificēts logotips, MPLIB, MPLINK, mSiC, MultiTRAK, NetDetach, visuzinošais kodu ģenerēšana, PICDEM, PICDEM.net, PICkit, PICtail, Power MOS IV, Power MOS 7, PureS PowerSmart, , QMatrix, REAL ICE, Ripple Blocker, RTAX, RTG4, SAM-ICE, Serial Quad I/O, vienkārša karte, SimpliPHY, SmartBuffer, SmartHLS, SMART-IS, storClad, SQI, SuperSwitcher, SuperSwitcher II, Switchtec, SynchroPHY, Total Izturība, uzticamais laiks, TSHARC, Tjūrings, USBCheck, VariSense, VectorBlox, VeriPHY, ViewSpan, WiperLock, XpressConnect un ZENA ir Microchip Technology Incorporated preču zīmes ASV un citās valstīs.

SQTP ir uzņēmuma Microchip Technology Incorporated pakalpojumu zīme ASV
Adaptec logotips, Frequency on Demand, Silicon Storage Technology un Symmcom ir Microchip Technology Inc. reģistrētas preču zīmes citās valstīs.
GestIC ir Microchip Technology Germany II GmbH & Co. KG, Microchip Technology Inc. meitasuzņēmuma, reģistrēta preču zīme citās valstīs.

ISBN: 978-1-6683-4890-1

Kvalitātes vadības sistēma
Lai iegūtu informāciju par Microchip kvalitātes vadības sistēmām, lūdzu, apmeklējiet vietni www.microchip.com/quality.

Pārdošana un serviss visā pasaulē

AMERIKA

ĀZIJA/Klusā okeāna reģions

EIROPĀ

Korporatīvs Birojs

2355 West Chandler Blvd. Chandler, AZ 85224-6199

Tālr.: 480-792-7200

Fakss: 480-792-7277

Tehniskais atbalsts: www.microchip.com/support

Web Adrese: www.microchip.com

Atlanta

Duluta, GA

Tālr.: 678-957-9614

Fakss: 678-957-1455

Ostina, Teksasa

Tālr.: 512-257-3370

Bostona

Vestboro, MA Tālr. 774-760-0087

Fakss: 774-760-0088

Čikāga

Itaska, IL

Tālr.: 630-285-0071

Fakss: 630-285-0075

Dalasa

Addison, TX

Tālr.: 972-818-7423

Fakss: 972-818-2924

Detroita

Novi, MI

Tālr.: 248-848-4000

Hjūstona, TX

Tālr.: 281-894-5983

Indianapolisa

Noblesville, IN Tālr. 317-773-8323

Fakss: 317-773-5453

Tālr.: 317-536-2380

Losandželosa

Misija Viejo, CA Tālr. 949-462-9523

Fakss: 949-462-9608

Tālr.: 951-273-7800

Rolija, NC

Tālr.: 919-844-7510

Ņujorka, NY

Tālr.: 631-435-6000

San Hosē, CA

Tālr.: 408-735-9110

Tālr.: 408-436-4270

Kanāda – Toronto

Tālr.: 905-695-1980

Fakss: 905-695-2078

Austrālija - Sidneja

Tālr.: 61-2-9868-6733

Ķīna – Pekina

Tālr.: 86-10-8569-7000

Ķīna - Čendu

Tālr.: 86-28-8665-5511

Ķīna - Čuncjina

Tālr.: 86-23-8980-9588

Ķīna – Donguana

Tālr.: 86-769-8702-9880

Ķīna - Guandžou

Tālr.: 86-20-8755-8029

Ķīna - Hangdžou

Tālr.: 86-571-8792-8115

Ķīna – Hong Kong SAR

Tālr.: 852-2943-5100

Ķīna - Nanjing

Tālr.: 86-25-8473-2460

Ķīna - Qingdao

Tālr.: 86-532-8502-7355

Ķīna – Šanhaja

Tālr.: 86-21-3326-8000

Ķīna - Šeņjana

Tālr.: 86-24-2334-2829

Ķīna - Šenžena

Tālr.: 86-755-8864-2200

Ķīna - Sudžou

Tālr.: 86-186-6233-1526

Ķīna - Uhaņa

Tālr.: 86-27-5980-5300

Ķīna - Sjaņa

Tālr.: 86-29-8833-7252

Ķīna - Sjameņa

Tālr.: 86-592-2388138

Ķīna - Zhuhai

Tālr.: 86-756-3210040

Indija – Bengalūra

Tālr.: 91-80-3090-4444

Indija - Ņūdeli

Tālr.: 91-11-4160-8631

Indija – Pune

Tālr.: 91-20-4121-0141

Japāna – Osaka

Tālr.: 81-6-6152-7160

Japāna – Tokija

Tālr.: 81-3-6880-3770

Koreja – Tegu

Tālr.: 82-53-744-4301

Koreja - Seula

Tālr.: 82-2-554-7200

Malaizija - Kuala Lumpur

Tālr.: 60-3-7651-7906

Malaizija - Penanga

Tālr.: 60-4-227-8870

Filipīnas – Manila

Tālr.: 63-2-634-9065

Singapūra

Tālr.: 65-6334-8870

Taivāna – Hsin Ču

Tālr.: 886-3-577-8366

Taivāna - Gaosjuna

Tālr.: 886-7-213-7830

Taivāna - Taipeja

Tālr.: 886-2-2508-8600

Taizeme – Bangkoka

Tālr.: 66-2-694-1351

Vjetnama - Hošimina

Tālr.: 84-28-5448-2100

Austrija – Velsa

Tālr.: 43-7242-2244-39

Fakss: 43-7242-2244-393

Dānija – Kopenhāgena

Tālr.: 45-4485-5910

Fakss: 45-4485-2829

Somija – Espo

Tālr.: 358-9-4520-820

Francija – Parīze

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

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

Vācija – Garčings

Tālr.: 49-8931-9700

Vācija – Hāns

Tālr.: 49-2129-3766400

Vācija – Heilbronna

Tālr.: 49-7131-72400

Vācija – Karlsrūe

Tālr.: 49-721-625370

Vācija – Minhene

Tel: 49-89-627-144-0

Fax: 49-89-627-144-44

Vācija – Rozenheima

Tālr.: 49-8031-354-560

Izraēla - Hods Hašarons

Tālr.: 972-9-775-5100

Itālija – Milāna

Tālr.: 39-0331-742611

Fakss: 39-0331-466781

Itālija – Padova

Tālr.: 39-049-7625286

Nīderlande – Drunen

Tālr.: 31-416-690399

Fakss: 31-416-690340

Norvēģija – Tronheima

Tālr.: 47-72884388

Polija – Varšava

Tālr.: 48-22-3325737

Rumānija – Bukareste

Tel: 40-21-407-87-50

Spānija – Madride

Tel: 34-91-708-08-90

Fax: 34-91-708-08-91

Zviedrija – Gēteborga

Tel: 46-31-704-60-40

Zviedrija – Stokholma

Tālr.: 46-8-5090-4654

Lielbritānija - Vokingema

Tālr.: 44-118-921-5800

Fakss: 44-118-921-5820

Dokumenti / Resursi

MICROCHIP PIC64GX 64 bitu RISC-V četrkodolu mikroprocesors [pdfLietotāja rokasgrāmata
PIC64GX, PIC64GX 64 bitu RISC-V četrkodolu mikroprocesors, 64 bitu RISC-V četrkodolu mikroprocesors, RISC-V četrkodolu mikroprocesors, četrkodolu mikroprocesors, mikroprocesors

Atsauces

Lietotāja rokasgrāmata

MICROCHIP PIC64GX 64 bitu RISC-V četrkodolu mikroprocesors

Informācija par produktu

Produkta lietošanas instrukcijas