Option
HeimHeim Skill DevOps und CI/CD jetson-customize-clocks

jetson-customize-clocks

NVIDIA/skills NVIDIA/skills

Sie können das Taktverhalten von CPU, GPU und EMC auf NVIDIA Jetson-Geräten festlegen, begrenzen oder anpassen, indem Sie vor dem Flashen die Dateien „BPMP DTB“ und „nvpower.sh“ bearbeiten.

...Alle erweitern
0
Zeit aktualisiert 25. September 2026

Uhren anpassen

Zweck

Passen Sie das Verhalten der CPU-, GPU- und EMC-Taktfrequenzen auf einem Jetson-Zielgerät an, indem Sie vor dem Flashen des Images Dateien unter Linux_for_Tegra/ vor dem Flashen des Images. Dabei sind zwei Ebenen zu berücksichtigen:

  • Die BPMP-DTB unter Linux_for_Tegra/bootloader/ — die max-rate-custom Obergrenzen sowie das EMC-DVFS-Gate (bwmgr + cactmon auf allen SoCs; osp-controller nur auf T26x).
  • „nvpower.sh“ unter Linux_for_Tegra/rootfs/etc/systemd/nvpower.sh — cpufreq-/devfreq-Regler sowie (optional) gerätebezogene Minimal-/Maximal-/statische Frequenzen, die beim Booten in sysfs geschrieben werden.

Häufige Auslöser: „CPU-/GPU-/EMC-Frequenz sperren“, „GPU auf Fmax festlegen“, „EMC auf MAXN festlegen“, „EMC-DVFS deaktivieren/aktivieren“, „CPU-DVFS deaktivieren/aktivieren“, „maximale CPU-/GPU-Rate festlegen“, „cpufreq-Regler ändern“.

Nicht im Umfang enthalten: Laufzeit-Taktoptimierung auf einem laufenden Zielsystem (ohne Flash-Schritt), Bearbeitungen des NVP-Modells im Energiesparmodus (verwenden Sie den verwandten Skill /jetson-customize-nvpmodel) sowie Überschreibungen der Silizium-Obergrenze (max-rate-maxn ist schreibgeschützt).

Voraussetzungen

Das aktive Profil gemäß ../../context/target-platform-contract.md. In folgenden Fällen ablehnen und umleiten:

Bedingung Ablehnen bei
Kein aktives Profil oder active: NA Weiterleiten an /jetson-set-target oder /jetson-init-target.
Profil fehlt bsp_image: Block Route zu /jetson-init-image.
/Linux_for_Tegra/ fehlt Route zu /jetson-init-image.
/Linux_for_Tegra/ fehlt oder ist kein Git-Repo Pfad zu /jetson-init-source.

Pfade auflösen:

  • von bsp_image.root_path: falls vorhanden, andernfalls /Image.
  • von source.root_path: falls vorhanden, andernfalls /Source.

ist für diese Fertigkeit schreibgeschützt; jeder Schreibvorgang (der BPMP-DTB von Operation 1 und der von Operation 2 nvpower.sh) landet unter (dem Overlay-Tracker). Dies ist die Workflow- Invariante in ../../context/bsp-customization-workflow.md#workflow-invariants — die manuelle Bearbeitung im vorgelagerten Bereich zerstört stillschweigend den Diff-Trail und führt zu /jetson-promote-image eine Noop-Operation.

Anweisungen

  1. Erfüllen Sie die oben genannten Voraussetzungen (aktives Profil, extrahiertes BSP-Image, Quell-Overlay-Tracker initialisiert).
  2. Wählen Sie den Vorgang aus der folgenden Tabelle aus.
  3. Befolgen Sie den verlinkten Abschnitt zur Vorgehensweise – Vorgang 1 (BPMP-DTB), Vorgang 2 (nvpower.sh) oder das MAXN-Rezept für beide.
  4. Übernehmen Sie die Änderung im Overlay-Tracker gemäß den Übernahmeregeln des jeweiligen Vorgangs.
  5. Stellen Sie die Änderungen mit /jetson-promote-image → /jetson-flash-image. Die neue BPMP-DTB und nvpower.sh werden beim nächsten Systemstart wirksam.

Unterstützte Operationen

Operation Wo die Bearbeitung zu finden ist Abschnitt „Vorgehensweise“
Eine CPU-/GPU-Taktfrequenz auf einen bestimmten Wert festlegen BPMP-DTB max-rate-custom am Taktknoten + nvpower.sh Regler performance „Inhalt bearbeiten: max-rate-custom“ + „Bearbeitung auswählen“
EMC auf seine Anfangsrate sperren (EMC-DVFS deaktivieren) BPMP-DTB: bwmgr.enabled = 0, cactmon.enabled = 0, sowie /delete-node/ osp-controller nur bei T26x „Inhaltsbearbeitung: EMC DVFS deaktivieren / aktivieren“
EMC DVFS wieder aktivieren BPMP-DTB: bwmgr.enabled = 1, cactmon.enabled = 1, wiederherstellen osp-controller auf T26x „Inhaltsbearbeitung: EMC DVFS deaktivieren / aktivieren“
Für Stresstests alle Werte auf MAXN festlegen Kombinieren Sie das Obige mit „nvpmodel MAXN“ als Standard beim Booten siehe Anleitung
Die feste Obergrenze einer Taktfrequenz senken, ohne sie zu sperren BPMP-DTB max-rate-custom nur „Inhalt bearbeiten: max-rate-custom"
Die Rate eines Geräts begrenzen, ohne nvpower.sh Min/Max über sysfs festzulegen „Bearbeitung auswählen“

Vorgang 1 – BPMP-DTB-Bearbeitungen

