MICROCHIP-Logotip

MICROCHIP PIC64GX 64-bitni štirijedrni mikroprocesor RISC-V

MICROCHIP-PIC64GX-64-Bit-RISC-V-Štirijedrni-Mikroprocesorski-Izdelek

Informacije o izdelku

Tehnični podatki:

  • Ime izdelka: Mikročip PIC64GX
  • Postopek zagona: SMP in AMP podprte delovne obremenitve
  • Posebne lastnosti: Podpora Watchdog, način zaklepanja

Navodila za uporabo izdelka

  1. Postopek zagona
    1. Komponente programske opreme, vključene v zagon
      Postopek zagona sistema vključuje naslednje komponente programske opreme:
      • Hart Software Services (HSS): nič-stage-zagonski nalagalnik, sistemski nadzornik in ponudnik izvajalnih storitev za aplikacije.
    2. Potek zagona
      Zaporedje toka zagona sistema je naslednje:
      1. Inicializacija programskih storitev Hart (HSS)
      2. Izvedba zagonskega nalagalnika
      3. Zagon aplikacije
  2. Psi čuvaji
    1. PIC64GX Watchdog
      PIC64GX ima funkcijo čuvaja za spremljanje delovanja sistema in sprožitev dejanj v primeru okvar sistema.
  3. Način zaklepanja
    Način zaklepanja je zasnovan za stranke, ki potrebujejo popoln nadzor nad dejanji sistema po zagonu. Omejuje funkcionalnosti sistemskega monitorja E51.

pogosta vprašanja

  • V: Kaj je namen programskih storitev Hart (HSS)?
    O: HSS služi kot ničelna točkatage-zagonski nalagalnik, sistemski nadzornik in ponudnik izvajalnih storitev za aplikacije med postopkom zagona.
  • V: Kako deluje nadzorna funkcija PIC64GX?
    O: Nadzornik PIC64GX nadzoruje delovanje sistema in lahko izvede vnaprej določene ukrepe v primeru okvar sistema, da zagotovi zanesljivost sistema.

Uvod

Ta bela knjiga pojasnjuje, kako Microchip PIC64GX zaganja delovne obremenitve aplikacij, in opisuje postopek zagona sistema, ki deluje enako za SMP in AMP delovne obremenitve. Poleg tega pokriva, kako deluje ponovni zagon za SMP in AMP delovne obremenitve, opazovalci na PIC64GX in poseben način zaklepanja za sisteme, kjer stranke želijo popoln nadzor za omejitev dejanj sistemskega monitorja E51 po zagonu sistema.

Postopek zagona

Oglejmo si različne komponente programske opreme, ki sodelujejo pri zagonu sistema, čemur sledi podrobnejši pogled na zaporedje samega toka zagona sistema.

Komponente programske opreme, vključene v zagon
V procesu zagona sistema so vključene naslednje komponente:

Slika 1.1. Zagonske komponente

MICROCHIP-PIC64GX-64-Bit-RISC-V-Štirijedrni-Mikroprocesor-Slika- (1)

  • Storitve programske opreme Hart (HSS)
    Storitve programske opreme Hart (HSS) so ničelnetage-zagonski nalagalnik, sistemski nadzornik in ponudnik izvajalnih storitev za aplikacije. HSS podpira zgodnjo nastavitev sistema, usposabljanje DDR in inicializacijo/konfiguracijo strojne opreme. Večinoma deluje na E51s, z majhno količino funkcionalnosti na ravni strojnega načina, ki se izvaja na vsakem U54s. Zažene enega ali več kontekstov z nalaganjem »koristnega tovora« aplikacije iz zagonskega medija in zagotavlja storitve izvajalnega okolja platforme/izvajalnega okolja nadzornika (SEE) za jedra operacijskega sistema. Podpira varen zagon in je pomembna komponenta pri zagotavljanju particioniranja/ločevanja strojne opreme za AMP konteksti.
  • Das U-Boot (U-Boot)
    Das U-Boot (U-Boot) je odprtokodni univerzalni zagonski nalagalnik s skripti. Podpira preprost CLI, ki lahko pridobi zagonsko sliko iz različnih virov (vključno s kartico SD in omrežjem). U-Boot naloži Linux. Po potrebi lahko zagotovi okolje UEFI. Običajno je končan in ni na poti, ko se Linux zažene – z drugimi besedami, ne ostane rezidenčen po zagonu.
  • Jedro Linuxa
    Jedro Linuxa je najbolj priljubljeno jedro operacijskega sistema na svetu. V kombinaciji z uporabniškim področjem aplikacij tvori tisto, kar običajno imenujemo operacijski sistem Linux. Operacijski sistem Linux ponuja bogate API-je POSIX in okolje za razvijalce, nprample, jeziki in orodja, kot so Python, Perl, Tcl, Rust, C/C++ in Tcl; knjižnice, kot so OpenSSL, OpenCV, OpenMP, OPC/UA in OpenAMP (RPmsg in RemoteProc).
    Yocto in Buildroot sta graditelja sistemov Linux, kar pomeni, da ju je mogoče uporabiti za ustvarjanje sistemov Linux po meri. Yocto izda distribucijo Linuxa z bogatim
    nabor aplikacij, orodij in knjižnic ter izbirno upravljanje paketov. Buildroot ustvari bolj minimalen koren filesistem in lahko cilja na sisteme, ki ne potrebujejo trajnega pomnilnika, ampak delujejo v celoti iz RAM-a (z uporabo podpore za začetnice Linuxa, npr.ample).
  • Zephyr
    Zephyr je majhen odprtokodni operacijski sistem v realnem času (RTOS). Zagotavlja ogrodje z nizkimi stroški v realnem času z lahkimi komunikacijskimi kanali RPMsg za Linux. Vključuje jedro, knjižnice, gonilnike naprav, sklade protokolov, filesistemov, mehanizmov za posodobitve vdelane programske opreme itd., in je odličen za stranke, ki želijo bolj golo kovinsko izkušnjo na PIC64GX.

