Harte Echtzeit mit Linux: die Cortex-R5F-Kerne des TI AM67A nutzen

Ja — auf einem TI AM67A lassen sich Linux auf den Cortex-A53-Kernen und eine Echtzeit-Firmware auf einem Cortex-R5F gleichzeitig betreiben. Genau dafür ist der Baustein ausgelegt: Der überwiegende Teil der Anwendung läuft unter Linux, die zeitkritischen Anteile werden auf den R5F ausgelagert. Die interessante Frage ist nicht, ob das funktioniert. Sie lautet: Wo verläuft die Grenze, welchen R5F verwenden Sie, und was passiert zwischen den beiden Domänen? Diese drei Entscheidungen bestimmen, ob die Echtzeit-Domäne überhaupt etwas einbringt. Alle Bausteinangaben stammen aus dem AM67x-Datenblatt SPRSPA3B und dem Technical Reference Manual SPRUJB3D. Für diesen Artikel wurden von Spikedge keine eigenen Leistungsmessungen auf dieser Plattform durchgeführt; alles, was eine Messung voraussetzen würde, ist als solches gekennzeichnet.

Zuerst die falsche Frage aussortieren

„Ist Linux echtzeitfähig?" führt die Diskussion jedes Mal in die Irre. Die brauchbare Frage lautet: Was passiert, wenn Ihre Aufgabe ihren Termin verfehlt?

Dahinter stehen drei verschiedene Zusagen, die nicht dasselbe sind:

• Im Mittel schnell. Das leistet ein Standard-Linux-Scheduler gut. Für durchsatzorientierte Aufgaben ausreichend.
• Meistens rechtzeitig. Mit PREEMPT_RT, CPU-Isolation, IRQ-Affinität und Prioritätsvergabe erreicht Linux dieses Band. Das ist echte Entwicklungsarbeit und wird durch Messung belegt, nicht durch Konfiguration.
• Immer rechtzeitig. Wenn ein einzelner verpasster Zyklus eine physikalische Folge hat — eine Achse driftet, eine Verriegelung löst nicht aus, etwas überhitzt — ändert sich die Beweislast. Dann zählt nicht der Mittelwert, sondern der Worst Case, und den können Sie nur in einer Domäne verteidigen, in der sonst nichts läuft.

Die R5F-Domäne des AM67A existiert für die dritte Kategorie. Der R5F ist nicht schneller als ein A53. Er ist vorhersagbar: eng gekoppelter Speicher, eigener Interrupt-Controller, eigene Taktdomäne und — beim Kern in der MCU-Domäne — eigene 512 KB SRAM. Keine Seitenfehler, kein Paging, keine Konkurrenz durch andere Prozesse.

Eine Einschränkung gehört dazu: Ein R5F verkauft Ihnen keine Hard-Real-Time-Garantie. Er liefert die Hardwaregrundlage, auf der sich eine aufbauen lässt. Die Garantie entsteht durch Ihren Entwurf — Interrupt-Prioritäten, Worst-Case-Laufzeitanalyse, sperrfreie Datenstrukturen und Messung.

Wie viele R5F-Kerne stehen tatsächlich zur Verfügung?

Das Datenblatt führt drei einzelne Cortex-R5F-Kerne mit jeweils bis zu 800 MHz:

Zwei der drei gehören Ihnen. Der dritte führt die TI-Firmware für Energie-, Takt- und Ressourcenverwaltung aus und kommt im Boot-Image mit; auf ihm wird keine Anwendungslast eingeplant.

Zwei weitere Punkte, die häufig vorausgesetzt werden und nicht zutreffen:

• Es gibt keinen Lockstep. Das TRM führt Lockstep für alle drei R5F-Subsysteme unter den nicht unterstützten Merkmalen. „FFI" steht für Freedom From Interference und beschreibt Isolation, nicht redundante Ausführung mit Ergebnisvergleich. Ein Sicherheitskonzept, das auf hardwareseitige Doppelausführung baut, findet sie hier nicht.
• Welche Kerne das SDK freigibt, ist keine Datenblattfrage. Das Datenblatt verweist zweimal auf das Software Build Sheet. Das gehört geklärt, bevor die Aufteilung geplant wird.

