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à :
-
Ne pas extraire dessus à moins que l'utilisateur n'ait explicitement demandé une réextraction et accepté le risque de remplacement.
-
Dériver la version sur disque de
Linux_for_Tegra/nv_tegra_release. Demander avant de remplacer une autrebsp_image.versionenregistrée. -
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) :
Linux_for_Tegra/rootfs/etc/nv_tegra_releaseporte un tokenINSTALL_TYPE=sur les versions BSP qui l'exposent (lignes plus récentes). Lire et comparer directement.- Sinon,
find Linux_for_Tegra -name nvgpu.ko: présent → nvgpu, absent → OpenRM. - 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 :
<bsp_image.root_path>/<workspace>/- répertoire de travail actuel
Demander des chemins absolus pour tout ce qui manque. Noms de fichiers requis :
Jetson_Linux_R<ver>_aarch64.tbz2Tegra_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_pathenregistré 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-bspou placées manuellement). - Accès en écriture à la racine
Image/du workspace (ou à labsp_image.root_pathoverride). sudodisponible pourapply_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-bspou préparer manuellement les entrées.
Dépannage
apply_binaries.shse termine avec un code non nul — relire sa sortie console ; la plupart des échecs sont dus à unsudomanquant, une tarball rootfs manquante, ou un flag de pile GPU incorrect pour la génération SoC.nv_tegra_releaseabsent 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.versionenregistrée en désaccord avec le nom de fichier tarball — la tarball a été renommée ; faire confiance à la valeur analysée deLinux_for_Tegra/nv_tegra_releaseplutôt qu'aux noms de fichiers.root_pathdifférent enregistré déjà dans le profil — refuser et demander à l'utilisateur de confirmer avant de remplacement.