Als ich Unikernel auf gute Weise in ein eingebettetes System integrieren wollte, brauchte ich Geräte, auf denen RTOS und Linux gleichzeitig ausgeführt werden konnten, und portierte sie daher, wie der Titel schon sagt.
Ich bin der Meinung, dass es beim Portieren für Raspberry Pi viele FreeRTOS-unabhängige Boot-Konfigurationen gibt, aber dieses Mal können Sie mit FreeRTOS gleichzeitig mit Linux booten, nachdem Sie von U-Boot gestartet haben.
Es wäre sehr einfach, wenn Sie einen i.MX8M- oder ZynqMP-SoC mitbringen würden, der bereits über eine Implementierung verfügt, auf der RTOS und Linux gleichzeitig ausgeführt werden. Wenn Sie jedoch einen Raspelkuchen verwenden, sollten Sie Geld sparen und Wissen erwerben.
Es kann hier gefunden werden (https://github.com/TImada/raspi4_freertos). Informationen zum Erstellen und Verwenden finden Sie unter "README.md".
Die Basisimplementierung ist @eggmans FreeRTOS für Raspberry Pi 3. Vielen Dank für die Bemühungen unserer Vorgänger m (_ _) m.
Wie im Kommentarartikel zum Raspberry Pi-Stub-Code ausführlich beschrieben, beträgt der Speicherbereich bis zu 0xD8 - 0xF7 8 Byte. Jedes ist mit "spin_cpuX: X = 0,1,2,3" gekennzeichnet. Wenn Sie die Binärdatei mit CPU-Kern Nr. 3 starten möchten, schreiben Sie die Startadresse der Vektortabelle in spin_cpu3 (= Adresse 0xF0) und geben Sie den SEV-Befehl aus. Der CPU-Kern Nr. 3 funktioniert dann ordnungsgemäß.
Bei dieser Portierung habe ich das Schreiben der Vektortabellenadresse an die Adresse 0xF0 dem Befehl u-boot mw überlassen, aber wenn dieser Befehl auf dem CPU-Kern # 0 ausgeführt wird, bleibt das Schreibergebnis im Cache und wird im physischen Speicher gespeichert. Es gab eine Situation, in der es nicht reflektiert wurde (Alee ...). Der CPU-Kern Nr. 3 setzt den Programmzähler, indem er den Wert an der Adresse 0xF0 betrachtet. Wenn der Wert jedoch nicht im physischen Speicher wiedergegeben wird, bleibt der Wert an der Adresse 0xF0 0x0. Zu diesem Zeitpunkt ist im CPU-Kern Nr. 3 ein Stub-Code implementiert, so dass der WFE-Befehl ausgegeben und ein Nickerchen gemacht wird.
Um dieses Problem zu lösen, wäre es schön, wenn der Befehl dcache flush von u-boot verwendet werden könnte, aber der in Ubuntu 20.04 LTS für Raspberry Pi 4B enthaltene u-boot hatte diesen Befehl nicht, also u-boot Ich musste neu kompilieren ...
Wenn Sie Linux nach dem Aufrufen des FreeRTOS-Beispiels über die U-Boot-Eingabeaufforderung starten, legt Linux GIC für Linux fest und die zuvor in FreeRTOS festgelegte GIC-Konfiguration wird überschrieben (insbesondere das Problem). Es war eine Neufassung der GIC Distributor-Einstellungen von Linux. In diesem Fall werden der Tick-Timer und die UART-Interrupts nicht aktiviert.
Deshalb habe ich dieses Mal einen Mechanismus auf der FreeRTOS-Seite implementiert, um zu erkennen, wann Linux die GIC-Verteilereinstellung beendet, und FreeRTOS setzt die GIC-Einstellung erneut zurück, nachdem Linux die GIC-Einstellung abgeschlossen hat. Erkennungsmechanismus ist ein erdschleifender x2-Prozess. Irgendwann müssen wir die Methode überdenken.
Wenn Sie damit vertraut sind, haben Sie es möglicherweise bereits bemerkt. Wenn Sie UART1 (Mini-UART) auf der FreeRTOS-Seite verwenden, müssen Sie sich nicht um die Implementierung von UART2 kümmern, da UART1 bereits in der Basisimplementierung enthalten war.
Ja, natürlich wusste ich es, aber ich habe es gewagt. Lächeln.
Portiert remoteproc / rpmsg, damit Linux und FreeRTOS kommunizieren können.
Recommended Posts