Benutzerhandbuch für den 64-Bit RISC-V Quad-Core-Mikroprozessor MICROCHIP PIC64GX

Bootvorgang
1. Am Bootvorgang beteiligte Softwarekomponenten
  Am Systemstartvorgang sind die folgenden Softwarekomponenten beteiligt:
  - Hart Software Services (HSS): Ein Null-Stagder Bootloader, Systemmonitor und Anbieter von Laufzeitdiensten für Anwendungen.
2. Startablauf
  Der Ablauf beim Systemstart ist wie folgt:
  1. Initialisierung von Hart Software Services (HSS)
  2. Bootloader-Ausführung
  3. Anwendungsstart
Wachhunde
1. PIC64GX Watchdog
  Der PIC64GX verfügt über eine Watchdog-Funktion, um den Systembetrieb zu überwachen und im Falle von Systemfehlern Aktionen auszulösen.
Sperrmodus
Der Sperrmodus ist für Kunden gedacht, die nach dem Booten vollständige Kontrolle über die Systemaktionen benötigen. Er schränkt die Funktionalitäten des E51-Systemmonitors ein.

Häufig gestellte Fragen

F: Was ist der Zweck der Hart Software Services (HSS)?
A: Das HSS dient als NullpunkttagDer Bootloader, Systemmonitor und Anbieter von Laufzeitdiensten für Anwendungen während des Bootvorgangs.
F: Wie funktioniert die Watchdog-Funktion des PIC64GX?
A: Der PIC64GX-Watchdog überwacht den Systembetrieb und kann bei Systemfehlern vordefinierte Maßnahmen ergreifen, um die Systemzuverlässigkeit sicherzustellen.

Einführung

Dieses Whitepaper erläutert, wie der Microchip PIC64GX Anwendungs-Workloads bootet und beschreibt den Systemstartprozess, der für SMP und AMP Workloads. Darüber hinaus wird erläutert, wie ein Neustart für SMP funktioniert und AMP Arbeitslasten, Watchdogs auf dem PIC64GX und ein spezieller Sperrmodus für Systeme, bei denen Kunden vollständige Kontrolle wünschen, um die Aktionen des E51-Systemmonitors nach dem Systemstart einzuschränken.

Bootvorgang

Werfen wir einen Blick auf die verschiedenen Softwarekomponenten, die am Systemstart beteiligt sind, und werfen wir anschließend einen genaueren Blick auf die Abfolge des Systemstartflusses selbst.

Am Bootvorgang beteiligte Softwarekomponenten
Am Systemstartvorgang sind folgende Komponenten beteiligt:

Abbildung 1.1. Startkomponenten

Hart Software Services (HSS)
Die Hart Software Services (HSS) sind ein Zero-StagDer Bootloader, ein Systemmonitor und ein Anbieter von Laufzeitdiensten für Anwendungen. Der HSS unterstützt die frühe Systemeinrichtung, DDR-Training und Hardwareinitialisierung/-konfiguration. Er läuft hauptsächlich auf den E51s, wobei eine kleine Menge an Funktionalität auf Maschinenmodusebene auf jedem U54s läuft. Er bootet einen oder mehrere Kontexte, indem er die Anwendungsnutzlast vom Bootmedium lädt, und stellt Platform Runtime Services/Supervisor Execution Environment (SEE) für Betriebssystemkernel bereit. Er unterstützt den sicheren Start und ist eine wichtige Komponente zur Gewährleistung der Hardwarepartitionierung/-trennung für AMP Kontexte.

Das U-Boot (U-Boot)
Das U-Boot (U-Boot) ist ein universeller, skriptfähiger Open-Source-Bootloader. Es unterstützt eine einfache CLI, die das Boot-Image aus verschiedenen Quellen abrufen kann (einschließlich einer SD-Karte und dem Netzwerk). U-Boot lädt Linux. Bei Bedarf kann es eine UEFI-Umgebung bereitstellen. Es ist im Allgemeinen fertig und aus dem Weg, sobald Linux gebootet hat – mit anderen Worten, es bleibt nach dem Booten nicht resident.
Linux-Kernel
Der Linux-Kernel ist der weltweit beliebteste Betriebssystemkernel. In Kombination mit einem Benutzerbereich von Anwendungen bildet er das, was allgemein als Linux-Betriebssystem bezeichnet wird. Ein Linux-Betriebssystem bietet umfangreiche POSIX-APIs und eine Entwicklerumgebung, z. B.ample, Sprachen und Tools wie Python, Perl, Tcl, Rust, C/C++ und Tcl; Bibliotheken wie OpenSSL, OpenCV, OpenMP, OPC/UA und OpenAMP (RPmsg und RemoteProc).
Yocto und Buildroot sind Linux-System-Builder, d. h. sie können verwendet werden, um maßgeschneiderte Linux-Systeme zu generieren. Yocto gibt eine Linux-Distribution mit einer reichhaltigen
Satz von Anwendungen, Tools und Bibliotheken sowie optionales Paketmanagement. Buildroot gibt ein minimaleres Root- fileSystem und kann auf Systeme abzielen, die keinen persistenten Speicher benötigen, sondern vollständig aus dem RAM laufen (unter Verwendung der Initialenunterstützung von Linux, z. B.ample).

Zephyr
Zephyr ist ein kleines, Open-Source-Echtzeitbetriebssystem (RTOS). Es bietet ein Echtzeit-Framework mit geringem Overhead und RPMsg-Lite-Kommunikationskanälen zu Linux. Es enthält einen Kernel, Bibliotheken, Gerätetreiber, Protokollstapel, fileSysteme, Mechanismen für Firmware-Updates usw. und ist ideal für Kunden, die sich auf PIC64GX eine Bare-Metal-ähnlichere Erfahrung wünschen.

Startablauf
PIC64GX enthält einen RISC-V-Coreplex mit einem 64-Bit-E51-Systemmonitor-Hart und 4 64-Bit-U54-Anwendungs-Harts. In der RISC-V-Terminologie ist ein Hart ein RISC-V-Ausführungskontext, der einen vollständigen Satz von Registern enthält und seinen Code unabhängig ausführt. Sie können es sich als Hardware-Thread oder einzelne CPU vorstellen. Eine Gruppe von Harts innerhalb eines einzelnen Kerns wird oft als Komplex bezeichnet. In diesem Thema werden die Schritte zum Initialisieren des PIC64GX-Coreplex beschrieben, einschließlich des E51-Systemmonitor-Herzstücks und der U54-Anwendungs-Harts.

