My company is currently developing a device that utilizes the Jetson Xavier NX 16GB.
We had 6 of these devices and they’ve worked well but we recently purchased 5 more but have been unable to flash the new ones.
We have a system.img that we normally flash using the flash.sh script for consistency but on the new devices this is failing with
The device is recognized as being in forced recovery mode when running lsusb and the flash script starts normally but throws the above error and quits as soon as it attempt to write the system.img
Attempting to flash using the SDK manager also fails.
I’ve confirmed that our older Jetson Xaviers will reflash using both the flash.sh and SDK manager without issue.
I don’t see anything on the hardware that would indicate it’s a different version or would be unable to flash. I did also suspect maybe it was a bad device so I’ve tried another of the new modules and both have the same issue.
Here are some photos comparing the old Jetson from our original batch that has no issues flashing with flash.sh or the SDK manager and one of the new modules that fails the the above error every time.
I am curious, are all flashes from the same host computer and the same account on that computer? Are you using the same USB cable? Is it possible to use the same exact carrier board and find out if, when all other things are kept the same, flash fails?
Incidentally, you might post the exact flash command and mention which L4T release is being used. You can log serial console during the flash as well as getting a full serial console boot log (I know that boot will fail without the rootfs partition, but you might find other errors on the way to that point; if only rootfs failed, then something else might go on before that).
You did not say you are using a VM, but I will mention that there is a very high incidence of flash failure using one since the USB will disconnect and reconnect during the flash.
An example of a flash on command line while logging is this (adjust for your actual flash command line, this is just an example): sudo ./flash.sh jetson-xavier-nx mmcblk0p1 2>&1 | tee log_flash.txt
(be sure to comment on what release is being used for flash)
Using the same computer (not a VM, it’s an Ubuntu Laptop), the same USB cable, the Same Carrier Board, the Same Flashing Program and the Same L4T release. Literally the only thing different between the successful flash and the failed flash is the Jetson module itself (which has the same exact model number between the two units).
the command being used is:
I did manage to resolve the issue. Every Jetson from this batch needed to be flashed using the SDK manager in manual mode first, then and only then would the above flash.sh command work. Previous batches worked with the flash.sh command out of the box.
I would like to know how we can adjust the command to work out of the box as this would greatly speed up our ability to flash new modules.
Note that when you flash with “-r -k APP” that you are failing to update the other content. You should not flash with this unless you have already flashed without that using a release version which is a match (or at least compatible) with the APP partition you are installing.
The reason behind this is that Jetsons don’t have a BIOS. The equivalent of this is all in software (it saves on power consumption, physical size, and cost). All of that content is either in eMMC or QSPI memory (it depends on what the model has). When you perform a “normal” flash it also flashes that boot content, but this is where people go wrong: It isn’t just boot content that is needed, it is also that “equivalent to BIOS” content. When you purchase a dev kit there is never any guarantee as to which release of the “equivalent to BIOS” content you have. Whenever you purchase a separate module, then that content is always missing. By telling flash to not add the other content you might be saying to “leave invalid BIOS content or leave a missing BIOS content”. So you must flash the whole thing at least once if you really want to know it is working.
