This is something that is not possible in our configuration. The device running the TFTP server is a data at rest module, with all boot images and files to be located on an encrypted drive that gets mounted to it (/rmc0). Therefore, the server directory has to be located on the drive.
@linuxdev to follow on, using tcpdump, I was able to trace the download to start timing out at the same block of the boot.img file each time (block 15973).
I am curious if you could set up a fully/normally booted Jetson to perform a simple TFTP download of that image? This is not for boot, this is just to test if there is a bug related specifically to downloading that file using boot software versus a bug in general, and if a normally booted Jetson hits an issue at that offset, then the problem is different than if a regular running Jetson can successfully TFTP download that file.
Hi @linuxdev. Sorry for the delayed response. I did a similar test using a separate Ubuntu VM on the network. I was able to connect via TFTP to the server and successfully TFTP download the boot.img. I will try to run the same test with using the Jetson Dev Kit booted normally.
It might be possible to log what the VM shows during a download, and compare that to a serial console boot log. Messages identifying something such as a different search path might then provide a clue. At least you now have a “reference” download if you create a log of the manual test download in the VM.
Incidentally, do the test setup and Jetson share the same network switch?
They do share the same network switch. I was also able to have a normally booted Jetson tftp download the image successfully.
If the normally booted Jetson download log (and command producing the log) can be compared to a serial console boot log, it might point out the exact difference.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.