Schalten Sie den PIC64GX-Coreplex ein.
Beim Einschalten werden alle Harts im RISC-V-Coreplex vom Sicherheitscontroller aus dem Reset freigegeben.
Führen Sie den HSS-Code vom On-Chip-eNVM-Flash-Speicher aus.
Zunächst startet jedes Herz den HSS-Code aus dem integrierten eNVM-Flash-Speicher. Dieser Code führt dazu, dass alle U54-Anwendungs-Harts rotieren und auf Anweisungen warten, und lässt das E51-Monitor-Hart Code ausführen, um das System zu initialisieren und hochzufahren.

Dekomprimieren Sie den HSS-Code von eNVM in den L2-Scratch-Speicher.
Abhängig von der Konfiguration zum Build-Zeitpunkt ist das HSS normalerweise größer als die Kapazität des eNVM-Flash-Speichers selbst. Daher besteht das erste, was der auf dem E51 ausgeführte HSS-Code tut, darin, sich selbst vom eNVM in den L2-Scratch-Speicher zu dekomprimieren, wie in Abbildung 1.2 und Abbildung 1.3 dargestellt.
Abbildung 1.2. HSS dekomprimiert von eNVM zu L2 Scratch
Abbildung 1.3. HSS-Speicherkarte während der Dekomprimierung
Springen Sie von eNVM zu L2-Scratch in eine ausführbare Datei, wie in der folgenden Abbildung gezeigt.
Abbildung 1.4. HSS springt nach der Dekomprimierung von eNVM in den Code, der jetzt in L2Scratch ist
Die ausführbare Datei besteht aus drei Komponenten:
- Die Hardwareabstraktionsschicht (HAL), Low-Level-Code und Bare-Metal-Treiber
- Ein lokaler HSS-Fork von RISC-V OpenSBI (leicht modifiziert von Upstream auf PIC64GX für AMP Zwecke)
- Die HSS-Laufzeitdienste (Zustandsmaschinen laufen in einer Superschleife)
Initialisieren Sie die von OpenSBI verwendete Hardware und Datenstrukturen.
Für diese Initialisierung ist der HSS-Dienst „Startup“ zuständig.

Holen Sie sich das Anwendungsworkload-Image (payload.bin) aus dem externen Speicher. Dies wird in Abbildung 1.5 und Abbildung 1.6 dargestellt.
Wichtig: Beim PIC64GX Curiosity Kit erfolgt dies von einer SD-Karte.
Abbildung 1.5. Abrufen des Workload-Images payload.bin aus einem externen Speicher
Abbildung 1.6. HSS-Speicherzuordnung nach dem Abrufen von payload.bin
Kopieren Sie die verschiedenen Abschnitte aus payload.bin an ihre Ausführungszeitziele. payload.bin ist ein formatiertes Image, das verschiedene Anwendungsimages für SMP oder AMP Arbeitslasten. Es enthält Code-, Daten- und Deskriptortabellen, die es dem HSS ermöglichen, die Code- und Datenabschnitte dort zu platzieren, wo sie zum Ausführen der verschiedenen Anwendungsarbeitslasten benötigt werden.
Abbildung 1.7. payload.bin wird an Zieladressen kopiert

Weisen Sie die relevanten U54s an, zu ihren Ausführungsstartadressen zu springen. Diese Startadressinformationen sind in der Datei payload.bin enthalten.
Starten Sie die U54 Anwendung harts und jede Sekunde-stage Bootloader. Zum Beispielample, U-Boot startet Linux.

Neustart

Mit dem Konzept des Systemstarts ist auch die Notwendigkeit eines Neustarts verbunden. Wenn man an die Arbeitslasten von PIC64GX-Anwendungen denkt, muss beim Neustart sowohl symmetrisches Multiprocessing (SMP) als auch asymmetrisches Multiprocessing (AMP) Szenarien:

Bei einem SMP-System kann durch einen Neustart ein sicherer Kaltneustart des gesamten Systems durchgeführt werden, da keine zusätzlichen Arbeitslasten in einem anderen Kontext berücksichtigt werden müssen.

Im Falle einer AMP System kann es sein, dass einer Arbeitslast nur der eigene Neustart gestattet ist (und sie darf keinen anderen Kontext beeinträchtigen) oder dass ihr die Berechtigung erteilt wird, einen vollständigen Systemneustart durchzuführen.

Neustart und AMP
Um das SMP zu aktivieren und AMP Neustartszenarien unterstützt das HSS die Konzepte von Warm- und Kaltstartberechtigungen, die einem Kontext zugewiesen werden können. Ein Kontext mit Warmstartberechtigung kann nur sich selbst neu starten, und ein Kontext mit Kaltstartberechtigung kann einen vollständigen Systemneustart durchführen. Zum BeispielampBetrachten Sie hierzu die folgenden repräsentativen Szenarien.

Eine SMP-Arbeitslast in einem einzigen Kontext, die einen vollständigen Systemneustart anfordern darf
In diesem Szenario ist für den Kontext die Berechtigung zum Kaltneustart zulässig.
Ein Zwei-Kontext AMP Arbeitslast, wobei Kontext A einen vollständigen Systemneustart anfordern darf (der alle Kontexte betrifft), und Kontext B sich nur selbst neu starten darf
In diesem Szenario wird Kontext A die Berechtigung zum Kaltneustart und Kontext B die Berechtigung zum Warmneustart gewährt.
Ein Zwei-Kontext AMP Arbeitslast, wobei die Kontexte A und B nur sich selbst neu starten dürfen (und den anderen Kontext nicht beeinflussen dürfen)
In diesem Szenario sind in beiden Kontexten nur Warm-Reboot-Berechtigungen zulässig.
Ein Zwei-Kontext AMP Arbeitslast, wobei sowohl Kontext A als auch Kontext B vollständige Systemneustarts anfordern dürfen
In diesem Szenario sind in beiden Kontexten Kaltstartberechtigungen zulässig.
Darüber hinaus ist es für den HSS zur Build-Zeit möglich, Kaltstartberechtigungen immer zuzulassen, aber auch niemals Kaltstartberechtigungen zuzulassen.

Relevante HSS-Kconfig-Optionen
Kconfig ist ein Software-Build-Konfigurationssystem. Es wird häufig verwendet, um Build-Time-Optionen auszuwählen und Funktionen zu aktivieren oder zu deaktivieren. Es stammt ursprünglich aus dem Linux-Kernel, wird aber mittlerweile auch in anderen Projekten außerhalb des Linux-Kernels verwendet, darunter U-Boot, Zephyr und PIC64GX HSS.

Das HSS enthält zwei Kconfig-Optionen, die die Neustartfunktionalität aus der HSS-Perspektive steuern:

