MICROCHIP PIC64GX 64-Bit RISC-V Quad-Core Microprocessor ຄູ່ມືຜູ້ໃຊ້

ຂະບວນການ Boot
1. ອົງປະກອບຊອບແວມີສ່ວນຮ່ວມໃນການບູດ
  ຂະບວນການເລີ່ມຕົ້ນລະບົບປະກອບດ້ວຍອົງປະກອບຊອບແວດັ່ງຕໍ່ໄປນີ້:
  - Hart Software Services (HSS): A zero-stage boot loader, ຕິດຕາມກວດກາລະບົບ, ແລະຜູ້ໃຫ້ບໍລິການ runtime ສໍາລັບຄໍາຮ້ອງສະຫມັກ.
2. Boot Flow
  ລຳດັບຂອງລະບົບການເລີ່ມຕົ້ນລະບົບແມ່ນດັ່ງຕໍ່ໄປນີ້:
  1. ການເລີ່ມຕົ້ນການບໍລິການຊອບແວຮາດ (HSS)
  2. ການປະຕິບັດ Bootloader
  3. ການເລີ່ມຕົ້ນຄໍາຮ້ອງສະຫມັກ
ເຝົ້າລະວັງ
1. PIC64GX Watchdog
  PIC64GX ມີຫນ້າທີ່ເຝົ້າລະວັງເພື່ອຕິດຕາມການເຮັດວຽກຂອງລະບົບແລະກະຕຸ້ນການກະທໍາໃນກໍລະນີທີ່ລະບົບລົ້ມເຫລວ.
ແບບ Lockdown
ໂຫມດການປິດລ້ອມໄດ້ຖືກອອກແບບສໍາລັບລູກຄ້າທີ່ຕ້ອງການການຄວບຄຸມຢ່າງສົມບູນກ່ຽວກັບການປະຕິບັດລະບົບຫຼັງຈາກການເປີດເຄື່ອງ. ມັນຈໍາກັດການທໍາງານຂອງຈໍພາບລະບົບ E51.

FAQ

Q: ຈຸດປະສົງຂອງການບໍລິການຊອບແວ Hart (HSS) ແມ່ນຫຍັງ?
A: HSS ເຮັດຫນ້າທີ່ເປັນສູນtage boot loader, ຕິດຕາມກວດກາລະບົບ, ແລະຜູ້ໃຫ້ບໍລິການ runtime ສໍາລັບຄໍາຮ້ອງສະຫມັກໃນລະຫວ່າງການຂະບວນການ boot.
Q: ຫນ້າທີ່ເຝົ້າລະວັງ PIC64GX ເຮັດວຽກແນວໃດ?
A: PIC64GX watchdog ຕິດຕາມກວດກາການເຮັດວຽກຂອງລະບົບແລະສາມາດດໍາເນີນການທີ່ກໍານົດໄວ້ລ່ວງຫນ້າໃນກໍລະນີທີ່ລະບົບລົ້ມເຫລວເພື່ອຮັບປະກັນຄວາມຫນ້າເຊື່ອຖືຂອງລະບົບ.

ແນະນຳ

ປື້ມປົກຂາວນີ້ອະທິບາຍວິທີການທີ່ Microchip PIC64GX boots ການເຮັດວຽກຂອງແອັບພລິເຄຊັນແລະອະທິບາຍຂະບວນການບູດລະບົບ, ເຊິ່ງເຮັດວຽກດຽວກັນກັບ SMP ແລະ AMP ວຽກງານ. ນອກຈາກນັ້ນ, ມັນກວມເອົາວິທີການ reboot ເຮັດວຽກສໍາລັບ SMP ແລະ AMP ການໂຫຼດວຽກ, ການເຝົ້າລະວັງຢູ່ໃນ PIC64GX, ແລະຮູບແບບການປິດລ້ອມພິເສດສໍາລັບລະບົບທີ່ລູກຄ້າຕ້ອງການການຄວບຄຸມຢ່າງສົມບູນເພື່ອຈໍາກັດການດໍາເນີນການຂອງລະບົບ E51 ຕິດຕາມກວດກາຫຼັງຈາກການບູດລະບົບ.

ຂະບວນການ Boot

ໃຫ້ພວກເຮົາເບິ່ງອົງປະກອບຊອບແວຕ່າງໆທີ່ກ່ຽວຂ້ອງກັບການບູດລະບົບ, ຕິດຕາມດ້ວຍລາຍລະອຽດເພີ່ມເຕີມໃນລໍາດັບຂອງລະບົບການບູດລະບົບຂອງມັນເອງ.

ອົງປະກອບຊອບແວມີສ່ວນຮ່ວມໃນການບູດ
ອົງປະກອບຕໍ່ໄປນີ້ແມ່ນມີສ່ວນຮ່ວມໃນຂະບວນການເລີ່ມຕົ້ນລະບົບ:

ຮູບທີ 1.1. ອົງປະກອບການບູດ-up

ບໍລິການຊອບແວຮາດ (HSS)
ການບໍລິການຊອບແວຮາດ (HSS) ແມ່ນສູນtage boot loader, ຈໍລະບົບ, ແລະຜູ້ໃຫ້ບໍລິການ runtime ສໍາລັບຄໍາຮ້ອງສະຫມັກ. HSS ສະຫນັບສະຫນູນການຕິດຕັ້ງລະບົບໃນຕອນຕົ້ນ, ການຝຶກອົບຮົມ DDR, ແລະການເລີ່ມຕົ້ນ / ການຕັ້ງຄ່າຮາດແວ. ມັນສ່ວນຫຼາຍແມ່ນແລ່ນຢູ່ໃນ E51s, ໂດຍມີຈໍານວນຂະຫນາດນ້ອຍຂອງການເຮັດວຽກໃນລະດັບເຄື່ອງຈັກໃນການເຮັດວຽກໃນແຕ່ລະ U54s. ມັນບູດໜຶ່ງ ຫຼືຫຼາຍບໍລິບົດໂດຍການໂຫຼດແອັບພລິເຄຊັນ “payload” ຈາກສື່ boot, ແລະສະໜອງ Platform Runtime Services/Supervisor Execution Environment (SEE) ສໍາລັບ kernels ລະບົບປະຕິບັດການ. ມັນສະຫນັບສະຫນູນ boot ທີ່ປອດໄພແລະເປັນອົງປະກອບທີ່ສໍາຄັນໃນການຮັບປະກັນການແບ່ງປັນ / ການແຍກຮາດແວສໍາລັບການ AMP ສະພາບການ.

Das U-Boot (U-Boot)
Das U-Boot (U-Boot) ເປັນ open-source universal scriptable boot loader. ມັນສະຫນັບສະຫນູນ CLI ງ່າຍໆທີ່ສາມາດດຶງຮູບພາບ boot ຈາກຫຼາຍໆແຫຼ່ງ (ລວມທັງ SD Card ແລະເຄືອຂ່າຍ). U-Boot ໂຫຼດ Linux. ມັນສາມາດສະຫນອງສະພາບແວດລ້ອມ UEFI ຖ້າຈໍາເປັນ. ມັນໂດຍທົ່ວໄປແລ້ວແມ່ນສໍາເລັດແລະອອກຈາກວິທີການເມື່ອ Linux ໄດ້ booted - ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ມັນບໍ່ໄດ້ຢູ່ພາຍໃນ post-boot.
Linux Kernel
kernel Linux ແມ່ນ kernel ລະບົບປະຕິບັດການທີ່ນິຍົມທີ່ສຸດໃນໂລກ. ສົມທົບກັບພື້ນທີ່ຜູ້ໃຊ້ຂອງແອັບພລິເຄຊັນ, ມັນປະກອບເປັນສິ່ງທີ່ເອີ້ນວ່າລະບົບປະຕິບັດການ Linux. ລະບົບປະຕິບັດການ Linux ສະໜອງ POSIX APIs ທີ່ອຸດົມສົມບູນ ແລະສະພາບແວດລ້ອມຂອງຜູ້ພັດທະນາ, ຕົວຢ່າງເຊັ່ນample, ພາສາ ແລະເຄື່ອງມືເຊັ່ນ Python, Perl, Tcl, Rust, C/C++, ແລະ Tcl; ຫ້ອງສະໝຸດເຊັ່ນ OpenSSL, OpenCV, OpenMP, OPC/UA, ແລະ OpenAMP (RPmsg ແລະ RemoteProc).
Yocto ແລະ Buildroot ແມ່ນຜູ້ສ້າງລະບົບ Linux, ນັ້ນແມ່ນ, ພວກເຂົາສາມາດຖືກນໍາໃຊ້ເພື່ອສ້າງລະບົບ Linux ທີ່ກໍາຫນົດເອງ. Yocto ສົ່ງອອກການແຈກຢາຍ Linux ກັບອຸດົມສົມບູນ
ຊຸດຂອງແອັບພລິເຄຊັນ, ເຄື່ອງມື, ແລະຫ້ອງສະຫມຸດ, ແລະການຈັດການຊຸດທາງເລືອກ. Buildroot ຜະລິດຮາກທີ່ນ້ອຍກວ່າ fileລະບົບແລະສາມາດຕັ້ງເປົ້າໃສ່ລະບົບທີ່ບໍ່ຮຽກຮ້ອງໃຫ້ມີການເກັບຮັກສາຄົງທີ່ແຕ່ເຮັດວຽກທັງຫມົດຈາກ RAM (ການນໍາໃຊ້ການສະຫນັບສະຫນູນເບື້ອງຕົ້ນຂອງ Linux, ສໍາລັບການຍົກຕົວຢ່າງ.ampເລ).

Zephyr
Zephyr ເປັນລະບົບປະຕິບັດງານເວລາຈິງ (RTOS). ມັນສະຫນອງກອບວຽກຄ່າໃຊ້ຈ່າຍຕ່ໍາໃນເວລາທີ່ແທ້ຈິງ, ມີຊ່ອງທາງການສື່ສານ RPMsg-lite ກັບ Linux. ມັນປະກອບມີ kernel, ຫ້ອງສະຫມຸດ, ໄດເວີອຸປະກອນ, stacks ໂປໂຕຄອນ, fileລະບົບ, ກົນໄກການອັບເດດເຟີມແວ, ແລະອື່ນໆ, ແລະເປັນສິ່ງທີ່ດີສໍາລັບລູກຄ້າທີ່ຕ້ອງການປະສົບການທີ່ຄ້າຍຄືໂລຫະເປົ່າຫຼາຍໃນ PIC64GX.

Boot Flow
PIC64GX ປະກອບມີ RISC-V coreplex ທີ່ມີ 64-bit E51 system monitor hart ແລະ 4 64-bit U54 application harts. ໃນ RISC-V terminology, a hart ແມ່ນບໍລິບົດການປະຕິບັດ RISC-V ທີ່ປະກອບດ້ວຍຊຸດເຕັມຂອງທະບຽນແລະທີ່ປະຕິບັດລະຫັດຂອງຕົນເປັນເອກະລາດ. ທ່ານສາມາດຄິດວ່າມັນເປັນຫົວຂໍ້ຮາດແວຫຼື CPU ດຽວ. ກຸ່ມຂອງ harts ພາຍໃນແກນດຽວແມ່ນມັກຈະເອີ້ນວ່າສະລັບສັບຊ້ອນ. ຫົວຂໍ້ນີ້ອະທິບາຍຂັ້ນຕອນໃນການເລີ່ມຕົ້ນ PIC64GX coreplex, ລວມທັງລະບົບ E51 monitors ຫົວໃຈແລະ U54 application harts.

