Nvpmodel not installed on Jetson TX2 yocto image

On balenaOS 2.24.0+rev2 there is no nvpmodel installed.

It appears as if the meta-tegra repo is supposed to install it, as well as install a systemd daemon to set the settings on boot:

In November 2017 it seemed to still work: Turning On Fan Jetson Tx2

However, on the 2.24+rev2 and the official 2.17+rev1 image there is no nvpmodel and no nvpmodel.service

@floion Any idea what is not building correctly?

Hi. Sorry for the late reply.
This should be fixed by https://github.com/balena-os/balena-jetson-tx2/pull/104

1 Like

Great. Just kicked off a build - will report back later.

As mentioned in the discussions at the PR above this installs nvpmodel. However, changes (i.e. nvpmodel -m 0) do not persist across a reboot. Even if the root partition is write mounted beforehand.

Changing the default value at the bottom of /etc/nvpmodel.conf works and persists. First write mount the root folder works, then do the change.

That is a good starting point and I’m looking for a way to automate this. Either modifying the Yocto build or setting the nvpmodel using a custom udev rule on boot.

I am experimenting with using a udev rule to set the powermode. The required nvpmodel command is only available on the host, so this is executed as a global udev rule.

I have manually create a udev file in /lib/udev/rules.d which reloads on any USB device being plugged in.
(note the non-default udev folder as per https://github.com/balena-os/balena-jetson-tx2/commit/52ffdb88a11f7fcce18a79872dbee7c0a4ec61cd)

Keep in mind that you need to mount -o remount r,w /so that you can write to that filesystem

The file 101.rules looks as such:

ACTION=="add", SUBSYSTEMS=="usb", RUN+="/usr/sbin/nvpmodel -m 0"

I will try to add this to the config.json as per https://github.com/balena-os/meta-balena/blob/master/README.md#udevrules to automate the deployment and will report back here later.

Adding it to the APPLICATION_NAME.config.json also works.
Convert the .rules file with this: cat your_rule.rules | jq -sR .

For above rule it looks as such:

  "applicationName": "AmazingName",
  "applicationId": 1234567,
  "deviceType": "jetson-tx2",
  "userId": 12345,
  "username": "user_name",
  "appUpdatePollInterval": 600000,
  "listenPort": 48484,
  "vpnPort": 443,
  "apiEndpoint": "https://api.balena-cloud.com",
  "vpnEndpoint": "vpn.balena-cloud.com",
  "registryEndpoint": "registry2.balena-cloud.com",
  "deltaEndpoint": "https://delta.balena-cloud.com",
  "pubnubSubscribeKey": "",
  "pubnubPublishKey": "",
  "mixpanelToken": "12345678eeff12345567",
  "apiKey": "12345678eeff1234556712345678eeff12345567",
  "os": {
    "udevRules": {
      "101": "ACTION==\"add\", SUBSYSTEMS==\"usb\", RUN+=\"/usr/sbin/nvpmodel -m 0\"\n"

All but the os: section is generated and can be downloaded from your Application Dashboard:

  • Click Add device
  • Click Advanced
  • Tick Download configuration file only
  • Download configuration file

Now use balena config inject .../APPLICATION_NAME.config.json --drive .../BALENA_IMAGE.img --type=jetson-tx2 to inject it.
(see https://www.balena.io/docs/reference/cli/#config-inject-file-)

And flash it to a SDcard and then to the TX2.

1 Like

Looks like you worked out a good solution, thanks for sharing it with us.

Looks like you worked out a good solution, thanks for sharing it with us.

Does this work even if USB devices are attached on boot?
How do you make a change after the device is deployed using this method? Reflash?
Using a privileged container, you can also add to the udev rules at container build time, would this work also for nvpmodel?

RUN echo 'ACTION=="add", SUBSYSTEMS=="usb", RUN+="/usr/sbin/nvpmodel -m 0" ' > /etc/udev/rules.d/nvpmodel.rules
1 Like

Yes, it also works for devices attached at boot.

You can always make a change to the rules file manually afterwards, all you need to do is remount the root partition as rw.

Good point, yes you should be able to add the udev rules afterwards. In your example you might want to add a number in front of your .rules file to keep it in line with udev standards.

After adding the rule I would guess you need to also reload the udev rules or reboot the device - I’m not sure if you can do that from a privileged container though.