Harte Echtzeitanforderungen mit Linux
Latenzen bei der Interprozessorkommunikation mit OpenAMP
Die Interprozessorkommunikation in einem Multiprozessor-SoC mit Remote Processor Messaging (RPMsg) zwischen einer Linux- und einer FreeRTOS-Umgebung weist Latenzen auf, die richtungsabhängig sind. Ein System zur prozessor- und umgebungsübergreifenden Latenzmessung hilft bei der Suche nach dem Grund.
An moderne eingebettete Systeme werden zunehmend höhere Anforderungen gestellt, zum Beispiel hinsichtlich Kommunikation und Vernetzung sowie graphischer Oberflächen. Um diesen Anforderungen gerecht zu werden, wird immer häufiger Embedded Linux eingesetzt [1]. Obwohl der Einsatz von Linux viele Möglichkeiten eröffnet, hat er aber auch einen entscheidenden Nachteil: Das System verliert seine Echtzeitfähigkeit. Denn ohne spezielle, teils aufwendige Änderungen eignet sich der Linux-Kernel nicht zur Erfüllung harter Echtzeitanforderungen.
Eine Möglichkeit dennoch harte Echtzeitanforderungen erfüllen zu können, bietet das heterogene Multiprozessor-System-on-Chip (MPSoC). MPSoCs enthalten Anwendungsprozessoren, auf denen Linux ausgeführt wird, und Coprozessoren. Die Coprozessoren können zur Ausführung eigener dezidierter Firmware genutzt werden. Diese Betriebsart eines Mehrkernprozessors mit mehreren verschiedenen Umgebungen wird als asymmetrisches Multiprocessing (AMP) bezeichnet. Wird als Umgebung für den Coprozessor ein Echtzeitbetriebssystem oder eine Bare-Metal-Umgebung verwendet, so können auf diese Art harte Echtzeitanforderungen erfüllt werden, denn durch die Aufteilung auf verschiedene Prozessoren ist die Echtzeitumgebung von Linux entkoppelt [2].
Eine komplette Kapselung der Ausführungsumgebungen ist in der Praxis jedoch nicht nützlich. Schließlich soll das Linux-System dazu in der Lage sein, Informationen mit der Echtzeitumgebung auszutauschen. Der Linux-Kernel enthält mit Remote Processor Messaging (RPMsg) bereits ein Framework für die Interprozessorkommunikation, also die Kommunikation mit einem Coprozessor. Für die Implementierung der Interprozessor-kommunikation in der Coprozessor-Firmware gibt es die OpenAMP-Bibliothek. Sie enthält standardisierte Implementierungen, die auf RPMsg basieren und so die Datenübertragung zwischen dem Coprozessor und dem Linux-System ermöglicht.
Im Kontext von echtzeitkritischen Anwendungen stellt sich nun die Frage nach der Latenz der Interprozessorkommunikation. Welche Verzögerungen sind zu erwarten, wenn Daten zwischen den Umgebungen ausgetauscht werden und wovon hängen diese Verzögerungen hauptsächlich ab? Um diese Fragen zu beantworten, wurde ein exemplarisches Beispielsystem mit einer Embedded-Linux- und einer FreeRTOS-Umgebung aufgesetzt. Dieses Beispielsystem wurde dann mithilfe eines neu entwickelten Messsystems zur prozessorübergreifenden Latenzmessung im Detail analysiert.
Jobangebote+ passend zum Thema
Linux und FreeRTOS auf einem SoC
Für die Analyse der Latenzen bei der Interprozessorkommunikation wurde ein Beispielsystem implementiert, das jeweils eine Linux-Umgebung und eine FreeRTOS-Umgebung auf einem MPSoC ausführt (Bild 1).
Als SoC für das Beispielsystem wurde die neue i.MX-93-Prozessorfamilie von NXP Semiconductor ausgewählt. Bei dieser Prozessorfamilie handelt es sich um SoCs, die zusätzlich zu Anwendungsprozessoren auch einen Mikrocontroller integriert haben. Der im Beispiel tatsächlich verwendete MPSoC ist der PIMX9352CVUXKAA (im Weiteren IMX9352 genannt), er ist Kern des System-on-Module (SoM) VAR-SOM-MX93 Rev 1.0 von Variscite. Als Träger für das SoM wurde für die Latenzmessung das Symphony-Board Rev 1.6D verwendet.
Das IMX9352 hat zwei ARM-Cortex-A55-Prozessorkerne mit einer maximalen Taktfrequenz von 1,7 GHz. Bei diesen Prozessorkernen handelt es sich um Anwendungsprozessoren. Sie eignen sich vor allem für das Ausführen allgemeiner Betriebssysteme. Zusätzlich enthält der IMX9352 einen ARM-Cortex-M33-Prozessor mit maximaler Taktfrequenz von 250 MHz. Dieser Prozessor ist für die Verwendung in Mikrocontrollern konzipiert, für Echtzeit- und Low-Power-Anwendungen. Damit eignet sich der IMX9352 ideal für die Realisierung des Beispielsystems.
Für die Linux-Umgebung des Beispielsystems dient die Kernelversion 6.1.1-rt5. Dieser Kernel ist bereits mit dem PREEMPT_RT-Patch modifiziert, um ein besseres Echtzeitverhalten zu erreichen. Der Patch verkürzt die Zeiträume, in denen der Linux-Kernel nicht unterbrochen werden kann, und reduziert so die maximale Verzögerung, mit der der Kernel auf Interrupts reagiert [3]. Außerdem wurden dem Kernel zusätzliche Treiber und Anpassungen von NXP Semiconductor und eine Konfiguration für das SoM sowie die Trägerplatine von Variscite hinzu- gefügt. Der Linux-Kernel nutzt die beiden ARM-Cortex-A55-Prozessoren des MPSoCs.
Für die Echtzeitumgebung wurde die OpenAMP-Bibliothek für den ARM-Cortex-M33 im IMX9352 portiert und in eine FreeRTOS-basierte Firmware integriert. Diese Firmware wird von der Linux-Umgebung in den Programmspeicher des Coprozessors geladen und parallel ausgeführt. Mittels der Funktionen der OpenAMP-Bibliothek ist sie in der Lage, Daten mit der Linux-Umgebung auszutauschen.
RPMsg: Kommunikation mittels Shared Memory und Interprozessor-Interrupts
Das RPMsg-Framework nutzt die Tatsache, dass die kommunizierenden Prozessoren in einem Chip integriert sind. Heterogene MPSoCs sind so aufgebaut, dass die Prozessoren alle gemeinsam denselben Speicher nutzen. Dadurch sind für die Kommunikation keine Busse oder seriellen Schnittstellen nötig, wie es bei zwei separaten ICs auf einer Platine der Fall wäre. Stattdessen wird ein spezieller Speicherbereich (Shared Memory) ausgewählt, über den die Prozessoren Daten austauschen.
RPMsg ist dabei die oberste Schicht eines dreischichtigen Protokolls (Bild 2) bestehend aus der Bitübertragungsschicht, der Zugriffskontrollschicht und der Transportschicht [4].
- Bitübertragungsschicht
Die unterste Schicht der Interprozessorkommunikation mit RPMsg besteht aus dem erwähnten Shared Memory. Zusätzlich umfasst diese Schicht Interprozessor-Interrupts. Sie werden genutzt, um von einem Prozessor aus den Kommunikationspartner zu benachrichtigen, dass neue Daten im Shared Memory bereitliegen. - Zugriffskontrollschicht
Die Zugriffskontrollschicht regelt die Verwendung des Shared Memory durch die an der Kommunikation beteiligten Prozessoren. Hier wird auf das Virtual IO-Protokoll zurückgegriffen. Dieses Protokoll verwendet Virtqueues, das sind spezielle Datenstrukturen, die jeweils nur von einer Seite geschrieben und nur von einer Seite gelesen werden. Dadurch ist keine weitere Synchronisierung zwischen den Kommunikationspartnern notwendig. - Transportschicht
Auf der obersten Schicht des Kommunikationsprotokolls kommt RPMsg selbst zum Einsatz. Mit diesem Protokoll werden RPMsg-Endpunkte bei den Kommunikationspartnern definiert. Diese Endpunkte sind über RPMsg-Kanäle, die Virtual-IOs, miteinander verbunden. Die Kommunikation findet dabei immer Punkt-zu-Punkt statt. Die Endpunkte definieren außerdem eine Funktion, mit der empfangene Daten weiterverarbeitet werden.
Im Falle der Linux-Umgebung ist das RPMsg-Framework als Modul im Kernel integriert. Die Anbindung an die SoC-spezifische Hardware erfolgt über Erweiterungen dieses Moduls. Damit auch Anwendungen aus dem Linux-Userspace RPMsg nutzen können, gibt es außerdem noch Treiber, die einen RPMsg-Endpunkt entweder mit einem TTY-Gerät oder einem Character-Gerät verknüpfen. Lese- und Schreibzugriffe auf diese Geräte werden dann an den RPMsg-Endpunkt weitergeleitet und von diesem verarbeitet.
In der FreeRTOS-Umgebung muss die OpenAMP-Bibliothek für den speziellen Prozessor portiert werden, um die Standardfunktionen mit der SoC-spezifischen Hardware zu verknüpfen. Anschließend kann aus der Firmware einfach mittels Funktionsaufruf die RPMsg-Funktion genutzt werden.
Prozessor- und umgebungsübergreifende Latenzmessung
An der Kommunikation zwischen einer Anwendung aus dem Linux-Userspace und der Firmware eines Coprozessors sind verschiedene Schichten und Treiber beteiligt. Zwar sind im Linux-Kernel bereits verschiedene Möglichkeiten zur Messung von Latenzen integriert, doch keine davon kann eine Prozessor- oder gar umgebungsübergreifende Messung durchführen. Für die Analyse der RPMsg-Latenzen ist also ein spezielles Messsystem notwendig.
Zur Implementierung eines Prozessor- und umgebungsübergreifenden Messsystems auf einem MPSoC kann die Tatsache genutzt werden, dass die Prozessoren nicht nur gemeinsamen Zugriff auf den Speicher haben, sondern auch auf die Peripheriemodule. Es kann also ein Timer-Modul als gemeinsame Referenz verwendet werden, da sowohl aus der Linux-Umgebung als auch aus der FreeRTOS-Umgebung auf dem Coprozessor der aktuelle Timer-Wert ausgelesen werden kann. Für die Durchführung automatischer Latenzmessungen wurden drei Komponenten implementiert: Eine Linux-Userspace-Anwendung, ein Linux-Kernelmodul und eine FreeRTOS-basierte Firmware für den Coprozessor (Bild 3).
- Latenzen bei der Interprozessorkommunikation mit OpenAMP
- Linux-Userspace-Anwendung
- Literatur
Lesen Sie mehr zum Thema