ເປີດໃຊ້ PIC64GX coreplex.
ເມື່ອເປີດເຄື່ອງ, ຮາດທັງໝົດໃນ RISC-V coreplex ຖືກປ່ອຍອອກຈາກການຣີເຊັດໂດຍຕົວຄວບຄຸມຄວາມປອດໄພ.
ແລ່ນລະຫັດ HSS ຈາກຫນ່ວຍຄວາມຈໍາ flash eNVM ເທິງຊິບ.
ໃນເບື້ອງຕົ້ນ, ແຕ່ລະຫົວໃຈເລີ່ມແລ່ນລະຫັດ HSS ຈາກຫນ່ວຍຄວາມຈໍາ flash eNVM ເທິງຊິບ. ລະຫັດນີ້ເຮັດໃຫ້ harts ຄໍາຮ້ອງສະຫມັກ U54 ທັງຫມົດທີ່ຈະ spin, ລໍຖ້າສໍາລັບຄໍາແນະນໍາ, ແລະອະນຸຍາດໃຫ້ E51 monitor hart ເລີ່ມແລ່ນລະຫັດເພື່ອເລີ່ມຕົ້ນການແລະນໍາເອົາເຖິງລະບົບ.

ບີບອັດລະຫັດ HSS ຈາກ eNVM ໄປເປັນ L2-Scratch memory.
ອີງຕາມການກໍານົດເວລາການກໍ່ສ້າງຂອງມັນ, HSS ມັກຈະມີຂະຫນາດໃຫຍ່ກວ່າຄວາມອາດສາມາດຂອງຫນ່ວຍຄວາມຈໍາ flash eNVM ຕົວມັນເອງແລະດັ່ງນັ້ນສິ່ງທໍາອິດທີ່ລະຫັດ HSS ແລ່ນຢູ່ໃນ E51 ເຮັດແມ່ນ decompress ຕົວຂອງມັນເອງຈາກ eNVM ກັບ L2-Scratch memory, ດັ່ງທີ່ສະແດງຢູ່ໃນຮູບ. 1.2 ແລະ ຮູບທີ 1.3.
ຮູບທີ 1.2. HSS Decompresses ຈາກ eNVM ຫາ L2 Scratch
ຮູບທີ 1.3. HSS Memory Map ໃນລະຫວ່າງການບີບອັດ
ໂດດຈາກ eNVM ໄປ L2-Scratch ເຂົ້າໄປໃນການປະຕິບັດໄດ້ດັ່ງທີ່ສະແດງຢູ່ໃນຮູບຕໍ່ໄປນີ້.
ຮູບທີ 1.4. HSS ໂດດຈາກ eNVM ເຂົ້າໄປໃນລະຫັດໃນປັດຈຸບັນໃນ L2Scratch ປະຕິບັດຕາມການບີບອັດ
ການປະຕິບັດປະກອບດ້ວຍສາມອົງປະກອບ:
- ຊັ້ນ abstraction ຮາດແວ (HAL), ລະຫັດລະດັບຕ່ໍາ, ແລະໄດເວີໂລຫະເປົ່າ
- ສ້ອມ HSS ທ້ອງຖິ່ນຂອງ RISC-V OpenSBI (ດັດແກ້ເລັກນ້ອຍຈາກຕົ້ນນ້ໍາໃນ PIC64GX ສໍາລັບ AMP ຈຸດປະສົງ)
- ບໍລິການເວລາແລ່ນ HSS (ເຄື່ອງຂອງລັດແລ່ນຢູ່ໃນວົງ super)
ເລີ່ມຕົ້ນໂຄງສ້າງຮາດແວ ແລະຂໍ້ມູນທີ່ໃຊ້ໂດຍ OpenSBI.
ບໍລິການ HSS “Startup” ແມ່ນຮັບຜິດຊອບສໍາລັບການເລີ່ມຕົ້ນນີ້.

ດຶງເອົາຮູບພາບການເຮັດວຽກຂອງແອັບພລິເຄຊັນ (payload.bin) ຈາກບ່ອນເກັບຂໍ້ມູນພາຍນອກ. ນີ້ແມ່ນສະແດງຢູ່ໃນຮູບ 1.5 ແລະຮູບ 1.6
ສິ່ງສໍາຄັນ: ໃນກໍລະນີຂອງຊຸດ Curiosity PIC64GX, ມັນຈະມາຈາກ SD ກາດ.
ຮູບທີ 1.5. ກຳລັງດຶງຮູບ payload.bin Workload ຈາກບ່ອນເກັບຂໍ້ມູນພາຍນອກ
ຮູບທີ 1.6. HSS Memory Map ຫຼັງຈາກດຶງ payload.bin
ຄັດລອກພາກສ່ວນຕ່າງໆຈາກ payload.bin ໄປຫາຈຸດຫມາຍປາຍທາງເວລາປະຕິບັດຂອງພວກເຂົາ. payload.bin ແມ່ນຮູບພາບທີ່ມີຮູບແບບ, ເຊິ່ງລວມຮູບພາບຄໍາຮ້ອງສະຫມັກຕ່າງໆສໍາລັບ SMP ຫຼື AMP ວຽກງານ. ມັນປະກອບມີລະຫັດ, ຂໍ້ມູນ, ແລະຕາຕະລາງ descriptor ເຊິ່ງເຮັດໃຫ້ HSS ສາມາດຈັດວາງລະຫັດແລະຂໍ້ມູນໄດ້ຢ່າງເຫມາະສົມ, ບ່ອນທີ່ພວກເຂົາຕ້ອງການເພື່ອດໍາເນີນການເຮັດວຽກຂອງແອັບພລິເຄຊັນຕ່າງໆ.
ຮູບທີ 1.7. payload.bin ຖືກຄັດລອກໄປທີ່ທີ່ຢູ່ປາຍທາງ

ແນະນໍາ U54s ທີ່ກ່ຽວຂ້ອງເພື່ອເຕັ້ນໄປຫາທີ່ຢູ່ເລີ່ມຕົ້ນການປະຕິບັດຂອງພວກເຂົາ. ຂໍ້ມູນທີ່ຢູ່ເລີ່ມຕົ້ນນີ້ແມ່ນບັນຈຸຢູ່ໃນ payload.bin.
ເລີ່ມ U54 Application harts ແລະທຸກວິນາທີtage boot loaders. ຕົວຢ່າງample, U-Boot ເອົາ Linux ຂຶ້ນ.

ປິດເປີດໃໝ່

ກ່ຽວຂ້ອງກັບແນວຄວາມຄິດຂອງການບູດລະບົບແມ່ນຄວາມຕ້ອງການ reboot. ເມື່ອຄິດກ່ຽວກັບການໂຫຼດຂອງແອັບພລິເຄຊັນ PIC64GX, rebooting ຈໍາເປັນຕ້ອງພິຈາລະນາທັງການປະມວນຜົນຫຼາຍແບບ symmetric (SMP) ແລະ asymmetric multiprocessing (AMP) ສະຖານະການ:

ໃນກໍລະນີຂອງລະບົບ SMP, reboot ສາມາດເຢັນໄດ້ຢ່າງປອດໄພ reboot ລະບົບທັງຫມົດເນື່ອງຈາກວ່າບໍ່ມີວຽກງານເພີ່ມເຕີມໃນສະພາບການອື່ນທີ່ຈະພິຈາລະນາ.

ໃນກໍລະນີຂອງ AMP ລະບົບ, ການເຮັດວຽກອາດຈະໄດ້ຮັບອະນຸຍາດໃຫ້ reboot ຕົວມັນເອງເທົ່ານັ້ນ (ແລະບໍ່ແຊກແຊງກັບສະພາບການອື່ນໆ), ຫຼືມັນອາດຈະໄດ້ຮັບສິດທິພິເສດທີ່ຈະສາມາດ reboot ລະບົບຢ່າງເຕັມທີ່.

Reboot ແລະ AMP
ເພື່ອເປີດໃຊ້ SMP ແລະ AMP ສະຖານະການ reboot, HSS ສະຫນັບສະຫນູນແນວຄວາມຄິດຂອງສິດທິໃນການ reboot ອົບອຸ່ນແລະເຢັນ, ເຊິ່ງສາມາດກໍາຫນົດໃຫ້ກັບສະພາບການ. ບໍລິບົດທີ່ມີສິດທິພິເສດ reboot ອົບອຸ່ນພຽງແຕ່ສາມາດ reboot ຕົວມັນເອງ, ແລະສະພາບການທີ່ມີສິດທິ reboot ເຢັນສາມາດດໍາເນີນການ reboot ລະບົບຢ່າງເຕັມທີ່. ຕົວຢ່າງampດັ່ງນັ້ນ, ພິຈາລະນາຊຸດຂອງສະຖານະການຕົວແທນຕໍ່ໄປນີ້.

ບໍລິບົດດຽວ SMP workload, ເຊິ່ງອະນຸຍາດໃຫ້ຮ້ອງຂໍການ reboot ລະບົບເຕັມ
ໃນສະຖານະການນີ້, ສະພາບການແມ່ນອະນຸຍາດໃຫ້ສິດທິການ reboot ເຢັນ.
ສອງສະພາບການ AMP workload, ບ່ອນທີ່ບໍລິບົດ A ໄດ້ຮັບອະນຸຍາດໃຫ້ຮ້ອງຂໍການ reboot ລະບົບເຕັມ (ຜົນກະທົບຕໍ່ສະພາບການທັງຫມົດ), ແລະ Context B ແມ່ນອະນຸຍາດໃຫ້ reboot ຕົວຂອງມັນເອງເທົ່ານັ້ນ.
ໃນສະຖານະການນີ້, ບໍລິບົດ A ແມ່ນອະນຸຍາດໃຫ້ມີສິດທິພິເສດ reboot ເຢັນ, ແລະສະພາບການ B ແມ່ນອະນຸຍາດໃຫ້ສິດທິ reboot ອົບອຸ່ນ.
ສອງສະພາບການ AMP workload, ບ່ອນທີ່ບໍລິບົດ A ແລະ B ໄດ້ຖືກອະນຸຍາດໃຫ້ reboot ດ້ວຍຕົນເອງເທົ່ານັ້ນ (ແລະບໍ່ມີຜົນກະທົບຕໍ່ສະພາບການອື່ນໆ)
ໃນສະຖານະການນີ້, ທັງສອງສະພາບການໄດ້ຮັບອະນຸຍາດໃຫ້ພຽງແຕ່ສິດທິພິເສດ reboot ອົບອຸ່ນ.
ສອງສະພາບການ AMP workload, ບ່ອນທີ່ບໍລິບົດ A ແລະ B ທັງສອງໄດ້ຮັບອະນຸຍາດໃຫ້ຮ້ອງຂໍການປິດລະບົບເຕັມ
ໃນສະຖານະການນີ້, ທັງສອງສະພາບການໄດ້ຮັບອະນຸຍາດໃຫ້ສິດທິການ reboot ເຢັນ.
ຍິ່ງໄປກວ່ານັ້ນ, ມັນເປັນໄປໄດ້ສໍາລັບ HSS ໃນເວລາສ້າງເພື່ອໃຫ້ສິດທິພິເສດ reboot ເຢັນສະເຫມີ, ແລະບໍ່ໃຫ້ສິດທິພິເສດ reboot ເຢັນ.

