Depuis plusieurs années l’installation de Xenomai sur un Raspberry Pi 1 se fait assez facilement, et les résultats en sont plutôt satisfaisants. Malheureusement l’installation sur un Raspberry Pi 2 ne fonctionnait pas. Le problème a été résolu depuis quelques mois par un patch de Mathieu Rondonneau qui permet d’utiliser la toute dernière version de Xenomai (3.0.2).
Xenomai 3 propose deux modèles de fonctionnement :
- Dans le mode Mercury, les bibliothèques de Xenomai permettent de faire fonctionner du code applicatif (utilisant éventuellement l’API d’un autre système comme VxWorks ou pSOS) sur un noyau Linux standard, de préférence une version PREEMPT_RT.
- Dans le mode Cobalt, le système Adeos (ipipe) capture les interruptions avant le noyau Linux et est donc capable d’activer des tâches Xenomai dans un temps plus prévisible. L’intégration est un peu plus complexe puisqu’elle nécessite de modifier le code du noyau Linux.
C’est ce dernier mode (Cobalt) que nous allons installer.
Préparation
Commençons par télécharger et décompresser l’archive de Xenomai. Je prends la dernière version disponible :
$ wget http://xenomai.org/downloads/xenomai/stable/xenomai-3.0.2.tar.bz2 [...] $ tar xjf xenomai-3.0.2.tar.bz2
Voyons pour quelles versions du kernel le patch ipipe est disponible :
$ ls xenomai-3.0.2/kernel/cobalt/arch/arm/patches/ ipipe-core-3.10.32-arm-13.patch ipipe-core-3.18.20-arm-9.patch README ipipe-core-3.14.44-arm-16.patch ipipe-core-4.1.18-arm-4.patch
Le choix le plus adapté sera un noyau 4.1. Téléchargeons le noyau Linux, plus particulièrement sa version spécifique pour Raspberry Pi :
$ git clone https://github.com/raspberrypi/linux Clonage dans 'linux'... remote: Counting objects: 4883927, done. remote: Compressing objects: 100% (26/26), done. remote: Total 4883927 (delta 20), reused 12 (delta 12), pack-reused 4883889 Réception d'objets: 100% (4883927/4883927), 1.40 GiB | 1.63 MiB/s, done. Résolution des deltas: 100% (4041858/4041858), done. Vérification de la connectivité... fait. Checking out files: 100% (52713/52713), done.
Nous extrayons la branche 4.1 et vérifions le numéro complet :
$ cd linux/ $ git checkout rpi-4.1.y Checking out files: 100% (22027/22027), done. La branche rpi-4.1.y est paramétrée pour suivre la branche distante rpi-4.1.y depuis origin. Basculement sur la nouvelle branche 'rpi-4.1.y' $ head -3 Makefile VERSION = 4 PATCHLEVEL = 1 SUBLEVEL = 21
Le noyau de la branche 4.1 pour Raspberry Pi est un 4.1.21. Le patch ipipe est prévu pour un noyau 4.1.18. Nous pourrions remonter l’historique git pour trouver une version 4.1.18 exacte. Néanmoins, je préfère éviter car nous aurons besoin d’appliquer un second patch, qui a été très probablement produit sur un noyau 4.1.21, et qui entre en conflit avec l’arborescence arch/arm/mach-bcm du 4.1.18.
Préparons une branche de travail afin d’isoler les modifications de Xenomai des sources d’origine :
$ git checkout -b xenomai-3.0.2 Basculement sur la nouvelle branche 'xenomai-3.0.2'
Et vérifions si le patch ipipe s’applique bien :
$ patch --dry-run -p1 < ../xenomai-3.0.2/kernel/cobalt/arch/arm/patches/ipipe-core-4.1.18-arm-4.patch checking file arch/arm/Kconfig Hunk #3 succeeded at 533 (offset 36 lines). Hunk #4 succeeded at 720 (offset 36 lines). [...] checking file mm/mmu_context.c checking file mm/mprotect.c checking file mm/vmalloc.c
Nous voyons les messages Hunk succeeded indiquant que le patch a dû être décalé pour être appliqué correctement, mais aucune erreur ne se produit. L’argument --dry-run de l’exécution ci-dessus permettait de vérifier si le patch s’appliquait correctement sans faire de modifications.
Pour appliquer véritablement le patch ipipe, un script est livré qui permet en outre d’installer le domaine Xenomai proprement dit dans le noyau Linux. Utilisons-le :
$ cd .. $ xenomai-3.0.2/scripts/prepare-kernel.sh --linux=linux/ --arch=arm --ipipe=xenomai-3.0.2/kernel/cobalt/arch/arm/patches/ipipe-core-4.1.18-arm-4.patch
Enregistrons les modifications apportées :
$ cd linux/ $ git add '*' $ git commit -a -m "ipipe-core-4.1.18 patch"
Appliquons maintenant le patch de Mathieu Rondonneau que vous pouvez télécharger ici : patch-xenomai-3-on-bcm-2709.patch
$ cd .. $ wget https://www.blaess.fr/christophe/files/article-2016-05-22/patch-xenomai-3-on-bcm-2709.patch $ cd linux/ $ patch -p1 < ../patch-xenomai-3-on-bcm-2709.patch --dry-run checking file arch/arm/Kconfig checking file arch/arm/mach-bcm2709/armctrl.c checking file arch/arm/mach-bcm2709/bcm2708_gpio.c checking file arch/arm/mach-bcm2709/bcm2709.c checking file arch/arm/mach-bcm2709/include/mach/entry-macro.S
Le patch passe bien sur cette version, appliquons-le en retirant l’argument --dry-run :
$ patch -p1 < ../patch-xenomai-3-on-bcm-2709.patch patching file arch/arm/Kconfig patching file arch/arm/mach-bcm2709/armctrl.c patching file arch/arm/mach-bcm2709/bcm2708_gpio.c patching file arch/arm/mach-bcm2709/bcm2709.c patching file arch/arm/mach-bcm2709/include/mach/entry-macro.S $ git commit -a -m "xenomai-3-on-bcm2709 patch"
Compilations
Kernel Linux et Xenomai
Nous pouvons configurer et compiler ce noyau :
$ make ARCH=arm bcm2709_defconfig HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf # # configuration written to .config # $ make ARCH=arm menuconfig
Deux messages « WARNING » nous indiquent que certains éléments de la configuration actuelle entrent en conflit avec Xenomai. Nous désactivons les entrées suivantes :
CPU Power Management --->
CPU Frequency scaling --->
[ ] CPU Frequency scaling
et
Kernel Features --->
[ ] Contiguous Memory Allocator
puis
Kernel Features --->
[ ] Allow for memory compaction
et enfin
Kernel Hacking --->
[ ] KGDB: kernel debugger --->
Une dernière modification est nécessaire ; elle n’a rien de spécifique à Xenomai. Cela nous assure que le noyau disposera des bons arguments sur sa ligne de commande.
Dans le menu
Boot options --->
passer l’option
Kernel command line type (Use bootloader kernel arguments if available) --->
à la valeur
(X) Extend bootloader kernel arguments
Nous pouvons lancer la compilation avec un :
$ make ARCH=arm CROSS_COMPILE=arm-linux-
Bien entendu cela suppose que nous ayons configuré dans notre variable PATH l’accès à une toolchain de cross-compilation, par exemple générée avec Buildroot comme nous l’avions fait dans l’article « Création d’un système complet avec Buildroot 2015.11« .
Au bout de quelques minutes notre noyau est prêt. Je vais l’installer sur une carte micro-SD possédant deux partitions : BOOT (formatée en vfat) et ROOT (formatée en ext2). La partition BOOT comprend déjà le bootloader du Raspberry Pi obtenu lors de la compilation avec Buildroot 2016.02 (de manière identique à l’article indiqué ci-dessus).
$ cp arch/arm/boot/zImage /media/$USER/BOOT/ $ cp arch/arm/boot/dts/bcm2709-rpi-2-b.dtb /media/$USER/BOOT/
Xenomai en espace utilisateur
Nous allons maintenant compiler les bibliothèques de Xenomai, qui permettent de faire fonctionner le code dans l’espace utilisateur.
$ cd ../xenomai-3.0.2/ $ ./scripts/bootstrap [...] $ ./configure --host=arm-linux --enable-smp [...] $ make [...]
Les bibliothèques et les utilitaires ainsi compilés vont être installés sur la partition ROOT, qui contient un système de fichiers minimal avec Busybox et quelques scripts générés par Buildroot, comme dans l’article mentionné ci-dessus.
L’accès à cette partition ROOT nécessitant les droits d’administrateur, je prépare d’abord une copie de l’ensemble des fichiers à installer que je transfère ensuite avec le préfixe sudo.
$ make DESTDIR=$(pwd)/target install [...] $ sudo cp -a target/* /media/$USER/ROOT/ $ umount /media/$USER/*
Tests
Le moment de vérité est arrivé, on insère la carte micro-SD, on branche une console sur le port série, et on démarre un émulateur de terminal comme Minicom. Voici le résultat :
Uncompressing Linux... done, booting the kernel. [ 0.000000] Booting Linux on physical CPU 0xf00 [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpuacct [ 0.000000] Linux version 4.1.21-logilin+ (cpb@Logilin) (gcc version 4.9.3 (Buildroot 2016.02) ) #2 SMP Sun May 22 08:40:39 CEST 2016 [ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Machine: BCM2709 [ 0.000000] Memory policy: Data cache writealloc [...] [ 0.000000] I-pipe, 19.200 MHz clocksource, wrap in 960767920505705 ms [ 0.000000] clocksource ipipe_tsc: mask: 0xffffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns [ 0.000000] clocksource arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns [ 0.000000] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns [ 0.000001] Switching to timer-based delay loop, resolution 52ns [ 0.000917] Interrupt pipeline (release #4) [...] [ 0.948130] [Xenomai] scheduling class idle registered. [ 0.953408] [Xenomai] scheduling class rt registered. [ 0.958732] I-pipe: head domain Xenomai registered. [ 0.967286] [Xenomai] Cobalt v3.0.2 (Exact Zero) [...] Welcome to Buildroot buildroot login:
Un oeil averti verra passer dans les traces du noyau quelques messages liés à Xenomai ou ipipe. Connectons-nous et examinons le système :
buildroot login: root Password: # uname -a Linux buildroot 4.1.21-logilin+ #2 SMP Sun May 22 08:40:39 CEST 2016 armv7l GNU/Linux # cat /proc/xenomai/version 3.0.2 # cat /proc/ipipe/version 4
Notre système fonctionne bien avec Xenomai et ipipe. Le plus simple pour s’assure de son bon fonctionnement est d’utiliser l’un des outils de test livrés dans /usr/xenomai/bin.
# /usr/xenomai/bin/latency == Sampling period: 1000 us == Test mode: periodic user-mode task == All results in microseconds warming up... RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99) RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst RTD| 2.551| 2.795| 7.290| 0| 0| 2.551| 7.290 RTD| 2.551| 2.809| 7.082| 0| 0| 2.551| 7.290 RTD| 2.498| 2.825| 8.748| 0| 0| 2.498| 8.748 RTD| 2.446| 2.787| 7.393| 0| 0| 2.446| 8.748 RTD| 2.549| 2.784| 6.768| 0| 0| 2.446| 8.748 RTD| 2.497| 2.784| 6.716| 0| 0| 2.446| 8.748 RTD| 2.549| 2.781| 6.611| 0| 0| 2.446| 8.748
Cet outil montre les fluctuations (en micro-secondes) d’un timer de fréquence 1kHz. Ceci est assez révélateur des variations du temps de latence des interruptions également. La colonne la plus intéressante est la dernière à droite, puisqu’elle montre le retard maximum atteint pendant l’exécution. Au bout de quelques minutes, cette valeur se stabilise autour de 9 micro-secondes. En laissant l’expérience pendant une heure et en récupérant un histogramme des latences observées, on obtient les valeurs et graphique suivants :
# ----lat min|----lat avg|----lat max|-overrun|---msw| # 2.563| 3.363| 11.283| 0| 0|
Sur l’axe des abscisses, les latences en micro-secondes. En ordonnées le nombre de cas où chaque latence a été observée. Cet axe est logarithmique. Nous voyons donc qu’une énorme majorité des latences est de 3 ou 4 micro-secondes et que la pire latence est de 12 micro-secondes.
Néanmoins pour des vraies mesures réalistes, il faut stresser le système intensément. Pour ce faire, il existe un script nommé dohell, livré avec Xenomai qui assure une charge très forte en nombre de tâches et opérations d’entrées-sorties. J’ai fait tourner ce script pendant une heure, avec en outre une charge importante en interruptions grâce à un ping en mode flood qui se produisait régulièrement pendant une dizaine de secondes.
# ----lat min|----lat avg|----lat max|-overrun|---msw| # 1.318| 23.331| 61.452| 0| 0|
Enfin, j’ai réalisé une mesure pendant deux heures en alternant les périodes de faible charge et les périodes de charge très intense. Je pense en effet que les pires latences se mesurent plutôt en régimes transitoires qu’en régimes permanents. Il est donc important d’alterner les conditions d’exécution.
# ----lat min|----lat avg|----lat max|-overrun|---msw| # -0.346| 10.508| 62.491| 0| 0|
Nous pouvons remarquer que dans ce dernier cas, la latence minimale est de -0.346 micro-seconde. Ceci peut paraître surprenant mais est normal. Xenomai estime en effet la latence minimale et anticipe les déclenchements des timers de la valeur (en nanosecondes) indiquée dans /proc/xenomai/latency. Nous pourrions donc la corriger ainsi :
# cat /proc/xenomai/latency 10520 # echo $((10520 - 346 )) > /proc/xenomai/latency # cat /proc/xenomai/latency 10156 #
Conclusion
Nous voyons ainsi que le support de Xenomai sur Raspberry Pi 2 est assez simple à configurer et installer. Bien sûr il faudrait faire des tests plus longs et plus complets pour avoir une bonne certitude de la latence maximale mais je pense que la valeur de 63 microsecondes que nous avons obtenue doit en être une assez bonne approche.
N’hésitez pas à me faire part de vos essais et résultats.
Je tiens à remercier Nicolas Schurando qui m’a aidé lors d’une séance de formation à tester cette nouvelle version de Xenomai.
Un grand merci pour ce tuto, ça me donne envie de tenter l’experience et de me mettre à Xenomai.
Bonjour,
Je n’arrive pas à appliquer la procédure pour la Pi 3 en compilant depuis Ubuntu dans une VMWare avec un toolchain.
J’ai suivie tous vos tutos sur en remplacent uniquement par le buildroot que voici :
https://buildroot.org/downloads/buildroot-2016.05-rc3.tar.bz2
Et les commandes du genre :
mkdir -p board/raspberrypi2/
par
mkdir -p board/raspberrypi3/
Si je fais :
cp arch/arm/boot/zImage /media/$USER/boot/
cp arch/arm/boot/dts/bcm2710-rpi-3-b.dtb /media/$USER/boot/
Et que j’insert la SD dans la Pi 3, elle ne démarre plus.
Sa serrez peux être beaucoup vous demandé, mais vous est-il possible de mettre à disposition la dernière Jessie-lite avec Xenomai de pré installé ?
Bonjour, en effet Xenomai ne fonctionne pas (encore) sur Raspberry Pi 3.
Hi, I was able to follow this tutorial and run on the Raspberry Pi 2.
I’ve used the same versions you used but the USB ports are not working.
Did you manage to make the USB port to work?
Merci
Renato
I did not use the USB port, I was always connected on the serial port of the Rasperry Pi.
Maybe a missing module in the kernel configuration ?
Bonjour,
Merci pour cet article très intéressant et clair.
Cependant, je bloque sur la compilation pour xenomai à l’étape make, après le « ./configure –host=arm-linux –enable-smp ».
L’erreur est « Could not find current ARM architecture » suivie de « SMP not supported below armv6, compile with -march=armv6 or above ». Visiblement, aucun des __ARM_ARCH_2__ … __ARM_ARCH_7A__ n’est fourni en variable d’environnement.
Si cela a un rapport, j’utilise « gcc-linaro-4.9-2014.11-x86_64_arm-linux-gnueabihf- » et ai entré la ligne
« make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- » pour la partie Linux avant d’arriver à Xenomai.
J’ai aussi installé quelques outils qui semblaient manquer :
sudo apt-get install autoconf
apt-get install dh-autoreconf
sudo apt-get install build-essential libtool
avant de pouvoir lancer ./scripts/bootstrap
A priori, la cible est un cortex-a7 / arch V7 (RPi2) donc il faudrait avoir __ARM_ARCH_7A__, mais pourriez vous m’indiquer comment le faire ?
Merci d’avance pour votre réponse
En effet, j’ai utilisé un cross-compilateur généré spécifiquement pour la cible Rapsberry Pi 2, comme dans la première partie de cet article, les flags nécessaires sont déjà intégrés dans la configuration du compilateur.
Bonjour,
j’ai suivi la procédure sur un Rpi2 et une Raspbian pré-installé. Cependant, le boot m’amène toujours sur le noyau linux non patché. Qu’ai-je pu oublier ?
Bonjour,
Cordialement.
Hello,
I’m following your tutorial for RP1 B+, do you have a patch file for this processor?
What I mean is do you have a patch file similar to this one:
« patch-xenomai-3-on-bcm-2709.patch »
but for processor 2708?
« patch-xenomai-3-on-bcm-2708.patch »
In case you don’t have it can you help-me figgure out how to do it?
There are five files changed in the patch:
I think I should apply the same patch since at the beginning of the files it is stated the following:
——————– entry-macro.S
»
* arch/arm/mach-bcm2708/include/mach/entry-macro.S
*
* Low-level IRQ helper macros for BCM2708 platforms
»
—————————— armctrl.c
»
/*
* linux/arch/arm/mach-bcm2708/armctrl.c
*
* Copyright (C) 2010 Broadcom
»
—————————— bcm2708_gpio.c
»
/*
* linux/arch/arm/mach-bcm2708/bcm2708_gpio.c
*
* Copyright (C) 2010 Broadcom
»
There is just left the:
—————————— Kconfig
config ARCH_BCM2709
…
select IPIPE_ARM_KUSER_TSC if IPIPE
I think I just move the « select IPIPE_ARM_KUSER_TSC if IPIPE » to the config ARCH_BCM2708 section.
—————————— bcm2709.c
This one I’m not sure what to do.
#ifndef CONFIG_IPIPE
// timer control
writel(0, __io_address(ARM_LOCAL_CONTROL));
// timer pre_scaler
writel(0x80000000, __io_address(ARM_LOCAL_PRESCALER)); // 19.2MHz
//writel(0x06AAAAAB, __io_address(ARM_LOCAL_PRESCALER)); // 1MHz
#endif
if (use_dt)
{
of_clk_init(NULL);
clocksource_of_init();
}
else
dc4_arch_timer_init();
#ifdef CONFIG_IPIPE
// timer control
writel(0, __io_address(ARM_LOCAL_CONTROL));
// timer pre_scaler
writel(0x80000000, __io_address(ARM_LOCAL_PRESCALER)); // 19.2MHz
#endif
Thankyou,
Dracunciliasis
Many thanks. I am a layman who wishes to try realtime linux alike.
Everything works until I come to the SD card.
Would it be possible to simplify the procedure as follows?
Flash a bootloader to a native SD card. Copy the image of xenomai3 binary to the SD.
Insert the SD card
RPI run like Noobs.
Many thanks.
Besides, I followed your procedure on a PC or RPi2 or a VM-Linux. Everythings runs file until SD card. I get blocked there.
Bonjour,
Pendant la copie de zImage dans mon carte SD est ce que je dois supprimer zImage ancienne cré par buildroot?
Bien sûr. Mais gardez-en de préférence une copie au cas où la nouvelle version ne boote pas…
Bonjour ,
por compiler les bibliothèques de Xenomai le fichier bootstrap n’est pas trouvée?
dans tutoriel https://www.blaess.fr/christophe/2012/08/27/xenomai-sur-raspberry-pi/
pourquoi vous avez copier zImage en Kernel.img est n’est en zImage?
2eme probleme: sudo make ARCH=arm INSTALL_MOD_PATH=/media/Root modules_install
il me demande d’installer modules install et lorsque je l’installe il m’affiche qu’il déja instalé?
La version 2012 du bootloader cherchait un noyau nommé
kernel.img.La version actuelle de Buildroot définit le nom du noyau dans le fichier
config.txtcommezImage.Il y a plus compliqué encore : le bootloader des distributions Raspbian actuelles charge le fichier
kernel.imgsi la cible est un Raspberry Pi 1 ou 2, etkernel7.imgsi c’est un Raspberry Pi 3. Le « 7 » fait référence à L’architecture Arm v7 du nouveau system-on-chip du Pi 3.Je ne comprends pas la seconde question : «
sudo make [...] modules_install» sert à copier tous les fichiers modules (les .ko) dans le répertoire «lib/modules/<numero du noyau>/» à partir du chemin$INSTALL_MOD_PATH. Ça n’installe rien.Bonsoir
Merci tout va bien et le system fonctionne mais lorsaque je tape:
$ ./scripts/bootstrap
le fichier bootstrap n’est pas trouvée dans script
est ce que nécessaire de se passer par ces étape?
$ ./scripts/bootstrap
[…]
$ ./configure –host=arm-linux –enable-smp
[…]
$ make
Je vous remercie
Si vous avez bien pris la version 3.0.2 de Xenomai comme indiqué dans l’article, le fichier
bootstrapse trouve bien dans le répertoirescripts.Je viens de le vérifier.
Sinon, vous n’êtes probablement pas dans le bon répertoire.
oui j’ai bien trouvé le fichier désolé. Je dois la compiler avant tout ?
Bonsoir,
j’ai suivi ce tutoriel et je suis bloqué dans la dernière make.pouvez vous m’aidez?
voila ce qui est affiché (les derniers lignes):
../boilerplate/.libs/libboilerplate.a(libboilerplate_la-time.o): error adding symbols: File in wrong format
collect2: error: ld returned 1 exit status
make[3]: *** [libcobalt.la] Erreur 1
make[3]: quittant le répertoire « /home/segec/buildroot/XenoPi2/xenomai-3.0.2/lib/cobalt »
make[2]: *** [all-recursive] Erreur 1
make[2]: quittant le répertoire « /home/segec/buildroot/XenoPi2/xenomai-3.0.2/lib/cobalt »
make[1]: *** [all-recursive] Erreur 1
make[1]: quittant le répertoire « /home/segec/buildroot/XenoPi2/xenomai-3.0.2/lib »
make: *** [all-recursive] Erreur 1
Bonsoir,
merci pour votre tutoriel tout d’abord.
je voudrais savoir comment désactiver les entrées que vous avez cité:
CPU Power Management —>
CPU Frequency scaling —>
[ ] CPU Frequency scaling
[….]
Merci de me répondre
L’édition des ces fonctionnalités du kernel se fait dans le menu de configuration accessible avec « make ARCH=arm menuconfig ».
Bonjour,
Je vous remercie pour ce tutoriel, j’ai suivi tous les étapes avec success, sauf pour l’étape :
~/linux$ ./scripts/bootstrap
-bash: ./scripts/bootstrap: No such file or director
pourtant je suis bien dans le dossier linux
j’ai fait une petite recherche d’auprès du dossier xenomai-3.0.2 il y a effectivement le fichier mais pas dans le dossier linux où nous travaillons
~/xenomai-3.0.2$ ls scripts/
Kconfig.frag Makefile.in dynlist.ld prepare-kernel.sh xeno-config-cobalt.in xeno.in
Makefile.am bootstrap histo.gp wrap-link.sh xeno-config-mercury.in
d’après vous est ce que c’est un problème de patch?
Merci pour votre aide
Bonjour,
En effet pour exécuter cette commande, il faut se placer dans le répertoire de Xenomai.
J’ai rajouté la ligne correspondant à ce déplacement dans l’article.
Merci de cette remarque.
Merci infiniment, ça marche 🙂
Bonjour christophe
Après avoir builder raspberry et l’avoir mis sur carte SD, j’arrive pas à me connecter à la machine, déjà pars que j’ai pas d’écran série pour me connecter, j’aimerai savoir si je peux builder xenomai pour raspberry sur HDMI, car c’est plus facile pour moi de se connecter ainsi.
Ou bien au minimum j’ai un accès ssh, quand j’ai connecté raspberry avec câble RJ45 j’ai remarqué que les led ne s’allume pas, est ce que xenomai n’accepte pas l’interface ethernet?
Merci pour l’aide.
Pas de problème pour utiliser une console graphique ou une connexion SSH.
J’ai juste pris l’habitude d’utiliser le port série, car c’est plus proche des conditions que je rencontre sur les systèmes embarqués sur lesquels je travaille généralement.
Bonjour,
Je suis entrain de suivre les étapes pour la compilation de xenomai+linux sur Raspberry Pi3.
Mais je suis bloquée à l’étape:
wget https://www.blaess.fr/christophe/files/article-2016-05-22/patch-xenomai-3-on-bcm-2709.patch
ça affiche une erreur bizarre :
« » Resolving http://www.blaess.fr (www.blaess.fr)… 213.186.33.17
Connecting to http://www.blaess.fr (www.blaess.fr)|213.186.33.17|:443… connected.
HTTP request sent, awaiting response… 403 Forbidden
2017-03-10 16:44:46 ERROR 403: Forbidden. « » »
Qu’est ce que je dois faire ?
Merci de me répondre .
Bonjour,
Merci de me signaler ce problème. Il est lié à l’utilisation de wget et https.
En attendant de pouvoir le corriger, voici un contournement : utilisez l’option « -U Mozilla » de wget ainsi :
Bonjour ,
Je voulais installer xenomai3 sur la Raspberry Pi 3 (sur laquelle NOOBS est installé su la carte SD) . J’ai une certaine confusion.
Je voulais savoir est-ce je dois utiliser le Buildroot ou pas nécessaire?
les étapes décrites ci-dessus sont-elles identiques pour la Raspberry Pi3?
Merci de m’aider
Bonjour,
À ma connaissance Xenomai ne fonctionne pas encore sur Raspberry Pi 3…
Bonjour,
Alors comment faire pour ajouter l’extension temps réel à raspberry pi 3?
Avec le Raspberry Pi 3 on peut utiliser PREEMPT_RT qui améliore les performances temps réel de Linux, mais pas Xenomai.
Pour mes formations sur Xenomai je continue à utiliser des Pi 2.
Compris!
Mais ma recherche m’a conduit et j’ai trouvé un tuto japonais qui implémente Xenomai 3 sur Raspberry Pi3 .
Je vais l’essayer mais je suis pas sure du résultat.
Si vous voulez le voir juste une petite traduction :
http://artteknika.hatenablog.com/entry/2016/08/23/143400
PS: si vous trouvez que les étapes ne sont pas raisonnables prière de m’informer.
merci
Merci du lien. Les étapes indiquées sont bonnes, ce sont les mêmes que pour le Pi 2, hormis le fichier Device Tree. Ça me surprend, il me semblait que ça ne fonctionnait pas avec le Pi 3. Je vais reprendre mes essais pour vérifier çà.
J’aimerais bien avoir votre réponse si ça fonctionne ou pas
merci pour votre aide
Le système démarre en effet sur un Raspberry Pi 3 avec la même méthode que celle décrite dans cet article. Il faut simplement utiliser le fichier Device Tree « bcm2710-rpi-3-b.dtb » produit lors de la compilation du kernel.
J’ai utilisé un cross-compiler produit par Buildroot 2017-02.
Je n’ai pas fait de vrai test du système, j’ai juste vérifié que ça boote. Je rédigerai une petite note à ce propos dès que j’aurai vérifié que ça marche correctement (notamment, m’assurer que l’on puisse gérer les interruptions des GPIO avec Xenomai).
Merci pour vitre réponse .
Maintenant je suis entrain d’installer Ethercat 1.5.2 depuis ethercat-hg sur la rpi3 . J’ai fait la compilation :
#sudo make
#sudo make modules_install install
#sudo depmod
et quand je fais /etc/init.d/ethercat start la réponse est:
Starting EtherCAT master 1.5.2 modprobe: FATAL: Module ec_master not found.
failed
la commande:
« insserv ethercat » ça marche (rien n’est affiché)
je suis bloquée depuis 2 jours j’ai suivi le tuto point par point mais le problème c’est il n’ya pas de ec_master.ko pour le charger .
qu’est ce qu’il faut faire?
Merci de m’aider
j’ai bien suivi mais j’ai trouvé ces erreurs ….
features.c: In function ‘cobalt_check_features’:
/home/lol/Desktop/rasp/xenomai-3.0.2/lib/cobalt/arch/arm/include/asm/xenomai/syscall.h:69:45: error: invalid register name for ‘__r0’
unsigned long __a0; register unsigned long __r0 __asm__ (« r0 »);
…
qu’est ce qu’il faut faire?
Merci de m’aider
Bonjour,
Je pense qu’il manque un des patches.
Ou alors c’est un problème de cross-compiler. Vous compilez sur un PC ?
oui
sur ubuntu sous virtual box
vous pouvez m’envoyer touts les fichers que je dois mettre sur SD dans un zip svp ?
Non, désolé, j’ai écrit cet article il y a un an. Cela fait bien longtemps que je n’ai plus la carte SD.
Bonjour,
J’ai tout bien fait et tout marche conformément à ce tutoriel. Maintenant que j’ai un xenomai qui tourne avec buildroot. Je fait comment pour dev une application?
Hé hé, la documentation de l’API de Xenomai se trouve ici : http://xenomai.org/api-reference/, mais ce n’est quand même pas très facile.
Quel type d’application temps réel souhaitez vous développer ?
Une passerelle entre un PC et un contrôleur afin de récupérer des infos en temps réel sur mon PC via UDP.
Ma RPi récupère des valeur de PWM d’un contrôleur et les renvoie au PC via UDP.
Mon PC envoie des informations capteur simulé à la RPI via UDP qui les renvoie au controleur.
Bonjour,
Est-il possible selon vous d’établir une communication série temps réel entre le Raspberry Pi 2 sous Xenomai(3) ? Il ne suffit pas d’inclure des librairies rtdm, il faut configurer le port série ttyAMA0 mais je n’ai pas trouvé comment faire, une idée ?
Merci pour votre travail et vos articles !
Bonjour,
La documentation des drivers Serial avec RTDM n’est pas très détaillée en effet : https://xenomai.org/documentation/xenomai-3/html/xeno3prm/group__rtdm__serial.html.
Il y a bien un driver Serial dans Xenomai, mais je n’ai jamais utilisé et l’UART en question (16550A) est celle des PC, pas du Raspberry Pi. La documentation se trouve ici : https://xenomai.org//serial-16550a-driver/.