I’m stuck in the setup process for flashing my TX2.
When trying to Flash my TX2 during the setup, I can’t seem to get my board in to Recovery Mode (this isn’t the first time this particular board has been flashed, but I’m doing a “hard reset”).
I power the board off using the Power Button.
I press down the Force Recovery Button, then press the Power Button, release the power button and then release the Recovery Button.
Eventually, the board … just boots up and gives me an Ubuntu login splash screen.
I’m able to detect the TX2 from my Host Computer
(terminal ‘lsusb’ and seeing 0955:7020 NVidia Corp.)
Now, interestingly, the ‘help’ text in the SDK Manager says I should be seeing ‘0955:7c18 NVidia’.
Any suggestions on how to continue the Flash Process?
Your procedure for reaching recovery mode is correct, so that should not boot fully unless the recovery button itself has perhaps gone bad. Regardless of full boot or recovery mode the Jetson will show lsusb with device “0955:7020”, but in one case it will be a recovery mode Jetson, and in the other case it’ll be a virtual device over the micro-B USB.
If you have a serial console available (see TX2 Serial), does this show a normal boot process as well? I’m guessing that if it does, then perhaps there is a button failure or carrier board failure.
Clarification before I explain lsusb: “0955:7020” is for a Nano, while “0955:7c18” is for a TX2. What I use as an example below is the 7020 model, but if you try to use a 7020 with a TX2 it is an error; or if you use 7c18 with a Nano, then this is an error. If you are flashing such that your device is a TX2, but your flash specifies Nano, then this will cause the error.
TX2: “0955:7c18”
Nano: “0955:7020”
Unless you disable the “nv-l4t-usb-device-mode.service” you won’t be able to tell using “lsusb”. Well, not directly.
As an explanation, in recovery mode the Jetson becomes a custom device understood only by the “driver package” (the flash software running on the Linux host PC). This shows up as manufacturer 0x0955 (NVIDIA), and device 0x7020 (that’s for a Nano, but for a TX2 it should be “0x7c18”). When a Jetson is fully booted, it runs a service (nv-l4t-usb-device-mode.service) which also turns the micro-USB into a device, but it is a different device (fully booted it is in fact both a network device and a mass storage device with a read-only README file). This is all plain vanilla “lsusb” will show.
If you monitor “dmesg --follow”, and do not have the micro-B USB cable connected, and then you plug in that cable, you should see log lines appended. Those log lines will definitively tell you details of what kind of device “0955:7020” is…and if it shows a network or mass storage, then it is fully booted. If it does not show those other device types, and does not name a driver, then it is the recovery mode Jetson.
What shows up in dmesg when your recovery mode device (or attempted recovery mode device) is plugged in?
When in Recovery mode, should I be able to see the device via lsusb?
Does the board have to be “seen” in the SDK before I start the flash? (via the Target Hardware section of the “Hardware Configuration” part of the SDK)
It is interesting that (when the board is powered up) that it was showing up as “0955:7020” and not “0955:7c18” even though it’s a TX2.
I have it set as a TX2 in the SDK.
In the ERROR message in the SDK, one line I don’t know about is
line 3. Ubuntu ‘System coniguration wizard’ is completed on the device …
What is that? I don’t remember seeing that in the setup steps
When TX2 is in “device mode”, the host side lsusb can always see “nvidia corp”.
Please be careful that I said “device mode” but not “recovery mode”.
When jetson is in recovery mode, it is one kind of device mode case so you can see that in lsusb. However, after rel-32, by default TX2 is also in device mode after kernel is up.
Thus, using “lsusb” on host to check the recovery is not precise. If you are sure your board is in recovery mode but the screen connected on the board still gives you the boot screen, logo or even the desktop, then you are doing wrong.
When board in recovery mode, there is no OS/kernel running. You should not see anything on the screen.
Ok! Yes. That makes sense.
While in “Device” mode, I can see my TX2 as an Nvidia device (although it’s not the right ID… )
While in recovery mode, when I use the ‘lsusb’ command, there’s nothing on the screen attached to the TX2 board and I do not get a returned ID from that command …
However, I also am getting the error above …
Starting with the TX2 board powered on and connected to my host via a USB cable.
A monitor is attached to my TX2 board via hdmi. I can see an ubuntu desktop displayed.
Running the ‘lsusb’ command on my host machine, I get a return of ‘Bus 001 Device 015: ID 0955:7020 NVidia Corp.’
I hold down the recovery mode button (labelled ‘Rec’) and push down the Power Button, then release the power button and then release the Recovery Button.
I get a prompt on the screen saying ‘Goodbye, username. Would you like to…’ with buttons on the screen … the choices are ‘Lock’, ‘Suspend’, ‘Restart’, ‘Shutdown’.
If I choose ‘Suspend’ … the system goes in to “Suspend” mode … and I don’t see anything on the attached monitor.
On my host computer, if I run the ‘lsusb’ command, I don’t get a return … which I expect, because the board’s OS is in “Suspend”.
And unfortunately, no. I don’t have another board to test this with. :(
Are you certain? If the wrong ID is returned, then perhaps the module is really a Nano.
For clarification:
“Device mode” means this is some sort of USB device, e.g., a keyboard or mouse. For host mode, this is a computer which can see and use devices.
Device mode does not specify which kind of device. It only specifies that there is something which seems to be a device which a host can use.
Recovery mode runs in device mode. This is a custom device which has no generic drivers. Only the flash software (the “driver package”) understands this device. This mode makes it possible to flash.
Fully booted, the Jetson can appear to be a network device or mass storage. This uses generic drivers and has no special function. You can use the virtual ethernet device over USB, or read the README file.
Holding recovery while resetting power should go to recovery mode. Holding recovery while tapping the power on button will only produce recovery mode if power actually cycles…if the unit was already on, then this implies you have to hold the power button for about 8 seconds to power off, and then hit the button again; but if the unit were already off, and you hold recovery while then tapping power, this should put the unit in recovery mode.
If for any reason the recovery button is held while power comes alive (regardless of being reset or being cold powered on), then the Jetson should be in recovery mode. If not, then this is a hardware error.
I suspect suspend mode might not count as having been power off. Possibly (I don’t know for sure) the recovery button might not go to recovery button if for some reason suspect were actually still counted as power on since power would have never cycled off.
@WayneWWW : I’ll try that, thank you. @linuxdev : RE it being a Nano or TX2 … well, looking at the Dev board … and the processor … it definitely says TX2 on the side and is bigger than a Nano board … soooooo
I have to wonder what is going on with that. For this to be a TX2 and show up with lsusb of “0955:7020” (so far as I know this implies Nano, which in turn uses the DIMM socket format and not the larger TX2 module form factor) seems bizarre.
I have to wonder what is going on with that. For this to be a TX2 and show up with lsusb of “ 0955:7020 ” (so far as I know this implies Nano, which in turn uses the DIMM socket format and not the larger TX2 module form factor) seems bizarre.
Agreed. But, we’ll see how things go …
And not to count the electrical-chickens before they set the bits right … but, Woohoo!
Looks like that did it … setup is in progress!
(for those following along at home, I was using the wrong key combination to put my board in Reset Mode)
Thank you everyone! (and @WayneWWW )
If things don’t go well, I’ll post back.