Modifier le mode d'alimentation nvpmodel (côté BSP)

Objectif

Éditer la configuration nvpmodel par carte pour que l'appareil démarre avec le mode d'alimentation souhaité, les pinces CPU/GPU/EMC/TPC et le mode par défaut. Côté BSP uniquement — toutes les écritures aboutissent dans le suivi de superposition, la copie bsp_image en amont est en lecture seule.

Cette compétence gère les éditions côté BSP du fichier de configuration nvpmodel par carte : ajouter des modes, supprimer des modes, éditer les pinces CPU/GPU/EMC/TPC et modifier le démarrage par défaut. S'applique sur les plates-formes Jetson / Tegra (T234 Orin, T264 Thor).

Format de fichier (canonique, selon l'en-tête du fichier BSP)

# 1. définitions PARAM — déclarer les commandes nommées et leurs chemins sysfs
< PARAM TYPE=FILE  NAME=<param_name> >
<arg_name> </absolute/sysfs/path>
...
< PARAM TYPE=CLOCK NAME=<param_name> >
FREQ_TABLE        </sysfs/.../available_frequencies>
MAX_FREQ          </sysfs/.../max_freq>
MIN_FREQ          </sysfs/.../min_freq>
FREQ_TABLE_KNEXT  </sysfs/.../available_frequencies>     # kernel-NEXT variant
MAX_FREQ_KNEXT    </sysfs/.../max_freq>
MIN_FREQ_KNEXT    </sysfs/.../min_freq>

# 2. définitions POWER_MODEL — un bloc par profil
< POWER_MODEL ID=<int> NAME=<string> >
PARAM_NAME ARG_NAME <value>
...

# 3. PM_CONFIG — obligatoire ; sélectionne le démarrage par défaut
< PM_CONFIG DEFAULT=<id> >

Règles :

• Pour TYPE=FILE, <value> est une chaîne (0, 1, on, auto, …).
• Pour TYPE=CLOCK, <value> est un entier (Hz pour les horloges, entier brut pour les masques).
• -1 pour une valeur CLOCK signifie INT_MAX (pas de limite).
• La ligne d'en-tête < … > doit commencer à la colonne 0 avec un espace après < et avant >. Strict.
• Chaque PARAM_NAME référencé dans un POWER_MODEL doit être déclaré plus haut.
• Les valeurs de fréquence doivent provenir du tableau available_frequencies du noyau pour cette horloge — les valeurs non présentes dans le tableau sont arrondies silencieusement.
• CORE_0 ne peut pas être mis hors ligne ; au moins un cœur CPU doit rester en ligne dans chaque profil.
• Copier les noms PARAM textuellement à partir d'un bloc POWER_MODEL existant dans le fichier par carte — les familles de puces diffèrent (T234 Orin utilise CPU_A78_<n> pour les clusters CPU ; T264 Thor utilise une convention différente). Ne pas inventer.

Prérequis

Résoudre le profil actif selon ../../context/target-platform-contract.md. Refuser et router dans ces cas :

Résoudre les chemins :

• <bsp_image.root_path> à partir de bsp_image.root_path: si présent, sinon <workspace>/Image.
• <source.root_path> à partir de source.root_path: si présent, sinon <workspace>/Source.

<bsp_image.root_path> est en lecture seule pour cette compétence ; chaque écriture aboutit sous <source.root_path> (le suivi de superposition). C'est l'invariant de flux de travail dans ../../context/bsp-customization-workflow.md#workflow-invariants — l'édition manuelle en amont détruit silencieusement la trace diff et rend /jetson-promote-image sans effet.

Le fichier par carte

La conf que cette compétence édite a le chemin relatif :

Linux_for_Tegra/rootfs/etc/nvpmodel/nvpmodel_<active-sku>.conf

Il vit dans deux racines ; la compétence parcourt les deux :

Les sections suivantes font référence au fichier par carte pour signifier la copie de superposition sous <source.root_path>. Les opérations 1–4 lisent, éditent et enregistrent toutes contre cette copie de superposition. La copie <bsp_image.root_path> est lue une fois lors de l'étape de détection « Résoudre <active-sku> » et une fois lors de l'étape d'importation vierge de la Recette d'édition de superposition, puis jamais touchée à nouveau.

Résoudre <active-sku> — quel fichier éditer

Le nom de fichier n'est pas toujours module.id + "_" + module.sku. Des variantes existent :

• nvpmodel_p3767_0000_super.conf (variante SKU en mode super)
• nvpmodel_igx_orin.conf, nvpmodel_igx_orin_safety.conf (IGX, sans numéro SKU)

Au démarrage, nvpower.sh (à Linux_for_Tegra/rootfs/etc/systemd/nvpower.sh) lit la chaîne compatible racine du DTB du noyau et la mappe — plus l'état super/sécurité — au nom de fichier nvpmodel. Reproduire ce mappage côté BSP, contre <bsp_image.root_path> :

1. Résoudre le DTB du noyau correct pour le SKU sous <bsp_image.root_path>/Linux_for_Tegra/ et lire sa compatible racine (détecter le DTB du noyau à partir de la conf flash active).
2. Lire <bsp_image.root_path>/Linux_for_Tegra/rootfs/etc/systemd/nvpower.sh pour trouver le mappage compatible-string → conf et l'appliquer à la compatible de l'étape précédente (en tenant compte des drapeaux super/sécurité).
3. Vérifier que nvpmodel_<...>.conf résolu existe sous <bsp_image.root_path>/Linux_for_Tegra/rootfs/etc/nvpmodel/.

Raccourci : filtrer <bsp_image.root_path>/Linux_for_Tegra/rootfs/etc/nvpmodel/ sur nvpmodel_<module.id>_<module.sku>*.conf ; pour les confs flash en mode super, choisir la variante _super. Utiliser seulement lorsque non ambigu ; sinon, se replier sur la méthode DTB.

Ne pas composer aveuglément nvpmodel_<id>_<sku>.conf — vérifier que le fichier existe réellement.

Ensemble de propagation — confs à synchroniser

Le fichier SKU actif est rarement le seul conf qui devrait porter une personnalisation. Après l'avoir édité, appliquer la même édition à chaque frère dans l'ensemble de propagation pour que le changement subsiste peu importe quel module / SKU baseboard est démarré :

• La conf nvpmodel de la plate-forme de référence — la conf en amont dont le fichier actif a été créé (résoudre via reference_devkit dans le profil actif, ou l'ancestralité du fork jetson-derive-carrier). Pour une BSP qui contient uniquement la référence (pas de carriers dérivés), c'est le même fichier que l'actif et la règle se réduit à un non-op.
• Chaque conf nvpmodel dérivée de carrier — chaque nvpmodel_*.conf produit par jetson-derive-carrier pour un carrier personnalisé au-dessus du même SKU de module.
• Frères _super si présents (ex. nvpmodel_p3767_0000_super.conf) — appliquer l'édition structurelle (nouveau bloc POWER_MODEL, bloc supprimé, basculement PM_CONFIG DEFAULT=, renommage NAME) mais préserver les plafonds MAX_FREQ / MIN_FREQ plus élevés de la conf super. Ces plafonds élevés sont la raison même de l'existence de la variante _super ; une réécriture de contenu en cascade depuis le fichier non-super aplatierait silencieusement l'enveloppe super.

« Appliquer la même édition » ≠ copie de fichier en cascade. Porter les lignes POWER_MODEL / PARAM modifiées dans chaque frère ; préserver chaque autre ligne. La copie en cascade est sûre uniquement quand les deux confs étaient octet-identiques avant l'édition. Sinon, re-valider selon les Règles sur chaque cible (tableau available-frequencies pour les valeurs d'horloge, unicité ID, PM_CONFIG DEFAULT= référence un ID présent) — les confs frères peuvent porter des tableaux available_frequencies spécifiques au SKU qui n'acceptent pas les valeurs de fréquence du fichier actif.

Recette d'édition de superposition (appliquer avant toute opération)

Suivre la Recette d'éditions hors-compétence canonique dans le document de flux de travail — paire importation vierge + commit de personnalisation, tous deux bloqués par la porte d'aperçu. Appliquer une fois par exécution, couvrant chaque fichier par carte que l'exécution touche (la conf active plus chaque frère dans l'Ensemble de propagation).

