Jetson： Failed to start nvpmode1 server。
GUI cannot be started at boot
● nvpmodel.service - nvpmodel service
Loaded: loaded (/etc/systemd/system/nvpmodel.service; enabled; vendor preset:
Active: failed (Result: exit-code) since Sat 2023-01-28 08:52:50 EET; 19h ago
Process: 5288 ExecStart=/usr/sbin/nvpmodel -f /etc/nvpmodel.conf (code=exited,
Main PID: 5288 (code=exited, status=255)
Jan 28 08:52:50 nano nvpmodel[5288]: NVPM ERROR: failed to write PARAM GPU_P
Jan 28 08:52:50 nano nvpmodel[5288]: NVPM ERROR: Error opening /sys/devices/
Jan 28 08:52:50 nano nvpmodel[5288]: NVPM ERROR: failed to read PARAM GPU: A
Jan 28 08:52:50 nano nvpmodel[5288]: NVPM ERROR: Error opening /sys/devices/
Jan 28 08:52:50 nano nvpmodel[5288]: NVPM ERROR: failed to write PARAM GPU_P
Jan 28 08:52:50 nano nvpmodel[5288]: NVPM ERROR: failed to set power mode!
Jan 28 08:52:50 nano nvpmodel[5288]: NVPM ERROR: optMask is 2, no request fo
Jan 28 08:52:50 nano systemd[1]: nvpmodel.service: Main process exited, code
Jan 28 08:52:50 nano systemd[1]: nvpmodel.service: Failed with result 'exit-
Jan 28 08:52:50 nano systemd[1]: Failed to start nvpmodel service.
Apr 07 09:11:17 nano kernel: nvpmodel: initialized successfully
Jan 28 08:52:50 nano systemd[1]: Starting nvpmodel service…
Jan 28 08:52:50 nano nvpmodel[5288]: NVPM ERROR: Error opening /sys/devices/gpu.0/power/control: 2
Jan 28 08:52:50 nano nvpmodel[5288]: NVPM ERROR: failed to write PARAM GPU_POWER_CONTROL_ENABLE: ARG GPU_PWR_CNTL_EN: PATH: /sys/devices/gpu.0/power/control VAL: on
Jan 28 08:52:50 nano nvpmodel[5288]: NVPM ERROR: Error opening /sys/devices/gpu.0/devfreq/57000000.gpu/available_frequencies: 2
Jan 28 08:52:50 nano nvpmodel[5288]: NVPM ERROR: failed to read PARAM GPU: ARG FREQ_TABLE: PATH /sys/devices/gpu.0/devfreq/57000000.gpu/available_frequencies
Jan 28 08:52:50 nano nvpmodel[5288]: NVPM ERROR: Error opening /sys/devices/gpu.0/power/control: 2
Jan 28 08:52:50 nano nvpmodel[5288]: NVPM ERROR: failed to write PARAM GPU_POWER_CONTROL_DISABLE: ARG GPU_PWR_CNTL_DIS: PATH: /sys/devices/gpu.0/power/control VAL: auto
Jan 28 08:52:50 nano nvpmodel[5288]: NVPM ERROR: failed to set power mode!
Jan 28 08:52:50 nano nvpmodel[5288]: NVPM ERROR: optMask is 2, no request for power mode
Jan 28 08:52:50 nano systemd[1]: nvpmodel.service: Main process exited, code=exited, status=255/n/a
Jan 28 08:52:50 nano systemd[1]: nvpmodel.service: Failed with result ‘exit-code’.
Jan 28 08:52:50 nano systemd[1]: Failed to start nvpmodel service.
I probably can’t answer, but here is some related information…
nvpmodel is basically writing to files in “/sys”. Those files are in turn pseudo files, and not real files (they are actually drivers in RAM and not files on the filesystem). Two things directly relate to finding and using those files:
- The driver has to load and run.
- The device tree usually has to name arguments for drivers, e.g., physical addresses to find hardware at.
Either a missing driver or a bad or missing device tree argument can cause driver load to fail. Has the kernel itself ever been updated or changed? Has the device tree ever changed? Note that if this is a dev kit, then the device tree from the NVIDIA site should be correct, but if this is a third party carrier board, then the device tree differs if their carrier board layout differs. So you’ll need to mention:
- If this is a dev kit versus third party carrier board.
- Indirectly, if not a dev kit, was the board support package for that carrier board used?
- If the kernel has ever been modified (including modules).
- If the device tree has ever been modified.
- Which release of L4T or JetPack/SDK Manager was used for flashing (this also changes device tree at times).
If this is new behavior on a previously working unit, or if it is freshly flashed.
Thank for your reply
i use the third party carrier board
Did you flash this with their software? Unless their carrier board is an exact electrical layout duplicate of the dev kit (which is an SD card model), the device tree will differ. It is quite possible, if the dev kit flash software was used without adjusting the device tree, that this is why the “/sys” files are not found.
Every third party carrier board manufacturer will either provide their own board support package, or else state that it is an exact duplicate of the dev kit such that NVIDIA’s flash software works with it.
I use the emmc version（Jetson Nano 4GB
P3448-0002）. The carrier board comes with an sd card slot. The image is booted from the sd card.
Is the device tree file used the one on the emmc or the one on the sd card?
finally，thank for reply.
This sounds like a dev kit (SD card slot would be on the module, not the carrier board; verify the SD slot is on the module). In that case the software would be valid.
If there is an FDT entry in “/boot/extlinux/extlinux.conf”, then this is where the device tree comes from. If not, then it tends to be from a partition (and on an SD card model this would be in QSPI memory, not the SD card). I’m not positive about use of QSPI for a device tree; most SD card users will name the tree on the SD card via the FDT entry.
Some trivia perhaps related to this (or perhaps not) is that the software in the QSPI memory (which is on the module itself) has to be from the same release as that which is used to create the SD card boot content. If they differ, then it is also possible that the combination of device tree and other software could cause a driver to not load. Did you flash the Nano itself (which is how QSPI is installed)? Or was just the SD card created? If just the SD card, then you might need to flash the QSPI.
sd is on the carrier board. The module is with emmc.
My settings are emmc flashing the minimal image, then modifies extlinux.conf. Set the default to boot from the carrier board’s sd card.
The sd card image, when turned on, gives an nvpmodel error.
Maybe my description is not detailed and missing the part you might want to know. If so, could you please let me know. Thanks!
The eMMC model is quite different compared to the SD card model so far as boot is concerned. What you described is a third party carrier board, and any driver or driver setup (e.g., device tree) will be especially different in boot stages. One cannot normally boot an eMMC model from the SD card, at least not without modifying boot to add drivers and setup.
Third party carrier boards have a different board support package than do dev kits because of the SD card. You’ll need the flash software from the third party manufacturer (unless it is an exact duplicate of the electrical layout of the SD card dev kit…but it can’t be since a dev kit does not have a carrier board SD card slot and also does not have eMMC).
Basically, the drivers are not able to properly find and use the altered layout of components due to needing a different device tree. Setting up boot will also use what is on the eMMC and will not use the “/boot” of an SD card.
Who manufactures the carrier board? That’s where you’ll find the proper flash software and boot setup instructions.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.