MICROCHIP PIC64GX 64-Bit RISC-V Quad-Core Microprocessor User Guide

Proseso ng Boot
1. Mga Bahagi ng Software na Kasangkot sa Pag-boot
  Ang proseso ng pag-boot ng system ay kinabibilangan ng mga sumusunod na bahagi ng software:
  - Hart Software Services (HSS): Isang zero-stage boot loader, system monitor, at provider ng runtime services para sa mga application.
2. Daloy ng Boot
  Ang pagkakasunud-sunod ng daloy ng boot ng system ay ang mga sumusunod:
  1. Pagsisimula ng Hart Software Services (HSS)
  2. Pagpapatupad ng bootloader
  3. Pagsisimula ng aplikasyon
Mga asong nagbabantay
1. PIC64GX Watchdog
  Nagtatampok ang PIC64GX ng function ng watchdog upang subaybayan ang pagpapatakbo ng system at mag-trigger ng mga aksyon sa kaso ng mga pagkabigo ng system.
LockdownMode
Idinisenyo ang lockdown mode para sa mga customer na nangangailangan ng kumpletong kontrol sa mga aksyon ng system pagkatapos mag-boot. Nililimitahan nito ang mga functionality ng E51 system monitor.

FAQ

T: Ano ang layunin ng Hart Software Services (HSS)?
A: Ang HSS ay nagsisilbing zero-stage boot loader, system monitor, at provider ng mga serbisyo ng runtime para sa mga application sa panahon ng proseso ng boot.
Q: Paano gumagana ang PIC64GX watchdog function?
A: Ang PIC64GX watchdog ay sinusubaybayan ang pagpapatakbo ng system at maaaring gumawa ng mga paunang natukoy na aksyon sa kaso ng mga pagkabigo ng system upang matiyak ang pagiging maaasahan ng system.

Panimula

Ipinapaliwanag ng whitepaper na ito kung paano ibino-boot ng Microchip PIC64GX ang mga workload ng application at inilalarawan ang proseso ng pag-boot ng system, na parehong gumagana para sa SMP at AMP mga workload. Bukod pa rito, sinasaklaw nito kung paano gumagana ang isang reboot para sa SMP at AMP workload, watchdog sa PIC64GX, at isang espesyal na mode ng lockdown para sa mga system kung saan nais ng mga customer ang kumpletong kontrol upang limitahan ang mga aksyon ng E51 system monitor pagkatapos ng system boot.

Proseso ng Boot

Tingnan natin ang iba't ibang bahagi ng software na kasangkot sa system bootup, na sinusundan ng mas detalyadong pagtingin sa pagkakasunud-sunod ng system boot flow mismo.

Mga Bahagi ng Software na Kasangkot sa Pag-boot
Ang mga sumusunod na bahagi ay kasangkot sa proseso ng pag-boot-up ng system:

Larawan 1.1. Mga Bahagi ng Boot-up

Hart Software Services (HSS)
Ang Hart Software Services (HSS) ay isang zero-stage boot loader, isang system monitor, at isang provider ng mga serbisyo ng runtime para sa mga application. Sinusuportahan ng HSS ang maagang pag-setup ng system, pagsasanay sa DDR, at pagsisimula/pag-configure ng hardware. Ito ay kadalasang tumatakbo sa mga E51, na may maliit na halaga ng paggana sa antas ng machine-mode na tumatakbo sa bawat U54. Nagbo-boot ito ng isa o higit pang mga konteksto sa pamamagitan ng pag-load ng "payload" ng application mula sa boot medium, at nagbibigay ng Platform Runtime Services/Supervisor Execution Environment (SEE) para sa mga kernel ng operating system. Sinusuportahan nito ang secure na boot at isang mahalagang bahagi sa pagtiyak ng hardware partitioning/separation para sa AMP mga konteksto.

Das U-Boot (U-Boot)
Ang Das U-Boot (U-Boot) ay isang open-source na unibersal na scriptable boot loader. Sinusuportahan nito ang isang simpleng CLI na maaaring makuha ang imahe ng boot mula sa iba't ibang mga mapagkukunan (kabilang ang isang SD Card at ang Network). Nilo-load ng U-Boot ang Linux. Maaari itong magbigay ng UEFI na kapaligiran kung kinakailangan. Ito ay karaniwang tapos na at wala sa paraan kapag nag-boot na ang Linux – sa madaling salita, hindi ito mananatiling resident post-boot.
Linux Kernel
Ang Linux kernel ay ang pinakasikat na operating system kernel sa mundo. Pinagsama sa isang userland ng mga application, ito ay bumubuo ng kung ano ang karaniwang tinutukoy bilang isang Linux operating system. Ang Linux Operating System ay nagbibigay ng mga rich POSIX API at developer environment, halimbawaample, mga wika at tool gaya ng Python, Perl, Tcl, Rust, C/C++, at Tcl; mga aklatan gaya ng OpenSSL, OpenCV, OpenMP, OPC/UA, at OpenAMP (RPmsg at RemoteProc).
Ang Yocto at Buildroot ay mga tagabuo ng Linux system, ibig sabihin, magagamit ang mga ito upang makabuo ng mga pasadyang customized na Linux system. Ang Yocto ay naglalabas ng pamamahagi ng Linux na may mayaman
set ng mga application, tool, at library, at opsyonal na pamamahala ng package. Ang Buildroot ay naglalabas ng mas kaunting ugat filesystem at maaaring mag-target ng mga system na hindi nangangailangan ng patuloy na imbakan ngunit ganap na tumatakbo mula sa RAM (gamit ang suporta sa inisyal ng Linux, para sa example).

Zephyr
Ang Zephyr ay isang maliit, open-source na Real-Time Operating System (RTOS). Nagbibigay ito ng Real-Time Low-Overhead Framework, na may RPMsg-lite na mga channel ng komunikasyon sa Linux. Kabilang dito ang isang kernel, mga aklatan, mga driver ng device, mga stack ng protocol, filesystem, mekanismo para sa pag-update ng firmware, at iba pa, at ito ay mahusay para sa mga customer na gustong magkaroon ng mas hubad na metal na karanasan sa PIC64GX.

Daloy ng Boot
Kasama sa PIC64GX ang isang RISC-V coreplex na may 64-bit E51 system monitor hart at 4 na 64-bit U54 application hart. Sa terminolohiya ng RISC-V, ang isang hart ay isang konteksto ng pagpapatupad ng RISC-V na naglalaman ng isang buong hanay ng mga rehistro at independiyenteng nagpapatupad ng code nito. Maaari mong isipin ito bilang isang hardware thread o isang solong CPU. Ang isang grupo ng mga hart sa loob ng isang core ay madalas na tinatawag na isang complex. Inilalarawan ng paksang ito ang mga hakbang upang simulan ang PIC64GX coreplex, kabilang ang E51 system na sinusubaybayan ang puso at ang U54 application harts.

