Multiprocessing mit OpenAmP
Viele Kerne – zwei Möglichkeiten
Fortsetzung des Artikels von Teil 1
OpenAMP unter Linux
Im Projekt MBatt ist Linux wie meist üblich der Master im System. Somit gibt es zwei Varianten zur Integration von OpenAMP:
1. Die Komponenten »remoteproc«, »VirtIO« und »RPMsg« laufen im Kernel, nur die Anwendungen im Userspace. Dazu ist der RP von Linux zu starten, indem der unter »/lib/firmware« liegende Dateiname der Firmware in die Datei »firmware« geschrieben und dann »start« in die Datei state eingetragen wird. Beide liegen unter »/sys/class/remoteproc/remoteprocX«. Nach dem Initialisieren der Kommunikation wird das serielle »Device File« (/dev/rpmsgX) angelegt, das von der Anwendung zur Kommunikation genutzt wird. Zum Beenden des RP wird »/dev/rpmsgX« geschlossen, wodurch ein »shutdown« gesendet wird. Zum Schluss wird der RP über Eintrag von »stop« in »/sys/class/remoteproc/remoteprocX/state« angehalten. Für MBatt wurde die Variante gewählt, da die Verfügbarkeit der RPU beim Systemstart nicht erforderlich ist. Die Möglichkeit, sie nach Bedarf zu starten und anzuhalten vereinfacht jedoch das Entwickeln sowie das Benutzen.
2. Der Start des Remote-Prozessors beim Systemstart ist unabhängig und verzichtet auf das Lifecycle-Management per »remotproc«. Hier laufen »VirtIO« und »RPMsg« im Userspace, die I/O-Zugriffe sind über einen Userspace-I/O-Treiber (zum Beispiel »libMetal«) im Kernel auszuführen. Hingegen übernimmt den Start des Remote-Prozessors sowie das Laden der Firmware beispielsweise ein »First Stage Bootloader«.
Bei beiden Varianten sind zusätzliche, geringfügig unterschiedliche Informationen im Device Tree einzutragen. Bei Variante eins sind das »Power Domains«, IPI, der RP und die dafür reservierten Speicherbereiche. Die Speicherbereiche müssen mit der Ressourcentabelle des RP übereinstimmen. Hierbei ist der genaue Inhalt stark vom verwendeten SoC und der Konfiguration abhängig.
Bei MBatt kommuniziert eine Linux-Anwendung im Rahmen eines Smart Grids via Internet mit dem Netzbetreiber. Dabei gibt die Anwendung unterschiedliche Daten über den Betriebszustand, zum Beispiel den Ladezustand der Batterien, weiter. Nebenher empfängt die Anwendung aber auch Daten wie Anforderungen zur Einspeisung von Leistung ins Netz oder, bei zu viel Leistung im Netz, zum Laden der Batterien. OpenAMP gibt die aufbereiteten Leistungsvorgaben an die Regelung auf der RPU weiter, außerdem überträgt die Software Daten für das Logging und die Visualisierung von der RPU zur APU.
Jobangebote+ passend zum Thema
OpenAMP mit Bare-metal/RTOS
In der Regel wird auf dem Remote-Prozessor eine Bare-metal- beziehungsweise RTOS-Anwendung verwendet, bei MBatt wird auf der RPU ein »FreeRTOS« genutzt, ein Real Time Operating System (RTOS) unter Lizenz des Massachusetts Institute of Technology (MIT). Sie umfasst neben der Anwendungs-Software auch die OpenAMP-Bibliothek sowie die gemeinsame Ressourcentabelle. Die Anwendung muss nach dem Start die Kommunikation initialisieren und kann dann über die RPMsg Programmierschnittstelle mit dem Master kommunizieren. Beim Empfang des »shutdown« sind die entsprechenden Ressourcen freizugegeben und das Abschalten zu bestätigen. Beim Linken der Firmware für den Remoteprozessor müssen die Speicherbereiche mit denen aus der Ressourcentabelle beziehungsweise dem Device Tree übereinstimmen. Die ELF wird dem Master dann zur Verfügung gestellt. Von der Regelung werden verschiedene Tasks genutzt, wodurch sicherheitskritische Funktionen sowie Regelungsfunktionen immer Vorrang vor nicht zeit- und sicherheitskritischen Aufgaben haben.
Praxistipps zur Entwicklung
Beim Entwickeln von Systemen mit asymmetrischem Multiprocessing stellen sich dem Entwickler einige typische Probleme, weshalb nachfolgend ein Vorschlag für den Entwicklungsprozess unterbreitet wird. Er besteht aus sechs Phasen:
1. Entwickeln der Raid Processing Unit Board, Support Package (BPU) und Anwendungs-Software ohne OpenAMP-Kommunikation
In diesem Schritt wird zunächst das BSP für die RPU inklusive der erforderlichen OpenAMP-Bibliotheken erstellt. Danach wird die Anwendungs-Software entwickelt, bis die Kommunikation via »RPMsg« zwingend erforderlich ist.
In eingebetteten Systemen ist ein Board Support Package (BSP) die Ebene der Software, die hardwarespezifische Treiber und andere Routinen enthält, die es einem bestimmten Betriebssystem (traditionell einem Echtzeitbetriebssystem oder RTOS) ermöglichen, in einer bestimmten Hardwareumgebung (einem Computer oder einer CPU-Karte) zu funktionieren, die mit dem RTOS selbst integriert ist.
2. Entwickeln der Accelerated Processing Unit, Board Support Package und Anwendungs-Software ohne OpenAMP-Kommunikation
In diesem Schritt wird das BSP für die APU inklusive der erforderlichen OpenAMP-Kernelmodule erstellt. Danach wird die Anwendungs-Software entwickelt, bis die Kommunikation via RPMsg zwingend erforderlich ist.
3. Test der OpenAMP-Kommunikation
Als nächstes sind die Ressourcentabellen zu definieren, außerdem wird der Device Tree der Accelerated Processing Unit und das »Linkerscript« der RPU angepasst. Danach wird die Kommunikation zum Beispiel mit einer Echo-Anwendung verifiziert.
4. Test der OpenAMP-Kommunikation der APU-Anwendungssoftware
Die Kommunikation der APU wird implementiert und getestet. Da die Kommunikation über ein Device File stattfindet, kann sie entweder über einen »Stub« ersetzt oder eine spezielle Software auf der RPU entwickelt werden, die das gewünschte Verhalten verifiziert. Ein Stub in diesem Kontext ist ein kleines Stück Software, das den von der APU kommenden Output verifiziert, ohne dass die RPU davon betroffen wäre.
5. Test der APU-Anwendungssoftware mit OpenAMP-Kommunikation und Testsoftware auf der RPU
Die Kommunikation der RPU wird implementiert und getestet. Die Verifikation der Kommunikation erfolgt idealerweise auf der APU und ist zum Beispiel mit einem Unit Test-Framework umsetzbar.
6. Integration der APU und der RPU-Anwendungs-Software
Zuletzt findet die Integration der beiden Anwendungen statt. Das Debuggen in einem solchen System wird über eine JTAG-Kette gelöst, was sowohl simultanes als auch separates Debuggen der Prozessoren ermöglicht. Da die beiden Prozessoren und Anwendungen eng gekoppelt sind, führen Breakpoints häufig zum Verändern des Systemverhaltens und sind daher mit Bedacht einzusetzen.
Literatur
[1] (https://www.multicore-association.org)
[2] (https://forschungsstiftung.de/Projekte/Details/MBatt-Multilevel-Umrichter-fuer-Batteriespeichersysteme.html)
[3] Zynq UltraScale+ MPSoC Software Developer Guide. 8.0. Juni 2018. url: https://www.xilinx.com/support/documentation/user_guides/ug1137-zynq-ultrascale-mpsoc-swdev.pdf.
[4] OpenAMP Wiki. 8.0. Okt.2019. url: https://github.com/OpenAMP/open-amp/wiki/OpenAMP-RPMsg-Virtio-Implementation
[5] Mixed Mode GmbH. MBatt. 2019.
- Viele Kerne – zwei Möglichkeiten
- OpenAMP unter Linux
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Debugging von RTOS-Software-Systemen
Schluss mit dem Rätselraten
Tools für die Software-Entwicklung
Linux-Systeme schneller entwickeln mit Tracealyzer 4.4
COM-HPC
Smarte Anwendungen im Internet of Things
Neuer Standort in Hamburg-Harburg
Garz & Fricke weiht Firmenzentrale offiziell ein
Globale Vereinbarung
Mouser schließt Vertrag mit Kontron
Volle Skalierbarkeit mit SMARC 2.0
Der perfekte Standard für Arm-basierte COMs
Garz & Fricke übernimmt Keith & Koep
Neues Geschäftsfeld mit System on Modules
Cybersecurity
Wirksame Sicherheit mit Simulationstechnik