CONFIG_ALLOW_COLD REBOOT
Wenn diese Option aktiviert ist, kann ein Kontext global einen Kaltstart-Ecall ausgeben. Wenn sie deaktiviert ist, sind nur Warmstarts zulässig. Zusätzlich zur Aktivierung dieser Option muss einem Kontext über den Payload-Generator YAML die Berechtigung zum Ausgeben eines Kaltstarts erteilt werden. file oder die folgende Kconfig-Option.
CONFIG_ALLOW_COLD REBOOT_ALWAYS
- Wenn diese Funktion aktiviert ist, können alle Kontexte global einen ECAA-Kaltstart ausführen, unabhängig von den Berechtigungen des Flags payload.bin.
- Darüber hinaus kann die Datei payload.bin selbst ein kontextbezogenes Flag enthalten, das angibt, dass ein bestimmter Kontext zum Ausführen von Kaltstarts berechtigt ist:
  - Um einem Kontext einen Warm-Reboot eines anderen Kontexts zu ermöglichen, können wir die Option allow-reboot: warm in die YAML-Beschreibung einfügen. file wird zum Erstellen der Datei payload.bin verwendet
  - Um einen kontextbezogenen Kaltstart des gesamten Systems zu ermöglichen, können wir die Option allow-reboot: cold hinzufügen. Ohne Angabe von allow-reboot ist einem Kontext standardmäßig nur ein Warmstart selbst gestattet. Unabhängig von der Einstellung dieses Flags wird das HSS alle Kaltstartanforderungen in warme (kontextbezogene) Neustarts umwandeln, wenn CONFIG_ALLOW_COLDREBOOT im HSS nicht aktiviert ist.

Neustart im Detail
In diesem Abschnitt wird detailliert beschrieben, wie der Neustart funktioniert. Dabei wird mit der OpenSBI-Schicht (der untersten M-Mode-Schicht) begonnen. Anschließend wird erläutert, wie die Funktionalität dieser OpenSBI-Schicht von einer RTOS-Anwendung oder einem umfangreichen Betriebssystem wie Linux ausgelöst wird.

OpenSBI Neustart Ecall

Die RISC-V Supervisor Binary Interface (SBI)-Spezifikation beschreibt eine standardisierte Hardwareabstraktionsschicht für Plattforminitialisierung und Firmware-Runtime-Dienste. Der Hauptzweck von SBI besteht darin, Portabilität und Kompatibilität zwischen verschiedenen RISC-V-Implementierungen zu ermöglichen.
OpenSBI (Open Source Supervisor Binary Interface) ist ein Open-Source-Projekt, das eine Referenzimplementierung der SBI-Spezifikation bereitstellt. OpenSBI bietet außerdem Laufzeitdienste, darunter Interrupt-Handling, Timer-Management und Konsolen-E/A, die von Softwareschichten höherer Ebene genutzt werden können.
OpenSBI ist Teil des HSS und wird auf der Ebene des Maschinenmodus ausgeführt. Wenn das Betriebssystem oder die Anwendung einen Trap verursacht, wird dieser zur Verarbeitung an OpenSBI weitergeleitet. OpenSBI stellt den oberen Schichten der Software über einen speziellen Trap-Mechanismus namens Ecall eine bestimmte Funktionalität vom Typ Systemaufruf zur Verfügung.

Der System-Reset (EID 0x53525354) bietet eine umfassende Systemaufruffunktion, mit der die Software der oberen Schicht einen Neustart oder ein Herunterfahren auf Systemebene anfordern kann. Sobald dieser Ecall von einem U54 aufgerufen wird, wird er von der HSS-Software abgefangen, die im Maschinenmodus auf diesem U54 ausgeführt wird, und eine entsprechende Neustartanforderung wird an den E51 gesendet, um je nach den Berechtigungen des Kontexts entweder den Kontext oder das gesamte System neu zu starten.

