MICROCHIP PIC64GX 64-Bit RISC-V Pandhuan Pangguna Mikroprosesor Quad-Core

Proses Booting
1. Komponen piranti lunak sing melu booting
  Proses boot-up sistem kalebu komponen piranti lunak ing ngisor iki:
  - Hart Software Services (HSS): A nul-stage boot loader, monitor sistem, lan panyedhiya layanan runtime kanggo aplikasi.
2. Alur Boot
  Urutan aliran boot sistem kaya ing ngisor iki:
  1. Initialization of Hart Software Services (HSS)
  2. Eksekusi bootloader
  3. Aplikasi wiwitan
Pengawas
1. PIC64GX Watchdog
  PIC64GX nduweni fungsi watchdog kanggo ngawasi operasi sistem lan micu tumindak yen ana kegagalan sistem.
Mode Kunci
Mode kunci dirancang kanggo pelanggan sing mbutuhake kontrol lengkap babagan tumindak sistem sawise boot. Watesan fungsi monitor sistem E51.

FAQ

P: Apa tujuane Hart Software Services (HSS)?
A: HSS serves minangka nul-stage boot loader, monitor sistem, lan panyedhiya layanan runtime kanggo aplikasi sajrone proses boot.
P: Kepiye fungsi watchdog PIC64GX?
A: Pengawas PIC64GX ngawasi operasi sistem lan bisa njupuk tindakan sing wis ditemtokake yen gagal sistem kanggo njamin linuwih sistem.

Pambuka

Whitepaper iki nerangake carane Microchip PIC64GX boots beban kerja aplikasi lan njlèntrèhaké proses boot sistem, sing makaryakke padha kanggo SMP lan AMP beban kerja. Kajaba iku, kalebu cara urip maneh kanggo SMP lan AMP workloads, watchdogs ing PIC64GX, lan mode kunci khusus kanggo sistem ngendi pelanggan kepéngin kontrol lengkap kanggo matesi tumindak monitor sistem E51 sawise boot sistem.

Proses Booting

Ayo goleki macem-macem komponen piranti lunak sing ana ing bootup sistem, banjur katon luwih rinci babagan urutan aliran boot sistem kasebut.

Komponen piranti lunak sing melu booting
Komponen ing ngisor iki melu ing proses boot-up sistem:

Gambar 1.1. Komponen Boot-up

Layanan Perangkat Lunak Hart (HSS)
Layanan Perangkat Lunak Hart (HSS) minangka noltage boot loader, monitor sistem, lan panyedhiya layanan runtime kanggo aplikasi. HSS ndhukung persiyapan sistem awal, latihan DDR, lan inisialisasi/konfigurasi hardware. Iku biasane mlaku ing E51s, karo jumlah cilik saka fungsi tingkat mode mesin mlaku ing saben U54s. Booting siji utawa luwih konteks kanthi ngemot "payload" aplikasi saka medium boot, lan nyedhiyakake Layanan Runtime Platform / Lingkungan Eksekusi Pengawas (SEE) kanggo kernel sistem operasi. Ndhukung boot aman lan minangka komponen penting kanggo njamin pemisahan / pamisahan hardware AMP konteks.

Das U-Boot (U-Boot)
Das U-Boot (U-Boot) minangka open-source universal scriptable boot loader. Ndhukung CLI prasaja sing bisa njupuk gambar boot saka macem-macem sumber (kalebu Card SD lan Jaringan). U-Boot ngemot Linux. Bisa nyedhiyakake lingkungan UEFI yen perlu. Umume rampung lan ora bisa digunakake nalika Linux wis boot - kanthi tembung liya, ora tetep dadi penduduk sawise boot.
Linux Kernel
Kernel Linux minangka kernel sistem operasi paling populer ing donya. Digabungake karo userland aplikasi, mbentuk apa sing umum diarani minangka sistem operasi Linux. Sistem Operasi Linux nyedhiyakake API POSIX sing sugih lan lingkungan pangembang, contoneample, basa lan piranti kayata Python, Perl, Tcl, Rust, C/C++, lan Tcl; perpustakaan kayata OpenSSL, OpenCV, OpenMP, OPC/UA, lan OpenAMP (RPmsg lan RemoteProc).
Yocto lan Buildroot minangka pembangun sistem Linux, yaiku, bisa digunakake kanggo ngasilake sistem Linux sing disesuaikan. Yocto ngasilake distribusi Linux kanthi sugih
set aplikasi, alat, lan perpustakaan, lan manajemen paket opsional. Buildroot ngasilake root sing luwih minimal filesistem lan bisa target sistem sing ora mbutuhake panyimpenan terus-terusan nanging mbukak kabeh saka RAM (nggunakake dhukungan inisial Linux, contone.ample).

Zephyr
Zephyr minangka Sistem Operasi Real-Time (RTOS) cilik lan mbukak-sumber. Iki nyedhiyakake Framework Low-Overhead Real-Time, kanthi saluran komunikasi RPMsg-lite menyang Linux. Iki kalebu kernel, perpustakaan, driver piranti, tumpukan protokol, filesistem, mekanisme kanggo nganyari perangkat kukuh, lan ing, lan apik kanggo pelanggan sing pengin pengalaman liyane Bare-metal-kaya ing PIC64GX.

Alur Boot
PIC64GX kalebu coreplex RISC-V karo hart monitor sistem E64 51-dicokot lan 4 harts aplikasi U64 54-dicokot. Ing terminologi RISC-V, hart minangka konteks eksekusi RISC-V sing ngemot set lengkap register lan nglakokake kode kasebut kanthi mandiri. Sampeyan bisa mikir minangka thread hardware utawa CPU siji. Klompok hart ing inti siji asring diarani kompleks. Topik iki njlèntrèhaké langkah-langkah kanggo initialize PIC64GX coreplex, kalebu sistem E51 monitor jantung lan aplikasi U54 harts.