ຕົວເລືອກ HSS Kconfig ທີ່ກ່ຽວຂ້ອງ
Kconfig ເປັນລະບົບການສ້າງຊອບແວ. ມັນຖືກນໍາໃຊ້ທົ່ວໄປເພື່ອເລືອກທາງເລືອກໃນການກໍ່ສ້າງແລະເປີດຫຼືປິດຄຸນສົມບັດ. ມັນມີຕົ້ນກໍາເນີດມາຈາກແກ່ນ Linux ແຕ່ໃນປັດຈຸບັນໄດ້ພົບເຫັນການນໍາໃຊ້ໃນໂຄງການອື່ນໆນອກເຫນືອຈາກ Linux kernel, ລວມທັງ U-Boot, Zephyr, ແລະ PIC64GX HSS.

HSS ມີສອງທາງເລືອກ Kconfig ທີ່ຄວບຄຸມການເຮັດວຽກຂອງ reboot ຈາກມຸມເບິ່ງ HSS:

CONFIG_ALLOW_COLD ຣີບູດ
ຖ້າອັນນີ້ຖືກເປີດໃຊ້, ມັນທົ່ວໂລກອະນຸຍາດໃຫ້ບໍລິບົດອອກ ecall reboot ເຢັນ. ຖ້າປິດໃຊ້ງານ, ພຽງແຕ່ reboots ອົບອຸ່ນຈະໄດ້ຮັບການອະນຸຍາດ. ນອກເຫນືອຈາກການເປີດໃຊ້ທາງເລືອກນີ້, ການອະນຸຍາດໃຫ້ອອກການ reboot ເຢັນຕ້ອງໄດ້ຮັບການອະນຸຍາດໃຫ້ກັບສະພາບການໂດຍຜ່ານ payload generator YAML. file ຫຼືຕົວເລືອກ Kconfig ຕໍ່ໄປນີ້.
CONFIG_ALLOW_COLD REBOOT_ALWAYS
- ຖ້າເປີດໃຊ້, ຄຸນສົມບັດນີ້ທົ່ວໂລກອະນຸຍາດໃຫ້ທຸກສະພາບການອອກ ECAA ຣີບູດເຢັນ, ໂດຍບໍ່ຄໍານຶງເຖິງສິດທິຂອງທຸງ payload.bin.
- ນອກຈາກນັ້ນ, payload.bin ຕົວຂອງມັນເອງສາມາດມີທຸງຕໍ່ສະພາບການ, ເຊິ່ງຊີ້ໃຫ້ເຫັນວ່າບໍລິບົດສະເພາະໃດນຶ່ງມີສິດທີ່ຈະອອກ cool reboots:
  - ເພື່ອອະນຸຍາດໃຫ້ context warm reboot ສະພາບການອື່ນ, ພວກເຮົາສາມາດເພີ່ມທາງເລືອກ allow-reboot: warm in the YAML description file ໃຊ້ເພື່ອສ້າງ payload.bin
  - ເພື່ອອະນຸຍາດໃຫ້ສະພາບການປິດເປີດເຄື່ອງໃໝ່ຂອງລະບົບທັງໝົດ, ພວກເຮົາສາມາດເພີ່ມຕົວເລືອກອະນຸຍາດໃຫ້ປິດເປີດໃໝ່: ເຢັນ. ໂດຍຄ່າເລີ່ມຕົ້ນ, ໂດຍບໍ່ລະບຸການອະນຸຍາດໃຫ້ປິດເປີດໃໝ່, ບໍລິບົດແມ່ນອະນຸຍາດໃຫ້ປິດເປີດໃໝ່ເທົ່ານັ້ນ ໂດຍບໍ່ສົນການຕັ້ງຄ່າຂອງທຸງນີ້, ຖ້າ CONFIG_ALLOW_COLDREBOOT ບໍ່ໄດ້ເປີດໃຊ້ໃນ HSS, HSS ຈະເຮັດວຽກຄືນທຸກຄໍາຮ້ອງຂໍ reboot ເຢັນເພື່ອອົບອຸ່ນ (ຕໍ່ສະພາບການ) reboots. .

ຣີບູດໃນລາຍລະອຽດ
ພາກສ່ວນນີ້ອະທິບາຍວິທີການ reboot ເຮັດວຽກໂດຍລະອຽດ - ໂດຍເລີ່ມຕົ້ນດ້ວຍຊັ້ນ OpenSBI (ຊັ້ນ M-mode ຕ່ໍາສຸດ) ແລະຫຼັງຈາກນັ້ນປຶກສາຫາລືວິທີການເຮັດວຽກຂອງຊັ້ນ OpenSBI ນີ້ມາຈາກແອັບພລິເຄຊັນ RTOS ຫຼື OS ທີ່ອຸດົມສົມບູນເຊັ່ນ Linux.

OpenSBI Reboot ecall

ຂໍ້ມູນຈໍາເພາະຂອງ RISC-V Supervisor Binary Interface (SBI) ອະທິບາຍ layer abstraction ຮາດແວທີ່ໄດ້ມາດຕະຖານສໍາລັບການເລີ່ມຕົ້ນແພລດຟອມ ແລະການບໍລິການແລ່ນເວລາເຟີມແວ. ຈຸດປະສົງຫຼັກຂອງ SBI ແມ່ນເພື່ອເປີດໃຊ້ງານ ແລະການເຂົ້າກັນໄດ້ໃນທົ່ວການປະຕິບັດ RISC-V ທີ່ແຕກຕ່າງກັນ.
OpenSBI (Open Source Supervisor Binary Interface) ແມ່ນໂຄງການແຫຼ່ງເປີດທີ່ສະຫນອງການປະຕິບັດການອ້າງອີງຂອງຂໍ້ກໍານົດ SBI. OpenSBI ຍັງໃຫ້ບໍລິການ runtime, ລວມທັງການຈັດການຂັດຂວາງ, ການຈັດການຈັບເວລາ, ແລະ console I/O, ເຊິ່ງສາມາດຖືກນໍາໃຊ້ໂດຍຊັ້ນຊອບແວລະດັບສູງ.
OpenSBI ຖືກລວມເຂົ້າເປັນສ່ວນໜຶ່ງຂອງ HSS ແລະແລ່ນຢູ່ໃນລະດັບ Machine Mode. ເມື່ອລະບົບປະຕິບັດການຫຼືແອັບພລິເຄຊັນເຮັດໃຫ້ເກີດການໃສ່ກັບດັກ, ມັນຈະຖືກສົ່ງກັບ OpenSBI ເພື່ອຈັດການກັບມັນ. OpenSBI ເປີດເຜີຍການທໍາງານປະເພດການໂທລະບົບສະເພາະໃດຫນຶ່ງກັບຊັ້ນເທິງຂອງຊອບແວໂດຍຜ່ານກົນໄກການດັກໂດຍສະເພາະແມ່ນເອີ້ນວ່າ ecall.

ການຕັ້ງລະບົບຄືນໃຫມ່ (EID 0x53525354) ສະຫນອງຟັງຊັນການໂທລະບົບທີ່ສົມບູນແບບທີ່ອະນຸຍາດໃຫ້ຊອຟແວຊັ້ນເທິງຮ້ອງຂໍການປິດເປີດຫຼືປິດລະດັບລະບົບ. ເມື່ອ ecall ນີ້ຖືກເອີ້ນໂດຍ U54, ມັນຖືກຕິດຢູ່ໂດຍຊອຟແວ HSS ທີ່ເຮັດວຽກຢູ່ໃນ Machine Mode ໃນ U54 ນັ້ນ, ແລະການຮ້ອງຂໍ reboot ທີ່ສອດຄ້ອງກັນຖືກສົ່ງໄປຫາ E51 ເພື່ອ reboot ບໍ່ວ່າຈະຢູ່ໃນສະພາບການຫຼືລະບົບທັງຫມົດ, ຂຶ້ນກັບສິດທິຂອງ. ສະພາບການ.