Weitere Informationen finden Sie im Spezifikation der binären RISC-V-Supervisor-Schnittstelle insbesondere Systemreset-Erweiterung (EID #0x53525354 „SRST“).

Linux-Neustart

Als spezifisches BeispielampIn Linux wird der Befehl shutdown verwendet, um das System anzuhalten oder neu zu starten. Der Befehl hat normalerweise viele Aliase, nämlich halt, power off und reboot. Diese Aliase geben an, ob die Maschine beim Herunterfahren angehalten, ausgeschaltet oder neu gestartet werden soll.

Diese Benutzerbereichsbefehle geben einen Neustartsystemaufruf an Linux aus, der vom Kernel abgefangen und in einen SBI-Ecall umgewandelt wird.
Es gibt verschiedene Neustartstufen – REBOOT_WARM, REBOOT_COLD, REBOOT_HARD – diese können als Kommandozeilenargumente an den Kernel übergeben werden (z.B.ample, reboot=w[arm] für REBOOT_WARM). Weitere Informationen zum Linux-Kernel-Quellcode finden Sie unter Dokumentation/Admin-Handbuch/Kernel-Parameter.txt.
Alternativ können, wenn /sys/kernel/reboot aktiviert ist, die darunterliegenden Handler gelesen werden, um die aktuelle Systemneustartkonfiguration abzurufen, und geschrieben werden, um sie zu ändern. Weitere Informationen zum Linux-Kernel-Quellcode finden Sie unter Dokumentation/ABI/Testen/Sysfs-Kernel-Neustart.

Wachhunde

Ein weiteres Konzept im Zusammenhang mit dem Systemstart und Systemneustart ist die Systemwiederherstellung nach Auslösen eines Watchdog-Timers. Watchdog-Timer werden in eingebetteten Systemen häufig verwendet, um nach vorübergehenden Hardwarefehlern automatisch eine Wiederherstellung durchzuführen und um zu verhindern, dass fehlerhafte oder bösartige Software den Systembetrieb stört.
PIC64GX bietet Hardware-Watchdog-Unterstützung zur Überwachung der einzelnen Harts bei laufendem System. Die Watchdogs stellen sicher, dass die Harts neu gestartet werden können, wenn sie aufgrund nicht behebbarer Softwarefehler nicht reagieren.
PIC64GX enthält fünf Instanzen von Watchdog-Timer-Hardwareblöcken zur Erkennung von Systemabstürzen – eine für jeden der Harts. Um gemischte asymmetrische Mehrfachverarbeitung zu ermöglichen (AMP)-Arbeitslasten unterstützt das HSS die Überwachung und Reaktion auf das Auslösen der Watchdogs.

PIC64GX Watchdog

Das HSS ist verantwortlich für das Booten der Anwendungshardware beim Einschalten und für den Neustart (einzeln oder gemeinsam) bei jedem Neustart.tage, falls dies erforderlich oder gewünscht ist. Infolgedessen wird die Reaktion auf Watchdog-Ereignisse auf dem PIC64GX vom HSS übernommen.
Ein „virtueller Watchdog“-Monitor wird als HSS-Zustandsmaschinendienst implementiert und ist dafür verantwortlich, den Status jedes einzelnen U54-Watchdog-Hardwaremonitors zu überwachen. Wenn einer dieser U54-Watchdogs auslöst, erkennt dies das HSS und startet den U54 entsprechend neu. Wenn der U54 Teil eines SMP-Kontexts ist, wird der gesamte Kontext für den Neustart berücksichtigt, sofern der Kontext über die Berechtigung zum Warmstart verfügt. Das gesamte System wird neu gestartet, wenn der Kontext über die Berechtigung zum Kaltstart verfügt.

Relevante Kconfig-Optionen

Watchdog-Unterstützung ist standardmäßig in veröffentlichten HSS-Builds enthalten. Wenn Sie ein benutzerdefiniertes HSS erstellen möchten, beschreibt dieser Abschnitt den Konfigurationsmechanismus, um sicherzustellen, dass die Watchdog-Unterstützung aktiviert ist.

Die Konfiguration des HSS erfolgt über das Konfigurationssystem Kconfig. Eine Toplevel-.config file wird benötigt, um auszuwählen, welche Dienste in den HSS-Build hinein oder daraus heraus kompiliert werden.
Zuerst muss die oberste Option CONFIG_SERVICE_WDOG aktiviert werden („Virtual Watchdog support“ über make config).

Dadurch werden die folgenden Unteroptionen verfügbar, die von der Watchdog-Unterstützung abhängig sind:

CONFIG_SERVICE_WD OG_DEBUG
Aktiviert die Unterstützung für Informations-/Debugmeldungen vom virtuellen Watchdog-Dienst.
CONFIG_SERVICE_WD OG_DEBUG_TIMEOUT_SECS
Bestimmt die Periodizität (in Sekunden), in der Watchdog-Debugmeldungen vom HSS ausgegeben werden.
CONFIG_SERVICE_WD OG_ENABLE_E51
Aktiviert den Watchdog für das Herz des E51-Monitors zusätzlich zu den U54s und schützt so den Betrieb des HSS selbst.

Wenn der E51-Watchdog aktiviert ist, schreibt das HSS regelmäßig in den Watchdog, um ihn zu aktualisieren und zu verhindern, dass er ausgelöst wird. Wenn das E51-Herz aus irgendeinem Grund blockiert oder abstürzt und der E51-Watchdog aktiviert ist, wird dadurch immer das gesamte System zurückgesetzt.

Watchdog-Betrieb
Die Watchdog-Hardware implementiert Abwärtszähler. Ein Fenster ohne Aktualisierungsverbot kann erstellt werden, indem der Watchdog-Maximalwert, bis zu dem eine Aktualisierung zulässig ist (MVRP), konfiguriert wird.

Wenn der aktuelle Wert des Watchdog-Timers größer als der MVRP-Wert ist, ist das Aktualisieren des Watchdogs verboten. Der Versuch, den Watchdog-Timer im verbotenen Fenster zu aktualisieren, führt zu einem Timeout-Interrupt.

Durch das Aktualisieren des Watchdogs zwischen dem MVRP-Wert und dem Triggerwert (TRIG) wird der Zähler erfolgreich aktualisiert und ein Auslösen des Watchdogs verhindert.
Sobald der Watchdog-Timerwert unter den TRIG-Wert fällt, wird der Watchdog ausgelöst.

Watchdog-Zustandsmaschine

Die Watchdog-Zustandsmaschine ist sehr unkompliziert: Sie startet mit der Konfiguration des Watchdogs für den E51, sofern aktiviert, und wechselt dann über einen Ruhezustand in den Überwachungszustand. Bei jedem Durchlauf des Superloops wird dieser Überwachungszustand aufgerufen, der den Status jedes einzelnen U54-Watchdogs überprüft.

Die Watchdog-Zustandsmaschine interagiert mit der Boot-Zustandsmaschine, um ein Hart (und alle anderen Harts in seinem Boot-Set) neu zu starten, wenn sie erkennt, dass das Hart seinen Watchdog nicht rechtzeitig aktualisieren konnte.

Sperrmodus

Normalerweise (besonders bei AMP Anwendungen) wird erwartet, dass das HSS im M-Modus auf einem U54 verbleibt, um einen kontextbezogenen Neustart zu ermöglichen (d. h. einen Neustart nur eines Kontexts ohne Neustart des gesamten Chips) und um dem HSS die Überwachung des Zustands (ECCs, Sperrstatusbits, Busfehler, SBI-Fehler, PMP-Verletzungen usw.) zu ermöglichen.

Um die Möglichkeit zum Neustarten eines Computers zuAMP Kontextbasiert (ohne dass das gesamte System neu gestartet werden muss) hat der E51 normalerweise privilegierten Speicherzugriff auf den gesamten Speicherbereich des Systems. Es kann jedoch Situationen geben, in denen dies nicht erwünscht ist und der Kunde es vorziehen könnte, die Aktionen der E51 HSS-Firmware nach dem erfolgreichen Systemstart einzuschränken. In diesem Fall ist es möglich, den HSS in den Sperrmodus zu versetzen, nachdem die U54 Application Harts gestartet wurden.

Dies kann mit der HSS-Kconfig-Option CONFIG_SERVICE_LOCKDOWN aktiviert werden.
Der Lockdown-Dienst soll eine Einschränkung der Aktivitäten des HSS nach dem Booten der U54-Anwendung Harts ermöglichen.

Abbildung 4.2. HSS-Sperrmodus

Sobald der Lockdown-Modus startet, stoppt er die Ausführung aller anderen HSS-Dienstzustandsmaschinen. Er ruft zwei schwach gebundene Funktionen auf:

e51_pmp_lockdown() und
e51_lockdown()

Diese Funktionen sollen durch kartenspezifischen Code überschrieben werden. Die erste ist eine konfigurierbare Triggerfunktion, die es einem BSP ermöglicht, die Sperrung des E51 von den Anwendungsnutzlasten an diesem Punkt anzupassen. Die schwach gebundene Standardimplementierung dieser Funktion ist leer. Die zweite ist die Funktionalität, die ab diesem Punkt ausgeführt wird. Die schwach gebundene Standardimplementierung bedient den Watchdog an diesem Punkt im E51 und führt einen Neustart durch, wenn ein U54-Watchdog ausgelöst wird. Weitere Informationen finden Sie im HSS-Quellcode in services/lockdown/lockdown_service.c file.

Anhang

HSS payload.bin-Format

Dieser Abschnitt beschreibt die Datei payload.bin file Format und das Image, das vom HSS zum Booten von PIC64GX SMP verwendet wird und AMP Anwendungen.
Die Datei payload.bin ist eine formatierte Binärdatei (Abbildung A.10), die aus einem Kopf, verschiedenen Deskriptortabellen und verschiedenen Blöcken besteht, die die Code- und Datenabschnitte jedes Teils der Anwendungsarbeitslast enthalten. Ein Block kann als zusammenhängender Speicherblock beliebiger Größe betrachtet werden.

Abbildung A.10. payload.bin-Format

Der Header-Teil (siehe Abbildung A.11) enthält einen magischen Wert zur Identifizierung der Datei payload.bin und einige Verwaltungsinformationen sowie Details des Images, das auf den einzelnen
U54-Anwendungscodes. Es beschreibt, wie jedes einzelne U54-Hart gebootet wird, und den Satz bootfähiger Images insgesamt. In seinen Verwaltungsinformationen enthält es Zeiger auf verschiedene Deskriptortabellen, um eine Vergrößerung der Header-Größe zu ermöglichen.

Abbildung A.11. payload.bin-Header

Code und initialisierte Konstantendaten gelten als schreibgeschützt und werden in einem schreibgeschützten Abschnitt gespeichert, auf den von Header-Deskriptoren verwiesen wird.
Bei initialisierten Datenvariablen ungleich Null handelt es sich um Lese-/Schreibdaten, deren Initialisierungswerte jedoch beim Start aus dem schreibgeschützten Block kopiert werden. Diese werden ebenfalls im schreibgeschützten Abschnitt gespeichert.

Der schreibgeschützte Nutzdatenabschnitt wird durch eine Tabelle mit Code- und Datenblockdeskriptoren beschrieben. Jeder Blockdeskriptor in dieser Tabelle enthält einen „Hart-Eigentümer“ (das Haupt-Hart im Zielkontext).
at), einen Ladeoffset (Offset innerhalb von payload.bin) und eine Ausführungsadresse (Zieladresse im PIC64GX-Speicher) zusammen mit einer Größe und Prüfsumme. Dies ist in Abbildung A.12 dargestellt.