Daya ing PIC64GX coreplex.
Ing daya-on, kabeh harts ing RISC-V coreplex dirilis saka reset dening Controller Keamanan.
Jalanake kode HSS saka memori lampu kilat eNVM on-chip.
Kaping pisanan, saben jantung wiwit mbukak kode HSS saka memori lampu kilat eNVM on-chip. Kode iki nyebabake kabeh harts aplikasi U54 muter, nunggu instruksi, lan ngijini E51 monitor hart miwiti kode mlaku kanggo initialize lan nggawa munggah sistem.

Decompress kode HSS saka eNVM kanggo memori L2-Scratch.
Gumantung ing konfigurasi wektu mbangun, HSS biasane luwih gedhe tinimbang kapasitas memori lampu kilat eNVM dhewe lan mulane kode HSS sing mlaku ing E51 yaiku decompress dhewe saka eNVM menyang memori L2-Scratch, kaya sing ditampilake ing Gambar. 1.2 lan Gambar 1.3.
Gambar 1.2. HSS Decompresses saka eNVM kanggo L2 Scratch
Gambar 1.3. Peta Memori HSS Sajrone Dekompresi
Langsung saka eNVM menyang L2-Scratch menyang eksekusi kaya sing ditampilake ing gambar ing ngisor iki.
Gambar 1.4. HSS Langsung saka eNVM menyang Kode Saiki ing L2Scratch Sawise Dekompresi
Eksekusi kasusun saka telung komponen:
- Lapisan abstraksi hardware (HAL), kode tingkat rendah, lan driver bare metal
- Garpu HSS lokal saka RISC-V OpenSBI (diowahi rada saka hulu ing PIC64GX kanggo AMP tujuan)
- Layanan runtime HSS (mesin negara mlaku ing super loop)
Miwiti struktur hardware lan data sing digunakake dening OpenSBI.
Layanan HSS "Mulai" tanggung jawab kanggo initialization iki.

Njupuk gambar beban kerja aplikasi (payload.bin) saka panyimpenan eksternal. Iki ditampilake ing Gambar 1.5 lan Gambar 1.6
Penting: Ing cilik saka PIC64GX Penasaran Kit, iki bakal saka kertu SD.
Gambar 1.5. Njupuk Gambar Beban Kerja payload.bin saka Panyimpenan Eksternal
Gambar 1.6. HSS Memory Map sawise Fetching payload.bin
Nyalin macem-macem bagean saka payload.bin menyang tujuan wektu eksekusi. Payload.bin punika gambar format, kang consolidates macem-macem gambar aplikasi kanggo SMP utawa AMP beban kerja. Iki kalebu kode, data, lan tabel deskriptor sing ngidini HSS nempatake kode lan bagean data kanthi tepat, sing dibutuhake kanggo mbukak macem-macem beban kerja aplikasi.
Gambar 1.7. payload.bin disalin menyang Alamat Tujuan

Ajar U54 sing cocog kanggo mlumpat menyang alamat wiwitan eksekusi. Informasi alamat wiwitan iki ana ing payload.bin.
Miwiti U54 Aplikasi harts lan sembarang detiktage boot loader. Kanggo example, U-Boot ndadekke munggah Linux.

Urip maneh

Gegandhengan karo konsep sistem booting iku perlu kanggo urip maneh. Nalika mikir babagan beban kerja aplikasi PIC64GX, urip maneh kudu nimbang loro simetri multiprocessing (SMP) lan multiprocessing asimetris (AMP) skenario:

Ing kasus sistem SMP, urip maneh bisa kanthi aman urip maneh kabeh sistem amarga ora ana beban kerja tambahan ing konteks liyane sing kudu dipikirake.

Ing kasus an AMP sistem, beban kerja mung diijini urip maneh (lan ora ngganggu konteks liyane), utawa duwe hak istimewa kanggo bisa nindakake urip maneh sistem kanthi lengkap.

Urip maneh lan AMP
Kanggo ngaktifake SMP lan AMP skenario urip maneh, HSS ndhukung konsep hak istimewa urip maneh anget lan kadhemen, kang assignable kanggo context. Konteks karo hak istimewa urip maneh anget mung bisa urip maneh dhewe, lan konteks karo hak istimewa urip maneh kadhemen bisa nindakake urip maneh sistem lengkap. Kanggo example, nimbang pesawat ing ngisor iki skenario wakil.

Beban kerja SMP konteks tunggal, sing diijini njaluk reboot sistem lengkap
Ing skenario iki, konteks diijini hak istimewa urip maneh kadhemen.
A loro-konteks AMP beban kerja, ing ngendi konteks A diijini njaluk reboot sistem lengkap (ngaruhi kabeh konteks), lan Konteks B mung diijini urip maneh.
Ing skenario iki, konteks A diijini hak istimewa urip maneh kadhemen, lan konteks B diijini hak istimewa urip maneh anget.
A loro-konteks AMP beban kerja, ing ngendi konteks A lan B mung diijini urip maneh (lan ora mengaruhi konteks liyane)
Ing skenario iki, loro konteks mung diijini hak istimewa urip maneh anget.
A loro-konteks AMP beban kerja, ing ngendi konteks A lan B diijini njaluk reboot sistem lengkap
Ing skenario iki, loro konteks diijini hak istimewa urip maneh kadhemen.
Salajengipun, iku bisa kanggo HSS ing wektu mbangun tansah ngidini hak istimewa urip maneh kadhemen, lan ora ngidini hak istimewa urip maneh kadhemen.

Relevan HSS Kconfig Pilihan
Kconfig minangka sistem konfigurasi mbangun piranti lunak. Biasane digunakake kanggo milih opsi wektu mbangun lan ngaktifake utawa mateni fitur. Iki asale saka kernel Linux nanging saiki wis digunakake ing proyek liyane ngluwihi kernel Linux, kalebu U-Boot, Zephyr, lan PIC64GX HSS.