MAIN-R5F und MCU-R5F sind nicht austauschbar

Dieser Punkt verdient einen eigenen Abschnitt, weil er die teuerste Fehlannahme ist.

Die beiden für Anwendungen verfügbaren R5F-Kerne liegen in unterschiedlichen Domänen. Der MCU-R5F sitzt im MCU-Kanal, ist mit dem Zusatz „Freedom From Interference" beschrieben und verfügt über eigene 512 KB SRAM. Der MAIN-R5F liegt in der MAIN-Domäne neben dem A53-Cluster, den Beschleunigern und dem schnellen Interconnect. Unterschiedliche Domänen bedeuten unterschiedliche Interconnect-Pfade, unterschiedliche Reset- und Energiebeziehungen und unterschiedliche Speichersichtbarkeit.

In der Praxis zeigt sich das an Berichten aus der Community, in denen Firmware auf einem Kern sauber hochläuft und auf dem anderen beim Aufbau der Inter-Core-Kommunikation stehen bleibt — gleicher Code, anderer Kern. Eine einzelne Ursache schreiben wir dem nicht zu; das würde eine eigene Reproduktion voraussetzen. Die Entwurfsempfehlung steht unabhängig davon:

Behandeln Sie „welcher R5F" als Architekturentscheidung, nicht als Build-Schalter.

• MCU-R5F, wenn die Aufgabe von den Vorgängen in der MAIN-Domäne isoliert sein muss. Auf diesen Kern bezieht sich die FFI-Formulierung, und er hat den eigenen SRAM. Die harte Regelschleife gehört hierhin.
• MAIN-R5F, wenn die Aufgabe von der Nähe zu Peripherie und Speicher der MAIN-Domäne profitiert und ihre Termine fest, aber nicht hart sind.

Und: Validieren Sie das Hochlaufen früh auf genau dem Kern, mit dem Sie in Serie gehen wollen. Ein Wechsel zwischen beiden ist keine Neuübersetzung.

Welche Aufgabe gehört wohin?

Vier Fragen, in dieser Reihenfolge. Das erste „Ja" entscheidet.

1. Hat ein verpasster Termin eine physikalische Folge? Motorkommando, Sicherheitsverriegelung, Triggerzeitpunkt, synchrone Abtastung. Wenn ja, gehört die Aufgabe in die R5F-Domäne. Damit ist die Diskussion beendet.

2. Hängt die Aufgabe an einem Interrupt im Mikrosekundenbereich? Encoder-Impulse, Capture-Eingänge, externe Trigger. Der AM67A bietet je drei ePWM-, eCAP- und eQEP-Module; diese aus dem Linux-Userspace zu bedienen, gibt an Jitter mehr zurück, als es an Aufwand spart. R5F.

3. Braucht die Aufgabe umfangreiche Bibliotheken? TLS-Stack, Datenbank, ROS 2, Dateisystem, Netzwerkprotokoll, Modell-Laufzeitumgebung. Wenn ja, Cortex-A53. Solche Bibliotheken auf einen R5F zu portieren ist bisweilen möglich und fast nie wirtschaftlich.

4. Ist die Aufgabe datenintensiv, aber zeitlich weich? Video, Aufzeichnung, Telemetrie, Inferenz. A53 und Beschleuniger. Auf dem R5F zerstören diese Aufgaben genau die Eigenschaft, wegen der er gewählt wurde.

Die Grauzone — „wichtig, aber ohne physikalische Folge" — gehört auf den A53. Eine Aufgabe auf den R5F zu verlagern kostet eine zweite Toolchain, eine zweite Debug-Umgebung, einen zweiten Lebenszyklus und ein Protokoll dazwischen. Dieser Aufwand rechtfertigt sich nur, wenn Frage 1 oder 2 mit Ja beantwortet wird.

