Упатство за употреба на четири-јадрен микропроцесор MICROCHIP PIC64GX 64-битен RISC-V

Процес на подигање
1. Софтверски компоненти вклучени во подигнувањето
  Процесот на подигање на системот ги вклучува следните софтверски компоненти:
  - Харт софтверски услуги (HSS): А нула-stagе подигнувач, системски монитор и давател на услуги за траење за апликации.
2. Проток на подигање
  Редоследот на протокот на системот за подигање е како што следува:
  1. Иницијализирање на софтверските услуги Харт (HSS)
  2. Извршување на подигнувачот
  3. Стартување на апликацијата
Чувари
1. PIC64GX Watchdog
  PIC64GX располага со функција за набљудување за следење на работата на системот и активирање дејства во случај на дефект на системот.
Режим на заклучување
Режимот на заклучување е дизајниран за клиенти на кои им е потребна целосна контрола врз дејствата на системот по подигнувањето. Ги ограничува функционалностите на системскиот монитор E51.

Најчесто поставувани прашања

П: Која е целта на Харт софтверските услуги (HSS)?
О: HSS служи како нула-stagе подигнувач, системски монитор и давател на услуги за траење за апликации за време на процесот на подигање.
П: Како функционира чуварската функција PIC64GX?
О: чуварот PIC64GX ја следи работата на системот и може да преземе однапред дефинирани дејства во случај на дефект на системот за да обезбеди сигурност на системот.

Вовед

Оваа бела книга објаснува како Microchip PIC64GX ги подигнува работните оптоварувања на апликациите и го опишува процесот на подигање на системот, кој функционира исто за SMP и AMP оптоварувања на работа. Дополнително, опфаќа како функционира рестартирањето за SMP и AMP оптоварување, чувари на PIC64GX и специјален режим на заклучување за системи каде што клиентите сакаат целосна контрола за да ги ограничат активностите на системскиот монитор E51 по подигнувањето на системот.

Процес на подигање

Дозволете ни да ги погледнеме различните софтверски компоненти вклучени во подигнувањето на системот, проследено со подетален преглед на секвенцата на самиот тек на системот за подигање.

Софтверски компоненти вклучени во подигнувањето
Следниве компоненти се вклучени во процесот на подигање на системот:

Слика 1.1. Компоненти за подигнување

Харт софтверски услуги (HSS)
Hart Software Services (HSS) е нула-stagе подигнувач, системски монитор и давател на услуги за траење за апликации. HSS поддржува рано поставување на системот, обука за DDR и иницијализација/конфигурација на хардверот. Најчесто работи на E51s, со мала количина на функционалност на ниво на машински режим што работи на секој U54. Тој подигнува еден или повеќе контексти со вчитување на „payload“ на апликацијата од медиумот за подигање и обезбедува Платформи за траење услуги/Околина за извршување на супервизор (SEE) за кернелите на оперативниот систем. Поддржува безбедно подигање и е важна компонента во обезбедувањето на партиционирање/одвојување на хардверот за AMP контексти.

Das U-Boot (U-Boot)
Das U-Boot (U-Boot) е универзален подигнувач со скрипт со отворен код. Поддржува едноставен CLI што може да ја врати сликата за подигање од различни извори (вклучувајќи SD-картичка и мрежа). U-Boot го вчитува Linux. Може да обезбеди UEFI средина доколку е потребно. Тој е генерално завршен и не е во можност откако ќе се подигне Linux - со други зборови, тој не останува резидентен по подигањето.
Линукс кернелот
Линукс кернелот е најпопуларниот кернел на оперативниот систем во светот. Во комбинација со корисничка земја на апликации, тој го формира она што вообичаено се нарекува оперативен систем Линукс. Оперативниот систем Linux обезбедува богати POSIX API и околина за развивачи, на прample, јазици и алатки како Python, Perl, Tcl, Rust, C/C++ и Tcl; библиотеки како што се OpenSSL, OpenCV, OpenMP, OPC/UA и OpenAMP (RPmsg и RemoteProc).
Yocto и Buildroot се создавачи на системи на Линукс, односно тие можат да се користат за генерирање на нарачани приспособени Linux системи. Yocto излегува дистрибуција на Линукс со богата
збир на апликации, алатки и библиотеки и опционално управување со пакети. 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 кој содржи целосен сет на регистри и кој го извршува својот код независно. Можете да го замислите како хардверска нишка или еден процесор. Група срца во едно јадро често се нарекува комплекс. Оваа тема ги опишува чекорите за иницијализирање на корплексот PIC64GX, вклучувајќи го E51 системот за монитори на срцето и U54 апликациите.

