I have tried for over a week to be able to flash jetpack 4.6 to xavier nx.
I do not have another unix machine.
I have tried ubuntu using oracle virtual machine . Windows sees the xavierNX as APX device but Ubuntu lsusb does not see nvida nx.
I have 4.6 onthe xavier nx working using nvme with the sd card as per jetsonhacks.
IT SEEM RIDICULOUS NOT TO BE ABLE TO UPDATE THE OPERATING SYSTEM WITHOUT HAVING TO PIGGY-BACK ON ANOTHER MACHINE.
Is all very well talking about Artificial Intelligence it seems to be missing in this case.
It sounds like the reason for failure is that the USB device is not being correctly passed through. Technically, VMs are not supported (mostly for this reason). Every VM has different instructions for making sure USB is correctly passed through. One twist is that during a flash the USB will repeatedly disconnect and reconnect, and so if initially the device is found, but then it fails, it is likely that the reconnect was not configured.
Despite the inconvenience, I doubt there would be a non-Linux flash system any time soon. I say this because (A) the flash software is an x86_64/amd64 Linux binary executable, and (B) some features of Linux are used to create filesystem images (e.g., loopback and producing the ext4 filesystem), and many of those features are not available on non-Linux systems.
Normally you can copy pre-created SD card images on Windows without issue, but the problem is that on the SD card models some (or all) of the boot content exists in the QSPI memory on the Jetson itself. The content has changed over time, and although there are several releases which are compatible with a given QSPI setup, such content does change over time and newer SD card releases will not be compatible with older QSPI content.
Note that the Jetson becomes a custom USB device when in recovery mode, and that the “driver package” (which runs only on desktop PC Linux) is responsible for changing any QSPI memory. Thus the SD card itself is not enough when crossing from one version using a certain QSPI layout to a newer version with a different QSPI layout.
Thanks for the explanation I wish I was aware of this before I started ,I tried this work around as suggested by someone who replied to my original HELP message.
I guess I will have to keep re-imaging my SD card every time a new jetpack version appears and follow the jetsonhacks
All I want is an OTA means of updating without having to do the above and buying a unix machine.
If you have any other suggestions please let me know.
Thanks for your infomation
I’m not positive if the R32.4.1 version of L4T (see “head -n 1 /etc/nv_tegra_release” to find that version…L4T is what is flashed, JetPack/SDK Manager is just the front end to flashing) is the point where OTA changed most recently, but if you’ve upgraded to that release or newer, then flashing won’t be required until the QSPI layout changes. I doubt there will be any other QSPI changes in the near future, although possibly there will be when Ubuntu 20.04 becomes supported (I think Q1 of 2022). Versions prior to this had a different QSPI memory layout, and everything at or newer than the above version (which I hope someone verifies) won’t require flashing and can just use a new SD card.
head -n 1 /etc/nv_tegra_release
R32 (release), REVISION: 6.1, GCID: 27863751, BOARD: t186ref, EABI: aarch64, DATE: Mon Jul 26 19:36:31 UTC 2021
I’ll leave it at that. Thanks for your help
I will try to load ubuntu (server with desktop) on raspberry pi 4 and try to flash from that (As an experiment)
Do note that other Linux-based platforms technically have the ability to create images, and any of these can deal with an SD card, but true flash with a Jetson in recovery mode cannot work with anything but a desktop PC architecture running Linux (the RPi is not a desktop architecture).
1 Like