Xenomai 3 sur Raspberry Pi 2

Publié par cpb
Mai 22 2016

Xenomai 3 on Raspberry Pi 2Depuis plusieurs années l’installation de Xenomai sur un Raspberry Pi 1 se fait assez facilement, et les résultats en sont plutôt satisfaisants. Malheureusement l’installation sur un Raspberry Pi 2 ne fonctionnait pas. Le problème a été résolu depuis quelques mois par un patch de Mathieu Rondonneau qui permet d’utiliser la toute dernière version de Xenomai (3.0.2).

Xenomai 3 propose deux modèles de fonctionnement :

  • Dans le mode Mercury, les bibliothèques de Xenomai permettent de faire fonctionner du code applicatif (utilisant éventuellement l’API d’un autre système comme VxWorks ou pSOS) sur un noyau Linux standard, de préférence une version PREEMPT_RT.
  • Dans le mode Cobalt, le système Adeos (ipipe) capture les interruptions avant le noyau Linux et est donc capable d’activer des tâches Xenomai dans un temps plus prévisible. L’intégration est un peu plus complexe puisqu’elle nécessite de modifier le code du noyau Linux.

C’est ce dernier mode (Cobalt) que nous allons installer.

Préparation

Commençons par télécharger et décompresser l’archive de Xenomai. Je prends la dernière version disponible :

$ wget  http://xenomai.org/downloads/xenomai/stable/xenomai-3.0.2.tar.bz2
 [...]
$ tar  xjf  xenomai-3.0.2.tar.bz2

Voyons pour quelles versions du kernel le patch ipipe est disponible :

$ ls  xenomai-3.0.2/kernel/cobalt/arch/arm/patches/
ipipe-core-3.10.32-arm-13.patch  ipipe-core-3.18.20-arm-9.patch  README
ipipe-core-3.14.44-arm-16.patch  ipipe-core-4.1.18-arm-4.patch

Le choix le plus adapté sera un noyau 4.1. Téléchargeons le noyau Linux, plus particulièrement sa version spécifique pour Raspberry Pi :

$ git  clone https://github.com/raspberrypi/linux
Clonage dans 'linux'...
remote: Counting objects: 4883927, done.
remote: Compressing objects: 100% (26/26), done.
remote: Total 4883927 (delta 20), reused 12 (delta 12), pack-reused 4883889
Réception d'objets: 100% (4883927/4883927), 1.40 GiB | 1.63 MiB/s, done.
Résolution des deltas: 100% (4041858/4041858), done.
Vérification de la connectivité... fait.
Checking out files: 100% (52713/52713), done.

Nous extrayons la branche 4.1 et vérifions le numéro complet :

$ cd  linux/
$ git  checkout  rpi-4.1.y
Checking out files: 100% (22027/22027), done.
La branche rpi-4.1.y est paramétrée pour suivre la branche distante rpi-4.1.y depuis origin.
Basculement sur la nouvelle branche 'rpi-4.1.y'
$ head  -3  Makefile 
VERSION = 4
PATCHLEVEL = 1
SUBLEVEL = 21

Le noyau de la branche 4.1 pour Raspberry Pi est un 4.1.21. Le patch ipipe est prévu pour un noyau 4.1.18. Nous pourrions remonter l’historique git pour trouver une version 4.1.18 exacte. Néanmoins, je préfère éviter car nous aurons besoin d’appliquer un second patch, qui a été très probablement produit sur un noyau 4.1.21, et qui entre en conflit avec l’arborescence arch/arm/mach-bcm du 4.1.18.

Préparons une branche de travail afin d’isoler les modifications de Xenomai des sources d’origine :

$ git  checkout  -b  xenomai-3.0.2
Basculement sur la nouvelle branche 'xenomai-3.0.2'

Et vérifions si le patch ipipe s’applique bien :

