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

Proses Booting
1. Komponen Perangkat Lunak yang Terlibat dalam Booting
  Proses boot-up sistem melibatkan komponen perangkat lunak berikut:
  - Layanan Perangkat Lunak Hart (HSS): Noltage boot loader, monitor sistem, dan penyedia layanan runtime untuk aplikasi.
2. Aliran Booting
  Urutan alur boot sistem adalah sebagai berikut:
  1. Inisialisasi Layanan Perangkat Lunak Hart (HSS)
  2. Eksekusi bootloader
  3. Memulai aplikasi
Anjing penjaga
1. Pengawas PIC64GX
  PIC64GX dilengkapi fungsi pengawas untuk memantau operasi sistem dan memicu tindakan jika terjadi kegagalan sistem.
Mode Penguncian
Mode lockdown dirancang untuk pelanggan yang memerlukan kontrol penuh atas tindakan sistem setelah booting. Ini membatasi fungsi monitor sistem E51.

Tanya Jawab Umum

T: Apa tujuan dari Hart Software Services (HSS)?
J: HSS berfungsi sebagai zero-stage boot loader, monitor sistem, dan penyedia layanan runtime untuk aplikasi selama proses boot.
T: Bagaimana cara kerja fungsi pengawas PIC64GX?
J: Pengawas PIC64GX memantau operasi sistem dan dapat mengambil tindakan yang telah ditentukan jika terjadi kegagalan sistem untuk memastikan keandalan sistem.

Perkenalan

Whitepaper ini menjelaskan bagaimana Microchip PIC64GX mem-boot beban kerja aplikasi dan menjelaskan proses boot sistem, yang beroperasi sama untuk SMP dan AMP beban kerja. Selain itu, ini mencakup cara kerja reboot untuk SMP dan AMP beban kerja, pengawas pada PIC64GX, dan mode penguncian khusus untuk sistem di mana pelanggan menginginkan kontrol penuh untuk membatasi tindakan monitor sistem E51 setelah boot sistem.

Proses Booting

Mari kita lihat berbagai komponen perangkat lunak yang terlibat dalam booting sistem, diikuti dengan melihat lebih detail urutan alur boot sistem itu sendiri.

Komponen Perangkat Lunak yang Terlibat dalam Booting
Komponen berikut terlibat dalam proses boot-up sistem:

Gambar 1.1. Komponen Booting

Layanan Perangkat Lunak Hart (HSS)
Layanan Perangkat Lunak Hart (HSS) adalah noltage boot loader, monitor sistem, dan penyedia layanan runtime untuk aplikasi. HSS mendukung pengaturan sistem awal, pelatihan DDR, dan inisialisasi/konfigurasi perangkat keras. Ini sebagian besar berjalan pada E51, dengan sejumlah kecil fungsionalitas tingkat mode mesin berjalan pada setiap U54. Ini mem-boot satu atau lebih konteks dengan memuat "payload" aplikasi dari media boot, dan menyediakan Platform Runtime Services/Supervisor Execution Environment (SEE) untuk kernel sistem operasi. Ini mendukung boot aman dan merupakan komponen penting dalam memastikan partisi/pemisahan perangkat keras AMP konteks.

Das U-Boot (U-Boot)
Das U-Boot (U-Boot) adalah pemuat boot skrip universal sumber terbuka. Ini mendukung CLI sederhana yang dapat mengambil image boot dari berbagai sumber (termasuk Kartu SD dan Jaringan). U-Boot memuat Linux. Ini dapat menyediakan lingkungan UEFI jika diperlukan. Biasanya sudah selesai dan selesai setelah Linux di-boot – dengan kata lain, ia tidak akan tetap ada setelah boot.
Kernel Linux
Kernel Linux adalah kernel sistem operasi paling populer di dunia. Dikombinasikan dengan lahan pengguna aplikasi, membentuk apa yang biasa disebut sebagai sistem operasi Linux. Sistem Operasi Linux menyediakan API POSIX yang kaya dan lingkungan pengembang, misalnyaample, bahasa dan alat seperti Python, Perl, Tcl, Rust, C/C++, dan Tcl; perpustakaan seperti OpenSSL, OpenCV, OpenMP, OPC/UA, dan OpenAMP (RPmsg dan RemoteProc).
Yocto dan Buildroot adalah pembuat sistem Linux, artinya keduanya dapat digunakan untuk menghasilkan sistem Linux yang disesuaikan dan dipesan lebih dahulu. Yocto mengeluarkan distribusi Linux dengan kaya
kumpulan aplikasi, alat, dan perpustakaan, serta manajemen paket opsional. Buildroot menghasilkan root yang lebih minimal filesistem dan dapat menargetkan sistem yang tidak memerlukan penyimpanan persisten tetapi dijalankan sepenuhnya dari RAM (misalnya menggunakan dukungan inisial Linuxampsaya).

Angin barat
Zephyr adalah Sistem Operasi Real-Time (RTOS) bersumber terbuka dan kecil. Ini menyediakan Kerangka Kerja Low-Overhead Real-Time, dengan saluran komunikasi RPMsg-lite ke Linux. Ini mencakup kernel, perpustakaan, driver perangkat, tumpukan protokol, filesistem, mekanisme pembaruan firmware, dan sebagainya, dan sangat bagus untuk pelanggan yang menginginkan pengalaman lebih seperti bare-metal di PIC64GX.

Aliran Booting
PIC64GX mencakup coreplex RISC-V dengan hart monitor sistem E64 51-bit dan 4 hart aplikasi U64 54-bit. Dalam terminologi RISC-V, hart adalah konteks eksekusi RISC-V yang berisi kumpulan register lengkap dan mengeksekusi kodenya secara independen. Anda dapat menganggapnya sebagai thread perangkat keras atau CPU tunggal. Sekelompok rusa dalam satu inti sering disebut kompleks. Topik ini menjelaskan langkah-langkah untuk menginisialisasi coreplex PIC64GX, termasuk sistem E51 yang memonitor jantung dan aplikasi U54.

Nyalakan coreplex PIC64GX.
Saat dihidupkan, semua hart di coreplex RISC-V dilepaskan dari pengaturan ulang oleh Pengontrol Keamanan.
Jalankan kode HSS dari memori flash eNVM on-chip.
Awalnya, setiap jantung mulai menjalankan kode HSS dari memori flash eNVM on-chip. Kode ini menyebabkan semua aplikasi U54 berputar, menunggu instruksi, dan membiarkan monitor E51 mulai menjalankan kode untuk menginisialisasi dan menjalankan sistem.

