вариант
ДомДом Skill DevOps и CI/CD jetson-customize-clocks

jetson-customize-clocks

NVIDIA/skills NVIDIA/skills

Блокируйте, ограничивайте или настраивайте поведение тактовых генераторов ЦП, графического процессора и EMC на устройствах NVIDIA Jetson, отредактировав файлы BPMP DTB и nvpower.sh перед записью прошивки.

...Расширить все
0
Обновлено время 25 сентября 2026 г.

Настройка часов

Цель

Настройте поведение тактовых генераторов ЦП, графического процессора и системы EMC на целевом устройстве Jetson, отредактировав файлы в папке Linux_for_Tegra/ перед записью образа. В сферу применения входят два уровня:

  • DTB BPMP в Linux_for_Tegra/bootloader/ — пределы max-rate-custom , а также шлюз EMC DVFS (bwmgr + cactmon на всех SoC; osp-controller только на T26x).
  • nvpower.sh в Linux_for_Tegra/rootfs/etc/systemd/nvpower.sh — регуляторы cpufreq / devfreq и (опционально) минимальные / максимальные / статические частоты для каждого устройства, записываемые в sysfs при загрузке.

Распространённые триггеры: «зафиксировать частоту ЦП/GPU/EMC», «зафиксировать GPU на Fmax», «зафиксировать EMC на MAXN», «отключить/включить EMC DVFS», «отключить/включить DVFS ЦП», «установить максимальную частоту ЦП/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.

