Journal de campagne Jetson : de l'émulateur au silicium

OC2-Edge s’exécute aujourd’hui en émulation x86-64 et ARM64 : ~930 tests automatisés au vert, 9 chaînes d’intégration continue, démonstration rejouable par quiconque clone le dépôt (rejouer la démo sur émulateur). La campagne Jetson ouvre l’étape suivante : porter le nœud sur silicium réel.

Cet article est le premier épisode d’un journal de campagne récurrent. Il fixe la doctrine, décrit le banc, publie le protocole et ses critères de passage. Il ne publie aucun résultat : à la date de publication, aucune étape n’est validée sur matériel. La section « Résultats au fil de l’eau », en fin d’article, est vide et le restera jusqu’aux premières mesures.

Zéro engagement matériel

Sur les modules Jetson, l’activation définitive du démarrage sécurisé passe par des fusibles (fuses) : des bits programmables une seule fois dans le SoC (System on Chip). NVIDIA documente l’opération comme irréversible : un bit passé à 1 ne revient jamais à 0 [2]. Un fusible grillé avec une mauvaise clé, ou dans le mauvais ordre, peut rendre le module définitivement inutilisable [2].

La doctrine de la campagne en découle : zéro engagement matériel tant que la chaîne complète n’est pas validée. Trois règles s’appliquent.

1. Aucun fusible n’est grillé pendant la campagne. La validation de la chaîne de signature s’effectue sans écriture dans le silicium. L’outillage de fusion de NVIDIA dispose d’un mode d’essai qui envoie le blob de fusibles au module sans rien graver [2] ; seul ce mode est utilisé.
2. Les garde-fous sont codés en dur dans l’outillage. Les scripts de flash du dépôt refusent toute commande de fusion ; la cible de gravure n’existe pas dans l’outillage publié de la campagne. Un opérateur ne peut pas griller un fusible par erreur avec les outils du dépôt : il devrait sortir de l’outillage et le faire volontairement.
3. Tout reste réversible. Le module se reflashe intégralement par USB en mode recovery ; un état antérieur se restaure à tout moment. Tant qu’aucun fusible n’est engagé, aucune manipulation de la campagne ne dégrade le matériel de façon permanente.

L’ancrage matériel de la vérification, c’est-à-dire l’inscription de l’empreinte de clé publique dans les fusibles, est le dernier jalon de la campagne, pas le premier. Cette opération ne sera envisagée qu’après validation de toutes les étapes précédentes, sur un module dédié à cet usage, et fera l’objet d’une décision documentée dans ce journal.

Le banc : NVIDIA Jetson Orin

Le banc de la campagne est un module NVIDIA Jetson Orin, un calculateur embarqué ARM64 [1]. Cette cible réunit quatre propriétés utiles pour une première campagne silicium :

• une architecture ARM64, déjà couverte par l’émulateur du dépôt : les tests existants s’appliquent sans portage d’architecture ;
• une chaîne de boot documentée publiquement par le constructeur, avec un port UEFI (Unified Extensible Firmware Interface) open-source [1][5] ;
• une couche Yocto communautaire maintenue, meta-tegra, qui évite de dépendre du seul outillage propriétaire [3] ;
• un accélérateur de calcul intégré, pertinent pour de futurs modules d’inférence embarquée.

Le Jetson Orin ne représente pas tous les calculateurs tactiques. Il sert de première cible parce que sa chaîne est documentée et son outillage accessible. Le registre de cartes du dépôt est conçu pour accueillir d’autres cibles selon le même protocole ; les enseignements de cette campagne y seront consignés pour les suivantes.

Ce qui se transpose tel quel

Trois éléments passent de l’émulateur au Jetson sans modification de fond.

Le registre de cartes. Le dépôt décrit chaque cible matérielle dans un registre : architecture, méthode de flash, périphériques attendus, points de contrôle. L’émulateur ARM64 y figure comme une cible parmi d’autres. Le Jetson Orin s’y ajoute comme une entrée supplémentaire, pas comme un cas particulier : les outils qui lisent le registre ne changent pas.

Le build meta-tegra. L’image immuable d’OC2-Edge est produite par le Projet Yocto [4]. meta-tegra, la couche Yocto pour Jetson maintenue par la communauté OE4T, fournit le BSP (Board Support Package : noyau, pilotes, outils de flash) sous forme de recettes Yocto [3]. Le même arbre de build produit l’image émulateur et l’image Jetson ; seule la couche cible change. Les exigences de build reproductible bit à bit (reproductible bit à bit) s’appliquent à l’image Jetson comme aux autres ; leur satisfaction effective sur cette cible est un point à vérifier pendant la campagne.

