During Jetson Xavier Boot I am seeing above message along with
see ‘systemctl status nv-l4t-usb-device-mode.service’ for details
when I see the system control log I see following message
nv-l4t-usb-device-mode.service - Configure USB flashing port for device mode
Loaded: loaded (/opt/nvidia/l4t-usb-device-mode/nv-l4t-usb-device-mode.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Wed 2020-06-24 22:28:36 EDT; 5min ago
Process: 5085 ExecStopPost=/opt/nvidia/l4t-usb-device-mode/nv-l4t-usb-device-mode-stop.sh (code=exited, status=0/SUCCESS)
Process: 4880 ExecStart=/opt/nvidia/l4t-usb-device-mode/nv-l4t-usb-device-mode-start.sh (code=exited, status=1/FAILURE)
Main PID: 4880 (code=exited, status=1/FAILURE)
Jun 24 22:28:33 jetson01-desktop nv-l4t-usb-device-mode-stop.sh[5085]: /opt/nvidia/l4t-usb-device-mode/nv-l4t-usb-device-mode-stop.sh: line 34: echo: write error: No such d
Jun 24 22:28:33 jetson01-desktop nv-l4t-usb-device-mode-stop.sh[5085]: rmdir: failed to remove ‘l4t/configs/c.1/strings/0x409’: No such file or directory
Jun 24 22:28:33 jetson01-desktop nv-l4t-usb-device-mode-stop.sh[5085]: rmdir: failed to remove ’l4t/functions/ncm.usb0/’: No such file or directory
Jun 24 22:28:33 jetson01-desktop nv-l4t-usb-device-mode-stop.sh[5085]: rmdir: failed to remove ’l4t/functions/ecm.usb0/’: No such file or directory
Jun 24 22:28:33 jetson01-desktop nv-l4t-usb-device-mode-stop.sh[5085]: rmdir: failed to remove ’l4t/functions/mass_storage.0/’: No such file or directory
Jun 24 22:28:33 jetson01-desktop nv-l4t-usb-device-mode-stop.sh[5085]: rmdir: failed to remove ’l4t/functions/acm.GS0/’: No such file or directory
Jun 24 22:28:33 jetson01-desktop nv-l4t-usb-device-mode-stop.sh[5085]: l4tbr0: ERROR while getting interface flags: No such device
Jun 24 22:28:33 jetson01-desktop nv-l4t-usb-device-mode-stop.sh[5085]: bridge l4tbr0 doesn’t exist; can’t delete it
Jun 24 22:28:36 jetson01-desktop systemd[1]: nv-l4t-usb-device-mode.service: Failed with result ‘exit-code’.
Jun 24 22:28:36 jetson01-desktop systemd[1]: Failed to start Configure USB flashing port for device mode.
I couldn’t not see the flash USB port even during force recovery mode. Unable to do SSH as well
What this code is for is to allow the micro-B USB to emulate various devices. For example, the mass storage part is just a demo with a read-only file. The network part is how the Jetson pretends to be a network adapter and provides DHCP to give the host PC address 192.168.55.1 when the micro-B USB is connected (the Jetson gets address 192.168.55.100).
As this is brought up or dropped as a service temporary files are added or deleted. If the service is still running, then the files are locked. Stopping the service normally removes the temporary content. My speculation is that if something causes the Jetson to shut down too quickly, then the stale files never have a chance to be removed. When it comes time to boot the current code has no way to remove locked files since it may not understand they are stale from a previous boot.
If the Jetson was ever shut down abnormally, e.g., power being pulled, then this is definitely high on the list of why this would happen. On the other hand, the micro-OTG connector has an ID pin to know if the connected cable is type-A (host mode) or type-B (device mode)…perhaps there is a weakness in the code if the cable unplugged or replugged under some circumstances, e.g., rapidly or perhaps when under load and unable to respond fast enough to a rapid change.
When this occurs, what cable type do you have connected (if any)? Has there been any sort of unexpected fast power down?
You might experiment with this to cycle on and off:
sudo systemctl start nv-l4t-usb-device-mode.service sudo systemctl status nv-l4t-usb-device-mode.service
sudo systemctl stop nv-l4t-usb-device-mode.service sudo systemctl status nv-l4t-usb-device-mode.service
The “status” is for knowing if active or not. Note that there might be unrelated network warnings which are not really errors. It is the “active” (or not) which counts.
for my case, it happens to me after flashing a new image to update the exisitng image. i indeed unplug and plug back the plug to force nano go to recover mode. what you are saying make sense. but i dont understand is that i flashed a new image it suppose erase all the emmc . dont know why after flashing it still happens .
what also tried is that remove the set -e from the nv-l4t-usb-device-mode-start.sh to ignore these errs … that seems helps
The services controlled with systemctl only occur when the system is booted, and never when in recovery mode. I couldn’t tell you what is going on right at that moment in the Xavier case due to USB-C being a bit different than the micro-OTG port I’m used to (Nano uses micro-OTG). USB-C has extra wires, and so it still follows the same rules as the older USB ports, but it has enough wires to work in both device and host mode with the same cable without the two ends of the plug differing.
On the systems with micro-OTG ports the emulation of the ethernet and mass storage devices over the micro-OTG port depends on the ID pin, and will enable or disable between purely host mode and purely device mode. I’m not sure what is going on for the Xavier since there isn’t an ID pin in the usual way for a USB-C, but the logic is the same although USB-C might essentially count as two types of port (type-A and type-B) at the same time.
The content in /opt/nvidia/l4t-usb-device-mode/ is part of the default flash image, but is not part of a regular non-NVIDIA Ubuntu install. Right after you flash a Nano or Xavier this content will run even on first boot. This is how you are able to do optional extra package installs if you don’t have wired ethernet. This is the code which turns the Jetson into virtual address 192.168.55.1 and the host PC into virtual address 192.168.55.100. If you are not adding extra package content via ssh over the virtual wired ethernet, then this code does not need to run.
A particular question for you is in what way does this error cause issues? I’m not trying to avoid the question, but I am wondering what the circumstances are when this occurs. That code cannot run when in recovery mode, but will run after a flash completes and the unit reboots to go into a normal boot.
In the factory line, after flahing the image. we use 192.168.55.1 to install per device certificate and running some quick testing as there is no wifi /ethenet on the productine line. this 192.168.55.1 is used for this purpose.
Is this scripted? What I’m wondering about is how fast the system has to respond. If a person is manually completing the first login step, then there is more time for the virtual ethernet to be activated. If something is scripted, then there may be a need for a short pause. In a case where this fails, do you have available the full serial console boot log? It would be of interest to know what was going on just prior to the virtual ethernet’s attempt at starting (well, more or less the full boot log, not just the specific error).
yes. it is scripted . we also bypass the oem config . the user account is pre-created . also we dont login to setup time etc in GUI. everything is setting up via 192.168.55.1
Would it be possible for you to test this with a “sleep 5” prior to the first use of ssh or networking? What is specifically going on in the script just prior to the network/USB issue?
There are a number of places you could add a delay/sleep, but this is where device mode is being set up during start which you mentioned earlier:
If you are manually doing this, then the delay would be added to the above file. When run as a service you will find this directory has related “service” files: /etc/systemd/system/
…which has file “nv-l4t-usb-device-mode.service”, and in turn this is just a symbolic link pointing back to “/opt/nvidia/l4t-usb-device-mode/nv-l4t-usb-device-mode.service”.
The traditional way to do this would be to actually copy “/opt/nvidia/l4t-usb-device-mode/nv-l4t-usb-device-mode.service” to “/etc/systemd/system/”, thus overwriting the symbolic link. Make edits to that copy. When you want to revert those changes, then remove the “/etc/systemd/system/nv-l4t-usb-device-mode.service” file and link it back to the original again (with “ln -s”).
Basically the “ExecStartPre=/bin/sleep 30” is what you want, but I’d probably drop the 30 down to 5 or 10. Remember that this is only for testing to see if a significant wait period allows this to set up correctly. If this helps, then the issue can be looked at from this perspective. If not, then no harm done and we know it isn’t a “wait longer” to get it working issue.