Jetson carrier board : Orin NX, PCIe et démarrage UEFI

Une carrier board Jetson est le circuit imprimé qui accueille un module NVIDIA Jetson et en fait un produit. Sur un projet récent de carrier board Jetson, le support de boot était un périphérique PCIe que le firmware UEFI ne prend pas en charge, et le faire démarrer a demandé beaucoup de travail. Notre conseil depuis est simple : choisissez un support de boot de la liste supportée par NVIDIA.

Contrairement à l'idée reçue, la partie difficile d'une carrier board Jetson Orin NX est rarement le routage ; c'est le chemin de boot et le logiciel qui doit décrire votre carte. Chez AESTECHNO, bureau d'études électronique à Montpellier, nous concevons des carrier boards et le Linux embarqué qui tourne dessus. Ce guide couvre ce que le module apporte, les supports de boot gérés par l'UEFI, les cinq éléments que NVIDIA demande de modifier pour une carte sur mesure, notre méthode, une matrice de décision et le retour terrain. Pour la plateforme elle-même, commencez par notre guide des processeurs NVIDIA Jetson pour l'IA embarquée.

Ce qu'est une carrier board Jetson

Une carrier board Jetson est la carte sur laquelle s'enfiche un système sur module NVIDIA Jetson. Le module porte le système sur puce Orin, sa mémoire LPDDR5 et sa gestion d'alimentation ; la carrier board fournit l'alimentation d'entrée, le stockage, les connecteurs, les caméras, le réseau et l'interface physique avec le reste du produit.

Les Orin NX et Orin Nano partagent un même format. D'après le tableau de spécifications de la page produit Jetson Orin de NVIDIA, ces modules utilisent le même connecteur SO-DIMM 260 broches et mesurent 69,6 mm sur 45 mm. NVIDIA indique que la carrier board de référence du kit de développement Orin Nano Super est compatible avec tous les modules Orin NX et Orin Nano : une carte conçue pour cette famille peut donc accueillir l'un ou l'autre. C'est utile quand la charge d'inférence d'edge AI n'est pas encore figée : la même carte peut sortir avec un module plus petit ou plus gros, et ce choix peut suivre les prix.

Le kit de développement est lui aussi une carrier board

Le kit de développement est un module monté sur la carrier board de NVIDIA. Dans la nomenclature NVIDIA, le kit Orin Nano P3766 associe le module P3767 et la carrier board P3768, et chacun des deux contient une EEPROM avec son identifiant de carte. Tout le board support package Jetson Linux est réglé pour ce couple. À l'inverse d'un kit de développement, une carte sur mesure est inconnue du logiciel tant que vous ne l'avez pas décrite, et c'est l'objet des sections suivantes.

Pourquoi les produits finissent sur une carrier board sur mesure

Une carrier board sur mesure est la réponse habituelle quand un kit de développement ou une carte du commerce ne correspond pas au boîtier, aux connecteurs, à l'alimentation ou à la cible de certification d'un vrai produit. Une carte sur mesure garde le module, qui est la partie chère et difficile, et ne change que ce dont le produit a besoin.

La disponibilité des modules justifie l'effort. La page de cycle de vie des produits Jetson annonce les Orin NX 16GB, Orin NX 8GB, Orin Nano 8GB et Orin Nano 4GB disponibles jusqu'en janvier 2032, ce qui laisse le temps d'amortir une carte dédiée. Le compromis est celui que nous avons décrit dans notre comparatif entre électronique COTS et sur mesure : le module reste sur étagère, la carte qui le reçoit est la vôtre. Nous avons appliqué exactement ce partage sur un projet COM Express, où la carte du commerce était 30 mm trop longue pour la mécanique et consommait trop, et nous avons conçu une carrier board sur mesure à la place.

Le prix du module suit le marché de la mémoire

Un module ne protège pas un produit du prix de la mémoire. Sur un projet Jetson Orin NX, la pénurie de mémoire 2025-2026 a fortement augmenté le coût de la RAM et du stockage NVMe pour notre client, et le prix des modules Jetson a augmenté en conséquence. Notre article sur la pénurie de mémoire 2026 et les produits embarqués détaille cette exposition. Pour la carrier board, cela plaide pour une empreinte qui accepte plusieurs variantes de module et pour ne pas surdimensionner le SSD NVMe.

Ce que l'Orin NX et l'Orin Nano apportent à la carrier board

La principale différence pour la carte porteuse est la génération PCIe, la plage de puissance et la taille mémoire, puisque l'Orin NX et l'Orin Nano partagent un connecteur et un encombrement. L'Orin NX gère le PCIe jusqu'en Gen4 et l'Orin Nano jusqu'en Gen3, selon le guide de bring-up de NVIDIA, et aucun des deux n'a de stockage interne : la carrier board doit le fournir.