Aus der Praxis: Die meisten Aufteilungsfehler entstehen dadurch, dass der R5F zu viel übernimmt, nicht zu wenig. Jede zusätzliche Aufgabe auf dem Echtzeitkern vergrößert den Umfang der Worst-Case-Analyse und höhlt den Grund für seinen Einsatz aus. Entwerfen Sie den R5F als Gerät mit genau einer Aufgabe, nicht als zweite CPU.

Die Brücke: remoteproc und RPMsg

Auf der Linux-Seite übernehmen das zwei Frameworks.

remoteproc verwaltet den Lebenszyklus des entfernten Kerns: Firmware im Speicher ablegen, Kern aus dem Reset holen, anhalten, nach einem Absturz wiederherstellen. Die Resource Table im Firmware-ELF meldet, welche Speicherbereiche (Carveouts) der Kern benötigt, welche Vrings er nutzt und wo der Trace-Puffer liegt. In dieser Tabelle einigen sich beide Seiten auf die Speicheraufteilung — und hier entstehen die meisten stillen Fehler.

RPMsg stellt darüber Nachrichtenkanäle bereit: Ringpuffer im gemeinsamen Speicher plus ein Mailbox-Interrupt als Türklingel. Eine Seite schreibt, klingelt, die andere wacht auf.

Diese Unterscheidung ist praktisch bedeutsam, denn RPMsg ist nicht für jede Art von Verkehr das richtige Mittel. Für Kommandos, Statusmeldungen, Parameteränderungen und Fehlermeldungen ist es die passende Abstraktion — benannte Kanäle, Flusskontrolle und Verbindungsverwaltung sind enthalten. Für einen Datenpfad mit einigen hundert Byte je Zyklus und einem Mikrosekundenbudget sind Kopier- und Warteschlangensemantik unnötiger Aufwand.

Das tragfähige Muster nutzt beides:

Gemeinsamer Speicher: hier steckt der eigentliche Entwurf

Den gemeinsamen Speicher als „ein Feld, das beide Seiten sehen" zu betrachten, ist die teuerste Vereinfachung dieser Architektur. Drei getrennte Themen.

Cache-Kohärenz. Die A53-Seite sieht den Bereich über Caches, der R5F hat seine eigene Sicht. Greifen beide Seiten gecacht lesend und schreibend auf denselben Bereich zu, sind die Daten manchmal falsch — und solche Fehler treten im Feld unter Last auf, nicht auf dem Labortisch. Es gibt zwei vertretbare Wege: den Bereich auf einer Seite ungecacht einblenden (einfach, langsamer) oder bei jedem Zugriff explizite Cache-Pflege betreiben (schnell, verlangt Disziplin). Dazwischen gibt es nichts.

Zerrissene Lesezugriffe. Werden zwei 32-Bit-Felder in zwei getrennten Schreibzugriffen aktualisiert, kann der Leser eines alt und eines neu sehen. Der übliche sperrfreie Ausweg ist ein Zähler nach Art eines Seqlock: Der Schreiber macht den Zähler beim Eintritt ungerade und beim Austritt gerade; der Leser liest ihn vorher und nachher und wiederholt bei Abweichung. Alternativ Doppelpufferung: Der Schreiber füllt den inaktiven Puffer und tauscht mit einem einzigen atomaren Indexschreibzugriff.

Eigentümerschaft. Jeder gemeinsame Bereich sollte genau einen Schreiber haben. Ein Bereich, in den beide Seiten schreiben, verlangt früher oder später eine Sperre — und eine Sperre bedeutet auf der R5F-Seite unbegrenztes Warten, womit die Worst-Case-Analyse hinfällig wird. Verwenden Sie stattdessen zwei Einbahnbereiche.

