Xenomai sur Raspberry Pi

Publié par cpb
Août 27 2012

Xenomai sur Raspberry-PiDepuis 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 http://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 http://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.

58 Réponses

  1. sinseman44 dit :

    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 ?

    • cpb dit :

      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.

  2. RENNER Ugo dit :

    Bonjour,

    Merci beaucoup pour ce billet. J’ai pas réussi à trouver comment créer la toolchain, pourrais-tu me renseigner ?

    Merci !

  3. JeD dit :

    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

  4. Ugo RENNER dit :

    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 !

    • Tele Laci dit :

      ——————————-
      >>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.

      • cpb dit :

        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 ?

        • Tele Laci dit :

          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

      • Ugo RENNER dit :

        Thank you very much for your help, I will try this =)

  5. Pierrot dit :

    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

  6. guillaume dit :

    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?

  7. cpb dit :

    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.

    • guillaume dit :

      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.

      • cpb dit :

        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é.

  8. pablo dit :

    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

    • cpb dit :

      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 PATH environment variable to include the directory containing arm-linux-gcc.

      So, don’t do:

      $ sudo make

      but:

      $ sudo -i
      # PATH=$PATH:/usr/local/cross-rpi/usr/bin/   (with the path to your toolchain)
      # make
  9. pablo dit :

    merci beaucoup vous aviez raison … J’avais besoin de ce

  10. Pierrot dit :

    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?

  11. linuxesdios dit :

    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

    • cpb dit :

      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?

  12. Pierrot dit :

    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? 🙂

    • Pierrot dit :

      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.

      • cpb dit :

        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

        • Pierrot dit :

          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

          • Pierrot dit :

            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?

  13. Pierrot dit :

    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

  14. Antoine dit :

    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…

    • cpb dit :

      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.

  15. Ramzy dit :

    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?

  16. Thomas dit :

    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

    • cpb dit :

      With Xenomai, you can access GPIO just like classic Linux kernel modules. The API is in , for instance:

      // Register access
      int  gpio_request (unsigned int gpio, const char * ident); 
      void gpio_free    (unsigned int gpio); 
      
      //  Export to /sys.
      int  gpio_export   (unsigned int gpio); 
      int  gpio_unexport (unsigned int gpio); 
      
      // Direction
      int  gpio_direction_input  (unsigned int gpio); 
      int  gpio_direction_output (unsigned int gpio); 
      
      // Read/Write
      int  gpio_get_value (unsigned int gpio); 
      int  gpio_set_value (unsigned int gpio, int value); 
      
      // IRQ number for the GPIO
      int  gpio_to_irq (unsigned int gpio);  
      int  irq_to_gpio (unsigned int irq);

      So it’s easy to set the direction of a GPIO (as from the user space with /sys/class/gpio/ interface).

  17. Rasti dit :

    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

  18. sabri dit :

    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

    • cpb dit :

      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.

  19. yrakcaz dit :

    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!

  20. Quiroz dit :

    Bonjour,
    Existe t’il, a l’heur actuelle, un patch xenomai pour raspberry pi 2?
    Merci.

  21. F_Laurent dit :

    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 ?

  22. ox223252 dit :

    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

    • cpb dit :

      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.

      • ox223252 dit :

        alors pour ce premier test j’ai travaillé avec un Raspberry Pi model B (ni B+ ni 2).
        Comment savoir la version du bootloader ?

        • cpb dit :

          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.

          $ 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-3.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  menuconfig

          Vérifier s’il n’y a pas d’options conflictuelles dans le menu Realtime sub-system

          $ make  ARCH=arm  CROSS_COMPILE=arm-linux-

          Copier le noyau arch/arm/boot/zImage sur la carte SD.

          $ cd  ../xenomai-2.6.4
          $ ./configure  --host=arm-linux  CFLAGS='-march=armv6'  LDFLAGS='-march=armv6'
          $ make
          $ make  DESTDIR=$(pwd)/target  install
          $ cp  -a  target/*  /media/$USER/Root

          En supposant que /media/$USER/Root est le chemin d’accès à la partition Root de la carte SD.

          • ox223252 dit :

            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);

          • cpb dit :

            Désole, il manque en effet un

            $ make ARCH=arm bcmrpi_defconfig

            juste avant le

            $ make ARCH=arm menuconfig

            Certaines options inappropriées étaient peut-être sélectionnées.

  23. ox223252 dit :

    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

    • cpb dit :

      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 :

      • Menu « Kernel Features« : l’option « Enable -fstack-protector buffer overflow detection » (peut-être pas de rapport mais c’est conseillé)
      • Menu « Kernel Hacking« : l’option « KGDB: kernel debugger --->« 
  24. ox223252 dit :

    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
    _

  25. Pierre dit :

    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

  26. hsan dit :

    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

  27. hsan dit :

    y’a-t-il quelqu’un qui a une réponse pour mes questions?

  28. hsan dit :

    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]:

  29. hsan dit :

    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.

URL de trackback pour cette page