La page produit Jetson Orin de NVIDIA présente l'Orin NX en versions 16 Go et 8 Go, jusqu'à 100 TOPS entre 10 W et 25 W dans ses modes de puissance d'origine, et l'Orin Nano en versions 8 Go et 4 Go, jusqu'à 40 TOPS entre 7 W et 15 W. Le tableau de spécifications de la même page ajoute des modes de puissance plus élevés : jusqu'à 40 W pour l'Orin NX et jusqu'à 25 W pour l'Orin Nano, les modes qui correspondent aux 157 et 67 TOPS annoncés sur la page des modules Jetson de NVIDIA. Pour le concepteur de la carte, la plage de puissance compte plus que les TOPS : dimensionnez l'étage d'entrée, le chemin thermique et le boîtier pour le mode le plus élevé que le produit pourra activer, pas pour celui avec lequel il sort.

Les lignes UPHY sont partagées : planifiez-les d'abord

Les lignes haute vitesse du module ne sont pas toutes indépendantes. Le guide NVIDIA prévient que tous les ports ne sont pas utilisables, car PCIe, UFS et USB (XUSB) se partagent les lignes UPHY, et que les lignes USB SuperSpeed sont affectées aux lignes 0 à 2 de l'UPHY0 sur le module P3767. La configuration retenue se règle côté logiciel par la variable ODMDATA, et certains choix coûtent du débit : la configuration hsio-uphy-config-40 limite un port racine PCIe à la Gen2. Dans notre pratique, le plan de lignes est figé avant le schéma, avec les largeurs et générations de liens PCI Express dont chaque endpoint a besoin.

Supports de boot : en choisir un que le firmware UEFI gère

Le support de boot d'une carrier board Jetson Orin est le stockage depuis lequel le firmware UEFI charge le système d'exploitation. Le guide Jetson Linux de NVIDIA précise que « OS boot is supported from eMMC/SD/UFS/NvME/USB », le boot USB étant réservé à la génération Orin. Hors de cette liste, le firmware n'a aucun pilote pour lire le périphérique, quoi que Linux sache faire ensuite.

L'UEFI est, selon l'article Wikipedia sur l'UEFI, une spécification de l'architecture du firmware d'une plateforme informatique, propriété de l'UEFI Forum. Sur Jetson, le chapitre UEFI du Jetson Linux Developer Guide explique que l'UEFI a remplacé l'ancien bootloader CBoot à partir de la release 34, et que L4tLauncher est son chargeur d'OS par défaut. Par défaut, l'UEFI lit ensuite le noyau et le device tree indiqués dans le fichier extlinux.conf du système de fichiers racine.

Pourquoi un pilote Linux ne suffit pas

Contrairement à l'idée reçue selon laquelle tout périphérique doté d'un pilote Linux peut porter le système de fichiers racine, le firmware doit lire le support de boot avant que le noyau et ses pilotes soient chargés. En UEFI, la prise en charge des périphériques au boot vient des pilotes UEFI, que l'article Wikipedia situe dans la phase DXE, où « UEFI drivers / Option ROMs of PCI / AMBA devices are executed ». Un périphérique PCIe pour lequel le firmware n'a pas de pilote est invisible à ce stade, même s'il fonctionne parfaitement une fois Linux lancé.

L'ordre de boot et la priorité aux supports amovibles

L'ordre de boot compte aussi sur un produit. Selon NVIDIA, les supports amovibles (SD et USB) passent avant les supports fixes (eMMC, NVMe, UFS) dans l'ordre par défaut. On peut fixer cet ordre avec la variable DefaultBootPriority du fichier L4TConfiguration.dts, qui, note NVIDIA, « only sets the default boot order on the first boot after flashing », ou avec un overlay de flashage comme BootOrderNvme.dtbo. Sur un produit de terrain doté d'un port USB de maintenance, nous recommandons de figer l'ordre pour qu'une clé USB oubliée ne change pas ce qui démarre. NVIDIA recommande aussi fortement de désactiver le shell UEFI sur les produits de série.

Ce que NVIDIA demande de modifier pour une carte sur mesure

Le board support package est le logiciel qui doit décrire une carrier board sur mesure, et NVIDIA liste précisément ce qui y change. Le guide d'adaptation et de bring-up des modules Orin NX et Orin Nano indique qu'avant d'utiliser le module avec une carte autre que la P3768, il faut modifier le device tree du noyau, les configurations MB1 et MB2, les données ODM et la configuration de flashage.