ສໍາລັບຂໍ້ມູນເພີ່ມເຕີມ, ເບິ່ງໄດ້ RISC-V Supervisor Binary Interface Specification ໂດຍສະເພາະ ສ່ວນຂະຫຍາຍການຣີເຊັດລະບົບ (EID #0x53525354 “SRST”).

Linux reboot

ໃນຖານະເປັນສະເພາະ exampໃນເລື່ອງນີ້, ໃນ Linux, ຄໍາສັ່ງປິດຖືກນໍາໃຊ້ເພື່ອຢຸດຫຼືປິດລະບົບໃຫມ່. ຄໍາສັ່ງປົກກະຕິແລ້ວມີນາມແຝງຫຼາຍອັນ, ຄື ຢຸດ, ປິດເຄື່ອງ, ແລະປິດເປີດໃໝ່. ນາມແຝງເຫຼົ່ານີ້ກໍານົດວ່າຈະຢຸດເຄື່ອງໃນເວລາປິດເຄື່ອງ, ປິດເຄື່ອງໃນເວລາປິດ, ຫຼືປິດເປີດເຄື່ອງໃຫມ່ໃນເວລາປິດ.

ຄໍາສັ່ງພື້ນທີ່ຜູ້ໃຊ້ເຫຼົ່ານີ້ອອກການເອີ້ນລະບົບ reboot ກັບ Linux, ເຊິ່ງຖືກດັກໂດຍ kernel ແລະ interworked ກັບ SBI ecall.
ມີຫຼາຍລະດັບຂອງການ reboot – REBOOT_WARM, REBOOT_COLD, REBOOT_HARD – ເຫຼົ່ານີ້ສາມາດຖືກສົ່ງຜ່ານເປັນ argument ແຖວຄໍາສັ່ງກັບ kernel (ສໍາລັບ example, reboot=w[arm] ສໍາລັບ REBOOT_WARM). ສໍາລັບຂໍ້ມູນເພີ່ມເຕີມກ່ຽວກັບລະຫັດແຫຼ່ງ Linux kernel, ເບິ່ງ ເອກະສານ/admin-guide/kernel-parammers.txt.
ອີກທາງເລືອກ, ຖ້າ /sys/kernel/reboot ຖືກເປີດໃຊ້, ຕົວຈັດການທີ່ຢູ່ຂ້າງລຸ່ມສາມາດອ່ານໄດ້ເພື່ອເອົາການຕັ້ງຄ່າລະບົບ reboot ໃນປັດຈຸບັນ, ແລະຂຽນເພື່ອປ່ຽນແປງມັນ. ສໍາລັບຂໍ້ມູນເພີ່ມເຕີມກ່ຽວກັບລະຫັດແຫຼ່ງ Linux kernel, ເບິ່ງ ເອກະສານ/ABI/testing/sysfs-kernel-reboot.

ເຝົ້າລະວັງ

ແນວຄວາມຄິດອີກອັນໜຶ່ງທີ່ກ່ຽວຂ້ອງກັບການບູດລະບົບ ແລະ ການປິດເປີດລະບົບຄືນໃໝ່ແມ່ນການຟື້ນຕົວຂອງລະບົບເມື່ອມີການເປີດເຄື່ອງຈັບເວລາເຝົ້າລະວັງ. ເຄື່ອງຈັບເວລາ Watchdog ຖືກໃຊ້ຢ່າງກວ້າງຂວາງໃນລະບົບຝັງຕົວເພື່ອຟື້ນຕົວອັດຕະໂນມັດຈາກຄວາມຜິດຂອງຮາດແວຊົ່ວຄາວ, ແລະເພື່ອປ້ອງກັນຊອບແວທີ່ຜິດພາດຫຼືເປັນອັນຕະລາຍຈາກການຂັດຂວາງການເຮັດວຽກຂອງລະບົບ.
PIC64GX ປະກອບມີການຮອງຮັບຮາດແວເຝົ້າລະວັງເພື່ອຕິດຕາມຮາດແວສ່ວນບຸກຄົນໃນເວລາທີ່ລະບົບກໍາລັງເຮັດວຽກ. watchdogs ຮັບປະກັນວ່າ harts ສາມາດ restarted ຖ້າພວກເຂົາບໍ່ຕອບສະຫນອງເນື່ອງຈາກຄວາມຜິດພາດຂອງຊອບແວທີ່ບໍ່ສາມາດຟື້ນຟູໄດ້.
PIC64GX ປະກອບມີຫ້າຕົວຢ່າງຂອງຕັນຮາດແວ timer watchdog ທີ່ໃຊ້ເພື່ອກວດຫາການລັອກລະບົບ -one ສໍາລັບແຕ່ລະ harts. ເພື່ອອໍານວຍຄວາມສະດວກໃນການປະມວນຜົນຫຼາຍແບບ Asymmetric ແບບປະສົມ (AMP) ປະລິມານການເຮັດວຽກ, HSS ສະຫນັບສະຫນູນການຕິດຕາມແລະ reacting ກັບ watchdogs firing.

PIC64GX Watchdog

HSS ມີໜ້າທີ່ຮັບຜິດຊອບໃນການບູດແອັບພລິເຄຊັ່ນ harts ໃນເວລາເປີດເຄື່ອງ, ແລະເປີດເຄື່ອງຄືນໃໝ່ (ສະເພາະບຸກຄົນ ຫຼື ລວມກັນ) ໃນທຸກເວລາ.tage, ມັນຄວນຈະຕ້ອງການຫຼືຕ້ອງການ. ດ້ວຍເຫດນີ້, ປະຕິກິລິຍາຕໍ່ເຫດການເຝົ້າລະວັງໃນ PIC64GX ແມ່ນຈັດການໂດຍ HSS.
ຈໍສະແດງຜົນ 'virtual watchdog' ຖືກປະຕິບັດເປັນບໍລິການເຄື່ອງຈັກຂອງລັດ HSS, ແລະຄວາມຮັບຜິດຊອບຂອງມັນແມ່ນເພື່ອຕິດຕາມສະຖານະຂອງແຕ່ລະຕົວຕິດຕາມຮາດແວຂອງ U54. ເມື່ອນຶ່ງໃນຈຳນວນ U54 watchdogs ເຫຼົ່ານີ້ເດີນທາງ, HSS ກວດພົບສິ່ງນີ້ ແລະຈະປິດເປີດ U54 ຄືນໃໝ່ຕາມຄວາມເໝາະສົມ. ຖ້າ U54 ເປັນສ່ວນໜຶ່ງຂອງບໍລິບົດ SMP, ບໍລິບົດທັງໝົດຈະຖືກພິຈາລະນາສຳລັບການປິດເປີດໃໝ່, ເນື່ອງຈາກບໍລິບົດມີສິດທິພິເສດໃນການປິດເປີດຄືນໃໝ່. ລະບົບທັງໝົດຈະຖືກປິດເປີດຄືນໃໝ່ ຖ້າບໍລິບົດມີສິດທິພິເສດໃນການປິດເປີດໃໝ່.

ຕົວເລືອກ Kconfig ທີ່ກ່ຽວຂ້ອງ

ການສະຫນັບສະຫນູນ Watchdog ແມ່ນລວມຢູ່ໃນຄ່າເລີ່ມຕົ້ນໃນການກໍ່ສ້າງ HSS ທີ່ປ່ອຍອອກມາ. ຖ້າເຈົ້າຕ້ອງການສ້າງ HSS ແບບກຳນົດເອງ, ພາກນີ້ຈະອະທິບາຍກົນໄກການກຳນົດຄ່າເພື່ອຮັບປະກັນວ່າການຮອງຮັບ Watchdog ຖືກເປີດໃຊ້.

HSS ຖືກຕັ້ງຄ່າໂດຍໃຊ້ລະບົບການຕັ້ງຄ່າ Kconfig. ລະດັບສູງສຸດ .config file ຈໍາເປັນຕ້ອງໄດ້ເລືອກເອົາການບໍລິການໃດທີ່ຖືກລວບລວມຢູ່ໃນຫຼືອອກຈາກການກໍ່ສ້າງ HSS.
ກ່ອນອື່ນ ໝົດ, ທາງເລືອກ CONFIG_SERVICE_WDOG ລະດັບສູງສຸດຕ້ອງໄດ້ຮັບການເປີດໃຊ້ງານ (“ການຮອງຮັບການເຝົ້າລະວັງແບບສະເໝືອນ” ຜ່ານການສ້າງການຕັ້ງຄ່າ).

ນີ້ຫຼັງຈາກນັ້ນເປີດເຜີຍທາງເລືອກຍ່ອຍຕໍ່ໄປນີ້ເຊິ່ງຂຶ້ນກັບການສະຫນັບສະຫນູນ Watchdog:

CONFIG_SERVICE_WD OG_DEBUG
ເປີດໃຊ້ການຮອງຮັບຂໍ້ມູນ/ຂໍ້ບົກພ່ອງຈາກການບໍລິການເຝົ້າລະວັງສະເໝືອນ.
CONFIG_SERVICE_WD OG_DEBUG_TIMEOUT_SECS
ກໍານົດໄລຍະເວລາ (ເປັນວິນາທີ) ທີ່ຂໍ້ຄວາມດີບັກ Watchdog ຈະຖືກສົ່ງອອກໂດຍ HSS.
CONFIG_SERVICE_WD OG_ENABLE_E51
ເປີດໃຊ້ໂມງເຝົ້າລະວັງ E51 ຕິດຕາມຫົວໃຈນອກເໜືອໄປຈາກ U54s, ປົກປ້ອງການເຮັດວຽກຂອງ HSS ເອງ.

ເມື່ອ E51 watchdog ຖືກເປີດໃຊ້, HSS ຈະຂຽນເປັນໄລຍະໄປຫາ Watchdog ເພື່ອໂຫຼດຫນ້າຈໍຄືນມັນແລະປ້ອງກັນບໍ່ໃຫ້ມັນຈາກການຍິງ. ຖ້າເຫດຜົນບາງຢ່າງ, ຫົວໃຈ E51 ລັອກຂຶ້ນຫຼືຂັດຂ້ອງແລະເຄື່ອງເຝົ້າລະວັງ E51 ຖືກເປີດໃຊ້, ນີ້ຈະຕັ້ງລະບົບທັງຫມົດຄືນໃຫມ່ສະເຫມີ.

ການດໍາເນີນງານ Watchdog
ຮາດແວ watchdog ປະຕິບັດຕົວນັບລົງ. ສາມາດສ້າງໜ້າຈໍຫ້າມໂຫຼດຂໍ້ມູນຄືນໃໝ່ໄດ້ໂດຍການກຳນົດຄ່າສູງສຸດຂອງ watchdog ທີ່ອະນຸຍາດໃຫ້ໂຫຼດຂໍ້ມູນຄືນໃໝ່ (MVRP).

ເມື່ອມູນຄ່າປັດຈຸບັນຂອງໂມງຈັບເວລາຫຼາຍກວ່າຄ່າ MVRP, ການໂຫຼດຫນ້າຈໍຄືນຂອງ watchdog ແມ່ນຖືກຫ້າມ. ການພະຍາຍາມໂຫຼດຫນ້າຈໍຄືນໂມງຈັບເວລາຢູ່ໃນປ່ອງຢ້ຽມທີ່ຫ້າມຈະຢືນຢັນການຂັດຂວາງການຫມົດເວລາ.

ການໂຫຼດຫນ້າຈໍຄືນ watchdog ລະຫວ່າງຄ່າ MVRP ແລະຄ່າ Trigger (TRIG) ສົບຜົນສໍາເລັດຈະໂຫຼດຫນ້າຈໍຄືນ counter ແລະປ້ອງກັນບໍ່ໃຫ້ watchdog firing.
ເມື່ອຄ່າໂມງຈັບເວລາຂອງ watchdog ນັບຕໍ່າກວ່າຄ່າ TRIG, watchdog ຈະດັບໄຟ.

Watchdog State Machine

ເຄື່ອງລັດ watchdog ແມ່ນກົງໄປກົງມາຫຼາຍ - ເລີ່ມຕົ້ນໂດຍການຕັ້ງຄ່າ watchdog ສໍາລັບ E51, ຖ້າເປີດໃຊ້, ຫຼັງຈາກນັ້ນຍ້າຍຜ່ານລັດທີ່ບໍ່ມີປະໂຫຍດເຂົ້າໄປໃນການຕິດຕາມ. ແຕ່ລະຄັ້ງທີ່ອ້ອມຮອບ superloop, ສະຖານະການຕິດຕາມນີ້ຈະຖືກເອີ້ນ, ເຊິ່ງກວດເບິ່ງສະຖານະຂອງແຕ່ລະ U54 watchdogs.

ເຄື່ອງລັດ watchdog ໂຕ້ຕອບກັບເຄື່ອງລັດບູດເພື່ອຣີສະຕາດ hart (ແລະຮາດອື່ນໆທີ່ຢູ່ໃນຊຸດບູດຂອງມັນ), ຖ້າມັນກວດພົບວ່າ hart ບໍ່ໄດ້ຈັດການເພື່ອໂຫຼດຫນ້າຈໍຄືນ watchdog ຂອງມັນໃຫ້ທັນເວລາ.

ແບບ Lockdown

ປົກກະຕິ (ໂດຍສະເພາະກັບ AMP ຄໍາຮ້ອງສະຫມັກ), ຄາດວ່າ HSS ຈະຢູ່ໃນໂຫມດ M, ໃນ U54, ເພື່ອອະນຸຍາດໃຫ້ reboot ຕໍ່ສະພາບການ (ເຊັ່ນ: reboot ຫນຶ່ງບໍລິບົດເທົ່ານັ້ນ, ໂດຍບໍ່ມີການ reboot ຊິບເຕັມ), ແລະອະນຸຍາດໃຫ້ HSS ຕິດຕາມກວດກາສຸຂະພາບ (. ECCs, Lock Status Bits, Bus Error, SBI errors, PMP ການລະເມີດ, ແລະອື່ນໆ).

ເພື່ອສະຫນອງຄວາມສາມາດ reboot ໃນ per-AMP ພື້ນຖານບໍລິບົດ (ໂດຍບໍ່ໄດ້ຮຽກຮ້ອງໃຫ້ລະບົບທັງຫມົດ reboot), E51 ປົກກະຕິມີສິດທິພິເສດໃນການເຂົ້າເຖິງຫນ່ວຍຄວາມຈໍາໃນພື້ນທີ່ຫນ່ວຍຄວາມຈໍາຂອງລະບົບທັງຫມົດ. ຢ່າງໃດກໍ່ຕາມ, ອາດຈະມີສະຖານະການທີ່ບໍ່ເປັນທີ່ຕ້ອງການ, ແລະລູກຄ້າອາດຈະຕ້ອງການທີ່ຈະຈໍາກັດສິ່ງທີ່ເຟີມແວ E51 HSS ເຮັດເມື່ອລະບົບໄດ້ບູດສໍາເລັດ. ໃນກໍລະນີນີ້, ມັນເປັນໄປໄດ້ທີ່ຈະເຮັດໃຫ້ HSS ເຂົ້າໄປໃນໂຫມດລັອກເມື່ອ U54 Application Harts ໄດ້ຮັບການບູດ.

ນີ້ສາມາດເປີດໃຊ້ໄດ້ໂດຍໃຊ້ຕົວເລືອກ HSS Kconfig CONFIG_SERVICE_LOCKDOWN.
ບໍລິການປິດລ້ອມມີຈຸດປະສົງເພື່ອອະນຸຍາດໃຫ້ມີການຈໍາກັດກິດຈະກໍາຂອງ HSS ຫຼັງຈາກທີ່ມັນເປີດ U54 ແອັບພລິເຄຊັນ Harts.

ຮູບທີ 4.2. ໂໝດການລັອກ HSS

ເມື່ອໂຫມດ Lockdown ເລີ່ມຕົ້ນ, ມັນຈະຢຸດເຄື່ອງລັດບໍລິການ HSS ອື່ນໆທັງໝົດຈາກການເຮັດວຽກ. ມັນເອີ້ນສອງຫນ້າທີ່ຜູກມັດທີ່ອ່ອນແອ:

e51_pmp_lockdown(), ແລະ
e51_lockdown()

ຟັງຊັນເຫຼົ່ານີ້ມີຈຸດປະສົງເພື່ອຖືກລົບລ້າງໂດຍລະຫັດສະເພາະຂອງກະດານ. ທໍາອິດແມ່ນຫນ້າທີ່ trigger ທີ່ສາມາດຕັ້ງຄ່າໄດ້ເພື່ອໃຫ້ BSP ປັບແຕ່ງການລັອກ E51 ອອກຈາກ payloads ຄໍາຮ້ອງສະຫມັກໃນຈຸດນີ້. ການປະຕິບັດຄ່າເລີ່ມຕົ້ນທີ່ຖືກຜູກມັດທີ່ອ່ອນແອຂອງຟັງຊັນນີ້ແມ່ນຫວ່າງເປົ່າ. ອັນທີສອງແມ່ນການເຮັດວຽກທີ່ດໍາເນີນການຈາກຈຸດນັ້ນໄປຂ້າງຫນ້າ. ການບໍລິການປະຕິບັດໃນຕອນຕົ້ນທີ່ຜູກມັດທີ່ອ່ອນແອທີ່ເຝົ້າລະວັງຢູ່ໃນຈຸດນີ້ໃນ E51, ແລະຈະປິດເປີດໃຫມ່ຖ້າ U54 ດັບເພີງ. ສໍາລັບຂໍ້ມູນເພີ່ມເຕີມ, ເບິ່ງລະຫັດແຫຼ່ງ HSS ໃນ services/lockdown/lockdown_service.c file.

ເອກະສານຊ້ອນທ້າຍ

ຮູບແບບ HSS payload.bin

ພາກນີ້ອະທິບາຍ payload.bin file ຮູບແບບແລະຮູບພາບທີ່ໃຊ້ໂດຍ HSS ເພື່ອບູດ PIC64GX SMP ແລະ AMP ຄໍາຮ້ອງສະຫມັກ.
payload.bin ແມ່ນຮູບແບບຖານສອງ (ຮູບ A.10) ປະກອບດ້ວຍຫົວ, ຕາຕະລາງ descriptor ຕ່າງໆ, ແລະ chunks ຕ່າງໆທີ່ມີລະຫັດແລະຂໍ້ມູນຂອງແຕ່ລະພາກສ່ວນຂອງການເຮັດວຽກຂອງຄໍາຮ້ອງສະຫມັກ. chunk ສາມາດພິຈາລະນາເປັນຕັນທີ່ຕິດກັນຂະຫນາດຂອງຫນ່ວຍຄວາມຈໍາ.

ຮູບ A.10. ຮູບແບບ payload.bin

ສ່ວນຫົວ (ສະແດງຢູ່ໃນຮູບ A.11) ປະກອບມີຄ່າ magic ທີ່ໃຊ້ໃນການລະບຸ payload.bin ແລະຂໍ້ມູນການເກັບຮັກສາເຮືອນບາງອັນ, ພ້ອມກັບລາຍລະອຽດຂອງຮູບພາບທີ່ມີຈຸດປະສົງເພື່ອດໍາເນີນການແຕ່ລະອັນ.
ລະຫັດຄໍາຮ້ອງສະຫມັກ U54. ມັນອະທິບາຍວິທີການ boot ແຕ່ລະ U54 hart ແຕ່ລະຄົນ, ແລະຊຸດຮູບພາບທີ່ສາມາດ boot ໄດ້ໂດຍລວມ. ໃນຂໍ້ມູນການຮັກສາເຮືອນຂອງມັນ, ມັນມີຕົວຊີ້ໄປຫາຕາຕະລາງຕ່າງໆຂອງຕົວອະທິບາຍເພື່ອໃຫ້ຂະຫນາດຂອງຫົວເພີ່ມຂຶ້ນ.

ຮູບ A.11. payload.bin ສ່ວນຫົວ

ລະຫັດ ແລະຂໍ້ມູນຄົງທີ່ເບື້ອງຕົ້ນແມ່ນຖືວ່າອ່ານໄດ້ຢ່າງດຽວ ແລະຖືກເກັບໄວ້ໃນພາກອ່ານເທົ່ານັ້ນ, ເຊິ່ງຊີ້ໄປໂດຍຕົວອະທິບາຍສ່ວນຫົວ.
ຕົວແປຂໍ້ມູນເບື້ອງຕົ້ນທີ່ບໍ່ແມ່ນສູນແມ່ນຂໍ້ມູນທີ່ອ່ານ-ຂຽນ ແຕ່ມີຄ່າເບື້ອງຕົ້ນຂອງພວກມັນຖືກຄັດລອກຈາກຕອນທີ່ອ່ານຢ່າງດຽວໃນຕອນເລີ່ມຕົ້ນ. ສິ່ງເຫຼົ່ານີ້ຍັງຖືກເກັບໄວ້ໃນພາກອ່ານເທົ່ານັ້ນ.

ພາກສ່ວນຂໍ້ມູນ payload ແບບອ່ານຢ່າງດຽວແມ່ນອະທິບາຍໂດຍຕາຕະລາງຂອງລະຫັດ ແລະຕົວອະທິບາຍສ່ວນຂໍ້ມູນ. ແຕ່ລະ chunk descriptor ໃນຕາຕະລາງນີ້ປະກອບດ້ວຍ 'hart owner' (hart ຕົ້ນຕໍໃນສະພາບການທີ່ມັນຖືກເປົ້າຫມາຍ.
at), ຄ່າຊົດເຊີຍການໂຫຼດ (ຊົດເຊີຍພາຍໃນ payload.bin), ແລະທີ່ຢູ່ປະຕິບັດ (ທີ່ຢູ່ປາຍທາງໃນຫນ່ວຍຄວາມຈໍາ PIC64GX), ພ້ອມກັບຂະຫນາດແລະ checksum. ນີ້ແມ່ນສະແດງຢູ່ໃນຮູບ A.12.

ຮູບ A.12. Read-Only Chunk Descriptor ແລະ Payload Chunk Data

ນອກເຫນືອໄປຈາກ chunks ທີ່ໄດ້ກ່າວມາຂ້າງເທິງ, ຍັງມີ chunks ຂອງຫນ່ວຍຄວາມຈໍາທີ່ສອດຄ້ອງກັນກັບຕົວແປຂໍ້ມູນທີ່ຖືກເລີ່ມຕົ້ນເປັນສູນ. ສິ່ງເຫຼົ່ານີ້ບໍ່ໄດ້ຖືກເກັບໄວ້ເປັນຂໍ້ມູນໃນ payload.bin, ແຕ່ແທນທີ່ຈະເປັນຊຸດພິເສດຂອງຕົວອະທິບາຍ chunk ທີ່ເປັນສູນ, ເຊິ່ງລະບຸທີ່ຢູ່ ແລະຄວາມຍາວຂອງ RAM ເພື່ອຕັ້ງເປັນສູນໃນລະຫວ່າງການເລີ່ມຕົ້ນ. ນີ້ແມ່ນສະແດງຢູ່ໃນຮູບ A.13.

ຮູບ A.13. ZI Chunks

hss-payload-generator
ເຄື່ອງມື HSS Payload Generator ສ້າງຮູບພາບ payload ທີ່ມີຮູບແບບສໍາລັບ Hart Software Service zero-stage bootloader ເທິງ PIC64GX, ໃຫ້ການຕັ້ງຄ່າ file ແລະຊຸດຂອງ ELF files ແລະ/ຫຼື binary. ການຕັ້ງຄ່າ file ຖືກນໍາໃຊ້ເພື່ອສ້າງແຜນທີ່ ELF binaries ຫຼື binary blobs ກັບ harts ຄໍາຮ້ອງສະຫມັກສ່ວນບຸກຄົນ (U54s).

ຮູບ B.14. hss-payload-generator Flow

ເຄື່ອງມືເຮັດການກວດສອບສຸຂະພາບຂັ້ນພື້ນຖານກ່ຽວກັບໂຄງສ້າງຂອງການຕັ້ງຄ່າໄດ້ file ຕົວຂອງມັນເອງແລະຮູບພາບ ELF. ຮູບພາບ ELF ຈະຕ້ອງເປັນ RISC-V ປະຕິບັດໄດ້.

Example Run

ເພື່ອແລ່ນເຄື່ອງມື hss-payload-generator ດ້ວຍ sampການຕັ້ງຄ່າ file ແລະ ELF files:
$ ./hss-payload-generator -c test/config.yaml output.bin
ເພື່ອພິມການວິນິໄສກ່ຽວກັບຮູບພາບທີ່ມີຢູ່ກ່ອນແລ້ວ, ໃຫ້ໃຊ້:
$ ./hss-payload-generator -d output.bin

ເພື່ອເປີດໃຊ້ການພິສູດຢືນຢັນການບູດທີ່ປອດໄພ (ຜ່ານການເຊັນຮູບ), ໃຊ້ -p ເພື່ອລະບຸສະຖານທີ່ຂອງກະແຈສ່ວນຕົວ X.509 ສໍາລັບ Elliptic Curve P-384 (SECP384r1):
$ ./hss-payload-generator -c test/config.yaml payload.bin -p /path/to/private.pem

ສໍາລັບຂໍ້ມູນເພີ່ມເຕີມ, ເບິ່ງເອກະສານ Secure Boot Authentication.

ກຳນົດຄ່າ File Example

ທໍາອິດ, ພວກເຮົາສາມາດເລືອກຊື່ສໍາລັບຮູບພາບຂອງພວກເຮົາ, ຖ້າບໍ່ດັ່ງນັ້ນ, ຫນຶ່ງຈະຖືກສ້າງແບບເຄື່ອນໄຫວ:
ຕັ້ງຊື່: 'PIC64-HSS::TestImage'
ຕໍ່ໄປ, ພວກເຮົາຈະກໍານົດທີ່ຢູ່ຈຸດເຂົ້າສໍາລັບແຕ່ລະຫົວໃຈ, ດັ່ງນີ້:
hart-entry-points: {u54_1: ‘0x80200000’, u54_2: ‘0x80200000’, u54_3: ‘0xB0000000′, u54_4:’0x80200000’}

ຮູບພາບແຫຼ່ງ ELF ສາມາດລະບຸຈຸດເຂົ້າ, ແຕ່ພວກເຮົາຕ້ອງການທີ່ຈະສາມາດສະຫນັບສະຫນູນຈຸດເຂົ້າຂັ້ນສອງສໍາລັບ harts ຖ້າຈໍາເປັນ, ສໍາລັບ ex.ampຖ້າ ຫາກ ວ່າ ຫຼາຍ harts ມີ ຈຸດ ປະ ສົງ ເພື່ອ boot ຮູບ ດຽວ ກັນ, ພວກ ເຂົາ ເຈົ້າ ອາດ ຈະ ມີ ຈຸດ ເຂົ້າ ຂອງ ບຸກ ຄົນ. ເພື່ອຮອງຮັບສິ່ງນີ້, ພວກເຮົາລະບຸທີ່ຢູ່ຈຸດເຂົ້າຕົວຈິງໃນການຕັ້ງຄ່າ file ຕົວຂອງມັນເອງ.

ຕອນນີ້ພວກເຮົາສາມາດກໍານົດບາງ payloads (ແຫຼ່ງ ELF files, ຫຼື binary blobs) ທີ່ຈະຖືກຈັດໃສ່ໃນບາງຂົງເຂດໃນຄວາມຊົງຈໍາ. ພາກສ່ວນ payload ຖືກກໍານົດດ້ວຍ payloads ຄໍາສໍາຄັນ, ແລະຫຼັງຈາກນັ້ນຈໍານວນຂອງ payload descriptors ບຸກຄົນ. ແຕ່ລະ payload ມີຊື່ (ເສັ້ນທາງໄປຫາມັນ file), a owner-hart, ແລະທາງເລືອກ 1 ຫາ 3 harts ມັດທະຍົມ.

ນອກຈາກນັ້ນ, payload ມີໂຫມດສິດທິພິເສດທີ່ມັນຈະເລີ່ມປະຕິບັດ. ໂໝດສິດທິພິເສດທີ່ຖືກຕ້ອງແມ່ນ PRV_M, PRV_S ແລະ PRV_U, ບ່ອນທີ່ສິ່ງເຫຼົ່ານີ້ຖືກກຳນົດເປັນ:

PRV_M ໂໝດເຄື່ອງ
PRV_S ໂໝດຜູ້ຄຸມງານ
PRV_U ໂໝດຜູ້ໃຊ້

ໃນຕົວຢ່າງຕໍ່ໄປນີ້ample:

test/zephyr.elf ແມ່ນສົມມຸດວ່າເປັນແອັບພລິເຄຊັນ Zephyr ທີ່ເຮັດວຽກຢູ່ໃນ U54_3, ແລະຄາດວ່າຈະເລີ່ມຕົ້ນໃນໂໝດສິດທິພິເສດ PRV_M.
test/u-boot-dtb.bin ແມ່ນແອັບພລິເຄຊັນ Das U-Boot bootloader, ແລະມັນເຮັດວຽກຢູ່ໃນ U54_1, U54_2 ແລະ U54_4. ມັນຄາດວ່າຈະເລີ່ມຕົ້ນໃນໂຫມດສິດທິພິເສດ PRV_S.

ສຳຄັນ:
ຜົນຜະລິດຂອງ U-Boot ສ້າງ ELF file, ແຕ່ໂດຍທົ່ວໄປແລ້ວມັນບໍ່ໄດ້ມີສ່ວນຂະຫຍາຍ .elf. ໃນກໍລະນີນີ້, ໄບນາຣີທີ່ສ້າງໂດຍ CONFIG_OF_SEPARATE ຖືກນໍາໃຊ້, ເຊິ່ງຕໍ່ທ້າຍອຸປະກອນຕົ້ນໄມ້ໃສ່ກັບ U-Boot binary.

ນີ້ແມ່ນ example ການຕັ້ງຄ່າ 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}