Abbildung A.12. Nur-Lese-Chunk-Deskriptor und Payload-Chunk-Daten

Zusätzlich zu den oben genannten Blöcken gibt es auch Speicherblöcke, die Datenvariablen entsprechen, die auf Null initialisiert sind. Diese werden nicht als Daten in payload.bin gespeichert, sondern sind ein spezieller Satz von nullinitialisierten Blockdeskriptoren, die eine Adresse und Länge des RAM angeben, die beim Start auf Null gesetzt werden sollen. Dies ist in Abbildung A.13 dargestellt.

Abbildung A.13. ZI-Chunks

HSS-Nutzlastgenerator
Das HSS Payload Generator-Tool erstellt ein formatiertes Payload-Image für den Hart Software Service Zero-StagDer Bootloader auf PIC64GX bei einer Konfiguration file und ein Satz ELF files und/oder Binärdateien. Die Konfiguration file wird verwendet, um die ELF-Binärdateien oder Binärblobs den einzelnen Anwendungs-Harts (U54s) zuzuordnen.

Abbildung B.14. hss-payload-generator-Flow

Das Tool führt grundlegende Plausibilitätsprüfungen der Struktur der Konfiguration durch file selbst und auf den ELF-Images. ELF-Images müssen ausführbare RISC-V-Dateien sein.

Example Lauf

Um das Tool hss-payload-generator mit dem s auszuführenample Konfiguration file und ELF files:
$ ./hss-payload-generator -c test/config.yaml output.bin
Um Diagnoseinformationen zu einem bereits vorhandenen Bild auszudrucken, verwenden Sie:
$ ./hss-payload-generator -d output.bin

Um die sichere Boot-Authentifizierung (über Image-Signierung) zu aktivieren, verwenden Sie -p, um den Speicherort eines privaten X.509-Schlüssels für die Elliptic Curve P-384 (SECP384r1) anzugeben:
$ ./hss-payload-generator -c test/config.yaml payload.bin -p /Pfad/zu/private.pem

Weitere Informationen finden Sie in der Dokumentation zur Secure Boot-Authentifizierung.

Konfiguration File Example

Zunächst können wir optional einen Namen für unser Image festlegen, andernfalls wird dynamisch einer erstellt:
Setname: 'PIC64-HSS::TestImage'
Als Nächstes definieren wir die Einstiegspunktadressen für jedes Herz wie folgt:
hart-entry-points: {u54_1: ‘0x80200000’, u54_2: ‘0x80200000’, u54_3: ‘0xB0000000′, u54_4:’0x80200000’}

Die ELF-Quellbilder können einen Einstiegspunkt angeben, aber wir möchten bei Bedarf sekundäre Einstiegspunkte für Harts unterstützen können, zum BeispielampWenn mehrere Harts dasselbe Image booten sollen, können sie individuelle Einstiegspunkte haben. Um dies zu unterstützen, geben wir die tatsächlichen Einstiegspunktadressen in der Konfiguration an. file selbst.

Wir können nun einige Nutzlasten definieren (Quelle ELF files oder Binärblobs), die in bestimmten Regionen im Speicher abgelegt werden. Der Payload-Abschnitt wird mit dem Schlüsselwort payloads und dann einer Reihe einzelner Payload-Deskriptoren definiert. Jede Payload hat einen Namen (Pfad zu ihrer file), ein Eigentümer-Hart und optional 1 bis 3 sekundäre Harts.

Darüber hinaus verfügt eine Nutzlast über einen Berechtigungsmodus, in dem sie die Ausführung startet. Gültige Berechtigungsmodi sind PRV_M, PRV_S und PRV_U, wobei diese wie folgt definiert sind:

PRV_M Maschinenmodus
PRV_S Supervisor-Modus
PRV_U Benutzermodus

Im folgenden Beispielampauf:

Bei test/zephyr.elf wird davon ausgegangen, dass es sich um eine Zephyr-Anwendung handelt, die in U54_3 ausgeführt wird und im Berechtigungsmodus PRV_M gestartet werden soll.
test/u-boot-dtb.bin ist die Bootloader-Anwendung von Das U-Boot und läuft auf U54_1, U54_2 und U54_4. Sie startet voraussichtlich im privilegierten PRV_S-Modus.

Wichtig:
Die Ausgabe von U-Boot erzeugt ein ELF file, aber normalerweise wird die Erweiterung .elf nicht vorangestellt. In diesem Fall wird die von CONFIG_OF_SEPARATE erstellte Binärdatei verwendet, die einen Gerätebaum-Blob an die U-Boot-Binärdatei anhängt.