I-on ang PIC64GX coreplex.
Sa power-on, ang lahat ng hart sa RISC-V coreplex ay inilabas mula sa pag-reset ng Security Controller.
Patakbuhin ang HSS code mula sa on-chip eNVM flash memory.
Sa una, ang bawat puso ay magsisimulang patakbuhin ang HSS code mula sa on-chip eNVM flash memory. Ang code na ito ay nagiging sanhi ng pag-ikot ng lahat ng U54 application hart, naghihintay ng mga tagubilin, at hinahayaan ang E51 monitor hart na simulan ang pagpapatakbo ng code upang simulan at ilabas ang system.

I-decompress ang HSS code mula sa eNVM patungo sa L2-Scratch memory.
Depende sa configuration ng build-time nito, ang HSS ay kadalasang mas malaki kaysa sa kapasidad ng eNVM flash memory mismo at kaya ang unang bagay na ginagawa ng HSS code na tumatakbo sa E51 ay ang decompress mismo mula sa eNVM hanggang L2-Scratch memory, tulad ng ipinapakita sa Figure 1.2 at Larawan 1.3.
Larawan 1.2. Nagde-decompress ang HSS mula eNVM hanggang L2 Scratch
Larawan 1.3. HSS Memory Map Sa Panahon ng Decompression
Tumalon mula sa eNVM patungo sa L2-Scratch sa isang executable tulad ng ipinapakita sa sumusunod na figure.
Larawan 1.4. Tumalon ang HSS mula sa eNVM patungo sa Code Now sa L2Scratch Kasunod ng Decompression
Ang executable ay binubuo ng tatlong bahagi:
- Ang hardware abstraction layer (HAL), low-level code, at bare metal driver
- Isang lokal na HSS fork ng RISC-V OpenSBI (medyo binago mula sa upstream sa PIC64GX para sa AMP layunin)
- Ang mga serbisyo ng HSS runtime (ang mga state machine ay tumatakbo sa isang super loop)
Simulan ang hardware at data structures na ginagamit ng OpenSBI.
Ang serbisyo ng HSS na "Startup" ay responsable para sa pagsisimulang ito.

Kunin ang larawan ng workload ng application (payload.bin) mula sa panlabas na storage. Ito ay ipinapakita sa Figure 1.5 at Figure 1.6
Mahalaga: Sa kaso ng PIC64GX Curiosity Kit, ito ay mula sa isang SD card.
Larawan 1.5. Kinukuha ang payload.bin Workload Image mula sa External Storage
Larawan 1.6. HSS Memory Map pagkatapos ng Pagkuha ng payload.bin
Kopyahin ang iba't ibang mga seksyon mula sa payload.bin hanggang sa kanilang mga patutunguhan sa oras ng pagpapatupad. Ang payload.bin ay isang naka-format na imahe, na pinagsasama-sama ang iba't ibang mga larawan ng aplikasyon para sa SMP o AMP mga workload. Kabilang dito ang mga talahanayan ng code, data, at descriptor na nagbibigay-daan sa HSS na naaangkop na ilagay ang code at mga seksyon ng data, kung saan kinakailangan ang mga ito upang patakbuhin ang iba't ibang workload ng application.
Larawan 1.7. Ang payload.bin ay kinopya sa mga Destination Address

Atasan ang mga nauugnay na U54 na pumunta sa kanilang mga address ng pagsisimula ng pagpapatupad. Ang impormasyon ng panimulang address na ito ay nasa payload.bin.
Simulan ang U54 Application harts at anumang segundotagmga boot loader. Para kay example, ang U-Boot ay naglalabas ng Linux.

I-reboot

Kaugnay ng konsepto ng system booting ay ang pangangailangang mag-reboot. Kapag nag-iisip tungkol sa PIC64GX application workloads, ang pag-reboot ay kailangang isaalang-alang ang parehong simetriko multiprocessing (SMP) at asymmetric multiprocessing (AMP) mga senaryo:

Sa kaso ng isang SMP system, ang isang pag-reboot ay maaaring ligtas na mag-cold reboot sa buong system dahil walang mga karagdagang workload sa ibang konteksto na dapat isaalang-alang.

Sa kaso ng isang AMP system, ang isang workload ay maaari lamang pahintulutan na i-reboot ang sarili nito (at hindi makagambala sa anumang iba pang konteksto), o maaaring may pribilehiyong makapagsagawa ng buong pag-reboot ng system.

I-reboot at AMP
Upang paganahin ang SMP at AMP mga senaryo sa pag-reboot, sinusuportahan ng HSS ang mga konsepto ng mainit at malamig na mga pribilehiyo sa pag-reboot, na maaaring italaga sa isang konteksto. Ang isang konteksto na may mainit na pribilehiyo sa pag-reboot ay makakapag-reboot lamang sa sarili nito, at ang isang konteksto na may isang malamig na pribilehiyo sa pag-reboot ay maaaring magsagawa ng isang buong pag-reboot ng system. Para kay example, isaalang-alang ang sumusunod na hanay ng mga kinatawan ng mga senaryo.

Isang solong konteksto ng SMP workload, na pinapayagang humiling ng buong pag-reboot ng system
Sa sitwasyong ito, pinahihintulutan ang konteksto ng pribilehiyo ng malamig na pag-reboot.
Isang dalawang-konteksto AMP workload, kung saan pinapayagan ang konteksto A na humiling ng buong pag-reboot ng system (nakakaapekto sa lahat ng konteksto), at pinapayagan ang Konteksto B na i-reboot ang sarili lamang
Sa sitwasyong ito, pinahihintulutan ang konteksto A ng pribilehiyo ng malamig na pag-reboot, at ang konteksto B ay pinapayagan ang pribilehiyo ng mainit na pag-reboot.
Isang dalawang-konteksto AMP workload, kung saan ang mga konteksto A at B ay pinapayagan lamang na i-reboot ang kanilang mga sarili (at hindi makakaapekto sa ibang konteksto)
Sa sitwasyong ito, ang parehong konteksto ay pinapayagan lamang ang mainit na mga pribilehiyo sa pag-reboot.
Isang dalawang-konteksto AMP workload, kung saan ang mga konteksto A at B ay parehong pinapayagang humiling ng buong pag-reboot ng system
Sa sitwasyong ito, pinahihintulutan ang parehong konteksto ng mga pribilehiyo ng cold reboot.
Higit pa rito, posible para sa HSS sa oras ng pagbuo na palaging payagan ang pribilehiyo ng malamig na pag-reboot, at hindi kailanman payagan ang pribilehiyo ng malamig na pag-reboot.

