Dans cet article, je regroupe toutes les tentatives de compilation de noyau Linux pour le SOM Voipac iMX6 Rex destiné à un usage industriel. Je vous conseille préalablement mon article sur le marché du i.MX6 ainsi que mes premiers pas avec le iMX6 Rex.

Méthodes proposées par le fabricant

Rendez-vous sur cette page du wiki du fabricant pour découvrir les tutoriels pas à pas.

Compilation du noyau seul en mode standalone

Ce procédé que je qualifie de « standalone » consiste à compiler le noyau Linux directement depuis ses sources et un compilateur approprié. Pour tous les Linuxiens qui ont déjà fait un make menuconfig ; make pour une machine x86_64, c’est exactement cette méthode qui est détaillée ici pour le iMX6 Rex Ultra.

Téléchargement et configuration de la chaîne de compilation

Le wiki de Voipac propose de télécharger une chaîne de compilation chez Linaro, plus précisément l’archive de vinaires gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux.tar.xz. L’URL de téléchargement est cassée sur le wiki, et je l’ai corrigée ici.

Les binaires ainsi déposés dans /opt/gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux/bin sont en 32 bits. Sur Debian 11, pour les exécuter, il faut installer des librairies 32 bits grâce à Multiarch. Le paquet ia32-libs n’existe plus, et la suite de paquets ci-dessous devrait la remplacer.

Les commandes suivantes permettent d’exporter des variables d’environnement globales nécessaires au processus de compilation pour l’architecture gnueabihf / armhf.

Compilation du noyau

A ce stade, le wiki de Voipac propose la compilation du noyau dans les versions suivantes :

  • 3.0.35 (2011) pour Android 4.4.2 Kit-Kat
  • 3.14 (2014), la version compilée par défaut avec le processus Yocto Jethro.
  • 4.1 (2015)

Malheureusement, aucune méthode ni aucun repository n’est proposé pour compiler une version plus récente que la 4.1.

Voici les commandes proposées pour Linux 4.1

Ce qui est positif, c’est que tout le nécessaire est fourni dans le repository pour compiler le fichier imx6-rexultra.dtb (Device Tree Blob) permettant au noyau de connaître les périphériques matériels.

L’erreur de compilation suivante apparaît :

Un patch est nécessaire sur le fichier scripts/dtc/dtc-parser.tab.c. Sur la ligne 73 il faut remplacer YYTYPE yylloc; par extern YYLTYPE yylloc;.

De plus le paquet bc est indispensable durant la compilation.

Cette méthode fonctionne sur ma machine :

