選項
首頁首頁 Skill 開發營運和 CI/CD jetson-customize-clocks

jetson-customize-clocks

NVIDIA/skills NVIDIA/skills

在燒錄前,透過編輯 BPMP DTB 和 nvpower.sh 檔案,鎖定、限制或自訂 NVIDIA Jetson 裝置上的 CPU、GPU 及 EMC 時脈行為。

...展開全部
0
更新時間 2026-09-25

自訂時鐘

目的

透過編輯 Linux_for_Tegra/ 下的檔案,以自訂 Jetson 目標裝置上的 CPU、GPU 及 EMC 時脈行為。此範圍涵蓋兩個層級:

  • 位於 Linux_for_Tegra/bootloader/ — 每時鐘 max-rate-custom 上限,以及 EMC DVFS 閘控(所有 SoC 上的 bwmgr + cactmon;僅 T26x 上的 osp-controller)。
  • 位於的 nvpower.sh —— 包含 Linux_for_Tegra/rootfs/etc/systemd/nvpower.sh — cpufreq / devfreq 調速器,以及(可選)開機時寫入 sysfs 的各裝置最小/最大/靜態速率。

常見觸發條件:「鎖定 CPU/GPU/EMC 頻率」、「將 GPU 鎖定至 Fmax」、「將 EMC 鎖定至 MAXN」、「禁用/啟用 EMC DVFS」、「禁用/啟用 CPU DVFS」、「設定 CPU/GPU 最大速率」、「變更 cpufreq 調速器」。

不在範圍內:在運行中的目標系統上進行即時時鐘調校(不涉及快閃記憶體重寫)、nvpmodel 電源模式編輯(請使用同級技能 /jetson-customize-nvpmodel),以及矽晶片上限的覆寫(max-rate-maxn 為唯讀)。

先決條件

根據 ../../context/target-platform-contract.md。 在以下情況下應拒絕並重新路由:

條件 以
無有效設定檔,或 active: NA 轉送至 /jetson-set-target 或 /jetson-init-target.
個人資料缺少 bsp_image: 封鎖 路由至 /jetson-init-image.
/Linux_for_Tegra/ 遺漏 路由至 /jetson-init-image.
/Linux_for_Tegra/ 遺失或非 Git 儲存庫 導向至 /jetson-init-source.

解析路徑:

  • 從 bsp_image.root_path: 若存在,否則 /Image.
  • 從 source.root_path: 若存在則,否則 /Source.

對此技能而言為唯讀;每次寫入 (操作 1 的 BPMP DTB 及操作 2 的 nvpower.sh) 都會被歸入 (疊加追蹤器)之下。這是工作流程 的不變性,在 ../../context/bsp-customization-workflow.md#workflow-invariants — 手動編輯上游會默默地破壞差異追蹤,並使 /jetson-promote-image 無操作。

操作說明

  1. 解決上述先決條件(啟用配置檔、已提取 BSP 映像、已初始化原始碼疊加追蹤器)。
  2. 從下表中選擇操作。
  3. 依照連結的程序章節操作 — 操作 1(BPMP DTB)、操作 2(nvpower.sh),或同時適用於兩者的 MAXN 處方。
  4. 根據各操作的提交規範,將覆疊追蹤器內的編輯內容提交。
  5. 使用 /jetson-promote-image → /jetson-flash-image進行部署。新的 BPMP DTB 將 nvpower.sh 將於下次開機時生效。

支援的操作

操作 編輯位置 程序區段
將 CPU / GPU 時脈鎖定至特定頻率 BPMP DTB max-rate-custom 在時脈節點上 + nvpower.sh 調速器 performance 「內容編輯: max-rate-custom" + "選擇編輯"
將 EMC 鎖定在其初始速率(停用 EMC DVFS) BPMP DTB: bwmgr.enabled = 0, cactmon.enabled = 0,以及 /delete-node/ osp-controller 僅限 T26x 系列 「內容編輯:EMC DVFS 停用/啟用」
重新啟用 EMC DVFS BPMP DTB: bwmgr.enabled = 1, cactmon.enabled = 1,還原 osp-controller 於 T26x 上 「內容編輯:EMC DVFS 停用/啟用」
將所有設定鎖定為 MAXN 以進行壓力測試 將上述設定與 nvpmodel MAXN 結合為開機預設值 參見操作指南
在不鎖定狀態下降低時脈的硬性上限 BPMP DTB max-rate-custom 僅此 「內容編輯: max-rate-custom"
在不固定最小/最大值的情況下限制裝置的速率 nvpower.sh 透過 sysfs 設定最小/最大值 "選擇此編輯"

