Ingénieur Linux embarqué : Yocto, device tree, pilotes et secure boot

En entretien, un ingénieur Linux embarqué répond sur la couche située entre le matériel et l'application. Le poste part souvent du BSP fourni par le fabricant du SoC (NXP i.MX, STM32MP, Texas Instruments, Rockchip) : il faut l'adapter à la carte du projet, écrire ou corriger des pilotes, régler le démarrage et industrialiser le build de l'image. Les offres affichent aussi « développeur Linux embarqué », « ingénieur BSP » ou « développeur pilotes Linux ».

Yocto peut vouloir dire deux choses très différentes sur un CV : avoir lancé bitbake sur une image fournie, ou avoir organisé les layers d'un produit et suivi ses mises à jour. Faites préciser ce que la personne a écrit elle-même : une recette, un bbappend, un nœud de device tree, un pilote, un script de mise à jour. Le niveau se voit aussi au débogage, avec dmesg, la console série et une trace de kernel oops.

Des offres récentes citent aussi le secure boot, la mise à jour signée et le suivi des CVE. Posez au moins une question sur chacun. Le PDF reprend 30 questions sur six axes avec une grille de 1 à 4.

Yocto, noyau, bootloader : les briques du poste

Yocto Project et BitBake

L'outil de construction d'images le plus demandé dans les offres. Le système se décrit en layers et en recettes, que BitBake compile. Une version LTS sort tous les deux ans : Scarthgap (5.0) est maintenue jusqu'en avril 2028, Wrynose (6.0) jusqu'en avril 2030. Demandez ce que la personne a écrit elle-même dans un layer.

Buildroot

Une alternative plus simple à Yocto, qui génère une image complète à partir d'une configuration unique. Elle convient aux systèmes réduits et aux petites équipes. Une version LTS sort chaque année en février.

Noyau Linux et device tree

Le device tree décrit le matériel de la carte (bus, composants, broches, mémoire) pour que le noyau charge les bons pilotes. La plupart des tâches d'adaptation d'une carte passent par lui. Les versions longterm du noyau, comme 6.12 et 6.18, reçoivent des correctifs plusieurs années.

Pilotes noyau

Pilotes platform, I2C, SPI, et sous-systèmes comme IIO pour les capteurs ou input pour les boutons. L'ingénieur adapte des pilotes existants et en écrit pour les composants non supportés. Un pilote écrit hors de l'arbre officiel doit être maintenu à chaque mise à jour du noyau.

U-Boot et TF-A

U-Boot est le bootloader le plus courant sur les cartes ARM : il charge le noyau et le device tree, et gère la logique de retour arrière des mises à jour. Sur beaucoup de SoC, Trusted Firmware-A (TF-A) s'exécute avant lui et prépare l'environnement sécurisé.

systemd

Le gestionnaire de démarrage et de services de la plupart des images. Il lance l'application, la redémarre en cas de plantage et mesure le temps de démarrage avec systemd-analyze. Certaines images très réduites utilisent BusyBox init à la place.

SWUpdate, RAUC et Mender

Trois outils de mise à jour à distance, tous capables de gérer deux partitions A et B et une image signée. Le choix dépend du serveur de déploiement souhaité et de l'intégration au BSP. Ce sujet revient souvent dans les offres pour des produits déployés en nombre.

Secure boot, dm-verity et OP-TEE

Le secure boot vérifie chaque étage du démarrage par signature, dm-verity contrôle l'intégrité de la partition système, OP-TEE exécute du code de confiance dans la zone TrustZone du processeur. Les mécanismes de départ dépendent du SoC (HAB sur i.MX, TF-A sur STM32MP).

Les offres d'ingénieur Linux embarqué demandent du C, souvent du C++ et du Python pour les outils, Yocto ou Buildroot, le noyau Linux et le device tree, U-Boot, et des bus comme I2C, SPI, UART, CAN ou Ethernet. Certaines ajoutent Qt pour l'interface, Rust, la connectivité (Wi-Fi, 4G, Bluetooth), le temps réel avec PREEMPT_RT ou un cœur microcontrôleur à côté de Linux. Le poste varie selon la part de bas niveau : certains profils passent leurs journées dans les pilotes et le device tree, d'autres dans l'intégration de l'image, la CI et les mises à jour. Le Cyber Resilience Act européen ajoute des obligations de suivi des vulnérabilités et de mise à jour pour les produits connectés, d'où la présence du secure boot et du SBOM dans certaines offres.