Le fichier du noyau est dans arch/arm/boot/zImage et les fichiers dtb sont dans arch/arm/boot/dts/*.dtb.

ll est possible d’exploiter ce noyau avec par exemple un rootfs généré grâce à Debian debootstrap, multistrap ou n’importe quelle méthode de type « Linux From Scratch ».

Il s’agit plus précisément d’une version Linux 4.1.36. C’est la même version qui est fournie sur la carte SD de démonstration du Rex.

Compilation d’une image contenant le noyau avec Yocto

La méthode Yocto 4.1 Krogoth (2016) proposée par Voipac est disponible sur leur wiki. Comme toutes les méthodes Yocto pour i.MX6, elle repose sur l’outil repo, codé en Python et qui nécessite de nos jours une version 3.6 au minimum.

Ensuite, les fichiers du BSP pour le iMX6 Rex étaient historiquement hébergés à l’adresse suivante chez Freescale : git://git.freescale.com/imx/fsl-arm-yocto-bsp.git. Comme cela est expliqué sur les forums NXP, ce dépôt a été fermé et est théoriquement remplacé par git://source.codeaurora.org/external/imx/fsl-arm-yocto-bsp.git pour télécharger le BSP en version L4.1.15_2.1.0-ga.

Le problème, c’est que l’opération repo sync échoue. La cible des fichiers à télécharger semble ne pas répondre.

La méthode Yocto 2.1 Krogoth proposée par Voipac ne fonctionne donc plus de nos jours. C’était la seule méthode Yocto capable de compiler les fichiers Device Tree Blob .dtb. C’est dommage.

Méthodes proposées par Fedevel

Méthode avec LTIB

Sur imx6rex.com, La page iMX6 Rex Software propose une méthode pas à pas How to start with Linux and uBoot qui utilise LTIB (Linux Target Image Builder). C’est un vieil outil qui était supporté par le passé pour compiler le BSP en version L3.0.35_4.1.0 sur Ubuntu 9.

Aujourd’hui le fichier L3.0.35_4.1.0_130816_source.tar.gz est introuvable. J’ai tenté de demander le fichier sur les forums NXP sans succès. Encore pire, il apparaît que les emplacements des différents packages utilisés par LTIB ne sont plus maintenus.

Je n’ai pas eu beaucoup plus de succès concernant ce fichier introuvable sur les forums Fedevel qui me redirige vers Yocto.

La méthode LTIB ne peut donc plus être utilisée de nos jours.

Méthode avec Yocto pour le Rex (1)

La page How to start with YOCTO semble prometteuse bien que basée sur une ancienne version de Yocto 1.6 Daisy (2014). Mais elle explique que le iMX6 Rex n’a pas été porté pour Yocto, et que la page explique le principe dans les grandes lignes pour les personnes qui voudraient le faire eux-mêmes.

La layer imx6rex proposée sur la page contient deux recettes Yocto d’exemple qui ne font rien, et une recette pour remplacer le nom du matériel dans uBoot. On ne sort donc pas du cas général pour la board imx6qdlsabresd, et j’ignore quelles sont les spécificités du Rex qui ne seront pas supportés, ni quels sont les matériels du imx6qdlsabresd qui sont absents du Rex. En particulier, rien n’indique que le noyau Linux a été patché pour compiler les Device Tree Blob .dtb qui étaient présents sur le noyau custom Voipac ci-dessus. Ma question à ce sujet sur les forums Fedevel reste pour le moment en suspens.

L’aspect positif est que le dépôt https://github.com/Freescale/fsl-community-bsp-platform fonctionne avec Yocto à jour en version 4.0 Kirkstone sur Debian 11. L’aspect négatif est que le Rex ne fait pas partie des $MACHINE supportées par le dépôt communautaire du BSP Freescale.

En respectant la procédure j’ai pu compiler avec Yocto 4.0 Kirkstone sur Debian 11 une image core-image-minimal et fsl-image-multimedia-full, contenant toutes deux un noyau Linux 5.18.5. Chez moi, la première image cale très rapidement après le démarrage du noyau, et la second image fonctionne correctement.

Avec l’aide de ce thread de forum, j’ai pu compiler avec Yocto 2.0 Jethro sur Ubuntu 16. Il a fallu recompiler OpenSSL 1.0.2e, et Python 3.6 pour l’outil repo. Il a cependant fallu désactiver totalement la vérification de validité du certificat SSL dans repo (explications ici) car je suspecte la version recompilée de OpenSSL d’être trop ancienne. Dans Yocto 2.0 Jethro cependant, il faut Python 2.7 pour bitbake. Mon image core-image-minimal contient ainsi un noyau Linux 3.14 que je n’ai même pas essayé car trop ancien (2014) pour moi. Entre OpenSSL plus supporté sur Ubuntu 16, la nécessité de disposer de deux versions différentes de Python, et le noyau Linux en version 3.14, on voit bien que le dépôt communautaire du BSP Freescale pour Yocto 2.0 Jethro a sérieusement pris la poussière.

Méthode avec Yocto pour le Rex (2)

La page How to develop your own software: uBoot, Linux, Filesystem, YOCTO est censée remplacée la page ci-dessus avec Yocto 2.0 Jethro (2015). Mais elle a été rédigée pour le OpenRex et non pour le Rex. La partie customisation du noyau Linux pour le OpenRex est très légère en particulier pour les Device Tree Blob .dtb quand je lis ceci :

Cette ressource en ligne est très intéressante et pédagogique. Mais je ne m’attends pas à ce qu’elle produise une image ou un noyau pleinement compatible avec le iMX6 Rex.

Conclusion

Sur cinq méthodes de compilation pour le iMX6 Rex proposées soit sur le site du fabricant, soit sur le site imx6rex de Fedevel, une seule fonctionne encore parfaitement de nos jours pour Linux 4.1 (2015) qui est déjà End Of Life (EOL). Pour le sport, j’ai réussi à installer Debian 11 armhf sur le Rex grâce à debootstrap, plus ce noyau Linux 4.1. Mais qui veut encore d’un noyau 4.1 en 2022 ?

Les autres méthodes ne fonctionnent pas, soit parce que les dépôts Yocto ne sont plus maintenus, soit parce que le noyau n’est pas patché spécifiquement pour supporter le Rex avec les fichiers Device Tree Blob (.dtb) correspondants.

Je rejoins donc l’avis préalable présent sur le site du fabricant concernant le cycle du vie du Rex : n’adoptez pas ce produit pour de nouveaux projets de développements. A noter qu’il existe d’autres matériels à processeur iMX6 qui ne souffrent pas de cet inconvénient.