Kaugnay na HSS Kconfig Options
Ang Kconfig ay isang software build configuration system. Ito ay karaniwang ginagamit upang pumili ng mga pagpipilian sa oras ng pagbuo at upang paganahin o huwag paganahin ang mga tampok. Nagmula ito sa Linux kernel ngunit ngayon ay natagpuang gamit sa iba pang mga proyekto na lampas sa Linux kernel, kabilang ang U-Boot, Zephyr, at ang PIC64GX HSS.

Ang HSS ay naglalaman ng dalawang Kconfig na opsyon na kumokontrol sa reboot functionality mula sa HSS perspective:

CONFIG_ALLOW_COLD REBOOT
Kung ito ay pinagana, ito sa buong mundo ay nagbibigay-daan sa isang konteksto na mag-isyu ng malamig na reboot ecall. Kung hindi pinagana, ang mga warm reboot lang ang papayagan. Bilang karagdagan sa pagpapagana sa opsyong ito, ang pahintulot na mag-isyu ng malamig na pag-reboot ay dapat ibigay sa isang konteksto sa pamamagitan ng payload generator na YAML file o ang sumusunod na opsyon sa Kconfig.
CONFIG_ALLOW_COLD REBOOT_ALWAYS
- Kung naka-enable, ang feature na ito sa buong mundo ay nagbibigay-daan sa lahat ng konteksto na mag-isyu ng malamig na reboot ECAA, anuman ang mga karapatan sa flag ng payload.bin.
- Bukod pa rito, ang mismong payload.bin ay maaaring maglaman ng per-context na flag, na nagsasaad na ang isang partikular na konteksto ay may karapatan na mag-isyu ng mga cold reboot:
  - Upang payagan ang isang context warm reboot ng isa pang konteksto, maaari naming idagdag ang opsyong allow-reboot: warm sa paglalarawan ng YAML file ginamit upang lumikha ng payload.bin
  - Upang payagan ang isang context cold reboot ng buong system, maaari naming idagdag ang opsyong allow-reboot: cold. Bilang default, nang hindi tinukoy ang allow-reboot, pinapayagan lang ang isang konteksto ng warm reboot mismo Anuman ang setting ng flag na ito, kung ang CONFIG_ALLOW_COLDREBOOT ay hindi pinagana sa HSS, gagawin muli ng HSS ang lahat ng cold reboot na kahilingan sa warm (per-context) reboots .

I-reboot sa Detalye
Inilalarawan ng seksyong ito kung paano gumagana ang pag-reboot nang detalyado – simula sa layer ng OpenSBI (ang pinakamababang layer ng M-mode) at pagkatapos ay tinatalakay kung paano na-trigger ang functionality ng OpenSBI layer na ito mula sa isang RTOS application o isang rich OS tulad ng Linux.

OpenSBI Reboot ecall

Ang detalye ng RISC-V Supervisor Binary Interface (SBI) ay naglalarawan ng isang standardized na layer ng abstraction ng hardware para sa pagsisimula ng platform at mga serbisyo ng firmware runtime. Ang pangunahing layunin ng SBI ay paganahin ang portability at compatibility sa iba't ibang pagpapatupad ng RISC-V.
Ang OpenSBI (Open Source Supervisor Binary Interface) ay isang open-source na proyekto na nagbibigay ng reference na pagpapatupad ng SBI specification. Nagbibigay din ang OpenSBI ng mga serbisyo ng runtime, kabilang ang interrupt handling, pamamahala ng timer, at console I/O, na maaaring magamit ng mga layer ng software na mas mataas ang antas.
Ang OpenSBI ay kasama bilang bahagi ng HSS at tumatakbo sa antas ng Machine Mode. Kapag nagdulot ng bitag ang operating system o application, ipapasa ito sa OpenSBI para pangasiwaan ito. Inilalantad ng OpenSBI ang isang partikular na uri ng paggana ng system-call sa itaas na mga layer ng software sa pamamagitan ng isang partikular na mekanismo ng bitag na tinatawag na ecall.

Nagbibigay ang System Reset (EID 0x53525354) ng komprehensibong function ng system call na nagbibigay-daan sa software sa itaas na layer na humiling ng pag-reboot o pag-shutdown sa antas ng system. Kapag ang ecall na ito ay na-invoke ng isang U54, ito ay nakulong ng HSS software na tumatakbo sa Machine Mode sa U54 na iyon, at isang kaukulang kahilingan sa pag-reboot ay ipinadala sa E51 upang i-reboot ang alinman sa konteksto o ang buong system, depende sa mga karapatan ng konteksto.