Potek zagona
PIC64GX vključuje RISC-V coreplex s 64-bitnim sistemskim monitorjem E51 in 4 64-bitnimi aplikacijami U54. V terminologiji RISC-V je hart kontekst izvajanja RISC-V, ki vsebuje celoten niz registrov in neodvisno izvaja svojo kodo. Lahko si ga predstavljate kot nit strojne opreme ali en CPU. Skupino jelen znotraj enega jedra pogosto imenujemo kompleks. Ta tema opisuje korake za inicializacijo coreplexa PIC64GX, vključno s sistemom E51 za spremljanje srca in aplikacijo U54.

  1. Vklopite PIC64GX coreplex.
    Ob vklopu varnostni krmilnik sprosti vse kartice v jedrnem kompleksu RISC-V iz ponastavitve.
  2. Zaženite kodo HSS iz bliskovnega pomnilnika eNVM na čipu.
    Na začetku vsako srce začne izvajati kodo HSS iz bliskovnega pomnilnika eNVM na čipu. Ta koda povzroči, da se vsi programski harti U54 vrtijo in čakajo na navodila, in omogoča, da monitorski hart E51 začne izvajati kodo za inicializacijo in priklic sistema.
  3. Razširite kodo HSS iz eNVM v pomnilnik L2-Scratch.
    Odvisno od konfiguracije časa gradnje je HSS običajno večji od zmogljivosti samega bliskovnega pomnilnika eNVM, zato je prva stvar, ki jo naredi koda HSS, ki se izvaja na E51, dekompresija iz eNVM v pomnilnik L2-Scratch, kot je prikazano na sliki 1.2 in slika 1.3.
    Slika 1.2. HSS dekompresira iz eNVM v L2 ScratchMICROCHIP-PIC64GX-64-Bit-RISC-V-Štirijedrni-Mikroprocesor-Slika- (2)
    Slika 1.3. Zemljevid pomnilnika HSS med dekompresijoMICROCHIP-PIC64GX-64-Bit-RISC-V-Štirijedrni-Mikroprocesor-Slika- (3)
  4. Preskočite z eNVM na L2-Scratch v izvršljivo datoteko, kot je prikazano na naslednji sliki.
    Slika 1.4. HSS preskoči iz eNVM v kodo zdaj v L2Scratch po dekompresijiMICROCHIP-PIC64GX-64-Bit-RISC-V-Štirijedrni-Mikroprocesor-Slika- (4)
    Izvedljiva datoteka je sestavljena iz treh komponent:
    • Sloj abstrakcije strojne opreme (HAL), nizkonivojska koda in goli gonilniki
    • Lokalna HSS fork RISC-V OpenSBI (nekoliko spremenjena od navzgor na PIC64GX za AMP namene)
    • Storitve izvajalnega časa HSS (stanje delujejo v super zanki)
  5. Inicializirajte strojno opremo in podatkovne strukture, ki jih uporablja OpenSBI.
    Za to inicializacijo je odgovorna storitev HSS »Startup«.
  6. Pridobite sliko delovne obremenitve aplikacije (payload.bin) iz zunanjega pomnilnika. To je prikazano na sliki 1.5 in sliki 1.6
    Pomembno: V primeru PIC64GX Curiosity Kit bo to s kartice SD.
    Slika 1.5. Pridobivanje slike delovne obremenitve payload.bin iz zunanjega pomnilnikaMICROCHIP-PIC64GX-64-Bit-RISC-V-Štirijedrni-Mikroprocesor-Slika- (5)
    Slika 1.6. Zemljevid pomnilnika HSS po pridobivanju payload.binMICROCHIP-PIC64GX-64-Bit-RISC-V-Štirijedrni-Mikroprocesor-Slika- (6)
  7. Kopirajte različne odseke iz payload.bin na njihove cilje časa izvajanja. Payload.bin je formatirana slika, ki združuje različne slike aplikacij za SMP oz AMP delovne obremenitve. Vključuje tabele s kodo, podatki in deskriptorji, ki HSS omogočajo, da ustrezno postavi razdelke kode in podatkov, kjer so potrebni za izvajanje različnih delovnih obremenitev aplikacije.
    Slika 1.7. payload.bin je kopiran v ciljne nasloveMICROCHIP-PIC64GX-64-Bit-RISC-V-Štirijedrni-Mikroprocesor-Slika- (7)
  8. Naročite ustreznim U54, naj skočijo na svoje začetne naslove izvajanja. Te informacije o začetnem naslovu so v datoteki payload.bin.
  9. Zaženite aplikacijo U54 Harts in katero koli sekundotage zagonski nalagalniki. Na primerample, U-Boot odpre Linux.

Znova zaženite

S konceptom zagona sistema je povezana potreba po ponovnem zagonu. Ko razmišljate o delovnih obremenitvah aplikacije PIC64GX, je treba pri ponovnem zagonu upoštevati tako simetrično večprocesiranje (SMP) kot asimetrično večprocesiranje (AMP) scenariji:

  1. V primeru sistema SMP lahko ponovni zagon varno hladno znova zažene celoten sistem, saj ni dodatnih delovnih obremenitev v drugem kontekstu, ki bi jih bilo treba upoštevati.
  2. V primeru an AMP sistem, je lahko delovni obremenitvi dovoljeno le, da se znova zažene (in ne posega v noben drug kontekst) ali pa ima privilegij, da lahko izvede celoten ponovni zagon sistema.

Znova zaženite in AMP
Če želite omogočiti SMP in AMP scenarijih ponovnega zagona HSS podpira koncepte privilegijev toplega in hladnega ponovnega zagona, ki jih je mogoče dodeliti kontekstu. Kontekst s privilegijem toplega ponovnega zagona se lahko znova zažene samo sam, kontekst s privilegijem hladnega ponovnega zagona pa lahko izvede popoln ponovni zagon sistema. Na primerample, razmislite o naslednjem nizu reprezentativnih scenarijev.

  • Delovna obremenitev SMP z enim kontekstom, ki lahko zahteva popoln vnovični zagon sistema
  • V tem scenariju je kontekstu dovoljen privilegij hladnega ponovnega zagona.
  • Dvojni kontekst AMP delovna obremenitev, kjer je kontekstu A dovoljeno zahtevati popoln vnovični zagon sistema (ki vpliva na vse kontekste), kontekstu B pa je dovoljeno, da se znova zažene le sam
  • V tem scenariju je kontekstu A dovoljen privilegij hladnega ponovnega zagona, kontekstu B pa je dovoljen privilegij toplega ponovnega zagona.
  • Dvojni kontekst AMP delovna obremenitev, kjer je dovoljeno, da se konteksta A in B znova zaženeta sama (in ne vplivata na drug kontekst)
  • V tem scenariju imata oba konteksta dovoljene samo privilegije toplega ponovnega zagona.
  • Dvojni kontekst AMP delovna obremenitev, pri čemer lahko konteksta A in B zahtevata popolne vnovične zagone sistema
  • V tem scenariju imata oba konteksta dovoljene privilegije hladnega ponovnega zagona.
  • Poleg tega je možno, da HSS v času gradnje vedno dovoli privilegij hladnega ponovnega zagona in nikoli ne dovoli privilegija hladnega ponovnega zagona.