HSS ngemot rong opsi Kconfig sing ngontrol fungsi urip maneh saka perspektif HSS:

CONFIG_ALLOW_COLD REBOOT
Yen iki diaktifake, global ngidini konteks kanggo ngetokake ecall urip maneh kadhemen. Yen dipateni, mung reboot anget sing bakal diidini. Saliyane ngaktifake pilihan iki, ijin kanggo ngetokake urip maneh kadhemen kudu diwenehake menyang konteks liwat generator muatan YAML file utawa pilihan Kconfig ing ngisor iki.
CONFIG_ALLOW_COLD REBOOT_ALWAYS
- Yen diaktifake, fitur iki global ngidini kabeh konteks kanggo ngetokake ECAA kadhemen urip maneh, preduli saka payload.bin flag entitlements.
- Kajaba iku, payload.bin dhewe bisa ngemot gendera saben konteks, nuduhake yen konteks tartamtu nduweni hak kanggo ngetokake reboot sing adhem:
  - Kanggo ngidini reboot anget konteks konteks liyane, kita bisa nambah opsi ngidini-reboot: anget ing katrangan YAML file digunakake kanggo nggawe payload.bin
  - Kanggo ngidini reboot kadhemen konteks saka kabeh sistem, kita bisa nambah opsi ngidini-reboot: kadhemen. Kanthi gawan, tanpa nemtokake ngidini-reboot, konteks mung diijini urip maneh panas dhewe Tanpa preduli saka setelan gendera iki, yen CONFIG_ALLOW_COLDREBOOT ora diaktifake ing HSS, HSS bakal ngolah maneh kabeh panjalukan urip maneh kadhemen kanggo anget (saben konteks) reboot. .

Urip maneh kanthi rinci
Bagean iki njlèntrèhaké cara urip maneh kanthi rinci - diwiwiti karo lapisan OpenSBI (lapisan mode M paling murah) lan banjur ngrembug babagan carane fungsi lapisan OpenSBI iki dipicu saka aplikasi RTOS utawa OS sugih kaya Linux.

OpenSBI Reboot ecall

Spesifikasi RISC-V Supervisor Binary Interface (SBI) njlèntrèhaké lapisan abstraksi hardware standar kanggo inisialisasi platform lan layanan runtime firmware. Tujuan utama SBI yaiku kanggo ngaktifake portabilitas lan kompatibilitas ing macem-macem implementasi RISC-V.
OpenSBI (Open Source Supervisor Binary Interface) minangka proyek sumber terbuka sing nyedhiyakake implementasi referensi saka spesifikasi SBI. OpenSBI uga nyedhiyakake layanan runtime, kalebu penanganan interupsi, manajemen wektu, lan console I/O, sing bisa dimanfaatake dening lapisan piranti lunak sing luwih dhuwur.
OpenSBI kalebu minangka bagéan saka HSS lan mlaku ing tingkat Machine Mode. Nalika sistem operasi utawa aplikasi nyebabake jebakan, bakal diterusake menyang OpenSBI kanggo nangani. OpenSBI mbabarake fungsi jinis telpon sistem tartamtu menyang lapisan ndhuwur piranti lunak liwat mekanisme jebakan tartamtu sing diarani ecall.

Reset Sistem (EID 0x53525354) nyedhiyakake fungsi panggilan sistem lengkap sing ngidini piranti lunak lapisan ndhuwur njaluk urip maneh utawa mati tingkat sistem. Sawise ecall iki dijaluk dening U54, iku kepepet dening piranti lunak HSS mlaku ing Machine Mode ing U54 sing, lan panjalukan urip maneh cocog dikirim menyang E51 kanggo urip maneh salah siji konteks utawa kabeh sistem, gumantung ing hak saka konteks.