Para sa karagdagang impormasyon, tingnan ang Detalye ng Binary Interface ng Supervisor ng RISC-V partikular System Reset Extension (EID #0x53525354 “SRST”).

Pag-reboot ng Linux

Bilang isang tiyak na exampSa mga ito, sa Linux, ang shutdown command ay ginagamit upang ihinto o i-reboot ang system. Ang utos ay karaniwang may maraming mga alias, katulad ng paghinto, pag-off, at pag-reboot. Tinutukoy ng mga alias na ito kung ihihinto ang makina sa pagsara, papatayin ang makina sa pagsara, o i-reboot ang makina sa pagsara.

Ang mga utos ng user-space na ito ay naglalabas ng reboot system call sa Linux, na nakulong ng kernel at nakipag-interwork sa isang SBI ecall.
Mayroong iba't ibang antas ng pag-reboot - REBOOT_WARM, REBOOT_COLD, REBOOT_HARD - ang mga ito ay maaaring ipasa bilang mga argumento ng command line sa kernel (para sa example, reboot=w[arm] para sa REBOOT_WARM). Para sa karagdagang impormasyon sa Linux kernel source code, tingnan ang Documentation/admin-guide/kernel-paramters.txt.
Bilang kahalili, kung ang /sys/kernel/reboot ay pinagana, ang mga humahawak sa ilalim ay maaaring basahin upang makuha ang kasalukuyang configuration ng pag-reboot ng system, at isulat upang baguhin ito. Para sa karagdagang impormasyon sa Linux kernel source code, tingnan Documentation/ABI/testing/sysfs-kernel-reboot.

Mga asong nagbabantay

Ang isang karagdagang konsepto na nauugnay sa pag-boot ng system at pag-reboot ng system ay ang pagbawi ng system sa pagpapaputok ng timer ng watchdog. Ang mga watchdog timer ay malawakang ginagamit sa mga naka-embed na system upang awtomatikong mabawi mula sa lumilipas na mga pagkakamali ng hardware, at upang maiwasan ang mali o masamang software na makagambala sa pagpapatakbo ng system.
Kasama sa PIC64GX ang suporta sa hardware na tagapagbantay upang masubaybayan ang mga indibidwal na hart kapag tumatakbo ang system. Tinitiyak ng mga watchdog na ang mga hart ay maaaring i-restart kung hindi sila tumugon dahil sa mga hindi mababawi na error sa software.
Kasama sa PIC64GX ang limang pagkakataon ng mga bloke ng hardware ng watchdog timer na ginagamit upang makita ang mga lockup ng system -isa para sa bawat isa sa mga hart. Upang mapadali ang pinaghalong Asymmetric Multi-Processing (AMP) workloads, sinusuportahan ng HSS ang pagsubaybay at pagtugon sa pagpapaputok ng mga watchdog.

PIC64GX Watchdog

Ang HSS ay responsable para sa pag-boot ng application harts sa power-up, at para sa muling pag-boot sa kanila (indibidwal o sama-sama) sa anumang oras.tage, kung kailangan o ninanais. Bilang resulta nito, ang pagtugon sa mga kaganapang nagbabantay sa PIC64GX ay pinangangasiwaan ng HSS.
Ang monitor ng 'virtual watchdog' ay ipinapatupad bilang isang serbisyo ng makina ng estado ng HSS, at ang mga responsibilidad nito ay subaybayan ang katayuan ng bawat isa sa U54 na indibidwal na monitor ng hardware ng watchdog. Kapag bumiyahe ang isa sa mga U54 na watchdog na ito, matutukoy ito ng HSS at ire-reboot ang U54 kung naaangkop. Kung ang U54 ay bahagi ng konteksto ng SMP, ang buong konteksto ay isasaalang-alang para sa pag-reboot, dahil ang konteksto ay may mainit na pribilehiyo sa pag-reboot. Ang buong system ay ire-reboot kung ang konteksto ay may cold reboot privilege.

Mga Kaugnay na Opsyon sa Kconfig

Ang suporta sa asong tagapagbantay ay kasama bilang default sa mga inilabas na build ng HSS. Kung nais mong bumuo ng custom na HSS, ilalarawan ng seksyong ito ang mekanismo ng pagsasaayos upang matiyak na pinagana ang suporta ng Watchdog.

Ang HSS ay na-configure gamit ang Kconfig configuration system. Isang toplevel .config file ay kinakailangan upang piliin kung anong mga serbisyo ang maisasama sa loob o labas ng HSS build.
Una, kailangang i-enable ang top-level na CONFIG_SERVICE_WDOG na opsyon ("Virtual Watchdog support" sa pamamagitan ng make config).

Inilalantad nito ang mga sumusunod na sub-opsyon na nakadepende sa suporta ng Watchdog:

CONFIG_SERVICE_WD OG_DEBUG
Pinapagana ang suporta para sa mga mensaheng nagbibigay-kaalaman/pag-debug mula sa serbisyo ng virtual na tagapagbantay.
CONFIG_SERVICE_WD OG_DEBUG_TIMEOUT_SECS
Tinutukoy ang periodicity (sa mga segundo) na ang mga mensahe ng pag-debug ng Watchdog ay ilalabas ng HSS.
CONFIG_SERVICE_WD OG_ENABLE_E51
Pinapagana ang watchdog para sa E51 na sinusubaybayan ang puso bilang karagdagan sa mga U54, na nagpoprotekta sa pagpapatakbo ng HSS mismo.

Kapag ang E51 watchdog ay pinagana, ang HSS ay pana-panahong magsusulat sa Watchdog upang i-refresh ito at pigilan ito sa pagpapaputok. Kung, sa ilang kadahilanan, ang E51 heart ay nagla-lock o nag-crash at ang E51 watchdog ay pinagana, ito ay palaging i-reset ang buong system.

Operasyon ng asong tagapagbantay
Ang hardware ng watchdog ay nagpapatupad ng mga down counter. Maaaring gumawa ng window na ipinagbabawal sa pag-refresh sa pamamagitan ng pag-configure ng watchdog na Maximum Value hanggang sa kung saan ang Refresh ay Pinahihintulutan (MVRP).

Kapag ang kasalukuyang halaga ng watchdog timer ay mas malaki kaysa sa halaga ng MVRP, ipinagbabawal ang pag-refresh sa watchdog. Ang pagtatangkang i-refresh ang watchdog timer sa ipinagbabawal na window ay maglalagay ng timeout interrupt.

Ang pagre-refresh ng watchdog sa pagitan ng MVRP value at ng Trigger Value (TRIG) ay matagumpay na magre-refresh ng counter at mapipigilan ang watchdog na magpaputok.
Kapag mas mababa ang halaga ng watchdog timer sa halaga ng TRIG, magpapagana ang watchdog.

Watchdog State Machine

Napakasimple ng watchdog state machine – nagsisimula sa pamamagitan ng pag-configure ng watchdog para sa E51, kung naka-enable, pagkatapos ay lumipat sa idle state sa pagsubaybay. Sa bawat oras sa paligid ng superloop, ang estado ng pagsubaybay na ito ay ginagamit, na tumitingin sa katayuan ng bawat isa sa mga U54 na watchdog.

Nakikipag-ugnayan ang watchdog state machine sa boot state machine upang i-restart ang isang hart (at anumang iba pang hart na nasa boot set nito), kung matukoy nito na hindi nagawang i-refresh ng hart ang watchdog nito sa oras.

LockdownMode

Karaniwan (lalo na sa AMP mga application), inaasahan na ang HSS ay mananatiling residente sa M-mode, sa isang U54, upang payagan ang per-context reboot (ibig sabihin, i-reboot ang isang konteksto lamang, nang walang full-chip reboot), at upang payagan ang HSS na subaybayan ang kalusugan ( ECCs, Lock Status Bits, Bus Errors, SBI errors, PMP violations, etc).

Upang makapagbigay ng mga kakayahan sa pag-reboot sa isang per-AMP batayan ng konteksto (nang hindi nangangailangan ng buong system na mag-reboot), ang E51 ay karaniwang may privileged memory access sa buong memory space ng system. Gayunpaman, maaaring may mga sitwasyon kung saan hindi ito kanais-nais, at maaaring mas gusto ng customer na paghigpitan ang ginagawa ng E51 HSS firmware kapag matagumpay na na-boot ang system. Sa kasong ito, posibleng ilagay ang HSS sa lockdown mode kapag na-boot na ang U54 Application Harts.

Ito ay maaaring paganahin gamit ang HSS Kconfig na opsyon na CONFIG_SERVICE_LOCKDOWN.
Ang serbisyo ng lockdown ay nilayon na payagan ang paghihigpit sa mga aktibidad ng HSS pagkatapos nitong i-boot ang U54 application na Harts.

Larawan 4.2. HSS Lockdown Mode

Kapag nagsimula na ang Lockdown mode, hihinto nito ang lahat ng iba pang HSS service state machine na tumakbo. Tinatawag nito ang dalawang mahinang nakatali na mga function:

e51_pmp_lockdown(), at
e51_lockdown()

Ang mga function na ito ay nilayon na ma-override ng board-specific na code. Ang una ay isang na-configure na trigger function upang payagan ang isang BSP na i-customize ang pag-lock ng E51 mula sa mga payload ng application sa puntong ito. Ang mahinang nakatali na default na pagpapatupad ng function na ito ay walang laman. Ang pangalawa ay ang functionality na pinapatakbo mula sa puntong iyon pasulong. Ang mahinang nakatali na default na pagpapatupad ay nagbibigay ng serbisyo sa tagapagbantay sa puntong ito sa E51, at magre-reboot kung ang isang U54 na tagapagbantay ay magpapaputok. Para sa karagdagang impormasyon, tingnan ang HSS source code sa services/lockdown/lockdown_service.c file.

Apendise

HSS payload.bin Format

Inilalarawan ng seksyong ito ang payload.bin file format at ang imaheng ginamit ng HSS para i-boot ang PIC64GX SMP at AMP mga aplikasyon.
Ang payload.bin ay isang naka-format na binary (Figure A.10) na binubuo ng isang head, iba't ibang mga descriptor table, at iba't ibang chunks na naglalaman ng code at mga seksyon ng data ng bawat bahagi ng workload ng application. Ang isang tipak ay maaaring ituring bilang isang arbitrary-sized na magkadikit na bloke ng memorya.

Larawan A.10. Payload.bin Format

Ang bahagi ng header (ipinapakita sa Figure A.11) ay naglalaman ng magic value na ginamit upang tukuyin ang payload.bin at ilang impormasyon sa housekeeping, kasama ang mga detalye ng larawang nilalayong tumakbo sa bawat isa sa
U54 application code. Inilalarawan nito kung paano i-boot ang bawat indibidwal na U54 hart, at ang set ng mga bootable na imahe sa pangkalahatan. Sa impormasyon ng housekeeping nito, mayroon itong mga pointer sa iba't ibang talahanayan ng mga deskriptor upang payagan ang laki ng header na lumaki.

Larawan A.11. payload.bin Header

Ang code at ang inisyal na pare-parehong data ay itinuturing na read-only at nakaimbak sa isang read-only na seksyon, na itinuturo ng mga descriptor ng header.
Ang mga di-zero na inisyal na variable ng data ay read-write na data ngunit kinopya ang kanilang mga halaga ng initialization mula sa read-only na chunk sa start-up. Ang mga ito ay nakaimbak din sa read-only na seksyon.

Ang read-only payload na seksyon ng data ay inilalarawan ng isang talahanayan ng code at mga data chunk descriptor. Ang bawat chunk descriptor sa talahanayang ito ay naglalaman ng isang 'may-ari ng hart' (ang pangunahing hart sa kontekstong ito ay naka-target
at), isang load offset (offset sa loob ng payload.bin), at isang execution address (destination address sa PIC64GX memory), kasama ang isang laki at checksum. Ito ay ipinapakita sa Figure A.12.

Larawan A.12. Read-Only Chunk Descriptor at Payload Chunk Data

Bilang karagdagan sa mga nabanggit na chunks, mayroon ding mga chunks ng memorya na tumutugma sa mga variable ng data na sinisimulan sa zero. Ang mga ito ay hindi nakaimbak bilang data sa payload.bin, ngunit sa halip ay isang espesyal na hanay ng mga zero-initialized chunk descriptor, na tumutukoy ng address at haba ng RAM na itatakda sa zero sa panahon ng pagsisimula. Ito ay ipinapakita sa Figure A.13.

Larawan A.13. ZI Chunks

hss-payload-generator
Ang tool ng HSS Payload Generator ay lumilikha ng na-format na payload na imahe para sa Hart Software Service zero-stage bootloader sa PIC64GX, binigyan ng configuration file at isang set ng ELF files at/o mga binary. Ang pagsasaayos file ay ginagamit upang imapa ang ELF binary o binary blobs sa indibidwal na application harts (U54s).

Larawan B.14. Daloy ng hss-payload-generator

Nagsasagawa ang tool ng mga pangunahing pagsusuri sa katinuan sa istruktura ng configuration file mismo at sa mga larawan ng ELF. Ang mga larawang ELF ay dapat na RISC-V na mga executable.

Example Run

Upang patakbuhin ang hss-payload-generator tool gamit ang sampang configuration file at ELF files:
$ ./hss-payload-generator -c test/config.yaml output.bin
Upang mag-print ng mga diagnostic tungkol sa isang dati nang larawan, gamitin ang:
$ ./hss-payload-generator -d output.bin

Upang paganahin ang secure na boot authentication (sa pamamagitan ng pag-sign ng imahe), gamitin ang -p upang tukuyin ang lokasyon ng isang X.509 Private Key para sa Elliptic Curve P-384 (SECP384r1):
$ ./hss-payload-generator -c test/config.yaml payload.bin -p /path/to/private.pem

Para sa higit pang impormasyon, tingnan ang dokumentasyon ng Secure Boot Authentication.

Config File Example

Una, maaari kaming opsyonal na magtakda ng pangalan para sa aming larawan, kung hindi, dynamic na gagawin ang isa:
set-name: 'PIC64-HSS::TestImage'
Susunod, tutukuyin namin ang mga entry point address para sa bawat puso, tulad ng sumusunod:
hart-entry-points: {u54_1: ‘0x80200000’, u54_2: ‘0x80200000’, u54_3: ‘0xB0000000′, u54_4:’0x80200000’}

Ang ELF source na mga imahe ay maaaring tumukoy ng isang entry point, ngunit gusto naming masuportahan ang pangalawang entry point para sa harts kung kinakailangan, para sa exampOo, kung maraming hart ang nilayon na mag-boot ng parehong larawan, maaaring mayroon silang mga indibidwal na entry point. Upang suportahan ito, tinukoy namin ang aktwal na mga address ng entry point sa configuration file mismo.

Maaari na nating tukuyin ang ilang mga payload (pinagmulan ng ELF files, o binary blobs) na ilalagay sa ilang partikular na rehiyon sa memorya. Ang seksyon ng payload ay tinukoy sa mga keyword na payload, at pagkatapos ay isang bilang ng mga indibidwal na tagapaglarawan ng payload. Ang bawat payload ay may pangalan (path to its file), isang owner-hart, at opsyonal na 1 hanggang 3 pangalawang hart.

Bukod pa rito, ang payload ay may privilege mode kung saan magsisimula itong ipatupad. Ang mga wastong privilege mode ay PRV_M, PRV_S at PRV_U, kung saan ang mga ito ay tinukoy bilang:

PRV_M Machine mode
PRV_S Supervisor mode
PRV_U User mode

Sa sumusunod na example:

Ang test/zephyr.elf ay ipinapalagay na isang Zephyr application na tumatakbo sa U54_3, at inaasahang magsisimula sa PRV_M privilege mode.
Ang test/u-boot-dtb.bin ay ang Das U-Boot bootloader application, at tumatakbo ito sa U54_1, U54_2 at U54_4. Inaasahan nitong magsisimula sa PRV_S privilege mode.

Mahalaga:
Ang output ng U-Boot ay lumilikha ng isang ELF file, ngunit kadalasan ay hindi nito inihahanda ang .elf na extension. Sa kasong ito, ang binary na ginawa ng CONFIG_OF_SEPARATE ay ginagamit, na nagdaragdag ng isang device tree blob sa U-Boot binary.

Eto si example Payloads configuration file:

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

Mahalaga:
Kaso lamang ang mahalaga para sa file mga pangalan ng path, hindi ang mga keyword. Kaya, halimbawa, ang u54_1 ay itinuturing na kapareho ng U54_1, at ang exec-addr ay itinuturing na kapareho ng EXEC-ADDR. Kung may extension ng an.elf o .bin, kailangan itong isama sa configuration file.

Para sa isang hubad na metal na application na hindi gustong mag-alala sa OpenSBI, ang opsyong skip-open, kung totoo, ay magiging sanhi ng payload sa pusong iyon na ma-invoke gamit ang isang simpleng mret sa halip.
kaysa sa isang OpenSBI sbi_init() na tawag. Nangangahulugan ito na ang puso ay magsisimulang patakbuhin ang bare metal code anuman ang anumang pagsasaalang-alang ng OpenSBI HSM. Tandaan na nangangahulugan din ito na hindi magagamit ng puso
tumatawag upang i-invoke ang OpenSBI functionality. Ang opsyon sa skip-opens ay opsyonal at default sa false.

Upang payagan ang isang konteksto na mainit na pag-reboot ng isa pang konteksto, maaari naming idagdag ang opsyong payagan ang pag-reboot: mainit-init. Upang payagan ang isang context cold reboot ng buong system, maaari naming idagdag ang opsyong allow-reboot: cold. Bilang default, nang hindi tinukoy ang allow-reboot, pinapayagan lang ang isang konteksto na magpainit ng pag-reboot mismo.
Posible ring iugnay ang ancillary data sa bawat payload, halimbawaample, isang DeviceTree Blob (DTB) file, sa pamamagitan ng pagtukoy sa pantulong na data filepangalan tulad ng sumusunod:
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 }
Ang ancilliary data na ito ay isasama sa payload (ilalagay diretso pagkatapos ng main file sa executable
space), at ang address nito ay ipapasa sa OpenSBI sa next_arg1 field (ipinasa sa $a1 na rehistro sa larawan sa oras ng boot).