Substitutions concrètes pour cette compétence :

• <rel>/<file> est rootfs/etc/nvpmodel/<conf>.
• Message d'importation vierge suggéré : import pristine: <comma-separated rel paths of imported confs>, corps Source: <bsp_image.root_path>/Linux_for_Tegra/ (BSP <bsp_image.version>).
• En-tête de commit de personnalisation suggéré : jetson-customize-nvpmodel: <summary>, lignes de corps comme nvpmodel_p3767_0001.conf: PM_CONFIG DEFAULT 2 -> 0 (MAXN).

Instructions

Choisir l'opération qui correspond à l'intention de l'utilisateur et suivre la sous-section correspondante. Toutes les opérations côté écriture (1–4) doivent d'abord appliquer la Recette d'édition de superposition.

• Opération 1 — Ajouter un nouveau mode d'alimentation (pilote l'estimateur d'énergie NVIDIA).
• Opération 2 — Supprimer un mode d'alimentation.
• Opération 3 — Éditer un mode d'alimentation existant (pinces, core-online, NAME).
• Opération 4 — Modifier le démarrage par défaut (PM_CONFIG DEFAULT=).
• Opération 5 — Lister les modes d'alimentation définis (lecture seule).

Après toute opération côté écriture, exécuter la chaîne Deploy (## Deploy) pour faire atterrir le changement sur l'appareil.

Exemples

Ajouter un nouveau mode d'alimentation 30 W à partir d'une exportation d'estimateur d'énergie et l'épingler comme démarrage par défaut sur une cible P3767-0001 :

/jetson-customize-nvpmodel
> add a new POWER_MODEL from ~/Downloads/nvpmodel_30W.conf as ID 8 NAME "30W_CUSTOM"
> set PM_CONFIG DEFAULT to 8

Limiter une cible Thor à l'enveloppe d'alimentation MAXN en basculant le démarrage par défaut (aucun réglage d'enveloppe nécessaire) :

/jetson-customize-nvpmodel
> set PM_CONFIG DEFAULT to the MAXN profile's ID

Lister les modes d'alimentation que le SKU actif définit actuellement et quel est le démarrage par défaut :

/jetson-customize-nvpmodel
> list defined power modes

Opération 1 — Ajouter un nouveau mode d'alimentation

Appliquer d'abord la Recette d'édition de superposition.

Générer le profil via l'estimateur d'énergie

Ne pas interpoler ou extrapoler les fréquences à partir des profils existants pour estimer la puissance.

Pour tout enveloppe d'alimentation non standard (budget personnalisé, charge de travail personnalisée), utiliser l'estimateur d'énergie NVIDIA : https://jetson-tools.nvidia.com/powerestimator/

• Choisir le SKU de module exact et la version JetPack.
• Entrer la charge de travail (cœurs CPU, utilisation GPU, EMC, codecs, caméra, affichage).
• Estimer le budget d'alimentation.
• Télécharger nvpmodel.conf personnalisé.
• Partager le chemin de fichier nvpmodel.conf téléchargé.

Ajouter le bloc POWER_MODEL

Dans le fichier par carte, insérer le nouveau bloc après la dernière déclaration < PARAM … > (POWER_MODEL doit référencer les PARAMs déclarés) et avant la ligne finale < PM_CONFIG ... >. La structure du bloc est le Format de fichier montré ci-dessus ; les valeurs de fréquence proviennent de la sortie de l'estimateur d'énergie (voir « Générer le profil via l'estimateur d'énergie »).

Vérifier que ID est unique ; NAME doit être en majuscules, sans espace. Chaque valeur numérique MAX_FREQ / MIN_FREQ doit satisfaire la règle available_frequencies (voir Règles). Si vous envisagez ce mode comme démarrage par défaut, suivre l'opération 4.

Opération 2 — Supprimer un mode d'alimentation

Appliquer d'abord la Recette d'édition de superposition.

1. Dans le fichier par carte, supprimer le bloc entier < POWER_MODEL ID=<n> NAME=... > incluant toutes ses lignes de paramètres, jusqu'au (mais sans inclure) marqueur < POWER_MODEL ... > ou < PM_CONFIG ... > suivant.
2. Si l'ID supprimé correspond à la valeur DEFAULT=<id> actuelle dans la ligne finale < PM_CONFIG … >, pointer DEFAULT= vers un ID restant — sinon nvpmodel échouera à appliquer un défaut au démarrage.
3. Rechercher les références en dur dans les scripts rootfs avant de déclarer le changement sûr :

   grep -rn "nvpmodel -m" \
     Linux_for_Tegra/rootfs/etc \
     Linux_for_Tegra/rootfs/opt 2>/dev/null

Les écarts ID sont légaux — vous n'êtes pas obligé de renuméroter les modes restants.

Opération 3 — Éditer un mode d'alimentation existant

Appliquer d'abord la Recette d'édition de superposition.

1. Dans le fichier par carte, éditer les lignes de paramètres à l'intérieur du bloc. Garder les noms <param> et <arg> correspondant exactement aux déclarations PARAM.
2. Si l'édition modifie l'enveloppe d'alimentation (tout CPU/GPU/EMC/PVA/DLA MAX_FREQ / MIN_FREQ, nombre de core-online pour un mode lié en fréquence, ou masque TPC), re-exécuter l'estimateur d'énergie NVIDIA (voir « Générer le profil via l'estimateur d'énergie ») pour ancrer les nouvelles fréquences dans un modèle réel par composant. Ne pas interpoler à partir des modes voisins.
3. Valider les valeurs d'horloge selon la règle available_frequencies (voir Règles).

Les éditions qui ne basculent que les drapeaux core-online au sein d'une enveloppe déjà validée, ou qui ne changent que NAME=, n'ont pas besoin du passage de l'estimateur d'énergie.

Opération 4 — Modifier le démarrage par défaut

Appliquer d'abord la Recette d'édition de superposition.

Éditer la ligne < PM_CONFIG DEFAULT=<id> > au bas du fichier par carte.

<id> doit référencer un bloc existant < POWER_MODEL ID=<id> … > dans le même fichier. Pointer vers un ID indéfini rend nvpmodel inapte à s'appliquer au démarrage.

Opération 5 — Lister les modes d'alimentation définis

C'est une opération en lecture seule ; aucune configuration de suivi de superposition n'est nécessaire. Exécuter contre la copie que vous voulez inspecter (<bsp_image.root_path>/... pour l'état vierge, <source.root_path>/... pour l'état post-édition) :

grep -E '^< POWER_MODEL ' <per-board file>
grep -E '^< PM_CONFIG '   <per-board file>

La première commande imprime chaque ID/NAME ; la seconde imprime le démarrage par défaut actuel. Sur une cible en exécution, nvpmodel -p --verbose (ou nvpmodel -q) est autoritaire.

Limitations

• Portée côté BSP uniquement — cette compétence n'invoque jamais nvpmodel -m sur une cible en exécution. La commutation de mode en direct nécessite un redémarrage via Deploy, ou le flux côté canal scp + nvpmodel -m décrit dans ## Deploy.
• Les éditions atterrissent uniquement dans la copie de superposition sous <source.root_path> ; la copie <bsp_image.root_path> est en lecture seule et est réécrite par /jetson-promote-image. L'édition manuelle de bsp_image est silencieusement perdue au prochain /jetson-init-image ré-extraction.
• Les valeurs de fréquence doivent provenir du tableau available_frequencies du noyau pour l'horloge pertinente — les valeurs en dehors du tableau sont arrondies silencieusement. Cette compétence ne valide pas contre le tableau d'une cible en direct ; faire confiance aux valeurs existantes du fichier par carte et à la sortie de l'estimateur d'énergie.
• Les éditions d'enveloppe non triviales (tout changement CPU/GPU/EMC/PVA/DLA MAX_FREQ / MIN_FREQ) nécessitent l'estimateur d'énergie NVIDIA (https://jetson-tools.nvidia.com/powerestimator/) — l'interpolation ou l'extrapolation entre les modes existants ne sont pas supportées.
• La propagation entre frères est partielle par conception : seules les lignes POWER_MODEL / PARAM modifiées sont portées, jamais une réécriture de fichier en cascade, puisque les frères _super portent des plafonds MAX_FREQ/MIN_FREQ élevés qui doivent rester intacts.
• Les noms PARAM sont spécifiques à la famille de puces (ex. CPU_A78_<n> sur T234, différent sur T264). Copier textuellement à partir des blocs POWER_MODEL existants ; les noms inventés échouent silencieusement à s'appliquer.

Dépannage

Deploy

Le commit de personnalisation dans le suivi de superposition n'atteint pas l'appareil de lui-même. La chaîne Deploy :

1. /jetson-promote-image — copie chaque fichier suivi dans la superposition dans <bsp_image.root_path>/Linux_for_Tegra/. Diff-aware (ignorer les fichiers octet-identiques) ; utilise sudo cp -p pour les destinations rootfs/*.
2. /jetson-flash-image — flashe la bsp_image mise à jour vers l'appareil.
3. (Alternatif, pas de flash) Copier <source.root_path>/Linux_for_Tegra/rootfs/etc/nvpmodel/<conf> directement vers /etc/nvpmodel/<conf> de la cible en exécution, puis sudo nvpmodel -m <id> (ou redémarrer pour reprendre le nouveau DEFAULT=).

L'édition de <source.root_path>/... sans commit — ou l'édition directe de <bsp_image.root_path>/... — ne fait rien pour /jetson-promote-image et est silencieusement perdue au prochain /jetson-init-image ré-extraction.