Kanggo informasi luwih lengkap, ndeleng ing Spesifikasi Antarmuka Binary Supervisor RISC-V utamané Ekstensi Reset Sistem (EID #0x53525354 "SRST").

Linux Reboot

Minangka eks tartamtuampIki, ing Linux, printah mateni digunakake kanggo mungkasi utawa urip maneh sistem. Printah kasebut biasane duwe akeh alias, yaiku mandheg, mateni, lan urip maneh. Alias iki nemtokake manawa mesin kudu mandheg nalika mati, mateni mesin nalika mati, utawa urip maneh mesin nalika mati.

Printah pangguna-ruang iki ngetokake telpon sistem urip maneh menyang Linux, sing kepepet dening kernel lan interworked menyang ecall SBI.
Ana macem-macem tingkat reboot - REBOOT_WARM, REBOOT_COLD, REBOOT_HARD - iki bisa diterusake minangka argumen baris perintah menyang kernel (kanggo example, reboot=w[arm] kanggo REBOOT_WARM). Kanggo informasi luwih lengkap babagan kode sumber kernel Linux, waca Dokumentasi/admin-guide/kernel-paramters.txt.
Utawa, yen / sys / kernel / reboot diaktifake, panangan ing ngisor iki bisa diwaca kanggo entuk konfigurasi urip maneh sistem saiki, lan ditulis kanggo ngowahi. Kanggo informasi luwih lengkap babagan kode sumber kernel Linux, waca Dokumentasi/ABI/testing/sysfs-kernel-reboot.

Pengawas

Konsep liyane sing gegandhengan karo booting sistem lan rebooting sistem yaiku pemulihan sistem nalika dipateni timer pengawas. Timer Watchdog digunakake akeh ing sistem sing dipasang supaya bisa pulih kanthi otomatis saka kesalahan hardware sementara, lan kanggo nyegah piranti lunak sing salah utawa jahat ngganggu operasi sistem.
PIC64GX kalebu support watchdog hardware kanggo ngawasi harts individu nalika sistem mlaku. Pengawas mesthekake yen harts bisa diwiwiti maneh yen ora nanggapi amarga kesalahan piranti lunak sing ora bisa dibalekake.
PIC64GX kalebu limang pamblokiran hardware timer watchdog digunakake kanggo ndeteksi lockups sistem -siji kanggo saben harts. Kanggo nggampangake campuran Multi-Processing Asymmetrical (AMP) beban kerja, HSS ndhukung ngawasi lan menehi reaksi marang asu-asu sing dipecat.

PIC64GX Watchdog

HSS tanggung jawab kanggo booting harts aplikasi ing daya-up, lan kanggo miwiti maneh (individu utawa bebarengan) ing sembarang wektu.tage, yen perlu utawa dikarepake. Minangka akibat saka iki, nanggepi acara watchdog ing PIC64GX ditangani dening HSS.
Monitor 'virtual watchdog' dileksanakake minangka layanan mesin negara HSS, lan tanggung jawab kanggo ngawasi status saben monitor hardware U54 individu. Nalika salah siji saka pengawas U54 iki lelungan, HSS ndeteksi iki lan bakal urip maneh U54 minangka cocok. Yen U54 minangka bagean saka konteks SMP, kabeh konteks dianggep kanggo urip maneh, amarga konteks kasebut nduweni hak istimewa urip maneh. Sistem kabeh bakal urip maneh yen konteks nduweni hak istimewa urip maneh kadhemen.

Relevan Kconfig Pilihan

Dhukungan Watchdog kalebu minangka standar ing mbangun HSS sing dirilis. Yen sampeyan pengin mbangun HSS adat, bagean iki bakal njlèntrèhaké mekanisme konfigurasi kanggo mesthekake yen support Watchdog diaktifake.

HSS dikonfigurasi nggunakake sistem konfigurasi Kconfig. A toplevel .config file dibutuhake kanggo milih layanan apa sing dikompilasi ing utawa metu saka bangunan HSS.
Kaping pisanan, pilihan CONFIG_SERVICE_WDOG tingkat ndhuwur kudu diaktifake ("Dhukungan Pengawas Virtual" liwat konfigurasi make).

Iki banjur mbukak sub-opsi ing ngisor iki sing gumantung marang dhukungan Watchdog:

CONFIG_SERVICE_WD OG_DEBUG
Mbisakake dhukungan kanggo pesen informasi / debug saka layanan pengawas virtual.
CONFIG_SERVICE_WD OG_DEBUG_TIMEOUT_SECS
Nemtokake periodicity (ing detik) sing Watchdog debug pesen bakal output dening HSS.
CONFIG_SERVICE_WD OG_ENABLE_E51
Mbisakake watchdog kanggo E51 monitor jantung saliyane U54s, nglindhungi operasi saka HSS dhewe.

Nalika watchdog E51 diaktifake, HSS periodik nulis kanggo Watchdog kanggo refresh lan nyegah saka diperlokaké. Yen, sakperangan alesan, jantung E51 dikunci utawa nabrak lan watchdog E51 diaktifake, iki bakal tansah ngreset kabeh sistem.

Operasi Watchdog
Hardware watchdog ngleksanakake counter mudhun. Jendhela sing dilarang refresh bisa digawe kanthi ngonfigurasi Nilai Maksimum pengawas nganti sing Diidini Refresh (MVRP).

Nalika nilai saiki watchdog timer luwih saka nilai MVRP, refreshing watchdog dilarang. Nyoba kanggo refresh timer watchdog ing jendhela larang bakal negesake interupsi wektu entek.

Refresh watchdog antarane Nilai MVRP lan Nilai Pemicu (TRIG) bakal kasil refresh counter lan nyegah watchdog saka diperlokaké.
Sawise nilai timer watchdog count ngisor Nilai TRIG, watchdog bakal murub.

Mesin Negara Pengawas

Mesin negara watchdog banget langsung - diwiwiti kanthi ngonfigurasi watchdog kanggo E51, yen diaktifake, banjur pindhah menyang ngawasi. Saben wektu ing superloop, negara ngawasi iki dijaluk, sing mriksa status saben pengawas U54.

Mesin negara watchdog sesambungan karo mesin negara boot kanggo miwiti maneh hart (lan harts liyane sing ana ing pesawat boot sawijining), yen ndeteksi hart wis ora ngatur kanggo refresh watchdog ing wektu.

Mode Kunci

Biasane (utamane karo AMP aplikasi), samesthine HSS bakal tetep manggon ing M-mode, ing U54, kanggo ngidini urip maneh saben konteks (ie urip maneh mung siji konteks, tanpa urip maneh chip lengkap), lan ngidini HSS ngawasi kesehatan ( ECC, Bit Status Kunci, Kesalahan Bus, kesalahan SBI, Pelanggaran PMP, lsp).

Kanggo nyedhiyakake kapabilitas urip maneh ing saben-AMP basis konteks (tanpa mbutuhake kabeh sistem kanggo urip maneh), E51 biasane duwe hak istimewa akses memori kanggo kabeh papan memori sistem. Nanging, bisa uga ana kahanan sing ora dikarepake, lan pelanggan luwih seneng mbatesi apa sing ditindakake dening firmware E51 HSS yen sistem wis sukses. Ing kasus iki, bisa dilebokake HSS menyang mode kunci sawise U54 Aplikasi Harts wis boot.

Iki bisa diaktifake nggunakake pilihan HSS Kconfig CONFIG_SERVICE_LOCKDOWN.
Layanan kunci dimaksudake kanggo ngidini watesan kegiatan HSS sawise boot aplikasi U54 Harts.

Gambar 4.2. Mode Lockdown HSS

Sawise mode Lockdown diwiwiti, kabeh mesin negara layanan HSS ora bisa mlaku. Iki nyebutake rong fungsi sing ora kuwat:

e51_pmp_lockdown(), lan
e51_lockdown()

Fungsi-fungsi kasebut dimaksudake kanggo diganti dening kode khusus papan. Kapisan minangka fungsi pemicu sing bisa dikonfigurasi supaya BSP bisa ngatur ngunci E51 metu saka beban aplikasi ing titik iki. Implementasi standar sing lemah banget kanggo fungsi iki kosong. Kapindho yaiku fungsi sing ditindakake saka titik kasebut. Implementasine gawan weakly-bound layanan watchdog ing titik iki ing E51, lan bakal urip maneh yen watchdog U54 murub. Kanggo informasi luwih lengkap, waca kode sumber HSS ing services/lockdown/lockdown_service.c file.

Lampiran

HSS payload.bin Format

bagean iki njlèntrèhaké payload.bin file format lan gambar digunakake dening HSS kanggo boot PIC64GX SMP lan AMP aplikasi.
Payload.bin minangka binar format (Gambar A.10) sing kasusun saka sirah, macem-macem tabel deskriptor, lan macem-macem potongan sing ngemot kode lan bagean data saben bagean saka beban kerja aplikasi. A cuwilan bisa dianggep minangka blok memori contiguous ukuran sewenang-wenang.

Gambar A.10. Payload.bin Format

Bagean header (ditampilake ing Figure A.11) ngemot nilai tenung digunakake kanggo ngenali payload.bin lan sawetara informasi housekeeping, bebarengan karo rincian gambar dimaksudaké kanggo mbukak ing saben
kode aplikasi U54. Iku nggambarake carane boot saben U54 hart individu, lan pesawat saka gambar bootable sakabèhé. Ing informasi housekeeping sawijining, wis penunjuk kanggo macem-macem tabel deskriptor kanggo ngidini ukuran header kanggo tuwuh.

Gambar A.11. payload.bin Header

Kode lan data konstan sing diinisialisasi dianggep mung diwaca lan disimpen ing bagean mung diwaca, sing dituduhake dening deskriptor header.
Variabel data sing ora diinisialisasi nol yaiku data sing diwaca-tulis nanging nduweni nilai inisialisasi sing disalin saka potongan mung diwaca nalika wiwitan. Iki uga disimpen ing bagean mung diwaca.

Bagean data muatan mung diwaca digambarake kanthi tabel kode lan deskriptor potongan data. Saben deskriptor potongan ing tabel iki ngemot 'pemilik hart' (harta utama ing konteks sing dituju
ing), beban offset (offset ing payload.bin), lan alamat eksekusi (alamat tujuan ing memori PIC64GX), bebarengan karo ukuran lan checksum. Iki dituduhake ing Figure A.12.

Gambar A.12. Deskriptor Potongan Mung Waca lan Data Potongan Payload

Saliyane potongan kasebut, ana uga potongan memori sing cocog karo variabel data sing diinisialisasi dadi nol. Iki ora disimpen minangka data ing payload.bin, nanging minangka set khusus saka deskriptor potongan nul-initialized, sing nemtokake alamat lan dawa RAM kanggo nyetel menyang nul nalika wiwitan. Iki dituduhake ing Figure A.13.

Gambar A.13. ZI Cukur

hss-payload-generator
Alat HSS Payload Generator nggawe gambar muatan format kanggo Hart Software Service nul-stage bootloader ing PIC64GX, diwenehi konfigurasi file lan pesawat saka ELF files lan / utawa binar. Konfigurasi file digunakake kanggo map binar ELF utawa blobs binar menyang harts aplikasi individu (U54s).

Gambar B.14. hss-payload-generator Aliran

Alat kasebut nindakake pamriksa kewarasan dhasar babagan struktur konfigurasi file dhewe lan ing gambar ELF. Gambar ELF kudu eksekusi RISC-V.

Examplan Run

Kanggo mbukak alat hss-payload-generator karo sampkonfigurasi le file lan ELF files:
$ ./hss-payload-generator -c test/config.yaml output.bin
Kanggo nyithak diagnostik babagan gambar sing wis ana, gunakake:
$ ./hss-payload-generator -d output.bin

Kanggo ngaktifake otentikasi boot aman (liwat tandha gambar), gunakake -p kanggo nemtokake lokasi Kunci Pribadi X.509 kanggo Elliptic Curve P-384 (SECP384r1):
$ ./hss-payload-generator -c test/config.yaml payload.bin -p /path/to/private.pem

Kanggo informasi luwih lengkap, waca dokumentasi Otentikasi Boot Aman.

Konfigurasi File Example

Kaping pisanan, kita bisa nyetel jeneng kanggo gambar kita, yen ora, siji bakal digawe kanthi dinamis:
set-name: 'PIC64-HSS::TestImage'
Sabanjure, kita bakal nemtokake alamat titik entri kanggo saben jantung, kaya ing ngisor iki:
hart-entry-points: {u54_1: ‘0x80200000’, u54_2: ‘0x80200000’, u54_3: ‘0xB0000000′, u54_4:’0x80200000’}

Gambar sumber ELF bisa nemtokake titik entri, nanging kita pengin bisa ndhukung titik entri sekunder kanggo harts yen perlu, kanggo example, yen sawetara harts dimaksudaké kanggo boot gambar padha, padha bisa duwe titik entri individu. Kanggo ndhukung iki, kita nemtokake alamat titik entri sing nyata ing konfigurasi kasebut file dhewe.

Saiki kita bisa nemtokake sawetara muatan (sumber ELF files, utawa gumpalan binar) sing bakal diselehake ing wilayah tartamtu ing memori. Bagean payload ditetepake karo payloads tembung kunci, banjur sawetara deskriptor payload individu. Saben muatan duwe jeneng (path menyang file), pemilik-hart, lan opsional 1 nganti 3 hart sekunder.

Kajaba iku, muatan duwe mode hak istimewa sing bakal miwiti eksekusi. Mode hak istimewa sing bener yaiku PRV_M, PRV_S lan PRV_U, sing ditetepake minangka:

PRV_M Mode mesin
PRV_S mode Supervisor
PRV_U Mode pangguna

Ing ngisor iki example:

test / zephyr.elf dianggep minangka aplikasi Zephyr sing mlaku ing U54_3, lan ngarepake miwiti ing mode PRV_M hak istimewa.
test / u-boot-dtb.bin iku aplikasi bootloader Das U-Boot, lan mlaku ing U54_1, U54_2 lan U54_4. Iku ngarepake kanggo miwiti ing PRV_S mode hak istimewa.

penting:
Output saka U-Boot nggawe ELF file, nanging biasane ora prepend extension .elf. Ing kasus iki, binar sing digawe dening CONFIG_OF_SEPARATE digunakake, sing nambahake gumpalan wit piranti menyang binar U-Boot.

Iki mantanampkonfigurasi Payloads 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}