Upang pigilan ang HSS na awtomatikong mag-boot ng isang konteksto (halimbawa, kung sa halip ay gusto naming italaga ang kontrol nito sa isang konteksto gamit ang remoteProc), gamitin ang skip-autoboot flag:
test/zephyr.elf: {exec-addr: '0xB0000000', owner-hart: u54_3, priv-mode: prv_m, skip-opensbi: true, skip-autoboot: true}
Sa wakas, maaari naming opsyonal na i-override ang mga pangalan ng mga indibidwal na payload, gamit ang opsyon sa payload-name. Para kay example:
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' }

Tandaan na ang mga tagabuo ng Yocto at Buildroot Linux ay bubuo, magko-configure, at magpapatakbo ng hss-payload-
generator kung kinakailangan upang makabuo ng mga larawan ng application. Bukod pa rito, ang pic64gx-curiosity-kit-amp ang target ng makina sa Yocto ay bubuo ng imahe ng application gamit ang hss-payload-generator tool na nagpapakita AMP, na may Linux na tumatakbo sa 3 hart at Zephyr na tumatakbo sa 1 hart.

Kasaysayan ng Pagbabago
Inilalarawan ng kasaysayan ng rebisyon ang mga pagbabagong ipinatupad sa dokumento. Ang mga pagbabago ay nakalista ayon sa rebisyon, simula sa pinakabagong publikasyon.