Befolgen Sie das BPMP-DTB-Anpassungsprotokoll in ../../references/bsp-customization-bpmp-dtb.md. Das Protokoll regelt die Abläufe – einwandfreier Import beim ersten Durchlauf, dtc Dekompilieren, Neukompilieren, Plausibilitätsprüfung, Commit. Diese Funktion liefert lediglich die taktspezifischen Inhalte (welche Knoten und Eigenschaften im Schritt „DTS bearbeiten“ des Protokolls bearbeitet werden sollen).

Die bearbeiteten .dtb landet im /Linux_for_Tegra/ Overlay-Tracker. /jetson-promote-imageKanal A durchläuft den Tracker und kopiert die Datei in bsp_image. Bearbeiten Sie „ /Linux_for_Tegra/bootloader/ “ nicht direkt – das ist die „Promote“-Ausgabe, keine Eingabe.

Die SKU-korrekte BPMP-DTB auflösen

Gemäß dem Abschnitt „Auflösen der aktiven BPMP-DTB“ des Protokolls lesen Sie BPFDTB_FILE aus der aktiven Flash-Konfiguration aus. Bei den gängigen Thor-/ Einzel-SKU-Konfigurationsformen ist dies die statische BPFDTB_FILE=... Zeile in der plattenbezogenen .conf und der Wert ist unverändert maßgeblich.