Вклучете го корплексот PIC64GX.
При вклучување, сите харти во корплексот 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 во Code Now во L2Scratch по декомпресија
Извршната датотека се состои од три компоненти:
- Слој за апстракција на хардверот (HAL), код на ниско ниво и драјвери за гол метал
- Локална HSS вилушка на RISC-V OpenSBI (малку изменета од возводно на PIC64GX за AMP цели)
- Услугите за извршување на HSS (состојните машини работат во супер јамка)
Иницијализирајте го хардверот и структурите на податоци што ги користи OpenSBI.
Услугата HSS „Startup“ е одговорна за оваа иницијализација.

Преземете ја сликата на обемот на работа на апликацијата (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 и која било секундаtagе-натоварувачи за подигање. За прampLe, U-Boot го носи Linux.

Рестартирај

Поврзана со концептот за подигање на системот е потребата за рестартирање. Кога размислувате за оптоварувањата на апликацијата PIC64GX, рестартирањето треба да ги земе предвид и симетричното мултипроцесирање (SMP) и асиметричното мултипроцесирање (AMP) сценарија:

Во случај на SMP систем, рестартирањето може безбедно да го рестартира целиот систем, бидејќи нема дополнителни оптоварувања во друг контекст што треба да се разгледа.

Во случај на ан AMP систем, на обемот на работа може да му биде дозволено само да се рестартира (и да не се меша со кој било друг контекст), или може да биде привилегирано да може да изврши целосно рестартирање на системот.

Рестартирај и AMP
За да се овозможи ЗМП и AMP сценарија за рестартирање, HSS ги поддржува концептите на привилегии за топло и ладно рестартирање, кои можат да се доделат на контекст. Контекстот со привилегија за топло рестартирање може само да се рестартира, а контекстот со привилегија за ладно рестартирање може да изврши целосно рестартирање на системот. За прampле, разгледајте го следниот сет на репрезентативни сценарија.

Оптоварување на SMP со еден контекст, што е дозволено да побара целосно рестартирање на системот
Во ова сценарио, на контекстот му е дозволена привилегија за ладно рестартирање.
Дво-контекст AMP обемот на работа, каде што на контекстот А му е дозволено да побара целосно рестартирање на системот (што влијае на сите контексти), а на контекстот Б му е дозволено само да се рестартира
Во ова сценарио, на контекстот А е дозволена привилегија за ладно рестартирање, а на контекстот Б е дозволена привилегија за топло рестартирање.
Дво-контекст AMP обемот на работа, каде што контекстите А и Б смеат само сами да се рестартираат (и да не влијаат на другиот контекст)
Во ова сценарио, на двата контекста им се дозволени само привилегии за топло рестартирање.
Дво-контекст AMP обемот на работа, каде што на контекстите А и Б им е дозволено да бараат целосно рестартирање на системот
Во ова сценарио, на двата контекста им се дозволени привилегии за ладно рестартирање.
Понатаму, можно е HSS во времето на изградба секогаш да дозволува привилегија за ладно рестартирање и никогаш да не дозволува привилегија за ладно рестартирање.

Релевантни опции за HSS Kconfig
Kconfig е конфигурациски систем за изработка на софтвер. Најчесто се користи за избор на опции за време на изградба и за овозможување или оневозможување на функциите. Потекнува од кернелот Линукс, но сега се користи во други проекти надвор од кернелот на Линукс, вклучувајќи ги U-Boot, Zephyr и PIC64GX HSS.

HSS содржи две Kconfig опции кои ја контролираат функционалноста за рестартирање од HSS перспектива:

CONFIG_ALLOW_COLD RESTART
Ако ова е овозможено, глобално му дозволува на контекстот да издаде повик за ладно рестартирање. Ако е оневозможено, ќе бидат дозволени само топло рестартирање. Покрај овозможувањето на оваа опција, мора да се даде дозвола за издавање ладно рестартирање на контекст преку генератор на носивост YAML file или следнава опција Kconfig.
CONFIG_ALLOW_COLD REBOOT_ALWAYS
- Ако е овозможена, оваа функција глобално им дозволува на сите контексти да издаваат ладно рестартирање ECAA, без оглед на правата на знамето payload.bin.
- Дополнително, самиот payload.bin може да содржи знаменце по контекст, што покажува дека одреден контекст има право да издава ладни рестартирања:
  - За да дозволиме контекстно топло рестартирање друг контекст, можеме да ја додадеме опцијата дозволи-рестартира: топло во описот YAML file се користи за креирање на товарот.bin
  - За да дозволиме контекстно ладно рестартирање на целиот систем, можеме да ја додадеме опцијата дозволи-рестартира: ладно. Стандардно, без специфицирање дозволи-рестартирање, контекстот е дозволен само топло рестартирање, без оглед на поставката на ова знаменце, ако CONFIG_ALLOW_COLDREBOOT не е овозможено во HSS, HSS ќе ги преработи сите барања за ладно рестартирање на топли (по контекст) рестартирање .

Рестартирајте детално
Овој дел детално опишува како функционира рестартирањето - почнувајќи со слојот OpenSBI (најнискиот слој на М-режим) и потоа дискутирајќи како оваа функционалност на слојот OpenSBI се активира од апликација RTOS или богат оперативен систем како Linux.

Повик за рестартирање на OpenSBI

Спецификацијата RISC-V Supervisor Binary Interface (SBI) опишува стандардизиран слој за апстракција на хардверот за иницијализација на платформата и услуги за извршување на фирмверот. Главната цел на SBI е да овозможи преносливост и компатибилност на различни имплементации на RISC-V.
OpenSBI (Open Source Supervisor Binary Interface) е проект со отворен код кој обезбедува референтна имплементација на спецификацијата SBI. OpenSBI, исто така, обезбедува услуги за траење, вклучително и справување со прекини, управување со тајмер и влез/излез на конзолата, кои можат да се користат од слоевите на софтвер од повисоко ниво.
OpenSBI е вклучен како дел од HSS и работи на ниво на машински режим. Кога оперативниот систем или апликацијата ќе предизвикаат замка, таа ќе биде предадена на 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] за REBOOT_WARM). За повеќе информации за изворниот код на кернелот Линукс, видете Documentation/admin-guide/kernel-paramters.txt.
Алтернативно, ако е овозможено /sys/kernel/reboot, управувачите одоздола може да се читаат за да се добие тековната конфигурација за рестартирање на системот и да се напишат за да се смени. За повеќе информации за изворниот код на кернелот Линукс, видете Документација/ABI/тестирање/sysfs-kernel-reboot.