Le flash USB en mode recovery. Le module Jetson expose un mode récupération par USB, piloté par les outils du BSP [1]. L’outillage du dépôt enveloppe ce flash dans les mêmes commandes que le déploiement sur émulateur : la procédure opérateur est identique, seule la cible déclarée dans le registre diffère.

Ce qui change : la chaîne de boot

Sur l’émulateur, le firmware OVMF (le port UEFI pour machines virtuelles) démarre directement l’UKI (Unified Kernel Image) signée, qui monte le socle immuable. Sur Jetson, la chaîne de boot du BSP NVIDIA s’intercale avant UEFI [1] :

1. le BootROM, figé dans le silicium, s’exécute à la sortie de reset et charge MB1 ;
2. MB1, binaire fourni et signé par NVIDIA, initialise le matériel selon sa table de configuration ;
3. MB2 charge les firmwares de la plateforme et transfère le contrôle à UEFI ;
4. UEFI, ici le port open-source edk2-nvidia [5], charge l’UKI comme le fait OVMF sur l’émulateur.

Le point d’entrée d’OC2-Edge reste le même : une UKI signée, vérifiée par UEFI. Ce qui précède UEFI change entièrement.

L’ancrage de la vérification diffère aussi. Sur l’émulateur, la racine de confiance est une variable UEFI provisionnée par l’outillage du dépôt. Sur Jetson, deux niveaux coexistent : la vérification de l’UKI par UEFI, identique dans son principe à celle de l’émulateur, et la vérification des maillons antérieurs (MB1, MB2, firmwares) par le BootROM, ancrée dans les fusibles [2]. La campagne valide d’abord le premier niveau, sans toucher au second : conformément à la doctrine, l’ancrage fusibles reste hors périmètre jusqu’au dernier jalon.

Le protocole de la campagne

La campagne procède par étapes ordonnées. Chaque étape a un critère de passage vérifiable ; une étape n’est ouverte que lorsque la précédente est validée et documentée dans ce journal.

Étape	Contenu	Critère de passage
1	Boot du BSP de référence meta-tegra, sans OC2-Edge	Le module démarre l’image de référence ; console série active
2	Boot de l’image OC2-Edge non signée	Le socle immuable démarre ; les services du nœud répondent
3	Secure Boot UEFI avec clés de développement	L’UKI signée démarre ; une UKI altérée est refusée au boot
4	Partitions A/B et retour arrière	Une mise à jour interrompue par coupure d’alimentation retombe sur la partition saine
5	Chaîne de mise à jour TUF hors ligne	Le nœud applique une mise à jour signée depuis un support local, sans réseau
6	Ancrage matériel (fusibles), module dédié	Décision distincte et documentée, après validation complète des étapes 1 à 5

Deux règles complètent le protocole. Une étape validée est rejouable : la procédure et les scripts correspondants sont versionnés dans le dépôt, et un tiers équipé du même module peut la reproduire. Un échec est une donnée : il est publié avec sa cause identifiée, ou marqué comme point ouvert si la cause n’est pas établie.

Résultats au fil de l’eau

À la date de publication de cet article, cette section est vide.

Aucune étape n’est validée sur silicium. Aucun temps de boot, aucune mesure de consommation, aucun comportement matériel n’est connu. La campagne est outillée ; elle n’a pas encore produit de résultats.

Publier cette section vide est un choix de méthode : le protocole précède les mesures, et le lecteur pourra comparer ce qui était annoncé avec ce qui sera constaté. C’est une règle de production de ce blog : les articles d’avancement publient les échecs comme les succès. Les prochains épisodes de ce journal rempliront cette section, étape par étape, dans l’ordre du protocole. Un échec y figurera au même titre qu’un succès, daté et documenté.

Sources

1. NVIDIA, « Jetson AGX Orin, Orin NX, and Orin Nano Boot Flow », Jetson Linux Developer Guide, 2025, https://docs.nvidia.com/jetson/archives/r36.5/DeveloperGuide/AR/BootArchitecture/JetsonOrinSeriesBootFlow.html
2. NVIDIA, « Secure Boot », Jetson Linux Developer Guide, 2025, https://docs.nvidia.com/jetson/archives/r36.4.3/DeveloperGuide/SD/Security/SecureBoot.html
3. OE4T, « meta-tegra : BSP layer for NVIDIA Jetson platforms », 2026, https://github.com/OE4T/meta-tegra
4. Yocto Project, « The Yocto Project », 2026, https://www.yoctoproject.org
5. NVIDIA, « edk2-nvidia : NVIDIA EDK2 platform support », 2026, https://github.com/NVIDIA/edk2-nvidia