Rebisyon	Petsa	Paglalarawan
A	07/2024	Paunang Rebisyon

Impormasyon sa Microchip

Ang Microchip Website
Nagbibigay ang Microchip ng online na suporta sa pamamagitan ng aming website sa www.microchip.com/. Ito website ay ginagamit upang gumawa files at impormasyong madaling makuha ng mga customer. Ang ilan sa mga magagamit na nilalaman ay kinabibilangan ng:

Suporta sa Produkto – Datasheet at errata, mga tala ng aplikasyon at sampmga programa, mapagkukunan ng disenyo, mga gabay sa gumagamit at mga dokumento ng suporta sa hardware, pinakabagong paglabas ng software at naka-archive na software

Pangkalahatang Teknikal na Suporta – Mga Madalas Itanong (FAQ), mga kahilingan sa teknikal na suporta, mga online na grupo ng talakayan, listahan ng miyembro ng Microchip design partner program
Negosyo ng Microchip – Tagapili ng produkto at mga gabay sa pag-order, pinakabagong mga press release ng Microchip, isang listahan ng mga seminar at kaganapan, mga listahan ng mga opisina ng pagbebenta ng Microchip, mga distributor, at mga kinatawan ng pabrika

Serbisyong Abiso sa Pagbabago ng Produkto

Nakakatulong ang serbisyo ng abiso sa pagbabago ng produkto ng Microchip na panatilihing napapanahon ang mga customer sa mga produkto ng Microchip. Makakatanggap ang mga subscriber ng abiso sa email sa tuwing may mga pagbabago, update, rebisyon o pagkakamali na nauugnay sa isang partikular na pamilya ng produkto o tool sa pag-develop ng interes.

Upang magparehistro, pumunta sa www.microchip.com/pcn at sundin ang mga tagubilin sa pagpaparehistro.

Suporta sa Customer
Ang mga gumagamit ng mga produkto ng Microchip ay maaaring makatanggap ng tulong sa pamamagitan ng ilang mga channel:

Distributor o Kinatawan
Lokal na Sales Office
Naka-embed na Solutions Engineer (ESE)
Teknikal na Suporta

Dapat makipag-ugnayan ang mga customer sa kanilang distributor, kinatawan, o ESE para sa suporta. Available din ang mga lokal na opisina ng pagbebenta upang tulungan ang mga customer. Kasama sa dokumentong ito ang isang listahan ng mga opisina at lokasyon ng pagbebenta.
Ang teknikal na suporta ay makukuha sa pamamagitan ng website sa: www.microchip.com/support.