Compétences d'un ingénieur Linux embarqué à évaluer

• Yocto, layers et recettes
• Device tree et pilotes noyau
• Chaîne de démarrage et U-Boot
• Secure boot et mises à jour A/B
• Débogage noyau et temps réel
• Build reproductible et tests sur carte

Cinq questions posées à un ingénieur Linux embarqué

Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.

1. Question 1 · confirmé

   Le fabricant de la carte fournit un BSP Yocto. Comment ajoutez-vous votre application et un correctif du noyau sans modifier ses layers ?

   Une bonne réponseUn layer propre au projet, avec sa priorité, qui contient la recette de l'application, une configuration de machine ou de distribution si besoin, et des fichiers .bbappend. Le correctif du noyau passe par un .bbappend sur la recette du noyau qui ajoute le patch et des fragments de configuration (.cfg) dans SRC_URI. Les révisions de tous les layers sont figées, par un fichier kas ou un manifeste repo, pour que le build soit reproductible.

   Signal d'alerteModifier directement les fichiers du layer du fabricant, ou faire un menuconfig dans le dossier de build sans rien enregistrer.

2. Question 2 · confirmé

   Un capteur I2C ajouté sur la carte n'apparaît pas sous Linux. Quelle est votre méthode ?

   Une bonne réponseVérifier le nœud du device tree : placé sous le bon contrôleur I2C, compatible qui correspond au pilote, adresse dans reg, contrôleur avec status = "okay" et pinctrl correct. Vérifier que le pilote est compilé (configuration du noyau, module chargé). Ensuite dmesg pour une erreur de probe, /sys/kernel/debug/devices_deferred pour un probe différé, i2cdetect pour voir si le composant répond, et le device tree réellement chargé sous /proc/device-tree, décompilé avec dtc.

   Signal d'alerteAccuser le matériel sans avoir vérifié le device tree, ou modifier le fichier .dts sans vérifier que le bon DTB est chargé.

3. Question 3 · confirmé

   Décrivez la chaîne de démarrage d'une carte ARM, de la mise sous tension jusqu'à l'application.

   Une bonne réponseLe code en ROM du SoC charge un premier étage depuis la mémoire de démarrage choisie (eMMC, SD, NAND, SPI). Ce premier étage, SPL d'U-Boot ou TF-A selon le SoC, initialise la DRAM et charge U-Boot, parfois avec OP-TEE. U-Boot charge le noyau, le DTB et éventuellement un initramfs, puis passe la ligne de commande. Le noyau monte la partition racine et lance init, en général systemd, qui démarre les services. Il sait dire où regarder quand la carte s'arrête à chaque étape.

   Signal d'alerte« Le bootloader lance Linux » sans étapes, ou aucune idée du rôle du DTB.

4. Question 4 · senior

   Comment concevez-vous la mise à jour à distance d'une flotte d'appareils sous Linux sans risque d'en bloquer un ?

   Une bonne réponseDeux partitions système A et B, et une partition de données à part. L'outil de mise à jour (SWUpdate, RAUC ou Mender) écrit l'image signée dans la partition inactive et la vérifie. U-Boot démarre dessus avec un compteur de tentatives (bootcount) et revient à l'ancienne partition si le nouveau système n'est pas confirmé sain après ses vérifications. Il prévoit les mises à jour du bootloader, plus risquées, et la migration des données entre versions.

   Signal d'alerteUn apt upgrade ou une copie de fichiers sur le système en marche, sans retour arrière possible.

5. Question 5 · confirmé

   Votre pilote provoque un kernel oops au chargement. Comment lisez-vous la trace ?

   Une bonne réponseLe message donne le type d'erreur (souvent un déréférencement de pointeur nul), la fonction et le décalage où pointe le PC (fonction+0x48/0x120), la pile d'appels et le module en cause. Avec le vmlinux ou le module compilé avec les informations de debug, faddr2line ou decode_stacktrace.sh retrouvent la ligne du code source. Il pense aux causes fréquentes au probe : ressource demandée avant d'exister, donnée privée non initialisée, ordre d'initialisation.

   Signal d'alerteRelancer en ajoutant des printk partout sans lire la trace.

Questions fréquentes sur le recrutement en Linux embarqué

Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.