![\"Xenomai](\"http:\/\/www.blaess.fr\/christophe\/wp-content\/uploads\/2016\/05\/Xenomai-Raspberry-Pi-2.png\")
Depuis plusieurs ann\u00e9es l’installation de Xenomai sur un Raspberry Pi 1 se fait assez facilement, et les r\u00e9sultats en sont plut\u00f4t satisfaisants. Malheureusement l’installation sur un Raspberry Pi 2 ne fonctionnait pas. Le probl\u00e8me a \u00e9t\u00e9 r\u00e9solu depuis quelques mois par un patch de Mathieu Rondonneau qui permet d’utiliser la toute derni\u00e8re version de Xenomai (3.0.2).
\n\n<\/p>\n
Xenomai 3 propose deux mod\u00e8les de fonctionnement :<\/p>\n
C’est ce dernier mode (Cobalt<\/em>) que nous allons installer.<\/p>\n Commen\u00e7ons par t\u00e9l\u00e9charger et d\u00e9compresser l’archive de Xenomai. Je prends la derni\u00e8re version disponible :<\/p>\n Voyons pour quelles versions du kernel le patch ipipe<\/em> est disponible :<\/p>\n Le choix le plus adapt\u00e9 sera un noyau 4.1. T\u00e9l\u00e9chargeons le noyau Linux, plus particuli\u00e8rement sa version sp\u00e9cifique pour Raspberry Pi :<\/p>\n Nous extrayons la branche 4.1 et v\u00e9rifions le num\u00e9ro complet :<\/p>\n Le noyau de la branche 4.1 pour Raspberry Pi est un 4.1.21. Le patch ipipe<\/em> est pr\u00e9vu pour un noyau 4.1.18. Nous pourrions remonter l’historique git<\/em> pour trouver une version 4.1.18 exacte. N\u00e9anmoins, je pr\u00e9f\u00e8re \u00e9viter car nous aurons besoin d’appliquer un second patch, qui a \u00e9t\u00e9 tr\u00e8s probablement produit sur un noyau 4.1.21, et qui entre en conflit avec l’arborescence Pr\u00e9parons une branche de travail afin d’isoler les modifications de Xenomai des sources d’origine :<\/p>\n Et v\u00e9rifions si le patch ipipe<\/em> s’applique bien :<\/p>\n Nous voyons les messages Hunk succeeded<\/em> indiquant que le patch a d\u00fb \u00eatre d\u00e9cal\u00e9 pour \u00eatre appliqu\u00e9 correctement, mais aucune erreur ne se produit. L’argument Pour appliquer v\u00e9ritablement le patch ipipe<\/em>, un script est livr\u00e9 qui permet en outre d’installer le domaine Xenomai proprement dit dans le noyau Linux. Utilisons-le :<\/p>\n Enregistrons les modifications apport\u00e9es :<\/p>\n Appliquons maintenant le patch de Mathieu Rondonneau que vous pouvez t\u00e9l\u00e9charger ici : Le patch passe bien sur cette version, appliquons-le en retirant l’argument Nous pouvons configurer et compiler ce noyau :<\/p>\n Deux messages \u00ab\u00a0WARNING\u00a0\u00bb nous indiquent que certains \u00e9l\u00e9ments de la configuration actuelle entrent en conflit avec Xenomai. Nous d\u00e9sactivons les entr\u00e9es suivantes :<\/p>\n et<\/p>\n puis<\/p>\n et enfin<\/p>\n Une derni\u00e8re modification est n\u00e9cessaire ; elle n’a rien de sp\u00e9cifique \u00e0 Xenomai. Cela nous assure que le noyau disposera des bons arguments sur sa ligne de commande. passer l’option<\/p>\n \u00e0 la valeur<\/p>\n Nous pouvons lancer la compilation avec un :<\/p>\n Bien entendu cela suppose que nous ayons configur\u00e9 dans notre variable Au bout de quelques minutes notre noyau est pr\u00eat. Je vais l’installer sur une carte micro-SD poss\u00e9dant deux partitions : Nous allons maintenant compiler les biblioth\u00e8ques de Xenomai, qui permettent de faire fonctionner le code dans l’espace utilisateur.<\/p>\n Les biblioth\u00e8ques et les utilitaires ainsi compil\u00e9s vont \u00eatre install\u00e9s sur la partition ROOT, qui contient un syst\u00e8me de fichiers minimal avec Busybox et quelques scripts g\u00e9n\u00e9r\u00e9s par Buildroot, comme dans l’article mentionn\u00e9 ci-dessus.<\/p>\n L’acc\u00e8s \u00e0 cette partition Le moment de v\u00e9rit\u00e9 est arriv\u00e9, on ins\u00e8re la carte micro-SD, on branche une console sur le port s\u00e9rie, et on d\u00e9marre un \u00e9mulateur de terminal comme Minicom. Voici le r\u00e9sultat :<\/p>\n Un oeil averti verra passer dans les traces du noyau quelques messages li\u00e9s \u00e0 Xenomai ou ipipe. <\/em>Connectons-nous et examinons le syst\u00e8me :<\/p>\n Notre syst\u00e8me fonctionne bien avec Xenomai et ipipe.<\/em> Le plus simple pour s’assure de son bon fonctionnement est d’utiliser l’un des outils de test livr\u00e9s dans Cet outil montre les fluctuations (en micro-secondes) d’un timer de fr\u00e9quence 1kHz. Ceci est assez r\u00e9v\u00e9lateur des variations du temps de latence des interruptions \u00e9galement. La colonne la plus int\u00e9ressante est la derni\u00e8re \u00e0 droite, puisqu’elle montre le retard maximum atteint pendant l’ex\u00e9cution. Au bout de quelques minutes, cette valeur se stabilise autour de 9 micro-secondes. En laissant l’exp\u00e9rience pendant une heure et en r\u00e9cup\u00e9rant un histogramme des latences observ\u00e9es, on obtient les valeurs et graphique suivants :<\/p>\n Sur l’axe des abscisses, les latences en micro-secondes. En ordonn\u00e9es le nombre de cas o\u00f9 chaque latence a \u00e9t\u00e9 observ\u00e9e. Cet axe est logarithmique. Nous voyons donc qu’une \u00e9norme majorit\u00e9 des latences est de 3 ou 4 micro-secondes et que la pire latence est de 12 micro-secondes.<\/p>\n N\u00e9anmoins pour des vraies mesures r\u00e9alistes, il faut stresser le syst\u00e8me intens\u00e9ment. Pour ce faire, il existe un script nomm\u00e9 Pr\u00e9paration<\/h1>\n
$ wget http:\/\/xenomai.org\/downloads\/xenomai\/stable\/xenomai-3.0.2.tar.bz2<\/strong>\n [...]\n$ tar xjf xenomai-3.0.2.tar.bz2<\/strong><\/pre>\n
$ ls xenomai-3.0.2\/kernel\/cobalt\/arch\/arm\/patches\/<\/strong>\nipipe-core-3.10.32-arm-13.patch\u00a0 ipipe-core-3.18.20-arm-9.patch\u00a0 README\nipipe-core-3.14.44-arm-16.patch\u00a0 ipipe-core-4.1.18-arm-4.patch<\/pre>\n
$ git clone https:\/\/github.com\/raspberrypi\/linux<\/strong>\nClonage dans 'linux'...\nremote: Counting objects: 4883927, done.\nremote: Compressing objects: 100% (26\/26), done.\nremote: Total 4883927 (delta 20), reused 12 (delta 12), pack-reused 4883889\nR\u00e9ception d'objets: 100% (4883927\/4883927), 1.40 GiB | 1.63 MiB\/s, done.\nR\u00e9solution des deltas: 100% (4041858\/4041858), done.\nV\u00e9rification de la connectivit\u00e9... fait.\nChecking out files: 100% (52713\/52713), done.<\/pre>\n
$ cd linux\/<\/strong>\n$ git checkout rpi-4.1.y<\/strong>\nChecking out files: 100% (22027\/22027), done.\nLa branche rpi-4.1.y est param\u00e9tr\u00e9e pour suivre la branche distante rpi-4.1.y depuis origin.\nBasculement sur la nouvelle branche 'rpi-4.1.y'\n$ head -3 Makefile <\/strong>\nVERSION = 4\nPATCHLEVEL = 1\nSUBLEVEL = 21<\/pre>\n
arch\/arm\/mach-bcm<\/code> du 4.1.18.<\/p>\n$ git checkout -b xenomai-3.0.2<\/strong>\nBasculement sur la nouvelle branche 'xenomai-3.0.2'<\/pre>\n
$ patch --dry-run -p1 < ..\/xenomai-3.0.2\/kernel\/cobalt\/arch\/arm\/patches\/ipipe-core-4.1.18-arm-4.patch<\/strong>\nchecking file arch\/arm\/Kconfig\nHunk #3 succeeded at 533 (offset 36 lines).\nHunk #4 succeeded at 720 (offset 36 lines).\n[...]\nchecking file mm\/mmu_context.c\nchecking file mm\/mprotect.c\nchecking file mm\/vmalloc.c<\/pre>\n
--dry-run<\/code> de l’ex\u00e9cution ci-dessus permettait de v\u00e9rifier si le patch s’appliquait correctement sans faire de modifications.<\/p>\n$ cd ..<\/strong>\n$ 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<\/strong><\/pre>\n
$ cd linux\/<\/strong>\n$ git add '*'<\/strong>\n$ git commit -a -m \"ipipe-core-4.1.18 patch\"<\/strong><\/pre>\n
patch-xenomai-3-on-bcm-2709.patch<\/code><\/a><\/p>\n$ cd ..<\/strong>\n$ wget http:\/\/www.blaess.fr\/christophe\/files\/article-2016-05-22\/patch-xenomai-3-on-bcm-2709.patch<\/strong>\n$ cd linux\/<\/strong>\n$ patch -p1 < ..\/patch-xenomai-3-on-bcm-2709.patch --dry-run<\/strong>\nchecking file arch\/arm\/Kconfig\nchecking file arch\/arm\/mach-bcm2709\/armctrl.c\nchecking file arch\/arm\/mach-bcm2709\/bcm2708_gpio.c\nchecking file arch\/arm\/mach-bcm2709\/bcm2709.c\nchecking file arch\/arm\/mach-bcm2709\/include\/mach\/entry-macro.S<\/pre>\n
--dry-run<\/code> :<\/p>\n$ patch -p1 < ..\/patch-xenomai-3-on-bcm-2709.patch<\/strong>\npatching file arch\/arm\/Kconfig\npatching file arch\/arm\/mach-bcm2709\/armctrl.c\npatching file arch\/arm\/mach-bcm2709\/bcm2708_gpio.c\npatching file arch\/arm\/mach-bcm2709\/bcm2709.c\npatching file arch\/arm\/mach-bcm2709\/include\/mach\/entry-macro.S\n$ git commit -a -m \"xenomai-3-on-bcm2709 patch\"<\/strong><\/pre>\n
Compilations<\/h1>\n
Kernel Linux et Xenomai<\/h2>\n
$ make ARCH=arm bcm2709_defconfig<\/strong>\n HOSTCC scripts\/kconfig\/zconf.tab.o\n HOSTLD scripts\/kconfig\/conf\n#\n# configuration written to .config\n#\n$ make ARCH=arm menuconfig<\/strong><\/pre>\n
CPU Power Management --->\n CPU Frequency scaling --->\n [ ] CPU Frequency scaling<\/pre>\n
Kernel Features --->\n [ ] Contiguous Memory Allocator<\/pre>\n
Kernel Features --->\n [ ] Allow for memory compaction<\/pre>\n
Kernel Hacking --->\n [ ] KGDB: kernel debugger ---><\/pre>\n
\nDans le menu<\/p>\nBoot options ---><\/pre>\n
Kernel command line type (Use bootloader kernel arguments if available) ---><\/pre>\n
(X) Extend bootloader kernel arguments<\/pre>\n
$ make ARCH=arm CROSS_COMPILE=arm-linux-<\/strong><\/pre>\n
PATH<\/code> l’acc\u00e8s \u00e0 une toolchain<\/em> de cross-compilation<\/em>, par exemple g\u00e9n\u00e9r\u00e9e avec Buildroot comme nous l’avions fait dans l’article \u00ab\u00a0Cr\u00e9ation d’un syst\u00e8me complet avec Buildroot 2015.11<\/a>\u00ab\u00a0.<\/p>\nBOOT<\/code> (format\u00e9e en vfat)<\/em> et ROOT<\/code> (format\u00e9e en ext2).<\/em> La partition BOOT comprend d\u00e9j\u00e0 le bootloader<\/em> du Raspberry Pi<\/strong> obtenu lors de la compilation avec Buildroot 2016.02<\/strong> (de mani\u00e8re identique \u00e0 l’article indiqu\u00e9 ci-dessus).<\/p>\n$ cp arch\/arm\/boot\/zImage \/media\/$USER\/BOOT\/<\/strong>\n$ cp arch\/arm\/boot\/dts\/bcm2709-rpi-2-b.dtb \/media\/$USER\/BOOT\/<\/strong><\/pre>\n
Xenomai en espace utilisateur<\/h2>\n
$ cd ..\/xenomai-3.0.2\/<\/strong>\n$ .\/scripts\/bootstrap<\/strong> \n [...]\n$ .\/configure --host=arm-linux --enable-smp<\/strong>\n [...]\n$ make<\/strong>\n [...]<\/pre>\n
ROOT<\/code> n\u00e9cessitant les droits d’administrateur, je pr\u00e9pare d’abord une copie de l’ensemble des fichiers \u00e0 installer que je transf\u00e8re ensuite avec le pr\u00e9fixe sudo<\/code>.<\/p>\n$ make DESTDIR=$(pwd)\/target install<\/strong>\n [...]\n$ sudo cp -a target\/* \/media\/$USER\/ROOT\/<\/strong>\n$ umount \/media\/$USER\/*<\/strong><\/pre>\n
Tests<\/h1>\n
Uncompressing Linux... done, booting the kernel.\n[ 0.000000] Booting Linux on physical CPU 0xf00\n[ 0.000000] Initializing cgroup subsys cpuset\n[ 0.000000] Initializing cgroup subsys cpu\n[ 0.000000] Initializing cgroup subsys cpuacct\n[ 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\n[ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d\n[ 0.000000] CPU: PIPT \/ VIPT nonaliasing data cache, VIPT aliasing instruction cache\n[ 0.000000] Machine: BCM2709\n[ 0.000000] Memory policy: Data cache writealloc\n [...]\n[ 0.000000] I-pipe, 19.200 MHz clocksource, wrap in 960767920505705 ms\n[ 0.000000] clocksource ipipe_tsc: mask: 0xffffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns\n[ 0.000000] clocksource arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns\n[ 0.000000] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns\n[ 0.000001] Switching to timer-based delay loop, resolution 52ns\n[ 0.000917] Interrupt pipeline (release #4)\n\n [...]\n[ 0.948130] [Xenomai] scheduling class idle registered.\n[ 0.953408] [Xenomai] scheduling class rt registered.\n[ 0.958732] I-pipe: head domain Xenomai registered.\n[ 0.967286] [Xenomai] Cobalt v3.0.2 (Exact Zero) \n [...]\nWelcome to Buildroot\nbuildroot login:<\/pre>\n
buildroot login: root<\/strong>\nPassword: \n# uname -a<\/strong>\nLinux buildroot 4.1.21-logilin+ #2 SMP Sun May 22 08:40:39 CEST 2016 armv7l GNU\/Linux\n# cat \/proc\/xenomai\/version<\/strong>\n3.0.2\n# cat \/proc\/ipipe\/version<\/strong>\n4<\/pre>\n
\/usr\/xenomai\/bin<\/code>.<\/p>\n# \/usr\/xenomai\/bin\/latency<\/strong>\n== Sampling period: 1000 us\n== Test mode: periodic user-mode task\n== All results in microseconds\nwarming up...\nRTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)\nRTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst\nRTD| 2.551| 2.795| 7.290| 0| 0| 2.551| 7.290\nRTD| 2.551| 2.809| 7.082| 0| 0| 2.551| 7.290\nRTD| 2.498| 2.825| 8.748| 0| 0| 2.498| 8.748\nRTD| 2.446| 2.787| 7.393| 0| 0| 2.446| 8.748\nRTD| 2.549| 2.784| 6.768| 0| 0| 2.446| 8.748\nRTD| 2.497| 2.784| 6.716| 0| 0| 2.446| 8.748\nRTD| 2.549| 2.781| 6.611| 0| 0| 2.446| 8.748<\/pre>\n
# ----lat min|----lat avg|----lat max|-overrun|---msw|\n# 2.563| 3.363| 11.283| 0| 0|<\/pre>\n
![\"Xenomai](\"http:\/\/www.blaess.fr\/christophe\/wp-content\/uploads\/2016\/05\/1-hour-no-load.png\")
<\/a><\/p>\ndohell<\/code>, livr\u00e9 avec Xenomai qui assure une charge tr\u00e8s forte en nombre de t\u00e2ches et op\u00e9rations d’entr\u00e9es-sorties. J’ai fait tourner ce script pendant une heure, avec en outre une charge importante en interruptions gr\u00e2ce \u00e0 un ping<\/code> en mode flood<\/em> qui se produisait r\u00e9guli\u00e8rement pendant une dizaine de secondes.<\/p>\n# ----lat min|----lat avg|----lat max|-overrun|---msw|\n# 1.318| 23.331| 61.452| 0| 0|<\/pre>\n
![\"1h.](\"http:\/\/www.blaess.fr\/christophe\/wp-content\/uploads\/2016\/05\/1-hour-heavy-load.png\")
<\/a><\/p>\n![\"Xenomai](\"http:\/\/www.blaess.fr\/christophe\/wp-content\/uploads\/2016\/05\/2-hours-mixed-load.png\")
<\/a>