Sechs Anti-Pattern

Die wiederkehrenden Fehler dieser Architektur, das teuerste zuerst.

1. Den R5F als zweiten Applikationsprozessor behandeln. Anzeichen: Die Firmware wächst, Logging, Netzwerk und Dateizugriffe ziehen ein. Folge: Die Worst-Case-Laufzeit ist nicht mehr berechenbar.

2. Den kritischen Pfad über RPMsg führen. Anzeichen: Die Regelschleife wartet in jedem Durchlauf auf eine Nachricht aus Linux. Folge: Der Worst Case der Schleife entspricht dem von Linux, und der Grund für den R5F entfällt. Die kritische Schleife muss sicher weiterlaufen, auch wenn Linux vollständig stehen bleibt.

3. Die Grenze danach ziehen, wo der Code bereits liegt. Anzeichen: „Diese Funktion war ohnehin in C, verschieben wir sie auf den R5F." Folge: Die Echtzeit-Domäne füllt sich mit fachfremdem Code. Die Grenze ergibt sich aus der Terminzusage, nicht aus der Sprache.

4. Eine Startreihenfolge voraussetzen. Anzeichen: Die R5F-Firmware erwartet eine von Linux vorbereitete Struktur oder umgekehrt. Folge: Ein System, das kalt startet, blockiert beim Warmstart oder beim Neustart über remoteproc. Beide Seiten müssen in einem definierten Zustand warten, wenn die Gegenseite fehlt; die Übergabe gehört explizit ausformuliert.

5. Den Absturz von Linux nicht einplanen. Anzeichen: Die A53-Seite startet neu, die Sicht des R5F auf den gemeinsamen Zustand veraltet, und niemand bemerkt es. Folge: ein Aktor, der weiter auf den letzten Sollwert wirkt. Jede gemeinsame Struktur braucht eine Aktualitätskennung — Zähler oder Zeitstempel — und der R5F ein definiertes Zeitüberschreitungsverhalten.

6. „Deterministisch" sagen, ohne zu messen. Anzeichen: Die Architektur ist richtig aufgebaut, die Latenzverteilung hat niemand angesehen. Folge: guter Mittelwert, schlechter Randbereich. Maßgeblich sind hier p99 und Worst Case — und beide zeigt nur die Messung.

Das Zeitbudget der Regelschleife aufstellen

„Latenz" ist in einer Regelschleife keine einzelne Zahl. Zerlegen Sie die Latenzzeit, bevor Sie optimieren:

1. Auslösendes Ereignis — Encoder-Impuls, Trigger, Timer-Überlauf.
2. Interrupt-Latenz — vom Ereignis bis zum ersten Befehl der Serviceroutine.
3. Bearbeitungszeit — lesen, rechnen, schreiben.
4. Ausgabe an den Aktor — über die Peripherie in die Physik.
5. (Falls vorhanden) Übergang zwischen den Domänen.

Bleiben die Schritte 1 bis 4 in der R5F-Domäne, sind die Latenzen klein und eng verteilt. Sobald Schritt 5 in den kritischen Pfad gerät, enthält das Zeitbudget den Worst Case der Linux-Seite. Der gesamte Zweck dieser Architektur besteht darin, Schritt 5 aus dem kritischen Pfad herauszuhalten.

Was gemessen werden muss

Jede veröffentlichungswürdige Zahl trägt drei Angaben mit sich: welcher Aufbau, welche Methode, gemessen von wem. Fehlt eine davon, wird die Zahl nicht veröffentlicht. Der Mindestumfang:

