nvpmodel Issues on Jetson Orin NX with Read-Only Rootfs and meta-tegra

[felipesolanosanchez]

Hello,

I'm in the process of porting a Jetson Xavier image—based on meta-tegra (commit 2c95c68)—to a Jetson Orin NX, and I've run into some issues with nvpmodel when changing power modes.

When using SysVinit with a read-write root filesystem, changing the power mode updates the conf_value but doesn't reflect in the real_value, meaning the actual mode isn't applied. In the case of SysVinit with a read-only rootfs, mode changes fail entirely due to problems writing to the /var directory.

Switching to Systemd with a read-write rootfs, everything works as expected—both conf_value and real_value are updated properly, and the mode change is applied. However, with Systemd and a read-only rootfs, we encounter the same issue as with SysVinit: the system fails to apply changes due to write access issues in /var.

Has anyone experienced this kind of behavior?

[kekiefer]

Do you need to change the mode dynamically? You can avoid nvpmodel needing to write the setting to /var/lib/nvpmodel/status by configuring the intended power mode at build time by putting NVPMODEL_CONFIG_DEFAULT = "0" (or whatever the intended mode is) in your machine or local .conf files.

[felipesolanosanchez]

Hello @kekiefer,
Thanks for your response, we are interested in entering a specific mode from boot and at least changing frequencies on the fly. The NVPMODEL_CONFIG_DEFAULT has been defined already from build and it has been confirmed that is modifies the default mode specified in the /etc/nvpmodel.config file. However, the nvpmodel doesn't seem to apply any of the changes specified on that .config file by using SysVinit.

Modifying the related files such as /sys/devices/system/cpu/<cpu#>/cpufreq/scaling_min_freq" does not give any issue, it is specifically the application of changes by the nvpmodel what does not respond at all.

[dwalkes]

However, with Systemd and a read-only rootfs, we encounter the same issue as with SysVinit: the system fails to apply changes due to write access issues in /var.

You may be able to add a read/write overlay to appropriate /var locations to solve this. There's a helper recipe for this at https://github.com/OE4T/tegra-demo-distro/blob/master/layers/meta-tegrademo/recipes-demo/data-overlay-setup/data-overlay-setup_1.0.bb and example usage at https://github.com/Trellis-Logic/kas-demos/blob/main/layers/meta-trellis-swupdate-rootfs-overlay-oe4t/recipes-core/base-files/base-files_%25.bbappend which might be helpful to reference.

[felipesolanosanchez]

@dwalkes Thank you for your response and suggestions. The nvpmodel was able to work after adding the data-overlay-setup, also a var-volatile.mount was required due to the checked conditions on the var-volatile-lib. service.