Ustrezne možnosti HSS Kconfig
Kconfig je konfiguracijski sistem za gradnjo programske opreme. Običajno se uporablja za izbiro možnosti časa gradnje in za omogočanje ali onemogočanje funkcij. Izvira iz jedra Linuxa, zdaj pa je našel uporabo v drugih projektih zunaj jedra Linuxa, vključno z U-Boot, Zephyr in PIC64GX HSS.

HSS vsebuje dve možnosti Kconfig, ki nadzirata funkcijo ponovnega zagona z vidika HSS:

  • CONFIG_ALLOW_COLD PONOVNI ZAGON
    Če je to omogočeno, globalno dovoli kontekstu, da izda e-klic hladnega ponovnega zagona. Če je onemogočeno, bodo dovoljeni samo topli ponovni zagoni. Poleg omogočanja te možnosti je treba dovoljenje za izdajo hladnega ponovnega zagona dodeliti kontekstu prek generatorja koristne obremenitve YAML file ali naslednjo možnost Kconfig.
  • CONFIG_ALLOW_COLD REBOOT_ALWAYS
    • Če je omogočena, ta funkcija globalno omogoča vsem kontekstom izdajo hladnega ponovnega zagona ECAA, ne glede na pooblastila zastavice payload.bin.
    • Poleg tega lahko sam payload.bin vsebuje zastavico za vsak kontekst, ki označuje, da je določen kontekst upravičen do izdajanja hladnih ponovnih zagonov:
      • Če želite omogočiti topel ponovni zagon konteksta v drugem kontekstu, lahko v opis YAML dodamo možnost allow-reboot: warm file uporabljen za ustvarjanje payload.bin
      • Če želite omogočiti kontekstni hladni ponovni zagon celotnega sistema, lahko dodamo možnost allow-reboot: cold. Privzeto, brez določitve dovoli ponovni zagon, je kontekstu dovoljen le sam topli ponovni zagon. Ne glede na nastavitev te zastavice, če CONFIG_ALLOW_COLDREBOOT ni omogočen v HSS, bo HSS predelal vse zahteve po hladnem ponovnem zagonu v tople ponovne zagone (na kontekst). .

Ponovni zagon v podrobnostih
V tem razdelku je podrobno opisano, kako deluje ponovni zagon – začenši s plastjo OpenSBI (najnižja plast M-mode) in nato obravnava, kako se ta funkcionalnost plasti OpenSBI sproži iz aplikacije RTOS ali bogatega OS, kot je Linux.

OpenSBI Ponovno zaženite e-klic

  • Specifikacija binarnega vmesnika nadzornika RISC-V (SBI) opisuje standardizirano plast abstrakcije strojne opreme za inicializacijo platforme in storitve izvajalnega okolja vdelane programske opreme. Glavni namen SBI je omogočiti prenosljivost in združljivost v različnih izvedbah RISC-V.
  • OpenSBI (Open Source Supervisor Binary Interface) je odprtokodni projekt, ki zagotavlja referenčno izvedbo specifikacije SBI. OpenSBI ponuja tudi izvajalne storitve, vključno z obravnavanjem prekinitev, upravljanjem časovnika in konzolnim V/I, ki jih lahko uporabljajo plasti programske opreme višje ravni.
  • OpenSBI je vključen kot del HSS in deluje na ravni strojnega načina. Ko operacijski sistem ali aplikacija povzroči past, bo posredovana OpenSBI, da jo obravnava. OpenSBI izpostavi določeno funkcijo vrste sistemskega klica zgornjim plastem programske opreme prek posebnega mehanizma pasti, imenovanega ecall.
  • Sistemska ponastavitev (EID 0x53525354) ponuja obsežno funkcijo sistemskega klica, ki programski opremi zgornje plasti omogoča, da zahteva ponovni zagon ali zaustavitev na ravni sistema. Ko ta ecall prikliče U54, ga ujame programska oprema HSS, ki se izvaja v strojnem načinu na tem U54, in ustrezna zahteva za ponovni zagon je poslana na E51 za ponovni zagon konteksta ali celotnega sistema, odvisno od pooblastil za kontekstu.

Za več informacij glejte Specifikacija binarnega vmesnika nadzornika RISC-V posebej Razširitev za ponastavitev sistema (EID št. 0x53525354 »SRST«).

Ponovni zagon Linuxa

Kot konkreten bivšiampNa podlagi tega se v Linuxu ukaz za zaustavitev uporablja za zaustavitev ali ponovni zagon sistema. Ukaz ima običajno veliko vzdevkov, in sicer zaustavitev, izklop in ponovni zagon. Ti vzdevki določajo, ali naj se stroj zaustavi ob zaustavitvi, izklopi stroj ob zaustavitvi ali znova zažene stroj ob zaustavitvi.

  • Ti ukazi uporabniškega prostora izdajo sistemski klic za ponovni zagon Linuxu, ki ga jedro ujame in poveže z e-klicem SBI.
  • Obstajajo različne ravni ponovnega zagona – REBOOT_WARM, REBOOT_COLD, REBOOT_HARD – te je mogoče kot argumente ukazne vrstice posredovati jedru (npr.ample, reboot=w[arm] za REBOOT_WARM). Za več informacij o izvorni kodi jedra Linux glejte Dokumentacija/admin-guide/kernel-paramters.txt.
  • Druga možnost je, da je /sys/kernel/reboot omogočen, lahko spodnje upravljalnike preberete, da dobite trenutno konfiguracijo ponovnega zagona sistema, in jih napišete, da jih spremenite. Za več informacij o izvorni kodi jedra Linux glejte Dokumentacija/ABI/testiranje/sysfs-kernel-reboot.

Psi čuvaji

  • Nadaljnji koncept, povezan z zagonom in ponovnim zagonom sistema, je obnovitev sistema po sprožitvi nadzornega časovnika. Watchdog timers se pogosto uporabljajo v vgrajenih sistemih za samodejno okrevanje po prehodnih napakah strojne opreme in za preprečevanje napačne ali zlonamerne programske opreme, da bi motila delovanje sistema.
  • PIC64GX vključuje podporo za nadzor strojne opreme za spremljanje posameznih povezav med delovanjem sistema. Stražarji zagotavljajo, da je Harts mogoče znova zagnati, če se ne odzovejo zaradi nepopravljivih programskih napak.
  • PIC64GX vključuje pet primerkov blokov strojne opreme nadzornega časovnika, ki se uporabljajo za zaznavanje zaklepanja sistema - po enega za vsak hart. Za olajšanje mešanega asimetričnega večprocesiranja (AMP) delovnih obremenitev, HSS podpira spremljanje in odzivanje na sprožitev nadzornih psov.

