Jetson Orin NX on JetPack 6.2: Secure Boot disables dynamic clock boosting—how to re-enable without modifying kernel driver?

[vongocminh778]

Continuing the discussion from Boosting clocks with disk encryption + secure boot:

On my Jetson Orin NX (JetPack 6.2) with Secure Boot enabled, I can no longer boost the ISP/VI/NVCSI/EMC clocks at runtime using debugfs commands. I’ve been running:

echo 1 > /sys/kernel/debug/bpmp/debug/clk/vi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/isp/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/nvcsi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/emc/mrq_rate_locked

cat /sys/kernel/debug/bpmp/debug/clk/vi/max_rate  | tee /sys/kernel/debug/bpmp/debug/clk/vi/rate
cat /sys/kernel/debug/bpmp/debug/clk/isp/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/isp/rate
cat /sys/kernel/debug/bpmp/debug/clk/nvcsi/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/nvcsi/rate
cat /sys/kernel/debug/bpmp/debug/clk/emc/max_rate  | tee /sys/kernel/debug/bpmp/debug/clk/emc/rate

These commands work when Secure Boot is off, but fail silently with Secure Boot on. I know it’s possible to hack around this by patching /drivers/video/tegra/camera/tegra_camera_platform.c, but that’s neither clean nor maintainable.

My questions:

1. Why does Secure Boot prevent these clock-boost debugfs writes?
2. Is there a safer or more flexible way to re-enable dynamic clock boosting (e.g. via DT overlays, devfreq settings, or other kernel interfaces) while still keeping Secure Boot enabled?

Any detailed pointers or examples would be greatly appreciated. Thanks!

[linuxdev]

I know nothing about the specific dynamic clock question. I do want to point something out though which might be related: Device tree is related to clocks, and when secure boot is enabled you might be switching to a device tree you are not expecting.

Normally there can be a device tree and/or overlay somewhere in “/boot”. Same for kernel. There is a priority scheme whereby items listed in extlinux.conf, if they are found, have the highest priority over those in an eMMC partition (the partition version would load if “/boot” content is not found or specified). Except for the rootfs partition the eMMC partitions are all signed, and only allowed if the signing is valid (the default signature is a NULL signature, but it is still signed). Is the device tree you are using from a signed partition, or is it from “/boot”?

Once secure boot is enabled the priority of load changes. Content for device tree and kernel in “/boot” are banned because they are not signed. If you were loading a tree and/or kernel in “/boot”, and if this has some influence on the clocks, and if you are expecting this same kernel and/or tree are loaded, then this would be incorrect because now the kernel and tree in signed partitions are now used. You would have to use flash tools to put a properly signed kernel and/or device tree in the signed partition.

[JerryChang]

hello vongocminh778,

it’s clock configuration through sysnode for system testing/evaluation/validation.
you don’t need (and, wish not) to have the same on production products.

for the camera init, it’s parsing through device tree for pix_clk_hz property, and setting the clock configuration accordingly.
please refer to Sensor Pixel Clock, there’re several formulas to evaluate proper pixel clock rates.

you may see-also Power Mode Controls, you may have custom power mode definition.
furthermore, as mentioned by Supported Modes and Power Efficiency section,
you may refer to Power Estimator for more information about estimating the power and generating the nvpmodel configuration file for the custom power mode.