Dekompresi kode HSS dari eNVM ke memori L2-Scratch.
Tergantung pada konfigurasi waktu pembuatannya, HSS biasanya lebih besar daripada kapasitas memori flash eNVM itu sendiri sehingga hal pertama yang dilakukan kode HSS yang berjalan pada E51 adalah mendekompresi dirinya sendiri dari eNVM ke memori L2-Scratch, seperti yang ditunjukkan pada Gambar 1.2 dan Gambar 1.3.
Gambar 1.2. HSS Mendekompresi dari eNVM ke L2 Scratch
Gambar 1.3. Peta Memori HSS Selama Dekompresi
Lompat dari eNVM ke L2-Scratch ke dalam executable seperti yang ditunjukkan pada gambar berikut.
Gambar 1.4. HSS Melompat dari eNVM ke Kode Sekarang di L2Scratch Setelah Dekompresi
Eksekusi terdiri dari tiga komponen:
- Lapisan abstraksi perangkat keras (HAL), kode tingkat rendah, dan driver bare metal
- Garpu HSS lokal RISC-V OpenSBI (dimodifikasi sedikit dari hulu pada PIC64GX untuk AMP tujuan)
- Layanan runtime HSS (mesin negara berjalan dalam super loop)
Inisialisasi perangkat keras dan struktur data yang digunakan oleh OpenSBI.
Layanan HSS “Startup” bertanggung jawab atas inisialisasi ini.

Ambil gambar beban kerja aplikasi (payload.bin) dari penyimpanan eksternal. Hal ini ditunjukkan pada Gambar 1.5 dan Gambar 1.6
Penting: Untuk Curiosity Kit PIC64GX, ini akan berasal dari kartu SD.
Gambar 1.5. Mengambil Gambar Beban Kerja payload.bin dari Penyimpanan Eksternal
Gambar 1.6. Peta Memori HSS setelah Mengambil payload.bin
Salin berbagai bagian dari payload.bin ke tujuan waktu eksekusinya. Payload.bin adalah gambar yang diformat, yang menggabungkan berbagai gambar aplikasi untuk SMP atau AMP beban kerja. Ini mencakup kode, data, dan tabel deskriptor yang memungkinkan HSS menempatkan bagian kode dan data dengan tepat, di mana mereka diperlukan untuk menjalankan berbagai beban kerja aplikasi.
Gambar 1.7. payload.bin Disalin ke Alamat Tujuan

Instruksikan U54 yang relevan untuk melompat ke alamat awal eksekusinya. Informasi alamat awal ini terdapat di payload.bin.
Mulai aplikasi U54 hart dan detik apa puntage boot loader. Misalnyaample, U-Boot menampilkan Linux.

Menyalakan ulang

Terkait dengan konsep booting sistem adalah kebutuhan untuk melakukan reboot. Saat memikirkan beban kerja aplikasi PIC64GX, reboot perlu mempertimbangkan multiprosesor simetris (SMP) dan multiprosesor asimetris (AMP) skenario:

Dalam kasus sistem SMP, reboot dapat dengan aman melakukan reboot dingin seluruh sistem karena tidak ada beban kerja tambahan dalam konteks lain yang perlu dipertimbangkan.

Dalam kasus AMP sistem, beban kerja mungkin hanya diperbolehkan untuk melakukan boot ulang sendiri (dan tidak mengganggu konteks lainnya), atau mungkin diberi hak istimewa untuk dapat melakukan boot ulang sistem secara penuh.

Nyalakan ulang dan AMP
Untuk mengaktifkan SMP dan AMP skenario reboot, HSS mendukung konsep hak istimewa reboot hangat dan dingin, yang dapat ditetapkan ke suatu konteks. Konteks dengan hak istimewa reboot hangat hanya dapat melakukan boot ulang sendiri, dan konteks dengan hak reboot dingin dapat melakukan reboot sistem penuh. Misalnyaampmisalnya, pertimbangkan serangkaian skenario representatif berikut.

Beban kerja SMP konteks tunggal, yang diperbolehkan untuk meminta reboot sistem penuh
Dalam skenario ini, konteksnya diperbolehkan hak istimewa reboot dingin.
Dua konteks AMP beban kerja, di mana konteks A diperbolehkan untuk meminta reboot sistem secara penuh (memengaruhi semua konteks), dan Konteks B diperbolehkan untuk melakukan reboot sendiri saja
Dalam skenario ini, konteks A diperbolehkan hak istimewa reboot dingin, dan konteks B diperbolehkan hak istimewa reboot hangat.
Dua konteks AMP beban kerja, dengan konteks A dan B hanya diperbolehkan melakukan boot ulang sendiri (dan tidak memengaruhi konteks lainnya)
Dalam skenario ini, kedua konteks hanya diperbolehkan hak reboot hangat.
Dua konteks AMP beban kerja, dengan konteks A dan B diizinkan untuk meminta reboot sistem secara penuh
Dalam skenario ini, kedua konteks diperbolehkan hak reboot dingin.
Selain itu, HSS pada waktu build mungkin saja selalu mengizinkan hak istimewa reboot dingin, dan tidak pernah mengizinkan hak istimewa reboot dingin.

Opsi HSS Kconfig yang Relevan
Kconfig adalah sistem konfigurasi pembuatan perangkat lunak. Biasanya digunakan untuk memilih opsi waktu pembuatan dan untuk mengaktifkan atau menonaktifkan fitur. Ini berasal dari kernel Linux tetapi sekarang telah digunakan dalam proyek lain di luar kernel Linux, termasuk U-Boot, Zephyr, dan PIC64GX HSS.

HSS berisi dua opsi Kconfig yang mengontrol fungsionalitas reboot dari perspektif HSS:

