Depuis l’arrivée du Raspberry Pi, j’ai eu envie d’installer Xenomai dessus pour me faire une idée de ses capacités dans le domaine temps réel. J’ai trouvé enfin le temps de m’en occuper ; voici un petit compte-rendu de l’installation.
Récupération des sources
Le noyau Linux vanilla ne contient pas encore les drivers pour le Rapsberrry Pi. Ils sont inclus dans les sources proposées sur le serveur officiel de la Rapsberry Pi Foundation, mais également dans la branche maintenue par Chris Boot. L’avantage de cette dernière est de proposer des versions du kernel plus récentes.
Le patch Adeos que Xenomai intègre dans le noyau Linux est adapté à une version bien particulière de ce dernier. Téléchargeons la dernière version de Xenomai et vérifions le niveau du patch pour processeur Arm.
[Projets]$ mkdir XenoPi [Projets] cd XenoPi [XenoPi]$ wget http://download.gna.org/xenomai/stable/xenomai-2.6.1.tar.bz2 [...] 2012-08-20 16:41:09 (1,58 MB/s) - «xenomai-2.6.1.tar.bz2» sauvegardé [22065780/22065780] [XenoPi]$ tar xjf xenomai-2.6.1.tar.bz2 [XenoPi]$ ls xenomai-2.6.1/ksrc/arch/arm/patches/ adeos-ipipe-2.6.38.8-arm-1.18-08.patch adeos-ipipe-3.0.36-arm-1.18-11.patch ipipe-core-3.2.21-arm-1.patch mxc README [XenoPi]$
Le patch le plus récent est pour un noyau 3.2.21. Par chance, cette version est disponible dans la branche de Chris Boot.
[XenoPi]$ git clone git://github.com/bootc/linux linux-rpi Cloning into 'linux-rpi'... [...] Resolving deltas: 100% (2109352/2109352), done. [XenoPi]$ cd linux-rpi/ [linux-rpi]$ git checkout rpi-3.2.21 Checking out files: 100% (16894/16894), done. Branch rpi-3.2.21 set up to track remote branch rpi-3.2.21 from origin. Switched to a new branch 'rpi-3.2.21' [linux-rpi]$ cd .. [XenoPi]$
Préparation du noyau
Tout d’abord, appliquons le patch de Xenomai sur le noyau Linux 3.2.21
[XenoPi]$ xenomai-2.6.1/scripts/prepare-kernel.sh --arch=arm --linux=linux-rpi/ --adeos=xenomai-2.6.1/ksrc/arch/arm/patches/ipipe-core-3.2.21-arm-1.patch patching file arch/arm/Kconfig [...] patching file mm/mprotect.c patching file mm/vmalloc.c [XenoPi]$
Nous devons à présent appliquer un petit patch spécifique au Raspberry Pi. J’en ignorais l’origine, mais Gilles Chanteperdrix l’a indiquée en commentaire de cet article. Il s’agit d’un patch initialement posté par Ian-Cim sur le forum RaspberryPi.Org.
[XenoPi]$ wget https://www.blaess.fr/christophe/files/article-2012-08-27/rpi-linux-3.2.21-xenomai-2.6.1.patch [XenoPi]$ cd linux-rpi/ [linux-rpi]$ patch -p1 < ../rpi-linux-3.2.21-xenomai-2.6.1.patch patching file arch/arm/Kconfig patching file arch/arm/mach-bcm2708/bcm2708.c [linux-rpi]$
Puis l’on préparer la compilation comme d’habitude après avoir téléchargé un fichier de configuration.
[linux-rpi]$ wget https://www.blaess.fr/christophe/files/article-2012-08-27/config-linux-3.2.21-xenomai [linux-rpi]$ cp config-linux-3.2.21-xenomai .config [linux-rpi]$ make ARCH=arm menuconfig [...] [linux-rpi]$
Compilation et installation du noyau
Pour la compilation, j’ai préparé une cross-toolchain avec Buildroot. Elle se trouve sur ma machine dans /usr/local/cross-rpi/. En outre, j’ai inséré la carte SD qui sert de mémoire de masse au Raspberry Pi dans mon poste de développement. Elle dispose de deux partitions qui sont visibles dans /media/Boot (le bootloader et l’image du kernel) et /media/Root (l’arborescence des fichiers).
[linux-rpi]$ make ARCH=arm CROSS_COMPILE=/usr/local/cross-rpi/usr/bin/arm-linux- [...] [linux-rpi]$ cp arch/arm/boot/zImage /media/Boot/kernel.img [linux-rpi]$ sudo make ARCH=arm INSTALL_MOD_PATH=/media/Root modules_install [...] [linux-rpi]$ cd .. [XenoPi]$
Boot du kernel
Après avoir démarré mon Raspberry Pi, sur lequel j’ai installé un petit système minimal, je me connecte par SSH.
[XenoPi]$ ssh root@192.168.5.152 root@192.168.5.152's password: ~ # uname -a Linux (none) 3.2.21-xenomai+ #1 PREEMPT Mon Aug 20 09:26:26 CEST 2012 armv6l GNU/Linux ~ # cd /proc/xenomai/ /proc/xenomai # ls acct heap latency sched timebases version apc interfaces registry schedclasses timer faults irq rtdm stat timerstat /proc/xenomai # cat version 2.6.1 /proc/xenomai #
Notre noyau est bien installé et le système Xenomai y est présent. Vérifions quelques paramètres.
/proc/xenomai # cat stat CPU PID MSW CSW PF STAT %CPU NAME 0 0 0 0 0 00500080 100.0 ROOT 0 0 0 1296 0 00000000 0.0 IRQ3: [timer] /proc/xenomai # cat sched CPU PID CLASS PRI TIMEOUT TIMEBASE STAT NAME 0 0 idle -1 - master R ROOT /proc/xenomai # cat irq IRQ CPU0 3: 1031 [timer] 259: 0 [virtual] /proc/xenomai # cat latency 9000 /proc/xenomai #
La latence minimale par défaut (entre l’arrivée d’une interruption et la prise en charge par son handler) est de 9 microsecondes, ce qui me paraît a priori un peu élevé.
Compilation et installation de Xenomai
La compilation des bibliothèques de Xenomai se fait de manière traditionnelle, sur le PC de développement.
[XenoPi]$ cd xenomai-2.6.1/
[xenomai-2.6.1]$ PATH=$PATH:/usr/local/cross-rpi/usr/bin/
[xenomai-2.6.1]$ ./configure --host=arm-linux CFLAGS='-march=armv6' LDFLAGS='-march=armv6'
configure: WARNING: if you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used
checking build system type... i686-pc-linux-gnu
[...]
config.status: linking ./include/asm-generic to src/include/asm-generic/xenomai
config.status: executing depfiles commands
config.status: executing libtool commands
[xenomai-2.6.1]$ make
[...]
[xenomai-2.6.1]$ make DESTDIR=$(pwd)/rpi install
[xenomai-2.6.1]$ cd rpi
[rpi]$ tar cf xenomai.tar usr/xenomai/bin/ usr/xenomai/lib/ usr/xenomai/sbin/
Je transfère alors l’archive contenant les bibliothèques et les exécutables de test sur le Raspberry Pi.
[rpi]$ scp xenomai.tar root@192.168.5.152:/root root@192.168.5.152's password: xenomai.tar 100% 1290KB 1.3MB/s 00:00 [rpi]$
Puis je me re-connecte sur le Raspberry Pi et je déploie l’archive.
[XenoPi]$ ssh root@192.168.5.152 root@192.168.5.152's password: ~ # cd / / # tar xf /root/xenomai.tar / # ls usr/xenomai/bin/ arith insn_read switchtest check-vdso insn_write wakeup-time clocktest irqloop wf_generate cmd_bits klatency wrap-link.sh cmd_read latency xeno cmd_write mutex-torture-native xeno-config cond-torture-native mutex-torture-posix xeno-regression-test cond-torture-posix regression xeno-test cyclictest rtcanrecv xeno-test-run dohell rtcansend xeno-test-run-wrapper insn_bits rtdm / #
Test d’installation
Pour tester rapidement le fonctionnement Xenomai, il est habituel de lancer l’outil latency visible ci-dessus.
/ # cd /usr/xenomai/bin /usr/xenomai/bin # ./latency -p 100 == Sampling period: 100 us == Test mode: periodic user-mode task == All results in microseconds warming up... RTT| 00:00:01 (periodic user-mode task, 100 us period, priority 99) RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst RTD| -4.000| -2.000| 8.000| 0| 0| -4.000| 8.000 RTD| -4.000| -2.000| 13.000| 0| 0| -4.000| 13.000 RTD| -5.000| -2.000| 15.000| 0| 0| -5.000| 15.000 RTD| -5.000| -2.000| 10.000| 0| 0| -5.000| 15.000 RTD| -5.000| -2.000| 16.000| 0| 0| -5.000| 16.000 RTD| -5.000| -2.000| 9.000| 0| 0| -5.000| 16.000 RTD| -4.000| -2.000| 9.000| 0| 0| -5.000| 16.000 RTD| -5.000| -2.000| 8.000| 0| 0| -5.000| 16.000 RTD| -5.000| -2.000| 8.000| 0| 0| -5.000| 16.000 RTD| -4.000| -2.000| 19.000| 0| 0| -5.000| 19.000 RTD| -4.000| -2.000| 11.000| 0| 0| -5.000| 19.000 RTD| -4.000| -2.000| 12.000| 0| 0| -5.000| 19.000 RTD| -5.000| -2.000| 11.000| 0| 0| -5.000| 19.000 RTD| -5.000| -2.000| 11.000| 0| 0| -5.000| 19.000 RTD| -5.000| -2.000| 11.000| 0| 0| -5.000| 19.000 RTD| -5.000| -2.000| 12.000| 0| 0| -5.000| 19.000 RTD| -4.000| -2.000| 11.000| 0| 0| -5.000| 19.000 RTD| -5.000| -2.000| 12.000| 0| 0| -5.000| 19.000 RTD| -5.000| -2.000| 8.000| 0| 0| -5.000| 19.000 RTD| -4.000| -2.000| 8.000| 0| 0| -5.000| 19.000 RTD| -4.000| -2.000| 8.000| 0| 0| -5.000| 19.000 RTT| 00:00:22 (periodic user-mode task, 100 us period, priority 99) RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst RTD| -5.000| -1.000| 8.000| 0| 0| -5.000| 19.000 (Contrôle-C) ---|-----------|-----------|-----------|--------|------|------------------------- RTS| -5.000| -1.000| 19.000| 0| 0| 00:00:23/00:00:23 /usr/xenomai/bin #
Nous voyons apparaître des latences négatives, ce qui est signe d’une mauvaise configuration de la latence minimale (voir cet article pour plus de détails). Cherchons la véritable valeur.
/usr/xenomai/bin # echo 0 > /proc/xenomai/latency /usr/xenomai/bin # ./latency -p 100 == Sampling period: 100 us == Test mode: periodic user-mode task == All results in microseconds warming up... RTT| 00:00:01 (periodic user-mode task, 100 us period, priority 99) RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst RTD| 5.000| 6.000| 17.000| 0| 0| 5.000| 17.000 RTD| 4.000| 6.000| 17.000| 0| 0| 4.000| 17.000 RTD| 5.000| 7.000| 17.000| 0| 0| 4.000| 17.000 RTD| 5.000| 7.000| 20.000| 0| 0| 4.000| 20.000 RTD| 5.000| 7.000| 20.000| 0| 0| 4.000| 20.000 RTD| 4.000| 6.000| 17.000| 0| 0| 4.000| 20.000 RTD| 4.000| 6.000| 18.000| 0| 0| 4.000| 20.000 RTD| 4.000| 6.000| 17.000| 0| 0| 4.000| 20.000 [...] RTD| 4.000| 6.000| 18.000| 0| 0| 3.000| 33.000 RTD| 5.000| 6.000| 19.000| 0| 0| 3.000| 33.000 RTD| 5.000| 6.000| 19.000| 0| 0| 3.000| 33.000 RTD| 4.000| 6.000| 17.000| 0| 0| 3.000| 33.000 RTD| 4.000| 6.000| 18.000| 0| 0| 3.000| 33.000 RTD| 5.000| 7.000| 19.000| 0| 0| 3.000| 33.000 (Contrôle-C) ---|-----------|-----------|-----------|--------|------|------------------------- RTS| 3.000| 6.000| 33.000| 0| 0| 00:20:04/00:20:04
Après vingt minutes de fonctionnement sous une charge modérée, nous obtenons une latence minimale de 3 microsecondes, ce qui est plus crédible que les 9 microsecondes précédentes. Nous pouvons fixer la valeur (dans un script de démarrage par exemple).
/usr/xenomai/bin # echo 3000 > /proc/xenomai/latency /usr/xenomai/bin #
Mesure de latence sous charge moyenne
J’ai commencé par une exécution de latency pendant deux heures et demi avec une charge moyenne (quelques processus actifs et plusieurs connexions réseau).
/usr/xenomai/bin # ./latency -p 100 == Sampling period: 100 us == Test mode: periodic user-mode task == All results in microseconds warming up... RTT| 00:00:01 (periodic user-mode task, 100 us period, priority 99) RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst RTD| 1.000| 3.000| 15.000| 0| 0| 1.000| 15.000 RTD| 2.000| 3.000| 14.000| 0| 0| 1.000| 15.000 RTD| 2.000| 3.000| 18.000| 0| 0| 1.000| 18.000 RTD| 1.000| 3.000| 15.000| 0| 0| 1.000| 18.000 [...] TT| 02:29:49 (periodic user-mode task, 100 us period, priority 99) RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst RTD| 1.000| 3.000| 16.000| 0| 0| 0.000| 33.000 RTD| 1.000| 3.000| 15.000| 0| 0| 0.000| 33.000 RTD| 1.000| 3.000| 16.000| 0| 0| 0.000| 33.000 RTD| 1.000| 3.000| 16.000| 0| 0| 0.000| 33.000 RTD| 1.000| 3.000| 16.000| 0| 0| 0.000| 33.000 RTD| 2.000| 3.000| 16.000| 0| 0| 0.000| 33.000 RTD| 1.000| 3.000| 13.000| 0| 0| 0.000| 33.000 RTD| 1.000| 3.000| 13.000| 0| 0| 0.000| 33.000 RTD| 2.000| 3.000| 14.000| 0| 0| 0.000| 33.000 RTD| 2.000| 3.000| 14.000| 0| 0| 0.000| 33.000 RTD| 1.000| 3.000| 14.000| 0| 0| 0.000| 33.000 RTD| 1.000| 3.000| 14.000| 0| 0| 0.000| 33.000 RTD| 1.000| 3.000| 14.000| 0| 0| 0.000| 33.000 (Contrôle-C) ---|-----------|-----------|-----------|--------|------|------------------------- RTS| 0.000| 3.000| 33.000| 0| 0| 02:30:01/02:30:01 /usr/xenomai/bin #
La latence maximale dans ces conditions est de 33 microsecondes, ce qui est très bon. En outre, nous voyons que sur les échantillons d’une seconde, la latence maximale est généralement de 15 à 16 microsecondes.
Mesure de latence sous haute charge
J’ai relancé latency pour un petit test (deux heures) sous une charge plutôt élevée en processus et en interruption. J’ai lancé sur une autre console le script dohell par périodes de cinq minutes avec quelques secondes de repos entre chaque cycle. En outre un ping flood sur l’interface ethernet du Raspberry Pi était exécuté depuis un autre poste.
# ./latency -p 100 -T 7200 == Sampling period: 100 us == Test mode: periodic user-mode task == All results in microseconds warming up... RTT| 00:00:01 (periodic user-mode task, 100 us period, priority 99) RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst RTD| 5.000| 12.000| 22.000| 0| 0| 5.000| 22.000 RTD| 5.000| 12.000| 37.000| 0| 0| 5.000| 37.000 RTD| 1.000| 12.000| 34.000| 0| 0| 1.000| 37.000 RTD| 5.000| 12.000| 22.000| 0| 0| 1.000| 37.000 RTD| 5.000| 12.000| 35.000| 0| 0| 1.000| 37.000 RTD| 4.000| 12.000| 22.000| 0| 0| 1.000| 37.000 RTD| 4.000| 12.000| 35.000| 0| 0| 1.000| 37.000 RTD| 5.000| 12.000| 22.000| 0| 0| 1.000| 37.000 RTD| 4.000| 12.000| 32.000| 0| 0| 1.000| 37.000 RTD| 4.000| 12.000| 22.000| 0| 0| 1.000| 37.000 RTD| 5.000| 12.000| 39.000| 0| 0| 1.000| 39.000 RTD| 5.000| 12.000| 22.000| 0| 0| 1.000| 39.000 [...] RTD| 2.000| 12.000| 23.000| 0| 0| -1.000| 42.000 RTD| 6.000| 12.000| 26.000| 0| 0| -1.000| 42.000 RTD| 4.000| 11.000| 21.000| 0| 0| -1.000| 42.000 RTD| 5.000| 11.000| 26.000| 0| 0| -1.000| 42.000 RTD| 6.000| 12.000| 18.000| 0| 0| -1.000| 42.000 RTD| 6.000| 12.000| 29.000| 0| 0| -1.000| 42.000 RTD| 6.000| 12.000| 23.000| 0| 0| -1.000| 42.000 ---|-----------|-----------|-----------|--------|------|------------------------- RTS| -1.000| 11.000| 42.000| 0| 0| 02:00:00/02:00:00
Après deux heures sous une forte charge, la latence maximale est de 42 microsecondes, ce qui est tout à fait tolérable pour de nombreuses applications temps réel. Nous pouvons remarquer qu’apparaissent encore des latences négatives (ou plutôt une seule occurence d’une latence négative), ce qui signifie qu’il faudrait plutôt inscrire la valeur 2 dans /proc/xenomai/latency
Conclusion
Au terme de cette brève expérience, je pense que le petit Raspberry Pi peut être tout à fait convaincant dans le cadre de systèmes temps réel, en utilisant le patch Xenomai bien entendu. Je vais mener d’autres expérimentations plus poussées, que je récapitulerai ici.
En comparaison avec la Pandaboard, au vu des tests effectués et des résultats indiqués sur tes précédents billets, la latence max en pleine charge de la raspberry pi est moins importante sur la raspberry pi (42 us de moyenne contre 51us de moyenne pour la Pandaboard), alors qu’en charge moyenne, c’est le contraire (33us contre 17 us).
Dis moi si je me trompe ?
Pour la Raspberry Pi, mon test était relativement court (2 heures) et la charge en interruption n’était pas très élevée. Je vais recommencer le test prochainement, avec un test longue durée (plusieurs jours) et une charge très élevée pour avoir une idée des latences max. absolues.
Je pense que l’origine du patch se trouve ici:
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=41&t=12368&p=133156&hilit=xenomai#p133156
Merci. J’ai mis à jour l’article.
Bonjour,
Merci beaucoup pour ce billet. J’ai pas réussi à trouver comment créer la toolchain, pourrais-tu me renseigner ?
Merci !
Bonjour,
J’utilise mon Pi framboise avec un noyau (3.2.21-ipipe) patché par Adeos et Xenomai (2.6.1). Je voudrais utiliser le port série avec RTDM (Real Time Driver Model), mais je suis confronté à quelques difficultés.
– J’ai activé le pilote 16440A UART et configuré le noyau en acces mode sur Memory-mapped I/O
– j’ai cherché dans le journal du noyau pour trouver le MMIO et l’IRQ
dev: f1: ttyAMA0 à MMIO 0x20201000 (irq = 83) est une PL011 rev3
– Désactiver le pilote du port série du noyau:
setserial / dev/ttyAMA0 aucune uart
– J’ai chargé le module xeno_16550A
modprobe xeno_16550A mem = 0x20201000 irq = 83 start_index = 0 baud_base = 115200
Le module semble être bien chargé
root @ jedPI: ~ / rtserial # cat / proc / xenomai / rtdm / named_devices
Nom Hash Driver / proc
60 rtser0 xeno_16550A rtser0
Enfin, j’ai compilé et exécuté cet exemple : (http://powet.eu/raspberrypi/cross_link.c)
J’ai toujours ce message d’erreur « Connection timed out »
root @ jedPI:. ~ / examples # / cross_link
principale: write-config écrite
principal: lecture fichier ouvert
principal: lecture-config écrite
principal: lecture spéciale créée
principal: départ en lecture tâche
Nr | écrivez-> irq | irq-> read | write-> read |
————————————————– ———
read_task: erreur sur RTSER_RTIOC_WAIT_EVENT, Connection timed out
read_task: erreur sur RTSER_RTIOC_WAIT_EVENT, Connection timed out
read_task: erreur sur RTSER_RTIOC_WAIT_EVENT, Connection timed out
J’ai aussi constaté que le nombre d’interruptions n’augmentent pas, pourtant je suis sûr que mon Atmega328 envoie des données.
root @ jedPI: ~ # cat / proc / xenomai / irq
IRQ CPU0
3: 1275474 [timer]
83: 0 rtser0
259: 248 [virtuel]
Je pense que les interruptions ne sont pas déclenchées, mais je ne sais pas pourquoi.
Est-ce que vous avez une piste ?
Merci d’avance,
JeD
Bonjour,
Je ne parviens pas à booter sur le kernel patché, que sur le normal.
Voila ce que j’obtiens :
http://cl.ly/image/2M1s1I273G2Z
Une idée ?
Merci !
——————————-
>>Bonjour,
>>
>>Je ne parviens pas à booter sur le kernel patché, que sur le normal.
>>
>>Voila ce que j’obtiens :
>>
>>http://cl.ly/image/2M1s1I273G2Z
>>
>>Une idée ?
>>
>>Merci !
————————————
Hi Ugo,
I have had totally the same problem. The compiled new kernel could not mount the root=/dev/mmcblk0p2 partition with ext4 type:
« Kernel Panic – not syncing: VFS: Unable to mount root fs on unknown-block(179,2) »
I donno the reason to be honest. What I have found is the following:
http://powet.eu/2012/07/25/raspberry-pi-xenomai/
It describes totally the same methods to compile kernel, as Chris does do here, except one difference:
he uses a different config file:
http://powet.eu/raspberrypi/.config
Use that one instead of « config-linux-3.2.21-xenomai » and it will work!!! I donno why, I donno the reason, I should have compared the 2 config files rigorously, but I did not do that.
Good luck.
—————————-
Hi Chris,
I love your blog, its magnificent. Although I dont speak in French at all, I always translate it with google 😛
Have a nice day.
Hi !
I think the main difference is the « ext4 filesystems » which is compiled as module in my config file, and compiled statically in the kernel of Powet config file.
Indeed I usually avoid journalling file systems (Ext3, Ext4…) on flash cards, so I configured these filesystems as kernel modules (not available to mount root filesystem).
Ugo, could you turn Ext3 and Ext4 filesystems to ‘Y’ in the config menu and try to boot again ?
Hi Chris,
Yup that was the problem exactry, I tested it.
I have changed File Systems->Ext4 from to in menuconfig (let it be statically linked) and now it works like charm.
You know, if you put the ‘official’ raspberry Debian wheezy image on SD card that is partitioned to p1:FAT16, p2:EXT4…so the problem is obvious. You must link ext4 fs statically or change p2 to ext2. As you like it.
Thx, be good,
Laci
Thank you very much for your help, I will try this =)
Bonjour Christophe,
Merci pour ce tuto! Je débute avec le RPi et linux. J’aimerai tester Xenomai, mais je bloque dès le début lors de la préparation du noyau:
root@[…]/XenoPi# xenomai-2.6.1/scripts/prepare-kernel.sh –arch=arm –linux=linux-rpi/ –adeos=xenomai-2.6.1/ksrc/arch/arm/patches/ipipe-core-3.2.21-arm-1.patch
bash: xenomai-2.6.1/scripts/prepare-kernel.sh: Permission denied
J’ai fais un chmod a+x prepare-kernel.sh avant l’exécution mais ça ne change rien. Une idée?
Pierrot
Le « chmod a+x prepare-kernel.sh » ne devrait pas être nécessaire normalement. Où se trouvent les répertoires de Xenomai et de Linux ? Ce ne serait pas sur un disque externe ou une clé montés sans l’autorisation d’exécution ?
En effet c’était le cas.
Merci Christophe
Hello !
J’ai suivi toutes les étapes jusqu’à et y compris l’installation du noyau. J’ai utilisé la carte SD officielle (2012-10-28-wheezy-raspbian.img). DU coup, j’ai activé ext4 aussi dans le menuconfig.
Malheureusement, au boot sur le RPi il ne me met aucune erreur, par contre impossible d’effectuer le expand_rootfs ni de lancer le serveur ssh. J’ai donc lancé apt-get update et upgrade mais apparament il essaie d’installer des version plus anciennes des packages et du coup ça foire (il veut une version de libc6 plus ancienne). Ca me fait un segmentation fault par ci par là : subprocess new pre-installation script was killed by signal (Segmentation fault)
Est-ce lié au faut que wheezy est basé sur le kernel 3.2.27 à la base? Que puis-je faire pour regler le probleme?
J’ai un peu du mal à saisir ce qui est installé sur la carte, ce qui fonctionne et ce qui ne fonctionne pas. Le noyau est compilé maison si j’ai bien compris. La libc6 provient d’où ? de la Raspbian ?
J’aurais tendance à démarrer sur le kernel initial de la Raspbian pour faire l’apt-get update et redémarrer ensuite sur le kernel perso.
Oui en gros j’ai juste téléchargé l’image officielle de Raspbian Wheezy et j’ai monté les deux partitions sur mon ordi « développement ». J’ai pris le noyau de bootc comme indiqué dans ton article, que j’ai patché avec xenomai et le patch ian-cim. ensuite j’ai transféré l’image boot sur la partition boot et j’ai compilé + installé kernel&xenomai dans la partition root, ensuite j’ai dd’é l’image sur la carte SD.
Donc oui, la libc6 provient bien de Raspbian. uname -a affiche bien le kernel 3.2.21 avec xenomai. Le problème c’est que raspi-config perd ses fonctionnalités et le apt-get upgrade fait n’importe quoi. (Je sais pas donner trop de détails car à chaque fois que ça foire je dois reflasher la carte SD et ca dure un certain temps …). Il y a sans doute d’autres problèmes mais en ce moment j’ai testé que ca (LXDE fonctionne sans problème apparemment)
Mais en bref : je tape sudo apt-get update, aucun soucis. sudo apt-get upgrade: il y a bien 80MB de mises à jour donc je fais Y. Et la après avoir tout téléchargé il se met à l’installation de man-db je pense mais ca affiche Segmentation fault et du coup il quitte l’installation. Je retape la commande et la il skippe l’installation de ce dernier et passe à autre chose (je me suis trompé ici: il n’installe pas libc6 mais un package dont la dépendence est libc6 version x, mais une libc6 version y plus récente est déjà installée… donc ca passe pas). il propose l’option -f mais ca aide à rien.
Je comprends pas trop comment ca se passe avec les kernels… D’après ta réponse il devrait y avoir moyen de switcher entre les kernels? Mais après avoir remplacé l’ancien par le compilé maison, comment faire? Je trouve cela un peu dommage, si pas bizarre, de devoir retourner sur l’autre kernel pour faire des updates alors que j’en ai compilé un.
Le noyau sur lequel on a booté pour faire une mise à jour du système ne devrait pas avoir beaucoup d’influence sur celle-ci. Ce qui compte ce sont les packages enregistrés dans la base de données de la distribution installées. Je pense que c’est plutôt à ce niveau que tu as un problème, et qu’il faudrait repartir d’une installation Raspbian neuve, puis la mettre à jour. Ensuite installer le nouveau noyau recompilé (en gardant le précédent sous la main).
Si on veut installer le nouveau kernel en respectant le système de packages debian, il faut utiliser l’utilitaire make-kpkg. J’en avais donné un aperçu dans cet article, mais c’était une installation native sur le PC, pas en environnement cross-compilé.
sorry I have a problem when compile and install xenomai
sudo make
Making all in src
make[1]: Entering directory `/home/pablo/XenoPi/xenomai-2.6.1/src’
Making all in include
make[2]: Entering directory `/home/pablo/XenoPi/xenomai-2.6.1/src/include’
make all-am
make[3]: Entering directory `/home/pablo/XenoPi/xenomai-2.6.1/src/include’
make[3]: Leaving directory `/home/pablo/XenoPi/xenomai-2.6.1/src/include’
make[2]: Leaving directory `/home/pablo/XenoPi/xenomai-2.6.1/src/include’
Making all in skins
make[2]: Entering directory `/home/pablo/XenoPi/xenomai-2.6.1/src/skins’
Making all in common
make[3]: Entering directory `/home/pablo/XenoPi/xenomai-2.6.1/src/skins/common’
/bin/bash ../../../libtool –tag=CC –mode=compile arm-linux-gcc -DHAVE_CONFIG_H -I. -I../../../src/include -O2 -D_GNU_SOURCE -D_REENTRANT -Wall -Werror-implicit-function-declaration -pipe -D__XENO__ -D__IN_XENO__ -Wstrict-prototypes -I../../../include -march=armv6 -MT libxenomai_la-assert_context.lo -MD -MP -MF .deps/libxenomai_la-assert_context.Tpo -c -o libxenomai_la-assert_context.lo `test -f ‘assert_context.c’ || echo ‘./’`assert_context.c
libtool: compile: arm-linux-gcc -DHAVE_CONFIG_H -I. -I../../../src/include -O2 -D_GNU_SOURCE -D_REENTRANT -Wall -Werror-implicit-function-declaration -pipe -D__XENO__ -D__IN_XENO__ -Wstrict-prototypes -I../../../include -march=armv6 -MT libxenomai_la-assert_context.lo -MD -MP -MF .deps/libxenomai_la-assert_context.Tpo -c assert_context.c -fPIC -DPIC -o .libs/libxenomai_la-assert_context.o
../../../libtool: line 1111: arm-linux-gcc: command not found
make[3]: *** [libxenomai_la-assert_context.lo] Error 1
make[3]: Leaving directory `/home/pablo/XenoPi/xenomai-2.6.1/src/skins/common’
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/pablo/XenoPi/xenomai-2.6.1/src/skins’
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/pablo/XenoPi/xenomai-2.6.1/src’
make: *** [all-recursive] Error 1
what is this error?
merci
The problem is « arm-linux-gcc: command not found« .
You need to have a cross-toolchain installed. I think it’s already done to compile your kernel.
Next, you need to modify your
PATHenvironment variable to include the directory containingarm-linux-gcc.So, don’t do:
but:
merci beaucoup vous aviez raison … J’avais besoin de ce
Bonjour Christophe,
J’ai réussi à démarrer (j’obtiens le « kernel panic ») mais j’ai du mettre le dernier firmware sur ma partition boot (bootcode.bin, start.elf, cmline.txt (fichier ne contenant qu’un espace)) en plus du kernel.img.
Est-ce normal, ou le RPI aurait pu démarrer sans installer ce bootloader?
hi y have a problen when i trytu ejecute
root@raspberrypi:~/usr/xenomai/bin# ls -al
total 684
drwxr-xr-x 3 root root 4096 Jan 15 00:11 .
drwxr-xr-x 5 root root 4096 Jan 15 00:20 ..
-rwxr-xr-x 1 root root 34302 Jan 15 00:09 arith
-rwxr-xr-x 1 root root 5602 Jan 15 00:09 check-vdso
-rwxr-xr-x 1 root root 16034 Jan 15 00:09 clocktest
-rwxr-xr-x 1 root root 9433 Jan 15 00:09 cmd_bits
-rwxr-xr-x 1 root root 15203 Jan 15 00:09 cmd_read
-rwxr-xr-x 1 root root 15126 Jan 15 00:09 cmd_write
-rwxr-xr-x 1 root root 35310 Jan 15 00:09 cond-torture-native
-rwxr-xr-x 1 root root 53505 Jan 15 00:09 cond-torture-posix
-rwxr-xr-x 1 root root 17405 Jan 15 00:09 cyclictest
-rwxr-xr-x 1 root root 2120 Jan 15 00:09 dohell
-rwxr-xr-x 1 root root 8703 Jan 15 00:09 insn_bits
-rwxr-xr-x 1 root root 14530 Jan 15 00:09 insn_read
-rwxr-xr-x 1 root root 10062 Jan 15 00:09 insn_write
-rwxr-xr-x 1 root root 9169 Jan 15 00:09 irqloop
-rwxr-xr-x 1 root root 31874 Jan 15 00:09 klatency
-rwxr-xr-x 1 root root 41313 Jan 15 00:09 latency
-rwxr-xr-x 1 root root 36148 Jan 15 00:09 mutex-torture-native
-rwxr-xr-x 1 root root 53611 Jan 15 00:09 mutex-torture-posix
drwxr-xr-x 5 root root 4096 Jan 15 00:09 regression
-rwxr-xr-x 1 root root 13172 Jan 15 00:09 rtcanrecv
-rwxr-xr-x 1 root root 13320 Jan 15 00:09 rtcansend
-rwxr-xr-x 1 root root 31520 Jan 15 00:09 rtdm
-rwxr-xr-x 1 root root 59234 Jan 15 00:09 switchtest
-rwxr-xr-x 1 root root 32044 Jan 15 00:09 wakeup-time
-rwxr-xr-x 1 root root 18791 Jan 15 00:09 wf_generate
-rwxr-xr-x 1 root root 3220 Jan 15 00:10 wrap-link.sh
-rwxr-xr-x 1 root root 389 Jan 15 00:10 xeno
-rwxr-xr-x 1 root root 4003 Jan 15 00:10 xeno-config
-rw-r–r– 1 root root 10240 Jan 15 00:11 xenomai.tar
-rwxr-xr-x 1 root root 1812 Jan 15 00:09 xeno-regression-test
-rwxr-xr-x 1 root root 1382 Jan 15 00:09 xeno-test
-rwxr-xr-x 1 root root 18256 Jan 15 00:09 xeno-test-run
-rwxr-xr-x 1 root root 181 Jan 15 00:09 xeno-test-run-wrapper
root@raspberrypi:~/usr/xenomai/bin# ./latency -p 100
bash: ./latency: No such file or directory
y don`t not why , can you help me plese?
thank
You probably have compiled Xenomai with a different toolchain than the system libraries.
Maybe you compiled your kernel and busybox with a crosstool-NG toolchain and Xenomai with a buildroot toolchain?
Bonjour Christophe,
Avec ces explications j’ai installé correctement Xenomai sur mon RPI. Le test de latence ./latency fonctionne, donc à priori ma cible est bonne.
Merci pour ce tutoriel !
C’est sur mon PC de développement que j’ai un souci pour cross-compiler un programme Xenomai.
J’essaye en fait de compiler exemple-hello-01.c page 211 de votre livre S.T.R.S.L.
Mon problème est que le compilateur ne trouve pas les .h
Voici mon Makefile :
XENOCONFIG=/home/petersmooth/XenoPi/xenomai-2.6.1/rpi/usr/xenomai/bin/xeno-config
CC= $(shell $(XENOCONFIG) –cc)
CFLAGS= $(shell $(XENOCONFIG) –skin=native –cflags)
LDFLAGS= $(shell $(XENOCONFIG) –ckin=native –ldflags)
LDFLAGS+=-lnative
LDLIBS=-lnative -lxenomai
all:: helloFromXenomai
clean::
rm -f helloFromXenomai *.o
Et Voici le début mon script xeno-config ou j’ai bien indiqué le chemin du cross-compilateur à la ligne XENO_CC:
#! /bin/sh
staging=${DESTDIR}
prefix= »/usr/xenomai »
exec_prefix= »${prefix} »
libdir= »${exec_prefix}/lib »
datarootdir= »${prefix}/share »
datadir= »${datarootdir} »
pkgdatadir= »${datadir}/xenomai »
includedir= »${prefix}/include »
XENO_VERSION= »2.6.1″
XENO_PREFIX= »${staging}${prefix} »
XENO_CC= »/usr/local/cross-rpi/usr/bin/arm-linux-gcc »
XENO_TARGET_ARCH= »arm »
XENO_BASE_CFLAGS= »-I${staging}${includedir} -D_GNU_SOURCE -D_REENTRANT -D__XENO__ »
XENO_BASE_LDFLAGS= »-L${staging}${libdir} -lxenomai -lpthread -lrt »
XENO_POSIX_LDFLAGS= »-L${staging}${libdir} -lpthread_rt -lxenomai -lpthread -lrt »
XENO_POSIX_WRAPPERS= »${staging}${libdir}/posix.wrappers »
XENO_POSIX_FAST_WRAPPING= »yes »
XENO_LIBRARY_DIR= »${staging}${libdir} »
XENO_INCLUDE_DIR= »${staging}${includedir} »
Pour compiler je me place dans le répertoire ou se trouve mon helloFromXenomai.c et mon Makefile.
Etant rooté je tape :
PATH=$PATH:/home/petersmooth/XenoPi/xenomai-2.6.1/rpi/usr/xenomai/bin
Suivit de :
export PATH
Et enfin, après avoir lancé le make, voici ce que j’obtiens :
root@Peter-Tosh-Lin:/home/petersmooth/MyDEV/C_ARM/04_HelloFromXenomai# make
Usage xeno-config –skin=skinname OPTIONS
Options :
–help
–v,–verbose
–version
–cc
–arch
–prefix
–skin native|posix|psos|rtdm|uitron|vrtx|vxworks
–cflags
–ldflags
–lib*-dir,–libdir,–user-libdir
Deprecated options:
–xeno-cflags
–xeno-ldflags
–posix-cflags
–posix-ldflags
/usr/local/cross-rpi/usr/bin/arm-linux-gcc -I/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT -D__XENO__ -lnative helloFromXenomai.c -lnative -lxenomai -o helloFromXenomai
helloFromXenomai.c:6:18: fatal error: rtdk.h: No such file or directory
compilation terminated.
make: *** [helloFromXenomai] Error 1
J’ai essayé pas mal de choses pour compiler cet exemple mais en vain. J’ai également essayé de compiler les exemples fournis lors de l’installation de Xenomai mais je n’y suis pas parvenu non plus. Est-ce que c’est possbile d’avoir un petit coup de pouce? 🙂
J’ai aussi ajouté le path de ma toolchaine avant la commande make comme suit :
PATH=$PATH:/usr/local/cross-rpi/usr/bin/
Mais ça ne résoud pas le problème.
Bonjour,
J’ai vu une faute de frappe dans le Makefile, sur la ligne du LDFLAGS, il y a un « ckin » au lieu de « skin », cela a-t-il une influence sur le résultat ?
Cordialement
Merci pour cette réponse rapide!
J’ai corrigé le Makefile mais ça n’a pas d’influence sur le résultat.
En outre j’avais une autre erreur dans le script xeno-config :
J’y ai remplacer :
prefix= « /usr/xenomai »
par :
prefix= »/home/petersmooth/XenoPi/xenomai-2.6.1″
Maintenant le compilateur cherche asm/xenomai/system.h :
root@Peter-Tosh-Lin:/home/petersmooth/MyDEV/C_ARM/04_HelloFromXenomai# PATH=$PATH:/usr/local/cross-rpi/usr/bin/
root@Peter-Tosh-Lin:/home/petersmooth/MyDEV/C_ARM/04_HelloFromXenomai# PATH=$PATH:/home/petersmooth/XenoPi/xenomai-2.6.1/rpi/usr/xenomai/bin
root@Peter-Tosh-Lin:/home/petersmooth/MyDEV/C_ARM/04_HelloFromXenomai# make
/usr/local/cross-rpi/usr/bin/arm-linux-gcc -I/home/petersmooth/XenoPi/xenomai-2.6.1/include -D_GNU_SOURCE -D_REENTRANT -D__XENO__ -lnative -L/home/petersmooth/XenoPi/xenomai-2.6.1/lib -lxenomai -lpthread -lrt -lnative helloFromXenomai.c -lnative -lxenomai -o helloFromXenomai
In file included from /home/petersmooth/XenoPi/xenomai-2.6.1/include/nucleus/thread.h:25:0,
from /home/petersmooth/XenoPi/xenomai-2.6.1/include/nucleus/sched.h:31,
from /home/petersmooth/XenoPi/xenomai-2.6.1/include/native/task.h:25,
from helloFromXenomai.c:7:
/home/petersmooth/XenoPi/xenomai-2.6.1/include/nucleus/types.h:36:32: fatal error: asm/xenomai/system.h: No such file or directory
compilation terminated.
make: *** [helloFromXenomai] Error 1
J’ai réinstallé Xenomai sur ma carte SD en incluant cette fois ci les repertoires include et share comme suit :
tar cf xenomai.tar usr/xenomai/bin/ usr/xenomai/lib/ usr/xenomai/sbin/ usr/xenomai/include usr/xenomai/share
Je vais maintenant chercher les includes dans ma carte SD, et non plus dans mon PC de développement; Voici le début de mon script xeno-config :
#! /bin/sh
staging=${DESTDIR}
prefix= »/media/Xenoroot/usr/xenomai »
exec_prefix= »${prefix} »
libdir= »${exec_prefix}/lib »
datarootdir= »${prefix}/share »
datadir= »${datarootdir} »
pkgdatadir= »${datadir}/xenomai »
includedir= »${prefix}/include »
XENO_VERSION= »2.6.1″
XENO_PREFIX= »${staging}${prefix} »
XENO_CC= »/usr/local/cross-rpi/usr/bin/arm-linux-gcc »
XENO_TARGET_ARCH= »arm »
XENO_BASE_CFLAGS= »-I${staging}${includedir} -D_GNU_SOURCE -D_REENTRANT -D__XENO__ »
XENO_BASE_LDFLAGS= »-L${staging}${libdir} -lxenomai -lpthread -lrt »
XENO_POSIX_LDFLAGS= »-L${staging}${libdir} -lpthread_rt -lxenomai -lpthread -lrt »
XENO_POSIX_WRAPPERS= »${staging}${libdir}/posix.wrappers »
XENO_POSIX_FAST_WRAPPING= »yes »
XENO_LIBRARY_DIR= »${staging}${libdir} »
XENO_INCLUDE_DIR= »${staging}${includedir} »
Finalement j’obtiens le message « Could not find current ARM architecture » après make:
root@Peter-Tosh-Lin:/home/petersmooth/MyDEV/C_ARM/04_HelloFromXenomai# make
/usr/local/cross-rpi/usr/bin/arm-linux-gcc -I/media/Xenoroot/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT -D__XENO__ -lnative -L/media/Xenoroot/usr/xenomai/lib -lxenomai -lpthread -lrt -lnative helloFromXenomai.c -lnative -lxenomai -o helloFromXenomai
In file included from /media/Xenoroot/usr/xenomai/include/asm/xenomai/atomic.h:26:0,
from /media/Xenoroot/usr/xenomai/include/nucleus/system.h:26,
from /media/Xenoroot/usr/xenomai/include/asm/xenomai/system.h:247,
from /media/Xenoroot/usr/xenomai/include/nucleus/types.h:36,
from /media/Xenoroot/usr/xenomai/include/nucleus/thread.h:25,
from /media/Xenoroot/usr/xenomai/include/nucleus/sched.h:31,
from /media/Xenoroot/usr/xenomai/include/native/task.h:25,
from helloFromXenomai.c:7:
/media/Xenoroot/usr/xenomai/include/asm/xenomai/features.h:73:2: error: #error « Could not find current ARM architecture »
make: *** [helloFromXenomai] Error 1
Est-ce que vous savez à quoi correspond cette erreur?
Xenomai ne supportait pas jusqu’à présent l’architecture ARMv6zk du RaspberryPI.
D’où l’erreur « Could not find current ARM architecture ».
Gilles Chanteperdrix vient de faire un commit pour que le fichier /include/asm/xenomai/features.h puisse supporter cette architecture, ce qui m’a permit de compiler après avoir réinstaller Xenomai sur ma carte SD.
Merci encore pour l’aide,
Pierre
Bonjour,
est-il possible d’accéder aux GPIO sous Xenomai? J’avoue que je suis intéressé par des applications de contrôle moteur…
Bonjour, on peut effectivement utiliser les GPIO avec Xenomai, je posterai des exemples très prochainement. Il subsiste encore un problème pour les interruptions des GPIO du Raspberry Pi. J’arrive à les traiter, mais avec des latences anormales. Je vais essayer de creuser le problème cette semaine.
Génial, je reste connecté!
Je commence d’avoir une idée sur Linux comme système d’exploitation et je l’ai patché avec XENOMAI en suivant les instruction sur le net, alors que j’ai besoin d’apprendre plus sur XENOMAI pour mon stage, l’Anglais c mon problème, le pays où je suis c’est 1 pays Tiers-Monde pour acheter un livre ou recevoir les moyens sont inexistants donc je base toujours sur le net (free), si vous avez un livre sur Xenomai (doc) pouvez vous le partager avec moi?
Hi,
i cant speak french (of course) so there is an question about GPIO ?
Can you english your answer please ?
is there an possibilitie (through Arduino , or teensy for instance) to get the steps and direction endstops and so on through that interface ?
I would be willing to do the hardware for it like an shield
so any hint (in english) is welcome
thx
thomas
With Xenomai, you can access GPIO just like classic Linux kernel modules. The API is in, for instance:
So it’s easy to set the direction of a GPIO (as from the user space with /sys/class/gpio/ interface).
Hi,
has anyone a solution for:
heavy ethernet load , lead to hight jitter?
If there is a high load on ethernet communication, the jitter increase,
we see every. I would say 10s a peak of almost 8ms-10ms or even more,
nomally the jitter for the cyclic task is 40us-60s in worst case and preatty stable, but with high ethernet
load unaceptable peaks occure.
Is this caused by the usb connection of the smcxxx network implementation?
thx
Rasti
Salut,
J’ai suivi votre tutorial et je l’ai appliqué et quand je voudrais connecter avec ssh sur mon raspberry pi , je ne peux pas , quand je branche le cable ethernet les leds ne s’allument pas
vraiment j’ai besoin d’aide , car je suis entrain de faire mon pfe d’ingénieur
Il doit probablement manquer, dans la configuration du kernel, le driver pour le contrôleur Ethernet :
Device drivers->Network device support->USB Network Adapters->Multi-purpose USB Networking Framework->SMSC LAN95XX based...À inclure de préférence statiquement dans le noyau plutôt qu’en module.
Bonjour,
J’ai suivi ce tutoriel et cela marche parfaitement bien, merci!
Cependant, j’ai désormais besoin d’avoir le skin vxWorks pour Xenomai, et IMPOSSIBLE de réussir à compiler le module xeno_vxworks.ko… Quelqu’un aurait une idée?
Merci d’avance!
Bonjour,
Existe t’il, a l’heur actuelle, un patch xenomai pour raspberry pi 2?
Merci.
Bonjour..
J’ai dans un premier temps tenté xenomai « stable » 3.0.1 sur mon laptop, et celui-ci a été un franc succès. maintenant, n’étant pas des plus fonctionnels sur ce gere de hardware j’aurai souhaité tenter sur mon RPi2.
Depuis hier, que ce soit en compil locale ou en cross-compile je ne cesse de planter à ce stade de la manipulation, peu importe la source d’informations que je suit : « recipe for target ‘vmlinux’ failed »
Sur un autre site ils passaient par un make zImage etc etc mais pareillement, voir pire! tout se déroulait sans output d’erreurs, lib et autres fichiers vitaux étaient ok excepté pour le kernel.
Any ideas ?
Je n’ai pas vérifié récemment, mais il y a quelques mois Xenomai ne fonctionnait pas encore sur Raspberry Pi 2.
Bonjour,
Je viens de suivre le tuto (pour la troisième fois aujourd’hui), et je me trouve confronté à un problème, la compilation se passe bien, mais au moment du boot, sur mon écran, ne s’affiche qu’un gros carré avec de jolies couleurs qui restent figé.
Savez-vous pourquoi et si oui quoi faire pour y remédier ?
Cordialement
Bonjour,
Sur quelle version de Raspberry Pi avez-vous fait votre essai ? Xenomai ne fonctionne pas encore (du moins pas complètement) sur Raspberry Pi 2.
Le problème (carré coloré) semble indiquer que le bootloader ne peut pas charger le noyau. Il peut y avoir un problème de version du bootloader par exemple.
alors pour ce premier test j’ai travaillé avec un Raspberry Pi model B (ni B+ ni 2).
Comment savoir la version du bootloader ?
Depuis 2012, la compilation de Linux et Xenomai sur Raspberry Pi ont pas mal évolué. Aujourd’hui, je préconise plutôt d’agir comme suit.
Vérifier s’il n’y a pas d’options conflictuelles dans le menu
Realtime sub-systemCopier le noyau
arch/arm/boot/zImagesur la carte SD.En supposant que
/media/$USER/Rootest le chemin d’accès à la partition Root de la carte SD.Merci pour la réponse, mais il y a un problème au milieu de la compilation du kernel,
drivers/scsi/osd/osd_initiator.c: In function ‘build_test’:
drivers/scsi/osd/osd_initiator.c:68:2: error: size of unnamed array is negative
BUILD_BUG_ON(sizeof(struct osdv2_cdb) != OSD_TOTAL_CDB_LEN);
^
drivers/scsi/osd/osd_initiator.c:69:2: error: size of unnamed array is negative
BUILD_BUG_ON(sizeof(struct osdv1_cdb) != OSDv1_TOTAL_CDB_LEN);
Désole, il manque en effet un
juste avant le
Certaines options inappropriées étaient peut-être sélectionnées.
Bonjour
Merci pour tes reponses, mais encore une fois je me trouve face à un probleme, lorsque je rentre les commandes suivantes, la compilation echoue.
Voila toutes les commandes que j’ai saisies.
Je ne pensais pas qu’il serait si compliqué d’avoir un système RT ^^
wget http://xenomai.org/downloads/xenomai/stable/xenomai-2.6.4.tar.bz2
tar -xjf xenomai-2.6.4.tar.bz2
git clone http://github.com/raspberrypi/linux linux-rpi
cd linux-rpi
git checkout rpi-3.8.y
patch -p1 < ../xenomai-2.6.4/ksrc/arch/arm/patches/raspberry/ipipe-core-3.8.13-raspberry-pre-2.patch
patch -p1 < ../xenomai-2.6.4/ksrc/arch/arm/patches/ipipe-core-3.8.13-arm-4.patch
patch -p1 < ../xenomai-2.6.4/ksrc/arch/arm/patches/raspberry/ipipe-core-3.8.13-raspberry-post-2.patch
../xenomai-2.6.4/scripts/prepare-kernel.sh –arch=arm –linux=.
make ARCH=arm bcmrpi_defconfig
make ARCH=arm menuconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
kernel/ipipe/core.c: In function ‘ipipe_probe_kernel_read’:
kernel/ipipe/core.c:1748:2: erreur: implicit declaration of function ‘get_fs’ [-Werror=implicit-function-declaration]
kernel/ipipe/core.c:1750:2: erreur: implicit declaration of function ‘set_fs’ [-Werror=implicit-function-declaration]
kernel/ipipe/core.c:1750:9: erreur: ‘KERNEL_DS’ undeclared (first use in this function)
kernel/ipipe/core.c:1750:9: note: each undeclared identifier is reported only once for each function it appears in
kernel/ipipe/core.c:1753:2: erreur: implicit declaration of function ‘__copy_from_user_inatomic’ [-Werror=implicit-function-declaration]
kernel/ipipe/core.c: In function ‘ipipe_probe_kernel_write’:
kernel/ipipe/core.c:1767:9: erreur: ‘KERNEL_DS’ undeclared (first use in this function)
kernel/ipipe/core.c:1770:2: erreur: implicit declaration of function ‘__copy_to_user_inatomic’ [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[2]: *** [kernel/ipipe/core.o] Erreur 1
make[1]: *** [kernel/ipipe] Erreur 2
make: *** [kernel] Erreur 2
Ah oui, je suis déjà tombé sur ce problème. Pour le résoudre, dans le
make ARCH=arm menuconfig, il faut désactiver les deux options suivantes :Kernel Features« : l’option «Enable -fstack-protector buffer overflow detection» (peut-être pas de rapport mais c’est conseillé)Kernel Hacking« : l’option «KGDB: kernel debugger --->«Merci encore pour tes réponses,.
La compilation se passe à merveille (si je puis dire), mais comme toujours un problème en cachant un autre c’est au boot que je plante.
voila les dernière lignes de logs :
Welcome to Raspbian GNNU/Linux 8 (jessie)!
[ ] systemd[1]: Failed to insert module ‘ipv6’
[ ] systemd[1]: Set hostname to
[ ] Indeed it is in host mode hprt0 = 00021501
[ ] usb 1-1: new high-speed USB device number 2 using dwc_otg
[ ] Indeed it is in host mode hprt0 = 00001101
_
Bonjour,
J’ai une carte SD qui tourne bien avec Xenomai sur un Raspberry B+. Je pense qu’elle a été créée à l’origine en suivant plus ou moins ce tutorial. (Pas par moi, qui ne m’y connais pas vraiment, comme vous l’avez sans doute compris).
Lorsque je tente de réutiliser cette même carte SD dans un autre RPI B+ acheté récemment, cela ne boote pas! Les 2 RPI sont « théoriquement » identiques (même bon de commande, même version 1.2 indiqué sur la carte etc.). J’ai testé le RPI « défectueux » en installant Rasbian sur la même carte SD, et cela fonctionne parfaitement. Donc je suppose que d’un point de vue du matériel (RPI et carte SD), tout va bien.
En observant attentivement les deux RPI B+, j’ai observé une très légère différence : La carte RAM de l’ancien (qui marche) est une Samsung, celle du nouveau est une Elpida.
Auriez-vous une suggestion pour résoudre ce problème svp?
Note: en faisant quelques recherches, il semble que les RAM Samsung ont été remplacées sur les RPI B+ par des RAM Elvida vers mi-2016.
Merci beaucoup
Bonjour
je suis bloqué dans cette étape:
sudo make ARCH=arm INSTALL_MOD_PATH=/media/Root modules_install
voila ce qui est affiché :
…Warning: you may need to install module-init-tools
See http://www.codemonkey.org.uk/docs/post-halloween-2.6.txt
depmod: ERROR: failed to load symbols from /media/segec/c7c29467-dda8-4262-b934-893cb45d9bd6/lib/modules/3.2.21-xenomai+/kernel/net/ipv6/xfrm6_mode_transport.ko: Invalid argument
depmod: ERROR: failed to load symbols from /media/segec/c7c29467-dda8-4262-b934-893cb45d9bd6/lib/modules/3.2.21-xenomai+/kernel/net/ipv6/xfrm6_mode_tunnel.ko: Invalid argument
depmod: ERROR: failed to load symbols from /media/segec/c7c29467-dda8-4262-b934-893cb45d9bd6/lib/modules/3.2.21-xenomai+/kernel/net/ipv6/xfrm6_mode_beet.ko: Invalid argument
depmod: ../libkmod/libkmod-elf.c:207: elf_get_mem: Assertion `offset size’ failed.
/home/segec/buildroot/XenoPi/linux-rpi/scripts/depmod.sh : ligne 43 : 5986 Abandon (core dumped) « $DEPMOD » « $@ » « $KERNELRELEASE »
make: *** [_modinst_post] Erreur 134
lorsque je monte mon carte sd sur raspberry pi2 et je fait cette commande uname -a
# uname -a
Linux buildroot 4.1.5-v7 …
y’a-t-il quelqu’un qui a une réponse pour mes questions?
bonjour
je suis a ce niveau ,quelle etape je dois suivre :
segec@ubuntu:~/buildroot/XenoPi/linux-rpi$ make ARCH=arm CROSS_COMPILE=~/buildroot/output/host/usr/bin/arm-linux-
scripts/kconfig/conf –silentoldconfig Kconfig
*
* Restart config…
*
*
* Linux/arm 3.2.21 Kernel Configuration
*
Patch physical to virtual translations at runtime (ARM_PATCH_PHYS_VIRT) [Y/n/?] (NEW) y
*
* System Type
*
MMU-based Paged Memory Management Support (MMU) [Y/n/?] y
ARM system type
1. ARM Ltd. Integrator family (ARCH_INTEGRATOR) (NEW)
2. ARM Ltd. RealView family (ARCH_REALVIEW) (NEW)
> 3. ARM Ltd. Versatile family (ARCH_VERSATILE) (NEW)
4. ARM Ltd. Versatile Express family (ARCH_VEXPRESS) (NEW)
5. Atmel AT91 (ARCH_AT91) (NEW)
6. Broadcom BCMRING (ARCH_BCMRING) (NEW)
7. Calxeda Highbank-based (ARCH_HIGHBANK) (NEW)
8. Cirrus Logic CLPS711x/EP721x-based (ARCH_CLPS711X) (NEW)
9. Cavium Networks CNS3XXX family (ARCH_CNS3XXX) (NEW)
10. Cortina Systems Gemini (ARCH_GEMINI) (NEW)
11. CSR SiRFSoC PRIMA2 ARM Cortex A9 Platform (ARCH_PRIMA2) (NEW)
12. EBSA-110 (ARCH_EBSA110) (NEW)
13. EP93xx-based (ARCH_EP93XX) (NEW)
14. FootBridge (ARCH_FOOTBRIDGE) (NEW)
15. Freescale MXC/iMX-based (ARCH_MXC) (NEW)
16. Freescale MXS-based (ARCH_MXS) (NEW)
17. Hilscher NetX based (ARCH_NETX) (NEW)
18. Hynix HMS720x-based (ARCH_H720X) (NEW)
19. IOP13xx-based (ARCH_IOP13XX) (NEW)
20. IOP32x-based (ARCH_IOP32X) (NEW)
21. IOP33x-based (ARCH_IOP33X) (NEW)
22. IXP23XX-based (ARCH_IXP23XX) (NEW)
23. IXP2400/2800-based (ARCH_IXP2000) (NEW)
24. IXP4xx-based (ARCH_IXP4XX) (NEW)
25. Marvell Dove (ARCH_DOVE) (NEW)
26. Marvell Kirkwood (ARCH_KIRKWOOD) (NEW)
27. NXP LPC32XX (ARCH_LPC32XX) (NEW)
28. Marvell MV78xx0 (ARCH_MV78XX0) (NEW)
29. Marvell Orion (ARCH_ORION5X) (NEW)
30. Marvell PXA168/910/MMP2 (ARCH_MMP) (NEW)
31. Micrel/Kendin KS8695 (ARCH_KS8695) (NEW)
32. Nuvoton W90X900 CPU (ARCH_W90X900) (NEW)
33. NVIDIA Tegra (ARCH_TEGRA) (NEW)
34. Picochip picoXcell (ARCH_PICOXCELL) (NEW)
35. Philips Nexperia PNX4008 Mobile (ARCH_PNX4008) (NEW)
36. PXA2xx/PXA3xx-based (ARCH_PXA) (NEW)
37. Qualcomm MSM (ARCH_MSM) (NEW)
38. Renesas SH-Mobile / R-Mobile (ARCH_SHMOBILE) (NEW)
39. RiscPC (ARCH_RPC) (NEW)
40. SA1100-based (ARCH_SA1100) (NEW)
41. Samsung S3C2410, S3C2412, S3C2413, S3C2416, S3C2440, S3C2442, S3C2443, S3C2450 (ARCH_S3C2410) (NEW)
42. Samsung S3C64XX (ARCH_S3C64XX) (NEW)
43. Samsung S5P6440 S5P6450 (ARCH_S5P64X0) (NEW)
44. Samsung S5PC100 (ARCH_S5PC100) (NEW)
45. Samsung S5PV210/S5PC110 (ARCH_S5PV210) (NEW)
46. SAMSUNG EXYNOS (ARCH_EXYNOS) (NEW)
47. Shark (ARCH_SHARK) (NEW)
48. Telechips TCC ARM926-based systems (ARCH_TCC_926) (NEW)
49. ST-Ericsson U300 Series (ARCH_U300) (NEW)
50. ST-Ericsson U8500 Series (ARCH_U8500) (NEW)
51. STMicroelectronics Nomadik (ARCH_NOMADIK) (NEW)
52. TI DaVinci (ARCH_DAVINCI) (NEW)
53. TI OMAP (ARCH_OMAP) (NEW)
54. ST SPEAr (PLAT_SPEAR) (NEW)
55. Broadcom BCM2708 family (ARCH_BCM2708) (NEW)
56. VIA/WonderMedia 85xx (ARCH_VT8500) (NEW)
57. Xilinx Zynq ARM Cortex A9 Platform (ARCH_ZYNQ) (NEW)
choice[1-57]:
Je suis arrivé a ce niveau pour le patch de Xenomai sur raspberry:
lorsque je monte mon carte sd sur raspberry et je l’activé.le systeme est bien en marche .mais lorsque je saisi ce commnde:
buildroot login: root
Password:
# uname -a
Linux buildroot 4.1.
mon question est ce que je dois supprimer zImage crée par buildroot et remplacé par Zimage crée apres patch car dans le tutoriol je ne comprends pas pourquoi il a copier sous le nom de Kernel .img et laisse le zImage ancienne? deux image c’est impossible.
Aidez moi ou mois par une conseill acr dans le totriel aucun ne repond moi.
Bonjour,
Est ce qu’on pourrait suivre les mêmes étapes pour RPI Zero ?