PIC64GX Watchdog

  • HSS je odgovoren za zagon aplikacijskih programov ob vklopu in za njihov ponovni zagon (posamezno ali skupno) ob katerem kolitage, če bi bilo potrebno ali zaželeno. Posledica tega je, da odziv na nadzorne dogodke na PIC64GX obravnava HSS.
  • Nadzornik 'navideznega čuvaja' je implementiran kot storitev državnega stroja HSS, njegova odgovornost pa je spremljanje statusa vsakega od posameznih monitorjev strojne opreme nadzornika U54. Ko eden od teh nadzornih psov U54 sproži, HSS to zazna in ustrezno znova zažene U54. Če je U54 del konteksta SMP, se za vnovični zagon šteje celoten kontekst, glede na to, da ima kontekst privilegij za topel vnovični zagon. Celoten sistem se bo znova zagnal, če ima kontekst privilegij hladnega ponovnega zagona.

Ustrezne možnosti Kconfig

  • Podpora Watchdog je privzeto vključena v izdane gradnje HSS. Če želite zgraditi HSS po meri, bo ta razdelek opisal konfiguracijski mehanizem za zagotovitev, da je podpora Watchdog omogočena.
  • HSS je konfiguriran s konfiguracijskim sistemom Kconfig. Najvišja raven .config file je potreben za izbiro storitev, ki bodo prevedene v zgradbo HSS ali iz nje.
  • Najprej mora biti omogočena možnost CONFIG_SERVICE_WDOG na najvišji ravni (»podpora za navidezni čuvaj« prek make config).

To nato razkrije naslednje podmožnosti, ki so odvisne od podpore Watchdog:

  • CONFIG_SERVICE_WD OG_DEBUG
    Omogoča podporo za informativna sporočila/sporočila za odpravljanje napak iz storitve navideznega čuvaja.
  • CONFIG_SERVICE_WD OG_DEBUG_TIMEOUT_SECS
    Določa periodičnost (v sekundah), v kateri bo HSS poslal sporočila o odpravljanju napak Watchdog.
  • CONFIG_SERVICE_WD OG_ENABLE_E51
    Omogoči čuvaja za E51 spremlja srce poleg U54s, ščiti delovanje samega HSS.

Ko je nadzorni pas E51 omogočen, bo HSS občasno pisal nadzornemu psu, da ga osveži in prepreči njegovo sprožitev. Če se srce E51 iz nekega razloga zaklene ali se zruši in je nadzorni pes E51 omogočen, bo to vedno ponastavilo celoten sistem.

Operacija Watchdog
Strojna oprema Watchdog izvaja nizke števce. Okno s prepovedjo osveževanja lahko ustvarite tako, da konfigurirate največjo vrednost nadzornega psa, do katere je dovoljena osvežitev (MVRP).

  • Ko je trenutna vrednost časovnika nadzornika večja od vrednosti MVRP, je osveževanje nadzornika prepovedano. Poskus osvežitve časovnika čuvaja v prepovedanem oknu bo uveljavil prekinitev časovne omejitve.
  • Osvežitev nadzornega psa med vrednostjo MVRP in sprožilno vrednostjo (TRIG) bo uspešno osvežila števec in preprečila sprožitev nadzornega psa.
  • Ko je vrednost časovnika čuvaja pod vrednostjo TRIG, se sproži nadzornik.

Watchdog State Machine

  • Stroj čuvaja stanja je zelo preprost – zagon s konfiguracijo psa čuvaja za E51, če je omogočen, nato pa se pomakne iz stanja mirovanja v nadzor. Vsakič okoli superzanke se prikliče to stanje spremljanja, ki preveri status vsakega od nadzornih psov U54.
  • Watchdog state machine sodeluje z zagonskim stanjem stroja, da znova zažene hart (in vse druge harte, ki so v njegovem zagonskem naboru), če zazna, da hart ni uspel pravočasno osvežiti svojega čuvaja.

Način zaklepanja

Običajno (predvsem z AMP aplikacij), se pričakuje, da bo HSS ostal rezidenčen v M-načinu na U54, da bo omogočil ponovni zagon po kontekstu (tj. ponovni zagon samo enega konteksta, brez ponovnega zagona celotnega čipa) in da bo HSS omogočil spremljanje stanja ( ECC, biti statusa zaklepanja, napake vodila, napake SBI, kršitve PMP itd.).

MICROCHIP-PIC64GX-64-Bit-RISC-V-Štirijedrni-Mikroprocesor-Slika- (8)

  • Da bi zagotovili zmožnosti ponovnega zagona naAMP na podlagi konteksta (brez potrebe po ponovnem zagonu celotnega sistema), ima E51 običajno privilegiran dostop do pomnilnika do celotnega pomnilniškega prostora sistema. Vendar pa lahko pride do situacij, ko to ni zaželeno, in stranka morda raje omeji, kaj počne vdelana programska oprema E51 HSS, ko se sistem uspešno zažene. V tem primeru je mogoče HSS preklopiti v način zaklepanja, ko se program U54 Application Harts zažene.
  • To lahko omogočite z možnostjo HSS Kconfig CONFIG_SERVICE_LOCKDOWN.
  • Storitev zaklepanja je namenjena omejevanju dejavnosti HSS po zagonu aplikacije U54 Harts.

Slika 4.2. Način zaklepanja HSS

MICROCHIP-PIC64GX-64-Bit-RISC-V-Štirijedrni-Mikroprocesor-Slika- (9)

Ko se način zaklepanja začne, ustavi delovanje vseh drugih strojev stanja storitev HSS. Kliče dve šibko vezani funkciji:

  • e51_pmp_lockdown() in
  • e51_lockdown()

Te funkcije naj bi preglasile kode, specifične za ploščo. Prva je nastavljiva sprožilna funkcija, ki BSP-ju omogoča prilagoditev zaklepanja E51 iz koristnih obremenitev aplikacije na tej točki. Šibko vezana privzeta izvedba te funkcije je prazna. Druga je funkcionalnost, ki se izvaja od te točke naprej. Šibko vezana privzeta izvedba servisira nadzornega psa na tej točki v E51 in se bo znova zagnala, če se sproži nadzorni pas U54. Za več informacij glejte izvorno kodo HSS v services/lockdown/lockdown_service.c file.