操作 1 — BPMP DTB 編輯

請遵循 BPMP-DTB 自訂協定,詳見 ../../references/bsp-customization-bpmp-dtb.md中的 BPMP-DTB 自訂協定。 該協定負責具體機制 — 首次處理時進行原始匯入、 dtc 反編譯、重新編譯、合理性檢查、提交。此技能 僅提供時鐘相關的內容(在協議的「編輯 DTS」步驟中, 應編輯哪些節點與屬性)。

經編輯的 .dtb 結果將存入 /Linux_for_Tegra/ 疊加追蹤器中。 /jetson-promote-image的 A 通道會遍歷 追蹤器,並將檔案複製至 bsp_image。 請勿直接編輯 /Linux_for_Tegra/bootloader/——那是推廣輸出,而非輸入。

解析 SKU 正確的 BPMP DTB

根據協議中「解析有效的 BPMP DTB」一節所述,請從 BPFDTB_FILE 自活躍的快閃記憶體配置中讀取。對於常見的 Thor / 單一 SKU 配置格式,這是一行靜態 BPFDTB_FILE=... 行 , .conf 中的靜態行,其值原樣即具權威性。

對於 SKU 多工配置型態(Orin AGX 開發套件的配置鏈 會根據 board_sku/board_FAB via update_flash_args_common ——參見 ../../context/bsp-customization-software-layers.md#per-board-conf-dispatch--update_flash_args_common), 請使用 board_sku= 並 board_FAB= 從活躍的配置檔中, 並從 BPFDTB_FILE 從分派輸出中讀取 — 而非從 每塊電路板的靜態行 .conf的靜態行。對於非多工配置,靜態值與分派值 相符;分派僅在配置鏈有條件地覆寫時 才屬強制要求 BPFDTB_FILE.

列出有效最大速率(檢查)

檢查運行時上限的兩層 — 參見 references/clock-control-model.md#effective-runtime-ceiling ——在決定 max-rate-custom 值之前,請檢查運行時上限的兩層 — 參見—。

檢查操作指南(BPMP 端反編譯 + grep;nvpmodel 端在開機預設模式下使用 awk)位於 references/bpmp-dtb-clock-edits.md#inspection-cookbook.

關於 nvpmodel 層,請參閱 /jetson-customize-nvpmodel.

此步驟不會改變狀態——這是「內容編輯: 在指定時鐘節點上」步驟中進行編輯 所需的先決條件。 max-rate-custom 針對命名時鐘節點」步驟中的編輯進行調整。

內容編輯: max-rate-custom 在命名時鐘節點上

在協定中的「編輯 DTS」步驟期間,請修改 命名時鐘節點內的屬性 —— 切勿 lateinit. max-rate-custom 必須嚴格低於時鐘的硬性上限(max-rate-maxn 若 已定義;否則,即時 max_rate 來自 同一晶片/SKU 的運行中目標)。

DTS 編輯表單、語義,以及 nvpmodel ↔ BPMP 時鐘節點 對應關係皆存於 references/bpmp-dtb-clock-edits.md.

接著將控制權交還給協定 — 其「重新編譯」、「對重新編譯後的 blob 進行 合理性檢查」、「在覆蓋追蹤器中階段化」以及「清理」 步驟將處理其餘部分。 根據協定規範的提交訊息慣例: : jetson-customize-clocks — max-rate-custom = .

內容編輯:EMC DVFS 停用/啟用

預設行為(EMC DVFS 啟用)無需編輯。停用 EMC DVFS 屬於在協定中同一「編輯 DTS」步驟內執行的多節點編輯,而非 bwmgr 切換操作:

# 編輯 範圍
1 bwmgr.enabled = <0x00> 所有 SoC,強制適用
2 cactmon.enabled = <0x00> 所有 SoC,必選
3 /delete-node/ osp-controller T26x(Thor)為必選項目 — T23x(Orin)無此節點,請跳過

偵測: dtc -I dtb -O dts | grep -c osp-controller — 零個匹配 ⇒ T23x 路徑。完整的 DTS 片段、存活路徑 的故障模式,以及重新啟用程序均位於 references/emc-dvfs-disable.md.

完成多節點編輯後,請依序執行該協議中的「重新編譯」至「清理」步驟 。提交訊息規範: : jetson-customize-clocks — EMC DVFS disable (bwmgr + cactmon[+ osp-controller]).

停用會提高閒置功耗;此功能旨在用於壓力/效能 測試,不適用於生產環境的 rootfs。

重新執行 + 幂等性

根據協議中「可重跑性」章節所述,以相同目標值 重新執行此技能將產生無操作提交。若 使用不同值重新執行,則會重新寫入同一屬性 — git log -- $BPMP_REL 顯示每次執行的歷史紀錄。若要將時鐘 恢復至其 max-rate-maxn 上限,請編輯 DTS 以移除該 max-rate-custom 該行並重新編譯。

操作 2 — nvpower.sh 編輯

編輯 nvpower.sh,該檔案會在開機時透過 nvpower.service 在開機時執行,用以設定 cpufreq / devfreq 調速器及其頻率。

該腳本的相對路徑為

此操作所編輯的腳本其相對路徑為:

Linux_for_Tegra/rootfs/etc/systemd/nvpower.sh

該檔案位於兩個根目錄下;此操作會遍歷兩者:

角色 位置 技能會寫入嗎?
偵測 + 原始來源 /Linux_for_Tegra/rootfs/etc/systemd/ 否 — 唯讀
疊加編輯目標 + Git 提交 /Linux_for_Tegra/rootfs/etc/systemd/ 是

後續的子步驟中所指的「每份腳本檔案」,意指位於 下的覆疊 副本 。該 該副本 會在下方的 pristine-import 步驟中讀取一次,之後便不再被觸及。

疊加編輯流程(在編輯 nvpower.sh 之前套用)

請遵循工作流程文件中標準的 「非專業技能編輯」流程 ——即「原始匯入」與「自訂提交」的組合,兩者皆 受預覽閘門控制。 nvpower.sh 是一個未設定 傳播範圍的單一檔案;一個原始提交 + 一個自訂提交即可涵蓋 整個變更。

針對此技能的具體替換:

  • / 是 rootfs/etc/systemd/nvpower.sh.
  • 建議的原始匯入訊息: import pristine: rootfs/etc/systemd/nvpower.sh, 正文 Source: /Linux_for_Tegra/ (BSP ).
  • 建議的自訂提交標頭: jetson-customize-clocks: nvpower.sh , 正文內容例如 set_cpufreq_governor: desired_cpufreq_gov "schedutil" -> "performance".

選擇編輯

函式位置(set_cpufreq_governor, set_devfreq_governor)、常見編輯配方(固定至 Fmax、靜態速率、最小/最大範圍),以及 nvidia-l4t-init 套件升級注意事項皆位於 references/nvpower-sh-edits.md.

部署

覆疊追蹤器中的自訂提交並不會 自動傳送至裝置。部署鏈:

  1. /jetson-promote-image — 將覆疊層中每個受追蹤的檔案 複製到 /Linux_for_Tegra/。支援差異比對(跳過 位元組完全相同的檔案);使用 sudo cp -p 作為 rootfs/* 。
  2. /jetson-flash-image — 將更新後的 bsp_image 至 裝置。 nvpower.service 在下次開機時執行新腳本。
  3. (替代方案,不進行燒錄)將 /Linux_for_Tegra/rootfs/etc/systemd/nvpower.sh 直接複製到正在運行的目標系統的 /etc/systemd/nvpower.sh,然後 sudo systemctl restart nvpower.service (或重新開機)。

編輯 /... 而不提交 — 或直接編輯 /... 直接編輯) /jetson-promote-image ,並會在下次 /jetson-init-image 重新提取時會無聲無息地消失。

操作指南 — 將所有項目固定為 MAXN 以進行壓力測試/效能測試

結合操作 1 與 2。操作 1 的 BPMP 會將所有流程 整合至一輪協定中(單一反編譯/多節點 編輯/重新編譯/提交週期——切勿為同一項 .dtb):

  1. BPMP DTB(「內容編輯: max-rate-custom 在指定時鐘節點上」步驟的內容):讓 max-rate-custom 在每個 CPU/GPU/EMC 時鐘上保持未設定狀態;移除現有的 max-rate-custom 會降低上限的現有行。
  2. BPMP DTB(「內容編輯:EMC DVFS 停用/啟用」步驟內容):將 EMC 鎖定在初始速率 — bwmgr.enabled = 0, cactmon.enabled = 0,並 /delete-node/ osp-controller 在 T26x 上執行(T23x 上跳過)。
  3. 將這兩項內容編輯應用於單一「編輯 DTS」協議呼叫中,然後執行剩餘的協議步驟(重新編譯、合理性檢查,以及涵蓋這兩項內容編輯的單一自訂提交)。
  4. nvpower.sh(操作 2):設定 desired_cpufreq_gov="performance" 並 desired_devfreq_gov="performance" 無條件地;移除 set_devfreq_governor中移除 GPU/nvjpg 的跳過設定。透過操作 2 的疊加編輯配方(「疊加編輯配方(在編輯 nvpower.sh 之前套用)」步驟)進行套用——這是在 rootfs 腳本上獨立的疊加追蹤器原始狀態 + 自訂提交對,有別於 BPMP-DTB 協議的提交。
  5. 透過 /jetson-customize-nvpmodel —— 每時鐘週期的 nvpmodel 上限將被限制在 max-rate-maxn ,無論 BPMP DTB 內容為何。

部署 /jetson-promote-image → /jetson-flash-image 會(透過覆蓋追蹤器)擷取新的 BPMP DTB,並將編輯後的 nvpower.sh (透過相同的覆蓋追蹤器)於下一次快閃寫入中。

限制

  • 僅限映像建置時。所有編輯內容皆會納入 /Linux_for_Tegra/ ,且僅能透過 /jetson-promote-image → /jetson-flash-image。即時目標調校不在本範疇內。
  • max-rate-custom 僅會降低上限。其數值必須嚴格低於 max-rate-maxn;不支援提高矽片上限。
  • 有效上限分為兩層。執行時上限為 min(BPMP cap, active-nvpmodel-mode cap)。nvpmodel 上限由 /jetson-customize-nvpmodel;此技能不會修改該上限。
  • SoC 條件式 EMC DVFS 閘。若要停用 EMC DVFS,需針對 T23x(bwmgr + cactmon)與 T26x(bwmgr + cactmon + 刪除 osp-controller)。錯誤偵測將導致未定義行為。
  • T23x 的 GPU 上限為多節點。GPU 時脈分佈於 nafll_gpusys ,且每個 nafll_gpcX;該上限僅在套用至所有節點時才會生效。
  • nvpower.sh 由套件管理。其隨 nvidia-l4t-init;套件升級會覆寫原地編輯。長期運作的設定應優先採用 systemd 即插即用方案或同級輔助工具。
  • ODMDATA 具有優先權。當 ODMDATA 標記涵蓋某個屬性時,該標記會在閃存寫入時覆寫直接的 BPMP DTS 編輯。直接的 BPMP DTS 編輯僅作為 NVIDIA 標記未涵蓋之屬性的備用方案。
  • max-rate-maxn 以及lateinit均不可用。 max-rate-maxn 是晶片層級的上限(唯讀)。 lateinit 用於開機時的時鐘初始化,而非上限覆寫 — 切勿觸碰這兩項。
  • BPMP DTB 可能採用 SKU 多工配置。在複合/分發式快閃記憶體配置中(Orin AGX 開發套件鏈), BPFDTB_FILE 由 board_sku / board_FAB 透過 update_flash_args_common。當鏈路以條件方式覆寫靜態 BPFDTB_FILE= 行是錯誤的,因為鏈路會根據條件覆寫該設定;應透過分派機制來解決。

疑難排解

錯誤 原因 解決方案
max-rate-custom 已設定,但時脈仍會上升至 max-rate-maxn T23x GPU 僅 nafll_gpusys 被限制; nafll_gpcX 分區仍以 max-rate-maxn ,並主導了實際上限。 套用相同的 max-rate-custom 至 nafll_gpusys ,並將每個 nafll_gpcX 由 grep -nE '^\s*nafll_gpc[0-9]+\s*:' .
EMC DVFS 停用似乎已生效,但 EMC 在 T26x 上仍會進行擴展 僅 bwmgr.enabled = <0x00> 被設定; osp-controller 仍能存活,並透過 QoS 路徑重新發出頻率變更指令。 新增編輯 #2 (cactmon.enabled = <0x00>) 和 #3 (/delete-node/ osp-controller) 置於同一個「編輯 DTS」步驟中。確認 osp-controller 透過 dtc -I dtb -O dts | grep -c osp-controller → 預期結果為 0。
在 T23x 上,EMC DVFS 停用遭駁回,並針對 osp-controller T23x (Orin) BPMP DTB 未包含 osp-controller;在 T23x 上必須跳過編輯 #3。 透過 grep -c osp-controller 步驟偵測 SoC 系列;僅當計數值 ≥1 時才套用 #3。
編輯後 BPMP 拒絕載入 DTB: max-rate-custom >= max-rate-maxn max-rate-custom 被設定為等於或高於晶片上限。 降低 max-rate-custom 嚴格低於 max-rate-maxn。若 max-rate-maxn 該節點中不存在此參數,請查詢正在運行的目標上的即時上限: cat /sys/kernel/debug/bpmp/debug/clk//max_rate.
osp-controller 在 status = "disabled" status = "disabled" 並不會將該節點從裝置樹中移除;BPMP 仍會遍歷該節點。 以 /delete-node/ osp-controller; — 該節點必須不存在,BPMP 才會跳過該路徑。
對 nvpower.sh 在 apt upgrade nvpower.sh 由 nvidia-l4t-init deb 所擁有,並會在升級時被覆寫。 對於長期運行的測試環境,請將套件編輯內容整合至 systemd 即插即用檔案,或整合至由 nvpower.sh,而非直接編輯 nvpower.sh 直接編輯該檔案。
/jetson-promote-image 在編輯 BPMP DTB 之後,此操作將無效 編輯內容已套用至 /Linux_for_Tegra/,該檔案 /jetson-promote-image的輸出——而非其輸入。 將該編輯移至 /Linux_for_Tegra/bootloader/ (疊加追蹤器)並透過 BPMP-DTB 協定提交。
上限值似乎在首次開機時生效,但在電源模式變更後會重置 當前 nvpmodel 模式的每時鐘週期上限被限制在 max-rate-custom. 檢查兩層;若 nvpmodel 已綁定,請透過 /jetson-customize-nvpmodel。僅靠 BPMP 上限並非執行時上限。

參考資料

  • ../../references/bsp-customization-bpmp-dtb.md — 標準 BPMP-DTB 自訂協定(原始匯入、反編譯、編輯、重新編譯、合理性檢查、提交)。此技能的操作 1 僅為內容消費者;協定本身負責機制運作。
  • references/clock-control-model.md — 層堆疊、雙上限概述、有效執行時上限公式。
  • references/bpmp-dtb-clock-edits.md — 雙上限語義、DTS 編輯表單、nvpmodel ↔ BPMP 時鐘節點映射、檢查實作指南。
  • references/emc-dvfs-disable.md — 完整的 SoC 條件式 EMC DVFS 停用程序,包含 DTS 程式碼片段、偵測與重新啟用步驟。
  • references/nvpower-sh-edits.md — nvpower.sh 函式位置 + 常用編輯範本 + 封裝升級注意事項。
  • /jetson-customize-nvpmodel — 相關技能:nvpmodel 功耗模式。活躍模式的每時鐘週期上限會被限制在 BPMP DTB 上限之下。
在 GitHub 上查看
---
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

請下載並將技能檔案解壓縮至您的 .claude/skills/ 目錄中。

下載 ZIP

複製儲存庫並將技能檔案複製到您的專案中。

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

複製 複製
快速設定: 將技能資料夾複製到 .claude/skills/ Claude 會自動偵測並使用該技能
儲存庫 NVIDIA/skills

相關技能

Verification &amp; Quality Assurance
更新時間 2026-06-29
klingai-upgrade-migration
更新時間 2026-07-03
base44-cli
更新時間 2026-06-29
Railway CLI Management
更新時間 2026-07-02
OR