penting:
Kasus mung penting kanggo file jeneng path, dudu tembung kunci. Dadi, contone, u54_1 dianggep padha karo U54_1, lan exec-addr dianggep padha karo EXEC-ADDR. Yen extension an.elf utawa .bin ana, iku kudu kalebu ing konfigurasi file.

Kanggo aplikasi bare metal sing ora pengin prihatin karo OpenSBI, opsi skip-opens, yen bener, bakal nyebabake muatan ing jantung kasebut dijaluk nggunakake mret sing prasaja.
tinimbang telpon OpenSBI sbi_init (). Iki tegese jantung bakal miwiti mbukak kode logam tanpa preduli saka OpenSBI HSM. Elinga yen iki uga tegese jantung ora bisa digunakake
ecalls kanggo ngundang fungsi OpenSBI. Opsi skip-opens iku opsional lan gawan dadi palsu.

Kanggo ngidini reboot anget konteks konteks liyane, kita bisa nambah pilihan ngidini urip maneh: anget. Kanggo ngidini reboot kadhemen konteks saka kabeh sistem, kita bisa nambah opsi ngidini-reboot: kadhemen. Kanthi gawan, tanpa nemtokake ngidini-reboot, konteks mung diijini kanggo anget urip maneh.
Sampeyan uga bisa nggandhengake data tambahan karo saben muatan, contoneamplan, DeviceTree Blob (DTB) file, kanthi nemtokake data tambahan filejeneng kaya ing ngisor iki:
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 }
Data tambahan iki bakal dilebokake ing muatan (diselehake langsung sawise file utama file ing eksekusi
spasi), lan alamate bakal diterusake menyang OpenSBI ing kolom next_arg1 (dilulusake ing daftar $a1 menyang gambar nalika boot).