Чувари

Дополнителен концепт поврзан со подигање на системот и рестартирање на системот е тој за обновување на системот по вклучувањето на тајмерот за набљудување. Тајмерите Watchdog се широко користени во вградените системи за автоматско опоравување од минливи хардверски дефекти и за спречување на погрешен или злонамерен софтвер да ја наруши работата на системот.
PIC64GX вклучува хардверска поддршка за следење на поединечните карти кога системот работи. Чуварите обезбедуваат дека хартите може да се рестартираат доколку не реагираат поради неотповикливи софтверски грешки.
PIC64GX вклучува пет примероци на хардверски блокови со тајмер-чувар што се користат за откривање на заклучувања на системот - по еден за секој од хардс. За да се олесни мешаната асиметрична мулти-обработка (AMP) оптоварување, HSS поддржува мониторинг и реагирање на пукањето на чуварите.

PIC64GX Watchdog

HSS е одговорен за подигнување на хартиите на апликацијата при вклучувањето и за нивно повторно подигање (индивидуално или колективно) во секое времеtagд, доколку е потребно или посакувано. Како последица на ова, реагирањето на настаните од чуварот на PIC64GX го управува HSS.
Мониторот „виртуелен чувар“ е имплементиран како државна машинска услуга на HSS, а неговите одговорности се да го надгледува статусот на секој од индивидуалните хардверски монитори на чуварот U54. Кога едно од овие U54 чувари ќе патува, HSS го открива ова и ќе го рестартира U54 како што е соодветно. Ако U54 е дел од контекст со SMP, целиот контекст се разгледува за рестартирање, имајќи предвид дека контекстот има привилегија за топло рестартирање. Целиот систем ќе се рестартира ако контекстот има привилегија за ладно рестартирање.