Chacun des cinq éléments correspond à une décision matérielle. Le pinmux vient du tableur pinmux Orin NX et Orin Nano de NVIDIA, adapté à la carte, qui génère les fichiers de pinmux, de GPIO et de tension des pads utilisés par MB1 et le bootloader. Le device tree décrit la carte à Linux ; la documentation du noyau sur le devicetree le définit comme « a data structure and language for describing hardware », nécessaire pour les périphériques « which cannot be detected by hardware ». ODMDATA choisit la configuration des lignes UPHY. MB2 gère l'EEPROM de carte, qui est optionnelle. La configuration de flashage relie le tout dans un fichier .conf propre à la carte.

Flasher une carte sur mesure : gardez un port USB en mode device

Le flashage en production est une exigence matérielle autant que logicielle. Le chapitre de NVIDIA sur le flashage indique que la méthode officielle pour l'Orin NX et l'Orin Nano est le flashage initrd, que les systèmes de production doivent l'utiliser pour que les mises à jour à distance fonctionnent, et que sur une carte sur mesure il faut « ensure that a USB device mode has been enabled ». Il précise aussi que le flashage initrd est validé sur le kit de développement. Une carte sans port USB en mode device accessible, ni moyen de passer le module en mode recovery, est une carte que l'on ne peut pas flasher sur la ligne de production.

Notre méthode pour une carrier board Jetson, étape par étape

Notre méthode est une séquence en sept étapes qui part du chemin de boot et du plan de lignes, puis passe au schéma, au stack-up, au routage, au bring-up et à la validation. L'ordre compte : les deux décisions les plus difficiles à changer après le premier prototype, quel support démarre et quelles lignes vont où, sont prises en premier.

L'étape un est la liste des interfaces et le plan de lignes face aux options UPHY de NVIDIA. L'étape deux est le support de boot, choisi dans la liste UEFI. L'étape trois est le schéma, à partir du guide de conception et du tableur pinmux de NVIDIA, dessiné sous Altium. L'étape quatre est le stack-up : nous calculons les impédances sous ANSYS et Simbeor, puis nous les recoupons avec le calcul Polar SI9000 du fabricant de PCB, comme dans notre guide du stack-up et de l'impédance PCB. L'étape cinq est le routage des paires PCIe, USB 3.2 et MIPI CSI-2 selon nos règles de conception PCB haute vitesse. L'étape six est le bring-up avec le board support package.

Validation : conformité PCIe et pré-scan CEM

La validation est l'étape sept, avec sa propre procédure de test. Dans notre laboratoire, les liens PCIe sont vérifiés avec un oscilloscope Tektronix et la suite de conformité TekExpress, qui mesure les diagrammes de l'œil et aide à régler l'égalisation, comme l'explique notre article sur le diagramme de l'œil et le jitter. La CEM est vérifiée par un pré-scan interne avant le laboratoire accrédité. Dans l'UE, la directive CEM 2014/30/UE limite les émissions et fixe des exigences d'immunité, et une carte aux connecteurs USB et Ethernet exposés passera l'essai d'immunité aux décharges électrostatiques IEC 61000-4-2, dont l'IEC a remplacé l'édition 2008 par une édition 2025.

Retour terrain : démarrer depuis un périphérique PCIe hors de la liste UEFI

Ce retour terrain est le cas d'une carrier board Jetson qui devait démarrer depuis un périphérique PCIe que le firmware UEFI ne prend pas en charge. Sur un projet récent, nous l'avons fait fonctionner, mais cela a demandé beaucoup de travail, et notre recommandation depuis est de ne pas tenter l'expérience : choisissez un support de boot que le firmware gère. La solution est confidentielle : ce retour terrain ne décrit pas comment nous avons fait et ne nomme pas le périphérique.

Ce que nous pouvons partager, c'est pourquoi ce type de problème est difficile et comment l'éviter. Un périphérique PCIe peut être parfaitement utilisable une fois Linux lancé ; la difficulté est la minute d'avant, quand seul le firmware est aux commandes et qu'il lui faut son propre moyen de lire le périphérique. Contrairement à ce que suggère un coup d'œil au schéma de principe, « démarrer depuis ce périphérique PCIe » n'est pas une fonction mais deux : un chemin de données pour Linux, et un chemin de boot pour l'UEFI. Le chemin de données relève du routage et des pilotes. Le chemin de boot relève du support firmware, et chaque heure passée hors de la liste NVIDIA est une heure de moins sur le produit.

La moitié logicielle : un BSP Yocto sur mesure sur Orin NX

