{"id":71425,"date":"2026-11-06T08:59:55","date_gmt":"2026-11-06T07:59:55","guid":{"rendered":"https:\/\/www.inovex.de\/?p=71425"},"modified":"2026-11-06T09:02:34","modified_gmt":"2026-11-06T08:02:34","slug":"zephyr-linux-kointegration-frueher-systemstart","status":"publish","type":"post","link":"https:\/\/www.inovex.de\/de\/blog\/zephyr-linux-kointegration-frueher-systemstart\/","title":{"rendered":"Zephyr-Linux-Kointegration \u2013 Erf\u00fcllung der Anforderungen an den fr\u00fchen Systemstart"},"content":{"rendered":"<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_89 counter-hierarchy ez-toc-counter ez-toc-custom ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\"><p class=\"ez-toc-title\" style=\"cursor:inherit\"><\/p>\n<\/div><nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/www.inovex.de\/de\/blog\/zephyr-linux-kointegration-frueher-systemstart\/#Verfuegbare-Bausteine\" >Verf\u00fcgbare Bausteine<\/a><ul class='ez-toc-list-level-3' ><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/www.inovex.de\/de\/blog\/zephyr-linux-kointegration-frueher-systemstart\/#Gemeinsamer-Speicher-und-Interprozessor-Interrupts\" >Gemeinsamer Speicher und Interprozessor-Interrupts<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/www.inovex.de\/de\/blog\/zephyr-linux-kointegration-frueher-systemstart\/#Die-Ressourcentabelle\" >Die Ressourcentabelle<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/www.inovex.de\/de\/blog\/zephyr-linux-kointegration-frueher-systemstart\/#VirtIO-und-VRings\" >VirtIO und VRings<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/www.inovex.de\/de\/blog\/zephyr-linux-kointegration-frueher-systemstart\/#RPMsg\" >RPMsg<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/www.inovex.de\/de\/blog\/zephyr-linux-kointegration-frueher-systemstart\/#Vergleich-zwischen-Load-und-Attach-Modell\" >Vergleich zwischen Load- und Attach-Modell<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/www.inovex.de\/de\/blog\/zephyr-linux-kointegration-frueher-systemstart\/#Fazit\" >Fazit<\/a><\/li><\/ul><\/nav><\/div>\n<p>Moderne Anwendungsprozessoren werden zunehmend mit mehr als einer Art von CPU in einem Geh\u00e4use ausgeliefert. Dies erm\u00f6glicht eine wesentlich direktere Integration eines funktionsreichen Mehrzweck-Betriebssystems zusammen mit einem Betriebssystem f\u00fcr Echtzeit- oder Sicherheitsanwendungen, verglichen mit dem, was mit separaten, dedizierten Mikroprozessoren oder Controllern m\u00f6glich w\u00e4re.<!--more--><\/p>\n<p>Eine g\u00e4ngige Kombination besteht aus einem ARM Cortex-A-Anwendungsprozessor zusammen mit einem separaten Cortex-M-Echtzeitprozessor. Der erste der beiden l\u00e4uft in der Regel unter Linux und \u00fcbernimmt die Netzwerkfunktionen, rechenintensive Aufgaben oder eine Benutzeroberfl\u00e4che, w\u00e4hrend der zweite ein Echtzeitbetriebssystem (RTOS) wie <a href=\"https:\/\/www.zephyrproject.org\/\">Zephyr<\/a> ausf\u00fchrt und f\u00fcr Anwendungen mit Echtzeit- oder Sicherheitsanforderungen sowie f\u00fcr die Verwaltung von Low-Level-Peripherieger\u00e4ten zust\u00e4ndig ist.<\/p>\n<p>Ein solches System erfordert eine sorgf\u00e4ltige, genau definierte Koordination zwischen den beteiligten Prozessoren, die auch als <a href=\"https:\/\/openamp.readthedocs.io\/en\/latest\/protocol_details\/lifecyclemgmt_overview.html\">Lebenszyklusmanagement<\/a> bezeichnet wird: Die Startreihenfolge der Prozessoren muss klar definiert sein, ebenso wie die Kommunikationskan\u00e4le und die verwendeten Protokolle zwischen ihnen sowie manchmal auch die Koordination der Abschaltsequenzen.<\/p>\n<div>\n<p>Im Linux-Kontext wird dies mithilfe des \u201e<a href=\"https:\/\/docs.kernel.org\/staging\/remoteproc.html\"><i>remoteproc<\/i><\/a>\u201c-Frameworks erreicht. Nach dem Bootvorgang kann eine Linux-Userspace-Komponente dieses Framework nutzen, um den Echtzeitprozessor (auch als \u201eRemote-Prozessor\u201c bezeichnet) zu steuern, eine Anwendung darauf zu laden und beim Aufbau der erforderlichen Kommunikationskan\u00e4le zu helfen. Der gesamte Prozess ist gut dokumentiert, und es stehen bereits zahlreiche Dokumentationen (remoteproc, <a href=\"https:\/\/docs.kernel.org\/staging\/rpmsg.html\">rpmsg<\/a>, <a href=\"https:\/\/docs.oasis-open.org\/virtio\/virtio\/v1.3\/virtio-v1.3.html\">virtio 1.3<\/a>), Artikel und Konferenzvortr\u00e4ge zur Verf\u00fcgung (<a href=\"https:\/\/wiki.st.com\/stm32mpu\/wiki\/Linux_RPMsg_framework_overview\">ST Microelectronics: \u00dcberblick \u00fcber das Linux-RPMsg-Framework<\/a>, <a href=\"https:\/\/www.rt-rk.com\/rpmsg-based-inter-core-communication-in-heterogeneous-embedded-systems\/\">rt-rk: RPMsg-basierte Inter-Core-Kommunikation in heterogenen eingebetteten Systemen<\/a>, <a href=\"https:\/\/developer.toradex.com\/software\/hmp\/hmp-nxp\/how-to-use-remoteproc\/\">Toradex: Verwendung von RemoteProc<\/a>, <a href=\"https:\/\/www.youtube.com\/watch?v=Ovg3rCZoAdQ\">Iuliana Prodan: \u201eEnhancing OpenAMP: Making Linux and Zephyr Work Better Together\u201c<\/a>). Diese L\u00f6sung eignet sich jedoch nicht f\u00fcr Systeme, die einen sehr schnellen Start des Echtzeitprozessors erfordern. Selbst wenn das Linux-System f\u00fcr einen schnellen Start optimiert ist, betr\u00e4gt die daraus resultierende Startverz\u00f6gerung f\u00fcr den Echtzeitprozessor immer noch mehrere Sekunden. Das ist zu lang, wenn das Echtzeitsystem innerhalb von Millisekunden betriebsbereit sein muss.<\/p>\n<p>Eine L\u00f6sung f\u00fcr dieses Problem besteht darin, den Echtzeitkern vor Linux zu starten und Linux anschlie\u00dfend daran anzuschlie\u00dfen. Dies l\u00e4sst sich zwar durch geringf\u00fcgige \u00c4nderungen an der Bootloader-Konfiguration leicht erreichen, die eigentliche Herausforderung liegt jedoch in der Anpassung des Lebenszyklusmanagements. Bei unver\u00e4nderter Linux-seitiger Konfiguration geht Linux davon aus, die volle Kontrolle \u00fcber den Lebenszyklus zu haben, und setzt den bereits laufenden Echtzeitprozessor zur\u00fcck sowie konfiguriert ihn neu.<\/p>\n<p>&nbsp;<\/p>\n<\/div>\n<p>Die Frage lautet also: Wie k\u00f6nnen wir einen Startvorgang einrichten, bei dem Linux nicht seinem Standard-Lademodell folgt, sondern sich stattdessen an den bereits laufenden Prozessor anbindet? Und wie werden die Kommunikationskan\u00e4le hergestellt, wenn der Lebenszyklus nicht mehr ausschlie\u00dflich von Linux verwaltet wird? Im Gegensatz zum gut dokumentierten Lademodell gibt es kaum bis gar keine Dokumentation dar\u00fcber, wie das Anbindungsmodell implementiert werden kann.<\/p>\n<p>Dieser Artikel ist in zwei Teile gegliedert: In diesem ersten Teil werden die grundlegenden Konzepte und der technische Hintergrund erl\u00e4utert, w\u00e4hrend der zweite Teil, der in K\u00fcrze folgt, eine vollst\u00e4ndige praktische Umsetzung Schritt f\u00fcr Schritt beschreibt.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Verfuegbare-Bausteine\"><\/span>Verf\u00fcgbare Bausteine<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Die Bausteine f\u00fcr den Aufbau einer Kommunikation zwischen zwei unabh\u00e4ngigen Prozessoren sind bereits verf\u00fcgbar. In den folgenden Abschnitten werden sie ihrer jeweiligen Schicht im ISO\/OSI-Schichtenmodell zugeordnet und ihre Rolle kurz beschrieben.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"Gemeinsamer-Speicher-und-Interprozessor-Interrupts\"><\/span>Gemeinsamer Speicher und Interprozessor-Interrupts<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Die Kommunikation zwischen zwei unabh\u00e4ngigen Prozessoren erfordert einen Mechanismus zur Daten\u00fcbertragung und eine M\u00f6glichkeit, sich gegenseitig Signale zu senden. Durch die korrekte Abfolge beider Schritte l\u00e4sst sich eine robuste Interprozessorkommunikation realisieren.<\/p>\n<p>Obwohl es auch andere Methoden gibt, ist der gemeinsame Speicher der g\u00e4ngigste Mechanismus f\u00fcr die Daten\u00fcbertragung zwischen unabh\u00e4ngigen Kernen auf einem einzigen Chip. Beim gemeinsamen Speicher schreibt der sendende Prozessor Daten in einen Speicherbereich, auf den beide Prozessoren zugreifen k\u00f6nnen, und l\u00f6st einen Interprozessor-Interrupt aus, um den empfangenden Prozessor zu benachrichtigen. Der empfangende Prozessor liest dann die Daten aus und sendet eine Best\u00e4tigung \u00fcber den Abschluss des Vorgangs an den Absender zur\u00fcck.<\/p>\n<p>Die Einrichtung und Nutzung von gemeinsam genutztem Speicher f\u00fcr die Kommunikation zwischen Prozessoren bringt drei allgemeine Herausforderungen mit sich: Beide beteiligten Seiten m\u00fcssen sich auf den konkreten Speicherort und die Gr\u00f6\u00dfe des gemeinsam genutzten Speicherbereichs einigen, sie m\u00fcssen m\u00f6glicherweise die Cache-Koh\u00e4renz aufrechterhalten, und der Zugriff auf den gemeinsam genutzten Speicherbereich kann sich auf die Leistung auswirken. Dar\u00fcber hinaus werden Interprozessor-Interrupts meist mit herstellerspezifischen L\u00f6sungen implementiert. In den meisten F\u00e4llen stellt eine dedizierte On-Chip-Peripherie die erforderliche Funktionalit\u00e4t bereit, ben\u00f6tigt jedoch in der Regel Treiberunterst\u00fctzung durch beide beteiligten Betriebssysteme. F\u00fcr diesen Teil der Artikelserie reicht es aus, zu wissen, dass diese Herausforderungen bestehen. Im zweiten Teil wird anhand eines konkreten Beispiels n\u00e4her darauf eingegangen, wie sie gel\u00f6st werden.<\/p>\n<p>Gemeinsamer Speicher und Interprozessor-Interrupts bilden zusammen die physikalische Schicht des ISO\/OSI-Schichtenmodells.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"Die-Ressourcentabelle\"><\/span>Die Ressourcentabelle<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Ein reservierter Bereich im gemeinsamen Speicher allein reicht nicht aus. Beide Seiten m\u00fcssen sich zudem auf eine Definition der gemeinsamen Datenstruktur einigen, und es muss gekl\u00e4rt werden, welche Seite f\u00fcr deren Initialisierung verantwortlich ist. Dies ist die Aufgabe der Ressourcentabelle: Sie ist eine unterst\u00fctzende Datenstruktur zum Aufbau von Kommunikationskan\u00e4len auf der Grundlage des gemeinsamen Speichers.<\/p>\n<p>Das Format und der Zweck der Ressourcentabelle werden durch das <a href=\"https:\/\/docs.kernel.org\/staging\/remoteproc.html\">\u201eremoteproc\u201c-Framework<\/a> von Linux definiert. Sie wird vom Remote-Prozessor verwendet, um Linux mitzuteilen, was er f\u00fcr einen ordnungsgem\u00e4\u00dfen Betrieb ben\u00f6tigt. Dazu geh\u00f6ren die Anzahl und der Typ der Kommunikationskan\u00e4le f\u00fcr \u00fcbergeordnete Protokolle sowie deren Konfigurations- und Statusinformationen.<\/p>\n<p>Das \u201eremoteproc\u201c-Framework legt innerhalb der Ressourcentabelle vier Standard-Ressourcenkategorien fest. Zu diesen Kategorien geh\u00f6ren \u201ecarveout\u201c, \u201edevmem\u201c, \u201etrace\u201c und \u201evdev\u201c. Von diesen spielt in dieser Artikelserie nur \u201evdev\u201c eine Rolle. Dar\u00fcber hinaus f\u00fchrt die Bezeichnung \u201ecarveout\u201c zu einer semantischen \u00dcberschneidung: Einerseits beschreibt sie die statisch definierten Shared-Memory-Abschnitte, andererseits einen in \u201eremoteproc\u201c und dessen Ressourcentabelle integrierten Ressourcentyp. F\u00fcr propriet\u00e4re Anforderungen k\u00f6nnen Entwickler benutzerdefinierte Protokolle \u00fcber einen festgelegten Bereich herstellerspezifischer Ressourcentypen implementieren.<\/p>\n<p>Entscheidend ist, dass die Interaktion zwischen dem Remote- und dem Master-Prozessor als strikter Systemvertrag und nicht als aktiver Austausch w\u00e4hrend der Laufzeit implementiert ist. Der Remote-Prozessor definiert seine Anforderungen statisch zur Kompilierungszeit in der Ressourcentabelle, und der Master-Prozessor liest diese Anforderungen aus, um die Umgebung bereitzustellen. Wenn die Master-Seite die \u00fcber die Tabelle angeforderten Ressourcen nicht bereitstellen kann, kann die Kommunikation nicht erfolgreich sein. Dieser Mechanismus ist unabh\u00e4ngig vom zugrunde liegenden Echtzeitbetriebssystem und funktioniert identisch, unabh\u00e4ngig davon, ob Zephyr, ein anderes RTOS oder eine Bare-Metal-Implementierung verwendet wird.<\/p>\n<p>Wie beim Shared-Memory-Carveout muss der Speicherort f\u00fcr die Ressourcentabelle von beiden Prozessoren vereinbart werden. Bei Verwendung des Load-Modells wird die Ressourcentabelle in einem speziellen Abschnitt innerhalb des ELF-Images platziert, das die Anwendung f\u00fcr den Remote-Prozessor enth\u00e4lt. In diesem Fall extrahiert das \u201eremoteproc\u201c-Framework von Linux die Ressourcentabelle aus diesem ELF-Abschnitt und platziert sie an der richtigen Speicherposition, bevor die Anwendung auf dem Remote-Prozessor gestartet wird. Im Gegensatz dazu erfordert das \u201eattach\u201c-Modell, dass die Ressourcentabelle bereits vor dem Booten von Linux im Speicher abgelegt wird. Sie muss jedoch weiterhin von Linux initialisiert werden. Wie dies im Detail erreicht wird, wird im zweiten Teil dieses Artikels erl\u00e4utert.<\/p>\n<p>Die Ressourcentabelle l\u00e4sst sich nicht einer bestimmten ISO\/OSI-Schicht zuordnen: Sie enth\u00e4lt Konfigurationsinformationen, die f\u00fcr den gesamten Kommunikationsstack relevant sind.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"VirtIO-und-VRings\"><\/span>VirtIO und VRings<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Wie oben erw\u00e4hnt, teilt die Ressourcentabelle der steuernden Seite mit, wie viele Kommunikationskan\u00e4le welcher Art sie erstellen soll, damit beide Seiten diese nutzen k\u00f6nnen. Obwohl benutzerdefinierte Transporte verwendet werden k\u00f6nnten, fordert die entfernte Seite in der Regel eine Kommunikation \u00fcber Virtual I\/O (kurz: virtio) unter Verwendung von zwei VRings an.<\/p>\n<p>Die <a href=\"https:\/\/docs.oasis-open.org\/virtio\/virtio\/v1.3\/virtio-v1.3.html\">VirtIO-Spezifikation<\/a> ist vor allem im Zusammenhang mit virtuellen Maschinen bekannt, doch ihre Konzepte gelten auch f\u00fcr Situationen, in denen zwei Prozessoren \u00fcber gemeinsam genutzten Speicher miteinander kommunizieren. VirtIO unterscheidet zwei Arten von Kommunikationsteilnehmern: Ger\u00e4te und Treiber. Hier stellt Linux die Treiberseite bereit, w\u00e4hrend der Remote-Prozessor als Ger\u00e4t fungiert.<\/p>\n<p>Virtio bietet eine Reihe vordefinierter Ger\u00e4tetypen an. Jeder davon verf\u00fcgt unter anderem \u00fcber eine bekannte Ger\u00e4te-ID, eine bestimmte Anzahl von V-Ringen f\u00fcr vordefinierte Zwecke und ein festgelegtes Laufzeitverhalten.<\/p>\n<p>Mit Virtio tauschen Ger\u00e4te und Treiber Massendaten mithilfe sogenannter V-Rings aus (in der Virtio-Spezifikation werden sie als \u201eVirtqueues\u201c bezeichnet, unter Linux und Zephyr als \u201eV-Ring\u201c). Anstelle der eigentlichen Nutzdaten transportiert ein V-Ring Puffer-Deskriptoren und verwaltet Speicherbereiche, die aus einem gemeinsamen Pufferpool zugewiesen wurden. Ein bemerkenswertes Detail ist die Unidirektionalit\u00e4t eines V-Rings: Die Kommunikation vom Treiber zum Ger\u00e4t erfolgt \u00fcber einen anderen V-Ring als die Kommunikation in die andere Richtung.<\/p>\n<p>Virtio und V-Ringe implementieren die Transportschicht des ISO\/OSI-Schichtenmodells.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"RPMsg\"><\/span>RPMsg<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Aufbauend auf den von virtio implementierten Kommunikationsfunktionen gibt es rpmsg, auch bekannt als \u201eRemote Processor Messaging\u201c. Rpmsg ist ein Nachrichtenbus, der dazu dient, Kommunikationsendpunkte zu \u00f6ffnen und Dienste namentlich anzuk\u00fcndigen. Rpmsg wird von virtio direkt als dedizierter, bekannter Ger\u00e4tetyp unterst\u00fctzt. Seine Spezifikation ist Teil der <a href=\"https:\/\/docs.kernel.org\/staging\/rpmsg.html\">Linux-Kernel-Dokumentation<\/a>.<\/p>\n<p>Sobald ein entferntes virtio-Ger\u00e4t einen rpmsg-Endpunkt erstellt, versucht der Linux-Kernel, einen rpmsg-Treiber zu finden, der dem angek\u00fcndigten Kanalnamen entspricht. Bei Erfolg l\u00e4dt Linux diesen Treiber und beginnt mit der Interaktion mit dem virtuellen Ger\u00e4t. Wenn beispielsweise Zephyr auf der Remote-Seite einen Endpunkt mit dem Namen `rpmsg-tty` erstellt und Linux \u00fcber einen passenden Rpmsg-Ger\u00e4tetreiber verf\u00fcgt, instanziiert Linux ein Ger\u00e4t namens \/dev\/ttyRPMSG0. Dieses neue tty-Ger\u00e4t implementiert die andere Seite der Verbindung. Verf\u00fcgt Linux \u00fcber keinen passenden Treiber, erkennt udev die Ank\u00fcndigung zwar, es wird jedoch kein Treiber geladen.<\/p>\n<p>Die Ank\u00fcndigung eines neuen Dienstes ist auch von der Linux-Seite aus m\u00f6glich. Analog zum obigen Beispiel k\u00f6nnte ein Linux-Treiber ebenfalls einen neuen Endpunkt deklarieren, und Zephyr k\u00f6nnte auf dieses Ereignis reagieren. In diesem Artikel liegt der Schwerpunkt auf Ank\u00fcndigungen, die von Zephyr gemacht werden.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Vergleich-zwischen-Load-und-Attach-Modell\"><\/span>Vergleich zwischen Load- und Attach-Modell<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Die oben genannten Bausteine sind alles, was zur Umsetzung beider Anwendungsf\u00e4lle ben\u00f6tigt wird: sowohl des Load-Modells als auch des Attach-Modells. Da das oberste Ziel darin besteht, den Remote-Kern so fr\u00fch wie m\u00f6glich zu booten, lohnt es sich, einen Schritt zur\u00fcckzutreten und den Boot-Ablauf beider Modelle zu veranschaulichen.<\/p>\n<p>Abbildung 1 zeigt das gut dokumentierte Load-Modell. Nach dem Einschalten des Ger\u00e4ts beginnt der Bootloader auf dem Cortex-A53-Prozessor zu laufen. Der Bootloader l\u00e4dt den Linux-Kernel in den Speicher und startet den Kernel. Nachdem der Linux-Kernel einen funktionsf\u00e4higen Userspace eingerichtet hat, kann ein Prozess das ELF-Image f\u00fcr den Remote-Cortex-M7-Kern ausfindig machen, laden und bereitstellen. Erst jetzt wird der M7-Kern freigegeben, startet Zephyr, und es kann ein Handshake zwischen beiden Prozessoren stattfinden.<\/p>\n<p>Im Gegensatz dazu zeigt Abbildung 2 das \u201eAttach\u201c-Modell. Der Bootloader k\u00fcmmert sich zun\u00e4chst um das Laden und Starten der Anwendung f\u00fcr den entfernten Prozessor, und erst danach wird der Linux-Kernel gestartet. Der M7-Kern beginnt mit der Ausf\u00fchrung, noch bevor der Linux-Kernel in den Speicher geladen wird. Er kann kritische Gesch\u00e4ftslogik ausf\u00fchren, w\u00e4hrend er im Hintergrund darauf wartet, dass Linux bereit ist \u2013 genau das, was f\u00fcr ein Szenario mit fr\u00fchem Systemstart erforderlich ist.<\/p>\n<figure id=\"attachment_71060\" aria-describedby=\"caption-attachment-71060\" style=\"width: 477px\" class=\"wp-caption alignnone\"><a href=\"https:\/\/www.inovex.de\/wp-content\/uploads\/load_model.drawio-2.png\"><img loading=\"lazy\" decoding=\"async\" id=\"image_load_model\" class=\"wp-image-71060 size-full\" src=\"https:\/\/www.inovex.de\/wp-content\/uploads\/load_model.drawio-2.png\" alt=\"\" width=\"477\" height=\"405\" srcset=\"https:\/\/www.inovex.de\/wp-content\/uploads\/load_model.drawio-2.png 477w, https:\/\/www.inovex.de\/wp-content\/uploads\/load_model.drawio-2-300x255.png 300w, https:\/\/www.inovex.de\/wp-content\/uploads\/load_model.drawio-2-400x340.png 400w, https:\/\/www.inovex.de\/wp-content\/uploads\/load_model.drawio-2-360x306.png 360w\" sizes=\"auto, (max-width: 477px) 100vw, 477px\" \/><\/a><figcaption id=\"caption-attachment-71060\" class=\"wp-caption-text\">Abbildung 1: Das Lastmodell. Zuerst wird Linux gebootet, anschlie\u00dfend wird Zephyr auf dem M7 gestartet.<\/figcaption><\/figure>\n<figure id=\"attachment_71058\" aria-describedby=\"caption-attachment-71058\" style=\"width: 497px\" class=\"wp-caption alignnone\"><a href=\"https:\/\/www.inovex.de\/wp-content\/uploads\/attach_model.drawio-2.png\"><img loading=\"lazy\" decoding=\"async\" id=\"image_attach_model\" class=\"wp-image-71058 size-full\" src=\"https:\/\/www.inovex.de\/wp-content\/uploads\/attach_model.drawio-2.png\" alt=\"\" width=\"497\" height=\"405\" srcset=\"https:\/\/www.inovex.de\/wp-content\/uploads\/attach_model.drawio-2.png 497w, https:\/\/www.inovex.de\/wp-content\/uploads\/attach_model.drawio-2-300x244.png 300w, https:\/\/www.inovex.de\/wp-content\/uploads\/attach_model.drawio-2-400x326.png 400w, https:\/\/www.inovex.de\/wp-content\/uploads\/attach_model.drawio-2-360x293.png 360w\" sizes=\"auto, (max-width: 497px) 100vw, 497px\" \/><\/a><figcaption id=\"caption-attachment-71058\" class=\"wp-caption-text\">Abbildung 2: Das Anbindungsmodell. Der Bootloader startet zun\u00e4chst Zephyr auf dem M7, Linux wird sp\u00e4ter angebunden.<\/figcaption><\/figure>\n<p>Die beiden Abbildungen verdeutlichen die Unterschiede hinsichtlich der Reihenfolge und des Zeitablaufs zwischen dem \u201eLoad\u201c- und dem \u201eAttach\u201c-Modell. Im \u201eLoad\u201c-Modell findet fast der gesamte Linux-Bootvorgang zwischen dem Power-On-Reset und der Freigabe des M7-Prozessors statt. Der Bootloader muss ein mehrere Megabyte gro\u00dfes Kernel-Image aus dem Speicher laden und m\u00f6glicherweise dessen Integrit\u00e4t \u00fcberpr\u00fcfen. Der Kernel startet dann, initialisiert seine Speicherverwaltung, sucht nach Treibern, aktiviert Ger\u00e4te und h\u00e4ngt das Root-Dateisystem ein. Erst nachdem diese Schritte abgeschlossen sind, kann das Init-System einen Dienst starten, um das Image f\u00fcr den M7-Prozessor zu laden. Folglich ben\u00f6tigt selbst ein hochoptimiertes System f\u00fcr diesen Ablauf einige Sekunden.<\/p>\n<p>Im Gegensatz dazu erfordert das \u201eAttach\u201c-Modell lediglich den Bootloader als Voraussetzung. Er kopiert ein Anwendungsimage von einigen hundert Kilobyte in den Speicher und gibt den M7-Prozessor sofort frei. Einschlie\u00dflich einer m\u00f6glichen Integrit\u00e4tspr\u00fcfung des M7-Images ist diese Abfolge innerhalb weniger Millisekunden nach dem Power-On-Reset abgeschlossen. Letztendlich wird der gesamte Linux-Bootvorgang aus dem kritischen Pfad der Echtzeitanwendung herausgenommen.<\/p>\n<p>Beide Diagramme zeigen zudem einen anf\u00e4nglichen Handshake zwischen den beiden beteiligten Prozessoren. Ohne hier zu sehr ins Detail zu gehen \u2013 der Folgeartikel wird auf die Einzelheiten eingehen \u2013, umfasst dieser Handshake stets dieselben grundlegenden Schritte:<\/p>\n<ol>\n<li>Linux liest die Ressourcentabelle und identifiziert einen vdev-Eintrag, der ein rpmsg-Ger\u00e4t mit zwei vRings anfordert.<\/li>\n<li>Linux initialisiert die vRings und den Pufferpool innerhalb des f\u00fcr den gemeinsamen Speicher reservierten Bereichs.<\/li>\n<li>Linux signalisiert die Bereitschaft, indem es ein Statusflag im vdev-Eintrag setzt und anschlie\u00dfend Zephyr auf dem M7-Prozessor benachrichtigt.<\/li>\n<li>Zephyr erkennt die \u00c4nderung des Statusflags, initialisiert sein Ende der vrings und gibt seine rpmsg-Endpunkte \u00fcber deren Dienstnamen bekannt.<\/li>\n<li>Linux gleicht jeden bekannt gegebenen Dienstnamen mit seinen rpmsg-Treibern ab und instanziiert die entsprechenden Ger\u00e4te.<\/li>\n<\/ol>\n<p>Bei Anwendung des Lastmodells analysiert \u201eremoteproc\u201c von Linux die Ressourcentabelle, bevor der Speicher belegt und der M7-Kern freigegeben wird, sodass f\u00fcr Zephyr in Schritt 3 nur eine minimale oder gar keine anf\u00e4ngliche Wartezeit entsteht. Im Gegensatz dazu erm\u00f6glicht das \u201eAttach\u201c-Modell, dass Zephyr vor Linux startet. Zwar muss Zephyr in Schritt 3 f\u00fcr eine unbekannte Zeit auf Linux warten, bis die Initialisierung abgeschlossen ist, doch kann es sofort kritische Anwendungsaufgaben ausf\u00fchren, w\u00e4hrend der Kommunikationskanal zur Linux-Seite in einer Hintergrundaufgabe aufgebaut wird. Dies ist jedoch nur m\u00f6glich, wenn Zephyr die Ressourcentabelle selbstst\u00e4ndig in den Speicher laden kann: Die Ressourcentabelle darf nicht mehr Teil des ELF-Images sein. Schlie\u00dflich d\u00fcrfen alle von Zephyr verwendeten Takte, Pins und Peripherieger\u00e4te von Linux unber\u00fchrt bleiben, da Linux diese andernfalls w\u00e4hrend des Bootvorgangs deaktivieren k\u00f6nnte.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Fazit\"><\/span>Fazit<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Damit ist der einf\u00fchrende Teil dieser Artikelserie abgeschlossen, in dem die Grundlagen einer \u201eremoteproc\u201c-Konfiguration mit rpmsg-basierter Kommunikation zwischen den Prozessoren behandelt wurden. Ein fr\u00fcher Start des Echtzeitprozessors erfordert ein anderes Initialisierungsmodell als die herk\u00f6mmliche Bereitstellung, die auf dem \u201eLoad\u201c-Modell basiert. Stattdessen nutzen zeitkritische Anwendungen das \u201eAttach\u201c-Modell und starten den Echtzeitkern fr\u00fchzeitig. Um eine robuste Kommunikation zwischen den Prozessoren herzustellen, nutzen beide Paradigmen dieselben Bausteine: Hardware-Interrupts, Shared-Memory-Carveouts, eine gemeinsame Ressourcentabelle, virtio auf der Transportschicht und rpmsg-Endpunkte. Der zweite Teil dieser Artikelserie behandelt die technischen Details der beteiligten Bausteine und erl\u00e4utert die notwendigen Schritte zur Implementierung des \u201eAttach\u201c-Modells auf einem Toradex Verdin SoM.<\/p>\n<p>Stay tuned!<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Moderne Anwendungsprozessoren werden zunehmend mit mehr als einer Art von CPU in einem Geh\u00e4use ausgeliefert. Dies erm\u00f6glicht eine wesentlich direktere Integration eines funktionsreichen Mehrzweck-Betriebssystems zusammen mit einem Betriebssystem f\u00fcr Echtzeit- oder Sicherheitsanwendungen, verglichen mit dem, was mit separaten, dedizierten Mikroprozessoren oder Controllern m\u00f6glich w\u00e4re.<\/p>\n","protected":false},"author":456,"featured_media":71423,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"ep_exclude_from_search":false,"footnotes":""},"tags":[],"service":[505],"level":[1280],"coauthors":[{"id":456,"display_name":"Stefan Kratochwil","user_nicename":"skratochwil"}],"class_list":["post-71425","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","service-embedded-systems"],"acf":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v28.8 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>Zephyr-Linux-Kointegration \u2013 Erf\u00fcllung der Anforderungen an den fr\u00fchen Systemstart - inovex GmbH<\/title>\n<meta name=\"description\" content=\"Boot-Verz\u00f6gerungen auf Multicore-SoCs vermeiden: Wie das Remoteproc Attach-Model Echtzeitkerne in Millisekunden vor Linux startet. Architektur, VirtIO &amp; RPMsg im Detail.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.inovex.de\/de\/blog\/zephyr-linux-kointegration-frueher-systemstart\/\" \/>\n<meta property=\"og:locale\" content=\"de_DE\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Zephyr-Linux-Kointegration \u2013 Erf\u00fcllung der Anforderungen an den fr\u00fchen Systemstart - inovex GmbH\" \/>\n<meta property=\"og:description\" content=\"Boot-Verz\u00f6gerungen auf Multicore-SoCs vermeiden: Wie das Remoteproc Attach-Model Echtzeitkerne in Millisekunden vor Linux startet. Architektur, VirtIO &amp; RPMsg im Detail.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.inovex.de\/de\/blog\/zephyr-linux-kointegration-frueher-systemstart\/\" \/>\n<meta property=\"og:site_name\" content=\"inovex GmbH\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/inovexde\" \/>\n<meta property=\"article:published_time\" content=\"2026-11-06T07:59:55+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-11-06T08:02:34+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.inovex.de\/wp-content\/uploads\/Zephyr_Linux_Co-Integration.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1500\" \/>\n\t<meta property=\"og:image:height\" content=\"880\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Stefan Kratochwil\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:image\" content=\"https:\/\/www.inovex.de\/wp-content\/uploads\/Zephyr_Linux_Co-Integration-1024x601.png\" \/>\n<meta name=\"twitter:creator\" content=\"@inovexgmbh\" \/>\n<meta name=\"twitter:site\" content=\"@inovexgmbh\" \/>\n<meta name=\"twitter:label1\" content=\"Verfasst von\" \/>\n\t<meta name=\"twitter:data1\" content=\"Stefan Kratochwil\" \/>\n\t<meta name=\"twitter:label2\" content=\"Gesch\u00e4tzte Lesezeit\" \/>\n\t<meta name=\"twitter:data2\" content=\"12\u00a0Minuten\" \/>\n\t<meta name=\"twitter:label3\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data3\" content=\"Stefan Kratochwil\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/zephyr-linux-kointegration-frueher-systemstart\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/zephyr-linux-kointegration-frueher-systemstart\\\/\"},\"author\":{\"name\":\"Stefan Kratochwil\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#\\\/schema\\\/person\\\/7bc6a7ea18496ccb143c7cc4fd4bb73a\"},\"headline\":\"Zephyr-Linux-Kointegration \u2013 Erf\u00fcllung der Anforderungen an den fr\u00fchen Systemstart\",\"datePublished\":\"2026-11-06T07:59:55+00:00\",\"dateModified\":\"2026-11-06T08:02:34+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/zephyr-linux-kointegration-frueher-systemstart\\\/\"},\"wordCount\":2447,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#organization\"},\"image\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/zephyr-linux-kointegration-frueher-systemstart\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/Zephyr_Linux_Co-Integration.png\",\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/zephyr-linux-kointegration-frueher-systemstart\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/zephyr-linux-kointegration-frueher-systemstart\\\/\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/zephyr-linux-kointegration-frueher-systemstart\\\/\",\"name\":\"Zephyr-Linux-Kointegration \u2013 Erf\u00fcllung der Anforderungen an den fr\u00fchen Systemstart - inovex GmbH\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/zephyr-linux-kointegration-frueher-systemstart\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/zephyr-linux-kointegration-frueher-systemstart\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/Zephyr_Linux_Co-Integration.png\",\"datePublished\":\"2026-11-06T07:59:55+00:00\",\"dateModified\":\"2026-11-06T08:02:34+00:00\",\"description\":\"Boot-Verz\u00f6gerungen auf Multicore-SoCs vermeiden: Wie das Remoteproc Attach-Model Echtzeitkerne in Millisekunden vor Linux startet. Architektur, VirtIO & RPMsg im Detail.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/zephyr-linux-kointegration-frueher-systemstart\\\/#breadcrumb\"},\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/zephyr-linux-kointegration-frueher-systemstart\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/zephyr-linux-kointegration-frueher-systemstart\\\/#primaryimage\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/Zephyr_Linux_Co-Integration.png\",\"contentUrl\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/Zephyr_Linux_Co-Integration.png\",\"width\":1500,\"height\":880},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/zephyr-linux-kointegration-frueher-systemstart\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Zephyr-Linux-Kointegration \u2013 Erf\u00fcllung der Anforderungen an den fr\u00fchen Systemstart\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#website\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/\",\"name\":\"inovex GmbH\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"de\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#organization\",\"name\":\"inovex GmbH\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/2021\\\/03\\\/inovex-logo-16-9-1.png\",\"contentUrl\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/2021\\\/03\\\/inovex-logo-16-9-1.png\",\"width\":1921,\"height\":1081,\"caption\":\"inovex GmbH\"},\"image\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#\\\/schema\\\/logo\\\/image\\\/\"},\"sameAs\":[\"https:\\\/\\\/www.facebook.com\\\/inovexde\",\"https:\\\/\\\/x.com\\\/inovexgmbh\",\"https:\\\/\\\/www.instagram.com\\\/inovexlife\\\/\",\"https:\\\/\\\/www.linkedin.com\\\/company\\\/inovex\",\"https:\\\/\\\/www.youtube.com\\\/channel\\\/UC7r66GT14hROB_RQsQBAQUQ\"]},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#\\\/schema\\\/person\\\/7bc6a7ea18496ccb143c7cc4fd4bb73a\",\"name\":\"Stefan Kratochwil\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/1eb853325d0a39ffa27acf77eb3b14be262fb3f67c7482f8d33057d96cd875ef?s=96&d=retro&r=g10096b24c4b4fb574e910a5b3b28238e\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/1eb853325d0a39ffa27acf77eb3b14be262fb3f67c7482f8d33057d96cd875ef?s=96&d=retro&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/1eb853325d0a39ffa27acf77eb3b14be262fb3f67c7482f8d33057d96cd875ef?s=96&d=retro&r=g\",\"caption\":\"Stefan Kratochwil\"},\"url\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/author\\\/skratochwil\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Zephyr-Linux-Kointegration \u2013 Erf\u00fcllung der Anforderungen an den fr\u00fchen Systemstart - inovex GmbH","description":"Boot-Verz\u00f6gerungen auf Multicore-SoCs vermeiden: Wie das Remoteproc Attach-Model Echtzeitkerne in Millisekunden vor Linux startet. Architektur, VirtIO & RPMsg im Detail.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.inovex.de\/de\/blog\/zephyr-linux-kointegration-frueher-systemstart\/","og_locale":"de_DE","og_type":"article","og_title":"Zephyr-Linux-Kointegration \u2013 Erf\u00fcllung der Anforderungen an den fr\u00fchen Systemstart - inovex GmbH","og_description":"Boot-Verz\u00f6gerungen auf Multicore-SoCs vermeiden: Wie das Remoteproc Attach-Model Echtzeitkerne in Millisekunden vor Linux startet. Architektur, VirtIO & RPMsg im Detail.","og_url":"https:\/\/www.inovex.de\/de\/blog\/zephyr-linux-kointegration-frueher-systemstart\/","og_site_name":"inovex GmbH","article_publisher":"https:\/\/www.facebook.com\/inovexde","article_published_time":"2026-11-06T07:59:55+00:00","article_modified_time":"2026-11-06T08:02:34+00:00","og_image":[{"width":1500,"height":880,"url":"https:\/\/www.inovex.de\/wp-content\/uploads\/Zephyr_Linux_Co-Integration.png","type":"image\/png"}],"author":"Stefan Kratochwil","twitter_card":"summary_large_image","twitter_image":"https:\/\/www.inovex.de\/wp-content\/uploads\/Zephyr_Linux_Co-Integration-1024x601.png","twitter_creator":"@inovexgmbh","twitter_site":"@inovexgmbh","twitter_misc":{"Verfasst von":"Stefan Kratochwil","Gesch\u00e4tzte Lesezeit":"12\u00a0Minuten","Written by":"Stefan Kratochwil"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.inovex.de\/de\/blog\/zephyr-linux-kointegration-frueher-systemstart\/#article","isPartOf":{"@id":"https:\/\/www.inovex.de\/de\/blog\/zephyr-linux-kointegration-frueher-systemstart\/"},"author":{"name":"Stefan Kratochwil","@id":"https:\/\/www.inovex.de\/de\/#\/schema\/person\/7bc6a7ea18496ccb143c7cc4fd4bb73a"},"headline":"Zephyr-Linux-Kointegration \u2013 Erf\u00fcllung der Anforderungen an den fr\u00fchen Systemstart","datePublished":"2026-11-06T07:59:55+00:00","dateModified":"2026-11-06T08:02:34+00:00","mainEntityOfPage":{"@id":"https:\/\/www.inovex.de\/de\/blog\/zephyr-linux-kointegration-frueher-systemstart\/"},"wordCount":2447,"commentCount":0,"publisher":{"@id":"https:\/\/www.inovex.de\/de\/#organization"},"image":{"@id":"https:\/\/www.inovex.de\/de\/blog\/zephyr-linux-kointegration-frueher-systemstart\/#primaryimage"},"thumbnailUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/Zephyr_Linux_Co-Integration.png","inLanguage":"de","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.inovex.de\/de\/blog\/zephyr-linux-kointegration-frueher-systemstart\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.inovex.de\/de\/blog\/zephyr-linux-kointegration-frueher-systemstart\/","url":"https:\/\/www.inovex.de\/de\/blog\/zephyr-linux-kointegration-frueher-systemstart\/","name":"Zephyr-Linux-Kointegration \u2013 Erf\u00fcllung der Anforderungen an den fr\u00fchen Systemstart - inovex GmbH","isPartOf":{"@id":"https:\/\/www.inovex.de\/de\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.inovex.de\/de\/blog\/zephyr-linux-kointegration-frueher-systemstart\/#primaryimage"},"image":{"@id":"https:\/\/www.inovex.de\/de\/blog\/zephyr-linux-kointegration-frueher-systemstart\/#primaryimage"},"thumbnailUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/Zephyr_Linux_Co-Integration.png","datePublished":"2026-11-06T07:59:55+00:00","dateModified":"2026-11-06T08:02:34+00:00","description":"Boot-Verz\u00f6gerungen auf Multicore-SoCs vermeiden: Wie das Remoteproc Attach-Model Echtzeitkerne in Millisekunden vor Linux startet. Architektur, VirtIO & RPMsg im Detail.","breadcrumb":{"@id":"https:\/\/www.inovex.de\/de\/blog\/zephyr-linux-kointegration-frueher-systemstart\/#breadcrumb"},"inLanguage":"de","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.inovex.de\/de\/blog\/zephyr-linux-kointegration-frueher-systemstart\/"]}]},{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/www.inovex.de\/de\/blog\/zephyr-linux-kointegration-frueher-systemstart\/#primaryimage","url":"https:\/\/www.inovex.de\/wp-content\/uploads\/Zephyr_Linux_Co-Integration.png","contentUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/Zephyr_Linux_Co-Integration.png","width":1500,"height":880},{"@type":"BreadcrumbList","@id":"https:\/\/www.inovex.de\/de\/blog\/zephyr-linux-kointegration-frueher-systemstart\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.inovex.de\/de\/"},{"@type":"ListItem","position":2,"name":"Zephyr-Linux-Kointegration \u2013 Erf\u00fcllung der Anforderungen an den fr\u00fchen Systemstart"}]},{"@type":"WebSite","@id":"https:\/\/www.inovex.de\/de\/#website","url":"https:\/\/www.inovex.de\/de\/","name":"inovex GmbH","description":"","publisher":{"@id":"https:\/\/www.inovex.de\/de\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.inovex.de\/de\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"de"},{"@type":"Organization","@id":"https:\/\/www.inovex.de\/de\/#organization","name":"inovex GmbH","url":"https:\/\/www.inovex.de\/de\/","logo":{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/www.inovex.de\/de\/#\/schema\/logo\/image\/","url":"https:\/\/www.inovex.de\/wp-content\/uploads\/2021\/03\/inovex-logo-16-9-1.png","contentUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/2021\/03\/inovex-logo-16-9-1.png","width":1921,"height":1081,"caption":"inovex GmbH"},"image":{"@id":"https:\/\/www.inovex.de\/de\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/inovexde","https:\/\/x.com\/inovexgmbh","https:\/\/www.instagram.com\/inovexlife\/","https:\/\/www.linkedin.com\/company\/inovex","https:\/\/www.youtube.com\/channel\/UC7r66GT14hROB_RQsQBAQUQ"]},{"@type":"Person","@id":"https:\/\/www.inovex.de\/de\/#\/schema\/person\/7bc6a7ea18496ccb143c7cc4fd4bb73a","name":"Stefan Kratochwil","image":{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/secure.gravatar.com\/avatar\/1eb853325d0a39ffa27acf77eb3b14be262fb3f67c7482f8d33057d96cd875ef?s=96&d=retro&r=g10096b24c4b4fb574e910a5b3b28238e","url":"https:\/\/secure.gravatar.com\/avatar\/1eb853325d0a39ffa27acf77eb3b14be262fb3f67c7482f8d33057d96cd875ef?s=96&d=retro&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/1eb853325d0a39ffa27acf77eb3b14be262fb3f67c7482f8d33057d96cd875ef?s=96&d=retro&r=g","caption":"Stefan Kratochwil"},"url":"https:\/\/www.inovex.de\/de\/blog\/author\/skratochwil\/"}]}},"_links":{"self":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts\/71425","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/users\/456"}],"replies":[{"embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/comments?post=71425"}],"version-history":[{"count":5,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts\/71425\/revisions"}],"predecessor-version":[{"id":71433,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts\/71425\/revisions\/71433"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/media\/71423"}],"wp:attachment":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/media?parent=71425"}],"wp:term":[{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/tags?post=71425"},{"taxonomy":"service","embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/service?post=71425"},{"taxonomy":"level","embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/level?post=71425"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/coauthors?post=71425"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}