jetson-customize-clocks
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 erweiternUhren 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/— diemax-rate-customObergrenzen 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. |
fehlt |
Route zu /jetson-init-image. |
fehlt oder ist kein Git-Repo |
Pfad zu /jetson-init-source. |
Pfade auflösen:
vonbsp_image.root_path:falls vorhanden, andernfalls./Image vonsource.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
- Erfüllen Sie die oben genannten Voraussetzungen (aktives Profil, extrahiertes BSP-Image, Quell-Overlay-Tracker initialisiert).
- Wählen Sie den Vorgang aus der folgenden Tabelle aus.
- Befolgen Sie den verlinkten Abschnitt zur Vorgehensweise – Vorgang 1 (BPMP-DTB), Vorgang 2 (
nvpower.sh) oder das MAXN-Rezept für beide. - Übernehmen Sie die Änderung im Overlay-Tracker gemäß den Übernahmeregeln des jeweiligen Vorgangs.
- Stellen Sie die Änderungen mit
/jetson-promote-image→/jetson-flash-image. Die neue BPMP-DTB undnvpower.shwerden 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
Overlay-Tracker. /jetson-promote-imageKanal A durchläuft den
Tracker und kopiert die Datei in bsp_image.
Bearbeiten Sie „
“ 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:
.
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
— 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:
.
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 | |
nein – schreibgeschützt |
| Overlay-Bearbeitungsziel + Git-Commit | |
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, TextSource:./Linux_for_Tegra/ (BSP ) - Vorgeschlagene Kopfzeile für den Anpassungs-Commit:
jetson-customize-clocks: nvpower.sh, Inhaltszeilen wieset_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:
/jetson-promote-image— kopiert jede nachverfolgte Datei im Overlay in. Diff-fähig (überspringt byte-identische Dateien); verwendet/Linux_for_Tegra/ sudo cp -pfürrootfs/*Ziele./jetson-flash-image— flasht die aktualisiertebsp_imageauf das Gerät.nvpower.serviceführt das neue Skript beim nächsten Systemstart aus.- (Alternative, ohne Flash) Kopiere
direkt in das Verzeichnis/Linux_for_Tegra/rootfs/etc/systemd/nvpower.sh /etc/systemd/nvpower.sh, dannsudo 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):
- BPMP-DTB (der Schritt „Inhaltsbearbeitung:
max-rate-customauf einem benannten Taktknoten“-Schritt): Lassen Siemax-rate-customauf jedem CPU-/GPU-/EMC-Takt ungesetzt; entferne vorhandenemax-rate-customZeilen, die die Obergrenze senken. - 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-controllerauf T26x (auf T23x überspringen). - 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).
- nvpower.sh (Vorgang 2): Setzen Sie
desired_cpufreq_gov="performance"unddesired_devfreq_gov="performance"bedingungslos; entfernen Sie das GPU/nvjpg-Überspringen inset_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. - Setzen Sie den nvpmodel-Modus für den Boot-Standard über
/jetson-customize-nvpmodel— die pro Takt geltende nvpmodel-Obergrenze wirdmax-rate-maxnunabhä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
und gelangen nur über/Linux_for_Tegra/ /jetson-promote-image→/jetson-flash-image. Die Anpassung am Live-Ziel liegt außerhalb des Anwendungsbereichs. max-rate-customsenkt lediglich die Obergrenze. Sie muss streng untermax-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_gpusysund jedenafll_gpcX; die Begrenzung gilt nur, wenn sie auf alle angewendet wird. nvpower.shwird über das Paket verwaltet. Es wird innvidia-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-maxnund „lateinit“ sind tabu.max-rate-maxnist die Hardware-Obergrenze (schreibgeschützt).lateinitdient 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_FILEwird ausgewählt durchboard_sku/board_FABüberupdate_flash_args_common. Das Auslesen der statischenBPFDTB_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 → 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/. |
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 , was /jetson-promote-imageAusgabe von — nicht auf dessen Eingabe. |
Verschieben Sie die Änderung in (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.shFunktionsstandorte + 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.
---
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.
Alle Dateien
9 Dateienjetson-customize-clocks installieren
Laden Sie die Skill-Dateien herunter und entpacken Sie sie in Ihr Verzeichnis „.claude/skills/“.
ZIP herunterladenKlonen 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





Heim