Dodatek

HSS payload.bin Format

  • Ta razdelek opisuje payload.bin file in sliko, ki jo uporablja HSS za zagon PIC64GX SMP in AMP aplikacije.
  • Payload.bin je formatirana dvojiška datoteka (slika A.10), sestavljena iz glave, različnih deskriptorskih tabel in različnih delov, ki vsebujejo odseke kode in podatkov vsakega dela delovne obremenitve aplikacije. Kos lahko obravnavamo kot sosednji blok pomnilnika poljubne velikosti.

Slika A.10. oblika payload.bin

MICROCHIP-PIC64GX-64-Bit-RISC-V-Štirijedrni-Mikroprocesor-Slika- (10)

Del glave (prikazan na sliki A.11) vsebuje čarobno vrednost, ki se uporablja za identifikacijo payload.bin in nekaj podatkov o vzdrževanju, skupaj s podrobnostmi o sliki, ki naj bi se izvajala na vsakem od
U54 aplikacijske kode. Opisuje, kako zagnati vsak posamezni hart U54 in nabor zagonskih slik na splošno. V svojih skrbniških informacijah ima kazalce na različne tabele deskriptorjev, ki omogočajo povečanje velikosti glave.

Slika A.11. glava payload.bin

MICROCHIP-PIC64GX-64-Bit-RISC-V-Štirijedrni-Mikroprocesor-Slika- (11)

  • Koda in inicializirani konstantni podatki veljajo samo za branje in so shranjeni v razdelku samo za branje, na katerega kažejo deskriptorji glave.
  • Inicializirane podatkovne spremenljivke, ki niso ničle, so podatki za branje in pisanje, vendar se njihove inicializacijske vrednosti ob zagonu prekopirajo iz odseka samo za branje. Ti so prav tako shranjeni v razdelku samo za branje.
  • Podatkovni razdelek samo za branje je opisan s tabelo kode in deskriptorjev kosov podatkov. Vsak deskriptor kosa v tej tabeli vsebuje 'lastnik harta' (glavni hart v kontekstu, na katerega je ciljan
    at), odmik nalaganja (odmik znotraj payload.bin) in naslov izvajanja (ciljni naslov v pomnilniku PIC64GX), skupaj z velikostjo in kontrolno vsoto. To je prikazano na sliki A.12.

Slika A.12. Deskriptor kosov samo za branje in podatki o kosih koristnega tovora

MICROCHIP-PIC64GX-64-Bit-RISC-V-Štirijedrni-Mikroprocesor-Slika- (12)

Poleg zgoraj omenjenih kosov obstajajo tudi deli pomnilnika, ki ustrezajo podatkovnim spremenljivkam, ki so inicializirane na nič. Ti niso shranjeni kot podatki v payload.bin, ampak so namesto tega poseben nabor ničelno inicializiranih deskriptorjev kosov, ki določajo naslov in dolžino RAM-a, ki se med zagonom nastavi na nič. To je prikazano na sliki A.13.

Slika A.13. ZI kosi

MICROCHIP-PIC64GX-64-Bit-RISC-V-Štirijedrni-Mikroprocesor-Slika- (13)

hss-generator-tovora
Orodje HSS Payload Generator ustvari oblikovano sliko koristnega tovora za programsko opremo Hart Software Service zero-stage zagonski nalagalnik na PIC64GX glede na konfiguracijo file in komplet ELF files in/ali binarne datoteke. Konfiguracija file se uporablja za preslikavo binarnih datotek ELF ali binarnih blobov v posamezne harte aplikacij (U54).

Slika B.14. hss-payload-generator Tok

MICROCHIP-PIC64GX-64-Bit-RISC-V-Štirijedrni-Mikroprocesor-Slika- (14)

Orodje izvaja osnovne preglede razumnosti strukture konfiguracije file in na slikah ELF. Slike ELF morajo biti izvedljive datoteke RISC-V.

Example Run

  • Za zagon orodja hss-payload-generator s sample konfiguracijo file in ELF files:
    $ ./hss-payload-generator -c test/config.yaml output.bin
  • Če želite natisniti diagnostiko o že obstoječi sliki, uporabite:
    $ ./hss-payload-generator -d output.bin
  • Če želite omogočiti preverjanje pristnosti pri varnem zagonu (prek podpisovanja slike), uporabite -p, da določite lokacijo zasebnega ključa X.509 za Elliptic Curve P-384 (SECP384r1):
    $ ./hss-payload-generator -c test/config.yaml payload.bin -p /path/to/private.pem

Za več informacij si oglejte dokumentacijo o preverjanju pristnosti varnega zagona.

Config File Example

  • Najprej lahko izbirno nastavimo ime za našo sliko, sicer bo ena ustvarjena dinamično:
    nastavljeno ime: 'PIC64-HSS::TestImage'
  • Nato bomo definirali naslove vstopnih točk za vsako srce, kot sledi:
    hart-entry-points: {u54_1: ‘0x80200000’, u54_2: ‘0x80200000’, u54_3: ‘0xB0000000′, u54_4:’0x80200000’}

Izvorne slike ELF lahko določijo vstopno točko, vendar želimo imeti možnost podpore sekundarnih vstopnih točk za harts, če je to potrebno, npr.ample, če je več hartov namenjenih zagonu iste slike, imajo lahko posamezne vstopne točke. Da bi to podprli, v konfiguraciji določimo dejanske naslove vstopnih točk file sama.

Zdaj lahko definiramo nekaj uporabnih obremenitev (vir ELF files ali binarnih blobov), ki bodo postavljeni v določene regije v pomnilniku. Razdelek koristne obremenitve je definiran s ključno besedo koristne obremenitve in nato s številnimi posameznimi deskriptorji koristne obremenitve. Vsak tovor ima ime (pot do svojega file), lastniški srček in po želji 1 do 3 sekundarni srčki.

Poleg tega ima tovor način privilegijev, v katerem se bo začel izvajati. Veljavni načini privilegijev so PRV_M, PRV_S in PRV_U, kjer so definirani kot:

  • PRV_M Strojni način
  • PRV_S Nadzorniški način
  • PRV_U Uporabniški način