Kanggo nyegah HSS saka booting konteks kanthi otomatis (contone, yen kita pengin utusan kontrol iki menyang konteks nggunakake remoteProc), gunakake bendera skip-autoboot:
test/zephyr.elf: {exec-addr: '0xB0000000', owner-hart: u54_3, priv-mode: prv_m, skip-opensbi: true, skip-autoboot: true}
Pungkasan, kita bisa milih ngganti jeneng muatan individu, nggunakake opsi jeneng muatan. Kanggo 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' }

Elinga yen pembangun Yocto lan Buildroot Linux bakal mbangun, ngatur, lan mbukak hss-payload-
generator minangka needed kanggo generate gambar aplikasi. Kajaba iku, pic64gx-curiosity-kit-amp target mesin ing Yocto bakal ngasilake gambar aplikasi nggunakake alat hss-payload-generator sing nduduhake AMP, karo Linux mlaku ing 3 hart lan Zephyr mlaku ing 1 hart.

Riwayat Revisi
Riwayat revisi nggambarake owah-owahan sing ditindakake ing dokumen kasebut. Owah-owahan kasebut didhaptar kanthi revisi, diwiwiti saka publikasi paling anyar.

Revisi	Tanggal	Katrangan
A	07/2024	Revisi wiwitan

Informasi Microchip

Microchip kasebut Websitus
Microchip nyedhiyakake dhukungan online liwat kita websitus ing www.microchip.com/. Iki websitus digunakake kanggo nggawe files lan informasi gampang kasedhiya kanggo pelanggan. Sawetara konten sing kasedhiya kalebu:

Dhukungan produk - Lembar data lan kesalahan, cathetan aplikasi lan sampprogram le, sumber desain, Panuntun pangguna lan dokumen support hardware, Rilis piranti lunak paling anyar lan piranti lunak arsip

Dhukungan Teknis Umum - Pitakonan sing Sering Ditakoni (FAQ), panjalukan dhukungan teknis, grup diskusi online, daftar anggota program mitra desain Microchip
Bisnis Microchip - Pandhuan pamilih lan pesenan produk, siaran pers Microchip paling anyar, dhaptar seminar lan acara, dhaptar kantor penjualan Microchip, distributor, lan perwakilan pabrik

Layanan Notifikasi Ganti Produk

Layanan kabar pangowahan produk Microchip mbantu para pelanggan tetep saiki ing produk Microchip. Pelanggan bakal nampa kabar email yen ana owah-owahan, nganyari, revisi utawa kesalahan sing ana gandhengane karo kulawarga produk utawa alat pangembangan sing dikarepake.

Kanggo ndhaftar, pindhah menyang www.microchip.com/pcn lan tindakake pandhuan registrasi.

Dhukungan Pelanggan
Pangguna produk Microchip bisa nampa pitulung liwat sawetara saluran:

Distributor utawa Perwakilan
Kantor Penjualan Lokal
Embedded Solution Engineer (ESE)
Dhukungan Teknis