Релевантни опции за Kconfig

Поддршката Watchdog е стандардно вклучена во објавените HSS-изданија. Доколку сакате да изградите сопствен HSS, овој дел ќе го опише механизмот за конфигурација за да се осигура дека поддршката на Watchdog е овозможена.

HSS е конфигуриран со помош на системот за конфигурација Kconfig. Највисоко ниво .config file е потребно за да изберете кои услуги ќе се компајлираат во или надвор од HSS-изградбата.
Прво, опцијата CONFIG_SERVICE_WDOG од највисоко ниво треба да биде овозможена („Поддршка на Virtual Watchdog“ преку 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 е овозможен, HSS периодично ќе му пишува на Watchdog за да го освежи и да го спречи да пука. Ако, поради некоја причина, срцето E51 се заклучи или падне, а чуварот E51 е овозможен, ова секогаш ќе го ресетира целиот систем.

Операција на чувар
Хардверот на чуварот имплементира шалтери. Прозорец забранет за освежување може да се создаде со конфигурирање на максималната вредност на чуварот до која е дозволено освежување (MVRP).

Кога моменталната вредност на тајмерот за набљудување е поголема од вредноста на MVRP, забрането е освежување на чуварот. Обидот за освежување на тајмерот за набљудување во забранетиот прозорец ќе наведе прекин на истек на време.

Освежувањето на чуварот помеѓу вредноста на MVRP и вредноста на активирањето (TRIG) успешно ќе го освежи бројачот и ќе го спречи чуварот да пука.
Штом вредноста на тајмерот на чуварот ќе се брои под вредноста на TRIG, чуварот ќе пука.

Државна машина чувар

Машината за состојба на чувар е многу јасна - стартува со конфигурирање на чуварот за E51, доколку е овозможено, а потоа преминува низ состојба на мирување во мониторинг. Секој пат околу суперјамката, се повикува оваа мониторинг состојба, која го проверува статусот на секое од U54 чуварите.

Машината за состојба на чувар е во интеракција со машината за состојбата на подигање за да го рестартира Харт (и сите други харти што се во нејзиниот сет за подигање), доколку открие дека Харт не успеал да го освежи својот чувар на време.

Режим на заклучување

Нормално (особено со AMP апликации), се очекува дека HSS ќе остане резидентен во М-режим, на U54, за да дозволи рестартирање по контекст (т.е. рестартирање само еден контекст, без рестартирање со целосен чип) и да му дозволи на HSS да го следи здравјето ( ECC, битови за статус на заклучување, грешки во магистралата, грешки на SBI, прекршувања на PMP, итн.).

Со цел да се обезбедат можности за рестартирање наAMP основа на контекстот (без да се бара рестартирање на целиот систем), E51 обично има привилегиран мемориски пристап до целиот мемориски простор на системот. Сепак, може да има ситуации кога тоа не е пожелно, а клиентот може да претпочита да го ограничи она што го прави фирмверот E51 HSS откако системот ќе се подигне успешно. Во овој случај, можно е 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 во services/lockdown/lockdown_service.c file.

Додаток

HSS payload.bin Формат

Овој дел го опишува payload.bin file форматот и сликата што ја користи HSS за подигнување на PIC64GX SMP и AMP апликации.
Payload.bin е форматирана бинарна форма (слика А.10) која се состои од глава, различни табели со дескриптори и разни делови кои ги содржат кодовите и деловите на податоци на секој дел од обемот на работа на апликацијата. Едно парче може да се смета како соседен блок на меморија со произволна големина.

Слика А.10. payload.bin Format

Делот за заглавие (прикажан на Слика А.11) содржи магична вредност што се користи за идентификување на payload.bin и некои информации за домаќинството, заедно со детали за сликата наменета да се прикажува на секоја од
U54 кодови за апликација. Тој опишува како да се подигне секој поединечен U54 хард, како и комплетот на бутабилни слики во целина. Во информациите за домаќинството, тој има покажувачи до различни табели со дескриптори за да дозволи големината на заглавјето да расте.

Слика А.11. носивост.bin Header

Кодот и иницијализираните константни податоци се сметаат за само за читање и се чуваат во дел само за читање, на кој се посочуваат дескрипторите на заглавието.
Иницијализираните променливи на податоци без нула се податоци за читање-запишување, но нивните вредности за иницијализација се копирани од делот само за читање при стартување. Тие се исто така зачувани во делот само за читање.

Делот за податоци за носивост само за читање е опишан со табела на кодови и дескриптори на делови од податоци. Секој дескриптор на парче во оваа табела содржи „сопственик на харт“ (главниот хард во контекст на кој е насочен
во), поместување на оптоварувањето (поместување во payload.bin) и адреса за извршување (дестинација во меморијата PIC64GX), заедно со големина и контролна сума. Ова е прикажано на слика А.12.

Слика А.12. Описувач на делови само за читање и податоци за делови за носивост

Покрај горенаведените делови, има и делови од меморијата што одговараат на променливите на податоци кои се иницијализирани на нула. Тие не се складираат како податоци во payload.bin, туку се специјален сет на нула иницијализирани дескриптори на делови, кои одредуваат адреса и должина на RAM меморијата што треба да се постави на нула при стартување. Ова е прикажано на слика А.13.

Слика А.13. ЗИ Парчиња

hss-payload-generator
Алатката HSS Payload Generator создава форматирана слика за носивост за Hart Software Service zero-stagе подигнувач на PIC64GX, со конфигурација file и комплет ELF fileи/или бинарни. Конфигурацијата file се користи за мапирање на бинарните елементи на ELF или бинарните блокови на поединечните апликациски харти (U54s).

Слика Б.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 за елиптичната крива P-384 (SECP384r1):
$ ./hss-payload-generator -c test/config.yaml payload.bin -p /path/to/private.pem

За повеќе информации, видете ја документацијата за автентикација за безбедно подигање.

Конфигурација 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) кои ќе бидат поставени во одредени региони во меморијата. Секцијата за носивост е дефинирана со клучниот збор носивост, а потоа и голем број индивидуални дескриптори за носивост. Секоја носивост има име (пат до нејзиниот 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 и работи на U54_1, U54_2 и U54_4. Очекува да започне во режимот на привилегии PRV_S.

Важно:
Излезот на U-Boot создава ELF file, но вообичаено не ја закачува екстензијата .elf. Во овој случај, се користи бинарното креирано од CONFIG_OF_SEPARATE, кое додава дупка на дрвото на уредот на бинарното U-Boot.

Еве го бившиотample Конфигурација на носивост file:

test/zephyr.elf:
{exec-addr: „0xB0000000“, сопственик-харт: u54_3, приватен режим: prv_m, skip-opensbi: точно}
test/u-boot-dtb.bin:
{exec-addr: '0x80200000', сопственик-харт: u54_1, секундарен-харт: u54_2, секундарен-харт: u54_4, режим на приватен: 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. Опцијата за прескокнување-отвора е опционална и стандардно е неточно.

За да дозволиме контекстно топло рестартирање на друг контекст, можеме да ја додадеме опцијата дозволи рестартирање: топло. За да дозволиме контекстно ладно рестартирање на целиот систем, можеме да ја додадеме опцијата дозволи-рестартира: ладно. Стандардно, без назначување дозволи-рестартирање, на контекстот му е дозволено само да се загрее самото рестартирање.
Исто така, можно е да се поврзат помошни податоци со секоја носивост, на пр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 во извршната датотека
празно место), а неговата адреса ќе биде предадена на OpenSBI во полето next_arg1 (пренесено во регистарот $a1 на сликата при подигање).

За да спречите HSS автоматски да подига контекст (на пример, ако наместо тоа сакаме да ја делегираме контролата на контекст користејќи remoteProc), користете го знаменцето за прескокнување-автоматско подигање:
test/zephyr.elf: {exec-addr: „0xB0000000“, сопственик-харт: 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-amp машинската цел во Yocto ќе генерира слика на апликацијата користејќи ја алатката hss-payload-generator што покажува AMP, со Linux што работи на 3 харти и Zephyr работи на 1 Харт.

Историја на ревизии
Историјата на ревизии ги опишува промените што беа имплементирани во документот. Промените се наведени со ревизија, почнувајќи од најактуелната публикација.

Ревизија	Датум	Опис
A	07/2024	Почетна ревизија

Информации за микрочип

Микрочипот Webсајт
Микрочип обезбедува онлајн поддршка преку нашата webсајт на www.microchip.com/. Ова webсајт се користи за да се направи fileи информации лесно достапни за клиентите. Некои од достапните содржини вклучуваат:

Поддршка за производи – Листови со податоци и грешки, белешки за апликација и сampле програми, ресурси за дизајн, упатства за корисникот и документи за поддршка на хардверот, најнови изданија на софтвер и архивиран софтвер

Општа техничка поддршка – Често поставувани прашања (ЧПП), барања за техничка поддршка, онлајн групи за дискусија, листа на членови на програмата за партнер за дизајн на микрочип
Бизнис на микрочип – Водичи за избор на производи и нарачки, најнови соопштенија за печатот на Microchip, список на семинари и настани, списоци на продажни канцеларии, дистрибутери и фабрички претставници на Microchip

Услуга за известување за промена на производот

Услугата за известување за промена на производот на Microchip им помага на клиентите да бидат актуелни за производите на Microchip. Претплатниците ќе добиваат известување по е-пошта секогаш кога има промени, ажурирања, ревизии или грешки поврзани со одредена фамилија на производи или алатка за развој од интерес.

За да се регистрирате, одете на www.microchip.com/pcn и следете ги упатствата за регистрација.

Поддршка за корисници
Корисниците на производите на Микрочип можат да добијат помош преку неколку канали:

Дистрибутер или претставник
Локална канцеларија за продажба
Инженер за вградени решенија (ESE)
Техничка поддршка

Клиентите треба да контактираат со нивниот дистрибутер, претставник или ESE за поддршка. Локалните канцеларии за продажба се исто така достапни за да им помогнат на клиентите. Во овој документ е вклучен список на продажни канцеларии и локации.
Техничката поддршка е достапна преку webсајт на: www.microchip.com/support.

Функција за заштита на код на уреди со микрочип
Забележете ги следните детали за функцијата за заштита на кодот на производите на Microchip:

Производите со микрочип ги исполнуваат спецификациите содржани во нивниот посебен лист со податоци за микрочипови.
Микрочип верува дека неговата фамилија на производи е безбедна кога се користи на предвидениот начин, во рамките на работните спецификации и под нормални услови.

Микрочипот ги вреднува и агресивно ги штити своите права на интелектуална сопственост. Обидите да се прекршат карактеристиките за заштита на кодот на производите на Microchip се строго забранети и може да го прекршат Законот за авторски права на дигиталниот милениум.
Ниту Microchip ниту кој било друг производител на полупроводници не може да ја гарантира безбедноста на неговиот код. Заштитата на кодот не значи дека гарантираме дека производот е „нескршлив“. Заштитата на кодот постојано се развива. Микрочип е посветен на континуирано подобрување на карактеристиките за заштита на кодот на нашите производи.

Правно известување
Оваа публикација и информациите овде може да се користат само со производите на Микрочип, вклучително и за дизајнирање, тестирање и интегрирање на производите на Микрочип со вашата апликација. Користењето на овие информации на кој било друг начин ги прекршува овие услови. Информациите за апликациите на уредот се обезбедени само за ваша погодност и може да бидат заменети со ажурирања. Ваша одговорност е да се осигурате дека вашата апликација ги исполнува вашите спецификации. Контактирајте ја локалната канцеларија за продажба на Microchip за дополнителна поддршка или добијте дополнителна поддршка на www.microchip.com/en-us/support/design-help/client-support-services.

ОВАА ИНФОРМАЦИЈА СЕ ОБЕЗБЕДУВА МИКРОЧИП „КАКО ШТО Е“. МИКРОЧИП НЕ ДАВА НИКАКВИ ПРЕТСТАВУВАЊА ИЛИ ГАРАНЦИИ БИЛО ИЗРАЗНИ ИЛИ ИМПЛИЦИРАНИ, ПИСМЕНИ ИЛИ УСНИ, ЗАКОНСКИ ИЛИ ПОинаку, ПОВРЗАНИ СО ИНФОРМАЦИИТЕ ВКЛУЧУВАЈТЕ НО НЕ ОГРАНИЧЕНИ НА ОГРАНИЧЕНО НЕПРЕКРШУВАЊЕ, ПРОДАЖБА И СООДВЕТНОСТ ЗА ПОСЕДНА ЦЕЛ ИЛИ ГАРАНЦИИ ПОВРЗАНИ СО НЕГОВАТА СОСТОЈБА, КВАЛИТЕТ ИЛИ ИЗВЕДБА.

ВО НИКОЈ СЛУЧАЈ МИКРОЧИПОТ НЕМА ДА СЕ ОДГОВАРА ЗА НИКАКВА ИНДИРЕКТНА, ПОСЕБНА, КАЗНЕТНА, ИНЦИДЕНТАЛНА ИЛИ ПОСЛЕДНА ЗАГУБА, ШТЕТА, ТРОШОЦА ИЛИ ТРОШОЦИ ОД КАКОВ ВИД КАКОВ ВИД СЕ ПОВРЗАНИ СО КОЛКУ КОЛКУ НИЕ, КОЛКУ НИЕ, ИП Е СОВЕТУВАНА ОД МОЖНОСТА ИЛИ ШТЕТИТЕ СЕ ПРЕДВИДЕЛИ. ВО ЦЕЛИОТ СТЕМЕН ДОЗВОЛЕН СО ЗАКОН, ВКУПНАТА ОДГОВОРНОСТ НА МИКРОЧИПОТ ЗА СИТЕ ПОБАРАЊА НА КАКОВ НАЧИН ПОВРЗАНИ СО ИНФОРМАЦИИТЕ ИЛИ НЕГОВАТА УПОТРЕБА НЕМА ДА ГО НАДМИНАТ БРОЈОТ НА НАДОМЕСТОЦИ, АКО ГИ ПОСТОЈАТ ТОА ШТО ГО ПОГОДУВАТЕ ТОА ВИЕ.

Употребата на уредите со микрочип во апликациите за одржување во живот и/или за безбедност е целосно на ризик на купувачот, а купувачот се согласува да го брани, обештети и држи безопасниот Микрочип од сите штети, барања, тужби или трошоци кои произлегуваат од таквата употреба. Ниту една лиценца не се пренесува, имплицитно или на друг начин, според правата на интелектуална сопственост на Микрочип, освен ако не е поинаку наведено.

Заштитни знаци
Името и логото на микрочипот, логото на микрочипот, Adaptec, AVR, AVR логото, AVR Freaks, BesTime, BitCloud, CryptoMemory, CryptoRF, dsPIC, flexPWR, HELDO, IGLOO, JukeBlox, KeeLoq, Kleer, LinkTouchS, maXe MediaLB, megaAVR, Microsemi, Microsemi лого, MOST, MOST лого, MPLAB, OptoLyzer, PIC, picoPower, PICSTART, PIC32 лого, PolarFire, Prochip Designer, QTouch, SAM-BA, SenGenuity, SpyNIC, SST, SST, SST, SST Logoymricom, , 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, моторна клупа, mTouch, Powermite 3, Precision Edge, ProASIC, ProASIC Plus, ProASIC Plus лого, Quiet-Wire, SyncFord , TimeCesium, TimeHub, TimePictra, TimeProvider и ZL се регистрирани заштитни знаци на Microchip Technology инкорпорирана во САД

Потиснување на клучеви во непосредна близина, AKS, аналоген за-дигитален век, кој било кондензатор, AnyIn, AnyOut, зголемено префрлување, BlueSky, BodyCom, Clockstudio, CodeGuard, CryptoAuthentication, CryptoAutomotive, CryptoAutomotive, DEMICPmicds чкртање , DAM, ECAN, Еспресо T1S, EtherGREEN, EyeOpen, GridTime, IdealBridge,
IGaT, сериско програмирање во коло, ICSP, INICnet, интелигентно паралелизирање, IntelliMOS, поврзување меѓу чипови, JitterBlocker, копче на дисплеј, MarginLink, maxCrypto, максView, memBrain, Mindi, MiWi, MPASM, MPF, MPLAB Сертифицирано лого, MPLIB, MPLINK, mSiC, MultiTRAK, NetDetach, генерирање на сезнаен код, PICDEM, PICDEM.net, PICkit, PICtail, Power MOS IV, Power MOS 7, PowerSiliconsmart, , QMatrix, REAL ICE, Ripple Blocker, RTAX, RTG4, SAM-ICE, Serial Quad I/O, едноставна карта, SimpliPHY, SmartBuffer, SmartHLS, SMART-IS, storClad, SQI, SuperSwitcher, SuperSwitcher II, Switchtec, TotalPHY, Synchro Издржливост, доверливо време, TSHARC, Туринг, 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 Западен Чендлер бул. Чендлер, АЗ 85224-6199

тел: 480-792-7200

Факс: 480-792-7277

Техничка поддршка: www.microchip.com/support

Web Адреса: www.microchip.com

Атланта

Дулут, ГА

тел: 678-957-9614

Факс: 678-957-1455

Остин, Тексас

тел: 512-257-3370

Бостон

Вестборо, м-р Тел: 774-760-0087

Факс: 774-760-0088

Чикаго

Итаска, ИЛ

тел: 630-285-0071

Факс: 630-285-0075

Далас

Адисон, ТХ

тел: 972-818-7423

Факс: 972-818-2924

Детроит

Нови, МИ

тел: 248-848-4000

Хјустон, TX

тел: 281-894-5983

Индијанаполис

Ноблсвил, IN Тел: 317-773-8323

Факс: 317-773-5453

тел: 317-536-2380

Лос Анџелес

Mission Viejo, Калифорнија Тел: 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

Кина - Ксиан

Тел: 86-29-8833-7252

Кина - Ксијамен

Тел: 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 четири-јадрен микропроцесор

Информации за производот

Упатство за употреба на производот