jetson-customize-clocks
NVIDIA/skills
Блокируйте, ограничивайте или настраивайте поведение тактовых генераторов ЦП, графического процессора и EMC на устройствах NVIDIA Jetson, отредактировав файлы BPMP DTB и nvpower.sh перед записью прошивки.
...Расширить всеНастройка часов
Цель
Настройте поведение тактовых генераторов ЦП, графического процессора и системы 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. |
отсутствует |
Маршрут к /jetson-init-image. |
отсутствующий или не являющийся репозиторием 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 не дает никакого результата.
Инструкции
- Выполните предварительные условия, указанные выше (активный профиль, извлечённый образ BSP, инициализированный трекер наложения исходного кода).
- Выберите операцию из приведённой ниже таблицы.
- Следуйте инструкциям в разделе по ссылке — Операция 1 (BPMP DTB), Операция 2 (
nvpower.sh) или рецепт MAXN для обеих операций. - Зафиксируйте изменения в трекере наложения в соответствии с правилами фиксации для каждой операции.
- Разверните с помощью
/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 попадает в
трекер оверлеев. /jetson-promote-imageКанал A проходит по
трекеру и копирует файл в bsp_image.
Не редактируйте «
» напрямую — это выходной поток промоутера, а не входной.
Определение 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.
Затем верните управление протоколу — его этапы «Рекомпиляция», «Проверка корректности
рекомпилированного блоба», «Размещение в трекере оверлея» и «Очистка»
покроют остальное.
Соглашение о сообщениях фиксации в соответствии с протоколом:
.
Редактирование содержимого: отключение/включение 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.
Примените этапы протокола от «Recompile» до «Cleanup» после того, как редактирование с участием нескольких узлов будет
завершено. Соглашение о сообщениях фиксации:
.
Отключение повышает энергопотребление в режиме простоя; предназначено для нагрузочных / тестов производительности, а не для производственных корневых файловых систем.
Повторный запуск + идемпотентность
Согласно разделу «Возможность повторного запуска» протокола, повторный запуск этого
навыка с тем же целевым значением приводит к фиксации без изменений. Повторный
запуск с другим значением перезаписывает то же свойство — 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 | |
да |
В последующих подшагах под файлом «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
Кит с настройками в трекере оверлея сам по себе не попадает на устройство . Цепочка развертывания:
/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. BPMP операции 1 редактирует весь поток
в течение одного цикла протокола (один цикл декомпиляции / редактирования на нескольких узлах
/ рекомпиляции / фиксации — не проходить протокол
дважды для одного и того же .dtb):
- DTB BPMP (содержание шага «Редактирование содержимого:
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). - Примените оба изменения содержимого в рамках одного вызова протокола «Edit the DTS», затем выполните оставшиеся шаги протокола (перекомпиляция, проверка корректности, единая фиксация настроек, охватывающая оба изменения содержимого).
- nvpower.sh (операция 2): установите
desired_cpufreq_gov="performance"иdesired_devfreq_gov="performance"безусловно; удалите пропуск GPU/nvjpg вset_devfreq_governor. Применяется с помощью рецепта редактирования оверлея Операции 2 (шаг «Рецепт редактирования оверлея (применить перед редактированием nvpower.sh)») — отдельной пары фиксаций pristine + настройки для оверлей-трекера в скрипте rootfs, отличной от фиксации протокола BPMP-DTB. - Установите режим 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 → ожидается 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/. |
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 |
Изменение было применено к , который является /jetson-promote-imageвыход — а не вход. |
Переместите изменение в (трекер наложения) и зафиксируйте через протокол 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.
---
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
Копировать





Дом