• Interrupt-Latenz des R5F. GPIO-Impuls gegen einen externen Trigger, am Oszilloskop, über mindestens einen Dauerlauf über Nacht. Als Histogramm, nicht als Mittelwert.
• Zähler für verpasste Zyklen. In der Firmware, von außen auslesbar. Jeder Wert ungleich null ist ein Befund.
• Umlaufzeit zwischen den Domänen. Synchronisierte Zeitstempel an beiden Enden, getrennt im Leerlauf und unter Volllast.
• Verschlechterung unter Last. Wie sich die obigen Werte ändern, während auf der A53-Seite Inferenz, NVMe-Zugriffe und Netzwerkverkehr laufen. Der Leerlaufwert sagt nichts aus.
• Zeit vom Kaltstart bis zur Regelbereitschaft — unabhängig davon, wann Linux bereit ist.
• Wiederherstellungsverhalten. Den R5F im laufenden Betrieb über remoteproc anhalten und neu starten: definierter Zustand oder undefinierter?

Wann diese Architektur nicht sinnvoll ist

• Es gibt keine hart terminierte Aufgabe. Werden weiche Termine mit PREEMPT_RT eingehalten, bringt eine zweite Toolchain nebst Protokollschicht nichts ein.
• Niemand im Team verantwortet Firmware. Die R5F-Seite ist eine eigene Toolchain, eine eigene Debug-Methodik und ein eigener Freigabezyklus. Firmware ohne Verantwortlichen ist ein Risiko ohne Verantwortlichen.
• Die kritische Aufgabe läuft bereits auf einem separaten Mikrocontroller. Einen validierten externen Regler in den SoC zu ziehen, erzeugt Revalidierungsaufwand statt Ersparnis. Nur bei konkretem Gewinn an Stückkosten, Latenz oder Synchronisation.
• Beide Firmware-Stände lassen sich im Feld nicht gemeinsam aktualisieren. Die Versionen der beiden Domänen sind gekoppelt; trägt das OTA-Konzept diese Kopplung nicht, zerfällt die Architektur im Feld.

Fazit

Der Nutzen von Linux und R5F auf einem AM67A entsteht nicht daraus, zwei Prozessoren zu haben. Er entsteht daraus, zwei unterschiedliche Zeitzusagen auf einer Baugruppe unterzubringen. Erhalten bleibt dieser Nutzen nur mit einer disziplinierten Grenzziehung: Der kritische Pfad schließt sich in der R5F-Domäne, Linux ist die Hilfsseite, die Brücke liegt außerhalb des kritischen Pfads, und jede gemeinsame Struktur hat genau einen Schreiber.

Der Rest ist Messung. In dieser Architektur ist das Wort „deterministisch" keine Aussage, solange kein Histogramm dahintersteht.

Den Baustein selbst behandeln wir in unserer AM67A-Architekturanalyse; wie viel davon ein konkretes Board herausführt, zeigt unsere Analyse des T3 Gemstone O1. Für die Aufteilung auf Ihrer eigenen Plattform ist unsere Arbeit an Hard Real-Time und RTOS der Ausgangspunkt; den Umfang legen wir in einem Architektur-Audit gemeinsam fest.

Quellen

1. Texas Instruments — AM67x Processors datasheet, SPRSPA3B, März 2024, überarbeitet Juni 2026 — https://www.ti.com/lit/ds/symlink/am67a.pdf
2. Texas Instruments — J722S/TDA4VEN/TDA4AEN/AM67 Processor Silicon Revision 1.0 Technical Reference Manual, SPRUJB3D, August 2026 — https://www.ti.com/lit/zip/sprujb3
3. Texas Instruments — PROCESSOR-SDK-AM67A — https://www.ti.com/tool/PROCESSOR-SDK-AM67A
4. Linux-Kernel-Dokumentation — Remoteproc Framework — https://docs.kernel.org/staging/remoteproc.html
5. Linux-Kernel-Dokumentation — RPMsg Messaging Framework — https://docs.kernel.org/staging/rpmsg.html

Zugriff auf die Quellen am 5. September 2026. SDK- und Kernel-Dokumentation sind versioniert; Fragen wie die nach den freigegebenen Kernen gehören stets gegen den eingesetzten Stand geprüft.