V naslednjem prample:

  • domneva se, da je test/zephyr.elf aplikacija Zephyr, ki se izvaja v U54_3 in pričakuje, da se bo zagnala v načinu privilegijev PRV_M.
  • test/u-boot-dtb.bin je zagonska aplikacija Das U-Boot in deluje na U54_1, U54_2 in U54_4. Pričakuje, da se bo zagnal v načinu privilegijev PRV_S.

Pomembno:
Izhod U-Boot ustvari ELF file, vendar običajno ne doda končnice .elf. V tem primeru je uporabljena binarna datoteka, ki jo je ustvaril CONFIG_OF_SEPARATE, ki doda blob drevesa naprave v binarno datoteko U-Boot.

Tukaj je bivšiample konfiguracijo uporabnih obremenitev file:

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

Pomembno:
Primer je pomemben samo za file imena poti, ne ključne besede. Tako se na primer u54_1 šteje za enako kot U54_1, exec-addr pa za enako kot EXEC-ADDR. Če je prisotna končnica.elf ali .bin, jo je treba vključiti v konfiguracijo file.

  • Za golo kovinsko aplikacijo, ki se ne želi ukvarjati z OpenSBI, bo možnost skip-opens, če je resnična, povzročila, da bo koristna obremenitev na tem srcu priklicana s preprostim ukazom mret.
    kot klic OpenSBI sbi_init(). To pomeni, da bo srce začelo izvajati golo kodo ne glede na morebitne pomisleke OpenSBI HSM. Upoštevajte, da to tudi pomeni, da srce ne more uporabljati
    ecalls za priklic funkcionalnosti OpenSBI. Možnost preskočenega odpiranja je neobvezna in je privzeto nastavljena na false.
  • Če želite omogočiti kontekstni topel ponovni zagon drugega konteksta, lahko dodamo možnost dovoli ponovni zagon: topel. Če želite omogočiti kontekstni hladni ponovni zagon celotnega sistema, lahko dodamo možnost allow-reboot: cold. Privzeto je kontekstu dovoljeno samo, da se ogreje sam ponovni zagon, ne da bi navedel enable-reboot.
  • Možno je tudi povezati pomožne podatke z vsakim tovorom, nprample, DeviceTree Blob (DTB) file, z navedbo pomožnih podatkov fileime kot sledi:
    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, pomožni-podatki : test/pic64gx.dtb }
  • Ti pomožni podatki bodo vključeni v obremenitev (postavljeni takoj za glavnimi file v izvršljivi datoteki
    prostor), njegov naslov pa bo posredovan OpenSBI v polju next_arg1 (posredovanem v registru $a1 v sliko ob zagonu).
  • Če želite preprečiti, da bi HSS samodejno zagnal kontekst (na primer, če želimo namesto tega prenesti nadzor nad tem na kontekst z uporabo remoteProc), uporabite zastavico skip-autoboot:
    test/zephyr.elf: {exec-addr: '0xB0000000', owner-hart: u54_3, priv-mode: prv_m, skip-opensbi: true, skip-autoboot: true}
  • Končno lahko izbirno preglasimo imena posameznih koristnih tovorov z uporabo možnosti payload-name. Na primerample:
    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, pomožni-podatki : test/pic64gx.dtb, koristno ime: 'u-boot' }

Upoštevajte, da bosta graditelja Yocto in Buildroot Linux zgradila, konfigurirala in zagnala hss-payload-
generator, kot je potrebno za ustvarjanje aplikacijskih slik. Poleg tega pic64gx-curiosity-kit-amp strojni cilj v Yoctu bo ustvaril sliko aplikacije z orodjem hss-payload-generator, ki prikazuje AMP, pri čemer Linux deluje na 3 hartih in Zephyr na 1 hartu.

Zgodovina revizij
Zgodovina revizij opisuje spremembe, ki so bile izvedene v dokumentu. Spremembe so navedene po reviziji, začenši z najnovejšo objavo.

Revizija

Datum

Opis

A 07/2024 Začetna revizija

Informacije o mikročipu

mikročip Webmesto
Microchip nudi spletno podporo prek našega webspletno mesto na www.microchip.com/. to webspletno mesto se uporablja za izdelavo filein informacije, ki so zlahka dostopne strankam. Nekatere razpoložljive vsebine vključujejo:

  • Podpora za izdelke – Podatkovni listi in napake, opombe o uporabi in sampprogrami, oblikovalski viri, uporabniški priročniki in podporni dokumenti strojne opreme, najnovejše izdaje programske opreme in arhivirana programska oprema
  • Splošna tehnična podpora – Pogosto zastavljena vprašanja (FAQ), zahteve za tehnično podporo, spletne razpravne skupine, seznam članov partnerskega programa Microchip design
  • Podjetje Microchip – Vodniki za izbiro in naročanje izdelkov, najnovejša sporočila za javnost podjetja Microchip, seznam seminarjev in dogodkov, seznami prodajnih pisarn podjetja Microchip, distributerjev in predstavnikov tovarn

Storitev obveščanja o spremembi izdelka

  • Microchipova storitev obveščanja o spremembah izdelkov pomaga strankam obveščati o izdelkih Microchip. Naročniki bodo prejeli e-poštno obvestilo vsakič, ko pride do sprememb, posodobitev, revizij ali napak v zvezi z določeno družino izdelkov ali razvojnim orodjem, ki jih zanima.
  • Za registracijo pojdite na www.microchip.com/pcn in sledite navodilom za registracijo.

Podpora uporabnikom
Uporabniki izdelkov Microchip lahko prejmejo pomoč prek več kanalov:

  • Distributer ali zastopnik
  • Lokalna prodajna pisarna
  • Inženir za vgrajene rešitve (ESE)
  • Tehnična podpora

Stranke naj se za podporo obrnejo na svojega distributerja, zastopnika ali ESE. Za pomoč strankam so na voljo tudi lokalne prodajne pisarne. Seznam prodajnih pisarn in lokacij je vključen v ta dokument.
Tehnična podpora je na voljo prek webspletno mesto na: www.microchip.com/support.

Funkcija zaščite kode Microchip Devices
Upoštevajte naslednje podrobnosti funkcije zaščite kode na izdelkih Microchip:

  • Izdelki Microchip izpolnjujejo specifikacije v njihovem posebnem podatkovnem listu Microchip.
  • Microchip verjame, da je njegova družina izdelkov varna, če se uporablja na predviden način, v okviru operativnih specifikacij in v normalnih pogojih.
  • Microchip ceni in agresivno ščiti svoje pravice intelektualne lastnine. Poskusi kršitve zaščitnih funkcij kode izdelkov Microchip so strogo prepovedani in lahko kršijo Zakon o elektronskih avtorskih pravicah.
  • Niti Microchip niti kateri koli drug proizvajalec polprevodnikov ne more jamčiti za varnost svoje kode. Zaščita kode ne pomeni, da jamčimo, da je izdelek "nezlomljiv". Zaščita kode se nenehno razvija. Microchip je zavezan nenehnemu izboljševanju funkcij zaščite kode naših izdelkov.

