I’m having trouble reflashing some Nanos which I’ve isolated to non-deterministic behavior in recovery mode.
Is it expected behavior for the tegrarcm utility to produce different results when run multiple times? For example, if I try to read the uid two times in a row, the second read always fails.
$ cd ~/nvidia/nvidia_sdk/JetPack_4.6.2_Linux_JETSON_NANO_TARGETS/Linux_for_Tegra/bootloader
$ sudo ./tegrarcm --uid
BR_CID: 0x3210100164307307040000000c030580
$ sudo ./tegrarcm --uid
Failed to read UID
$
To resolve the problem, the Nano needs to be power cycled (into recovery mode).
The problem happens on 6+ different Nanos. All of which boot and run the JetPack version of Linux without issue.
I don’t know if that is expected or not, especially for something which should be read-only. However, I can tell you there are a number of operations which, after performing some setup in the Jetson, will require restart to run again. An example is you shouldn’t try to clone twice without restarting recovery mode between clones, or you shouldn’t try to flash a second time if the first flash did not succeed (a successful flash reboots anyway). One thing I would consider a failure is if sometimes the operation succeeds right after fresh entry to recovery mode, but at other times it would fail after a fresh start of recovery mode.
I can’t answer about specific errors, but one of the first things you’ll be asked by someone who knows those specific errors is what your host PC environment is (e.g., native Ubuntu 18.04 versus VM), and which JetPack/SDKM release you are using.
I found a workaround for the failures running nvautoflash.sh.
It turns out, my 18.04 machine is slow when USB devices enumerate. Slower than the scripts tolerate.
To fix the problem, I hacked tegrarcm to delay after it reboots the Nano. The delay is long enough for the Nano to re-enumerate allowing the scripts continue without error.