Use lsusb command to view, as shown in the figure below.
Recovery mode and fully booted would result in the same lsusb. The lsusb only reports IDs, it does not report function, so modes are indistinguishable between fully booted and recovery mode if only using lsusb.
However, if this is available as a storage device, then you are correct, this is not recovery mode.
What will distinguish recovery mode from fully booted is that if you monitor “dmesg --follow” on your Ubuntu host PC, and then plug in the cable, the dmesg will say something about a network device and bulk storage if the Jetson is normally booted, but if the Jetson is in recovery mode, then it won’t mention finding a new mass storage device, nor will it list the MAC address of a network device.
Btw, during flash the unit is in recovery mode, but recovery mode is not used for adding optional components. For example, CUDA is added only after flash completes and the system reboots. So if you start in recovery mode and flash, then when done the unit will have self-rebooted to a fully booted normal boot without you intentionally doing this. Then of course it’ll want you to complete first boot setup to create an account, and it’ll want to complete adding those optional packages using ssh with that account while fully and normally booted.
Are you sure this is really not reaching recovery mode? You have to short the recovery mode pin to the ground pin either as power is first turned on, or as power is reset (you don’t have to hold the recovery pin short after that).
Also, recovery mode itself will never alter the Jetson. All this does is to temporarily turn the Jetson into a custom USB device capable of being flashed. It is the “driver package” (run by JetPack/SDK Manager) on the host PC which performs the actual flash operation.
The system prompts me about the error：
â—Ź 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 Sun 2018-01-28 10:58:25 EST; 2min 31s ago
Process: 4232 ExecStopPost=/opt/nvidia/l4t-usb-device-mode/nv-l4t-usb-device-mode-stop.sh (code=exited, status=0/SUCCESS)
Process: 3898 ExecStart=/opt/nvidia/l4t-usb-device-mode/nv-l4t-usb-device-mode-start.sh (code=exited, status=1/FAILURE)
Main PID: 3898 (code=exited, status=1/FAILURE)
Jan 28 10:58:22 nvidia-desktop nv-l4t-usb-device-mode-stop.sh[4232]: /opt/nvidia/l4t-usb-device-mode/nv-l4t-usb-device-mode-stop.sh: line 34: echo: write error: No such device
Jan 28 10:58:22 nvidia-desktop nv-l4t-usb-device-mode-stop.sh[4232]: rmdir: failed to remove 'l4t/configs/c.1/strings/0x409': No such file or directory
Jan 28 10:58:22 nvidia-desktop nv-l4t-usb-device-mode-stop.sh[4232]: rmdir: failed to remove 'l4t/functions/ncm.usb0/': No such file or directory
Jan 28 10:58:22 nvidia-desktop nv-l4t-usb-device-mode-stop.sh[4232]: rmdir: failed to remove 'l4t/functions/ecm.usb0/': No such file or directory
Jan 28 10:58:22 nvidia-desktop nv-l4t-usb-device-mode-stop.sh[4232]: rmdir: failed to remove 'l4t/functions/mass_storage.0/': No such file or directory
Jan 28 10:58:22 nvidia-desktop nv-l4t-usb-device-mode-stop.sh[4232]: rmdir: failed to remove 'l4t/functions/acm.GS0/': No such file or directory
Jan 28 10:58:22 nvidia-desktop nv-l4t-usb-device-mode-stop.sh[4232]: l4tbr0: ERROR while getting interface flags: No such device
Jan 28 10:58:22 nvidia-desktop nv-l4t-usb-device-mode-stop.sh[4232]: bridge l4tbr0 doesn't exist; can't delete it
Jan 28 10:58:25 nvidia-desktop systemd[1]: nv-l4t-usb-device-mode.service: Failed with result 'exit-code'.
Jan 28 10:58:25 nvidia-desktop systemd[1]: Failed to start Configure USB flashing port for device mode.
The above is the error printed by another core board. This core board can not enter the recovery mode, nor can it be detected by the “lsusb” command.
Recovery mode is totally a hardware triggered event. If board A is able to enter recovery mode while board B cannot, it means board B possibly has hardware defect.
Other than hardware failure, I suppose it would be possible for this to fail if a type-A micro USB cable is inserted (normally one would have a type-B micro USB cable inserted…there is an ID pin to detect type). Assuming the same cable works with recovery mode or other device mode on another board though, you can rule that out. If you are using different cables in testing, then you might check if it is a cable type issue.
1 Like