jetson-derive-carrier

Personnalisez le portail de première exécution pour toute compétence customize-* sur un carrier personnalisé. Résolvez la cible active selon target-platform-contract.md. Refusez s'il n'y a pas de bloc custom_carrier:, ou si <source.root_path>/Linux_for_Tegra/.git est absent (exécutez jetson-init-source d'abord). Les lignes de création/copie de fichiers modèles se fusionnent en un seul commit overlay-tracker et se copient directement au chemin cible carrier-renommé — les fichiers de référence nommés pristine ne sont jamais indexés (voir Fork plan pour la règle locale, qui remplace la séparation pristine + customization standard du workflow) ; la découverte de la chaîne de conf suit la dispatch conf par carte. Le DTB kernel base n'est pas forké — les deltas du carrier se superposent en tant que DT overlay câblé via OVERLAY_DTB_FILE.

Identifiants (du profil actif) : <chip> depuis reference_devkit.module.id via catalogue (inconnu → avertir, fallback tegra234) ; <module-id>/<module-sku> depuis reference_devkit.module ; <carrier-id>/<carrier-sku> depuis reference_devkit.carrier ; <custom-id>/<custom-sku>/<custom-flash-conf> depuis custom_carrier. <real-conf> = readlink <bsp_image.root_path>/Linux_for_Tegra/<reference_devkit.flash_config> (convention NVIDIA <devkit>.conf → <carrier>-<module>-a<rev>.conf ; avertir + traiter le niveau supérieur comme real + ignorer la ligne symlink-wrapper si ce n'est pas un symlink).

<custom-id> est un token de carte carrier personnalisée, pas nécessairement un ID NVIDIA-style pNNNN. Utilisez-le tel quel dans les noms de fichiers en dash-form et les chaînes DT compatible. Quand une famille de fichiers cible utilise des tokens numériques sans p, dérivez <custom-id-file-token> comme NNNN seulement si <custom-id> correspond à ^p[0-9]{4}$ ; sinon utilisez <custom-id> inchangé. Ne refusez pas les IDs carrier personnalisés simplement parce qu'ils ne commencent pas par p.

Instructions

Le fork plan ci-dessous est l'ensemble d'instructions : une passe de découverte, puis un fork ligne par ligne du fileset par-carte, gated par l'aperçu du message de commit avant chaque git commit.

Fork plan

Chaque git commit produit par cette compétence — dans l'overlay tracker (Linux_for_Tegra/) ou le repo source hardware/ — passe par la gate d'aperçu du message de commit. Affichez la liste des fichiers indexés + le message proposé à l'opérateur et exigez accept / edit / cancel avant chaque git commit ; en cas de cancel laissez l'index indexé pour résolution manuelle.

Matérialisez les forks renommés même quand les octets ne changent pas. Pour chaque ligne fork-plan acceptée, créez et suivez le chemin cible carrier personnalisé ; ne sautez pas une cible manquante parce que le fork n'est qu'un rename/copy ou est identique en octets à la référence. Cela inclut les forks BCT comme pinmux, GPIO/GPIOINT, padvoltage/PMC, misc, et MB2 misc. Sautez seulement quand la colonne Acceptance le permet, la source est un warn-and-skip miss explicite, ou le chemin cible attendu est déjà suivi ; dans ce dernier cas, rapportez-le comme déjà dérivé et ne créez pas de commit vide.

Les lignes de création/copie de fichiers modèles se fusionnent en un seul commit overlay-tracker, et les fichiers pristine nommés par référence ne sont jamais indexés. Toutes les lignes qui matérialisent un nouveau fichier (dérivé du modèle) dans l'overlay tracker — flash-conf de la carte, symlink flash-conf, MB1 BCT (pinmux, GPIO/GPIOINT, padvoltage/PMC, misc), MB2 BCT (misc), BPMP DTB (si opt-in), nvpmodel, nvfancontrol — se copient directement de <bsp_image.root_path>/Linux_for_Tegra/<rel>/<reference-name> à <source.root_path>/Linux_for_Tegra/<rel>/<custom-name> avec tout édits de contenu appliqués avant indexation. Le nom de référence (<carrier-id>-<carrier-sku>-keyed) n'est jamais indexé ou committé dans l'overlay tracker — seul le fichier custom-carrier-renommé est suivi. Cela remplace la séparation pristine + customization standard de commit batching. Toutes ces lignes se regroupent en un seul commit overlay-tracker qui ajoute : (i) les fichiers custom-carrier-nommés à leurs chemins cibles avec contenu déjà appliqué, (ii) le symlink flash-conf, et (iii) les réécritures de contenu flash-conf ciblées à l'intérieur du flash-conf renommé pour PINMUX_CONFIG / GPIO_CONFIG / GPIOINT_CONFIG / PMC_CONFIG / MISC_CONFIG / MB2_BCT (plus BPFDTB_FILE quand BPMP DTB est opt-in). Les lignes qui éditent des fichiers upstream existants au lieu de créer des modèles — le patch nvpower.sh — et le câblage overlay (OVERLAY_DTB_FILE+= append au fork flash-conf tout juste créé, traité comme une phase temporellement distincte selon commit batching) restent des commits séparés selon leurs propres lignes. Le squelette DT overlay se committe dans bsp_sources/hardware/, pas l'overlay tracker, donc il n'est pas affecté. La gate d'aperçu du message de commit se déclenche une fois sur le commit fusionné ; les lignes warn-and-skipped ne contribuent pas, et si chaque ligne du bundle est déjà suivie le commit est complètement omis.

Découverte (passe unique fusionnée)

Exécutez une passe de découverte unique ; n'entrelacez pas avec l'indexation. Ne tronquez pas les listes — chaque nom de fichier candidat dans chaque répertoire scanned doit être visible au matcher. head, tail, | head -N, | tail -N, et tout autre filtre limitant les lignes sont hors limites pour cette étape ; utilisez ls -1 / find non clippés, ou grep sur la sortie complète. La troncature risque de fausses appels warn-and-skip quand le fichier correspondant se trouve après la coupure. Capturez :

• Variables Flash-conf : DTB_FILE / TBCDTB_FILE / BPFDTB_FILE / PINMUX_CONFIG / PMC_CONFIG / GPIO_CONFIG / GPIOINT_CONFIG. DTB_FILE / TBCDTB_FILE sont capturés pour référence seulement afin que le câblage overlay puisse dériver <dtb-stem> pour le nom du fichier overlay — ils ne sont jamais réécrits par cette compétence.
• BCT .dts à bootloader/generic/BCT/ ; les frères .dtsi vivent un niveau au-dessus à bootloader/ — PAS à côté.
• nvpmodel : nvpmodel_<module-id>_<module-sku>*.conf. nvfancontrol : nvfancontrol_<module-id>_<module-sku>_<carrier-id>_<carrier-sku>.conf.
• Ancrages nvpower.sh pour (a)–(d) : branche <carrier-id> cvb, SKU elif <module-id>-<module-sku>, cascade nvpmodel tegra<chip>, cascade nvfancontrol tegra<chip>.

¶ Suivi #include. Scannez chaque .dts capturé pour les directives #include "..." n'importe où dans le fichier (les BSP NVIDIA les mettent à l'intérieur des corps de nœud BCT) ; les includes carrier-keyed rejoignent la liste de fork. Arrêtez-vous à un niveau.

† Règle rename. Source carrier-keyed (p. ex. …-p3834-xxxx-p4071-0000.dts) → substitution de nom <carrier-id>-<carrier-sku> → <custom-id>-<custom-sku> ; réécrivez la variable flash-conf (p. ex. PINMUX_CONFIG) au nom renommé dans le même commit customization. La portion module est préservée verbatim à partir du pristine — si pristine a p3834-xxxx, fork garde p3834-xxxx ; si pristine a p3834-0008, fork garde p3834-0008. Ne pincez jamais module-SKU vous-même. Même règle pour tout autre wildcard xxxx en position carrier-SKU quand pristine l'utilise (p. ex. p4071-xxxx → p1234-xxxx). Source module-keyed (p. ex. …-p3767-dp-a03.dtsi) → ajoutez _<custom-id-file-token>_<custom-sku> (forme underscore) ou -<custom-id>-<custom-sku> (forme dash) plus un commit extra sur fork flash-conf réécrivant la variable (p. ex. PINMUX_CONFIG) au nom suffixé. Contenu jamais substitué par défaut ; invitez si le contenu tient une auto-référence littérale carrier-id-sku.

‡ Squelette overlay. DT plugin overlay (/plugin/;) avec un fragment@0 à target-path = "/" ; à l'intérieur de __overlay__ définissez model = "<custom_carrier.name> carrier board" et compatible = "nvidia,<custom-id>-<custom-sku>+<module-id>-<module-sku>", "nvidia,<chip>". L'affinement de machine nvpower.sh lit compatible.

Vérification de l'édition

Re-grep après chaque sed / patch. sed ne fait silencieusement rien en cas de miss ; le code de sortie 0 ne prouve rien. Remplacements multi-lignes : utilisez str.replace(old, new) Python, pas sed multi-lignes (fragile à la dérive d'espaces, ne-ops silencieux). Refusez de committer en cas d'échec de vérification.

Résumé. Affichez les forks par repo (décompte + SHAs des commits), décision BPMP-DTB, lignes warn-and-skipped (fichier source obligatoire manquant sur ce BSP — ne faites pas échouer l'exécution), chemin overlay écrit.

Exemples

Phrases de déclenchement que l'opérateur pourrait utiliser :

derive custom carrier
bootstrap custom carrier
fork carrier board from reference devkit

Bloc custom_carrier: minimal dans le profil actif que la compétence s'attend à trouver :

custom_carrier:
  id: p1234            # any token; need not be NVIDIA pNNNN style
  sku: 0000
  flash_config: p1234.conf
  name: Acme Custom Carrier

Objectif

Personnalisez le fileset par-carte pour une nouvelle carte carrier afin que les compétences customize-* en aval, nvpower.sh, et la chaîne de boot atterrissent sur la carte carrier personnalisée au lieu du devkit de référence. Le DTB de base reste à la référence ; les deltas du carrier vivent dans un overlay DT pour qu'une re-dérivation par rapport à une nouvelle BSP de référence n'ait besoin que de re-exécuter cette compétence.

Prérequis

• Profil actif résolu selon target-platform-contract.md avec un bloc custom_carrier: (id, sku, flash-conf, nom amical).
• source.root_path/Linux_for_Tegra/.git initialisé — exécutez /jetson-init-source d'abord ; cette compétence refuse si l'overlay tracker est absent.
• bsp_image.root_path peuplé par /jetson-init-image afin que le symlink flash-conf de référence puisse être résolu.
• reference_devkit: peuplé (module + carrier) afin que la règle rename ait les tokens carrier-id/sku à substituer.

Limitations

• Le DTB kernel de base et sa source DTS ne sont pas forkés — les deltas du carrier doivent se superposer via l'overlay DT câblé par OVERLAY_DTB_FILE.
• Le fork BPMP DTB est opt-in (désactivé par défaut). La plupart des swaps carrier partagent le BPMP DTB de référence ; opt-in seulement quand la topologie de puissance/horloge de la carte diverge.
• La substitution de contenu flash-conf est ciblée, non générale. Les vars dont les fichiers cette compétence ne forke pas (DTB_FILE, TBCDTB_FILE, SCR_CONFIG, PMIC_CONFIG, DEVICEPROD_CONFIG, PROD_CONFIG, MINRATCHET_CONFIG, UPHY_CONFIG, OVERLAY_DTB_FILE+= dynamique) restent aux valeurs de référence — les réécrire les pointerait vers des fichiers qui n'existent pas.
• Les IDs carrier personnalisés n'ont pas besoin de suivre le style NVIDIA pNNNN ; le token numérique sans p est dérivé seulement quand l'ID correspond à ^p[0-9]{4}$.
• Ne personnalise pas les fichiers au niveau du module. Utilisez la compétence jetson-customize-* appropriée pour pinmux, horloges, courbes de ventilateur, nvpmodel, PCIe, UPHY, USB, MGBE, ou deltas caméra.

Dépannage

• Refuse avec "no custom_carrier: block" — déclarez le bloc dans le profil actif avant re-exécution ; la compétence ne l'inférera pas.
• Refuse avec ".git absent dans Linux_for_Tegra/" — overlay tracker non initialisé. Exécutez /jetson-init-source d'abord.
• "<real-conf> n'est pas un symlink" — la convention NVIDIA est un symlink <devkit>.conf vers <carrier>-<module>-a<rev>.conf ; si le niveau supérieur est la conf réelle, la compétence avertit, la traite comme réelle, et saute la ligne symlink-wrapper. Pas une erreur.
• sed a rapporté succès mais l'édition manque — sed ne fait silencieusement rien en cas de miss. La compétence re-greps après chaque patch et refuse de committer en cas d'échec de vérification ; pour les remplacements multi-lignes passez à str.replace Python.
• "chip: unknown" / fallback vers tegra234 — l'ID module n'est pas dans le catalogue ; mettez à jour le catalogue plutôt que d'override dans le profil.
• La demande d'aperçu du message de commit bloque l'exécution — gate attendue selon commit-batching ; acceptez, éditez, ou annulez. En cas d'annulation, l'index est laissé indexé pour résolution manuelle.
• Un fichier source obligatoire manque sur ce BSP — la ligne est enregistrée comme warn-and-skipped dans le résumé ; le reste de l'exécution se complète quand même.