ສຳຄັນ:
ກໍລະນີພຽງແຕ່ສໍາລັບການ file ຊື່ເສັ້ນທາງ, ບໍ່ແມ່ນຄໍາສໍາຄັນ. ດັ່ງນັ້ນ, ຕົວຢ່າງ, u54_1 ຖືກພິຈາລະນາຄືກັນກັບ U54_1, ແລະ exec-addr ຖືກພິຈາລະນາຄືກັນກັບ EXEC-ADDR. ຖ້າມີສ່ວນຂະຫຍາຍ an.elf ຫຼື .bin, ມັນຈໍາເປັນຕ້ອງຖືກລວມເຂົ້າໃນການຕັ້ງຄ່າ file.

ສໍາລັບຄໍາຮ້ອງສະຫມັກໂລຫະເປົ່າທີ່ບໍ່ຕ້ອງການທີ່ຈະກັງວົນກ່ຽວກັບ OpenSBI, ທາງເລືອກທີ່ຂ້າມເປີດ, ຖ້າເປັນຄວາມຈິງ, ຈະເຮັດໃຫ້ payload ໃນຫົວໃຈນັ້ນຖືກເອີ້ນໃຊ້ mret ງ່າຍດາຍແທນທີ່ຈະ.
ກ່ວາ OpenSBI sbi_init() ໂທ. ນີ້ຫມາຍຄວາມວ່າຫົວໃຈຈະເລີ່ມແລ່ນລະຫັດໂລຫະເປົ່າໂດຍບໍ່ຄໍານຶງເຖິງການພິຈາລະນາ OpenSBI HSM. ໃຫ້ສັງເກດວ່ານີ້ຍັງຫມາຍຄວາມວ່າຫົວໃຈບໍ່ສາມາດໃຊ້ໄດ້
ໂທຫາເພື່ອເອີ້ນຟັງຊັນ OpenSBI. ທາງເລືອກຂ້າມເປີດແມ່ນເປັນທາງເລືອກແລະຄ່າເລີ່ມຕົ້ນເປັນຜິດ.