$ patch  --dry-run  -p1  <  ../xenomai-3.0.2/kernel/cobalt/arch/arm/patches/ipipe-core-4.1.18-arm-4.patch
checking file arch/arm/Kconfig
Hunk #3 succeeded at 533 (offset 36 lines).
Hunk #4 succeeded at 720 (offset 36 lines).
[...]
checking file mm/mmu_context.c
checking file mm/mprotect.c
checking file mm/vmalloc.c

Nous voyons les messages Hunk succeeded indiquant que le patch a dû être décalé pour être appliqué correctement, mais aucune erreur ne se produit. L’argument --dry-run de l’exécution ci-dessus permettait de vérifier si le patch s’appliquait correctement sans faire de modifications.

Pour appliquer véritablement le patch ipipe, un script est livré qui permet en outre d’installer le domaine Xenomai proprement dit dans le noyau Linux. Utilisons-le :

$ cd  ..
$ xenomai-3.0.2/scripts/prepare-kernel.sh  --linux=linux/  --arch=arm  --ipipe=xenomai-3.0.2/kernel/cobalt/arch/arm/patches/ipipe-core-4.1.18-arm-4.patch

Enregistrons les modifications apportées :

$ cd  linux/
$ git  add  '*'
$ git  commit  -a  -m  "ipipe-core-4.1.18 patch"

Appliquons maintenant le patch de Mathieu Rondonneau que vous pouvez télécharger ici : patch-xenomai-3-on-bcm-2709.patch

$ cd  ..
$ wget  https://www.blaess.fr/christophe/files/article-2016-05-22/patch-xenomai-3-on-bcm-2709.patch
$ cd  linux/
$ patch  -p1  <  ../patch-xenomai-3-on-bcm-2709.patch  --dry-run
checking file arch/arm/Kconfig
checking file arch/arm/mach-bcm2709/armctrl.c
checking file arch/arm/mach-bcm2709/bcm2708_gpio.c
checking file arch/arm/mach-bcm2709/bcm2709.c
checking file arch/arm/mach-bcm2709/include/mach/entry-macro.S

Le patch passe bien sur cette version, appliquons-le en retirant l’argument --dry-run :

$ patch  -p1  <  ../patch-xenomai-3-on-bcm-2709.patch
patching file arch/arm/Kconfig
patching file arch/arm/mach-bcm2709/armctrl.c
patching file arch/arm/mach-bcm2709/bcm2708_gpio.c
patching file arch/arm/mach-bcm2709/bcm2709.c
patching file arch/arm/mach-bcm2709/include/mach/entry-macro.S
$ git  commit  -a  -m  "xenomai-3-on-bcm2709 patch"

Compilations

Kernel Linux et Xenomai

Nous pouvons configurer et compiler ce noyau :

$ make  ARCH=arm  bcm2709_defconfig
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
#
# configuration written to .config
#
$ make  ARCH=arm  menuconfig

Deux messages “WARNING” nous indiquent que certains éléments de la configuration actuelle entrent en conflit avec Xenomai. Nous désactivons les entrées suivantes :

CPU Power Management  --->
    CPU Frequency scaling  --->
        [ ] CPU Frequency scaling

et

Kernel Features  --->
    [ ] Contiguous Memory Allocator

puis

Kernel Features  --->
    [ ] Allow for memory compaction

et enfin

Kernel Hacking  --->
    [ ] KGDB: kernel debugger --->

Une dernière modification est nécessaire ; elle n’a rien de spécifique à Xenomai. Cela nous assure que le noyau disposera des bons arguments sur sa ligne de commande.
Dans le menu

Boot options  --->

passer l’option

    Kernel command line type (Use bootloader kernel arguments if available)  --->

à la valeur

        (X) Extend bootloader kernel arguments

Nous pouvons lancer la compilation avec un :

$ make  ARCH=arm  CROSS_COMPILE=arm-linux-