Pravno obvestilo
To publikacijo in informacije v njej lahko uporabljate samo z izdelki Microchip, vključno z načrtovanjem, testiranjem in integracijo izdelkov Microchip z vašo aplikacijo. Uporaba teh informacij na kakršen koli drug način krši te pogoje. Informacije o aplikacijah naprave so na voljo samo za vaše udobje in jih lahko nadomestijo posodobitve. Vaša odgovornost je zagotoviti, da vaša aplikacija ustreza vašim specifikacijam. Za dodatno podporo se obrnite na lokalno prodajno pisarno družbe Microchip ali pridobite dodatno podporo na www.microchip.com/en-us/support/design-help/client-support-services.

TE INFORMACIJE ZAGOTAVLJA MICROCHIP "TAKŠNE, KOT SO". MICROCHIP NE DAJE NOBENIH IZJAV ALI JAMSTEV KAKRŠNE KOLI VRSTE, BODISI IZRECNIH ALI POSREDNIH, PISNIH ALI USTNIH, ZAKONSKIH ALI DRUGAČEH, POVEZANIH Z INFORMACIJAMI, VKLJUČNO, VENDAR NE OMEJENO NA KAKRŠNE KOLI POSREDNE JAMSTVA O NEKRŠITVI, PRIMERNOST ZA PRODAJO IN PRIMERNOST ZA DOLOČEN NAMEN ALI GARANCIJE, POVEZANE Z NJEGOVIM STANJEM, KAKOVOSTJO ALI ZMOGLJIVOSTJO.

MICROCHIP V NOBENEM PRIMERU NE BO ODGOVOREN ZA KAKRŠNO KOLI POSREDNO, POSEBNO, KAZNOVALNO, NAKLJUČNO ALI POSLEDIČNO IZGUBO, ŠKODO, STROŠKE ALI IZDATKE KAKRŠNEKOLI VRSTE, POVEZANE Z INFORMACIJAMI ALI NJIHOVO UPORABO, NE glede na to, KI JE POVZROČENA, TUDI ČE JE MICROCHIP OBVEŠČEN O MOŽNOST ALI ŠKODA JE PREDVIDLJIVA. DO NAJVEČJEGA MERA, KI GA DOVOLJUJE ZAKON, SKUPNA ODGOVORNOST MICROCHIPA ZA VSE ZAHTEVKE, KI SO NA KAKRŠEN KOLI NAČIN POVEZANI Z INFORMACIJO ALI NJENO UPORABO, NE BO PRESEGALA ŠTEVILA PRISTOJBIN, ČE OBSTAJA, KI STE GA PLAČALI NEPOSREDNO MICROCHIPU ZA INFORMACIJO.

Uporaba naprav Microchip v aplikacijah za vzdrževanje življenja in/ali varnost je v celoti na kupčevo tveganje in kupec se strinja, da bo branil, odškodoval in zaščitil Microchip pred kakršno koli škodo, zahtevki, tožbami ali stroški, ki izhajajo iz takšne uporabe. Nobene licence se ne posredujejo, implicitno ali kako drugače, v okviru pravic intelektualne lastnine družbe Microchip, razen če je navedeno drugače.

Blagovne znamke
Ime in logotip Microchip, logotip Microchip, Adaptec, AVR, logotip AVR, AVR Freaks, BesTime, BitCloud, CryptoMemory, CryptoRF, dsPIC, flexPWR, HELDO, IGLOO, JukeBlox, KeeLoq, Kleer, LANCheck, LinkMD, maXStylus, maXTouch, MediaLB, megaAVR, Microsemi, logotip Microsemi, MOST, logotip MOST, MPLAB, OptoLyzer, PIC, picoPower, PICSTART, logotip PIC32, PolarFire, Prochip Designer, QTouch, SAM-BA, SenGenuity, SpyNIC, SST, logotip SST, SuperFlash, Symmetricom , SyncServer, Tachyon, TimeSource, tinyAVR, UNI/O, Vectron in XMEGA so registrirane blagovne znamke družbe Microchip Technology Incorporated v ZDA in drugih državah.

AgileSwitch, ClockWorks, The Embedded Control Solutions Company, EtherSynch, Flashtec, Hyper Speed ​​Control, HyperLight Load, Libero, motorna miza, mTouch, Powermite 3, Precision Edge, ProASIC, ProASIC Plus, logotip ProASIC Plus, Quiet-Wire, SmartFusion, SyncWorld , TimeCesium, TimeHub, TimePictra, TimeProvider in ZL so registrirane blagovne znamke Microchip Technology Incorporated v ZDA

Adjacent Key Suppression, AKS, Analog-for-the-Digital Age, Any Capacitor, AnyIn, AnyOut, Augmented Switching, BlueSky, BodyCom, Clockstudio, CodeGuard, CryptoAuthentication, CryptoAutomotive, CryptoCompanion, CryptoController, dsPICDEM, dsPICDEM.net, Dynamic Average Matching , DAM, ECAN, Espresso T1S, EtherGREEN, EyeOpen, GridTime, IdealBridge,
IGaT, serijsko programiranje v vezju, ICSP, INICnet, inteligentno paraleliziranje, IntelliMOS, povezljivost med čipi, blokiranje tresljajev, gumb na zaslonu, MarginLink, maxCrypto, maks.View, memBrain, Mindi, MiWi, MPASM, MPF, logotip MPLAB Certified, MPLIB, MPLINK, mSiC, MultiTRAK, NetDetach, Omniscient Code Generation, PICDEM, PICDEM.net, PICkit, PICtail, Power MOS IV, Power MOS 7, PowerSmart, PureSilicon , QMatrix, REAL ICE, Ripple Blocker, RTAX, RTG4, SAM-ICE, Serial Quad I/O, preprost zemljevid, SimpliPHY, SmartBuffer, SmartHLS, SMART-IS, storClad, SQI, SuperSwitcher, SuperSwitcher II, Switchtec, SynchroPHY, Total Endurance, Trusted Time, TSHARC, Turing, USBCheck, VariSense, VectorBlox, VeriPHY, ViewSpan, WiperLock, XpressConnect in ZENA so blagovne znamke družbe Microchip Technology Incorporated v ZDA in drugih državah.

  • SQTP je storitvena znamka Microchip Technology Incorporated v ZDA
  • Logotip Adaptec, Frequency on Demand, Silicon Storage Technology in Symmcom so registrirane blagovne znamke Microchip Technology Inc. v drugih državah.
  • GestIC je registrirana blagovna znamka Microchip Technology Germany II GmbH & Co. KG, hčerinske družbe Microchip Technology Inc., v drugih državah.