Bei SKU-multiplexierten Konfigurationsformen (Orin-AGX-Entwicklungskit-Konfigurationskette, die je nach board_sku/board_FAB über update_flash_args_common — siehe ../../context/bsp-customization-software-layers.md#per-board-conf-dispatch--update_flash_args_common), durchlaufen Sie die Dispatch-Kette mit board_sku= und board_FAB= ausgehend vom aktiven Profil und lesen Sie BPFDTB_FILE aus der Dispatch-Ausgabe – nicht aus der statischen Zeile der plattenbezogenen .conf. Statische und versendete Werte stimmen bei nicht-multiplexierten Konfigurationen überein; die Versendung ist nur dann zwingend erforderlich, wenn die Konfigurationskette bedingt BPFDTB_FILE.

Liste der effektiven Maximalraten (Prüfung)

Überprüfen Sie beide Ebenen der Laufzeitobergrenze – siehe references/clock-control-model.md#effective-runtime-ceiling — bevor eine Entscheidung über einen max-rate-custom Wert.

Das Prüf-Kochbuch (BPMP-seitige Dekompilierung + grep; nvpmodel-seitiges awk über den Standard-Boot-Modus) befindet sich in references/bpmp-dtb-clock-edits.md#inspection-cookbook.

Für die nvpmodel-Ebene siehe /jetson-customize-nvpmodel.

Dieser Schritt verändert den Zustand nicht – er ist eine Voraussetzung für die Festlegung des Umfangs der Bearbeitung im Schritt „Inhaltsbearbeitung: max-rate-custom auf einem benannten Taktknoten“.

Inhaltsbearbeitung: max-rate-custom an einem benannten Taktknoten

Ändern Sie während des Schritts „DTS bearbeiten“ des Protokolls die Eigenschaft innerhalb des benannten Uhrenknotens – diese lateinit. max-rate-custom muss streng unterhalb der Hard-Cap der Uhr liegen (max-rate-maxn falls definiert; andernfalls darf der Live-Wert max_rate eines laufenden Ziels desselben Chips / derselben SKU).

DTS-Bearbeitungsformular, Semantik und die Zuordnung zwischen nvpmodel und BPMP-Taktknoten befinden sich in references/bpmp-dtb-clock-edits.md.

Geben Sie dann die Kontrolle wieder an das Protokoll zurück – dessen Schritte „Neukompilieren“, „Plausibilitätsprüfung des neu kompilierten Blobs“, „In den Overlay-Tracker einfügen“ und „Bereinigung“ übernehmen den Rest. Konvention für Commit-Meldungen gemäß dem Protokoll: : jetson-customize-clocks — max-rate-custom = .

Inhaltsbearbeitung: EMC DVFS deaktivieren / aktivieren

Das Standardverhalten (EMC DVFS ein) erfordert keine Bearbeitung. Das Deaktivieren von EMC DVFS ist eine mehrknotige Bearbeitung, die innerhalb desselben Schritts „Edit the DTS“ des Protokolls angewendet wird, kein bwmgr Umschaltung:

# Bearbeitung Gültigkeitsbereich
1 bwmgr.enabled = <0x00> Alle SoCs, obligatorisch
2 cactmon.enabled = <0x00> Alle SoCs, obligatorisch
3 /delete-node/ osp-controller T26x (Thor) obligatorisch – T23x (Orin) verfügt über keinen solchen Knoten, überspringen

Erkennung: dtc -I dtb -O dts | grep -c osp-controller — keine Treffer ⇒ T23x-Pfad. Vollständige DTS-Ausschnitte, die Ausfallmodi der überlebenden Pfade und das Verfahren zur Wiederaktivierung befinden sich in references/emc-dvfs-disable.md.

Wenden Sie die Protokollschritte „Recompile“ bis „Cleanup“ an, sobald die Bearbeitung mehrerer Knoten abgeschlossen ist. Konvention für Commit-Meldungen: : jetson-customize-clocks — EMC DVFS disable (bwmgr + cactmon[+ osp-controller]).

Die Deaktivierung erhöht den Leerlaufstromverbrauch; vorgesehen für Belastungs- und Leistungstests, nicht für Produktions-Rootfs.

Wiederholung + Idempotenz

Gemäß dem Abschnitt „Re-runnability“ des Protokolls führt die erneute Ausführung dieses Skills mit demselben Zielwert zu einem No-Op-Commit. Eine erneute Ausführung mit einem anderen Wert überschreibt dieselbe Eigenschaft — git log -- $BPMP_REL zeigt den Verlauf pro Durchlauf an. Um eine Uhr auf ihre max-rate-maxn Obergrenze zurückzusetzen, bearbeiten Sie das DTS, um die max-rate-custom Zeile zu entfernen und neu zu kompilieren.

Vorgang 2 – Änderungen an nvpower.sh

Bearbeitet nvpower.sh, das beim Systemstart über nvpower.service ausgeführt wird, um die cpufreq- und devfreq-Regler sowie deren Raten festzulegen.

Die Skriptdatei

Das Skript, das von dieser Operation bearbeitet wird, hat den relativen Pfad:

Linux_for_Tegra/rootfs/etc/systemd/nvpower.sh

Es befindet sich in zwei Verzeichnisbäumen; die Operation durchläuft beide:

Rolle Ort Schreibt die Funktion?
Erkennung + unverfälschte Quelle /Linux_for_Tegra/rootfs/etc/systemd/ nein – schreibgeschützt
Overlay-Bearbeitungsziel + Git-Commit /Linux_for_Tegra/rootfs/etc/systemd/ ja

In den folgenden Teilschritten bezieht sich „pro Skriptdatei“ auf die Overlay- Kopie unter . Die Kopie wird einmal während des unten beschriebenen „pristine-import“-Schritts gelesen und danach nie wieder verändert.

Rezept zur Overlay-Bearbeitung (vor der Bearbeitung von „nvpower.sh“ anwenden)

Befolgen Sie das kanonische Rezept für „Off-Skill“-Bearbeitungen in der Workflow-Dokumentation – ein Paar aus „Pristine-Import“ und „Anpassungs-Commit“, beide durch das Vorschau-Gate gesteuert. nvpower.sh Es handelt sich um eine einzelne Datei ohne Propagations-Set; ein „Pristine“-Commit + ein Anpassungs-Commit decken die gesamte Änderung ab.

Konkrete Ersetzungen für diesen Skill:

  • / ist rootfs/etc/systemd/nvpower.sh.
  • Vorgeschlagene „Pristine-Import“-Meldung: import pristine: rootfs/etc/systemd/nvpower.sh, Text Source: /Linux_for_Tegra/ (BSP ).
  • Vorgeschlagene Kopfzeile für den Anpassungs-Commit: jetson-customize-clocks: nvpower.sh , Inhaltszeilen wie set_cpufreq_governor: desired_cpufreq_gov "schedutil" -> "performance".

Wähle die Bearbeitungs-

Funktionsorte (set_cpufreq_governor, set_devfreq_governor), gängige Bearbeitungsrezepte (an Fmax koppeln, statische Rate, Min-/Max-Grenzwerte) sowie den nvidia-l4t-init Hinweis zum Paket-Upgrade befinden sich in references/nvpower-sh-edits.md.

Deploy

Der Commit zur Anpassung im Overlay-Tracker gelangt nicht von selbst auf das Gerät. Die Deploy-Kette:

  1. /jetson-promote-image — kopiert jede nachverfolgte Datei im Overlay in /Linux_for_Tegra/. Diff-fähig (überspringt byte-identische Dateien); verwendet sudo cp -p für rootfs/* Ziele.
  2. /jetson-flash-image — flasht die aktualisierte bsp_image auf das Gerät. nvpower.service führt das neue Skript beim nächsten Systemstart aus.
  3. (Alternative, ohne Flash) Kopiere /Linux_for_Tegra/rootfs/etc/systemd/nvpower.sh direkt in das Verzeichnis /etc/systemd/nvpower.sh, dann sudo systemctl restart nvpower.service (oder neu starten).

Bearbeiten /... ohne zu speichern – oder direkt /... direkt — bewirkt nichts für /jetson-promote-image und geht beim nächsten /jetson-init-image Neu-Extraktion.

Rezept – alles auf MAXN festsetzen für Stress-/Leistungstests

Kombiniert die Vorgänge 1 und 2. Die BPMP-Bearbeitung von Vorgang 1 führt den gesamten Datenfluss durch einen Durchlauf des Protokolls (ein einziger Zyklus aus Dekompilierung / Bearbeitung über mehrere Knoten / Neukompilierung / Commit – das Protokoll nicht zweimal für denselben .dtb):

  1. BPMP-DTB (der Schritt „Inhaltsbearbeitung: max-rate-custom auf einem benannten Taktknoten“-Schritt): Lassen Sie max-rate-custom auf jedem CPU-/GPU-/EMC-Takt ungesetzt; entferne vorhandene max-rate-custom Zeilen, die die Obergrenze senken.
  2. BPMP-DTB (Inhalt des Schritts „Inhaltsbearbeitung: EMC DVFS deaktivieren / aktivieren“): EMC auf seine Initialisierungsrate festlegen – bwmgr.enabled = 0, cactmon.enabled = 0, plus /delete-node/ osp-controller auf T26x (auf T23x überspringen).
  3. Wenden Sie beide Inhaltsbearbeitungen innerhalb eines Protokollaufrufs „Edit the DTS“ an und führen Sie anschließend die verbleibenden Protokollschritte aus (Neukompilierung, Plausibilitätsprüfung, einzelner Anpassungs-Commit, der beide Inhaltsbearbeitungen abdeckt).
  4. nvpower.sh (Vorgang 2): Setzen Sie desired_cpufreq_gov="performance" und desired_devfreq_gov="performance" bedingungslos; entfernen Sie das GPU/nvjpg-Überspringen in set_devfreq_governor. Wird über das Overlay-Bearbeitungsrezept von Operation 2 angewendet (der Schritt „Overlay-Bearbeitungsrezept (vor der Bearbeitung von nvpower.sh anwenden)“) – ein separates Overlay-Tracker-Paar aus „Pristine“ und Anpassungs-Commit für das Rootfs-Skript, unabhängig vom Commit des BPMP-DTB-Protokolls.
  5. Setzen Sie den nvpmodel-Modus für den Boot-Standard über /jetson-customize-nvpmodel — die pro Takt geltende nvpmodel-Obergrenze wird max-rate-maxn unabhängig vom Inhalt der BPMP-DTB.

Stellt /jetson-promote-image → /jetson-flash-image erfasst das neue BPMP-DTB (über den Overlay-Tracker) und das bearbeitete nvpower.sh (über denselben Overlay-Tracker) beim nächsten Flash-Vorgang.

Einschränkungen

  • Nur zur Zeit der Image-Erstellung. Alle Änderungen werden unter /Linux_for_Tegra/ und gelangen nur über /jetson-promote-image → /jetson-flash-image. Die Anpassung am Live-Ziel liegt außerhalb des Anwendungsbereichs.
  • max-rate-custom senkt lediglich die Obergrenze. Sie muss streng unter max-rate-maxnliegen; eine Anhebung der Silizium-Obergrenze wird nicht unterstützt.
  • Die effektive Obergrenze besteht aus zwei Ebenen. Die Laufzeit-Obergrenze ist min(BPMP cap, active-nvpmodel-mode cap). Die nvpmodel-Obergrenze wird von /jetson-customize-nvpmodel; diese Funktion nimmt keine Änderungen daran vor.
  • SoC-abhängiges EMC-DVFS-Gate. Das Deaktivieren von EMC-DVFS erfordert die Bearbeitung unterschiedlicher Knotensätze bei T23x (bwmgr + cactmon) im Vergleich zu T26x (bwmgr + cactmon + delete osp-controller). Eine fehlerhafte Erkennung führt zu undefiniertem Verhalten.
  • Die T23x-GPU-Obergrenze ist mehrknotig. Der GPU-Takt ist auf nafll_gpusys und jede nafll_gpcX; die Begrenzung gilt nur, wenn sie auf alle angewendet wird.
  • nvpower.sh wird über das Paket verwaltet. Es wird in nvidia-l4t-init; Paket-Upgrades überschreiben vor Ort vorgenommene Änderungen. Bei langfristig genutzten Setups sollte ein systemd-Drop-in oder ein zugehöriges Hilfsprogramm bevorzugt werden.
  • ODMDATA hat Vorrang. Wenn ein ODMDATA-Token eine Eigenschaft abdeckt, überschreibt das Token direkte BPMP-DTS-Änderungen zum Zeitpunkt des Flash-Vorgangs. Direkte BPMP-DTS-Änderungen dienen als Fallback für Eigenschaften, die von keinem NVIDIA-Token abgedeckt werden.
  • max-rate-maxn und „lateinit“ sind tabu. max-rate-maxn ist die Hardware-Obergrenze (schreibgeschützt). lateinit dient der Initialisierung der Uhr zur Bootzeit, nicht zur Überschreibung der Obergrenze – rühren Sie keines von beiden an.
  • BPMP-DTB kann SKU-multiplexiert sein. Bei zusammengesetzten/verteilten Flash-Konfigurationen (Orin-AGX-Devkit-Kette) BPFDTB_FILE wird ausgewählt durch board_sku / board_FAB über update_flash_args_common. Das Auslesen der statischen BPFDTB_FILE= Zeile ist fehlerhaft, wenn die Kette sie bedingt überschreibt; lösen Sie das Problem stattdessen über das Dispatch.

Fehlerbehebung

Fehler Ursache Lösung
max-rate-custom eingestellt, aber die Taktrate steigt weiterhin auf max-rate-maxn bei T23x-GPU Nur nafll_gpusys wurde begrenzt; die nafll_gpcX Partitionen laufen weiterhin bei max-rate-maxn und dominieren die effektive Obergrenze. Wenden Sie dasselbe max-rate-custom auf nafll_gpusys und auf jeden nafll_gpcX Knoten, der durch grep -nE '^\s*nafll_gpc[0-9]+\s*:' .
Die Deaktivierung von EMC DVFS scheint zu greifen, aber EMC skaliert weiterhin auf T26x Nur bwmgr.enabled = <0x00> wurde gesetzt; osp-controller bleibt bestehen und gibt Frequenzänderungen über den QoS-Pfad erneut aus. Bearbeitungen Nr. 2 (cactmon.enabled = <0x00>) und Nr. 3 (/delete-node/ osp-controller) innerhalb desselben Schritts „DTS bearbeiten“ hinzu. Überprüfen Sie osp-controller über dtc -I dtb -O dts | grep -c osp-controller → erwarteter Wert 0.
EMC-DVFS-Deaktivierung auf T23x mit der Meldung „Knoten nicht gefunden“ für osp-controller T23x (Orin) BPMP-DTBs enthalten keine osp-controller; Bearbeitung Nr. 3 muss auf T23x übersprungen werden. SoC-Familie mit dem grep -c osp-controller Schritt; wende #3 nur an, wenn der Zählwert ≥1 ist.
BPMP weigert sich, die DTB nach der Bearbeitung zu laden: max-rate-custom >= max-rate-maxn max-rate-custom wurde auf oder über die Silizium-Obergrenze gesetzt. Senken Sie max-rate-custom strikt unterhalb max-rate-maxn. Falls max-rate-maxn im Knoten fehlt, erfragen Sie die Live-Obergrenze bei einem laufenden Ziel: cat /sys/kernel/debug/bpmp/debug/clk//max_rate.
osp-controller erscheint wieder, nachdem status = "disabled" status = "disabled" entfernt den Knoten nicht aus dem Gerätebaum; BPMP durchläuft ihn weiterhin. Ersetzen Sie durch /delete-node/ osp-controller; — der Knoten darf nicht vorhanden sein, damit BPMP den Pfad überspringt.
Änderungen an nvpower.sh nach „lost“ apt upgrade nvpower.sh gehört dem nvidia-l4t-init Deb und werden bei einem Upgrade überschrieben. Bei langfristig genutzten Testkonfigurationen sollten Paketänderungen in eine systemd-Drop-in-Datei oder eine untergeordnete Hilfsdatei integriert werden, auf die nvpower.sh, anstatt nvpower.sh direkt an der Datei.
/jetson-promote-image ist nach der Bearbeitung der BPMP-DTB eine leere Operation Die Änderung wurde auf /Linux_for_Tegra/, was /jetson-promote-imageAusgabe von — nicht auf dessen Eingabe. Verschieben Sie die Änderung in /Linux_for_Tegra/bootloader/ (den Overlay-Tracker) und über das BPMP-DTB-Protokoll fest.
Die Begrenzung scheint beim ersten Start zu greifen, wird dann aber nach einem Wechsel des Energiemodus zurückgesetzt Die pro Takt geltende Obergrenze des aktiven nvpmodel-Modus wird unterhalb von max-rate-custom. Überprüfen Sie beide Ebenen; falls „nvpmodel“ bindend ist, erhöhen (oder entfernen) Sie die „nvpmodel“-Obergrenze über /jetson-customize-nvpmodel. Die BPMP-Obergrenze allein stellt nicht die Obergrenze zur Laufzeit dar.

Referenzen

  • ../../references/bsp-customization-bpmp-dtb.md — Kanonisches BPMP-DTB-Anpassungsprotokoll (unveränderter Import, Dekompilierung, Bearbeitung, Neukompilierung, Plausibilitätsprüfung, Commit). Vorgang 1 dieser Fertigkeit ist ein reiner Inhaltsverbraucher; das Protokoll regelt die Mechanismen.
  • references/clock-control-model.md — Schichtstapel, Übersicht über die „Two-Ceilings“-Semantik, Formel für die effektive Laufzeitobergrenze.
  • references/bpmp-dtb-clock-edits.md — Semantik der zwei Obergrenzen, DTS-Bearbeitungsformular, Zuordnung zwischen nvpmodel und BPMP-Taktknoten, Leitfaden zur Überprüfung.
  • references/emc-dvfs-disable.md — Vollständiges SoC-abhängiges Verfahren zur Deaktivierung von EMC-DVFS mit DTS-Schnipseln, Erkennung und Reaktivierung.
  • references/nvpower-sh-edits.md — nvpower.sh Funktionsstandorte + allgemeine Bearbeitungsrezepte + Hinweis zur Paketaktualisierung.
  • /jetson-customize-nvpmodel — Verwandtes Thema: nvpmodel-Leistungsmodi. Die pro Takt geltende Obergrenze des aktiven Modus wird unterhalb der BPMP-DTB-Obergrenze begrenzt.
Auf GitHub ansehen
---
name: jetson-customize-clocks
description: Lock, cap, or customize CPU, GPU, and EMC clock behavior on NVIDIA Jetson devices by editing BPMP DTB and nvpower.sh before flashing.
license: Apache-2.0
---

# Customize Clocks

## Purpose

Customize CPU, GPU, and EMC clock behavior on a Jetson target by editing files under `Linux_for_Tegra/` before flashing the image. Two layers are in scope:

- The **BPMP DTB** at `Linux_for_Tegra/bootloader/<BPFDTB_FILE>` — per-clock `max-rate-custom` ceilings, plus the EMC DVFS gate (bwmgr + cactmon on all SoCs; osp-controller on T26x only).
- **nvpower.sh** at `Linux_for_Tegra/rootfs/etc/systemd/nvpower.sh` — cpufreq / devfreq governors and (optionally) per-device min / max / static rates written to sysfs at boot.

Common triggers: "lock CPU/GPU/EMC frequency", "pin GPU to Fmax", "pin EMC to MAXN", "disable/enable EMC DVFS", "disable/enable CPU DVFS", "set CPU/GPU max rate", "change cpufreq governor".

Out of scope: runtime clock tuning on a live target (no flash step), nvpmodel power-mode edits (use the sibling skill `/jetson-customize-nvpmodel`), and silicon-ceiling overrides (`max-rate-maxn` is read-only).

## 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
(Operation 1's BPMP DTB and Operation 2's `nvpower.sh`) 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.

## Instructions

1. Resolve the prerequisites above (active profile, BSP image extracted, source overlay tracker initialized).
2. Pick the operation from the table below.
3. Follow the linked procedure section — Operation 1 (BPMP DTB), Operation 2 (`nvpower.sh`), or the MAXN recipe for both.
4. Commit the edit inside the overlay tracker per each Operation's commit convention.
5. Deploy with `/jetson-promote-image` → `/jetson-flash-image`. The new BPMP DTB and `nvpower.sh` take effect on the next boot.

### Supported operations

| Operation | Where the edit lives | Procedure section |
|---|---|---|
| Lock a CPU / GPU clock to a specific rate | BPMP DTB `max-rate-custom` on the clock node + `nvpower.sh` governor `performance` | "Content edit: `max-rate-custom`" + "Pick the edit" |
| Lock EMC at its init rate (disable EMC DVFS) | BPMP DTB: `bwmgr.enabled = 0`, `cactmon.enabled = 0`, plus `/delete-node/ osp-controller` on T26x only | "Content edit: EMC DVFS disable / enable" |
| Re-enable EMC DVFS | BPMP DTB: `bwmgr.enabled = 1`, `cactmon.enabled = 1`, restore `osp-controller` on T26x | "Content edit: EMC DVFS disable / enable" |
| Pin everything to MAXN for stress runs | Combine the above + nvpmodel MAXN as boot default | see Recipe |
| Lower a clock's hard ceiling without locking | BPMP DTB `max-rate-custom` only | "Content edit: `max-rate-custom`" |
| Bound a device's rate without pinning | `nvpower.sh` min/max via sysfs | "Pick the edit" |

## Operation 1 — BPMP DTB edits

Follow the BPMP-DTB customization protocol in
[`../../references/bsp-customization-bpmp-dtb.md`](../../references/bsp-customization-bpmp-dtb.md).
The protocol owns the mechanics — pristine import on first touch,
`dtc` decompile, recompile, sanity-check, commit. This skill
supplies only the **clock-specific content** (which nodes and
properties to edit during the protocol's "Edit the DTS" step).

The edited `.dtb` lands in the `<source.root_path>/Linux_for_Tegra/`
overlay tracker. `/jetson-promote-image`'s channel A walks the
tracker and copies the file into `bsp_image`. **Do not edit
`<bsp_image.root_path>/Linux_for_Tegra/bootloader/<bpmp-dtb>`
directly** — that's the promote output, not an input.

### Resolve the SKU-correct BPMP DTB

Per the protocol's "Resolving the active BPMP DTB" section, read
`BPFDTB_FILE` from the active flash conf. For the common Thor /
single-SKU conf shapes this is the static `BPFDTB_FILE=...` line
in the per-board `.conf` and the value is authoritative as-is.

For **SKU-multiplexed conf shapes** (Orin AGX devkit conf chain
that selects a different BPMP DTB per `board_sku`/`board_FAB`
via `update_flash_args_common` — see
[`../../context/bsp-customization-software-layers.md#per-board-conf-dispatch--update_flash_args_common`](../../context/bsp-customization-software-layers.md#per-board-conf-dispatch--update_flash_args_common)),
walk the dispatch chain with `board_sku=<module.sku>` and
`board_FAB=<module.revision or empty>` from the active profile,
and read `BPFDTB_FILE` from the dispatch output — **not** from
the static line of the per-board `.conf`. Static and dispatched
values match for non-multiplexed confs; the dispatch is
mandatory only when the conf chain conditionally overrides
`BPFDTB_FILE`.

### List effective max rates (inspection)

Inspect both layers of the runtime ceiling — see [`references/clock-control-model.md#effective-runtime-ceiling`](references/clock-control-model.md#effective-runtime-ceiling) — before deciding on a `max-rate-custom` value.

Inspection cookbook (BPMP-side decompile + grep; nvpmodel-side awk over the boot default mode) is in [`references/bpmp-dtb-clock-edits.md#inspection-cookbook`](references/bpmp-dtb-clock-edits.md#inspection-cookbook).

For the nvpmodel layer see [`/jetson-customize-nvpmodel`](../jetson-customize-nvpmodel/SKILL.md).

This step does not mutate state — it's a precondition for sizing
the edit in the "Content edit: `max-rate-custom` on a named clock node" step.

### Content edit: `max-rate-custom` on a named clock node

During the "Edit the DTS" step of the protocol, modify the property
inside the named clock node — never `lateinit`. `max-rate-custom`
must be strictly below the clock's hard cap (`max-rate-maxn` if
defined, otherwise the live `max_rate` from a running target of
the same chip / SKU).

DTS edit form, semantics, and the nvpmodel ↔ BPMP clock-node
mapping live in [`references/bpmp-dtb-clock-edits.md`](references/bpmp-dtb-clock-edits.md).

Then hand control back to the protocol — its "Recompile", "Sanity-check
the recompiled blob", "Stage in the overlay tracker", and "Cleanup"
steps cover the rest.
Commit-message convention per the protocol:
`<BPMP_BASENAME>: jetson-customize-clocks — <clock-node> max-rate-custom = <value>`.

### Content edit: EMC DVFS disable / enable

Default behavior (EMC DVFS on) requires no edit. Disabling EMC
DVFS is a **multi-node edit** applied inside the same "Edit the DTS" step of
the protocol, **not** a `bwmgr` toggle:

| # | Edit | Scope |
|---|---|---|
| 1 | `bwmgr.enabled = <0x00>` | All SoCs, mandatory |
| 2 | `cactmon.enabled = <0x00>` | All SoCs, mandatory |
| 3 | `/delete-node/ osp-controller` | **T26x (Thor) mandatory** — T23x (Orin) has no such node, skip |

Detection: `dtc -I dtb -O dts <bpmp-dtb> | grep -c osp-controller`
— zero hits ⇒ T23x path. Full DTS snippets, the surviving-paths
failure modes, and the re-enable procedure are in
[`references/emc-dvfs-disable.md`](references/emc-dvfs-disable.md).

Apply the protocol's "Recompile" through "Cleanup" steps once the multi-node edit is in
place. Commit-message convention:
`<BPMP_BASENAME>: jetson-customize-clocks — EMC DVFS disable (bwmgr + cactmon[+ osp-controller])`.

Disabling raises idle power; intended for stress / performance
tests, not production rootfs.

### Re-run + idempotency

Per the protocol's "Re-runnability" section, re-running this
skill with the same target value produces a no-op commit. Re-
running with a different value rewrites the same property — `git
log -- $BPMP_REL` shows the per-run history. To return a clock
to its `max-rate-maxn` ceiling, edit the DTS to remove the
`max-rate-custom` line and recompile.

## Operation 2 — nvpower.sh edits

Edits `nvpower.sh`, which runs at boot via `nvpower.service` to set
cpufreq / devfreq governors and rates.

### The per-script file

The script this Operation edits has the relative path:

```
Linux_for_Tegra/rootfs/etc/systemd/nvpower.sh
```

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

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

Subsequent sub-steps refer to **the per-script file** to mean the overlay
copy under `<source.root_path>`. The `<bsp_image.root_path>` copy is read
once during the pristine-import step below, then never touched again.

### Overlay edit recipe (apply before editing nvpower.sh)

Follow the canonical
[Off-skill edits recipe](../../context/bsp-customization-workflow.md#off-skill-edits)
in the workflow doc — pristine import + customization commit pair, both
gated by the preview gate. `nvpower.sh` is a single file with no
propagation set; one pristine commit + one customization commit covers
the entire change.

Concrete substitutions for this skill:

- `<rel>/<file>` is `rootfs/etc/systemd/nvpower.sh`.
- Suggested pristine-import message:
  `import pristine: rootfs/etc/systemd/nvpower.sh`,
  body `Source: <bsp_image.root_path>/Linux_for_Tegra/ (BSP <bsp_image.version>)`.
- Suggested customization-commit header:
  `jetson-customize-clocks: nvpower.sh <summary>`,
  body lines like `set_cpufreq_governor: desired_cpufreq_gov "schedutil" -> "performance"`.

### Pick the edit

Function locations (`set_cpufreq_governor`, `set_devfreq_governor`), common-edit recipes (pin to Fmax, static rate, min/max bounds), and the `nvidia-l4t-init` package-upgrade caveat live in [`references/nvpower-sh-edits.md`](references/nvpower-sh-edits.md).

### Deploy

The customization commit in the overlay tracker does not reach the device
on its own. The Deploy chain:

1. **`/jetson-promote-image`** — copies every tracked file in the overlay
   into `<bsp_image.root_path>/Linux_for_Tegra/`. Diff-aware (skip
   byte-identical); uses `sudo cp -p` for `rootfs/*` destinations.
2. **`/jetson-flash-image`** — flashes the updated `bsp_image` to the
   device. `nvpower.service` runs the new script on the next boot.
3. (Alternate, no flash) Copy `<source.root_path>/Linux_for_Tegra/rootfs/etc/systemd/nvpower.sh`
   directly to the running target's `/etc/systemd/nvpower.sh`, then
   `sudo systemctl restart nvpower.service` (or reboot).

Editing `<source.root_path>/...` without committing — or editing
`<bsp_image.root_path>/...` directly — does nothing for `/jetson-promote-image`
and is silently lost on the next `/jetson-init-image` re-extract.

## Recipe — pin everything to MAXN for stress / performance runs

Combines Operations 1 + 2. Operation 1's BPMP edits all flow
through one round of the protocol (a single decompile / multi-node
edit / recompile / commit cycle — don't round-trip the protocol
twice for the same `.dtb`):

1. **BPMP DTB** (the "Content edit: `max-rate-custom` on a named clock node" step content): leave `max-rate-custom` unset on every CPU / GPU / EMC clock; remove existing `max-rate-custom` lines that lower the ceiling.
2. **BPMP DTB** (the "Content edit: EMC DVFS disable / enable" step content): pin EMC at its init rate — `bwmgr.enabled = 0`, `cactmon.enabled = 0`, plus `/delete-node/ osp-controller` on T26x (skip on T23x).
3. Apply both content edits inside one protocol "Edit the DTS" invocation, then run the remaining protocol steps (recompile, sanity-check, single customization commit covering both content edits).
4. **nvpower.sh** (Operation 2): set `desired_cpufreq_gov="performance"` and `desired_devfreq_gov="performance"` unconditionally; remove the GPU/nvjpg skip in `set_devfreq_governor`. Applies via Operation 2's overlay edit recipe (the "Overlay edit recipe (apply before editing nvpower.sh)" step) — a separate overlay-tracker pristine + customization commit pair on the rootfs script, distinct from the BPMP-DTB protocol's commit.
5. Set the boot-default nvpmodel mode to MAXN via [`/jetson-customize-nvpmodel`](../jetson-customize-nvpmodel/SKILL.md) — the per-clock nvpmodel cap clamps below `max-rate-maxn` regardless of BPMP DTB content.

Deploy [`/jetson-promote-image`](../jetson-promote-image/SKILL.md) → [`/jetson-flash-image`](../jetson-flash-image/SKILL.md) picks up the new BPMP DTB (via the overlay tracker) and the edited `nvpower.sh` (via the same overlay tracker) on the next flash.

## Limitations

- **Image-build-time only.** All edits land under `<source.root_path>/Linux_for_Tegra/` and reach the device only via `/jetson-promote-image` → `/jetson-flash-image`. Live-target tuning is out of scope.
- **`max-rate-custom` only lowers the ceiling.** It must be strictly below `max-rate-maxn`; raising the silicon cap is not supported.
- **Effective ceiling is two-layer.** The runtime ceiling is `min(BPMP cap, active-nvpmodel-mode cap)`. The nvpmodel cap is owned by `/jetson-customize-nvpmodel`; this skill does not edit it.
- **SoC-conditional EMC DVFS gate.** Disabling EMC DVFS requires editing different node sets on T23x (bwmgr + cactmon) vs T26x (bwmgr + cactmon + delete `osp-controller`). Mis-detection produces undefined behavior.
- **T23x GPU cap is multi-node.** The GPU clock is split across `nafll_gpusys` and every `nafll_gpcX`; the cap binds only when applied to all of them.
- **`nvpower.sh` is package-managed.** It ships in `nvidia-l4t-init`; package upgrades clobber in-place edits. Long-lived setups should prefer a systemd drop-in or sibling helper.
- **ODMDATA wins.** When an ODMDATA token covers a property, the token overrides direct BPMP DTS edits at flash time. Direct BPMP DTS edits are the fallback for properties no NVIDIA token reaches.
- **`max-rate-maxn` and `lateinit` are off-limits.** `max-rate-maxn` is the silicon ceiling (read-only). `lateinit` is for boot-time clock init, not ceiling overrides — never touch either.
- **BPMP DTB may be SKU-multiplexed.** On compound / dispatched flash confs (Orin AGX devkit chain), `BPFDTB_FILE` is selected by `board_sku` / `board_FAB` via `update_flash_args_common`. Reading the static `BPFDTB_FILE=` line is wrong when the chain conditionally overrides it; resolve via the dispatch instead.

## Troubleshooting

| Error | Cause | Solution |
|---|---|---|
| `max-rate-custom` set but clock still ramps to `max-rate-maxn` on T23x GPU | Only `nafll_gpusys` was capped; the `nafll_gpcX` partitions still run at `max-rate-maxn` and dominate the effective ceiling. | Apply the same `max-rate-custom` to `nafll_gpusys` **and** every `nafll_gpcX` node enumerated by `grep -nE '^\s*nafll_gpc[0-9]+\s*:' <decompiled.dts>`. |
| EMC DVFS disable appears to apply but EMC still scales on T26x | Only `bwmgr.enabled = <0x00>` was set; `osp-controller` survives and re-issues frequency changes via the QoS path. | Add edits #2 (`cactmon.enabled = <0x00>`) and #3 (`/delete-node/ osp-controller`) inside the same "Edit the DTS" step. Verify `osp-controller` via `dtc -I dtb -O dts <bpmp-dtb> \| grep -c osp-controller` → expect 0. |
| EMC DVFS disable rejected on T23x with "node not found" for `osp-controller` | T23x (Orin) BPMP DTBs do not contain `osp-controller`; edit #3 must be skipped on T23x. | Detect SoC family with the `grep -c osp-controller` step; only apply #3 when the count is ≥1. |
| BPMP refuses to load DTB after edit: `max-rate-custom >= max-rate-maxn` | `max-rate-custom` was set to or above the silicon ceiling. | Lower `max-rate-custom` strictly below `max-rate-maxn`. If `max-rate-maxn` is absent from the node, query the live cap on a running target: `cat /sys/kernel/debug/bpmp/debug/clk/<clock>/max_rate`. |
| `osp-controller` re-appears after `status = "disabled"` | `status = "disabled"` does not remove the node from the device tree; BPMP still walks it. | Replace with `/delete-node/ osp-controller;` — the node must not exist for BPMP to skip the path. |
| Edits to `nvpower.sh` lost after `apt upgrade` | `nvpower.sh` is owned by the `nvidia-l4t-init` deb and gets overwritten on upgrade. | For long-lived test setups, package edits into a systemd drop-in or a sibling helper file referenced by `nvpower.sh`, rather than editing `nvpower.sh` in place. |
| `/jetson-promote-image` is a no-op after editing the BPMP DTB | The edit was applied to `<bsp_image.root_path>/Linux_for_Tegra/`, which is `/jetson-promote-image`'s output — not its input. | Move the edit to `<source.root_path>/Linux_for_Tegra/bootloader/<BPFDTB_FILE>` (the overlay tracker) and commit through the BPMP-DTB protocol. |
| Cap appears to apply on first boot then resets after a power-mode change | The active nvpmodel mode's per-clock cap clamps below `max-rate-custom`. | Inspect both layers; if nvpmodel is binding, raise (or remove) the nvpmodel cap via `/jetson-customize-nvpmodel`. The BPMP cap alone is not the runtime ceiling. |

## References

- [`../../references/bsp-customization-bpmp-dtb.md`](../../references/bsp-customization-bpmp-dtb.md) — canonical BPMP-DTB customization protocol (pristine import, decompile, edit, recompile, sanity-check, commit). Operation 1 of this skill is a content-only consumer; the protocol owns the mechanics.
- [`references/clock-control-model.md`](references/clock-control-model.md) — layer stack, two-ceilings overview, effective-runtime-ceiling formula.
- [`references/bpmp-dtb-clock-edits.md`](references/bpmp-dtb-clock-edits.md) — two-ceilings semantics, DTS edit form, nvpmodel ↔ BPMP clock-node mapping, inspection cookbook.
- [`references/emc-dvfs-disable.md`](references/emc-dvfs-disable.md) — full SoC-conditional EMC DVFS disable procedure with DTS snippets, detection, re-enable.
- [`references/nvpower-sh-edits.md`](references/nvpower-sh-edits.md) — `nvpower.sh` function locations + common-edit recipes + package-upgrade caveat.
- [`/jetson-customize-nvpmodel`](../jetson-customize-nvpmodel/SKILL.md) — sibling skill: nvpmodel power modes. The active mode's per-clock cap clamps below the BPMP DTB cap.

jetson-customize-clocks installieren

Laden Sie die Skill-Dateien herunter und entpacken Sie sie in Ihr Verzeichnis „.claude/skills/“.

ZIP herunterladen

Klonen Sie das Repository und kopieren Sie die Skill-Dateien in Ihr Projekt.

git clone https://github.com/NVIDIA/skills/tree/main/skills/jetson-customize-clocks # Copy SKILL.md to your .claude/skills/ directory

Kopieren Kopieren
Schnelle Einrichtung: Kopiere den Skill-Ordner nach .claude/skills/. Claude erkennt den Skill automatisch und nutzt ihn.
Repository NVIDIA/skills

Ähnliche Skills

Verification &amp; Quality Assurance
Zeit aktualisiert 29. Juni 2026
klingai-upgrade-migration
Zeit aktualisiert 3. Juli 2026
base44-cli
Zeit aktualisiert 29. Juni 2026
Railway CLI Management
Zeit aktualisiert 2. Juli 2026
OR