является доступным только для чтения для данного навыка; каждая запись (BPMP DTB операции 1 и 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 вступят в силу при следующей перезагрузке.

Поддерживаемые операции

Операция Где находится редактируемый файл Раздел «Процедура»
Фиксация тактовой частоты ЦП/ГП на определенном значении 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 в качестве значения по умолчанию при загрузке см. рецепт
Снизить жесткий верхний предел тактовой частоты без блокировки DTB BPMP max-rate-custom только «Редактирование содержания: max-rate-custom"
Ограничить частоту устройства без фиксации nvpower.sh минимального/максимального значения через sysfs «Выбрать изменение»

Операция 1 — Изменения в DTB BPMP

Следуйте протоколу настройки BPMP-DTB, описанному в ../../references/bsp-customization-bpmp-dtb.md. Протокол определяет механику — импорт исходных данных при первом запуске, dtc декомпиляция, рекомпиляция, проверка на корректность, фиксация изменений. Данный навык предоставляет только контент, специфичный для конкретного тактового генератора (какие узлы и свойства следует редактировать на этапе протокола «Редактирование DTS»).

Отредактированные .dtb попадает в /Linux_for_Tegra/ трекер оверлеев. /jetson-promote-imageКанал A проходит по трекеру и копирует файл в bsp_image. Не редактируйте « /Linux_for_Tegra/bootloader/ » напрямую — это выходной поток промоутера, а не входной.

Определение DTB BPMP с правильным SKU

В соответствии с разделом протокола «Определение активного BPMP DTB» считывайте BPFDTB_FILE из активной конфигурации флэш-памяти. Для типичных конфигураций Thor / с одним SKU это статическая BPFDTB_FILE=... строка в конфигурации для каждой платы .conf , и её значение является авторитетным в том виде, в каком оно есть.

Для конфигураций с мультиплексированием SKU (цепочка конфигураций набора разработчика Orin AGX, которая выбирает разные DTB BPMP для 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; awk со стороны nvpmodel в режиме по умолчанию при загрузке) находится в 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.

Затем верните управление протоколу — его этапы «Рекомпиляция», «Проверка корректности рекомпилированного блоба», «Размещение в трекере оверлея» и «Очистка» покроют остальное. Соглашение о сообщениях фиксации в соответствии с протоколом: : 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.

Примените этапы протокола от «Recompile» до «Cleanup» после того, как редактирование с участием нескольких узлов будет завершено. Соглашение о сообщениях фиксации: : jetson-customize-clocks — EMC DVFS disable (bwmgr + cactmon[+ osp-controller]).

Отключение повышает энергопотребление в режиме простоя; предназначено для нагрузочных / тестов производительности, а не для производственных корневых файловых систем.

Повторный запуск + идемпотентность

Согласно разделу «Возможность повторного запуска» протокола, повторный запуск этого навыка с тем же целевым значением приводит к фиксации без изменений. Повторный запуск с другим значением перезаписывает то же свойство — 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/ да

В последующих подшагах под файлом «per-script» подразумевается наложение копия в папке . Копия считывается один раз во время шага «impristine-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.

Deploy

Кит с настройками в трекере оверлея сам по себе не попадает на устройство . Цепочка развертывания:

  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. BPMP операции 1 редактирует весь поток в течение одного цикла протокола (один цикл декомпиляции / редактирования на нескольких узлах / рекомпиляции / фиксации — не проходить протокол дважды для одного и того же .dtb):

  1. DTB BPMP (содержание шага «Редактирование содержимого: 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. Примените оба изменения содержимого в рамках одного вызова протокола «Edit the DTS», затем выполните оставшиеся шаги протокола (перекомпиляция, проверка корректности, единая фиксация настроек, охватывающая оба изменения содержимого).
  4. nvpower.sh (операция 2): установите desired_cpufreq_gov="performance" и desired_devfreq_gov="performance" безусловно; удалите пропуск GPU/nvjpg в set_devfreq_governor. Применяется с помощью рецепта редактирования оверлея Операции 2 (шаг «Рецепт редактирования оверлея (применить перед редактированием nvpower.sh)») — отдельной пары фиксаций pristine + настройки для оверлей-трекера в скрипте rootfs, отличной от фиксации протокола BPMP-DTB.
  5. Установите режим nvpmodel по умолчанию при загрузке в MAXN с помощью /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). Неправильное определение приводит к непредсказуемому поведению.
  • Ограничитель GPU на T23x является многоузловым. Тактовая частота GPU распределяется между nafll_gpusys и каждый nafll_gpcX; ограничение действует только в том случае, если применяется ко всем из них.
  • nvpower.sh управляется пакетом. Он поставляется в nvidia-l4t-init; обновления пакета перезаписывают изменения, внесенные на месте. Для долгосрочных настроек следует отдавать предпочтение готовому решению для systemd или вспомогательной утилите того же уровня.
  • ODMDATA имеет приоритет. Когда токен ODMDATA охватывает какое-либо свойство, он переопределяет прямые изменения DTS в BPMP во время записи во флэш-память. Прямые изменения DTS в BPMP являются резервным вариантом для свойств, на которые не распространяется ни один токен NVIDIA.
  • max-rate-maxn а lateinit недоступны. max-rate-maxn — это ограничение на уровне микросхемы (только для чтения). lateinit предназначено для инициализации тактовой частоты при загрузке, а не для переопределения предельного значения — никогда не трогайте ни то, ни другое.
  • BPMP DTB может быть мультиплексирован по SKU. В составных/распределённых конфигурациях прошивки (цепочка Orin AGX devkit), BPFDTB_FILE выбирается с помощью board_sku / board_FAB через update_flash_args_common. Чтение статической BPFDTB_FILE= неправильно, если цепочка условно переопределяет его; вместо этого используйте диспетчеризацию.

Устранение неполадок

Ошибка Причина Решение
max-rate-custom установлена, но тактовая частота все равно нарастает до max-rate-maxn включается на графическом процессоре T23x Было 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.
Отказ в отключении EMC DVFS на T23x с ошибкой «узел не найден» для osp-controller T23x (Орин). DTB-файлы BPMP не содержат osp-controller; правку № 3 необходимо пропустить на T23x. Определение семейства SoC с помощью grep -c osp-controller шага; применять #3 следует только тогда, когда счетчик равен ≥1.
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 не оказывает никакого эффекта после редактирования DTB BPMP Изменение было применено к /Linux_for_Tegra/, который является /jetson-promote-imageвыход — а не вход. Переместите изменение в /Linux_for_Tegra/bootloader/ (трекер наложения) и зафиксируйте через протокол BPMP-DTB.
Ограничение, похоже, применяется при первой загрузке, а затем сбрасывается после смены режима питания Ограничение на такт активного режима nvpmodel фиксируется ниже max-rate-custom. Проверьте оба уровня; если nvpmodel вызывает конфликт, увеличьте (или удалите) ограничение 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 — полная процедура отключения EMC DVFS с учетом условий SoC с фрагментами кода DTS, обнаружение, повторное включение.
  • references/nvpower-sh-edits.md — nvpower.sh местоположения функций + типовые рецепты редактирования + предостережение по обновлению пакета.
  • /jetson-customize-nvpmodel — сопутствующий навык: режимы питания nvpmodel. Ограничение на один такт в активном режиме фиксируется ниже предельного значения, заданного в DTB BPMP.
Посмотреть на 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
Обновлено время 29 июня 2026 г.
klingai-upgrade-migration
Обновлено время 3 июля 2026 г.
base44-cli
Обновлено время 29 июня 2026 г.
Railway CLI Management
Обновлено время 2 июля 2026 г.
OR