Hier ist der Example Payloads-Konfiguration 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', Besitzer-Hart: u54_1, Sekundär-Hart: u54_2, Sekundär-Hart: u54_4, Priv-Modus: prv_s}

Wichtig:
Die Groß- und Kleinschreibung ist nur wichtig für file Pfadnamen, nicht die Schlüsselwörter. So wird beispielsweise u54_1 als dasselbe wie U54_1 angesehen und exec-addr als dasselbe wie EXEC-ADDR. Wenn eine .elf- oder .bin-Erweiterung vorhanden ist, muss sie in die Konfiguration aufgenommen werden file.

Für eine Bare-Metal-Anwendung, die sich nicht mit OpenSBI befassen möchte, bewirkt die Option skip-opens, wenn sie wahr ist, dass die Nutzlast auf diesem Kern mit einem einfachen mret aufgerufen wird, anstatt
als ein OpenSBI sbi_init()-Aufruf. Das bedeutet, dass das Herzstück den Bare-Metal-Code unabhängig von OpenSBI HSM-Überlegungen ausführen wird. Beachten Sie, dass das Herzstück dadurch auch nicht verwenden kann
ecalls zum Aufrufen der OpenSBI-Funktionalität. Die Option „skip-opens“ ist optional und standardmäßig auf „false“ eingestellt.

Um einen kontextbezogenen Warm-Reboot eines anderen Kontexts zuzulassen, können wir die Option allow reboot: warm hinzufügen. Um einen kontextbezogenen Kalt-Reboot des gesamten Systems zuzulassen, können wir die Option allow-reboot: cold hinzufügen. Ohne Angabe von allow-reboot darf ein Kontext standardmäßig nur einen Warm-Reboot für sich selbst durchführen.
Es ist auch möglich, jeder Nutzlast Zusatzdaten zuzuordnen, zum Beispielample, ein DeviceTree Blob (DTB) filedurch Angabe der Zusatzdaten filewie folgt benennen:
test/u-boot.bin: { exec-addr: '0x80200000', Besitzer-Hart: u54_1, Sekundär-Hart: u54_2, Sekundär-Hart: u54_3, Sekundär-Hart: u54_4, Priv-Modus: prv_s, Zusatzdaten: test/pic64gx.dtb }
Diese Zusatzdaten werden in die Nutzlast aufgenommen (direkt nach dem Hauptdatensatz platziert). file in der ausführbaren Datei
Leerzeichen) und seine Adresse wird im Feld next_arg1 an OpenSBI übergeben (das beim Booten im Register $a1 an das Image übergeben wird).

Um zu verhindern, dass der HSS automatisch einen Kontext bootet (beispielsweise wenn wir die Steuerung hierüber stattdessen an einen Kontext delegieren möchten, der remoteProc verwendet), verwenden Sie das Flag „skip-autoboot“:
test/zephyr.elf: {exec-addr: '0xB0000000', owner-hart: u54_3, priv-mode: prv_m, skip-opensbi: true, skip-autoboot: true}
Schließlich können wir optional die Namen einzelner Payloads überschreiben, indem wir die Option payload-name verwenden. Zum Beispielampauf:
test/u-boot.bin: { exec-addr: '0x80200000', Besitzer-Hart: u54_1, Sekundär-Hart: u54_2, Sekundär-Hart: u54_3, Sekundär-Hart: u54_4, Priv-Modus: prv_s, Zusatzdaten: test/pic64gx.dtb, Payload-Name: 'u-boot' }

Beachten Sie, dass die Linux-Builder Yocto und Buildroot die hss-payload erstellen, konfigurieren und ausführen.
Generator nach Bedarf, um Anwendungsbilder zu erzeugen. Zusätzlich ist das pic64gx-curiosity-kit-amp machine target in Yocto generiert ein Anwendungsimage mit dem hss-payload-generator-Tool, das demonstriert AMP, wobei Linux auf 3 Harts und Zephyr auf 1 Hart läuft.

Änderungsverlauf
Der Revisionsverlauf beschreibt die Änderungen, die im Dokument vorgenommen wurden. Die Änderungen werden nach Revision aufgelistet, beginnend mit der aktuellsten Veröffentlichung.

Revision	Datum	Beschreibung
A	07/2024	Erstrevision

Mikrochip-Informationen

Der Mikrochip WebWebsite
Microchip bietet Online-Support über unsere webSeite unter www.microchip.com/. Das webWebsite wird verwendet, um files und Informationen für Kunden leicht zugänglich. Einige der verfügbaren Inhalte umfassen:

Produkt-Support – Datenblätter und Errata, Anwendungshinweise und sampDateiprogramme, Designressourcen, Benutzerhandbücher und Hardware-Supportdokumente, neueste Softwareversionen und archivierte Software

Allgemeiner technischer Support – Häufig gestellte Fragen (FAQs), Anfragen zum technischen Support, Online-Diskussionsgruppen, Mitgliederliste des Microchip-Designpartnerprogramms
Geschäft von Microchip – Produktauswahl- und Bestellleitfäden, aktuelle Pressemitteilungen von Microchip, eine Liste von Seminaren und Veranstaltungen, Listen von Microchip-Verkaufsbüros, Distributoren und Fabrikvertretern

Benachrichtigungsservice für Produktänderungen

Der Benachrichtigungsservice für Produktänderungen von Microchip hilft Kunden, die Produkte von Microchip auf dem Laufenden zu halten. Abonnenten erhalten E-Mail-Benachrichtigungen, wenn Änderungen, Aktualisierungen, Überarbeitungen oder Errata in Bezug auf eine bestimmte Produktfamilie oder ein Entwicklungstool von Interesse vorliegen.

Um sich zu registrieren, gehen Sie zu www.microchip.com/pcn und folgen Sie den Registrierungsanweisungen.

Kundenservice
Benutzer von Microchip-Produkten können über mehrere Kanäle Unterstützung erhalten:

Vertriebshändler oder Vertreter
Lokales Verkaufsbüro
Ingenieur für eingebettete Lösungen (ESE)
Technische Unterstützung

Kunden sollten sich für Unterstützung an ihren Händler, Vertreter oder ESE wenden. Lokale Verkaufsbüros stehen den Kunden ebenfalls zur Verfügung. Eine Liste der Verkaufsbüros und -standorte ist in diesem Dokument enthalten.
Technischen Support erhalten Sie über die webWebsite unter: www.microchip.com/support.

Codeschutzfunktion von Microchip Devices
Beachten Sie die folgenden Details zur Codeschutzfunktion bei Microchip-Produkten:

Mikrochipprodukte erfüllen die in ihrem jeweiligen Mikrochip-Datenblatt enthaltenen Spezifikationen.
Microchip ist davon überzeugt, dass seine Produktfamilie sicher ist, wenn sie bestimmungsgemäß, innerhalb der Betriebsspezifikationen und unter normalen Bedingungen verwendet wird.