Pelanggan kudu ngontak distributor, perwakilan, utawa ESE kanggo dhukungan. Kantor penjualan lokal uga kasedhiya kanggo mbantu para pelanggan. Dhaptar kantor penjualan lan lokasi kalebu ing dokumen iki.
Dhukungan teknis kasedhiya liwat websitus ing: www.microchip.com/support.

Fitur Proteksi Kode Piranti Microchip
Elinga rincian ing ngisor iki babagan fitur perlindungan kode ing produk Microchip:

Produk Microchip cocog karo spesifikasi sing ana ing Lembar Data Microchip tartamtu.
Microchip percaya yen kulawarga produk kasebut aman nalika digunakake kanthi cara sing dikarepake, ing spesifikasi operasi, lan ing kahanan normal.

Nilai Microchip lan agresif nglindhungi hak properti intelektual sawijining. Usaha kanggo nglanggar fitur perlindungan kode produk Microchip dilarang banget lan bisa uga nglanggar Digital Millennium Copyright Act.
Microchip utawa pabrikan semikonduktor liyane ora bisa njamin keamanan kode kasebut. Proteksi kode ora ateges manawa produk kasebut "ora bisa dipecah". Proteksi kode terus berkembang. Microchip nduweni komitmen kanggo terus ningkatake fitur perlindungan kode produk kita.

Kabar Legal
Publikasi iki lan informasi ing kene mung bisa digunakake karo produk Microchip, kalebu kanggo ngrancang, nguji, lan nggabungake produk Microchip karo aplikasi sampeyan. Panganggone informasi iki kanthi cara liya nglanggar syarat kasebut. Informasi babagan aplikasi piranti diwenehake mung kanggo penak lan bisa diganti karo nganyari. Sampeyan tanggung jawab kanggo mesthekake yen aplikasi sampeyan cocog karo spesifikasi sampeyan. Hubungi kantor sales Microchip lokal kanggo dhukungan tambahan utawa, entuk dhukungan tambahan ing www.microchip.com/en-us/support/design-help/client-support-services.

INFORMASI IKI DISEDIAKAN BY MICROCHIP "AS IS". MICROCHIP TANPA REPRESENTASI UTAWA JAMINAN APA SAJA APA SAJA UTAWA TERSURAT, TERTULIS UTAWA LISAN, STATUTORY UTAWA LAIN, sing ana hubungane karo informasi kasebut kalebu nanging ora winates karo JAMINAN NON-INFLARITY, NON-INFRINGEMENT. TUJUAN, Utawa JAMINAN sing ana gandhengane karo KONDISI, KUALITAS, UTAWA KINERJA.

MICROCHIP ORA TANGGUH TANGGUNG JAWAB ANGGARAN, KHUSUS, PUNITIF, INSIDENTAL, UTAWA KONSEKUENSI, RUGI, KERUSAKAN, BIAYA, UTAWA BAYARAN APA SAJA KANGGO ING INFORMASI UTAWA PENGGUNAAN, NANGING SING DIBUNTAK, SANAYAN IKI KEMUNGKINAN UTAWA KERUSAKAN SING BISA. SAKA FULLEST diijini dening hukum, tanggung jawab TOTAL MICROCHIP ing kabeh pratelan ing sembarang cara sing ana hubungane karo informasi utawa panggunaan ora ngluwihi nomer biaya, yen ana, sing wis mbayar langsung menyang microchip kanggo informasi.

Panggunaan piranti Microchip ing support urip lan / utawa aplikasi safety tanggung ing resiko panuku, lan panuku setuju kanggo defend, indemnify, lan terus Microchip mbebayani saka kabeh karusakan, claims, cocog, utawa expenses asil saka nggunakake kuwi. Ora ana lisensi sing diwenehake, kanthi implisit utawa liya, miturut hak properti intelektual Microchip kajaba nyatakake.

merek dagang
Jeneng lan logo Microchip, logo Microchip, Adaptec, AVR, logo AVR, AVR Freaks, BesTime, BitCloud, CryptoMemory, CryptoRF, dsPIC, flexPWR, HELDO, IGLOO, JukeBlox, KeeLoq, Kleer, LANCheck, LinkMD, maXStylus, maXTouch MediaLB, megaAVR, Microsemi, logo Microsemi, 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, lan XMEGA minangka merek dagang kadhaptar saka Microchip Technology Incorporated ing AS lan negara liya.

AgileSwitch, ClockWorks, Perusahaan Solusi Kontrol Embedded, EtherSynch, Flashtec, Kontrol Kacepetan Hiper, Beban HyperLight, Libero, bangku motor, mTouch, Powermite 3, Precision Edge, ProASIC, ProASIC Plus, logo ProASIC Plus, Quiet-Wire, SmartFusion, SyncWorld , TimeCesium, TimeHub, TimePictra, TimeProvider, lan ZL minangka merek dagang kadhaptar saka Microchip Technology Incorporated ing AS

Penindasan Kunci Adjacent, AKS, Analog-kanggo-Digital Age, Kapasitor Apa wae, AnyIn, AnyOut, Switching Augmented, BlueSky, BodyCom, Clockstudio, CodeGuard, CryptoAuthentication, CryptoAutomotive, CryptoCompanion, CryptoController, dsPICDEM, dsPICDEM.net Average Matching, Dynamic Matching , 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 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, peta prasaja, 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, lan ZENA minangka merek dagang Microchip Technology Incorporated ing AS lan negara liya.

SQTP minangka tandha layanan saka Microchip Technology Incorporated ing AS
Logo Adaptec, Frequency on Demand, Silicon Storage Technology, lan Symmcom minangka merek dagang kadhaptar saka Microchip Technology Inc. ing negara liya.
GestIC minangka merek dagang kadhaptar saka Microchip Technology Germany II GmbH & Co. KG, anak perusahaan saka Microchip Technology Inc., ing negara liya.