Bien entendu cela suppose que nous ayons configuré dans notre variable PATH l’accès à une toolchain de cross-compilation, par exemple générée avec Buildroot comme nous l’avions fait dans l’article “Création d’un système complet avec Buildroot 2015.11“.

Au bout de quelques minutes notre noyau est prêt. Je vais l’installer sur une carte micro-SD possédant deux partitions : BOOT (formatée en vfat) et ROOT (formatée en ext2). La partition BOOT comprend déjà le bootloader du Raspberry Pi obtenu lors de la compilation avec Buildroot 2016.02 (de manière identique à l’article indiqué ci-dessus).

$ cp  arch/arm/boot/zImage  /media/$USER/BOOT/
$ cp  arch/arm/boot/dts/bcm2709-rpi-2-b.dtb  /media/$USER/BOOT/

Xenomai en espace utilisateur

Nous allons maintenant compiler les bibliothèques de Xenomai, qui permettent de faire fonctionner le code dans l’espace utilisateur.

$ cd ../xenomai-3.0.2/
$ ./scripts/bootstrap 
  [...]
$ ./configure  --host=arm-linux  --enable-smp
  [...]
$ make
  [...]

Les bibliothèques et les utilitaires ainsi compilés vont être installés sur la partition ROOT, qui contient un système de fichiers minimal avec Busybox et quelques scripts générés par Buildroot, comme dans l’article mentionné ci-dessus.

L’accès à cette partition ROOT nécessitant les droits d’administrateur, je prépare d’abord une copie de l’ensemble des fichiers à installer que je transfère ensuite avec le préfixe sudo.

$ make  DESTDIR=$(pwd)/target  install
  [...]