Microchip legt großen Wert auf seine geistigen Eigentumsrechte und schützt diese mit Nachdruck. Versuche, die Codeschutzfunktionen von Microchip-Produkten zu verletzen, sind streng verboten und können einen Verstoß gegen den Digital Millennium Copyright Act darstellen.
Weder Microchip noch ein anderer Halbleiterhersteller kann die Sicherheit seines Codes garantieren. Codeschutz bedeutet nicht, dass wir garantieren, dass das Produkt „unknackbar“ ist. Der Codeschutz entwickelt sich ständig weiter. Microchip ist bestrebt, die Codeschutzfunktionen unserer Produkte kontinuierlich zu verbessern.

Rechtliche Hinweise
Diese Veröffentlichung und die darin enthaltenen Informationen dürfen nur mit Microchip-Produkten verwendet werden, einschließlich zum Entwerfen, Testen und Integrieren von Microchip-Produkten in Ihre Anwendung. Die anderweitige Verwendung dieser Informationen verstößt gegen diese Bedingungen. Informationen zu Geräteanwendungen werden nur zu Ihrer Bequemlichkeit bereitgestellt und können durch Aktualisierungen ersetzt werden. Es liegt in Ihrer Verantwortung sicherzustellen, dass Ihre Anwendung Ihren Spezifikationen entspricht. Wenden Sie sich für weitere Unterstützung an Ihr lokales Microchip-Verkaufsbüro oder erhalten Sie weitere Unterstützung unter www.microchip.com/en-us/support/design-help/client-support-services.

DIESE INFORMATIONEN WERDEN VON MICROCHIP „WIE BESEHEN“ BEREITGESTELLT. MICROCHIP GIBT KEINE ZUSICHERUNGEN ODER GARANTIEN JEGLICHER ART, WEDER AUSDRÜCKLICH NOCH STILLSCHWEIGEND, SCHRIFTLICH ODER MÜNDLICH, GESETZLICH ODER ANDERWEITIG, IN BEZUG AUF DIE INFORMATIONEN, EINSCHLIESSLICH, ABER NICHT BESCHRÄNKT AUF STILLSCHWEIGENDE GARANTIEN DER NICHTVERLETZUNG, MARKTGÄNGIGKEIT UND EIGNUNG FÜR EINEN BESTIMMTEN ZWECK ODER GARANTIEN IN BEZUG AUF IHREN ZUSTAND, IHRE QUALITÄT ODER LEISTUNG.

MICROCHIP ÜBERNIMMT IN KEINEM FALL HAFTUNG FÜR INDIREKTE, BESONDERE, STRAFENDE, ZUFÄLLIGE ODER FOLGEVERLUSTE, SCHÄDEN, KOSTEN ODER AUSGABEN JEGLICHER ART, DIE MIT DEN INFORMATIONEN ODER IHRER VERWENDUNG IN ZUSAMMENHANG STEHEN, JEGLICH DER URSACHE, SELBST WENN MICROCHIP HIERVON INFORMIERT WURDE MÖGLICHKEIT ODER DIE SCHÄDEN SIND VORHERSEHBAR. SOWEIT GESETZLICH ZULÄSSIG, ÜBERSTEIGT DIE GESAMTHAFTUNG VON MICROCHIP FÜR ALLE ANSPRÜCHE, DIE IN IRGENDEINER WEISE IM ZUSAMMENHANG MIT DEN INFORMATIONEN ODER IHRER VERWENDUNG SIND, NICHT DIE ANZAHL DER GEBÜHREN, DIE SIE GEGEBENENFALLS DIREKT AN MICROCHIP FÜR DIE INFORMATIONEN GEZAHLT HABEN.

Die Verwendung von Microchip-Geräten in lebenserhaltenden und/oder sicherheitsrelevanten Anwendungen erfolgt vollständig auf Risiko des Käufers und der Käufer erklärt sich damit einverstanden, Microchip von allen Schäden, Ansprüchen, Klagen oder Kosten, die sich aus einer solchen Verwendung ergeben, zu verteidigen, schadlos zu halten und schadlos zu halten. Sofern nicht anders angegeben, werden keine Lizenzen im Rahmen der geistigen Eigentumsrechte von Microchip übertragen, weder stillschweigend noch anderweitig.

Handelsmarken
Der Name und das Logo von Microchip, das Microchip-Logo, Adaptec, AVR, AVR-Logo, AVR Freaks, BesTime, BitCloud, CryptoMemory, CryptoRF, dsPIC, flexPWR, HELDO, IGLOO, JukeBlox, KeeLoq, Kleer, LANCheck, LinkMD, maXStylus, maXTouch, MediaLB, megaAVR, Microsemi, Microsemi-Logo, MOST, MOST-Logo, MPLAB, OptoLyzer, PIC, picoPower, PICSTART, PIC32-Logo, PolarFire, Prochip Designer, QTouch, SAM-BA, SenGenuity, SpyNIC, SST, SST-Logo, SuperFlash, Symmetricom , SyncServer, Tachyon, TimeSource, tinyAVR, UNI/O, Vectron und XMEGA sind eingetragene Warenzeichen von Microchip Technology Incorporated in den USA und anderen Ländern.

AgileSwitch, ClockWorks, The Embedded Control Solutions Company, EtherSynch, Flashtec, Hyper Speed Control, HyperLight Load, Libero, Motorbank, mTouch, Powermite 3, Precision Edge, ProASIC, ProASIC Plus, ProASIC Plus-Logo, Quiet-Wire, SmartFusion, SyncWorld , TimeCesium, TimeHub, TimePictra, TimeProvider und ZL sind eingetragene Marken von Microchip Technology Incorporated in den USA

Unterdrückung benachbarter Tasten, AKS, Analog für das digitale Zeitalter, Jeder Kondensator, AnyIn, AnyOut, Erweitertes Switching, BlueSky, BodyCom, Clockstudio, CodeGuard, CryptoAuthentication, CryptoAutomotive, CryptoCompanion, CryptoController, dsPICDEM, dsPICDEM.net, Dynamisches Durchschnittsmatching, DAM, ECAN, Espresso T1S, EtherGREEN, EyeOpen, GridTime, IdealBridge,
IGaT, In-Circuit-Serielles Programmieren, ICSP, INICnet, Intelligente Parallelisierung, IntelliMOS, Inter-Chip-Konnektivität, JitterBlocker, Knob-on-Display, MarginLink, maxCrypto, maxView, memBrain, Mindi, MiWi, MPASM, MPF, MPLAB-zertifiziertes Logo, MPLIB, MPLINK, mSiC, MultiTRAK, NetDetach, Allwissende Codegenerierung, PICDEM, PICDEM.net, PICkit, PICtail, Power MOS IV, Power MOS 7, PowerSmart, PureSilicon, QMatrix, REAL ICE, Ripple Blocker, RTAX, RTG4, SAM-ICE, Serielles Quad-E/A, einfache Karte, 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 und ZENA sind Marken von Microchip Technology Incorporated in den USA und anderen Ländern.