CONFIG_ALLOW_COLD BOOT ULANG
Jika ini diaktifkan, secara global memungkinkan konteks untuk mengeluarkan panggilan reboot dingin. Jika dinonaktifkan, hanya reboot hangat yang diizinkan. Selain mengaktifkan opsi ini, izin untuk melakukan cold reboot harus diberikan ke konteks melalui YAML generator payload file atau opsi Kconfig berikut.
CONFIG_ALLOW_COLD REBOOT_ALWAYS
- Jika diaktifkan, fitur ini secara global memungkinkan semua konteks untuk mengeluarkan ECAA reboot dingin, terlepas dari hak flag payload.bin.
- Selain itu, payload.bin sendiri dapat berisi tanda per konteks, yang menunjukkan bahwa konteks tertentu berhak untuk melakukan cold reboot:
  - Untuk mengizinkan konteks pemanasan reboot konteks lain, kita dapat menambahkan opsi izinkan-reboot: hangat dalam deskripsi YAML file digunakan untuk membuat payload.bin
  - Untuk mengizinkan reboot dingin konteks seluruh sistem, kita dapat menambahkan opsi izinkan-reboot: dingin. Secara default, tanpa menentukan izinkan boot ulang, konteks hanya diperbolehkan melakukan boot ulang hangat itu sendiri Terlepas dari pengaturan tanda ini, jika CONFIG_ALLOW_COLDREBOOT tidak diaktifkan di HSS, HSS akan mengerjakan ulang semua permintaan boot ulang dingin menjadi boot ulang hangat (per konteks) .

Mulai ulang secara Detail
Bagian ini menjelaskan cara kerja reboot secara mendetail – dimulai dengan lapisan OpenSBI (lapisan mode M terendah) dan kemudian membahas bagaimana fungsionalitas lapisan OpenSBI ini dipicu dari aplikasi RTOS atau OS kaya seperti Linux.

Panggilan Reboot OpenSBI

Spesifikasi Supervisor Binary Interface (SBI) RISC-V menjelaskan lapisan abstraksi perangkat keras standar untuk inisialisasi platform dan layanan runtime firmware. Tujuan utama SBI adalah untuk memungkinkan portabilitas dan kompatibilitas di berbagai implementasi RISC-V.
OpenSBI (Open Source Supervisor Binary Interface) adalah proyek sumber terbuka yang menyediakan referensi implementasi spesifikasi SBI. OpenSBI juga menyediakan layanan runtime, termasuk penanganan interupsi, manajemen timer, dan konsol I/O, yang dapat dimanfaatkan oleh lapisan perangkat lunak tingkat yang lebih tinggi.
OpenSBI disertakan sebagai bagian dari HSS dan berjalan pada tingkat Mode Mesin. Ketika sistem operasi atau aplikasi menyebabkan jebakan, maka akan diteruskan ke OpenSBI untuk menanganinya. OpenSBI mengekspos fungsionalitas tipe panggilan sistem tertentu ke lapisan atas perangkat lunak melalui mekanisme jebakan tertentu yang disebut ecall.

System Reset (EID 0x53525354) menyediakan fungsi panggilan sistem komprehensif yang memungkinkan perangkat lunak lapisan atas meminta reboot atau shutdown tingkat sistem. Setelah panggilan ini dipanggil oleh U54, panggilan tersebut akan dijebak oleh perangkat lunak HSS yang berjalan dalam Mode Mesin pada U54 tersebut, dan permintaan reboot terkait dikirim ke E51 untuk melakukan boot ulang baik konteks atau keseluruhan sistem, tergantung pada hak dari UXNUMX. konteks.

