Der Blätterkatalog benötigt Javascript.
Bitte aktivieren Sie Javascript in Ihren Browser-Einstellungen.
The Blätterkatalog requires Javascript.
Please activate Javascript in your browser settings.
22 Elektronik 03 2020 embedded abgelegt dem Wurzelverzeichnis unter Linux unter Windows C \\ Get_ firmware ist bereits implementiert Im nächsten Schritt werden ein über die Ressourcentabelle definierter Speicherbereich reserviert und darin die Strukturen für die Interprozessorkommunikation sowie die Datenund Textsektionen der Firmware abgelegt Zum Schluss wird der Remote-Prozessor RP mit Takt versorgt und der Reset ausgelöst Der Master wartet auf eine Nachricht des RP über IPC und baut dann die Verbindung via VirtIO RPMsg siehe folgenden Abschnitt auf Nach Auslösen des Reset-Signals startet der Remote-Prozessor und ruft im Rahmen seiner Initialisierung eine Funktion auf die die Speicheradressen aus der Ressourcentabelle liest Darauf basierend initialisiert er die Kommunikation via VirtIO RPMsg und meldet seinen Kanal dem Master der den Kanal bestätigt und die Kommunikation etabliert Zum geordneten Herunterfahren des Remote-Prozessors wird über die RPMsg-Kommunikation die Nachricht shutdown versendet woraufhin der Remote-Prozessor die in der Ressourcentabelle definierten Speicherbereiche freigibt die Programmausführung beendet und das Abschalten bestätigt Der Master setzt danach das Reset-Signal und deinitialisiert die Ressourcen auf seiner Seite Kommunikation mit Shared Memory Die Kommunikation zwischen den Prozessoren geschieht über gemeinsam genutzte Speicherbereiche Shared-Memory-Bereiche sowie InterprozessorInterrupts IPI Das Implementieren basiert auf VirtIO das zur Para-Virtualisierung Linuxbasierter Gastsysteme entwickelt wurde und heute ein Teil des Linux-Kernels ist Nach außen bietet VirtIO ein abstraktes VirtIO-Gerät das von RPMsg-Treiber instanziiert und konfiguriert wird Das Management des Shared Memory geschieht über einen vring der mit weiteren Informationen eine virtqueue bildet Sind neue Daten für den Remote-Prozessor im vring verfügbar wird ein IPI zur Benachrichtigung ausgelöst Der RPMsg-Treiber nutzt je eine virtqueue zum Senden und Empfangen von Daten pro untergeordnetem Prozessor die in einem vordefinierten Speicherbereich abgelegt sind Ein Master kann mehrere Slaves haben die jeweils selbst wieder Master für einen oder mehrere untergeordnete Systeme sein können Bild 3 Da der Interrupt Controller in SoCs typischerweise eine geteilte Ressource ist ist er kooperativ zu nutzen Insbesondere darf er beim Systemstart des untergeordneten Systems nicht zurückgesetzt werden Das Festlegen der Shared-Memory-Bereiche geschieht bei Linux über den Gerätebaum Device Tree auf Bare-Metal beziehungsweise bei RTOS über eine vom Entwickler angelegte Ressourcentabelle die mit der Festlegung auf den anderen Systemen übereinstimmen muss Ein Device Tree ist dabei eine Datenstruktur die die Hardwarekomponenten eines bestimmten Computers beschreibt sodass der Kernel des Betriebssystems diese Komponenten verwenden und verwalten kann einschließlich der CPU oder CPUs des Speichers der Busse und der Peripheriegeräte Beim Initialisieren des RPMsg-Treibers legt dieser alle virtqueues an und weist den vrings Speicherbereiche im Shared Memory zu Anschließend überträgt der Master die verbindungsnotwendigen Daten und informiert den Remote-Prozessor über einen InterprozessorInterrupt Bei einem Linux-Master ist das RPMsg-Interface ein serielles Gerät das entweder direkt im Kernel oder über einen Userspace-Treiber genutzt wird Der Begriff Userspace oder User Land bezieht sich auf alle Programme die außerhalb des Kernels des Betriebssystems laufen Praxisbeispiel MBatt MBatt ist ein Projekt zum Entwickeln eines Multilevel-Umrichters für BatteBild 1 Schematische Darstellung eines Systems mit mehreren Mastern Ein Linux-System ist der Master für zwei RTOS-Anwendungen wovon eine selbst wieder Master einer Baremetal-Anwendung ist Bild 2 Bild 2 Ablaufdiagramm des Lifecycle-Managements Schwarze Pfeile stellen eine Kommunikation über RPMsg dar rote Pfeile Hardwareaktionen über remoteproc Bild 3