Tampok na Proteksyon ng Code ng Mga Microchip Device
Tandaan ang mga sumusunod na detalye ng tampok na proteksyon ng code sa mga produkto ng Microchip:

Ang mga produktong Microchip ay nakakatugon sa mga pagtutukoy na nakapaloob sa kanilang partikular na Microchip Data Sheet.
Naniniwala ang Microchip na ang pamilya ng mga produkto nito ay ligtas kapag ginamit sa inilaan na paraan, sa loob ng mga pagtutukoy sa pagpapatakbo, at sa ilalim ng normal na mga kondisyon.

Pinahahalagahan ng Microchip at agresibong pinoprotektahan ang mga karapatan sa intelektwal na pag-aari nito. Mahigpit na ipinagbabawal ang mga pagtatangkang labagin ang mga tampok na proteksyon ng code ng mga produkto ng Microchip at maaaring lumabag sa Digital Millennium Copyright Act.
Ni ang Microchip o anumang iba pang tagagawa ng semiconductor ay hindi magagarantiyahan ang seguridad ng code nito. Ang proteksyon ng code ay hindi nangangahulugan na ginagarantiya namin na ang produkto ay "hindi nababasag". Ang proteksyon ng code ay patuloy na umuunlad. Ang Microchip ay nakatuon sa patuloy na pagpapabuti ng mga tampok sa proteksyon ng code ng aming mga produkto.

Legal na Paunawa
Ang publikasyong ito at ang impormasyon dito ay maaari lamang gamitin sa mga produkto ng Microchip, kabilang ang pagdidisenyo, pagsubok, at pagsasama ng mga produktong Microchip sa iyong aplikasyon. Ang paggamit ng impormasyong ito sa anumang iba pang paraan ay lumalabag sa mga tuntuning ito. Ang impormasyon tungkol sa mga application ng device ay ibinibigay lamang para sa iyong kaginhawahan at maaaring mapalitan ng mga update. Responsibilidad mong tiyaking natutugunan ng iyong aplikasyon ang iyong mga pagtutukoy. Makipag-ugnayan sa iyong lokal na opisina ng pagbebenta ng Microchip para sa karagdagang suporta o, kumuha ng karagdagang suporta sa www.microchip.com/en-us/support/design-help/client-support-services.

ANG IMPORMASYON NA ITO AY IBINIGAY NG MICROCHIP "AS IS". ANG MICROCHIP ay WALANG GUMAWA NG MGA REPRESENTASYON O WARRANTY NG ANUMANG URI MAHALAGA MAN O IPINAHIWATIG, NAKASULAT O BALIG, STATUTORY O IBA PA, NA KAUGNAY SA IMPORMASYON KASAMA NGUNIT HINDI LIMITADO SA ANUMANG IPINAHIWATIG NA WARRANTY NG HINDI PAGKAKABIGAY, AT PAGKAKATAON. LAYUNIN, O MGA WARRANTY NA KAUGNAY SA KUNDISYON, KALIDAD, O PAGGANAP NITO.

HINDI MANANAGOT ANG MICROCHIP SA ANUMANG INDIRECT, SPECIAL, PUNITIVE, INCIDENTAL, O CONSEQUENTIAL LOSS, PANCER, COST, O EXPENS OF ANUMANG URI NA KAUGNAY SA IMPORMASYON O SA PAGGAMIT NITO, GAANO MAN ANG SANHI, KAHIT NA MAY NAMIN POSIBILIDAD O ANG MGA PINSALA AY MAAABOT. HANGGANG SA BUONG SAKOT NA PINAHAYAGAN NG BATAS, ANG KABUUANG PANANAGUTAN NG MICROCHIP SA LAHAT NG MGA CLAIMS SA ANUMANG PARAAN NA KAUGNAY SA IMPORMASYON O ANG PAGGAMIT NITO AY HINDI HIGIT SA BILANG NG MGA BAYAD, KUNG MERON, NA DIREKTA NINYONG BINAYARAN SA MICROCHIP PARA SA IMPORMASYON.

Ang paggamit ng mga aparatong Microchip sa suporta sa buhay at/o mga aplikasyong pangkaligtasan ay ganap na nasa panganib ng mamimili, at sumasang-ayon ang bumibili na ipagtanggol, bayaran, at hindi makapinsala sa Microchip mula sa lahat ng pinsala, paghahabol, paghahabla, o gastos na nagreresulta mula sa naturang paggamit. Walang mga lisensya ang ipinadala, nang tahasan o kung hindi man, sa ilalim ng anumang mga karapatan sa intelektwal na ari-arian ng Microchip maliban kung iba ang nakasaad.

Mga trademark
Ang pangalan at logo ng Microchip, ang logo ng Microchip, Adaptec, AVR, AVR logo, AVR Freaks, BesTime, BitCloud, CryptoMemory, CryptoRF, dsPIC, flexPWR, HELDO, IGLOO, JukeBlox, KeeLoq, Kleer, LANCheck, LinkMD, maXStylus, maXTouch, MediaLB, megaAVR, Microsemi, Microsemi logo, MOST, MOST logo, MPLAB, OptoLyzer, PIC, picoPower, PICSTART, PIC32 logo, PolarFire, Prochip Designer, QTouch, SAM-BA, SenGenuity, SpyNIC, SST, SST Logo, SuperFlash, Symmetricom , SyncServer, Tachyon, TimeSource, tinyAVR, UNI/O, Vectron, at XMEGA ay mga rehistradong trademark ng Microchip Technology Incorporated sa USA at iba pang mga bansa.

AgileSwitch, ClockWorks, The Embedded Control Solutions Company, EtherSynch, Flashtec, Hyper Speed Control, HyperLight Load, Libero, motor bench, mTouch, Powermite 3, Precision Edge, ProASIC, ProASIC Plus, ProASIC Plus logo, Quiet-Wire, SmartFusion, SyncWorld , TimeCesium, TimeHub, TimePictra, TimeProvider, at ZL ay mga rehistradong trademark ng Microchip Technology Incorporated sa USA

Katabing 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 Average Matching Dynamic , DAM, ECAN, Espresso T1S, EtherGREEN, EyeOpen, GridTime, IdealBridge,
IGaT, In-Circuit Serial Programming, ICSP, INICnet, Intelligent Parallel, IntelliMOS, Inter-Chip Connectivity, JitterBlocker, Knob-on-Display, MarginLink, maxCrypto, maxView, memBrain, Mindi, MiWi, MPASM, MPF, MPLAB Certified na logo, 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, simpleng mapa, SimpliPHY, SmartBuffer, SmartHLS, SMART-IS, storClad, SQI, SuperSwitcher, SuperSwitcher II, Switchtec, SynchroPHY, Total Endurance, Trusted Time, TSHARC, Turing, USBCheck, VariSense, VectorBlox, VeriPHY, ViewAng Span, WiperLock, XpressConnect, at ZENA ay mga trademark ng Microchip Technology Incorporated sa USA at iba pang mga bansa.

