/jetson-customize-nvpmodel

name: jetson-customize-nvpmodel
description: >-
  Use when you need to add, remove, edit, list, or change the boot
  default of an nvpmodel power mode on a Jetson/Tegra (Orin, Thor)
  target. Triggers: edit power mode, tune frequency caps.
version: 0.0.1
license: "Apache-2.0"
metadata:
  data-classification: public
  author: "Jetson Team"
  tags:
    - power
    - nvpmodel
    - profile
  domain: power

Modify nvpmodel Power Mode (BSP-side)

Purpose

Edit the per-board nvpmodel configuration so the device boots with the desired power-mode set, CPU/GPU/EMC/TPC clamps, and default mode. BSP-side only — all writes land in the overlay tracker, the upstream `bsp_image` copy is read-only.

This skill handles BSP-side edits to the per-board nvpmodel configuration file: adding modes, removing modes, editing CPU/GPU/EMC/TPC clamps, and changing the boot default. Applies on Jetson / Tegra platforms (T234 Orin, T264 Thor).

File format (canonical, per the BSP file header)

# 1. PARAM definitions — declare named knobs and their sysfs paths
< 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. POWER_MODEL definitions — one block per profile
< POWER_MODEL ID=<int> NAME=<string> >
PARAM_NAME ARG_NAME <value>
...

# 3. PM_CONFIG — mandatory; selects boot default
< PM_CONFIG DEFAULT=<id> >

Rules:

• For `TYPE=FILE`, `<value>` is a **string** (`0`, `1`, `on`, `auto`, …).
• For `TYPE=CLOCK`, `<value>` is an **integer** (Hz for clocks, raw integer for masks).
• `-1` for a CLOCK value means **INT_MAX** (no cap).
• The header `< … >` line must start at column 0 with a space after `<` and before `>`. Strict.
• Every `PARAM_NAME` referenced in a POWER_MODEL must already be declared above.
• **Frequency values must come from the kernel's `available_frequencies`** table for that clock — values not in the table get silently rounded.
• `CORE_0` cannot be offlined; at least one CPU core must remain online in every profile.
• **Copy PARAM names verbatim** from an existing POWER_MODEL block in the per-board file — chip families differ (T234 Orin uses `CPU_A78_<n>` for CPU clusters; T264 Thor uses a different convention). Don't invent.

Prerequisites

Resolve the active profile per [`../../context/target-platform-contract.md`](../../context/target-platform-contract.md). Refuse and route in these cases:

| Condition | Refuse with | |---|---| | No active profile, or `active: NA` | Route to `/jetson-set-target` or `/jetson-init-target`. | | Profile lacks `bsp_image:` block | Route to `/jetson-init-image`. | | `<bsp_image.root_path>/Linux_for_Tegra/` missing | Route to `/jetson-init-image`. | | `<source.root_path>/Linux_for_Tegra/` missing or not a git repo | Route to `/jetson-init-source`. |

Resolve paths:

• `<bsp_image.root_path>` from `bsp_image.root_path:` if present, else `<workspace>/Image`.
• `<source.root_path>` from `source.root_path:` if present, else `<workspace>/Source`.

`<bsp_image.root_path>` is **read-only** for this skill; every write lands under `<source.root_path>` (the overlay tracker). This is the workflow invariant in [`../../context/bsp-customization-workflow.md#workflow-invariants`](../../context/bsp-customization-workflow.md#workflow-invariants) — hand-editing upstream silently destroys the diff trail and makes `/jetson-promote-image` a noop.

The per-board file

The conf this skill edits has the relative path:

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

It lives in **two** roots; the skill walks both:

| Role | Location | Skill writes? | |---|---|---| | Detection + pristine source | `<bsp_image.root_path>/Linux_for_Tegra/rootfs/etc/nvpmodel/` | no — read-only | | Overlay edit target + git commit | `<source.root_path>/Linux_for_Tegra/rootfs/etc/nvpmodel/` | yes |

Subsequent sections refer to **the per-board file** to mean the overlay copy under `<source.root_path>`. Operations 1–4 all read, edit, and save against that overlay copy. The `<bsp_image.root_path>` copy is read once during the "Resolving `<active-sku>`" detection step and once during the [Overlay edit recipe](#overlay-edit-recipe-apply-before-any-operation)'s pristine-import step, then never touched again.

Resolving `<active-sku>` — which file to edit

The filename is **not** always `module.id + "_" + module.sku`. Variants exist:

• `nvpmodel_p3767_0000_super.conf` (super-mode SKU variant)
• `nvpmodel_igx_orin.conf`, `nvpmodel_igx_orin_safety.conf` (IGX, no SKU number)

At boot, `nvpower.sh` (at `Linux_for_Tegra/rootfs/etc/systemd/nvpower.sh`) reads the kernel DTB's root `compatible` string and maps it — plus super/safety state — to the nvpmodel filename. Replicate that mapping **BSP-side**, against `<bsp_image.root_path>`:

1. Resolve the SKU-correct kernel DTB under `<bsp_image.root_path>/Linux_for_Tegra/` and read its root `compatible` (detect kernel DTB from the active flash conf). 2. Read `<bsp_image.root_path>/Linux_for_Tegra/rootfs/etc/systemd/nvpower.sh` to find the compatible-string → conf mapping, and apply it to the compatible from the previous step (factoring in super/safety flags). 3. Verify the resolved `nvpmodel_<...>.conf` exists under `<bsp_image.root_path>/Linux_for_Tegra/rootfs/etc/nvpmodel/`.

Shortcut: filter `<bsp_image.root_path>/Linux_for_Tegra/rootfs/etc/nvpmodel/` to `nvpmodel_<module.id>_<module.sku>*.conf`; for super-mode flash configs pick the `_super` variant. Use only when unambiguous; otherwise fall back to the DTB method.

Don't blindly compose `nvpmodel_<id>_<sku>.conf` — verify the file actually exists.

Propagation set — confs to keep in sync

The active-SKU file is rarely the o