jetson-customize-clocks
NVIDIA/skills
在燒錄前,透過編輯 BPMP DTB 和 nvpower.sh 檔案,鎖定、限制或自訂 NVIDIA Jetson 裝置上的 CPU、GPU 及 EMC 時脈行為。
...展開全部自訂時鐘
目的
透過編輯 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. |
遺漏 |
路由至 /jetson-init-image. |
遺失或非 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 無操作。
操作說明
- 解決上述先決條件(啟用配置檔、已提取 BSP 映像、已初始化原始碼疊加追蹤器)。
- 從下表中選擇操作。
- 依照連結的程序章節操作 — 操作 1(BPMP DTB)、操作 2(
nvpower.sh),或同時適用於兩者的 MAXN 處方。 - 根據各操作的提交規範,將覆疊追蹤器內的編輯內容提交。
- 使用
/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 結果將存入
疊加追蹤器中。 /jetson-promote-image的 A 通道會遍歷
追蹤器,並將檔案複製至 bsp_image。
請勿直接編輯
——那是推廣輸出,而非輸入。
解析 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 進行
合理性檢查」、「在覆蓋追蹤器中階段化」以及「清理」
步驟將處理其餘部分。
根據協定規範的提交訊息慣例:
.
內容編輯: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
— 零個匹配 ⇒ T23x 路徑。完整的 DTS 片段、存活路徑
的故障模式,以及重新啟用程序均位於
references/emc-dvfs-disable.md.
完成多節點編輯後,請依序執行該協議中的「重新編譯」至「清理」步驟
。提交訊息規範:
.
停用會提高閒置功耗;此功能旨在用於壓力/效能 測試,不適用於生產環境的 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
該檔案位於兩個根目錄下;此操作會遍歷兩者:
| 角色 | 位置 | 技能會寫入嗎? |
|---|---|---|
| 偵測 + 原始來源 | |
否 — 唯讀 |
| 疊加編輯目標 + Git 提交 | |
是 |
後續的子步驟中所指的「每份腳本檔案」,意指位於
下的覆疊
副本 。該 該副本
會在下方的 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.
部署
覆疊追蹤器中的自訂提交並不會 自動傳送至裝置。部署鏈:
/jetson-promote-image— 將覆疊層中每個受追蹤的檔案 複製到。支援差異比對(跳過 位元組完全相同的檔案);使用/Linux_for_Tegra/ sudo cp -p作為rootfs/*。/jetson-flash-image— 將更新後的bsp_image至 裝置。nvpower.service在下次開機時執行新腳本。- (替代方案,不進行燒錄)將
直接複製到正在運行的目標系統的/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):
- BPMP DTB(「內容編輯:
max-rate-custom在指定時鐘節點上」步驟的內容):讓max-rate-custom在每個 CPU/GPU/EMC 時鐘上保持未設定狀態;移除現有的max-rate-custom會降低上限的現有行。 - BPMP DTB(「內容編輯:EMC DVFS 停用/啟用」步驟內容):將 EMC 鎖定在初始速率 —
bwmgr.enabled = 0,cactmon.enabled = 0,並/delete-node/ osp-controller在 T26x 上執行(T23x 上跳過)。 - 將這兩項內容編輯應用於單一「編輯 DTS」協議呼叫中,然後執行剩餘的協議步驟(重新編譯、合理性檢查,以及涵蓋這兩項內容編輯的單一自訂提交)。
- nvpower.sh(操作 2):設定
desired_cpufreq_gov="performance"並desired_devfreq_gov="performance"無條件地;移除set_devfreq_governor中移除 GPU/nvjpg 的跳過設定。透過操作 2 的疊加編輯配方(「疊加編輯配方(在編輯 nvpower.sh 之前套用)」步驟)進行套用——這是在 rootfs 腳本上獨立的疊加追蹤器原始狀態 + 自訂提交對,有別於 BPMP-DTB 協議的提交。 - 透過
/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 → 預期結果為 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/. |
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 之後,此操作將無效 |
編輯內容已套用至 ,該檔案 /jetson-promote-image的輸出——而非其輸入。 |
將該編輯移至 (疊加追蹤器)並透過 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 上限之下。
---
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.
所有檔案
9 個檔案安裝 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
複製





首頁