Le board support package est l'autre moitié de chaque carrier board. Au Q1 2026, nous avons livré un projet Jetson Orin NX avec un BSP entièrement personnalisé, développé sous Yocto : layers personnalisés, configuration du noyau, device tree et système de fichiers racine. Sur une carte sur mesure, les cinq éléments listés par NVIDIA relèvent exactement de ce type de travail. Dans notre pratique, le planning d'un projet de carrier board Jetson dépend autant de ce logiciel que du PCB, et c'est pourquoi nous préparons le bring-up dès la première revue de schéma. Notre comparatif des distributions Linux embarqué explique quand Yocto vaut son coût.

Ce que nous recommandons après ces projets

Nous recommandons de faire du support de boot une ligne du cahier des charges, revue en pensant au firmware, et non une conséquence du choix de stockage. Malgré l'intérêt de réutiliser un périphérique de stockage que le produit possède déjà, gardez le boot sur NVMe, eMMC, SD, UFS ou USB, et laissez Linux monter tout autre périphérique PCIe comme donnée après le boot. Même si le NVMe sur un slot M.2 clé M est la réponse habituelle, vérifiez le périphérique exact sur la release firmware visée, tôt, dès le premier prototype. Sur ce prototype, nous recommandons une procédure de test qui couvre la conformité PCIe sur TekExpress, l'ordre de boot avec et sans support amovible, et le flashage tel qu'il se fera sur la ligne.

Matrice de décision : kit de développement, carte du commerce ou carte sur mesure

La bonne option est une question de volume, d'intégration mécanique, d'interfaces et de certification, plus que de module. Un kit de développement convient aux prototypes ; une carte du commerce convient aux petites séries dont les interfaces correspondent ; une carte sur mesure convient aux produits dont le boîtier, les connecteurs ou le chemin de boot sortent du catalogue.

Dans notre pratique, la question qui tranche est de savoir si les interfaces et le boîtier du produit existent dans une carte du catalogue, et si cette carte démarre depuis un support géré. Si les deux sont vrais, acheter est plus rapide. Si l'un manque, une carte sur mesure se rentabilise, car adapter une carte du catalogue avec adaptateurs et câbles coûte en général plus en CEM et en fiabilité qu'il ne fait gagner. C'est le même raisonnement que dans notre guide pour choisir entre SoC, SoM, SBC ou sur mesure.

Checklist matérielle avant le premier prototype

Une checklist matérielle est la liste des décisions qu'un premier prototype révélera si elles ont été prises trop tard : plan de lignes, support de boot, accès au flashage, marges d'alimentation et thermiques, connecteurs et EEPROM. Chaque ligne ci-dessous vient soit de la documentation NVIDIA, soit de la pratique générale des carrier boards.

Le stockage d'abord : un slot clé M pour un SSD NVMe, qui selon la spécification M.2 transporte jusqu'à quatre lignes PCIe, au format courant 2280, soit 22 mm de large et 80 mm de long ; notre brochage M.2 clés B, M et E montre les détrompeurs. NVIDIA précise que le disque NVMe doit être branché avant le boot, et que le boot USB fonctionne avec un stockage de masse bulk-only, sans branchement à chaud. Le sans-fil ensuite : un slot clé E fournit du PCIe et de l'USB 2.0 pour une carte Wi-Fi et Bluetooth. Puis l'alimentation : dimensionner l'entrée pour le mode de puissance le plus élevé du plus gros module que la carte peut accueillir, jusqu'à 40 W pour un Orin NX, avec le séquencement et les protections décrits dans notre guide de gestion d'alimentation embarquée.

La checklist en tableau

Caméras, affichage et le reste

Les caméras MIPI CSI-2 sont une raison fréquente de concevoir une carrier board Jetson, car les connecteurs du kit de développement conviennent rarement à un produit. Chaque caméra ajoute une entrée de device tree et une affectation de lignes : la liste des caméras appartient donc au même plan de lignes initial. Pour les câbles longs et les caméras industrielles, notre guide des protocoles vidéo industriels couvre HDMI, SDI et CoaXPress, et notre article sur l'USB 3 couvre les caméras USB et leur routage.

En résumé

Une carrier board Jetson est un chemin de boot, un plan de lignes et un board support package autour d'un module qui fait déjà le travail difficile côté silicium. Décidez ces trois points tôt et le routage devient la partie routinière ; décidez-les tard et ce sont eux qui imposent la nouvelle révision.

