オプション
家家 Skill DevOps と CI/CD jetson-customize-clocks

jetson-customize-clocks

NVIDIA/skills NVIDIA/skills

NVIDIA Jetsonデバイスでは、フラッシュする前にBPMP DTBおよびnvpower.shを編集することで、CPU、GPU、およびEMCのクロック動作をロック、制限、またはカスタマイズできます。

...すべて拡張します
0
更新された時間 2026年9月25日

時計のカスタマイズ

目的

イメージのフラッシュ前に、 Linux_for_Tegra/ 以下のファイルを編集することで、Jetsonターゲット上のCPU、GPU、およびEMCクロックの動作をカスタマイズします。対象となるのは以下の2つのレイヤーです:

  • 以下の場所にあるBPMP DTB 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: ブロック 「Route to」が /jetson-init-image.
/Linux_for_Tegra/ 欠落 ルート先が /jetson-init-image.
/Linux_for_Tegra/ 存在しない、またはGitリポジトリではない 次のパスへ /jetson-init-source.

パスの解決:

  • から bsp_image.root_path: 存在する場合、そうでない場合は /Image.
  • from 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に従ってください。 プロトコルには具体的な手順が定められています — 初回処理時の完全なインポート、 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 経由で 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 定義されている場合に限る。そうでない場合、 同じチップ/SKUの max_rate 値)以下に厳密に収める必要があります。

DTS編集フォーム、セマンティクス、およびnvpmodel ↔ BPMPクロックノードの マッピングは references/bpmp-dtb-clock-edits.md.

その後、制御をプロトコルに引き渡します。プロトコルの「再コンパイル」、「再コンパイルされたブロブの妥当性チェック 」、「オーバーレイトラッカーへのステージング」、および「クリーンアップ」 ステップが残りの処理を行います。 プロトコルに基づくコミットメッセージの規約: : 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には適しません。

再実行と冪等性

プロトコルの「再実行可能性」セクションに従い、この スキルを同じ目標値で再実行すると、ノーオペレーション(no-op)のコミットが生成されます。異なる 値で再実行すると、同じプロパティが上書きされます — 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

このスクリプトは2つのルートディレクトリに存在し、この操作では両方を処理します:

役割 場所 スキルは書き込みを行うか?
検出 + 完全なソース /Linux_for_Tegra/rootfs/etc/systemd/ いいえ — 読み取り専用
オーバーレイ編集対象 + Gitコミット /Linux_for_Tegra/rootfs/etc/systemd/ はい

以降のサブステップでは、スクリプトごとのファイルとは、 。 コピーは、 以下の「pristine-import」ステップで一度読み込まれるだけで、その後は一切変更されません。

オーバーレイ編集手順(nvpower.sh を編集する前に適用)

ワークフロードキュメントに記載されている標準的な 「Off-skill 編集手順」 に従ってください。つまり、「pristine インポート」と「カスタマイズコミット」のペアを行い、その両方を プレビューゲートで制御します。 nvpower.sh は、 伝播設定のない単一のファイルです。1つのプリスティン・コミットと1つのカスタマイズ・コミットで 変更全体を網羅します。

このスキルにおける具体的な置換内容:

  • / は 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は、プロトコルの1ラウンド(単一の逆コンパイル/マルチノード 編集/再コンパイル/コミットサイクル)を通じてすべてのフローを編集します。同じ BPMP DTB(「 コンテンツ編集:」 .dtb):

  1. BPMP DTB(「コンテンツ編集: max-rate-custom 「名前付きクロックノード上での」ステップのコンテンツ)に対して、プロトコルを2回往復させないこと: 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. 1つのプロトコル「DTSの編集」呼び出し内で両方のコンテンツ編集を適用し、残りのプロトコルステップ(再コンパイル、サニティチェック、両方のコンテンツ編集を網羅する単一のカスタマイズコミット)を実行します。
  4. nvpower.sh(操作 2):設定 desired_cpufreq_gov="performance" を desired_devfreq_gov="performance" を無条件に設定し、 set_devfreq_governorからGPU/nvjpgのスキップを削除します。これは、操作2のオーバーレイ編集レシピ(「オーバーレイ編集レシピ(nvpower.shを編集する前に適用)」ステップ)を通じて適用されます。これは、BPMP-DTBプロトコルのコミットとは別の、rootfsスクリプトに対する個別のオーバーレイトラッカーのプリスティン+カスタマイズコミットのペアです。
  5. boot-default nvpmodel モードを /jetson-customize-nvpmodel — クロックごとの nvpmodel 上限は、 max-rate-maxn 。

展開 /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以下に厳密に設定する必要があります。シリコン上限の引き上げはサポートされていません。
  • 有効な上限は2層です。実行時の上限は min(BPMP cap, active-nvpmodel-mode cap)です。nvpmodelの上限は /jetson-customize-nvpmodelが管理しており、このスキルでは編集できません。
  • SoC 条件付き EMC DVFS ゲート。EMC DVFS を無効化するには、T23x(bwmgr + cactmon)と T26x(bwmgr + cactmon + delete 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 では、 osp-controller T23x (Orin) では、BPMP DTB に osp-controller; T23xでは編集#3をスキップする必要があります。 以下の手順でSoCファミリーを検出する 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に参照されるsystemdドロップインや同階層のヘルパーファイルにパッケージの編集内容を記述し、 nvpower.sh その場で編集するのではなく、systemdのドロップインファイルや、BPMP DTBによって参照される同階層のヘルパーファイルにパッケージ設定を記述してください
/jetson-promote-image BPMP DTBを編集した後は、この操作は何も行われません 編集は /Linux_for_Tegra/に適用されました。これは /jetson-promote-imageの出力であり、入力ではありません。 編集を /Linux_for_Tegra/bootloader/ (オーバーレイトラッカー)に移動し、BPMP-DTBプロトコルを介してコミットしてください。
Capは初回起動時に適用されるようですが、電源モードの変更後にリセットされるようです アクティブな nvpmodel モードのクロックごとの上限値は、以下より下限にクリップされます max-rate-custom. 両方のレイヤーを調べてください。nvpmodel がバインディングしている場合は、 /jetson-customize-nvpmodel。BPMPの上限のみでは、実行時の上限にはなりません。

参考文献

  • ../../references/bsp-customization-bpmp-dtb.md — 標準的な BPMP-DTB カスタマイズプロトコル(完全なインポート、逆コンパイル、編集、再コンパイル、妥当性チェック、コミット)。このスキルの操作 1 はコンテンツのみを消費するものであり、メカニズムはプロトコルが管理する。
  • references/clock-control-model.md — レイヤースタック、2つの上限の概要、実効ランタイム上限の計算式。
  • references/bpmp-dtb-clock-edits.md — 2つの上限のセマンティクス、DTS編集フォーム、nvpmodel ↔ BPMPクロックノードのマッピング、検査手順集。
  • references/emc-dvfs-disable.md — DTSスニペットを用いた完全なSoC条件付きEMC DVFS無効化手順、検出、再有効化。
  • 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年6月29日
klingai-upgrade-migration
更新された時間 2026年7月3日
base44-cli
更新された時間 2026年6月29日
Railway CLI Management
更新された時間 2026年7月2日
OR