ເພື່ອອະນຸຍາດໃຫ້ context reboot warm ຂອງສະພາບການອື່ນ, ພວກເຮົາສາມາດເພີ່ມທາງເລືອກອະນຸຍາດໃຫ້ reboot: ອົບອຸ່ນ. ເພື່ອອະນຸຍາດໃຫ້ສະພາບການປິດເປີດເຄື່ອງໃໝ່ຂອງລະບົບທັງໝົດ, ພວກເຮົາສາມາດເພີ່ມຕົວເລືອກອະນຸຍາດໃຫ້ປິດເປີດໃໝ່: ເຢັນ. ໂດຍຄ່າເລີ່ມຕົ້ນ, ໂດຍບໍ່ມີການກໍານົດອະນຸຍາດໃຫ້ reboot, ສະພາບການແມ່ນອະນຸຍາດໃຫ້ພຽງແຕ່ reboot ຕົວມັນເອງອົບອຸ່ນ.
ມັນຍັງສາມາດເຊື່ອມໂຍງຂໍ້ມູນເສີມກັບແຕ່ລະ payload, ສໍາລັບການຍົກຕົວຢ່າງample, a DeviceTree Blob (DTB) file, ໂດຍການລະບຸຂໍ້ມູນເສີມ fileຊື່ດັ່ງນີ້:
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 (ວາງຊື່ຫຼັງຈາກຕົ້ນຕໍໄດ້ file ໃນການປະຕິບັດໄດ້
space), ແລະທີ່ຢູ່ຂອງມັນຈະຖືກສົ່ງກັບ OpenSBI ຢູ່ໃນຊ່ອງ next_arg1 (ຜ່ານເຂົ້າໃນການລົງທະບຽນ $a1 ກັບຮູບພາບໃນເວລາ boot).

ເພື່ອປ້ອງກັນບໍ່ໃຫ້ HSS ເລີ່ມຕົ້ນອັດຕະໂນມັດໃນບໍລິບົດ (ຕົວຢ່າງ, ຖ້າພວກເຮົາຕ້ອງການມອບການຄວບຄຸມນີ້ໃຫ້ກັບບໍລິບົດໂດຍໃຊ້ remoteProc), ໃຫ້ໃຊ້ທຸງ skip-autoboot:
test/zephyr.elf: {exec-addr: '0xB0000000', owner-hart: u54_3, priv-mode: prv_m, skip-opensbi: true, skip-autoboot: true}
ສຸດທ້າຍ, ພວກເຮົາສາມາດ override ຊື່ຂອງ payloads ສ່ວນບຸກຄົນ, ທາງເລືອກ payload-name. ຕົວຢ່າງample:
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' }

ໃຫ້ສັງເກດວ່າ Yocto ແລະ Buildroot Linux builders ຈະສ້າງ, configure, ແລະດໍາເນີນການ hss-payload-
ເຄື່ອງກໍາເນີດໄຟຟ້າຕາມຄວາມຕ້ອງການເພື່ອສ້າງຮູບພາບຄໍາຮ້ອງສະຫມັກ. ນອກຈາກນັ້ນ, pic64gx-curiosity-kit-amp ເປົ້າໝາຍເຄື່ອງໃນ Yocto ຈະສ້າງຮູບພາບແອັບພລິເຄຊັນໂດຍໃຊ້ເຄື່ອງມື hss-payload-generator ທີ່ສະແດງໃຫ້ເຫັນ AMP, ມີ Linux ແລ່ນຢູ່ໃນ 3 harts ແລະ Zephyr ແລ່ນຢູ່ໃນ 1 hart.

ປະຫວັດການແກ້ໄຂ
ປະຫວັດການດັດແກ້ອະທິບາຍການປ່ຽນແປງທີ່ໄດ້ປະຕິບັດໃນເອກະສານ. ການປ່ຽນແປງແມ່ນໄດ້ລະບຸໄວ້ໂດຍການປັບປຸງ, ເລີ່ມຕົ້ນຈາກການພິມເຜີຍແຜ່ໃນປັດຈຸບັນຫຼາຍທີ່ສຸດ.

ການທົບທວນ	ວັນທີ	ລາຍລະອຽດ
A	07/2024	ການປັບປຸງເບື້ອງຕົ້ນ

ຂໍ້ມູນໄມໂຄຊິບ

ໄມໂຄຣຊິບ Webເວັບໄຊ
Microchip ໃຫ້ການຊ່ວຍເຫຼືອອອນໄລນ໌ໂດຍຜ່ານຂອງພວກເຮົາ webສະຖານທີ່ຢູ່ www.microchip.com/. ນີ້ webເວັບໄຊໄດ້ຖືກນໍາໃຊ້ເພື່ອເຮັດໃຫ້ files ແລະຂໍ້ມູນຂ່າວສານໄດ້ຢ່າງງ່າຍດາຍສາມາດໃຊ້ໄດ້ກັບລູກຄ້າ. ບາງເນື້ອໃນທີ່ມີຢູ່ລວມມີ:

ສະຫນັບສະຫນູນຜະລິດຕະພັນ - ແຜ່ນຂໍ້ມູນແລະຂໍ້ຜິດພາດ, ບັນທຶກການນໍາໃຊ້ແລະ sample ໂປລແກລມ, ຊັບພະຍາກອນການອອກແບບ, ຄູ່ມືຜູ້ໃຊ້ແລະເອກະສານສະຫນັບສະຫນູນຮາດແວ, ການປ່ອຍຊອບແວຫລ້າສຸດແລະຊອບແວທີ່ເກັບໄວ້

