MICROCHIP PIC64GX 64-ბიტიანი RISC-V ოთხბირთვიანი მიკროპროცესორის გამოყენების სახელმძღვანელო

ჩატვირთვის პროცესი
1. ჩატვირთვაში ჩართული პროგრამული უზრუნველყოფის კომპონენტები
  სისტემის ჩატვირთვის პროცესი მოიცავს შემდეგ პროგრამულ კომპონენტებს:
  - Hart Software Services (HSS): A zero-stage boot loader, სისტემის მონიტორი და აპლიკაციების გაშვების სერვისების მიმწოდებელი.
2. ჩატვირთვის ნაკადი
  სისტემის ჩატვირთვის ნაკადის თანმიმდევრობა შემდეგია:
  1. Hart Software Services (HSS) ინიცირება
  2. ჩამტვირთველის შესრულება
  3. აპლიკაციის გაშვება
დარაჯები
1. PIC64GX მცველი
  PIC64GX აღჭურვილია დამკვირვებლის ფუნქციით, რომელიც აკონტროლებს სისტემის მუშაობას და იწვევს მოქმედებებს სისტემის გაუმართაობის შემთხვევაში.
დაბლოკვის რეჟიმი
ჩაკეტვის რეჟიმი განკუთვნილია მომხმარებლებისთვის, რომლებიც საჭიროებენ სრულ კონტროლს სისტემის მოქმედებებზე ჩატვირთვის შემდეგ. ის ზღუდავს E51 სისტემის მონიტორის ფუნქციებს.

FAQ

Q: რა არის Hart Software Services (HSS) მიზანი?
პასუხი: HSS ემსახურება როგორც ნულოვანიtage boot loader, სისტემის მონიტორი და გაშვების სერვისების მიმწოდებელი აპლიკაციებისთვის ჩატვირთვის პროცესში.

კითხვა: როგორ მუშაობს PIC64GX დამკვირვებელი ფუნქცია?
პასუხი: PIC64GX მაკონტროლებელი აკონტროლებს სისტემის მუშაობას და შეუძლია განახორციელოს წინასწარ განსაზღვრული ქმედებები სისტემის გაუმართაობის შემთხვევაში, სისტემის საიმედოობის უზრუნველსაყოფად.

შესავალი

ეს თეთრი ქაღალდი განმარტავს, თუ როგორ ჩატვირთავს Microchip PIC64GX აპლიკაციის დატვირთვას და აღწერს სისტემის ჩატვირთვის პროცესს, რომელიც იგივე მუშაობს SMP-ისთვის და AMP დატვირთვები. გარდა ამისა, ის მოიცავს, თუ როგორ მუშაობს გადატვირთვა SMP-სთვის და AMP სამუშაო დატვირთვა, დარაჯები PIC64GX-ზე და სპეციალური ჩაკეტვის რეჟიმი სისტემებისთვის, სადაც მომხმარებელს სურს სრული კონტროლი, რათა შეზღუდოს E51 სისტემის მონიტორის მოქმედებები სისტემის ჩატვირთვის შემდეგ.

ჩატვირთვის პროცესი

მოდით გადავხედოთ სისტემის ჩატვირთვის პროცესში ჩართულ სხვადასხვა პროგრამულ კომპონენტს, რასაც მოჰყვება უფრო დეტალური მიმოხილვა თავად სისტემის ჩატვირთვის ნაკადის თანმიმდევრობის შესახებ.

ჩატვირთვაში ჩართული პროგრამული უზრუნველყოფის კომპონენტები
სისტემის ჩატვირთვის პროცესში ჩართულია შემდეგი კომპონენტები:

სურათი 1.1. ჩატვირთვის კომპონენტები

Hart Software Services (HSS)
Hart Software Services (HSS) არის ნულოვანიtage boot loader, სისტემის მონიტორი და აპლიკაციების გაშვების სერვისების მიმწოდებელი. HSS მხარს უჭერს სისტემის ადრეულ დაყენებას, DDR ტრენინგს და ტექნიკის ინიციალიზაციას/კონფიგურაციას. ის ძირითადად მუშაობს E51-ზე, მანქანური რეჟიმის ფუნქციონალობის მცირე რაოდენობა მუშაობს თითოეულ U54-ზე. ის ჩატვირთავს ერთ ან მეტ კონტექსტს აპლიკაციის „payload“ ჩატვირთვის საშუალებით და უზრუნველყოფს პლატფორმის Runtime Services/Supervisor Execution Environment (SEE) ოპერაციული სისტემის ბირთვებისთვის. იგი მხარს უჭერს უსაფრთხო ჩატვირთვას და არის მნიშვნელოვანი კომპონენტი ტექნიკის დაყოფის/გამოყოფის უზრუნველსაყოფად AMP კონტექსტებს.
Das U-Boot (U-Boot)
Das U-Boot (U-Boot) არის ღია კოდის უნივერსალური სკრიპტირებადი ჩამტვირთველი. იგი მხარს უჭერს მარტივ CLI-ს, რომელსაც შეუძლია ჩატვირთვის სურათის ამოღება სხვადასხვა წყაროდან (SD ბარათისა და ქსელის ჩათვლით). U-Boot იტვირთება Linux. საჭიროების შემთხვევაში მას შეუძლია უზრუნველყოს UEFI გარემო. ის, როგორც წესი, დასრულებულია და გამოდის, როგორც კი Linux ჩაიტვირთება – სხვა სიტყვებით რომ ვთქვათ, ის არ რჩება რეზიდენტი ჩატვირთვის შემდეგ.

Linux Kernel
Linux kernel არის მსოფლიოში ყველაზე პოპულარული ოპერაციული სისტემის ბირთვი. აპლიკაციების მომხმარებელთა ქვეყანასთან ერთად, ის ქმნის იმას, რასაც ჩვეულებრივ ლინუქსის ოპერაციულ სისტემას უწოდებენ. Linux ოპერაციული სისტემა უზრუნველყოფს მდიდარ POSIX API-ებს და დეველოპერის გარემოს, მაგample, ენები და ინსტრუმენტები, როგორიცაა Python, Perl, Tcl, Rust, C/C++ და Tcl; ბიბლიოთეკები, როგორიცაა OpenSSL, OpenCV, OpenMP, OPC/UA და OpenAMP (RPmsg და RemoteProc).
Yocto და Buildroot არიან Linux სისტემის შემქმნელები, ანუ მათი გამოყენება შესაძლებელია შეკვეთით მორგებული Linux სისტემების შესაქმნელად. Yocto გამოსცემს Linux დისტრიბუციას rich
აპლიკაციების, ხელსაწყოების და ბიბლიოთეკების ნაკრები და არჩევითი პაკეტის მართვა. Buildroot გამოსცემს უფრო მინიმალურ ფესვს fileსისტემა და შეუძლია მიზნად ისახავს სისტემებს, რომლებსაც არ სჭირდებათ მუდმივი შენახვა, მაგრამ მუშაობს მთლიანად RAM-დან (მაგალითად, Linux-ის ინიციალების მხარდაჭერის გამოყენებითampლე).
ზეფირი
Zephyr არის პატარა, ღია კოდის რეალურ დროში ოპერაციული სისტემა (RTOS). ის უზრუნველყოფს რეალურ დროში დაბალი ოვერჰედის ჩარჩოს, RPMsg-lite საკომუნიკაციო არხებით Linux-ში. იგი მოიცავს ბირთვს, ბიბლიოთეკებს, მოწყობილობის დრაივერებს, პროტოკოლის სტეკებს, fileსისტემები, მექანიზმები პროგრამული უზრუნველყოფის განახლებისთვის და ა.შ. და შესანიშნავია მომხმარებლებისთვის, რომლებსაც სურთ PIC64GX-ზე მეტი შიშველი ლითონის მსგავსი გამოცდილება.

