jetson-init-image

Par nvidia · skills

Extrait les archives Jetson Linux + sample-rootfs et exécute `apply_binaries.sh` pour la cible active, puis enregistre `bsp_image` dans le profil. À utiliser après `jetson-init-target` ; pas pour la configuration de l'arborescence source.

npx skills add https://github.com/nvidia/skills --skill jetson-init-image

Initialiser l'image BSP

La sortie ne contient que bsp_image: dans le profil actif : version dérivée plus root_path uniquement lors du remplacement de <workspace>/Image.

Quand invoquer

  • L'utilisateur demande d'extraire, préparer ou initialiser l'image BSP.
  • Une skill aval signale l'absence de <bsp_image.root_path>/Linux_for_Tegra/.
  • Le profil actif n'a pas encore de bloc bsp_image:.

Procédure

Résoudre la cible et le chemin d'image

Résoudre le profil actif selon ../../context/target-platform-contract.md. Refuser s'il n'y a pas de profil actif ou si reference_devkit: est absent.

<workspace> est le parent du répertoire target-platform/ du profil actif. <bsp_image.root_path> par défaut à <workspace>/Image.

État du profil Action
bsp_image.root_path existe L'utiliser sans demander.
bsp_image: existe sans root_path Utiliser <workspace>/Image.
Pas de bloc bsp_image: Demander une fois : Entrée pour la valeur par défaut ou chemin d'override absolu.

Pour un override, valider que le parent existant le plus proche est inscriptible. Omettre root_path quand la valeur par défaut est utilisée.

Déterminer la pile GPU

Utiliser l'invariant GPU-driver partagé de ../../context/target-platform-contract.md. Dériver la pile attendue de reference_devkit.module.id et du catalogue :

Famille de puces IDs de modules Pile Flag apply_binaries.sh
T234 / Orin p3701, p3767 nvgpu aucun
T264 et plus récent / Thor+ p3834 OpenRM --openrm

Refuser les IDs de modules inconnus. Le flag --openrm n'est valide que sur les versions BSP qui livrent la pile OpenRM ; si le BSP actif n'expose pas le flag, l'omettre indépendamment de ce que la cible souhaite.

Réutiliser ou extraire

Si <bsp_image.root_path>/Linux_for_Tegra/ existe déjà :

  1. Ne pas extraire dessus à moins que l'utilisateur n'ait explicitement demandé une réextraction et accepté le risque de remplacement.

  2. Dériver la version sur disque de Linux_for_Tegra/nv_tegra_release. Demander avant de remplacer une autre bsp_image.version enregistrée.

  3. Vérifier la pile GPU installée par rapport à l'attente dérivée de la plateforme quand possible. Ordre de détection (la première sonde qui donne une réponse définitive gagne) :

    1. Linux_for_Tegra/rootfs/etc/nv_tegra_release porte un token INSTALL_TYPE= sur les versions BSP qui l'exposent (lignes plus récentes). Lire et comparer directement.
    2. Sinon, find Linux_for_Tegra -name nvgpu.ko : présent → nvgpu, absent → OpenRM.
    3. Si la famille de puces n'a jamais livré qu'une pile (par ex. T234 / Orin est toujours nvgpu dans les BSPs actuels), revenir à l'attente dérivée du catalogue sans sondage disque.

Si la pile installée entre en conflit avec la cible active, refuser et demander à l'utilisateur de réextraire avec la bonne pile ou corriger le profil cible. Sinon ignorer l'extraction et mettre à jour le profil.

Localiser les tarballs

Quand l'extraction est nécessaire, chercher :

  1. <bsp_image.root_path>/
  2. <workspace>/
  3. répertoire de travail actuel

Demander des chemins absolus pour tout ce qui manque. Noms de fichiers requis :

  • Jetson_Linux_R<ver>_aarch64.tbz2
  • Tegra_Linux_Sample-Root-Filesystem_R<ver>_aarch64.tbz2

