If you don’t mind: excellent. Find below the cdl-log and the UART-log.
Please mind that I 1) entered miniconsole 2) flashed using the vendors tool. 3) rebooted (RCM). log01.txt (11.5 KB) log02.txt (48.7 KB)
Sorry for the confusion. I see now that that was a poor choice of words. I should have written “2) initiated flashing using the vendors tool.”. I failed after a few seconds, so no flash happened.
First time I attempted to flash using the vendors tool, I had not enabled miniconsole. So once I realized flash failed, I enable miniconsole and repeated the attempt. That’s why there might be different timestamps.
Brief update: I got support from the vendor. They did not manage to flash the board neither (using remote access to the host). Also strange: the board does not leave RCM. A new board one is on the way…
Both my boards had the issue, that they left me with the impression that they cannot leave the recovery mode - because lsusb always returs the “Nvidia Corp”.
The support from the vendor, who remote controlled the ubuntu host, experienced the same issue - and initiated the exchange of the board.
Actually, I deal with lots kind of flash problem everyday. I always see some users give another post from somewhere else and said “hey, there is similar post”. But turned out they are not same issue at all.
For example, the whole error logs you shared in these 37 comments in this topic does not give “probing the target board failed.” error.
The post you think is same issue does not provide full log at all. His case is also based on VM. A VM means a unstable connection. I don’t know if you still used 18.04 VM or not. You said you are not using VM, then I trusted you.
Also, the post you shared may not be using ConnectTech carrier board…
Since this issue is on custom board, maybe the vendor should review if any problem on their design. A recovery mode is a pure hardware event. When the board is in recovery mode, there is no software running on the board itself.
You are certainly right: the post I linked to is not a perfect fit. However, we both got [ 0.0805 ] ERROR: failed to read rcm_state. when the flash procedure starts. Switching to Ubuntu 20.04 solved the problem in both our cases.
Neither me nor the support from the vendor realized this error [ 0.0805 ] ERROR: failed to read rcm_state at the beginning of the log, because there are indication for USB-timeout further down in the log. We focused on (and failed) troubleshooting only the most recent errors, and eventually replaced the board.
I switched from VM to “bare metal” (Ubuntu 18.04) straight after you recommmended to do so ((see my post 01.10.23). Only yesterday, I switched from Ubuntu 18.04 to 20.04.
I already sent an email to the vendor support. I assume they will come back to me with more questions, if they want to dive into it.
JetPack/SDKM works from more releases than what can be used. The particular L4T release being flashed, and the hardware being flashed, will limit the host PC release to a subset of what JetPack/SDKM works with. In the case of Orin Ubuntu 18.04 should work, but 20.04 is recommended. In all cases, regardless of what is being flashed, a VM tends to get in the way. VMs need to correctly handle USB passthrough even if there is a disconnect and reconnect, and this quite often fails. VMs are a major point of USB failure during flash.