ჩატვირთვის ნაკადი
PIC64GX მოიცავს RISC-V კორპლექსს 64-ბიტიანი E51 სისტემის მონიტორით და 4 64-ბიტიანი U54 აპლიკაციის ჰარტით. RISC-V ტერმინოლოგიაში, hart არის RISC-V შესრულების კონტექსტი, რომელიც შეიცავს რეგისტრების სრულ კომპლექტს და რომელიც ახორციელებს მის კოდს დამოუკიდებლად. თქვენ შეგიძლიათ წარმოიდგინოთ ეს, როგორც ტექნიკის ძაფი ან ერთი CPU. ურტების ჯგუფს ერთ ბირთვში ხშირად უწოდებენ კომპლექსს. ეს თემა აღწერს ნაბიჯებს PIC64GX კორეპლექსის ინიციალიზაციისთვის, მათ შორის E51 სისტემის მონიტორების გულისა და U54 აპლიკაციის ხაზების ჩათვლით.

ჩართეთ PIC64GX Coreplex.
ჩართვისას, RISC-V კორპლექსის ყველა ჰარტი იხსნება გადატვირთვისგან უსაფრთხოების კონტროლერის მიერ.

გაუშვით HSS კოდი ჩიპზე eNVM ფლეშ მეხსიერებიდან.
თავდაპირველად, თითოეული გული იწყებს HSS კოდის გაშვებას ჩიპზე eNVM ფლეშ მეხსიერებიდან. ეს კოდი აიძულებს ყველა U54 აპლიკაციის ჰარტის დატრიალებას, ინსტრუქციების მოლოდინში და საშუალებას აძლევს E51 მონიტორ ჰარტს დაიწყოს კოდის გაშვება სისტემის ინიციალიზაციისა და გამოტანის მიზნით.
HSS კოდის დეკომპრესია eNVM-დან L2-Scratch მეხსიერებამდე.
მისი შექმნის დროის კონფიგურაციიდან გამომდინარე, HSS ჩვეულებრივ უფრო დიდია, ვიდრე თავად eNVM ფლეშ მეხსიერების მოცულობა და ამიტომ პირველი, რასაც აკეთებს HSS კოდი, რომელიც მუშაობს E51-ზე, არის დეკომპრესია eNVM-დან L2-Scratch მეხსიერებაზე, როგორც ნაჩვენებია სურათზე. 1.2 და სურათი 1.3.
სურათი 1.2. HSS დეკომპრესირებულია eNVM-დან L2 Scratch-მდე
სურათი 1.3. HSS მეხსიერების რუკა დეკომპრესიის დროს

გადადით eNVM-დან L2-Scratch-ზე, როგორც ნაჩვენებია შემდეგ სურათზე.
სურათი 1.4. HSS გადახტება eNVM-დან ახლა კოდში L2Scratch-ში დეკომპრესიის შემდეგ
შესრულებადი შედგება სამი კომპონენტისგან:
- ტექნიკის აბსტრაქციის ფენა (HAL), დაბალი დონის კოდი და შიშველი ლითონის დრაივერები
- RISC-V OpenSBI-ის ადგილობრივი HSS ჩანგალი (ოდნავ შეცვლილია PIC64GX-ზე ზემოდან AMP მიზნები)
- HSS გაშვების სერვისები (სახელმწიფო მანქანები მუშაობს სუპერ მარყუჟში)
OpenSBI-ის მიერ გამოყენებული აპარატურის და მონაცემთა სტრუქტურების ინიციალიზაცია.
HSS სერვისი "გაშვება" პასუხისმგებელია ამ ინიციალიზაციაზე.
მიიღეთ აპლიკაციის დატვირთვის (payload.bin) სურათი გარე მეხსიერებიდან. ეს ნაჩვენებია სურათზე 1.5 და სურათზე 1.6
მნიშვნელოვანია: PIC64GX Curiosity Kit-ის შემთხვევაში, ეს იქნება SD ბარათიდან.
სურათი 1.5. payload.bin სამუშაო დატვირთვის სურათის მიღება გარე მეხსიერებიდან
სურათი 1.6. HSS მეხსიერების რუკა payload.bin-ის მიღების შემდეგ
დააკოპირეთ სხვადასხვა სექციები payload.bin-დან მათი შესრულების დროის დანიშნულებამდე. payload.bin არის ფორმატირებული სურათი, რომელიც აერთიანებს სხვადასხვა აპლიკაციის სურათებს SMP ან AMP დატვირთვები. იგი მოიცავს კოდს, მონაცემებს და აღწერის ცხრილებს, რომლებიც საშუალებას აძლევს HSS-ს სათანადოდ მოათავსოს კოდი და მონაცემთა სექციები, სადაც ისინი საჭიროა სხვადასხვა აპლიკაციის დატვირთვის გასაშვებად.
სურათი 1.7. payload.bin კოპირებულია დანიშნულების მისამართებში
დაავალეთ შესაბამის U54-ებს გადახტეს მათი შესრულების დაწყების მისამართებზე. ეს საწყისი მისამართის ინფორმაცია შეიცავს payload.bin-ში.
დაიწყეთ U54 აპლიკაციის ხაზები და ნებისმიერი წამიtage boot loaders. მაგampასევე, U-Boot აჩენს Linux-ს.

გადატვირთვა

სისტემის ჩატვირთვის კონცეფციასთან დაკავშირებულია გადატვირთვის საჭიროება. PIC64GX აპლიკაციის დატვირთვაზე ფიქრისას, გადატვირთვამ უნდა გაითვალისწინოს როგორც სიმეტრიული მრავალპროცესირება (SMP) ასევე ასიმეტრიული მრავალპროცესირება (AMP) სცენარები:

SMP სისტემის შემთხვევაში, გადატვირთვამ შეიძლება უსაფრთხოდ გადატვირთოს მთელი სისტემა, რადგან სხვა კონტექსტში დამატებითი დატვირთვები არ არის გასათვალისწინებელი.
იმ შემთხვევაში, თუ ა AMP სისტემაში, სამუშაო დატვირთვას შეიძლება მიეცეს მხოლოდ გადატვირთვის უფლება (და არ ჩაერიოს სხვა კონტექსტში), ან შეიძლება ჰქონდეს პრივილეგია, რომ შეძლოს სისტემის სრული გადატვირთვა.

გადატვირთეთ და AMP
SMP-ის გასააქტიურებლად და AMP გადატვირთვის სცენარებში, HSS მხარს უჭერს თბილი და ცივი გადატვირთვის პრივილეგიების ცნებებს, რომლებიც მიეკუთვნება კონტექსტს. თბილი გადატვირთვის პრივილეგიის მქონე კონტექსტს შეუძლია მხოლოდ საკუთარი თავის გადატვირთვა, ხოლო ცივი გადატვირთვის პრივილეგიის მქონე კონტექსტს შეუძლია განახორციელოს სისტემის სრული გადატვირთვა. მაგampგანიხილეთ წარმომადგენლობითი სცენარების შემდეგი ნაკრები.

ერთი კონტექსტური SMP დატვირთვა, რომელსაც შეუძლია მოითხოვოს სისტემის სრული გადატვირთვა
ამ სცენარში, კონტექსტს აქვს ცივი გადატვირთვის პრივილეგია.
ორი კონტექსტი AMP სამუშაო დატვირთვა, სადაც A კონტექსტს უფლება აქვს მოითხოვოს სისტემის სრული გადატვირთვა (რომელიც გავლენას ახდენს ყველა კონტექსტზე), ხოლო კონტექსტ B-ს უფლება აქვს მხოლოდ გადატვირთოს.
ამ სცენარში, კონტექსტში A ნებადართულია ცივი გადატვირთვის პრივილეგიით, ხოლო B კონტექსტში დაშვებულია თბილი გადატვირთვის პრივილეგია.

ორი კონტექსტი AMP დატვირთვა, სადაც A და B კონტექსტებს მხოლოდ საკუთარი თავის გადატვირთვის უფლება აქვთ (და არ იმოქმედებენ სხვა კონტექსტზე)
ამ სცენარში ორივე კონტექსტში დაშვებულია მხოლოდ თბილი გადატვირთვის პრივილეგიები.
ორი კონტექსტი AMP სამუშაო დატვირთვა, სადაც A და B კონტექსტებს უფლება აქვთ მოითხოვონ სისტემის სრული გადატვირთვა

