However, the flashing process seems to timeout and I am getting the following error.
***************************************
* *
* Step 3: Start the flashing process *
* *
***************************************
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for device to expose ssh ......RTNETLINK answers: File exists
RTNETLINK answers: File exists
Waiting for device to expose ssh ...Run command: flash on fc00:1:1:0::2
SSH ready
mount.nfs: Connection timed out
Flash failure
Cleaning up...
Does the flashing process from the SDK manager change anything on the module itself? (Such as doing something to aid the uefi boot process)
Because if it does not, then the flashing process is just changing data on disk and for systems that boot from nvme or last did before they require reflash it seems to me that an alternative installation approach could be adopted that just requires writing to disk partitions for those that get stuck.
If you ever use any of the previous platform which has internal emmc, for example, Orin AGX. And flash with “flash.sh” tool, what you said is correct for such platform.
But for any attempt to flash external drive, it is initrd flash tool instead. And this tool will take the device tree as input before flashing. The flash process from this tool is different from flash.sh. It will flash the bootloader software into QSPI flash on the board first with traditional flash.sh. Then, it will boot into initrd, initrd will then flash the data to the external drive.
So, the problem comes. If your custom board disable or change anything which is different from default setting, then flash process may not work.
For example, if your custom board does not have micro usb enabled for device mode, which is needed for the flash process here, then this flash will fail.
Also, another example, if the custom board does not use same PCIe design as devkit, then default setting may not work either.
My problem was that I was using an Ubuntu 22.04 machine to do the flashing which seems to not work with the initrd flashing. I was previously using the flash.sh script to flash the AGX Orin Dev Kit on Ubuntu 22.04 without any issues. After switching to an Ubuntu 20.04 machine the flashing of the Orin NX worked without any issues.
The RT patches are working on the Orin NX as well.
Linux nx 5.10.104-rt63-tegra #1 SMP PREEMPT RT Wed Mar 29 13:16:13 CDT 2023 aarch64 aarch64 aarch64 GNU/Linux
Another update. Being determined to be able to flash from an Ubuntu 22.04 machine I started digging into the scripts to see what they were actually doing.
It turns out the actual problem causing the mount.nfs: Connection timed out error was not the fact I was using Ubuntu 22.04, but rather just that the firewall was enabled and seems to be blocking the mounting of NFS needed for flashing. I disabled the firewall and the flashing worked from an Ubuntu 22.04 machine.