ສະຫນັບສະຫນູນດ້ານວິຊາການທົ່ວໄປ – ຄໍາຖາມທີ່ຖືກຖາມເລື້ອຍໆ (FAQs), ຄໍາຮ້ອງສະຫມັກສະຫນັບສະຫນູນດ້ານວິຊາການ, ກຸ່ມສົນທະນາອອນໄລນ໌, ການອອກແບບ Microchip ລາຍຊື່ສະມາຊິກໂຄງການຄູ່ຮ່ວມງານ
ທຸລະກິດຂອງ Microchip - ຄູ່ມືການຄັດເລືອກຜະລິດຕະພັນແລະການສັ່ງຊື້, ການປ່ອຍຂ່າວຫລ້າສຸດ Microchip, ລາຍຊື່ຂອງການສໍາມະນາແລະກິດຈະກໍາ, ລາຍຊື່ຂອງຫ້ອງການຂາຍ Microchip, ຈໍາຫນ່າຍ, ແລະຕົວແທນໂຮງງານຜະລິດ

ບໍລິການແຈ້ງການປ່ຽນແປງຜະລິດຕະພັນ

ບໍລິການແຈ້ງການປ່ຽນແປງຜະລິດຕະພັນຂອງ Microchip ຊ່ວຍໃຫ້ລູກຄ້າມີປະຈຸບັນກ່ຽວກັບຜະລິດຕະພັນຂອງ Microchip. ຜູ້ຈອງຈະໄດ້ຮັບການແຈ້ງເຕືອນທາງອີເມລ໌ທຸກຄັ້ງທີ່ມີການປ່ຽນແປງ, ການປັບປຸງ, ການແກ້ໄຂຫຼືຄວາມຜິດພາດທີ່ກ່ຽວຂ້ອງກັບຄອບຄົວຜະລິດຕະພັນທີ່ລະບຸຫຼືເຄື່ອງມືການພັດທະນາທີ່ມີຄວາມສົນໃຈ.

ເພື່ອລົງທະບຽນ, ໄປທີ່ www.microchip.com/pcn ແລະປະຕິບັດຕາມຄໍາແນະນໍາການລົງທະບຽນ.

ການຊ່ວຍເຫຼືອລູກຄ້າ
ຜູ້ໃຊ້ຜະລິດຕະພັນ Microchip ສາມາດໄດ້ຮັບການຊ່ວຍເຫຼືອຜ່ານຫຼາຍຊ່ອງທາງ:

ຕົວແທນຈໍາຫນ່າຍຫຼືຕົວແທນ
ຫ້ອງການຂາຍທ້ອງຖິ່ນ
Embedded Solutions Engineer (ESE)
ສະຫນັບສະຫນູນດ້ານວິຊາການ

ລູກຄ້າຄວນຕິດຕໍ່ຜູ້ຈັດຈໍາຫນ່າຍ, ຕົວແທນ, ຫຼື ESE ຂອງເຂົາເຈົ້າສໍາລັບການສະຫນັບສະຫນູນ. ຫ້ອງການຂາຍໃນທ້ອງຖິ່ນຍັງມີຢູ່ເພື່ອຊ່ວຍລູກຄ້າ. ບັນຊີລາຍຊື່ຂອງຫ້ອງການຂາຍແລະສະຖານທີ່ແມ່ນລວມຢູ່ໃນເອກະສານນີ້.
ສະຫນັບສະຫນູນດ້ານວິຊາການແມ່ນມີຢູ່ໂດຍຜ່ານ webເວັບໄຊຢູ່: www.microchip.com/support.

ຄຸນສົມບັດການປົກປ້ອງລະຫັດອຸປະກອນໄມໂຄຊິບ
ໃຫ້ສັງເກດລາຍລະອຽດຕໍ່ໄປນີ້ຂອງຄຸນສົມບັດປ້ອງກັນລະຫັດໃນຜະລິດຕະພັນໄມໂຄຊິບ:

ຜະລິດຕະພັນ Microchip ຕອບສະໜອງໄດ້ສະເພາະໃນເອກະສານຂໍ້ມູນ Microchip ໂດຍສະເພາະ.
ໄມໂຄຣຊິບເຊື່ອວ່າຜະລິດຕະພັນໃນຄອບຄົວຂອງມັນມີຄວາມປອດໄພເມື່ອໃຊ້ໃນລັກສະນະທີ່ຕັ້ງໃຈ, ພາຍໃນສະເພາະການໃຊ້ງານ ແລະພາຍໃຕ້ເງື່ອນໄຂປົກກະຕິ.

ຄຸນຄ່າຂອງ Microchip ແລະປົກປ້ອງສິດຊັບສິນທາງປັນຍາຂອງຕົນຢ່າງແຮງ. ຄວາມພະຍາຍາມທີ່ຈະລະເມີດລັກສະນະການປົກປ້ອງລະຫັດຂອງຜະລິດຕະພັນ Microchip ແມ່ນຖືກຫ້າມຢ່າງເຂັ້ມງວດແລະອາດຈະລະເມີດກົດຫມາຍວ່າດ້ວຍ Digital Millennium Copyright Act.
ທັງ Microchip ຫຼືຜູ້ຜະລິດ semiconductor ອື່ນໆສາມາດຮັບປະກັນຄວາມປອດໄພຂອງລະຫັດຂອງມັນ. ການປົກປ້ອງລະຫັດບໍ່ໄດ້ຫມາຍຄວາມວ່າພວກເຮົາກໍາລັງຮັບປະກັນວ່າຜະລິດຕະພັນແມ່ນ "ບໍ່ສາມາດທໍາລາຍໄດ້". ການປົກປ້ອງລະຫັດແມ່ນພັດທະນາຢ່າງຕໍ່ເນື່ອງ. Microchip ມຸ່ງຫມັ້ນທີ່ຈະປັບປຸງຄຸນສົມບັດການປົກປ້ອງລະຫັດຂອງຜະລິດຕະພັນຂອງພວກເຮົາຢ່າງຕໍ່ເນື່ອງ.

ປະກາດກົດໝາຍ
ສິ່ງພິມນີ້ ແລະຂໍ້ມູນໃນນີ້ອາດຈະຖືກໃຊ້ກັບຜະລິດຕະພັນໄມໂຄຊິບເທົ່ານັ້ນ, ລວມທັງການອອກແບບ, ທົດສອບ ແລະລວມຜະລິດຕະພັນໄມໂຄຊິບກັບແອັບພລິເຄຊັນຂອງເຈົ້າ. ການນໍາໃຊ້ຂໍ້ມູນນີ້ໃນລັກສະນະອື່ນໃດກໍ່ລະເມີດຂໍ້ກໍານົດເຫຼົ່ານີ້. ຂໍ້ມູນກ່ຽວກັບການນໍາໃຊ້ອຸປະກອນແມ່ນສະຫນອງໃຫ້ພຽງແຕ່ເພື່ອຄວາມສະດວກຂອງທ່ານແລະອາດຈະຖືກແທນທີ່ໂດຍການປັບປຸງ. ມັນເປັນຄວາມຮັບຜິດຊອບຂອງເຈົ້າເພື່ອຮັບປະກັນວ່າຄໍາຮ້ອງສະຫມັກຂອງເຈົ້າກົງກັບຂໍ້ກໍາຫນົດຂອງເຈົ້າ. ຕິດຕໍ່ຫ້ອງການຂາຍ Microchip ທ້ອງຖິ່ນຂອງທ່ານສໍາລັບການສະຫນັບສະຫນູນເພີ່ມເຕີມຫຼື, ໄດ້ຮັບການສະຫນັບສະຫນູນເພີ່ມເຕີມທີ່ www.microchip.com/en-us/support/design-help/client-support-services.

ຂໍ້ມູນນີ້ແມ່ນສະໜອງໃຫ້ໂດຍໄມໂຄຣຊິບ “ຄື”. ໄມໂຄຣຊິບບໍ່ໄດ້ເປັນຕົວແທນ ຫຼືການຮັບປະກັນໃດໆ ບໍ່ວ່າຈະເປັນການສະແດງອອກ ຫຼືໂດຍຫຍໍ້, ເປັນລາຍລັກອັກສອນ ຫຼືທາງປາກປາກ, ຕາມກົດໝາຍ ຫຼືໃນອີກອັນໜຶ່ງ, ກ່ຽວຂ້ອງກັບຂໍ້ມູນຮວມເຖິງຂໍ້ມູນແຕ່ບໍ່ຈຳກັດການກຳນົດໄວ້. ການບໍ່ລະເມີດ, ການຄ້າ, ແລະຄວາມສອດຄ່ອງເພື່ອຈຸດປະສົງສະເພາະ, ຫຼືການຮັບປະກັນທີ່ກ່ຽວຂ້ອງກັບເງື່ອນໄຂ, ຄຸນນະພາບ, ຫຼືການປະຕິບັດຂອງມັນ.

ໃນກໍລະນີໃດກໍ່ຕາມ, ໄມໂຄຣຊິບຈະມີຄວາມຜິດຕໍ່ຄວາມຜິດທາງອ້ອມ, ພິເສດ, ລົງໂທດ, ໂດຍບັງເອີນ, ຫຼືຜົນສະທ້ອນຕໍ່ການສູນເສຍ, ຄວາມເສຍຫາຍ, ຄ່າໃຊ້ຈ່າຍ, ຫຼືຄ່າໃຊ້ຈ່າຍໃດໆກໍຕາມທີ່ກ່ຽວຂ້ອງກັບສະພາບການປ່ຽນແປງ, ການປ່ຽນແປງໃນກໍລະນີໃດກໍ່ຕາມ. ໄດ້ຮັບການແນະນໍາຂອງ ຄວາມເປັນໄປໄດ້ ຫຼືຄວາມເສຍຫາຍແມ່ນເປັນໄປໄດ້. ໃນຂອບເຂດສູງສຸດທີ່ກົດໝາຍອະນຸຍາດ, ຄວາມຮັບຜິດ ຊອບທັງໝົດຂອງໄມໂຄຣຊິບ ຕໍ່ການຮຽກຮ້ອງທັງໝົດ ໃນທາງໃດກໍຕາມ ທີ່ກ່ຽວຂ້ອງກັບຂໍ້ມູນ ຫຼື ການໃຊ້ຂອງມັນຈະບໍ່ເກີນຈຳນວນຂອງຄ່າທຳນຽມ, ຖ້າມີ, ທີ່ເຈົ້າມີສ່ວນຈ່າຍ.

ການນໍາໃຊ້ອຸປະກອນ Microchip ໃນການຊ່ວຍເຫຼືອຊີວິດແລະ / ຫຼືຄໍາຮ້ອງສະຫມັກຄວາມປອດໄພແມ່ນມີຄວາມສ່ຽງຂອງຜູ້ຊື້ທັງຫມົດ, ແລະຜູ້ຊື້ຕົກລົງທີ່ຈະປົກປ້ອງ, ຊົດເຊີຍ, ແລະຖື Microchip ທີ່ບໍ່ມີອັນຕະລາຍຈາກຄວາມເສຍຫາຍ, ການຮຽກຮ້ອງ, ຟ້ອງ, ຫຼືຄ່າໃຊ້ຈ່າຍທີ່ເກີດຈາກການນໍາໃຊ້ດັ່ງກ່າວ. ບໍ່ມີໃບອະນຸຍາດຖືກຖ່າຍທອດ, ໂດຍທາງອ້ອມ ຫຼື ອື່ນໆ, ພາຍໃຕ້ສິດຊັບສິນທາງປັນຍາຂອງ Microchip ເວັ້ນເສຍແຕ່ໄດ້ລະບຸໄວ້ເປັນຢ່າງອື່ນ.

