Méthodologie & Expertise

Comment je
travaille

De l'analyse hardware au déploiement OTA en production - ma méthodologie et mon expertise Yocto pour construire des systèmes embarqués robustes.

4étapes clés
de la spec au produit
3+ans en
systèmes embarqués
De la spec au produit

Mon process de développement embarqué

01

Analyse hardware

  • Datasheet deep dive (SoC, peripherals, memory map)
  • Identification des contraintes (power, thermal, cost)
  • Choix de l'architecture (Yocto vs Buildroot, kernel version)
  • Validation de faisabilité avec l'équipe hardware
02

Architecture système

  • Schéma de boot (U-Boot → Kernel → FS)
  • Stack middleware (systemd, D-Bus, managers)
  • Partitioning strategy (boot, rootfs, data, update)
  • Choix des composants critiques (libc, init system)
03

Développement itératif

  • Validation par couches (boot → kernel → drivers → app)
  • Tests unitaires + tests d'intégration continue
  • Commits atomiques avec messages descriptifs
  • Documentation continue (README, diagrammes, troubleshooting guides)
04

Validation & déploiement

  • Tests hardware-in-the-loop sur cibles réelles
  • Stratégie OTA (RAUC, rollback, monitoring)
  • Handover complet (docs, scripts)
  • Suivi post-déploiement et correctifs
Environnement de travail

Mes outils & setup

Development environment

HostDebian / Ubuntu + Docker containers
IDEVisual Studio Code + plugins
BuildYocto Cooker + bitbake + devtool
DebugGDB • valgrind • perf • strace
CI/CDGitLab CI • automated builds
DocsMarkdown • Mermaid diagrams • Doxygen • Notion & Obsidian

Version control & collaboration

$ git commit -m "feat(bsp): add RAUC support"

$ git commit -m "fix(kernel): resolve DT issue"

$ git commit -m "docs: update build guide"

  • Commits atomiques et descriptifs (conventional commits)
  • Branches feature pour chaque développement
  • Pull requests avec review obligatoire
  • Tags sémantiques (v1.0.0, v1.1.0)
BSP en production

Mes plateformes Yocto

NXP i.MX6 Solo

FDI Urmet France

Production
Yocto 5.0 Scarthgap•Kernel 5.15 LTS•Qt 6.8
BSP unifié pour 4 références produits
Système OTA RAUC validé (dual partition)
RAUC
DMS
Qt/QML
Systemd
ModemManager

NXP i.MX8 Mm & Mn

FDI Urmet France

Production
Yocto 5.0 Scarthgap•Kernel 5.15 LTS•Qt 5.15
BSP unifié pour 2 références produits
Stack graphique avec Weston & DRM/KMS
Système OTA RAUC validé (dual partition)
IHM Qt pour écrans tactiles 7"
RAUC
DMS
Qt
Systemd

Allwinner V853s

Urmet SPA Italie

Étude R&D
Yocto (cible)•ARM Cortex-A + RISC-V + NPU
Étude de faisabilité migration SDK vendeur → Yocto
Investigation architecture SoC hétérogène (CPU + NPU)
Analyse compatibilité binaire et contraintes kernel
Définition architecture meta-layers cible
Roadmap migration livrée à la direction R&D
BSP
U-Boot
Device Tree
Meta-layers
Analyse kernel
Voir le détail du stage
Compétences techniques

Ma Stack Yocto

Layers & recipes

meta-custom-bsp/

├── recipes-bsp/u-boot/

├── recipes-kernel/linux/

├── recipes-core/systemd/

├── recipes-graphics/qt6/

├── recipes-support/rauc/

└── recipes-apps/hmi-qt/

  • Custom layers & distros
  • BitBake recipes (.bb, .bbappend)
  • Kernel patches & device trees
  • U-Boot configuration

Build & debugging

$ cooker shell

$ bitbake -e core-image

$ devtool modify linux-yocto

$ bitbake -g core-image

$ bitbake-layers show-recipes

  • cooker shell (environment management)
  • bitbake -e (environment introspection)
  • devtool (modify, upgrade, reset)
  • Dependency graphs (bitbake -g)

Images & deployment

  • Image types (ext4, wic, squashfs, tar.gz)
  • SDK generation (populate_sdk)
  • Multiconfig builds
  • RAUC bundles (.raucb)

CI/CD & industrialisation

  • Cooker yocto
  • GitLab CI pipelines automatisés
  • Builds reproductibles
  • CVE scanning & security patches
Mises à jour OTA

Architecture RAUC

Système de mise à jour robuste avec partitions A/B, vérification cryptographique et rollback automatique en cas d'échec.

Schéma de partitionnement

System A/dev/mmcblk0p2 • Active
System B/dev/mmcblk0p3 • Standby
Data/dev/mmcblk0p4 • Persistent

Processus de mise à jour

  1. 1Download bundle → /data/update.raucb
  2. 2RAUC install → writes to inactive partition
  3. 3Set bootloader flag → switch active/inactive
  4. 4Reboot → boot from new partition
  5. 5Validate → mark as good or rollback
Signature cryptographique (x.509)
Rollback automatique si échec boot
Device-pull updates (planification)
Monitoring temps réel (DMS)
Résolution de problèmes

Ma philosophie de debugging

Exemple concret : Comment je résous un kernel panic

  1. 1

    Reproduire de manière déterministe

    Identifier les conditions exactes qui déclenchent le crash. Est-ce au boot ? Après une action spécifique ? À intervalles réguliers ?

  2. 2

    Isoler la couche fautive

    Boot, kernel, driver, ou application ? Utiliser des points de test progressifs pour réduire le périmètre.

  3. 3

    Activer les logs verbeux

    loglevel=7, ftrace, dynamic debug. Plus d'informations = meilleure compréhension du problème.

  4. 4

    Analyser les stack traces & dumps

    Lire les call stacks, regarder les valeurs des registres, identifier la fonction et la ligne qui pose problème.

  5. 5

    Tester le fix en environnement contrôlé

    Valider sur hardware et ensuite en compilation automatisée. S'assurer que le fix ne crée pas de nouveaux problèmes.

  6. 6

    Documenter root cause & workaround

    Écrire dans le commit message ou la doc pourquoi le bug existait et comment il a été résolu.

Maintenabilité

Pourquoi je documente tout

Pour moi dans 6 mois

Je ne me souviendrai pas pourquoi j'ai fait ce patch kernel ou ce choix d'architecture.

Pour l'équipe

Quelqu'un d'autre doit pouvoir maintenir, debugger et faire évoluer le système sans moi.

Pour le client

Le produit doit être compréhensible, avec des guides clairs pour le déploiement et la maintenance.

À lire ensuite · À propos

Qui je suis

L'ingénieur derrière les systèmes - parcours, valeurs et ce qui me motive.