Ang SQTP ay isang marka ng serbisyo ng Microchip Technology Incorporated sa USA
Ang logo ng Adaptec, Frequency on Demand, Silicon Storage Technology, at Symmcom ay mga rehistradong trademark ng Microchip Technology Inc. sa ibang mga bansa.
Ang GestIC ay isang rehistradong trademark ng Microchip Technology Germany II GmbH & Co. KG, isang subsidiary ng Microchip Technology Inc., sa ibang mga bansa.

ISBN: 978-1-6683-4890-1

Sistema ng Pamamahala ng Kalidad
Para sa impormasyon tungkol sa Quality Management System ng Microchip, pakibisita www.microchip.com/quality.

Pandaigdigang Benta at Serbisyo

AMERIKA

ASIA/PACIFIC

EUROPE

Corporate Opisina

2355 West Chandler Blvd. Chandler, AZ 85224-6199

Tel: 480-792-7200

Fax: 480-792-7277

Teknikal na Suporta: www.microchip.com/support

Web Address: www.microchip.com

Atlanta

Duluth, GA

Tel: 678-957-9614

Fax: 678-957-1455

Austin, TX

Tel: 512-257-3370

Boston

Westborough, MA Tel: 774-760-0087

Fax: 774-760-0088

Chicago

Itasca, IL

Tel: 630-285-0071

Fax: 630-285-0075

Dallas

Addison, TX

Tel: 972-818-7423

Fax: 972-818-2924

Detroit

Novi, MI

Tel: 248-848-4000

Houston, TX

Tel: 281-894-5983

Indianapolis

Noblesville, IN Tel: 317-773-8323

Fax: 317-773-5453

Tel: 317-536-2380

Los Angeles

Mission Viejo, CA Tel: 949-462-9523

Fax: 949-462-9608

Tel: 951-273-7800

Raleigh, NC

Tel: 919-844-7510

New York, NY

Tel: 631-435-6000

San Jose, CA

Tel: 408-735-9110

Tel: 408-436-4270

Canada – Toronto

Tel: 905-695-1980

Fax: 905-695-2078

Australia – Sydney

Tel: 61-2-9868-6733

Tsina - Beijing

Tel: 86-10-8569-7000

Tsina – Chengdu

Tel: 86-28-8665-5511

Tsina – Chongqing

Tel: 86-23-8980-9588

Tsina – Dongguan

Tel: 86-769-8702-9880

Tsina - Guangzhou

Tel: 86-20-8755-8029

Tsina - Hangzhou

Tel: 86-571-8792-8115

Tsina – Hong Si Kong SAR

Tel: 852-2943-5100

Tsina – Nanjing

Tel: 86-25-8473-2460

Tsina – Qingdao

Tel: 86-532-8502-7355

Tsina - Shanghai

Tel: 86-21-3326-8000

Tsina – Shenyang

Tel: 86-24-2334-2829

Tsina - Shenzhen

Tel: 86-755-8864-2200

Tsina - Suzhou

Tel: 86-186-6233-1526

Tsina - Wuhan

Tel: 86-27-5980-5300

Tsina – Xian

Tel: 86-29-8833-7252

Tsina – Xiamen

Tel: 86-592-2388138

Tsina – Zhuhai

Tel: 86-756-3210040

India – Bangalore

Tel: 91-80-3090-4444

India – New Delhi

Tel: 91-11-4160-8631

India – Pune

Tel: 91-20-4121-0141

Japan – Osaka

Tel: 81-6-6152-7160

Japan – Tokyo

Tel: 81-3-6880-3770

Korea – Daegu

Tel: 82-53-744-4301

Korea – Seoul

Tel: 82-2-554-7200

Malaysia – Kuala Lumpur

Tel: 60-3-7651-7906

Malaysia – Penang

Tel: 60-4-227-8870

Pilipinas – Maynila

Tel: 63-2-634-9065

Singapore

Tel: 65-6334-8870

Taiwan – Hsin Chu

Tel: 886-3-577-8366

Taiwan – Kaohsiung

Tel: 886-7-213-7830

Taiwan - Taipei

Tel: 886-2-2508-8600

Thailand – Bangkok

Tel: 66-2-694-1351

Vietnam – Ho Chi Minh

Tel: 84-28-5448-2100

Austria – Wels

Tel: 43-7242-2244-39

Fax: 43-7242-2244-393

Denmark – Copenhagen

Tel: 45-4485-5910

Fax: 45-4485-2829

Finland – Espoo

Tel: 358-9-4520-820

France – Paris

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

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

Alemanya – garching

Tel: 49-8931-9700

Alemanya – Haan

Tel: 49-2129-3766400

Alemanya – Heilbronn

Tel: 49-7131-72400

Alemanya – Karlsruhe

Tel: 49-721-625370

Alemanya – Munich

Tel: 49-89-627-144-0

Fax: 49-89-627-144-44

Alemanya – Rosenheim

Tel: 49-8031-354-560

Israel – Hod Hasharon

Tel: 972-9-775-5100

Italya - Milan

Tel: 39-0331-742611

Fax: 39-0331-466781

Italya - Padova

Tel: 39-049-7625286

Netherlands – Drunen

Tel: 31-416-690399

Fax: 31-416-690340

Norway – Trondheim

Tel: 47-72884388

Poland – Warsaw

Tel: 48-22-3325737

Romania – Bucharest

Tel: 40-21-407-87-50

Espanya - Madrid

Tel: 34-91-708-08-90

Fax: 34-91-708-08-91

Sweden - Gothenburg

Tel: 46-31-704-60-40

Sweden - Stockholm

Tel: 46-8-5090-4654

UK – Wokingham

Tel: 44-118-921-5800

Fax: 44-118-921-5820

Mga Dokumento / Mga Mapagkukunan

MICROCHIP PIC64GX 64-Bit RISC-V Quad-Core Microprocessor [pdf] Gabay sa Gumagamit
PIC64GX, PIC64GX 64-Bit RISC-V Quad-Core Microprocessor, 64-Bit RISC-V Quad-Core Microprocessor, RISC-V Quad-Core Microprocessor, Quad-Core Microprocessor, Microprocessor

Mga sanggunian

User Manual

MICROCHIP PIC64GX 64-Bit RISC-V Quad-Core Microprocessor

Impormasyon ng Produkto

Mga Tagubilin sa Paggamit ng Produkto