• Une empreinte, deux familles. Orin NX et Orin Nano partagent le connecteur SO-DIMM 260 broches et l'encombrement de 69,6 x 45 mm ; routez selon les règles Orin NX si les deux doivent passer.
• Démarrer depuis la liste UEFI. NVIDIA gère le boot de l'OS depuis eMMC, SD, UFS, NVMe et USB sur Orin. Un périphérique PCIe hors de cette liste nous a demandé beaucoup de travail ; nous recommandons de ne pas essayer.
• Planifier les lignes UPHY d'abord. PCIe, USB et UFS se partagent des lignes, et le choix d'ODMDATA doit suivre le schéma.
• Cinq éléments logiciels par carte. Device tree, MB1, MB2, données ODM et configuration de flashage changent pour toute carte autre que la P3768 de NVIDIA.
• Garder un moyen de flasher. Le flashage initrd est la méthode officielle pour l'Orin NX et l'Orin Nano et demande un port USB en mode device sur votre carte.

Pour aller plus loin : les processeurs NVIDIA Jetson pour l'IA embarquée, la pénurie de mémoire 2026 et les produits embarqués, le bus PCI Express, le brochage du connecteur de carte PCIe, l'IA industrielle embarquée, CUDA ou OpenCL pour un projet embarqué, le Cyber Resilience Act et Linux embarqué, la compatibilité électromagnétique, la certification CE RED, les tests et la validation d'un produit électronique, le design for manufacturing, la gestion de l'obsolescence, nos réalisations en calcul embarqué COM Express, notre expertise en conception hardware et notre expertise en firmware embarqué.

Rédigé par Hugues Orgitello, ingénieur en conception électronique avec plus de 10 ans d'expérience, fondateur d'AESTECHNO à Montpellier en 2022.

FAQ : conception d'une carrier board Jetson

Qu'est-ce qu'une carrier board Jetson ?
C'est le circuit imprimé sur lequel s'enfiche un module NVIDIA Jetson. Le module porte le système sur puce Orin et sa mémoire LPDDR5 ; la carrier board fournit l'alimentation, le stockage, les connecteurs, les caméras, le réseau et l'interface physique avec le produit. Les Orin NX et Orin Nano utilisent un connecteur SO-DIMM 260 broches et mesurent 69,6 par 45 mm, donc une même carte peut accueillir l'une ou l'autre famille. Le kit de développement NVIDIA est lui-même un module sur la carte de NVIDIA, la P3768.

Une même carte peut-elle accueillir Orin NX et Orin Nano ?
Oui. NVIDIA indique que la carrier board de référence du kit de développement Orin Nano Super est compatible avec tous les modules Orin NX et Orin Nano, et les deux familles partagent connecteur et encombrement. Des différences demeurent : l'Orin NX gère le PCIe jusqu'en Gen4 et l'Orin Nano jusqu'en Gen3, et leurs plages de puissance diffèrent, jusqu'à 40 W et 25 W dans les modes élevés. Routez les paires haute vitesse selon les règles Orin NX et dimensionnez l'étage d'entrée et le thermique pour le mode le plus élevé du plus gros module.

Depuis quels supports un Jetson Orin peut-il démarrer ?
Le guide Jetson Linux de NVIDIA indique que le boot de l'OS est géré depuis eMMC, SD, UFS, NVMe et USB, le boot USB étant réservé à la génération Orin. Les Orin NX et Orin Nano n'ont pas de stockage interne : un SSD NVMe sur un slot M.2 clé M est le choix habituel sur une carte sur mesure. Les supports amovibles SD et USB passent en tête de l'ordre de boot par défaut, modifiable avec le réglage DefaultBootPriority ou un overlay de flashage.

Un Jetson peut-il démarrer depuis un PCIe non géré ?
Pas sans un travail firmware important. Le firmware UEFI charge le noyau avec ses propres pilotes : un périphérique pour lequel il n'a pas de pilote ne peut pas servir de support de boot, même si Linux le gère ensuite. Sur un projet récent de carrier board Jetson, nous avons fait démarrer un tel périphérique, mais cela a demandé beaucoup de travail et la solution reste confidentielle. Nous recommandons de démarrer depuis NVMe, eMMC, SD, UFS ou USB et de monter l'autre périphérique en donnée.

Que faut-il modifier côté logiciel pour une carte sur mesure ?
Le guide de bring-up NVIDIA pour Orin NX et Orin Nano liste cinq éléments pour toute carte autre que la P3768 : le device tree du noyau, la configuration MB1 avec pinmux, GPIO et tensions des pads, la configuration MB2 avec l'EEPROM de carte optionnelle, les données ODM qui choisissent la configuration des lignes UPHY, et le fichier de configuration de flashage. Dans un build Yocto, ces éléments trouvent leur place dans les layers personnalisés, la configuration du noyau et le device tree du board support package.