SQTP ist eine Dienstleistungsmarke von Microchip Technology Incorporated in den USA
Das Adaptec-Logo, Frequency on Demand, Silicon Storage Technology und Symmcom sind eingetragene Warenzeichen von Microchip Technology Inc. in anderen Ländern.
GestIC ist in anderen Ländern eine eingetragene Marke der Microchip Technology Germany II GmbH & Co. KG, einer Tochtergesellschaft der Microchip Technology Inc.

ISBN-Nummer: 978-1-6683-4890-1

Qualitätsmanagementsystem
Informationen zu den Qualitätsmanagementsystemen von Microchip finden Sie unter www.microchip.com/quality.

Weltweiter Vertrieb und Service

AMERIKA

ASIEN/PAZIFIK

EUROPA

Unternehmen Büro

2355 West Chandler Blvd. Chandler, AZ 85224-6199

Tel: 480-792-7200

Fax: 480-792-7277

Technische Unterstützung: www.microchip.com/support

Web Adresse: www.microchip.com

Atlanta

Duluth, Georgia

Tel: 678-957-9614

Fax: 678-957-1455

Austin, Texas

Tel: 512-257-3370

Boston

Westborough, MA Tel: 774-760-0087

Fax: 774-760-0088

Chicago

Itasca, Illinois

Tel: 630-285-0071

Fax: 630-285-0075

Dallas

Addison, TX

Tel: 972-818-7423

Fax: 972-818-2924

Detroit

Novi, Michigan

Tel: 248-848-4000

Houston, TX

Tel: 281-894-5983

Indianapolis

Noblesville, IN Tel.: 317-773-8323

Fax: 317-773-5453

Tel: 317-536-2380

Los Angeles

Mission Viejo, CA Tel.: 949-462-9523

Fax: 949-462-9608

Tel: 951-273-7800

Raleigh, NC

Tel: 919-844-7510

New York, NY

Tel: 631-435-6000

San José, CA

Tel: 408-735-9110

Tel: 408-436-4270

Kanada – Toronto

Tel: 905-695-1980

Fax: 905-695-2078

Australien – Sydney

Tel: 61-2-9868-6733

China – Peking

Tel: 86-10-8569-7000

China – Chengdu

Tel: 86-28-8665-5511

China – Chongqing

Tel: 86-23-8980-9588

China – Dongguan

Tel: 86-769-8702-9880

China – Guangzhou

Tel: 86-20-8755-8029

China – Hangzhou

Tel: 86-571-8792-8115

China – Hong Kong SAR

Tel: 852-2943-5100

China – Nanjing

Tel: 86-25-8473-2460

China – Qingdao

Tel: 86-532-8502-7355

China – Shanghai

Tel: 86-21-3326-8000

China – Shenyang

Tel: 86-24-2334-2829

China – Shenzhen

Tel: 86-755-8864-2200

China – Suzhou

Tel: 86-186-6233-1526

China – Wuhan

Tel: 86-27-5980-5300

China – Xi’an

Tel: 86-29-8833-7252

China – Xiamen

Tel: 86-592-2388138

China – Zhuhai

Tel: 86-756-3210040

Indien – Bangalore

Tel: 91-80-3090-4444

Indien – Neu-Delhi

Tel: 91-11-4160-8631

Indien – Pune

Tel: 91-20-4121-0141

Japan – Osaka

Tel: 81-6-6152-7160

Japan – Tokio

Tel: 81-3-6880-3770

Korea – Daegu

Tel: 82-53-744-4301

Korea – Seoul

Tel: 82-2-554-7200

Malaysia – Kuala Lumpur

Tel: 60-3-7651-7906

Malaysia – Penang

Tel: 60-4-227-8870

Philippinen – Manila

Tel: 63-2-634-9065

Singapur

Tel: 65-6334-8870

Taiwan – Hsin Chu

Tel: 886-3-577-8366

Taiwan – Kaohsiung

Tel: 886-7-213-7830

Taiwan – Taipeh

Tel: 886-2-2508-8600

Thailand – Bangkok

Tel: 66-2-694-1351

Vietnam – Ho Chi Minh

Tel: 84-28-5448-2100

Österreich – Wels

Tel: 43-7242-2244-39

Fax: 43-7242-2244-393

Dänemark – Kopenhagen

Tel: 45-4485-5910

Fax: 45-4485-2829

Finnland – Espoo

Tel: 358-9-4520-820

Frankreich – Paris

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

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

Deutschland – Garching

Tel: 49-8931-9700

Deutschland – Haan

Tel: 49-2129-3766400

Deutschland – Heilbronn

Tel: 49-7131-72400

Deutschland – Karlsruhe

Tel: 49-721-625370

Deutschland – München

Tel: 49-89-627-144-0

Fax: 49-89-627-144-44

Deutschland – Rosenheim

Tel: 49-8031-354-560

Israel – Hod Hasharon

Tel: 972-9-775-5100

Italien – Mailand

Tel: 39-0331-742611

Fax: 39-0331-466781

Italien – Padua

Tel: 39-049-7625286

Niederlande – Drunen

Tel: 31-416-690399

Fax: 31-416-690340

Norwegen – Trondheim

Tel: 47-72884388

Polen – Warschau

Tel: 48-22-3325737

Rumänien – Bukarest

Tel: 40-21-407-87-50

Spanien – Madrid

Tel: 34-91-708-08-90

Fax: 34-91-708-08-91

Schweden – Göteborg

Tel: 46-31-704-60-40

Schweden – Stockholm

Tel: 46-8-5090-4654

Großbritannien – Wokingham

Tel: 44-118-921-5800

Fax: 44-118-921-5820

Dokumente / Ressourcen

MICROCHIP PIC64GX 64-Bit RISC-V Quad-Core-Mikroprozessor [pdf] Benutzerhandbuch
PIC64GX, PIC64GX 64-Bit RISC-V Quad-Core-Mikroprozessor, 64-Bit RISC-V Quad-Core-Mikroprozessor, RISC-V Quad-Core-Mikroprozessor, Quad-Core-Mikroprozessor, Mikroprozessor

Verweise

Bedienungsanleitung

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

Produktinformationen

Anweisungen zur Produktverwendung