ამ სცენარში ორივე კონტექსტს აქვს ცივი გადატვირთვის პრივილეგიები.
გარდა ამისა, შესაძლებელია HSS-მა აშენების დროს ყოველთვის დაუშვას ცივი გადატვირთვის პრივილეგია და არასოდეს დაუშვას ცივი გადატვირთვის პრივილეგია.

შესაბამისი HSS Kconfig პარამეტრები
Kconfig არის პროგრამული უზრუნველყოფის კონფიგურაციის სისტემა. ის ჩვეულებრივ გამოიყენება მშენებლობის დროის პარამეტრების შესარჩევად და ფუნქციების ჩართვის ან გამორთვისთვის. ის წარმოიშვა Linux-ის ბირთვით, მაგრამ ახლა გამოიყენებოდა Linux-ის ბირთვის მიღმა სხვა პროექტებში, მათ შორის U-Boot, Zephyr და PIC64GX HSS.

HSS შეიცავს ორ Kconfig ვარიანტს, რომლებიც აკონტროლებენ გადატვირთვის ფუნქციას HSS პერსპექტივიდან:

CONFIG_ALLOW_COLD გადატვირთვა
თუ ეს ჩართულია, ის გლობალურად საშუალებას აძლევს კონტექსტს გაუშვას ცივი გადატვირთვის გამოძახება. თუ გამორთულია, ნებადართული იქნება მხოლოდ თბილი გადატვირთვა. გარდა ამ პარამეტრის ჩართვისა, ცივი გადატვირთვის ნებართვა უნდა მიენიჭოს კონტექსტს YAML დატვირთვის გენერატორის მეშვეობით. file ან შემდეგი Kconfig ვარიანტი.
CONFIG_ALLOW_COLD REBOOT_ALWAYS
- თუ ჩართულია, ეს ფუნქცია გლობალურად საშუალებას აძლევს ყველა კონტექსტს გაუშვას ცივი გადატვირთვა ECAA, მიუხედავად payload.bin დროშის უფლებებისა.
- გარდა ამისა, თავად payload.bin შეიძლება შეიცავდეს თითო კონტექსტის დროშას, რაც მიუთითებს იმაზე, რომ კონკრეტულ კონტექსტს უფლება აქვს გაუშვას ცივი გადატვირთვები:
  - კონტექსტური თბილი გადატვირთვის სხვა კონტექსტის დასაშვებად, შეგვიძლია დავამატოთ ოფცია დაშვება-გადატვირთვა: თბილი YAML აღწერილობაში file გამოიყენება payload.bin-ის შესაქმნელად
  - მთელი სისტემის კონტექსტური ცივი გადატვირთვის დასაშვებად, ჩვენ შეგვიძლია დავამატოთ ვარიანტი დაშვება-გადატვირთვა: ცივი. ნაგულისხმევად, დაშვება-გადატვირთვის მითითების გარეშე, კონტექსტს ნებადართულია მხოლოდ თბილი გადატვირთვა, ამ დროშის პარამეტრის მიუხედავად, თუ CONFIG_ALLOW_COLDREBOOT ჩართული არ არის HSS-ში, HSS გადაამუშავებს ყველა ცივი გადატვირთვის მოთხოვნას თბილი (კონტექსტის მიხედვით) გადატვირთვაზე. .

გადატვირთეთ დეტალურად
ეს განყოფილება დეტალურად აღწერს, თუ როგორ მუშაობს გადატვირთვა – დაწყებული OpenSBI ფენით (ყველაზე დაბალი M-რეჟის ფენა) და შემდეგ განიხილება, თუ როგორ ხდება ამ OpenSBI ფენის ფუნქციონირების ჩართვა RTOS აპლიკაციიდან ან მდიდარი OS-დან, როგორიცაა Linux.

OpenSBI Reboot ecall

RISC-V Supervisor Binary Interface (SBI) სპეციფიკაცია აღწერს სტანდარტიზებულ ტექნიკის აბსტრაქციის ფენას პლატფორმის ინიციალიზაციისა და firmware გაშვების სერვისებისთვის. SBI-ის მთავარი მიზანია უზრუნველყოს პორტაბელურობა და თავსებადობა სხვადასხვა RISC-V დანერგვაში.
OpenSBI (Open Source Supervisor Binary Interface) არის ღია კოდის პროექტი, რომელიც უზრუნველყოფს SBI სპეციფიკაციის მითითების განხორციელებას. OpenSBI ასევე გთავაზობთ გაშვების სერვისებს, მათ შორის შეფერხების მართვას, ტაიმერის მართვას და კონსოლის I/O-ს, რომელთა გამოყენება შესაძლებელია უფრო მაღალი დონის პროგრამული ფენების მიერ.
OpenSBI შედის HSS-ის ნაწილად და მუშაობს Machine Mode დონეზე. როდესაც ოპერაციული სისტემა ან აპლიკაცია იწვევს ხაფანგს, ის გადაეცემა OpenSBI-ს მის დასამუშავებლად. OpenSBI ავლენს გარკვეული სისტემური ზარის ტიპის ფუნქციონირებას პროგრამული უზრუნველყოფის ზედა ფენებზე კონკრეტული ხაფანგის მექანიზმის საშუალებით, რომელსაც ეწოდება ecall.

სისტემის გადატვირთვა (EID 0x53525354) უზრუნველყოფს სისტემის ზარის ყოვლისმომცველ ფუნქციას, რომელიც საშუალებას აძლევს ზედა ფენის პროგრამულ უზრუნველყოფას მოითხოვოს სისტემის დონის გადატვირთვა ან გამორთვა. როგორც კი ეს გამოძახება გამოიძახება U54-ის მიერ, ის იკავებს HSS პროგრამულ უზრუნველყოფას, რომელიც მუშაობს მანქანურ რეჟიმში ამ U54-ზე და შესაბამისი გადატვირთვის მოთხოვნა ეგზავნება E51-ს კონტექსტის ან მთელი სისტემის გადატვირთვის მიზნით, ეს დამოკიდებულია უფლებებზე. კონტექსტი.

