Lorsque je voulais intégrer Unikernel dans un système embarqué d'une bonne manière, j'avais besoin d'un équipement capable de faire fonctionner RTOS et Linux en même temps, alors je l'ai porté comme le titre le suggère.
Je pense qu'il existe de nombreuses configurations de démarrage indépendantes de FreeRTOS lors du portage pour Raspberry Pi, mais cette fois, FreeRTOS vous permet de démarrer simultanément avec Linux après avoir quitté u-boot.
Ce serait très facile si vous apportiez un SoC i.MX8M ou ZynqMP qui a déjà une implémentation qui exécute RTOS et Linux en même temps, mais si vous utilisez Raspai, cela devrait vous faire économiser de l'argent et acquérir des connaissances.
Il peut être trouvé ici (https://github.com/TImada/raspi4_freertos). Voir README.md pour savoir comment le construire et l'utiliser.
L'implémentation de base est @eggman FreeRTOS pour Raspberry Pi 3. Merci pour les efforts de nos prédécesseurs m (_ _) m.
Comme décrit en détail dans article de commentaire sur le stub code Raspberry Pi, la zone de mémoire jusqu'à 0xD8 --0xF7 est de 8 octets. Chacun est étiqueté spin_cpuX: X = 0,1,2,3. Si vous voulez lancer le binaire avec le cœur de processeur n ° 3, écrivez l'adresse de début de la table vectorielle dans spin_cpu3 (= adresse 0xF0) et émettez l'instruction SEV, et le cœur de processeur n ° 3 commencera à fonctionner correctement.
Dans ce portage, j'ai laissé l'adresse de la table vectorielle écrire à l'adresse 0xF0 à la commande u-boot mw, mais lorsque cette commande est exécutée sur le cœur du processeur n ° 0, le résultat de l'écriture reste dans le cache et est stocké dans la mémoire physique. Il y avait une situation où cela ne se reflétait pas (Alee ...). CPU core # 3 définit le compteur de programme en regardant la valeur à l'adresse 0xF0, mais si la valeur n'est pas reflétée dans la mémoire physique, la valeur à l'adresse 0xF0 reste 0x0. À ce moment, le cœur de processeur n ° 3 a un code de stub implémenté de sorte que l'instruction WFE soit émise et qu'une sieste soit effectuée.
Pour résoudre ce problème, ce serait bien si la commande dcache flush de u-boot pouvait être utilisée, mais u-boot inclus dans Ubuntu 20.04 LTS pour Raspberry Pi 4B n'avait pas cette commande, donc u-boot J'ai dû recompiler ...
Si vous lancez Linux après avoir expulsé l'exemple FreeRTOS de l'invite u-boot, Linux définira GIC pour Linux et la configuration GIC que vous avez définie précédemment dans FreeRTOS sera écrasée (en particulier le problème). C'était une réécriture des paramètres du distributeur GIC par Linux). Si cela se produit, le chronomètre et les interruptions UART n'entreront pas.
Donc, cette fois, j'ai implémenté un mécanisme du côté FreeRTOS pour détecter le moment où Linux termine le paramètre GIC Distributor, et FreeRTOS réinitialise le paramètre GIC une fois que Linux a terminé le paramètre GIC. Mécanisme de détection est un processus de boucle occupée x2 qui n'est pas convivial pour la Terre. A terme, nous devrons repenser la méthode.
Si vous le connaissez, vous l'avez peut-être déjà remarqué. En fait, si vous utilisez UART1 (mini UART) du côté FreeRTOS, vous n'avez pas besoin de vous soucier d'implémenter UART2 car UART1 était déjà dans l'implémentation de base.
Oui, bien sûr, je le savais, mais j'ai osé le faire. Sourire.
Porté remoteproc / rpmsg afin que Linux et FreeRTOS puissent communiquer.
Recommended Posts