Untuk informasi lebih lanjut, lihat Spesifikasi Antarmuka Biner Supervisor RISC-V khususnya Ekstensi Penyetelan Ulang Sistem (EID #0x53525354 “SRST”).

Linux di-boot ulang

Sebagai mantan tertentuampOleh karena itu, di Linux, perintah shutdown digunakan untuk menghentikan atau mem-boot ulang sistem. Perintah tersebut biasanya memiliki banyak alias, yaitu halt, power off, dan reboot. Alias ini menentukan apakah akan menghentikan mesin saat mati, mematikan mesin saat mati, atau menyalakan ulang mesin saat mati.

Perintah ruang pengguna ini mengeluarkan panggilan sistem reboot ke Linux, yang dijebak oleh kernel dan dihubungkan ke panggilan SBI.
Ada berbagai level reboot – REBOOT_WARM, REBOOT_COLD, REBOOT_HARD – ini dapat diteruskan sebagai argumen baris perintah ke kernel (misalnyaample, reboot=w[lengan] untuk REBOOT_WARM). Untuk informasi lebih lanjut tentang kode sumber kernel Linux, lihat Dokumentasi/admin-guide/kernel-paramters.txt.
Alternatifnya, jika /sys/kernel/reboot diaktifkan, penangan di bawahnya dapat dibaca untuk mendapatkan konfigurasi reboot sistem saat ini, dan ditulis untuk mengubahnya. Untuk informasi lebih lanjut tentang kode sumber kernel Linux, lihat Dokumentasi/ABI/testing/sysfs-kernel-reboot.

Anjing penjaga

Konsep lebih lanjut yang berkaitan dengan booting sistem dan reboot sistem adalah pemulihan sistem setelah pengaktifan pengatur waktu pengawas. Pengatur waktu pengawas banyak digunakan dalam sistem tertanam untuk memulihkan secara otomatis dari kesalahan perangkat keras sementara, dan untuk mencegah perangkat lunak yang salah atau jahat mengganggu pengoperasian sistem.
PIC64GX menyertakan dukungan pengawas perangkat keras untuk memantau setiap hart saat sistem sedang berjalan. Pengawas memastikan bahwa hart dapat dimulai ulang jika tidak merespons karena kesalahan perangkat lunak yang tidak dapat dipulihkan.
PIC64GX mencakup lima contoh blok perangkat keras pengatur waktu pengawas yang digunakan untuk mendeteksi penguncian sistem - satu untuk setiap hart. Untuk memfasilitasi Multi-Pemrosesan Asimetris campuran (AMP) beban kerja, HSS mendukung pemantauan dan reaksi terhadap pengaktifan pengawas.

Pengawas PIC64GX

HSS bertanggung jawab untuk mem-boot aplikasi saat power-up, dan untuk mem-boot ulang aplikasi tersebut (secara individual atau kolektif) kapan saja.tage, apakah itu diperlukan atau diinginkan. Sebagai konsekuensinya, reaksi terhadap peristiwa pengawas di PIC64GX ditangani oleh HSS.
Monitor 'pengawas virtual' diimplementasikan sebagai layanan mesin status HSS, dan tanggung jawabnya adalah memantau status masing-masing monitor perangkat keras pengawas individu U54. Ketika salah satu dari pengawas U54 ini tersandung, HSS mendeteksi hal ini dan akan mem-boot ulang U54 sebagaimana mestinya. Jika U54 adalah bagian dari konteks SMP, seluruh konteks dianggap untuk reboot, mengingat konteks tersebut memiliki hak istimewa reboot hangat. Seluruh sistem akan di-boot ulang jika konteksnya memiliki hak reboot dingin.

Opsi Kconfig yang Relevan

Dukungan Watchdog disertakan secara default dalam build HSS yang dirilis. Jika Anda ingin membuat HSS khusus, bagian ini akan menjelaskan mekanisme konfigurasi untuk memastikan bahwa dukungan Watchdog diaktifkan.

HSS dikonfigurasi menggunakan sistem konfigurasi Kconfig. .config tingkat atas file diperlukan untuk memilih layanan apa yang dikompilasi di dalam atau di luar build HSS.
Pertama, opsi CONFIG_SERVICE_WDOG tingkat atas harus diaktifkan (“Dukungan Pengawas Virtual” melalui make config).

Ini kemudian memperlihatkan sub-opsi berikut yang bergantung pada dukungan Watchdog:

CONFIG_SERVICE_WD OG_DEBUG
Mengaktifkan dukungan untuk pesan informasi/debug dari layanan pengawas virtual.
CONFIG_SERVICE_WD OG_DEBUG_TIMEOUT_SECS
Menentukan periodisitas (dalam detik) pesan debug Watchdog akan dikeluarkan oleh HSS.
CONFIG_SERVICE_WD OG_ENABLE_E51
Memungkinkan pengawas untuk monitor jantung E51 selain U54, melindungi pengoperasian HSS itu sendiri.

Ketika pengawas E51 diaktifkan, HSS akan menulis ke Watchdog secara berkala untuk menyegarkannya dan mencegahnya diaktifkan. Jika, karena alasan tertentu, jantung E51 terkunci atau mogok dan pengawas E51 diaktifkan, tindakan ini akan selalu mengatur ulang seluruh sistem.

Operasi Pengawas
Perangkat keras pengawas mengimplementasikan penghitung bawah. Jendela terlarang penyegaran dapat dibuat dengan mengonfigurasi Nilai Maksimum pengawas hingga Penyegaran Diizinkan (MVRP).

Ketika nilai pengatur waktu pengawas saat ini lebih besar dari nilai MVRP, penyegaran pengawas dilarang. Mencoba menyegarkan pengatur waktu pengawas di jendela terlarang akan menyebabkan interupsi batas waktu.

Menyegarkan pengawas antara nilai MVRP dan Nilai Pemicu (TRIG) akan berhasil menyegarkan penghitung dan mencegah pengawas menembak.
Ketika nilai pengatur waktu pengawas dihitung di bawah nilai TRIG, pengawas akan aktif.

Mesin Negara Pengawas

Mesin status pengawas sangat mudah – dimulai dengan mengonfigurasi pengawas untuk E51, jika diaktifkan, kemudian berpindah dari status diam ke pemantauan. Setiap kali berada di sekitar superloop, status pemantauan ini dipanggil, yang memeriksa status masing-masing pengawas U54.

Mesin status pengawas berinteraksi dengan mesin status boot untuk memulai ulang hart (dan hart lain yang ada dalam set bootnya), jika ia mendeteksi bahwa hart belum berhasil menyegarkan anjing pengawasnya tepat waktu.

Mode Penguncian

Biasanya (terutama dengan AMP aplikasi), diharapkan bahwa HSS akan tetap berada dalam mode M, pada U54, untuk memungkinkan reboot per konteks (yaitu reboot satu konteks saja, tanpa reboot chip penuh), dan untuk memungkinkan HSS memantau kesehatan ( ECC, Bit Status Kunci, Kesalahan Bus, kesalahan SBI, pelanggaran PMP, dll).

Untuk memberikan kemampuan reboot secara per-AMP berdasarkan konteks (tanpa mengharuskan seluruh sistem melakukan reboot), E51 biasanya memiliki akses memori istimewa ke seluruh ruang memori sistem. Namun, mungkin ada situasi di mana hal ini tidak diinginkan, dan pelanggan mungkin memilih untuk membatasi apa yang dilakukan firmware E51 HSS setelah sistem berhasil melakukan booting. Dalam hal ini, dimungkinkan untuk menempatkan HSS ke mode lockdown setelah U54 Application Harts di-boot.

Ini dapat diaktifkan menggunakan opsi HSS Kconfig CONFIG_SERVICE_LOCKDOWN.
Layanan lockdown dimaksudkan untuk memungkinkan pembatasan aktivitas HSS setelah mem-boot aplikasi U54 Harts.

Gambar 4.2. Mode Penguncian HSS

Setelah mode Lockdown dimulai, mode ini menghentikan semua mesin status layanan HSS lainnya agar tidak berjalan. Ini memanggil dua fungsi yang terikat lemah:

e51_pmp_lockdown(), dan
e51_lockdown()

Fungsi-fungsi ini dimaksudkan untuk diganti dengan kode khusus papan. Yang pertama adalah fungsi pemicu yang dapat dikonfigurasi untuk memungkinkan BSP menyesuaikan penguncian E51 dari muatan aplikasi pada saat ini. Implementasi default yang terikat lemah dari fungsi ini adalah kosong. Yang kedua adalah fungsionalitas yang dijalankan sejak saat itu. Implementasi default yang terikat lemah melayani pengawas pada saat ini di E51, dan akan melakukan boot ulang jika pengawas U54 diaktifkan. Untuk informasi lebih lanjut, lihat kode sumber HSS di services/lockdown/lockdown_service.c file.

Lampiran

Format payload.bin HSS

Bagian ini menjelaskan payload.bin file format dan gambar yang digunakan oleh HSS untuk boot PIC64GX SMP dan AMP aplikasi.
payload.bin adalah biner yang diformat (Gambar A.10) yang terdiri dari head, berbagai tabel deskriptor, dan berbagai potongan yang berisi bagian kode dan data dari setiap bagian beban kerja aplikasi. Sebuah potongan dapat dianggap sebagai blok memori bersebelahan berukuran sembarang.

Gambar A.10. Format payload.bin

Bagian header (ditunjukkan pada Gambar A.11) berisi nilai ajaib yang digunakan untuk mengidentifikasi payload.bin dan beberapa informasi housekeeping, bersama dengan detail gambar yang dimaksudkan untuk dijalankan pada masing-masing
Kode aplikasi U54. Ini menjelaskan cara mem-boot setiap hart U54, dan kumpulan gambar yang dapat di-boot secara keseluruhan. Dalam informasi tata graha, ia memiliki petunjuk ke berbagai tabel deskriptor untuk memungkinkan ukuran header bertambah.

Gambar A.11. payload.bin Tajuk

Kode dan data konstan yang diinisialisasi dianggap hanya-baca dan disimpan di bagian hanya-baca, yang ditunjuk oleh deskriptor header.
Variabel data yang diinisialisasi bukan nol adalah data baca-tulis tetapi nilai inisialisasinya disalin dari potongan hanya-baca saat permulaan. Ini juga disimpan di bagian read-only.

Bagian data payload read-only dijelaskan oleh tabel kode dan deskriptor potongan data. Setiap deskriptor potongan dalam tabel ini berisi 'pemilik hart' (hart utama dalam konteks yang ditargetkan
at), offset beban (offset dalam payload.bin), dan alamat eksekusi (alamat tujuan dalam memori PIC64GX), beserta ukuran dan checksum. Hal ini ditunjukkan pada Gambar A.12.

Gambar A.12. Deskriptor Potongan Hanya-Baca dan Data Potongan Payload

Selain potongan di atas, ada juga potongan memori yang sesuai dengan variabel data yang diinisialisasi ke nol. Ini tidak disimpan sebagai data di payload.bin, melainkan kumpulan khusus deskriptor potongan yang diinisialisasi nol, yang menentukan alamat dan panjang RAM yang akan disetel ke nol saat startup. Hal ini ditunjukkan pada Gambar A.13.

Gambar A.13. Potongan ZI

hss-payload-generator
Alat HSS Payload Generator membuat gambar payload yang diformat untuk zero-s Hart Software Servicetage bootloader pada PIC64GX, diberi konfigurasi file dan satu set ELF files dan/atau biner. Konfigurasi file digunakan untuk memetakan biner ELF atau gumpalan biner ke aplikasi individual hart (U54s).

Gambar B.14. Aliran generator muatan hss

Alat ini melakukan pemeriksaan kewarasan dasar pada struktur konfigurasi file itu sendiri dan pada gambar ELF. Gambar ELF harus berupa executable RISC-V.

Example Lari

Untuk menjalankan alat hss-payload-generator dengan sampkonfigurasi le file dan ELF files:
$ ./hss-payload-generator -c test/config.yaml keluaran.bin
Untuk mencetak diagnostik tentang gambar yang sudah ada, gunakan:
$ ./hss-payload-generator -d keluaran.bin

Untuk mengaktifkan otentikasi boot aman (melalui penandatanganan gambar), gunakan -p untuk menentukan lokasi Kunci Pribadi X.509 untuk Elliptic Curve P-384 (SECP384r1):
$ ./hss-payload-generator -c test/config.yaml payload.bin -p /path/to/private.pem

Untuk informasi lebih lanjut, lihat dokumentasi Otentikasi Boot Aman.

Konfigurasi File Example

Pertama, kita dapat secara opsional menetapkan nama untuk gambar kita, jika tidak, gambar akan dibuat secara dinamis:
set-nama: 'PIC64-HSS::TestImage'
Selanjutnya, kita akan menentukan alamat titik masuk untuk setiap hati, sebagai berikut:
hart-entry-points: {u54_1: ‘0x80200000’, u54_2: ‘0x80200000’, u54_3: ‘0xB0000000′, u54_4:’0x80200000’}

Gambar sumber ELF dapat menentukan titik masuk, tetapi kami ingin dapat mendukung titik masuk sekunder untuk hart jika diperlukan, misalnyaampMisalnya, jika beberapa hart dimaksudkan untuk mem-boot image yang sama, mereka mungkin memiliki titik masuk tersendiri. Untuk mendukung hal ini, kami menentukan alamat titik masuk sebenarnya dalam konfigurasi file diri.

Sekarang kita dapat mendefinisikan beberapa payload (sumber ELF files, atau gumpalan biner) yang akan ditempatkan di wilayah tertentu di memori. Bagian payload ditentukan dengan kata kunci payload, dan kemudian sejumlah deskriptor payload individual. Setiap muatan mempunyai nama (jalur ke muatannya file), seekor pemilik-hart, dan opsional 1 hingga 3 hart sekunder.

Selain itu, payload memiliki mode hak istimewa untuk memulai eksekusi. Mode hak istimewa yang valid adalah PRV_M, PRV_S, dan PRV_U, yang didefinisikan sebagai:

Mode mesin PRV_M
Mode Pengawas PRV_S
PRV_U Mode pengguna

Dalam contoh berikutampsaya:

test/zephyr.elf diasumsikan sebagai aplikasi Zephyr yang berjalan di U54_3, dan diharapkan dimulai dalam mode hak istimewa PRV_M.
test/u-boot-dtb.bin adalah aplikasi bootloader Das U-Boot, dan berjalan pada U54_1, U54_2 dan U54_4. Diharapkan untuk memulai dalam mode hak istimewa PRV_S.

Penting:
Output dari U-Boot menciptakan ELF file, tapi biasanya tidak menambahkan ekstensi .elf. Dalam hal ini, biner yang dibuat oleh CONFIG_OF_SEPARATE digunakan, yang menambahkan blob pohon perangkat ke biner U-Boot.

Disini mantanample Konfigurasi muatan file:

tes/zephyr.elf:
{exec-addr: '0xB0000000', pemilik-hart: u54_3, mode-priv: prv_m, lewati-opensbi: true}
tes/u-boot-dtb.bin:
{exec-addr: '0x80200000', pemilik-hart: u54_1, hart-sekunder: u54_2, hart-sekunder: u54_4, mode-priv: prv_s}

Penting:
Kasus hanya penting bagi file nama jalur, bukan kata kunci. Jadi, misalnya, u54_1 dianggap sama dengan U54_1, dan exec-addr dianggap sama dengan EXEC-ADDR. Jika ada ekstensi .elf atau .bin, ekstensi tersebut harus disertakan dalam konfigurasi file.

Untuk aplikasi bare metal yang tidak ingin khawatir dengan OpenSBI, opsi skip-opens, jika benar, akan menyebabkan payload pada jantung tersebut dipanggil menggunakan mret sederhana.
daripada panggilan OpenSBI sbi_init(). Ini berarti jantung akan mulai menjalankan kode bare metal terlepas dari pertimbangan OpenSBI HSM apa pun. Perhatikan bahwa ini juga berarti hati tidak dapat digunakan
panggilan untuk memanggil fungsionalitas OpenSBI. Opsi lewati-buka bersifat opsional dan defaultnya adalah false.

Untuk mengizinkan reboot konteks hangat dari konteks lain, kita dapat menambahkan opsi izinkan reboot: hangat. Untuk mengizinkan reboot dingin konteks seluruh sistem, kita dapat menambahkan opsi izinkan-reboot: dingin. Secara default, tanpa menentukan izinkan reboot, konteks hanya diperbolehkan untuk melakukan pemanasan reboot itu sendiri.
Dimungkinkan juga untuk mengaitkan data tambahan dengan setiap muatan, misalnyaample, Blob DeviceTree (DTB) file, dengan menentukan data tambahan fileberi nama sebagai berikut:
test/u-boot.bin: { exec-addr: '0x80200000', pemilik-hart: u54_1, hart sekunder: u54_2, hart sekunder: u54_3, hart sekunder: u54_4, mode priv: prv_s, data tambahan : tes/pic64gx.dtb }
Data tambahan ini akan dimasukkan ke dalam payload (ditempatkan tepat setelah data utama file dalam executable
spasi), dan alamatnya akan diteruskan ke OpenSBI di kolom next_arg1 (diteruskan dalam register $a1 ke image pada waktu boot).

Untuk mencegah HSS melakukan booting konteks secara otomatis (misalnya, jika kita ingin mendelegasikan kendali ini ke konteks menggunakan remoteProc), gunakan flag skip-autoboot:
test/zephyr.elf: {exec-addr: '0xB0000000', pemilik-hart: u54_3, mode priv: prv_m, lewati-opensbi: true, lewati-autoboot: true}
Terakhir, secara opsional kita dapat mengganti nama masing-masing muatan, menggunakan opsi nama muatan. Misalnyaampsaya:
test/u-boot.bin: { exec-addr: '0x80200000', pemilik-hart: u54_1, hart sekunder: u54_2, hart sekunder: u54_3, hart sekunder: u54_4, mode priv: prv_s, data tambahan : test/pic64gx.dtb, nama muatan: 'u-boot' }

Perhatikan bahwa pembuat Yocto dan Buildroot Linux akan membangun, mengkonfigurasi, dan menjalankan hss-payload-
generator sesuai kebutuhan untuk menghasilkan gambar aplikasi. Selain itu, pic64gx-curiosity-kit-amp target mesin di Yocto akan menghasilkan gambar aplikasi menggunakan alat hss-payload-generator yang menunjukkannya AMP, dengan Linux berjalan pada 3 hart dan Zephyr berjalan pada 1 hart.

Riwayat Revisi
Riwayat revisi menjelaskan perubahan yang diterapkan dalam dokumen. Perubahan dicantumkan berdasarkan revisi, dimulai dari publikasi terkini.

Revisi	Tanggal	Keterangan
A	07/2024	Revisi Awal

Informasi Mikrochip

Microchip Weblokasi
Microchip menyediakan dukungan online melalui websitus di www.microchip.com/. Ini websitus ini digunakan untuk membuat filedan informasi yang mudah diakses oleh pelanggan. Beberapa konten yang tersedia meliputi:

Dukungan Produk – Lembar data dan ralat, catatan aplikasi dan sampprogram, sumber daya desain, panduan pengguna dan dokumen dukungan perangkat keras, rilis perangkat lunak terbaru dan perangkat lunak yang diarsipkan

Dukungan Teknis Umum – Pertanyaan yang Sering Diajukan (FAQ), permintaan dukungan teknis, grup diskusi online, daftar anggota program mitra desain Microchip
Bisnis Microchip – Panduan pemilihan dan pemesanan produk, siaran pers Microchip terbaru, daftar seminar dan acara, daftar kantor penjualan Microchip, distributor, dan perwakilan pabrik

Layanan Pemberitahuan Perubahan Produk

Layanan pemberitahuan perubahan produk Microchip membantu pelanggan tetap mengikuti perkembangan produk Microchip. Pelanggan akan menerima pemberitahuan email setiap kali ada perubahan, pembaruan, revisi, atau kesalahan terkait dengan keluarga produk tertentu atau alat pengembangan yang diminati.

Untuk mendaftar, kunjungi www.microchip.com/pcn dan ikuti petunjuk pendaftaran.

Dukungan Pelanggan
Pengguna produk Microchip dapat menerima bantuan melalui beberapa saluran:

Distributor atau Perwakilan
Kantor Penjualan Lokal
Insinyur Solusi Tertanam (ESE)
Dukungan Teknis

Pelanggan harus menghubungi distributor, perwakilan, atau ESE mereka untuk mendapatkan dukungan. Kantor penjualan lokal juga tersedia untuk membantu pelanggan. Daftar kantor penjualan dan lokasi disertakan dalam dokumen ini.
Dukungan teknis tersedia melalui websitus di: www.microchip.com/dukungan.

Fitur Perlindungan Kode Perangkat Microchip
Perhatikan rincian berikut mengenai fitur perlindungan kode pada produk Microchip:

Produk mikrochip memenuhi spesifikasi yang tercantum dalam Lembar Data Mikrochip masing-masing.
Microchip yakin bahwa rangkaian produknya aman jika digunakan sesuai tujuan, sesuai spesifikasi pengoperasian, dan dalam kondisi normal.

Microchip menghargai dan secara agresif melindungi hak kekayaan intelektualnya. Upaya untuk melanggar fitur perlindungan kode produk Microchip sangat dilarang dan dapat melanggar Digital Millennium Copyright Act.
Baik Microchip maupun produsen semikonduktor lainnya tidak dapat menjamin keamanan kodenya. Perlindungan kode tidak berarti bahwa kami menjamin produk tersebut "tidak dapat dipecahkan". Perlindungan kode terus berkembang. Microchip berkomitmen untuk terus meningkatkan fitur perlindungan kode pada produk kami.

Pemberitahuan Hukum
Publikasi ini dan informasi di dalamnya hanya dapat digunakan dengan produk Microchip, termasuk untuk merancang, menguji, dan mengintegrasikan produk Microchip dengan aplikasi Anda. Penggunaan informasi ini dengan cara lain melanggar ketentuan ini. Informasi mengenai aplikasi perangkat disediakan hanya untuk kenyamanan Anda dan dapat digantikan oleh pembaruan. Anda bertanggung jawab untuk memastikan bahwa aplikasi Anda memenuhi spesifikasi Anda. Hubungi kantor penjualan Microchip lokal Anda untuk mendapatkan dukungan tambahan atau, dapatkan dukungan tambahan di www.microchip.com/en-us/support/design-help/client-support-services.

INFORMASI INI DISEDIAKAN OLEH MICROCHIP “SEBAGAIMANA ADANYA”. MICROCHIP TIDAK MEMBERIKAN PERNYATAAN ATAU JAMINAN APAPUN BAIK SECARA TERSURAT MAUPUN TERSIRAT, TERTULIS MAUPUN LISAN, BERDASARKAN HUKUM ATAU LAINNYA, YANG TERKAIT DENGAN INFORMASI TERMASUK NAMUN TIDAK TERBATAS PADA JAMINAN TERSIRAT TENTANG KETIDAKPELANGGARAN, KEMAMPUAN UNTUK DIPERDAGANGKAN, DAN KESESUAIAN UNTUK TUJUAN TERTENTU, ATAU JAMINAN YANG TERKAIT DENGAN KONDISI, KUALITAS, ATAU KINERJANYA.

DALAM KEADAAN APA PUN MICROCHIP TIDAK BERTANGGUNG JAWAB ATAS KERUGIAN, KERUSAKAN, BIAYA, ATAU BEBAN TIDAK LANGSUNG, KHUSUS, HUKUMAN, INSIDENTAL, ATAU KONSEKUENSIAL DALAM BENTUK APA PUN TERKAIT DENGAN INFORMASI ATAU PENGGUNAANNYA, APAPUN PENYEBABNYA, MESKIPUN MICROCHIP TELAH DIBERITAHU DARI KEMUNGKINAN ATAU KERUSAKAN DAPAT DIPERKIRAKAN. SEJAUH DIIZINKAN OLEH HUKUM, TOTAL TANGGUNG JAWAB MICROCHIP ATAS SEMUA KLAIM DENGAN CARA APA PUN TERKAIT DENGAN INFORMASI ATAU PENGGUNAANNYA TIDAK AKAN MELEBIHI JUMLAH BIAYA, JIKA ADA, YANG TELAH ANDA BAYARKAN LANGSUNG KE MICROCHIP UNTUK INFORMASI.

Penggunaan perangkat Microchip dalam aplikasi pendukung kehidupan dan/atau keselamatan sepenuhnya menjadi risiko pembeli, dan pembeli setuju untuk membela, mengganti kerugian, dan membebaskan Microchip dari segala kerusakan, klaim, tuntutan, atau biaya yang timbul dari penggunaan tersebut. Tidak ada lisensi yang diberikan, secara implisit atau sebaliknya, berdasarkan hak kekayaan intelektual Microchip apa pun kecuali dinyatakan lain.

Merek Dagang
Nama dan 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, PALING, PALING logo, MPLAB, OptoLyzer, PIC, picoPower, PICSTART, logo PIC32, PolarFire, Desainer Prochip, QTouch, SAM-BA, SenGenuity, SpyNIC, SST, Logo SST, SuperFlash, Symmetricom , SyncServer, Tachyon, TimeSource, tinyAVR, UNI/O, Vectron, dan XMEGA adalah merek dagang terdaftar dari Microchip Technology Incorporated di AS dan negara lain.

AgileSwitch, ClockWorks, Perusahaan Solusi Kontrol Tertanam, EtherSynch, Flashtec, Kontrol Kecepatan Hyper, Beban HyperLight, Libero, bangku motor, mTouch, Powermite 3, Precision Edge, ProASIC, ProASIC Plus, logo ProASIC Plus, Quiet-Wire, SmartFusion, SyncWorld , TimeCesium, TimeHub, TimePictra, TimeProvider, dan ZL adalah merek dagang terdaftar dari Microchip Technology Incorporated di AS

Penindasan Kunci Berdekatan, AKS, Analog-untuk-Zaman Digital, Kapasitor Apa Pun, AnyIn, AnyOut, Pengalihan Augmented, BlueSky, BodyCom, Clockstudio, CodeGuard, CryptoAuthentication, CryptoAutomotive, CryptoCompanion, CryptoController, dsPICDEM, dsPICDEM.net, Pencocokan Rata-Rata Dinamis , DAM, ECAN, Espresso T1S, EtherGREEN, EyeOpen, GridTime, IdealBridge,
IGaT, Pemrograman Serial Dalam Sirkuit, ICSP, INICnet, Paralel Cerdas, IntelliMOS, Konektivitas Antar-Chip, JitterBlocker, Knob-on-Display, MarginLink, maxCrypto, maxView, memBrain, Mindi, MiWi, MPASM, MPF, logo Bersertifikat MPLAB, MPLIB, MPLINK, mSiC, MultiTRAK, NetDetach, Pembuatan Kode Mahatahu, 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 sederhana, SimpliPHY, SmartBuffer, SmartHLS, SMART-IS, storClad, SQI, SuperSwitcher, SuperSwitcher II, Switchtec, SynchroPHY, Total Daya Tahan, Waktu Tepercaya, TSHARC, Turing, USBCheck, VariSense, VectorBlox, VeriPHY, ViewSpan, WiperLock, XpressConnect, dan ZENA adalah merek dagang Microchip Technology Incorporated di AS dan negara lain.

SQTP adalah merek layanan Microchip Technology Incorporated di Amerika Serikat
Logo Adaptec, Frequency on Demand, Silicon Storage Technology, dan Symmcom adalah merek dagang terdaftar dari Microchip Technology Inc. di negara lain.
GestIC adalah merek dagang terdaftar dari Microchip Technology Germany II GmbH & Co. KG, anak perusahaan Microchip Technology Inc., di negara lain.

Bahasa Indonesia: 978-1-6683-4890-1

Sistem Manajemen Mutu
Untuk informasi mengenai Sistem Manajemen Mutu Microchip, silakan kunjungi www.microchip.com/kualitas.

Penjualan dan Layanan di Seluruh Dunia

AMERIKA

ASIA/PASIFIK

EROPA

Perusahaan Kantor

2355 Barat Chandler Blvd. Chandler, AZ 85224-6199

Telp: Telepon: 480-792-7200

Fax: Telepon: 480-792-7277

Dukungan Teknis: www.microchip.com/dukungan

Web Alamat: www.microchip.com

Kota Atlanta

Duluth, Georgia

Telp: Telepon: 678-957-9614

Fax: Telepon: 678-957-1455

Austin, Texas

Telp: Telepon: 512-257-3370

Kota Boston

Westborough, MA Telp: Telepon: 774-760-0087

Fax: Telepon: 774-760-0088

Bahasa Indonesia: Chicago

Itasca, IL

Telp: Telepon: 630-285-0071

Fax: Telepon: 630-285-0075

Kota Dallas

Addison, TX

Telp: Telepon: 972-818-7423

Fax: Telepon: 972-818-2924

Kota Detroit

Baru, Michigan

Telp: Telepon: 248-848-4000

Kota Houston, TX

Telp: Telepon: 281-894-5983

Kota Indianapolis

Noblesville, DI Telp: Telepon: 317-773-8323

Fax: Telepon: 317-773-5453

Telp: Telepon: 317-536-2380

Kota Los Angeles

Misi Viejo, CA Telp: Telepon: 949-462-9523

Fax: Telepon: 949-462-9608

Telp: Telepon: 951-273-7800

Kota Raleigh, NC

Telp: Telepon: 919-844-7510

New York, Amerika Serikat

Telp: Telepon: 631-435-6000

San Jose, CA

Telp: Telepon: 408-735-9110

Telp: Telepon: 408-436-4270

Kanada – Kota Toronto

Telp: Telepon: 905-695-1980

Fax: Telepon: 905-695-2078

Australia-Sydney

Telp: 61-2-9868-6733

Cina – Beijing

Telp: 86-10-8569-7000

Cina – Chengdu

Telp: 86-28-8665-5511

Tiongkok – Chongqing

Telp: 86-23-8980-9588

Cina – Dongguan

Telp: 86-769-8702-9880

Cina – Guangzhou

Telp: 86-20-8755-8029

Cina – Hangzhou

Telp: 86-571-8792-8115

Cina – Hong Bahasa Inggris Kong Daerah Administratif Khusus

Telp: 852-2943-5100

Cina – Nanjing

Telp: 86-25-8473-2460

Cina – Qingdao

Telp: 86-532-8502-7355

Cina – Shanghai

Telp: 86-21-3326-8000

Cina – Shenyang

Telp: 86-24-2334-2829

Cina – Shenzhen

Telp: 86-755-8864-2200

Cina – Suzhou

Telp: 86-186-6233-1526

Cina – Wuhan

Telp: 86-27-5980-5300

Cina – Xian

Telp: 86-29-8833-7252

Cina – Xiamen

Telp: 86-592-2388138

Cina – Zhuhai

Telp: 86-756-3210040

India – Bengaluru

Telp: 91-80-3090-4444

India-New Delhi

Telp: 91-11-4160-8631

India – Kota Pune

Telp: 91-20-4121-0141

Jepang – Osaka

Telp: 81-6-6152-7160

Jepang – Tokyo

Telp: 81-3-6880- 3770

Korea – Daegu

Telp: 82-53-744-4301

Korea – Seoul

Telp: 82-2-554-7200

Malaysia – Kuala Lumpur

Telp: 60-3-7651-7906

Malaysia – Pulau Pinang

Telp: 60-4-227-8870

Filipina – Kota Manila

Telp: 63-2-634-9065

Singapura

Telp: 65-6334-8870

Indonesia – Hsin Chu

Telp: 886-3-577-8366

Taiwan – Kaohsiung

Telp: 886-7-213-7830

Taiwan-Taipei

Telp: 886-2-2508-8600

Thailand – Bangkok

Telp: 66-2-694-1351

Vietnam-Ho Chi Minh

Telp: 84-28-5448-2100

Austria – Wels

Telp: 43-7242-2244-39

Telp.: 43-7242-2244-393

Denmark – Kopenhagen

Telp: 45-4485-5910

Telp.: 45-4485-2829

Finlandia – Bahasa Espoo

Telp: 358-9-4520-820

Perancis – Paris

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

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

Jerman – Barching

Telp: 49-8931-9700

Jerman – Haan

Telp: 49-2129-3766400

Jerman – Kota Heilbronn

Telp: 49-7131-72400

Jerman – Kota Karlsruhe

Telp: 49-721-625370

Jerman – Kota Munchen

Tel: 49-89-627-144-0

Fax: 49-89-627-144-44

Jerman – Rosenheim

Telp: 49-8031-354-560

Israel – Hod Hasharon

Telp: 972-9-775-5100

Italia – Milan

Telp: 39-0331-742611

Telp.: 39-0331-466781

Italia – Padova

Telp: 39-049-7625286

Belanda – Drunen

Telp: 31-416-690399

Telp.: 31-416-690340

Norwegia – Kota Trondheim

Telp: 47-72884388

Polandia – Warsaw

Telp: 48-22-3325737

Rumania – 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

Telp: 46-8-5090-4654

Inggris – Wokingham

Telp: 44-118-921-5800

Telp.: 44-118-921-5820

Dokumen / Sumber Daya

MICROCHIP PIC64GX 64-Bit RISC-V Mikroprosesor Quad-Core [Bahasa Indonesia:] Panduan Pengguna
PIC64GX, PIC64GX 64-Bit RISC-V Mikroprosesor Quad-Core, Mikroprosesor Quad-Core RISC-V 64-Bit, Mikroprosesor Quad-Core RISC-V, Mikroprosesor Quad-Core, Mikroprosesor

Referensi

Panduan Pengguna

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

Informasi Produk

Petunjuk Penggunaan Produk