დამატებითი ინფორმაციისთვის იხილეთ RISC-V ზედამხედველის ორობითი ინტერფეისის სპეციფიკაცია განსაკუთრებით სისტემის გადატვირთვის გაფართოება (EID #0x53525354 „SRST“).

Linux გადატვირთვა

როგორც კონკრეტული ყოფილიampაქედან გამომდინარე, Linux-ში, გამორთვის ბრძანება გამოიყენება სისტემის შესაჩერებლად ან გადატვირთვისთვის. ბრძანებას, როგორც წესი, აქვს მრავალი მეტსახელი, კერძოდ, შეჩერება, გამორთვა და გადატვირთვა. ეს ფსევდონიმები აკონკრეტებს, შეაჩეროს მანქანა გამორთვისას, გამორთოს მანქანა გამორთვისას, ან გადატვირთოს მანქანა გამორთვისას.

მომხმარებლის სივრცის ეს ბრძანებები აგზავნის სისტემის გადატვირთვის ზარს Linux-ზე, რომელიც ჩაკეტილია ბირთვის მიერ და ურთიერთდაკავშირებულია SBI-ის გამოძახებაზე.
არსებობს გადატვირთვის სხვადასხვა დონე - REBOOT_WARM, REBOOT_COLD, REBOOT_HARD - ეს შეიძლება გადავიდეს როგორც ბრძანების ხაზის არგუმენტები ბირთვში (მაგ.ample, reboot=w[arm] for REBOOT_WARM). Linux-ის ბირთვის წყაროს კოდის შესახებ დამატებითი ინფორმაციისთვის იხ Documentation/admin-guide/kernel-paramters.txt.

ალტერნატიულად, თუ /sys/kernel/reboot ჩართულია, ქვემოთ მოცემული დამმუშავებლები შეიძლება წაიკითხონ სისტემის გადატვირთვის მიმდინარე კონფიგურაციის მისაღებად და დაწერონ მის შესაცვლელად. Linux-ის ბირთვის წყაროს კოდის შესახებ დამატებითი ინფორმაციისთვის იხ დოკუმენტაცია/ABI/ტესტირება/sysfs-kernel-გადატვირთვა.

დარაჯები

შემდგომი კონცეფცია, რომელიც დაკავშირებულია სისტემის ჩატვირთვასთან და სისტემის გადატვირთვასთან, არის სისტემის აღდგენა დამკვირვებლის ტაიმერის გაშვების შემდეგ. Watchdog ქრონომეტრები ფართოდ გამოიყენება ჩაშენებულ სისტემებში, რათა ავტომატურად აღდგეს გარდამავალი ტექნიკის გაუმართაობისგან და თავიდან აიცილოს არასწორი ან მავნე პროგრამული უზრუნველყოფის სისტემის მუშაობის შეფერხება.
PIC64GX მოიცავს ტექნიკის დამკვირვებლის მხარდაჭერას, რათა მონიტორინგი გაუწიოს ცალკეულ ჰარტებს, როდესაც სისტემა მუშაობს. მეთვალყურეები უზრუნველყოფენ ჰარტების გადატვირთვას, თუ ისინი არ პასუხობენ პროგრამული უზრუნველყოფის გამოუსწორებელი შეცდომების გამო.

PIC64GX მოიცავს ხუთ ინსტანციას მაკონტროლებელი ტაიმერის ტექნიკის ბლოკისთვის, რომლებიც გამოიყენება სისტემის ჩაკეტვის გამოსავლენად - თითო ყოველი ჰარტისთვის. შერეული ასიმეტრიული მრავალპროცესის გასაადვილებლად (AMP) დატვირთვა, HSS მხარს უჭერს მონიტორინგს და რეაგირებას მცველის სროლაზე.

PIC64GX მცველი

HSS პასუხისმგებელია აპლიკაციის ჰარტების ჩატვირთვაზე ჩართვისას და მათ ხელახლა ჩატვირთვაზე (ინდივიდუალურად თუ ერთობლივად) ნებისმიერ დროს.tagე, საჭირო იქნება თუ სასურველი. ამის შედეგად, PIC64GX-ზე დაკვირვების მოვლენებზე რეაგირებას ახორციელებს HSS.

„ვირტუალური დამკვირვებელი“ მონიტორი დანერგილია როგორც HSS სახელმწიფო აპარატის სერვისი და მისი მოვალეობებია U54 ინდივიდუალური დამკვირვებლის აპარატურის მონიტორის სტატუსის მონიტორინგი. როდესაც ერთ-ერთი U54 მცველი მოგზაურობს, HSS აღმოაჩენს ამას და გადატვირთავს U54-ს, საჭიროებისამებრ. თუ U54 არის SMP კონტექსტის ნაწილი, მთელი კონტექსტი განიხილება გადატვირთვისთვის, იმის გათვალისწინებით, რომ კონტექსტს აქვს თბილი გადატვირთვის პრივილეგია. მთელი სისტემა გადაიტვირთება, თუ კონტექსტს აქვს ცივი გადატვირთვის პრივილეგია.

შესაბამისი Kconfig პარამეტრები

Watchdog-ის მხარდაჭერა ნაგულისხმევად შედის გამოშვებულ HSS-ში. თუ გსურთ შექმნათ მორგებული HSS, ეს განყოფილება აღწერს კონფიგურაციის მექანიზმს, რათა უზრუნველყოს Watchdog-ის მხარდაჭერა.

HSS კონფიგურებულია Kconfig კონფიგურაციის სისტემის გამოყენებით. უმაღლესი დონის .config file საჭიროა აირჩიოთ ის სერვისები, რომლებიც შედგენილი იქნება HSS-ში ან მის გარეთ.
პირველ რიგში, უნდა ჩართოთ უმაღლესი დონის CONFIG_SERVICE_WDOG ვარიანტი („ვირტუალური დამკვირვებლის მხარდაჭერა“ make config-ის მეშვეობით).

შემდეგ გამოაშკარავდება შემდეგი ქვეოფციები, რომლებიც დამოკიდებულია Watchdog-ის მხარდაჭერაზე:

CONFIG_SERVICE_WD OG_DEBUG
ჩართავს საინფორმაციო/გამართვის შეტყობინებების მხარდაჭერას ვირტუალური დამკვირვებლის სერვისიდან.
CONFIG_SERVICE_WD OG_DEBUG_TIMEOUT_SECS
განსაზღვრავს პერიოდულობას (წამებში), რომლითაც Watchdog-ის გამართვის შეტყობინებები გამოვა HSS-ის მიერ.
CONFIG_SERVICE_WD OG_ENABLE_E51
ააქტიურებს E51-ის გულის მონიტორს U54-ის გარდა, იცავს თავად HSS-ის მუშაობას.

როდესაც E51 watchdog ჩართულია, HSS პერიოდულად წერს Watchdog-ს, რათა განაახლოს იგი და თავიდან აიცილოს გასროლა. თუ რაიმე მიზეზის გამო, E51 გული იკეტება ან დაეჯახა და E51 დამკვირვებელი ჩართულია, ეს ყოველთვის გადაიტვირთება მთელ სისტემას.

დარაჯის ოპერაცია
მაკონტროლებელი აპარატურა ახორციელებს ქვემოთ მრიცხველებს. განახლების აკრძალული ფანჯრის შექმნა შესაძლებელია დამკვირვებლის მაქსიმალური მნიშვნელობის კონფიგურაციით, რომლის მიხედვითაც ნებადართულია განახლება (MVRP).

როდესაც დამკვირვებლის ტაიმერის მიმდინარე მნიშვნელობა მეტია MVRP მნიშვნელობაზე, დამკვირვებლის განახლება აკრძალულია. აკრძალულ ფანჯარაში დამკვირვებლის ტაიმერის განახლების მცდელობა დაადასტურებს დროის ამოწურვის შეფერხებას.

დამკვირვებლის განახლება MVRP მნიშვნელობასა და ტრიგერის მნიშვნელობას შორის (TRIG) წარმატებით განაახლებს მრიცხველს და ხელს შეუშლის დამკვირვებლის გასროლას.
მას შემდეგ, რაც დამკვირვებლის ტაიმერის მნიშვნელობა დაითვლება TRIG მნიშვნელობის ქვემოთ, დამკვირვებელი იმუშავებს.

მცველი სახელმწიფო მანქანა

მაკონტროლებელი მდგომარეობის მანქანა ძალიან მარტივია - იწყება E51-ისთვის დამკვირვებლის კონფიგურაციით, თუ ჩართულია, შემდეგ უმოქმედო მდგომარეობაში გადადის მონიტორინგზე. ყოველ ჯერზე superloop-ის გარშემო, ხდება მონიტორინგის ეს მდგომარეობა, რომელიც ამოწმებს U54-ის თითოეული მცველის სტატუსს.
დამკვირვებელი სახელმწიფო მანქანა ურთიერთქმედებს ჩატვირთვის მდგომარეობის მანქანასთან, რათა გადატვირთოს ჰარტი (და ნებისმიერი სხვა ჰარტი, რომელიც მის ჩატვირთვის კომპლექტშია), თუ აღმოაჩენს, რომ ჰარტმა ვერ მოახერხა თავისი მცველის დროულად განახლება.

დაბლოკვის რეჟიმი

ჩვეულებრივ (განსაკუთრებით AMP აპლიკაციები), მოსალოდნელია, რომ HSS დარჩება რეზიდენტი M-რეჟიმში, U54-ზე, რათა დაუშვას თითო კონტექსტური გადატვირთვა (ანუ გადატვირთეთ მხოლოდ ერთი კონტექსტი, სრული ჩიპის გადატვირთვის გარეშე) და მისცეს HSS-ს საშუალება, გააკონტროლოს ჯანმრთელობა ( ECC, ჩაკეტვის სტატუსის ბიტები, ავტობუსის შეცდომები, SBI შეცდომები, PMP დარღვევები და ა.შ.).

იმისათვის, რომ უზრუნველყოს გადატვირთვის შესაძლებლობები თითოეულAMP კონტექსტური საფუძველზე (მთელი სისტემის გადატვირთვის მოთხოვნის გარეშე), E51 ჩვეულებრივ აქვს მეხსიერების პრივილეგირებული წვდომა სისტემის მთელ მეხსიერების სივრცეში. თუმცა, შეიძლება იყოს სიტუაციები, როდესაც ეს არ არის სასურველი და მომხმარებელს შეუძლია შეზღუდოს ის, რასაც აკეთებს E51 HSS firmware, როდესაც სისტემა წარმატებით ჩაიტვირთება. ამ შემთხვევაში, შესაძლებელია HSS-ის დაბლოკვის რეჟიმში გადაყვანა U54 Application Harts-ის ჩატვირთვის შემდეგ.
ამის ჩართვა შესაძლებელია HSS Kconfig პარამეტრის CONFIG_SERVICE_LOCKDOWN-ის გამოყენებით.

ჩაკეტვის სერვისი მიზნად ისახავს დაუშვას HSS-ის აქტივობების შეზღუდვა მას შემდეგ, რაც ის ჩაიტვირთება U54 აპლიკაცია Harts.

სურათი 4.2. HSS ჩაკეტვის რეჟიმი

ჩაკეტვის რეჟიმის დაწყების შემდეგ, ის აჩერებს ყველა სხვა HSS სერვისის სახელმწიფო აპარატის მუშაობას. ის უწოდებს ორ სუსტად შეკრულ ფუნქციას:

e51_pmp_lockdown(), და
e51_lockdown()

ეს ფუნქციები მიზნად ისახავს გადალახოს დაფის სპეციფიკური კოდით. პირველი არის კონფიგურირებადი ტრიგერის ფუნქცია, რომელიც საშუალებას აძლევს BSP-ს მოარგოს E51-ის დაბლოკვა აპლიკაციის დატვირთვიდან ამ ეტაპზე. ამ ფუნქციის სუსტად შეკრული ნაგულისხმევი განხორციელება ცარიელია. მეორე არის ფუნქციონალობა, რომელიც გაშვებულია ამ წერტილიდან წინ. სუსტად შეკრული ნაგულისხმევი იმპლემენტაცია ემსახურება დამკვირვებელს E51-ის ამ ეტაპზე და გადაიტვირთება, თუ U54 დამკვირვებელი გააქტიურდება. დამატებითი ინფორმაციისთვის იხილეთ HSS წყაროს კოდი სერვისებში/lockdown/lockdown_service.c file.

დანართი

HSS payload.bin ფორმატი

ეს განყოფილება აღწერს payload.bin file ფორმატი და გამოსახულება, რომელსაც იყენებს HSS PIC64GX SMP ჩატვირთვისთვის და AMP აპლიკაციები.

payload.bin არის ფორმატირებული ორობითი (სურათი A.10), რომელიც შედგება ხელმძღვანელის, სხვადასხვა აღწერის ცხრილებისა და სხვადასხვა ნაწილებისგან, რომლებიც შეიცავს აპლიკაციის დატვირთვის თითოეული ნაწილის კოდს და მონაცემთა განყოფილებებს. ბლოკი შეიძლება ჩაითვალოს მეხსიერების თვითნებური ზომის მიმდებარე ბლოკად.

სურათი A.10. payload.bin ფორმატი

სათაურის ნაწილი (ასახულია სურათზე A.11) შეიცავს ჯადოსნურ მნიშვნელობას, რომელიც გამოიყენება payload.bin-ის და ზოგიერთი საყოფაცხოვრებო ინფორმაციის იდენტიფიცირებისთვის, იმ სურათის დეტალებთან ერთად, რომელიც განკუთვნილია თითოეულზე.
U54 განაცხადის კოდები. იგი აღწერს, თუ როგორ უნდა ჩატვირთოთ თითოეული ინდივიდუალური U54 ჰარტი და მთლიანობაში ჩამტვირთავი სურათების ნაკრები. საყოფაცხოვრებო ინფორმაციაში მას აქვს მითითებები აღწერის სხვადასხვა ცხრილებისკენ, რათა მოხდეს სათაურის ზომის გაზრდა.

სურათი A.11. payload.bin Header

კოდი და ინიციალიზებული მუდმივი მონაცემები განიხილება მხოლოდ წაკითხვად და ინახება მხოლოდ წაკითხვის განყოფილებაში, რომელზეც მითითებულია სათაურის აღმწერები.
არა-ნულოვანი ინიციალიზებული მონაცემების ცვლადები არის წაკითხვა-ჩაწერის მონაცემები, მაგრამ მათი ინიციალიზაციის მნიშვნელობები კოპირებულია მხოლოდ წაკითხვის ნაწილიდან გაშვებისას. ისინი ასევე ინახება მხოლოდ წაკითხვის განყოფილებაში.
მხოლოდ წაკითხვადი დატვირთვის მონაცემთა განყოფილება აღწერილია კოდისა და მონაცემთა ნაწილის აღწერების ცხრილით. ამ ცხრილის თითოეული ნაწილის აღმწერი შეიცავს „ჰარტის მფლობელს“ (მთავარი ჰარტის კონტექსტში, სადაც ის არის გამიზნული
at), დატვირთვის ოფსეტი (ოფსეტი payload.bin-ში) და შესრულების მისამართი (დანიშნულების მისამართი PIC64GX მეხსიერებაში), ზომასა და საკონტროლო ჯამთან ერთად. ეს ნაჩვენებია სურათზე A.12.

სურათი A.12. მხოლოდ წაკითხვადი ნაწილის აღმწერი და ანაზღაურებადი ნაწილის მონაცემები

ზემოაღნიშნული ნაწილების გარდა, ასევე არის მეხსიერების ნაწილაკები, რომლებიც შეესაბამება მონაცემთა ცვლადებს, რომლებიც ინიციალიზებულია ნულამდე. ეს მონაცემები არ ინახება payload.bin-ში, არამედ არის ნულოვანი ინიციალიზებული ნაწილის აღწერების სპეციალური ნაკრები, რომელიც განსაზღვრავს RAM-ის მისამართს და სიგრძეს, რომელიც უნდა დაყენდეს ნულზე გაშვების დროს. ეს ნაჩვენებია სურათზე A.13.

სურათი A.13. ZI ჩანგები

hss-payload-generator
HSS Payload Generator ინსტრუმენტი ქმნის ფორმატირებულ დატვირთვის სურათს Hart Software Service zero-s-ისთვისtage bootloader PIC64GX-ზე, კონფიგურაციის გათვალისწინებით file და კომპლექტი ELF files და/ან ბინარები. კონფიგურაცია file გამოიყენება ELF ორობითი ან ორობითი ბლომების ცალკეული აპლიკაციის ჰარტებზე (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 ელიფსური მრუდის P-509 (SECP384r384) X.1 პირადი გასაღების ადგილმდებარეობის დასაზუსტებლად:
$ ./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 წყაროს სურათებს შეუძლიათ მიუთითონ შესვლის წერტილი, მაგრამ ჩვენ გვსურს, რომ საჭიროების შემთხვევაში შევინარჩუნოთ მეორადი შესვლის წერტილები ჰარტებისთვის, მაგ.ampმაგალითად, თუ რამდენიმე ჰარტი განკუთვნილია ერთი და იგივე სურათის ჩატვირთვისთვის, მათ შეიძლება ჰქონდეთ ინდივიდუალური შესვლის წერტილები. ამის მხარდასაჭერად, ჩვენ ვაკონფიგურირებთ შესვლის წერტილის მისამართებს კონფიგურაციაში file თავად.

ახლა ჩვენ შეგვიძლია განვსაზღვროთ გარკვეული დატვირთვა (წყარო ELF files, ან ორობითი blobs), რომლებიც განთავსდება გარკვეულ რეგიონებში მეხსიერებაში. დატვირთვის განყოფილება განისაზღვრება საკვანძო სიტყვით payloads, შემდეგ კი რამდენიმე ინდივიდუალური დატვირთვის აღწერით. თითოეულ დატვირთვას აქვს სახელი (გზა მისკენ file), მფლობელი-ჰარტი და სურვილისამებრ 1-დან 3 მეორადი ჰარტი.

გარდა ამისა, დატვირთვას აქვს პრივილეგიური რეჟიმი, რომელშიც ის დაიწყებს შესრულებას. მოქმედი პრივილეგიის რეჟიმებია PRV_M, PRV_S და PRV_U, სადაც ისინი განისაზღვრება როგორც:

PRV_M მანქანის რეჟიმი

PRV_S ზედამხედველის რეჟიმი
PRV_U მომხმარებლის რეჟიმი

შემდეგში ეგampლე:

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 ორობითს უმატებს მოწყობილობის ხეს.

აქ არის ყოფილიample Payloads კონფიგურაცია file:

test/zephyr.elf:
{exec-addr: '0xB0000000', მფლობელი-hart: u54_3, პირადი რეჟიმი: prv_m, skip-opensbi: true}
test/u-boot-dtb.bin:
{exec-addr: '0x80200000', მფლობელი-hart: u54_1, მეორადი-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-ით, ოფცია skip-opens, თუ ეს მართალია, გამოიწვევს ამ გულზე დატვირთვის გამოძახებას მარტივი mret-ის გამოყენებით.
ვიდრე OpenSBI sbi_init() ზარი. ეს ნიშნავს, რომ გული დაიწყებს შიშველი მეტალის კოდის გაშვებას, მიუხედავად ნებისმიერი OpenSBI HSM მოსაზრებებისა. გაითვალისწინეთ, რომ ეს ასევე ნიშნავს, რომ გული ვერ გამოიყენებს
მოუწოდებს გამოიძახონ OpenSBI ფუნქციონალობა. გამოტოვება-გახსნის ვარიანტი არჩევითია და ნაგულისხმევად არის false.
სხვა კონტექსტის კონტექსტური თბილი გადატვირთვის დასაშვებად, ჩვენ შეგვიძლია დავამატოთ ვარიანტი დაშვების გადატვირთვა: თბილი. მთელი სისტემის კონტექსტური ცივი გადატვირთვის დასაშვებად, ჩვენ შეგვიძლია დავამატოთ ვარიანტი დაშვება-გადატვირთვა: ცივი. ნაგულისხმევად, დაშვება-გადატვირთვის მითითების გარეშე, კონტექსტს მხოლოდ თავად შეუძლია თბილი გადატვირთვა.

ასევე შესაძლებელია დამხმარე მონაცემების დაკავშირება თითოეულ დატვირთვასთან, მაგample, DeviceTree Blob (DTB) file, დამხმარე მონაცემების მითითებით fileდაასახელეთ შემდეგნაირად:
test/u-boot.bin: { exec-addr: '0x80200000', მფლობელი-ჰარტი: u54_1, მეორადი-ჰარტი: u54_2, მეორადი-ჰარტი: u54_3, მეორადი-ჰარტი: u54_4, პირადი რეჟიმი: prv_s, დამხმარე-მონაცემები : test/pic64gx.dtb }
ეს დამხმარე მონაცემები შედის ტვირთამწეობაში (მოთავსებულია უშუალოდ ძირითადის შემდეგ file შესრულებადში
space), და მისი მისამართი გადაეცემა OpenSBI-ს next_arg1 ველში ($a1 რეესტრში გადაეცემა სურათს ჩატვირთვის დროს).
იმისათვის, რომ თავიდან აიცილოთ HSS კონტექსტის ავტომატურად ჩატვირთვა (მაგალითად, თუ ამის ნაცვლად გვსურს ამის კონტროლის დელეგირება კონტექსტზე remoteProc-ის გამოყენებით), გამოიყენეთ skip-autoboot flag:
test/zephyr.elf: {exec-addr: '0xB0000000', მფლობელი-hart: u54_3, priv-mode: prv_m, skip-opensbi: true, skip-autoboot: true}

დაბოლოს, ჩვენ შეგვიძლია სურვილისამებრ გადავცვალოთ ცალკეული ტვირთის სახელები payload-name ოფციის გამოყენებით. მაგampლე:
test/u-boot.bin: { exec-addr: '0x80200000', მფლობელი-ჰარტი: u54_1, მეორადი-ჰარტი: u54_2, მეორადი-ჰარტი: u54_3, მეორადი-ჰარტი: u54_4, პირადი რეჟიმი: prv_s, დამხმარე-მონაცემები : test/pic64gx.dtb, payload-name: 'u-boot' }

გაითვალისწინეთ, რომ Yocto და Buildroot Linux-ის შემქმნელები შექმნიან, დააკონფიგურირებენ და აწარმოებენ hss-payload-ს.
გენერატორი, როგორც საჭიროა განაცხადის სურათების გენერირებისთვის. გარდა ამისა, pic64gx-curiosity-kit-amp მანქანა სამიზნე Yocto-ში შექმნის აპლიკაციის სურათს hss-payload-generator ინსტრუმენტის გამოყენებით, რომელიც აჩვენებს AMP, Linux მუშაობს 3 ჰარტზე და Zephyr მუშაობს 1 ჰარტზე.

გადასინჯვის ისტორია
გადასინჯვის ისტორია აღწერს ცვლილებებს, რომლებიც განხორციელდა დოკუმენტში. ცვლილებები ჩამოთვლილია გადასინჯვით, დაწყებული უახლესი პუბლიკაციით.

რევიზია	თარიღი	აღწერა
A	07/2024	საწყისი რევიზია

მიკროჩიპის ინფორმაცია

მიკროჩიპი Webსაიტი
მიკროჩიპი გთავაზობთ ონლაინ მხარდაჭერას ჩვენი საშუალებით webსაიტი ზე www.microchip.com/. ეს webსაიტი გამოიყენება დასამზადებლად files და ინფორმაცია ადვილად ხელმისაწვდომი მომხმარებლებისთვის. ზოგიერთი ხელმისაწვდომი შინაარსი მოიცავს:

პროდუქტის მხარდაჭერა – მონაცემთა ცხრილები და შეცდომები, განაცხადის შენიშვნები და სampპროგრამები, დიზაინის რესურსები, მომხმარებლის სახელმძღვანელოები და ტექნიკის მხარდაჭერის დოკუმენტები, უახლესი პროგრამული უზრუნველყოფის გამოშვებები და დაარქივებული პროგრამული უზრუნველყოფა
ზოგადი ტექნიკური მხარდაჭერა – ხშირად დასმული კითხვები (FAQs), ტექნიკური მხარდაჭერის მოთხოვნები, ონლაინ სადისკუსიო ჯგუფები, მიკროჩიპის დიზაინის პარტნიორი პროგრამის წევრების სია
მიკროჩიპის ბიზნესი – პროდუქტის ამომრჩეველი და შეკვეთის სახელმძღვანელო, მიკროჩიპის უახლესი პრეს რელიზები, სემინარების და ღონისძიებების ჩამონათვალი, მიკროჩიპების გაყიდვების ოფისების, დისტრიბუტორებისა და ქარხნის წარმომადგენლების ჩამონათვალი

პროდუქტის ცვლილების შეტყობინების სერვისი

Microchip-ის პროდუქტის ცვლილების შეტყობინებების სერვისი ეხმარება კლიენტებს მიკროჩიპის პროდუქტებზე არსებული ინფორმაცია. აბონენტები მიიღებენ შეტყობინებას ელფოსტით, როდესაც არის ცვლილებები, განახლებები, გადასინჯვები ან შეცდომები, რომლებიც დაკავშირებულია კონკრეტულ პროდუქტის ოჯახთან ან განვითარების ხელსაწყოებთან.
რეგისტრაციისთვის გადადით www.microchip.com/pcn და მიჰყევით რეგისტრაციის ინსტრუქციას.

მომხმარებელთა მხარდაჭერა
Microchip-ის პროდუქტების მომხმარებლებს შეუძლიათ მიიღონ დახმარება რამდენიმე არხით:

დისტრიბუტორი ან წარმომადგენელი
ადგილობრივი გაყიდვების ოფისი
ჩაშენებული გადაწყვეტილებების ინჟინერი (ESE)
ტექნიკური მხარდაჭერა

კლიენტებმა მხარდაჭერისთვის უნდა დაუკავშირდნენ თავიანთ დისტრიბუტორს, წარმომადგენელს ან ESE-ს. ადგილობრივი გაყიდვების ოფისები ასევე ხელმისაწვდომია მომხმარებლების დასახმარებლად. ამ დოკუმენტში შედის გაყიდვების ოფისებისა და მდებარეობების ჩამონათვალი.
ტექნიკური მხარდაჭერა ხელმისაწვდომია მეშვეობით webსაიტი: www.microchip.com/support.

მიკროჩიპური მოწყობილობების კოდის დაცვის ფუნქცია
გაითვალისწინეთ კოდის დაცვის ფუნქციის შემდეგი დეტალები მიკროჩიპის პროდუქტებზე:

მიკროჩიპის პროდუქტები აკმაყოფილებს სპეციფიკაციებს, რომლებიც მოცემულია მიკროჩიპის მონაცემთა ფურცელში.
Microchip თვლის, რომ მისი ოჯახის პროდუქტები უსაფრთხოა, როდესაც გამოიყენება დანიშნულებისამებრ, ოპერაციული სპეციფიკაციების ფარგლებში და ნორმალურ პირობებში.
მიკროჩიპი აფასებს და აგრესიულად იცავს მის ინტელექტუალურ საკუთრების უფლებებს. მიკროჩიპის პროდუქტების კოდების დაცვის მახასიათებლების დარღვევის მცდელობა მკაცრად აკრძალულია და შესაძლოა არღვევდეს ციფრული ათასწლეულის საავტორო უფლებების აქტს.
არც მიკროჩიპი და არც ნახევარგამტარების სხვა მწარმოებელი არ იძლევა მისი კოდის უსაფრთხოების გარანტიას. კოდის დაცვა არ ნიშნავს იმას, რომ ჩვენ გარანტიას ვაძლევთ პროდუქტის „შეურღვევია“. კოდის დაცვა მუდმივად ვითარდება. მიკროჩიპი მოწოდებულია მუდმივად გააუმჯობესოს ჩვენი პროდუქციის კოდის დაცვის მახასიათებლები.

იურიდიული ცნობა
ეს პუბლიკაცია და აქ არსებული ინფორმაცია შეიძლება გამოყენებულ იქნას მხოლოდ Microchip-ის პროდუქტებთან, მათ შორის მიკროჩიპის პროდუქტების დიზაინის, ტესტირებისა და ინტეგრაციისთვის თქვენს აპლიკაციაში. ამ ინფორმაციის ნებისმიერი სხვა გზით გამოყენება არღვევს წინამდებარე პირობებს. ინფორმაცია მოწყობილობის აპლიკაციებთან დაკავშირებით მოწოდებულია მხოლოდ თქვენი მოხერხებულობისთვის და შეიძლება შეიცვალოს განახლებებით. თქვენი პასუხისმგებლობაა უზრუნველყოთ, რომ თქვენი აპლიკაცია აკმაყოფილებს თქვენს სპეციფიკაციებს. დაუკავშირდით თქვენს ადგილობრივ მიკროჩიპის გაყიდვების ოფისს დამატებითი მხარდაჭერისთვის ან მიიღეთ დამატებითი მხარდაჭერა აქ www.microchip.com/en-us/support/design-help/client-support-services.

ეს ინფორმაცია მოწოდებულია მიკროჩიპის მიერ "როგორც არის". მიკროჩიპი არ იძლევა რაიმე სახის წარმომადგენლობას ან გარანტიას, იქნება ეს გამოხატული თუ ნაგულისხმევი, წერილობითი თუ ზეპირი, კანონიერი ან სხვაგვარად, დაკავშირებული ინფორმაციასთან, მათ შორის, მაგრამ არა შეზღუდული შეზღუდული არადარღვევა, ვაჭრობა და ვარგისიანობა კონკრეტული მიზნისთვის, ან მის მდგომარეობასთან, ხარისხთან ან შესრულებასთან დაკავშირებული გარანტიები.

არავითარ შემთხვევაში მიკროჩიპი არ იქნება პასუხისმგებელი რაიმე სახის არაპირდაპირ, სპეციალურ, სადამსჯელო, შემთხვევით ან თანმიმდევრულ დანაკარგზე, დაზიანებაზე, ღირებულებაზე ან ხარჯზე, რაც არ უნდა იყოს დაკავშირებული აშშ-სთან, ა.შ. IP იყო რეკომენდაცია შესაძლებლობა ან ზარალი განჭვრეტადია. კანონით ნებადართული სრულყოფილად, მიკროჩიპის მთლიანი პასუხისმგებლობა ყველა პრეტენზიაზე რაიმე ფორმით, რომელიც დაკავშირებულია ინფორმაციასთან ან მის გამოყენებასთან, არ აღემატება საკომისიოების რაოდენობას, ასეთის არსებობის შემთხვევაში, რომ თქვენ გეხმარებათ თქვენ.

მიკროჩიპის მოწყობილობების გამოყენება სიცოცხლის მხარდაჭერისა და/ან უსაფრთხოების აპლიკაციებში მთლიანად მყიდველის რისკის ქვეშაა და მყიდველი თანახმაა დაიცვას, აანაზღაუროს და შეინახოს უვნებელი მიკროჩიპი ყველა ზიანისგან, პრეტენზიისგან, სარჩელისგან ან ხარჯებისგან. არანაირი ლიცენზია არ არის გადაცემული, ირიბად ან სხვაგვარად, ნებისმიერი მიკროჩიპის ინტელექტუალური საკუთრების უფლებით, თუ სხვა რამ არ არის მითითებული.

სავაჭრო ნიშნები
მიკროჩიპის სახელი და ლოგო, მიკროჩიპის ლოგო, Adaptec, AVR, AVR ლოგო, AVR Freaks, BesTime, BitCloud, CryptoMemory, CryptoRF, dsPIC, flexPWR, HELDO, IGLOO, JukeBlox, KeeLoq, Kleer, Linktys, maXe MediaLB, megaAVR, Microsemi, Microsemi ლოგო, MOST, MOST ლოგო, MPLAB, OptoLyzer, PIC, picoPower, PICSTART, PIC32 ლოგო, PolarFire, Prochip Designer, QTouch, SAM-BA, SenGenuity, SpyNIC, SST, SST, SST Logoym, SuperF, , SyncServer, Tachyon, TimeSource, tinyAVR, UNI/O, Vectron და XMEGA არის Microchip Technology-ის რეგისტრირებული სავაჭრო ნიშნები, რომლებიც ჩართულია აშშ-ში და სხვა ქვეყნებში.

AgileSwitch, ClockWorks, The Embedded Control Solutions Company, EtherSynch, Flashtec, Hyper Speed Control, HyperLight Load, Libero, ძრავის სკამი, mTouch, Powermite 3, Precision Edge, ProASIC, ProASIC Plus, ProASIC Plus ლოგო, Quiet-Wire, SyncWorld , TimeCesium, TimeHub, TimePictra, TimeProvider და ZL არის Microchip Technology-ის რეგისტრირებული სავაჭრო ნიშნები, რომლებიც ინკორპორირებულია აშშ-ში

მიმდებარე კლავიშის ჩახშობა, AKS, ანალოგური ციფრული ასაკისთვის, ნებისმიერი კონდენსატორი, AnyIn, AnyOut, Augmented Switching, BlueSky, BodyCom, Clockstudio, CodeGuard, CryptoAuthentication, CryptoAutomotive, CryptoAutomotive, DEMICPICDs, CryptoCompanion ჭინჭრის , DAM, ECAN, ესპრესო T1S, EtherGREEN, EyeOpen, GridTime, IdealBridge,
IGaT, სერიული პროგრამირება, ICSP, INICnet, ინტელექტუალური პარალელურობა, IntelliMOS, ჩიპებს შორის დაკავშირება, JitterBlocker, Knob-on-Display, MarginLink, maxCrypto, maxView, memBrain, Mindi, MiWi, MPASM, MPF, MPLAB სერთიფიცირებული ლოგო, MPLIB, MPLINK, mSiC, MultiTRAK, NetDetach, ყოვლისმომცველი კოდის გენერაცია, PICDEM, PICDEM.net, PICkit, PICtail, Power MOS IV, Power MOS 7, PowerSileSmart, , QMatrix, REAL ICE, Ripple ბლოკერი, RTAX, RTG4, SAM-ICE, სერიული Quad I/O, მარტივი რუკა, 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 და ZENA არის Microchip Technology-ის სავაჭრო ნიშნები, რომლებიც ინკორპორირებულია აშშ-სა და სხვა ქვეყნებში.

SQTP არის Microchip Technology-ის მომსახურების ნიშანი, რომელიც დაფუძნებულია აშშ-ში
Adaptec ლოგო, Frequency on Demand, 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. ჩენდლერი, AZ 85224-6199

ტელ: 480-792-7200

ფაქსი: 480-792-7277

ტექნიკური მხარდაჭერა: www.microchip.com/support

Web მისამართი: www.microchip.com

ატლანტა

დულუთი, GA

ტელ: 678-957-9614

ფაქსი: 678-957-1455

ოსტინი, ტეხასი

ტელ: 512-257-3370

ბოსტონი

Westborough, MA ტელ: 774-760-0087

ფაქსი: 774-760-0088

ჩიკაგო

იტასკა, IL

ტელ: 630-285-0071

ფაქსი: 630-285-0075

დალასი

ადისონი, TX

ტელ: 972-818-7423

ფაქსი: 972-818-2924

დეტროიტი

ნოვი, MI

ტელ: 248-848-4000

ჰიუსტონი, TX

ტელ: 281-894-5983

ინდიანაპოლისი

Noblesville, IN ტელ: 317-773-8323

ფაქსი: 317-773-5453

ტელ: 317-536-2380

ლოს ანჯელესი

Mission Viejo, CA ტელ: 949-462-9523

ფაქსი: 949-462-9608

ტელ: 951-273-7800

რალი, NC

ტელ: 919-844-7510

ნიუ-იორკი, ნიუ-იორკი

ტელ: 631-435-6000

სან ხოსე, CA

ტელ: 408-735-9110

ტელ: 408-436-4270

კანადა – ტორონტო

ტელ: 905-695-1980

ფაქსი: 905-695-2078

ავსტრალია - სიდნეი

ტელ: 61-2-9868-6733

ჩინეთი - პეკინი

ტელ: 86-10-8569-7000

ჩინეთი - ჩენგდუ

ტელ: 86-28-8665-5511

ჩინეთი - ჩონკინგი

ტელ: 86-23-8980-9588

ჩინეთი - დონგუანი

ტელ: 86-769-8702-9880

ჩინეთი - გუანჯოუ

ტელ: 86-20-8755-8029

ჩინეთი - ჰანჯოუ

ტელ: 86-571-8792-8115

ჩინეთი – ჰონგ კონგი SAR

ტელ: 852-2943-5100

ჩინეთი - ნანჯინგი

ტელ: 86-25-8473-2460

ჩინეთი - ცინგდაო

ტელ: 86-532-8502-7355

ჩინეთი - შანხაი

ტელ: 86-21-3326-8000

ჩინეთი - შენიანგი

ტელ: 86-24-2334-2829

ჩინეთი - შენჟენი

ტელ: 86-755-8864-2200

ჩინეთი - სუჯოუ

ტელ: 86-186-6233-1526

ჩინეთი - ვუჰანი

ტელ: 86-27-5980-5300

ჩინეთი - Xian

ტელ: 86-29-8833-7252

ჩინეთი - Xiamen

ტელ: 86-592-2388138

ჩინეთი - ჟუჰაი

ტელ: 86-756-3210040

ინდოეთი – ბანგალორი

ტელ: 91-80-3090-4444

ინდოეთი - ნიუ დელი

ტელ: 91-11-4160-8631

ინდოეთი – პუნი

ტელ: 91-20-4121-0141

იაპონია – ოსაკა

ტელ: 81-6-6152-7160

იაპონია – ტოკიო

ტელ: 81-3-6880- 3770

კორეა - დეგუ

ტელ: 82-53-744-4301

კორეა - სეული

ტელ: 82-2-554-7200

მალაიზია - კუალა ლუმპური

ტელ: 60-3-7651-7906

მალაიზია - პენანგი

ტელ: 60-4-227-8870

ფილიპინები – მანილა

ტელ: 63-2-634-9065

სინგაპური

ტელ: 65-6334-8870

ტაივანი – ჰსინ ჩუ

ტელ: 886-3-577-8366

ტაივანი - კაოსიუნგი

ტელ: 886-7-213-7830

ტაივანი - ტაიპეი

ტელ: 886-2-2508-8600

ტაილანდი - ბანგკოკი

ტელ: 66-2-694-1351

ვიეტნამი - ჰო ჩიმინი

ტელ: 84-28-5448-2100

ავსტრია – უელსი

ტელ: 43-7242-2244-39

ფაქსი: 43-7242-2244-393

დანია – კოპენჰაგენი

ტელ: 45-4485-5910

ფაქსი: 45-4485-2829

ფინეთი – ესპუო

ტელ: 358-9-4520-820

საფრანგეთი – პარიზი

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

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

გერმანია – გარჭობა

ტელ: 49-8931-9700

გერმანია – ჰაან

ტელ: 49-2129-3766400

გერმანია – ჰაილბრონი

ტელ: 49-7131-72400

გერმანია – კარლსრუე

ტელ: 49-721-625370

გერმანია – მიუნხენი

Tel: 49-89-627-144-0

Fax: 49-89-627-144-44

გერმანია – როზენჰაიმი

ტელ: 49-8031-354-560

ისრაელი - ჰოდ ჰაშარონი

ტელ: 972-9-775-5100

იტალია - მილანი

ტელ: 39-0331-742611

ფაქსი: 39-0331-466781

იტალია - პადოვა

ტელ: 39-049-7625286

ნიდერლანდები – დრუნენი

ტელ: 31-416-690399

ფაქსი: 31-416-690340

ნორვეგია – ტრონდჰეიმი

ტელ: 47-72884388

პოლონეთი - ვარშავა

ტელ: 48-22-3325737

რუმინეთი – ბუქარესტი

Tel: 40-21-407-87-50

ესპანეთი - მადრიდი

Tel: 34-91-708-08-90

Fax: 34-91-708-08-91

შვედეთი - გეტებორგი

Tel: 46-31-704-60-40

შვედეთი - სტოკჰოლმი

ტელ: 46-8-5090-4654

დიდი ბრიტანეთი - ვოკინგემი

ტელ: 44-118-921-5800

ფაქსი: 44-118-921-5820

დოკუმენტები / რესურსები

MICROCHIP PIC64GX 64-ბიტიანი RISC-V ოთხბირთვიანი მიკროპროცესორი [pdf] მომხმარებლის სახელმძღვანელო
PIC64GX, PIC64GX 64-ბიტიანი RISC-V ოთხბირთვიანი მიკროპროცესორი, 64-ბიტიანი RISC-V ოთხბირთვიანი მიკროპროცესორი, RISC-V ოთხბირთვიანი მიკროპროცესორი, ოთხბიტიანი მიკროპროცესორი, მიკროპროცესორი

ცნობები

მომხმარებლის სახელმძღვანელო

MICROCHIP PIC64GX 64-ბიტიანი RISC-V ოთხბირთვიანი მიკროპროცესორი

პროდუქტის ინფორმაცია

პროდუქტის გამოყენების ინსტრუქცია