ISBN: 978-1-6683-4890-1

Sistem Manajemen Mutu
Kanggo informasi babagan Sistem Manajemen Kualitas Microchip, bukak www.microchip.com/quality.

Dodolan lan Layanan ing saindenging jagad

AMERIKA

ASIA / PASIFIK

EROPA

perusahaan kantor

2355 West Chandler Blvd. Chandler, AZ 85224-6199

Telpon: 480-792-7200

Fax: 480-792-7277

Dhukungan Teknis: www.microchip.com/support

Web alamat: www.microchip.com

Atlanta

Duluth, GA

Telpon: 678-957-9614

Fax: 678-957-1455

Austin, TX

Telpon: 512-257-3370

Boston

Westborough, MA Telp: 774-760-0087

Fax: 774-760-0088

Chicago

Itasca, IL

Telpon: 630-285-0071

Fax: 630-285-0075

Dallas

Addison, TX

Telpon: 972-818-7423

Fax: 972-818-2924

Detroit

Novi, MI

Telpon: 248-848-4000

Houston, TX

Telpon: 281-894-5983

Indianapolis

Noblesville, IN Tel: 317-773-8323

Fax: 317-773-5453

Telpon: 317-536-2380

Los Angeles

Mission Viejo, CA Telp: 949-462-9523

Fax: 949-462-9608

Telpon: 951-273-7800

Raleigh, NC

Telpon: 919-844-7510

New York, NY

Telpon: 631-435-6000

San Jose, CA

Telpon: 408-735-9110

Telpon: 408-436-4270

Kanada – Toronto

Telpon: 905-695-1980

Fax: 905-695-2078

Australia - Sydney

Telpon: 61-2-9868-6733

China - Beijing

Telpon: 86-10-8569-7000

China - Chengdu

Telpon: 86-28-8665-5511

China - Chongqing

Telpon: 86-23-8980-9588

China - Dongguan

Telpon: 86-769-8702-9880

China - Guangzhou

Telpon: 86-20-8755-8029

China - Hangzhou

Telpon: 86-571-8792-8115

Cina – Hong Kong SAR

Telpon: 852-2943-5100

China - Nanjing

Telpon: 86-25-8473-2460

China - Qingdao

Telpon: 86-532-8502-7355

China - Shanghai

Telpon: 86-21-3326-8000

China - Shenyang

Telpon: 86-24-2334-2829

China - Shenzhen

Telpon: 86-755-8864-2200

China - Suzhou

Telpon: 86-186-6233-1526

China - Wuhan

Telpon: 86-27-5980-5300

China - Xian

Telpon: 86-29-8833-7252

China - Xiamen

Telpon: 86-592-2388138

China - Zhuhai

Telpon: 86-756-3210040

India – Bangalore

Telpon: 91-80-3090-4444

India - New Delhi

Telpon: 91-11-4160-8631

India – Pune

Telpon: 91-20-4121-0141

Jepang – Osaka

Telpon: 81-6-6152-7160

Jepang – Tokyo

Telpon: 81-3-6880-3770

Korea - Daegu

Telpon: 82-53-744-4301

Korea - Seoul

Telpon: 82-2-554-7200

Malaysia – Kuala lumpur

Telpon: 60-3-7651-7906

Malaysia – Penang

Telpon: 60-4-227-8870

Filipina – Manila

Telpon: 63-2-634-9065

Singapura

Telpon: 65-6334-8870

Taiwan - Hsin Chu

Telpon: 886-3-577-8366

Taiwan - Kaohsiung

Telpon: 886-7-213-7830

Taiwan - Taipei

Telpon: 886-2-2508-8600

Thailand – Bangkok

Telpon: 66-2-694-1351

Vietnam - Ho Chi Minh

Telpon: 84-28-5448-2100

Austria – Wels

Telpon: 43-7242-2244-39

Fax: 43-7242-2244-393

Denmark – Kopenhagen

Telpon: 45-4485-5910

Fax: 45-4485-2829

Finlandia – Espoo

Telpon: 358-9-4520-820

Prancis – Paris

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

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

Jerman – garching

Telpon: 49-8931-9700

Jerman – Haan

Telpon: 49-2129-3766400

Jerman – Heilbronn

Telpon: 49-7131-72400

Jerman – Karlsruhe

Telpon: 49-721-625370

Jerman – Munich

Tel: 49-89-627-144-0

Fax: 49-89-627-144-44

Jerman – Rosenheim

Telpon: 49-8031-354-560

Israel - Hod Hasharon

Telpon: 972-9-775-5100

Italia - Milan

Telpon: 39-0331-742611

Fax: 39-0331-466781

Italia - Padova

Telpon: 39-049-7625286

Walanda - Drunen

Telpon: 31-416-690399

Fax: 31-416-690340

Norwegia – Trondheim

Telpon: 47-72884388

Polandia - Warsawa

Telpon: 48-22-3325737

Romania – Bukares

Tel: 40-21-407-87-50

Spanyol - Madrid

Tel: 34-91-708-08-90

Fax: 34-91-708-08-91

Swedia - Gothenburg

Tel: 46-31-704-60-40

Swedia - Stockholm

Telpon: 46-8-5090-4654

UK - Wokingham

Telpon: 44-118-921-5800

Fax: 44-118-921-5820

Dokumen / Sumber Daya

MICROCHIP PIC64GX 64-Bit RISC-V Quad-Core Mikroprosesor [pdf] Pandhuan pangguna
PIC64GX, PIC64GX 64-Bit RISC-V Quad-Core Microprocessor, 64-Bit RISC-V Quad-Core Microprocessor, RISC-V Quad-Core Microprocessor, Quad-Core Microprocessor, Mikroprosesor

Referensi

Manual pangguna

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

Informasi produk

Pandhuan Panggunaan Produk