Vse druge tukaj omenjene blagovne znamke so last njihovih podjetij. © 2024, Microchip Technology Incorporated in njegove podružnice. Vse pravice pridržane.

  • ISBN: 978-1-6683-4890-1

Sistem vodenja kakovosti
Za informacije o Microchipovih sistemih vodenja kakovosti obiščite www.microchip.com/quality.

Prodaja in servis po vsem svetu

AMERIKE

AZIJA/PACIFIK AZIJA/PACIFIK

EVROPA

Korporacija Pisarna

2355 West Chandler Blvd. Chandler, AZ 85224-6199

Tel: 480-792-7200

faks: 480-792-7277

Tehnična podpora: www.microchip.com/support

Web Naslov: www.microchip.com

Atlanta

Duluth, GA

Tel: 678-957-9614

faks: 678-957-1455

Austin, TX

Tel: 512-257-3370

Boston

Westborough, MA Tel.: 774-760-0087

faks: 774-760-0088

Chicago

Itasca, IL

Tel: 630-285-0071

faks: 630-285-0075

Dallas

Addison, Teksas

Tel: 972-818-7423

faks: 972-818-2924

Detroit

Novi, MI

Tel: 248-848-4000

Houston, TX

Tel: 281-894-5983

Indianapolis

Noblesville, IN Tel.: 317-773-8323

faks: 317-773-5453

Tel: 317-536-2380

Los Angeles

Mission Viejo, CA Tel.: 949-462-9523

faks: 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

faks: 905-695-2078

Avstralija – Sydney

Tel.: 61-2-9868-6733

Kitajska – Peking

Tel.: 86-10-8569-7000

Kitajska – Chengdu

Tel.: 86-28-8665-5511

Kitajska - Chongqing

Tel.: 86-23-8980-9588

Kitajska – Dongguan

Tel.: 86-769-8702-9880

Kitajska – Guangzhou

Tel.: 86-20-8755-8029

Kitajska – Hangzhou

Tel.: 86-571-8792-8115

Kitajska Hong Kong SAR

Tel.: 852-2943-5100

Kitajska - Nanjing

Tel.: 86-25-8473-2460

Kitajska – Qingdao

Tel.: 86-532-8502-7355

Kitajska – Šanghaj

Tel.: 86-21-3326-8000

Kitajska – Shenyang

Tel.: 86-24-2334-2829

Kitajska – Shenzhen

Tel.: 86-755-8864-2200

Kitajska – Suzhou

Tel.: 86-186-6233-1526

Kitajska – Wuhan

Tel.: 86-27-5980-5300

Kitajska – Xian

Tel.: 86-29-8833-7252

Kitajska - Xiamen

Tel.: 86-592-2388138

Kitajska - Zhuhai

Tel.: 86-756-3210040

Indija Bangalore

Tel.: 91-80-3090-4444

Indija – New Delhi

Tel.: 91-11-4160-8631

Indija Pune

Tel.: 91-20-4121-0141

Japonska Osaka

Tel.: 81-6-6152-7160

Japonska Tokio

Tel: 81-3-6880-3770

Koreja – Daegu

Tel.: 82-53-744-4301

Koreja – Seul

Tel.: 82-2-554-7200

Malezija – Kuala Lumpur

Tel.: 60-3-7651-7906

Malezija – Penang

Tel.: 60-4-227-8870

Filipini Manila

Tel.: 63-2-634-9065

Singapur

Tel.: 65-6334-8870

Tajvan – Hsin Ču

Tel.: 886-3-577-8366

Tajvan - Kaohsiung

Tel.: 886-7-213-7830

Tajvan - Taipei

Tel.: 886-2-2508-8600

Tajska – Bangkok

Tel.: 66-2-694-1351

Vietnam – Ho Chi Minh

Tel.: 84-28-5448-2100

Avstrija Wels

Tel.: 43-7242-2244-39

Faks: 43-7242-2244-393

Danska Kopenhagen

Tel.: 45-4485-5910

Faks: 45-4485-2829

Finska Espoo

Tel.: 358-9-4520-820

Francija Pariz

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

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

Nemčija garching

Tel.: 49-8931-9700

Nemčija Haan

Tel.: 49-2129-3766400

Nemčija Heilbronn

Tel.: 49-7131-72400

Nemčija Karlsruhe

Tel.: 49-721-625370

Nemčija München

Tel: 49-89-627-144-0

Fax: 49-89-627-144-44

Nemčija Rosenheim

Tel.: 49-8031-354-560

Izrael – Hod Hasharon

Tel.: 972-9-775-5100

Italija – Milano

Tel.: 39-0331-742611

Faks: 39-0331-466781

Italija – Padova

Tel.: 39-049-7625286

Nizozemska – Drunen

Tel.: 31-416-690399

Faks: 31-416-690340

Norveška Trondheim

Tel: 47-72884388

Poljska – Varšava

Tel.: 48-22-3325737

Romunija Bukarešta

Tel: 40-21-407-87-50

Španija - Madrid

Tel: 34-91-708-08-90

Fax: 34-91-708-08-91

Švedska – Göteborg

Tel: 46-31-704-60-40

Švedska – Stockholm

Tel.: 46-8-5090-4654

Velika Britanija – Wokingham

Tel.: 44-118-921-5800

Faks: 44-118-921-5820

© 2024 Microchip Technology Inc. in njegove podružnice.

Dokumenti / Viri

MICROCHIP PIC64GX 64-bitni štirijedrni mikroprocesor RISC-V [pdf] Uporabniški priročnik
PIC64GX, PIC64GX 64-bitni štirijedrni mikroprocesor RISC-V, 64-bitni štirijedrni mikroprocesor RISC-V, štirijedrni mikroprocesor RISC-V, štirijedrni mikroprocesor, mikroprocesor

Reference

Pustite komentar

Vaš elektronski naslov ne bo objavljen. Obvezna polja so označena *