ເຄື່ອງໝາຍການຄ້າ
ຊື່ ແລະໂລໂກ້ຂອງ Microchip, ໂລໂກ້ Microchip, Adaptec, AVR, AVR logo, AVR Freaks, BesTime, BitCloud, CryptoMemory, CryptoRF, dsPIC, flexPWR, HELDO, IGLOO, JukeBlox, KeeLoq, Kleer, LANCheck, LinkMD, maXSty ໂລໂກ້ MediaLB, megaAVR, Microsemi, Microsemi, MOST, MOST, MPLAB, OptoLyzer, PIC, picoPower, PICSTART, ໂລໂກ້ PIC32, PolarFire, Prochip Designer, QTouch, SAM-BA, SenGenuity, SpyNIC, SST, SST Logoymmetric, SuperFlash , SyncServer, Tachyon, TimeSource, tinyAVR, UNI/O, Vectron, ແລະ XMEGA ແມ່ນເຄື່ອງໝາຍການຄ້າທີ່ຈົດທະບຽນຂອງ Microchip Technology Incorporated ໃນສະຫະລັດອາເມລິກາ ແລະປະເທດອື່ນໆ.

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, ແລະ ZL ແມ່ນເຄື່ອງໝາຍການຄ້າທີ່ຈົດທະບຽນຂອງ Microchip Technology Incorporated ໃນສະຫະລັດອາເມລິກາ

ການສະກັດກັ້ນກະແຈທີ່ຕິດກັນ, AKS, ອະນາລັອກສຳລັບຍຸກດິຈິຕອລ, ຕົວເກັບປະຈຸໃດໆ, AnyIn, AnyOut, Augmented Switching, BlueSky, BodyCom, Clockstudio, CodeGuard, CryptoAuthentication, CryptoAutomotive, CryptoCompanion, CryptoController, MDS, ds. , DAM, ECAN, Espresso T1S, EtherGREEN, EyeOpen, GridTime, IdealBridge,
IGaT, In-Circuit Serial Programming, ICSP, INICnet, Intelligent Paralleling, IntelliMOS, Inter-Chip Connectivity, JitterBlocker, Knob-on-Display, MarginLink, maxCrypto, ສູງສຸດView, 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, Pure , QMatrix, ICE ແທ້, Ripple Blocker, RTAX, RTG4, SAM-ICE, Serial Quad I/O, ແຜນທີ່ງ່າຍດາຍ, SimpliPHY, SmartBuffer, SmartHLS, SMART-IS, storClad, SQI, SuperSwitcher, SuperSwitcher II, Switchtec, SynchroPHY, Total ຄວາມອົດທົນ, ເວລາທີ່ເຊື່ອຖືໄດ້, TSHARC, Turing, USBCheck, VariSense, VectorBlox, VeriPHY, ViewSpan, WiperLock, XpressConnect, ແລະ ZENA ແມ່ນເຄື່ອງໝາຍການຄ້າຂອງ Microchip Technology Incorporated ໃນສະຫະລັດອາເມລິກາ ແລະປະເທດອື່ນໆ.

SQTP ເປັນເຄື່ອງໝາຍການບໍລິການຂອງ Microchip Technology Incorporated in USA
ໂລໂກ້ Adaptec, ຄວາມຖີ່ຕາມຄວາມຕ້ອງການ, Silicon Storage Technology, ແລະ Symmcom ແມ່ນເຄື່ອງໝາຍການຄ້າທີ່ຈົດທະບຽນຂອງ Microchip Technology Inc. ໃນປະເທດອື່ນໆ.
GestIC ເປັນເຄື່ອງໝາຍການຄ້າຈົດທະບຽນຂອງ Microchip Technology Germany II GmbH & Co. KG, ເຊິ່ງເປັນບໍລິສັດຍ່ອຍຂອງ Microchip Technology Inc., ໃນປະເທດອື່ນໆ.

ISBN: 978-1-6683-4890-1

ລະບົບການຄຸ້ມຄອງຄຸນນະພາບ
ສໍາລັບຂໍ້ມູນກ່ຽວກັບລະບົບການຄຸ້ມຄອງຄຸນນະພາບຂອງ Microchip, ກະລຸນາເຂົ້າໄປເບິ່ງ www.microchip.com/quality.

ການຂາຍ ແລະການບໍລິການທົ່ວໂລກ

ອາເມຣິກາ

ອາຊີ/ປາຊີຟິກ

ເອີຣົບ

ບໍລິສັດ ຫ້ອງການ

2355 West Chandler Blvd. Chandler, AZ 85224-6199

ໂທ: 480-792-7200

ແຟັກ: 480-792-7277

ສະຫນັບສະຫນູນດ້ານວິຊາການ: www.microchip.com/support

Web ທີ່ຢູ່: www.microchip.com

ແອດແລນຕາ

Duluth, GA

ໂທ: 678-957-9614

ແຟັກ: 678-957-1455

Austin, TX

ໂທ: 512-257-3370

ບອສຕັນ

Westborough, MA ໂທ: 774-760-0087

ແຟັກ: 774-760-0088

ຊິຄາໂກ

Itasca, IL

ໂທ: 630-285-0071

ແຟັກ: 630-285-0075

ດາລາສ

ແອດດິສັນ, TX

ໂທ: 972-818-7423

ແຟັກ: 972-818-2924

ດີທຣອຍ

Novi, MI

ໂທ: 248-848-4000

Houston, TX

ໂທ: 281-894-5983

Indianapolis

Noblesville, IN ໂທ: 317-773-8323

ແຟັກ: 317-773-5453

ໂທ: 317-536-2380

Los Angeles

Mission Viejo, CA Tel: 949-462-9523

ແຟັກ: 949-462-9608

ໂທ: 951-273-7800

ຣາລີ, NC

ໂທ: 919-844-7510

ນິວຢອກ, NY

ໂທ: 631-435-6000

ຊານ Jose, CA

ໂທ: 408-735-9110

ໂທ: 408-436-4270

ການາດາ – ໂຕຣອນໂຕ

ໂທ: 905-695-1980

ແຟັກ: 905-695-2078

ອົດສະຕາລີ - Sydney

ໂທ: 61-2-9868-6733

ຈີນ-ປັກກິ່ງ

ໂທ: 86-10-8569-7000

ຈີນ – Chengdu

ໂທ: 86-28-8665-5511

ຈີນ - ຈົງຊິງ

ໂທ: 86-23-8980-9588

ຈີນ - Dongguan

ໂທ: 86-769-8702-9880

ຈີນ - ກວາງໂຈ່ວ

ໂທ: 86-20-8755-8029

ຈີນ - Hangzhou

ໂທ: 86-571-8792-8115

ຈີນ – ຫົງ ກົງ SAR

ໂທ: 852-2943-5100

ຈີນ - Nanjing

ໂທ: 86-25-8473-2460

ຈີນ - Qingdao

ໂທ: 86-532-8502-7355

ຈີນ - ຊຽງໄຮ້

ໂທ: 86-21-3326-8000

ຈີນ - Shenyang

ໂທ: 86-24-2334-2829

ຈີນ - Shenzhen

ໂທ: 86-755-8864-2200

ຈີນ - ຊູໂຈວ

ໂທ: 86-186-6233-1526

ຈີນ - Wuhan

ໂທ: 86-27-5980-5300

ຈີນ - Xian

ໂທ: 86-29-8833-7252

ຈີນ - Xiamen

ໂທ: 86-592-2388138

ຈີນ - ຈູໄຫ່

ໂທ: 86-756-3210040

ປະເທດອິນເດຍ – Bangalore

ໂທ: 91-80-3090-4444

ອິນເດຍ - ນິວເດລີ

ໂທ: 91-11-4160-8631

ປະເທດອິນເດຍ – ປູນ

ໂທ: 91-20-4121-0141

ຍີ່ປຸ່ນ – ໂອຊາກາ

ໂທ: 81-6-6152-7160

ຍີ່ປຸ່ນ – ໂຕກຽວ

ໂທ: 81-3-6880- 3770

ເກົາຫຼີ - Daegu

ໂທ: 82-53-744-4301

ເກົາຫຼີ – ເຊອຸນ

ໂທ: 82-2-554-7200

ມາເລເຊຍ - Kuala ລໍາເປີ

ໂທ: 60-3-7651-7906

ມາເລເຊຍ - Penang

ໂທ: 60-4-227-8870

ຟີລິບປິນ – ມະນີລາ

ໂທ: 63-2-634-9065

ສິງກະໂປ

ໂທ: 65-6334-8870

ໄຕ້ຫວັນ – ຊິນຈູ

ໂທ: 886-3-577-8366

ໄຕ້ຫວັນ - Kaohsiung

ໂທ: 886-7-213-7830

ໄຕ້ຫວັນ - Taipei

ໂທ: 886-2-2508-8600

ປະເທດໄທ – ບາງກອກ

ໂທ: 66-2-694-1351

ຫວຽດນາມ - ໂຮ່ຈີມິນ

ໂທ: 84-28-5448-2100

ອອສເຕຣຍ – ເວນ

ໂທ: 43-7242-2244-39

ແຟັກ: 43-7242-2244-393

ເດນມາກ – Copenhagen

ໂທ: 45-4485-5910

ແຟັກ: 45-4485-2829

ຟິນແລນ – Espoo

ໂທ: 358-9-4520-820

ປະເທດຝຣັ່ງ – ປາຣີ

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

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

ເຢຍລະມັນ – garching

ໂທ: 49-8931-9700

ເຢຍລະມັນ – ຮານານ

ໂທ: 49-2129-3766400

ເຢຍລະມັນ – Heilbronn

ໂທ: 49-7131-72400

ເຢຍລະມັນ – Karlsruhe

ໂທ: 49-721-625370

ເຢຍລະມັນ – ມິວນິກ

Tel: 49-89-627-144-0

Fax: 49-89-627-144-44

ເຢຍລະມັນ – Rosenheim

ໂທ: 49-8031-354-560

ອິດສະຣາເອນ - Hod Hasharon

ໂທ: 972-9-775-5100

ອີຕາລີ – Milan

ໂທ: 39-0331-742611

ແຟັກ: 39-0331-466781

ອິຕາລີ - Padova

ໂທ: 39-049-7625286

ເນເທີແລນ - Drunen

ໂທ: 31-416-690399

ແຟັກ: 31-416-690340

ນໍເວ – Trondheim

ໂທ: 47-72884388

ໂປແລນ — ວໍຊໍ

ໂທ: 48-22-3325737

ໂຣມາເນຍ – Bucharest

Tel: 40-21-407-87-50

ສະເປນ – Madrid

Tel: 34-91-708-08-90

Fax: 34-91-708-08-91

ສວີເດນ – Gothenburg

Tel: 46-31-704-60-40

ສວີເດນ – ສະຕັອກໂຮມ

ໂທ: 46-8-5090-4654

ອັງກິດ - Wokingham

ໂທ: 44-118-921-5800

ແຟັກ: 44-118-921-5820

ເອກະສານ / ຊັບພະຍາກອນ

MICROCHIP PIC64GX 64-Bit RISC-V Quad-Core Microprocessor [pdf] ຄູ່ມືຜູ້ໃຊ້
PIC64GX, PIC64GX 64-Bit RISC-V Quad-Core Microprocessor, 64-Bit RISC-V Quad-Core Microprocessor, RISC-V Quad-Core Microprocessor, Quad-Core Microprocessor, ໄມໂຄຣໂປຣເຊສເຊີ

ເອກະສານອ້າງອີງ

ຄູ່ມືຜູ້ໃຊ້

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

ຂໍ້ມູນຜະລິດຕະພັນ

ຄໍາແນະນໍາການນໍາໃຊ້ຜະລິດຕະພັນ