Les deux noms de fichiers doivent contenir le même token R<ver>. Refuser les incompatibilités et enregistrer <ver> comme bsp_image.version. Ne pas télécharger les tarballs.

Extraire et appliquer les binaires

Utiliser les chemins absolus des tarballs ; ils peuvent se trouver en dehors de <bsp_image.root_path>.

ROOT="<bsp_image.root_path>"
BSP_TARBALL="<absolute path to Jetson_Linux_R<ver>_aarch64.tbz2>"
ROOTFS_TARBALL="<absolute path to Tegra_Linux_Sample-Root-Filesystem_R<ver>_aarch64.tbz2>"

mkdir -p "$ROOT"
tar xjf "$BSP_TARBALL" -C "$ROOT"
sudo tar xpjf "$ROOTFS_TARBALL" -C "$ROOT/Linux_for_Tegra/rootfs"

cd "$ROOT/Linux_for_Tegra"
if [ "$GPU_STACK" = "openrm" ]; then
  sudo ./apply_binaries.sh --openrm
else
  sudo ./apply_binaries.sh
fi

Définir GPU_STACK d'après l'étape « Déterminer la pile GPU » ci-dessus. Arrêter à la première commande qui échoue et afficher la commande ayant échoué.

Mettre à jour le profil actif

Persister les métadonnées d'image BSP résolues dans le profil cible actif afin que les skills ultérieures puissent trouver le BSP sans redemander. Préserver les blocs existants, les commentaires et les valeurs SKU entre guillemets ; utiliser un writer YAML capable de round-tripping comme ruamel.yaml.

bsp_image:
  root_path: <absolute override path>  # omettre pour <workspace>/Image
  version: "<derived version>"

Règles :

  • Même version et même chemin racine : pas de réécriture.
  • Version différente : demander avant de mettre à jour.
  • root_path enregistré différent : refuser la réécriture automatique.
  • Toujours citer version.

Terminer

Rapporter le chemin d'image, l'état extrait ou réutilisé, la pile GPU, la version dérivée et le statut de mise à jour du profil. Ensuite, suggérer /jetson-init-source.

Objectif

Matérialiser Linux_for_Tegra/ sur disque en extrayant les bons tarballs Jetson Linux + sample-rootfs et en exécutant apply_binaries.sh avec le flag de pile GPU dérivé de la cible active (nvgpu pour T234, OpenRM pour T264+). Ensuite, valider la version BSP dérivée dans le bloc bsp_image: du profil.

Prérequis

  • Profil cible actif résolu selon ../../context/target-platform-contract.md.
  • Tarball BSP Jetson Linux et tarball sample-rootfs correspondante préparées sur disque (par ex. via /jetson-download-bsp ou placées manuellement).
  • Accès en écriture à la racine Image/ du workspace (ou à la bsp_image.root_path override).
  • sudo disponible pour apply_binaries.sh.

Limitations

  • N'écrit que le bloc bsp_image: ; l'arborescence source, les documents et le profil carrier sont gérés par les skills sœurs.
  • Refuse de remplacement d'un Linux_for_Tegra/ existant sans direction utilisateur explicite.
  • Ne télécharge pas les tarballs ; s'appuyer sur /jetson-download-bsp ou préparer manuellement les entrées.

Dépannage

  • apply_binaries.sh se termine avec un code non nul — relire sa sortie console ; la plupart des échecs sont dus à un sudo manquant, une tarball rootfs manquante, ou un flag de pile GPU incorrect pour la génération SoC.
  • nv_tegra_release absent après extraction — l'extraction s'est arrêtée prématurément ; vérifier l'intégrité de la tarball et réexécuter.
  • version enregistrée en désaccord avec le nom de fichier tarball — la tarball a été renommée ; faire confiance à la valeur analysée de Linux_for_Tegra/nv_tegra_release plutôt qu'aux noms de fichiers.
  • root_path différent enregistré déjà dans le profil — refuser et demander à l'utilisateur de confirmer avant de remplacement.

Références

Skills similaires