MMU- und MPU- gestützte Prozessoren
Dies ist bei komplexen SoCs wie dem Xilinx Zynq Ultrascale+ MPSoC nicht trivial, denn bei den Arm Cortex-A53-Cores basiert die Arbeitsspeicherverwaltung auf einer Memory Management Unit (MMU), beim Arm Cortex-R5F-Dual-Core auf einer Memory Protection Unit (MPU). Der Unterschied zwischen diesen unterschiedlichen Arbeitsspeichermanagementsystemen ist, dass man mit einer MMU virtuelle Adressbereiche in beliebige physische Adressbereiche umwandeln kann. Die MMU weist einem Prozess also einen konkreten Adressbereich zu. Ein Controller mit MPU hat diese Zuweisungsfunktion nicht. Die MPU bietet zwar weiterhin den Schutz, dass der eine Prozess dem anderen nicht in denselben Speicherbereich schreiben kann. Ohne MMU muss jeder Prozess jedoch genau wissen, wohin er gelinkt werden soll. Das ist konzeptionell komplexer, da jedem Prozess ein dedizierter Speicherbereich zugewiesen werden muss. Die Systemsoftware des RTOS muss also das API der Speicherzuweisung bieten.
Zwei Welten
In der bisherigen RTOS und Echtzeit-Hypervisor-Landschaft gab es für das Management solcher heterogenen SoC mit MMU- und MPU-basierten Controllern bislang keine wirklich homogenen Lösungen. Die meisten OS-Anbieter haben für die Controller mit MPU kleinere RTOS entwickelt, die komplett andere APIs als die RTOS für Controller mit MMU haben. Dies spielte bislang auch keine große Rolle, da diese Controller meist diskret implementiert wurden. Infolge wurden RTOS für die MPU-basierten Controller vor allem auch auf einen schlanken Footprint und minimalen Arbeitsspeichergebrauch getrimmt, was ein Grund für diese Inkompatibilitäten ist. Wie wichtig das war, zeigt sich auch an der Tatsache, dass diese diskreten Controller mit MPU oft sogar „Bare Metal“ programmiert wurden, wenn kein Multithreading erforderlich war, um immer kleinere Footprints mit den damit einhergehenden Vorteilen wie Einsparung von Lizenzen, geringeren Hardwarekosten und einfacherer Zertifizierbarkeit zu realisieren. Mit homogenen OS-Ökosystemen für die Entwicklung von MMU- und MPU-basierten SoCs und ganzheitlich integrierten Entwicklungsumgebungen kann man jedoch die Programmierung von heterogenen SoCs deutlich komfortabler gestalten.
Heterogene OS-Installationen überwinden
Mit dem Launch des PikeOS-Betriebssystems und Hypervisor for MPU im September 2021 hat der Embedded-Software-Spezialist SYSGO, dessen Fokus auf funktional sicheren und IT-sicheren Lösungen liegt, nun erstmals eine solche Grundlage geschaffen, mit der heterogene SoCs ein homogenes RTOS- und Realtime-Hypervisor-Ökosystem erhalten, was das Programmieren und Payload-Balancing deutlich vereinfacht. PikeOS for MPU wurde hierzu codeseitig auf Basis des klassischen PikeOS-Betriebssystems für MMU-basierte Prozessoren entwickelt. Die APIs zur Programmierung von Applikationen für Prozessoren mit MMU oder MPU sind deshalb quasi identisch. Im Wesentlichen wurde schließlich nur das Memorymanagement-API entsprechend angepasst. Der Wechsel einer Applikation von einem MMU- zu einem MPU-basierten Core-Komplex ist jedoch trotz unterschiedlicher Speicherhandhabung mit wenigen Klicks binnen weniger Minuten zu handhaben. Noch wichtiger ist zudem der Vorteil, dass Code für beide Core-Varianten (MMU- und MPU) in ähnlicher Weise zertifizierbar ist. Kommende Zertifizierungen PikeOS for MPU basierter Lösungen können also auf den SIL 4-, DAL A- und ASIL D-Zertifizierungen des PikeOS for MMU aufbauen.
Homogenes OS-Ökosystem für MMU und MPU
Dadurch, dass rund 80 % des Quellcodes beider OS identisch ist, konnten auch wichtige Kernfunktionen des klassischen PikeOS wie der Separation-Kernel oder die Time- und Space-Partitionierungsmechanismen funktionsidentisch beibehalten werden. Durch die strikte Trennung von Partitionen ermöglicht der Separation-Kernel den parallelen Betrieb mehrerer Anwendungen – von einfachen, aber hochkritischen Steuerungsaufgaben bis hin zu komplexen Benutzerprogrammen mit vielen Funktionen. Außerdem eliminiert der Separation-Kernel das Risiko, dass sich Anwendungsfehler auf andere Partitionen und Anwendungen auswirken. Die Verwendung der gleichen Time- und Space-Partitionierungsmechanismen bringt PikeOS für MPU auch sehr nahe an die ARINC 653-Spezifikation, für die PikeOS für MMUs ursprünglich entwickelt wurde. Damit eignet sich PikeOS für MPU selbst für kritische Anwendungen in der Raumfahrt und Avionik.
Ein besonders interessantes Feature für die effiziente Entwicklung ganzheitlicher Lösungen auf Basis heterogener Systemplattformen ist die ICCOM-Funktionalität (Inter-Core Communication) der beiden PikeOS-Derivate: Diese Funktionalität erlaubt es PikeOS-Instanzen, die auf verschiedenen ARM Cortex A- und R-Cores laufen, über nachrichtenbasierte Kommunikationskanäle miteinander zu kommunizieren. Dies unabhängig davon, ob auf den Cores unterschiedliche oder gleiche Betriebssysteme laufen. ICCOM basiert auf einer symmetrischen Vollduplex-Datentransportschicht, die die Zustellung von Nachrichten garantiert.
Eine IDE für alle Cores
Ab Version 7.2 der Eclipse-basierten CODEO IDE können beide OS in einer integrierte Entwicklungsumgebung (IDE) genutzt werden. Sie kann innerhalb eines einzigen Arbeitsbereiches den gesamte Software-Stack eines heterogenen SoCs und seiner Inter-Core Communication verwalten, was den Softwareentwicklungsprozess für solche komplexen Targetsysteme deutlich vereinfacht. Unterstützt wird der gesamte Entwicklungszyklus von der frühen QEMU-basierten Systememulation und Applikationssimulation bis hin zu Remote-Debugging und Software-Aktualisierungsmechanismen für eingesetzte Systeme im Feldeinsatz.
Auch die Debug-Umgebung TRACE32 von Lauterbach unterstützt das kombinierte Debuggen von MMU- und MPU-basierten Targets. Das bedeutet auch, dass ein TRACE32-Hardware-Setup ausreicht, um die gesamte Xilinx Zynq Ultrascale+ MPSoC-Plattform mit heterogen OS-Setup zu debuggen. Allerdings sollte man beim Tandemeinsatz beider PikeOS nicht mehr von einem heterogenen OS-Setup sprechen. Es handelt sich vielmehr um ein homogenes Ökosystem für heterogene SoCs, das zudem noch in beiden Varianten auch einen Type-1-Echtzeit-Hypervisor integriert hat, sodass multiple zeit- und speicherisolierte, funktional sichere Applikationen dieser oder auch weiterer OS in entsprechend gekapselten Virtuellen Maschinen gehostet werden können.
Durch den Start eines individuellen GUI für solche OS-Partitionen können Softwarearchitekten auch beide PikeOS-Varianten gleichzeitig debuggen – inklusive synchronisierter Start-and-Stop-Events. Dies ist besonders bei der Suche nach Fehlern in der Kommunikation zwischen den einzelnen Subsystemen nützlich. Darüber hinaus kann TRACE32 das gesamte System tracen und grafische Diagramme der Anwendungs- und Funktionslaufzeiten anzeigen. Das Timing ist synchronisiert, was die Beobachtung des Timing-Verhaltens von sowohl klassischem PikeOS als auch PikeOS for MPU und die Messung von Latenzen zwischen beiden Systemen ermöglicht und so das Performancebalancing erleichtert.