$ sudo  cp  -a  target/*  /media/$USER/ROOT/
$ umount  /media/$USER/*

Tests

Le moment de vérité est arrivé, on insère la carte micro-SD, on branche une console sur le port série, et on démarre un émulateur de terminal comme Minicom. Voici le résultat :

Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0xf00
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 4.1.21-logilin+ (cpb@Logilin) (gcc version 4.9.3 (Buildroot 2016.02) ) #2 SMP Sun May 22 08:40:39 CEST 2016
[    0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine: BCM2709
[    0.000000] Memory policy: Data cache writealloc
  [...]
[    0.000000] I-pipe, 19.200 MHz clocksource, wrap in 960767920505705 ms
[    0.000000] clocksource ipipe_tsc: mask: 0xffffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns
[    0.000000] clocksource arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns
[    0.000000] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns
[    0.000001] Switching to timer-based delay loop, resolution 52ns
[    0.000917] Interrupt pipeline (release #4)

  [...]
[    0.948130] [Xenomai] scheduling class idle registered.
[    0.953408] [Xenomai] scheduling class rt registered.
[    0.958732] I-pipe: head domain Xenomai registered.
[    0.967286] [Xenomai] Cobalt v3.0.2 (Exact Zero) 
  [...]
Welcome to Buildroot
buildroot login:

Un oeil averti verra passer dans les traces du noyau quelques messages liés à Xenomai ou ipipe. Connectons-nous et examinons le système :

buildroot login: root
Password: 
# uname -a
Linux buildroot 4.1.21-logilin+ #2 SMP Sun May 22 08:40:39 CEST 2016 armv7l GNU/Linux
# cat /proc/xenomai/version
3.0.2
# cat /proc/ipipe/version
4

Notre système fonctionne bien avec Xenomai et ipipe. Le plus simple pour s’assure de son bon fonctionnement est d’utiliser l’un des outils de test livrés dans /usr/xenomai/bin.

# /usr/xenomai/bin/latency
== Sampling period: 1000 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT|  00:00:01  (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|      2.551|      2.795|      7.290|       0|     0|      2.551|      7.290
RTD|      2.551|      2.809|      7.082|       0|     0|      2.551|      7.290
RTD|      2.498|      2.825|      8.748|       0|     0|      2.498|      8.748
RTD|      2.446|      2.787|      7.393|       0|     0|      2.446|      8.748
RTD|      2.549|      2.784|      6.768|       0|     0|      2.446|      8.748
RTD|      2.497|      2.784|      6.716|       0|     0|      2.446|      8.748
RTD|      2.549|      2.781|      6.611|       0|     0|      2.446|      8.748

Cet outil montre les fluctuations (en micro-secondes) d’un timer de fréquence 1kHz. Ceci est assez révélateur des variations du temps de latence des interruptions également. La colonne la plus intéressante est la dernière à droite, puisqu’elle montre le retard maximum atteint pendant l’exécution. Au bout de quelques minutes, cette valeur se stabilise autour de 9 micro-secondes. En laissant l’expérience pendant une heure et en récupérant un histogramme des latences observées, on obtient les valeurs et graphique suivants :

# ----lat min|----lat avg|----lat max|-overrun|---msw|
#       2.563|      3.363|     11.283|       0|     0|

Xenomai 3 on Raspberry Pi 2

Sur l’axe des abscisses, les latences en micro-secondes. En ordonnées le nombre de cas où chaque latence a été observée. Cet axe est logarithmique. Nous voyons donc qu’une énorme majorité des latences est de 3 ou 4 micro-secondes et que la pire latence est de 12 micro-secondes.

Néanmoins pour des vraies mesures réalistes, il faut stresser le système intensément. Pour ce faire, il existe un script nommé dohell, livré avec Xenomai qui assure une charge très forte en nombre de tâches et opérations d’entrées-sorties. J’ai fait tourner ce script pendant une heure, avec en outre une charge importante en interruptions grâce à un ping en mode flood qui se produisait régulièrement pendant une dizaine de secondes.

# ----lat min|----lat avg|----lat max|-overrun|---msw|
#       1.318|     23.331|     61.452|       0|     0|

1h. charge élevée

Enfin, j’ai réalisé une mesure pendant deux heures en alternant les périodes de faible charge et les périodes de charge très intense. Je pense en effet que les pires latences se mesurent plutôt en régimes transitoires qu’en régimes permanents. Il est donc important d’alterner les conditions d’exécution.

# ----lat min|----lat avg|----lat max|-overrun|---msw|
#      -0.346|     10.508|     62.491|       0|     0|

Xenomai 3 on Raspberry Pi 2
Nous pouvons remarquer que dans ce dernier cas, la latence minimale est de -0.346 micro-seconde. Ceci peut paraître surprenant mais est normal. Xenomai estime en effet la latence minimale et anticipe les déclenchements des timers de la valeur (en nanosecondes) indiquée dans /proc/xenomai/latency. Nous pourrions donc la corriger ainsi :

# cat /proc/xenomai/latency
10520
# echo $((10520 - 346 )) > /proc/xenomai/latency
# cat /proc/xenomai/latency
10156
#

Conclusion

Nous voyons ainsi que le support de Xenomai sur Raspberry Pi 2 est assez simple à configurer et installer. Bien sûr il faudrait faire des tests plus longs et plus complets pour avoir une bonne certitude de la latence maximale mais je pense que la valeur de 63 microsecondes que nous avons obtenue doit en être une assez bonne approche.

N’hésitez pas à me faire part de vos essais et résultats.

Je tiens à remercier Nicolas Schurando qui m’a aidé lors d’une séance de formation à tester cette nouvelle version de Xenomai.

44 Réponses

  1. ZeRaler dit :

    Un grand merci pour ce tuto, ça me donne envie de tenter l’experience et de me mettre à Xenomai.

  2. Bidouya dit :

    Bonjour,
    Je n’arrive pas à appliquer la procédure pour la Pi 3 en compilant depuis Ubuntu dans une VMWare avec un toolchain.

    J’ai suivie tous vos tutos sur en remplacent uniquement par le buildroot que voici :
    https://buildroot.org/downloads/buildroot-2016.05-rc3.tar.bz2
    Et les commandes du genre :
    mkdir -p board/raspberrypi2/
    par
    mkdir -p board/raspberrypi3/

    Si je fais :
    cp arch/arm/boot/zImage /media/$USER/boot/
    cp arch/arm/boot/dts/bcm2710-rpi-3-b.dtb /media/$USER/boot/

    Et que j’insert la SD dans la Pi 3, elle ne démarre plus.

    Sa serrez peux être beaucoup vous demandé, mais vous est-il possible de mettre à disposition la dernière Jessie-lite avec Xenomai de pré installé ?

  3. Renato Coral dit :

    Hi, I was able to follow this tutorial and run on the Raspberry Pi 2.
    I’ve used the same versions you used but the USB ports are not working.
    Did you manage to make the USB port to work?

    Merci
    Renato

    • cpb dit :

      I did not use the USB port, I was always connected on the serial port of the Rasperry Pi.
      Maybe a missing module in the kernel configuration ?

  4. els dit :

    Bonjour,
    Merci pour cet article très intéressant et clair.
    Cependant, je bloque sur la compilation pour xenomai à l’étape make, après le “./configure –host=arm-linux –enable-smp”.

    L’erreur est “Could not find current ARM architecture” suivie de “SMP not supported below armv6, compile with -march=armv6 or above”. Visiblement, aucun des __ARM_ARCH_2__ … __ARM_ARCH_7A__ n’est fourni en variable d’environnement.
    Si cela a un rapport, j’utilise “gcc-linaro-4.9-2014.11-x86_64_arm-linux-gnueabihf-” et ai entré la ligne
    “make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-” pour la partie Linux avant d’arriver à Xenomai.

    J’ai aussi installé quelques outils qui semblaient manquer :
    sudo apt-get install autoconf
    apt-get install dh-autoreconf
    sudo apt-get install build-essential libtool
    avant de pouvoir lancer ./scripts/bootstrap

    A priori, la cible est un cortex-a7 / arch V7 (RPi2) donc il faudrait avoir __ARM_ARCH_7A__, mais pourriez vous m’indiquer comment le faire ?

    Merci d’avance pour votre réponse

    • cpb dit :

      En effet, j’ai utilisé un cross-compilateur généré spécifiquement pour la cible Rapsberry Pi 2, comme dans la première partie de cet article, les flags nécessaires sont déjà intégrés dans la configuration du compilateur.

  5. xenoboobs dit :

    Bonjour,
    j’ai suivi la procédure sur un Rpi2 et une Raspbian pré-installé. Cependant, le boot m’amène toujours sur le noyau linux non patché. Qu’ai-je pu oublier ?

    • cpb dit :

      Bonjour,

      • vérifier si le noyau compilé a bien été copié sur la carte SD (sous quel nom ? zImage, kernel.img ?)
      • le nom de ce noyau est-il bien indiqué dans config.txt (ligne kernel=) ?

      Cordialement.

  6. dracunciliasis dit :

    Hello,

    I’m following your tutorial for RP1 B+, do you have a patch file for this processor?
    What I mean is do you have a patch file similar to this one:
    “patch-xenomai-3-on-bcm-2709.patch”

    but for processor 2708?
    “patch-xenomai-3-on-bcm-2708.patch”

    In case you don’t have it can you help-me figgure out how to do it?
    There are five files changed in the patch:

    I think I should apply the same patch since at the beginning of the files it is stated the following:
    ——————– entry-macro.S

    * arch/arm/mach-bcm2708/include/mach/entry-macro.S
    *
    * Low-level IRQ helper macros for BCM2708 platforms

    —————————— armctrl.c

    /*
    * linux/arch/arm/mach-bcm2708/armctrl.c
    *
    * Copyright (C) 2010 Broadcom

    —————————— bcm2708_gpio.c

    /*
    * linux/arch/arm/mach-bcm2708/bcm2708_gpio.c
    *
    * Copyright (C) 2010 Broadcom

    There is just left the:
    —————————— Kconfig
    config ARCH_BCM2709

    select IPIPE_ARM_KUSER_TSC if IPIPE

    I think I just move the “select IPIPE_ARM_KUSER_TSC if IPIPE” to the config ARCH_BCM2708 section.

    —————————— bcm2709.c
    This one I’m not sure what to do.

    #ifndef CONFIG_IPIPE
    // timer control
    writel(0, __io_address(ARM_LOCAL_CONTROL));
    // timer pre_scaler
    writel(0x80000000, __io_address(ARM_LOCAL_PRESCALER)); // 19.2MHz
    //writel(0x06AAAAAB, __io_address(ARM_LOCAL_PRESCALER)); // 1MHz
    #endif

    if (use_dt)
    {
    of_clk_init(NULL);
    clocksource_of_init();
    }
    else
    dc4_arch_timer_init();

    #ifdef CONFIG_IPIPE
    // timer control
    writel(0, __io_address(ARM_LOCAL_CONTROL));
    // timer pre_scaler
    writel(0x80000000, __io_address(ARM_LOCAL_PRESCALER)); // 19.2MHz
    #endif

    Thankyou,
    Dracunciliasis

  7. jinlong dit :

    Many thanks. I am a layman who wishes to try realtime linux alike.
    Everything works until I come to the SD card.

    Would it be possible to simplify the procedure as follows?
    Flash a bootloader to a native SD card. Copy the image of xenomai3 binary to the SD.
    Insert the SD card
    RPI run like Noobs.

    Many thanks.

  8. jinlong dit :

    Besides, I followed your procedure on a PC or RPi2 or a VM-Linux. Everythings runs file until SD card. I get blocked there.

  9. hsan dit :

    Bonjour,
    Pendant la copie de zImage dans mon carte SD est ce que je dois supprimer zImage ancienne cré par buildroot?

  10. hsan dit :

    Bonjour ,
    por compiler les bibliothèques de Xenomai le fichier bootstrap n’est pas trouvée?

  11. hsan dit :

    dans tutoriel https://www.blaess.fr/christophe/2012/08/27/xenomai-sur-raspberry-pi/
    pourquoi vous avez copier zImage en Kernel.img est n’est en zImage?
    2eme probleme: sudo make ARCH=arm INSTALL_MOD_PATH=/media/Root modules_install
    il me demande d’installer modules install et lorsque je l’installe il m’affiche qu’il déja instalé?

    • cpb dit :

      La version 2012 du bootloader cherchait un noyau nommé kernel.img.
      La version actuelle de Buildroot définit le nom du noyau dans le fichier config.txt comme zImage.

      Il y a plus compliqué encore : le bootloader des distributions Raspbian actuelles charge le fichier kernel.img si la cible est un Raspberry Pi 1 ou 2, et kernel7.img si c’est un Raspberry Pi 3. Le “7” fait référence à L’architecture Arm v7 du nouveau system-on-chip du Pi 3.

      Je ne comprends pas la seconde question : “sudo make [...] modules_install” sert à copier tous les fichiers modules (les .ko) dans le répertoire “lib/modules/<numero du noyau>/” à partir du chemin $INSTALL_MOD_PATH. Ça n’installe rien.

      • hsan dit :

        Bonsoir
        Merci tout va bien et le system fonctionne mais lorsaque je tape:
        $ ./scripts/bootstrap

        le fichier bootstrap n’est pas trouvée dans script
        est ce que nécessaire de se passer par ces étape?
        $ ./scripts/bootstrap
        […]
        $ ./configure –host=arm-linux –enable-smp
        […]
        $ make

        Je vous remercie

        • cpb dit :

          Si vous avez bien pris la version 3.0.2 de Xenomai comme indiqué dans l’article, le fichier bootstrap se trouve bien dans le répertoire scripts.
          Je viens de le vérifier.

          Sinon, vous n’êtes probablement pas dans le bon répertoire.

  12. hsan dit :

    oui j’ai bien trouvé le fichier désolé. Je dois la compiler avant tout ?

  13. hedi dit :

    Bonsoir,
    j’ai suivi ce tutoriel et je suis bloqué dans la dernière make.pouvez vous m’aidez?
    voila ce qui est affiché (les derniers lignes):

    ../boilerplate/.libs/libboilerplate.a(libboilerplate_la-time.o): error adding symbols: File in wrong format
    collect2: error: ld returned 1 exit status
    make[3]: *** [libcobalt.la] Erreur 1
    make[3]: quittant le répertoire « /home/segec/buildroot/XenoPi2/xenomai-3.0.2/lib/cobalt »
    make[2]: *** [all-recursive] Erreur 1
    make[2]: quittant le répertoire « /home/segec/buildroot/XenoPi2/xenomai-3.0.2/lib/cobalt »
    make[1]: *** [all-recursive] Erreur 1
    make[1]: quittant le répertoire « /home/segec/buildroot/XenoPi2/xenomai-3.0.2/lib »
    make: *** [all-recursive] Erreur 1

  14. Elbaamri Sara dit :

    Bonsoir,
    merci pour votre tutoriel tout d’abord.
    je voudrais savoir comment désactiver les entrées que vous avez cité:

    CPU Power Management —>
    CPU Frequency scaling —>
    [ ] CPU Frequency scaling
    [….]

    Merci de me répondre

  15. RABBAH dit :

    Bonjour,
    Je vous remercie pour ce tutoriel, j’ai suivi tous les étapes avec success, sauf pour l’étape :
    ~/linux$ ./scripts/bootstrap
    -bash: ./scripts/bootstrap: No such file or director
    pourtant je suis bien dans le dossier linux
    j’ai fait une petite recherche d’auprès du dossier xenomai-3.0.2 il y a effectivement le fichier mais pas dans le dossier linux où nous travaillons
    ~/xenomai-3.0.2$ ls scripts/
    Kconfig.frag Makefile.in dynlist.ld prepare-kernel.sh xeno-config-cobalt.in xeno.in
    Makefile.am bootstrap histo.gp wrap-link.sh xeno-config-mercury.in
    d’après vous est ce que c’est un problème de patch?
    Merci pour votre aide

  16. RABBAH dit :

    Bonjour christophe
    Après avoir builder raspberry et l’avoir mis sur carte SD, j’arrive pas à me connecter à la machine, déjà pars que j’ai pas d’écran série pour me connecter, j’aimerai savoir si je peux builder xenomai pour raspberry sur HDMI, car c’est plus facile pour moi de se connecter ainsi.
    Ou bien au minimum j’ai un accès ssh, quand j’ai connecté raspberry avec câble RJ45 j’ai remarqué que les led ne s’allume pas, est ce que xenomai n’accepte pas l’interface ethernet?
    Merci pour l’aide.

    • cpb dit :

      Pas de problème pour utiliser une console graphique ou une connexion SSH.

      J’ai juste pris l’habitude d’utiliser le port série, car c’est plus proche des conditions que je rencontre sur les systèmes embarqués sur lesquels je travaille généralement.

  17. Syrine dit :

    Bonjour,
    Je suis entrain de suivre les étapes pour la compilation de xenomai+linux sur Raspberry Pi3.
    Mais je suis bloquée à l’étape:
    wget https://www.blaess.fr/christophe/files/article-2016-05-22/patch-xenomai-3-on-bcm-2709.patch

    ça affiche une erreur bizarre :
    “” Resolving http://www.blaess.fr (www.blaess.fr)… 213.186.33.17
    Connecting to http://www.blaess.fr (www.blaess.fr)|213.186.33.17|:443… connected.
    HTTP request sent, awaiting response… 403 Forbidden
    2017-03-10 16:44:46 ERROR 403: Forbidden. “””

    Qu’est ce que je dois faire ?
    Merci de me répondre .

  18. Syrine dit :

    Bonjour ,
    Je voulais installer xenomai3 sur la Raspberry Pi 3 (sur laquelle NOOBS est installé su la carte SD) . J’ai une certaine confusion.
    Je voulais savoir est-ce je dois utiliser le Buildroot ou pas nécessaire?
    les étapes décrites ci-dessus sont-elles identiques pour la Raspberry Pi3?
    Merci de m’aider

  19. Syrine dit :

    Bonjour,
    Alors comment faire pour ajouter l’extension temps réel à raspberry pi 3?

    • cpb dit :

      Avec le Raspberry Pi 3 on peut utiliser PREEMPT_RT qui améliore les performances temps réel de Linux, mais pas Xenomai.
      Pour mes formations sur Xenomai je continue à utiliser des Pi 2.

  20. Syrine dit :

    Compris!
    Mais ma recherche m’a conduit et j’ai trouvé un tuto japonais qui implémente Xenomai 3 sur Raspberry Pi3 .
    Je vais l’essayer mais je suis pas sure du résultat.
    Si vous voulez le voir juste une petite traduction :
    http://artteknika.hatenablog.com/entry/2016/08/23/143400
    PS: si vous trouvez que les étapes ne sont pas raisonnables prière de m’informer.
    merci

    • cpb dit :

      Merci du lien. Les étapes indiquées sont bonnes, ce sont les mêmes que pour le Pi 2, hormis le fichier Device Tree. Ça me surprend, il me semblait que ça ne fonctionnait pas avec le Pi 3. Je vais reprendre mes essais pour vérifier çà.

  21. Syrine dit :

    J’aimerais bien avoir votre réponse si ça fonctionne ou pas
    merci pour votre aide

    • cpb dit :

      Le système démarre en effet sur un Raspberry Pi 3 avec la même méthode que celle décrite dans cet article. Il faut simplement utiliser le fichier Device Tree “bcm2710-rpi-3-b.dtb” produit lors de la compilation du kernel.

      J’ai utilisé un cross-compiler produit par Buildroot 2017-02.

      Je n’ai pas fait de vrai test du système, j’ai juste vérifié que ça boote. Je rédigerai une petite note à ce propos dès que j’aurai vérifié que ça marche correctement (notamment, m’assurer que l’on puisse gérer les interruptions des GPIO avec Xenomai).

  22. Syrine dit :

    Merci pour vitre réponse .
    Maintenant je suis entrain d’installer Ethercat 1.5.2 depuis ethercat-hg sur la rpi3 . J’ai fait la compilation :
    #sudo make
    #sudo make modules_install install
    #sudo depmod
    et quand je fais /etc/init.d/ethercat start la réponse est:
    Starting EtherCAT master 1.5.2 modprobe: FATAL: Module ec_master not found.
    failed

    la commande:
    “insserv ethercat” ça marche (rien n’est affiché)

    je suis bloquée depuis 2 jours j’ai suivi le tuto point par point mais le problème c’est il n’ya pas de ec_master.ko pour le charger .
    qu’est ce qu’il faut faire?
    Merci de m’aider

  23. hackem dit :

    j’ai bien suivi mais j’ai trouvé ces erreurs ….

    features.c: In function ‘cobalt_check_features’:
    /home/lol/Desktop/rasp/xenomai-3.0.2/lib/cobalt/arch/arm/include/asm/xenomai/syscall.h:69:45: error: invalid register name for ‘__r0’
    unsigned long __a0; register unsigned long __r0 __asm__ (“r0”);


    qu’est ce qu’il faut faire?
    Merci de m’aider

  24. hackem dit :

    vous pouvez m’envoyer touts les fichers que je dois mettre sur SD dans un zip svp ?

URL de trackback pour cette page