We have some issues flashing our system.img file that we are using in production of out TX2i devices. This image is built using Jetpack 4.2 and is based on the r32.1.0 filesystem. This happens on devices affected by PCN210521 and we get the message about Cannot Open USB. By reading other forum posts here it looks like patches have been made for some of the older filesystems, but we couldn’t find one for r.32.1.0. Does anyone know if this exists, or if it is possible to make such a patch? We plan to update to the latest version of Jetpack in the future, but we need a short-term solution to keep the production of new units going. Thanks!
Someone else will likely have to answer this, but here is something you might find useful.
Every Jetson module has optional pin assignments. The device tree (which is firmware) is how drivers select what a given optional pin assignment is assigned to actually do. Two different vendors can use this to change how the carrier board wires to the module and what options occur that the carrier board has access to. The module itself is rarely at fault for failures of some item which has optional pin assignments. Usually the device tree is written for some other carrier board.
It is likely that you simply need to use the device tree which matches that particular carrier board. Only in cases where the third party carrier board vendor uses an exact match to the reference carrier board layout will the device tree from NVIDIA work.
You will need to find out from the manufacturer of the carrier board what device tree is used. Sometimes (rarely) the vendor will state that their layout is a match to NVIDIA’s, and to just use the NVIDIA flash software. In other cases the third party vendor will provide a patch to the NVIDIA flash software. The final case is that the vendor will provide rebranded flash software (which is likely an edit of the NVIDIA flash software, especially the device tree).
Since third party carrier board are not made by NVIDIA there is no chance that NVIDIA can tell you what the device tree needs. If you find that vendor’s instructions, then people here can tell you how to update. It might be as simple as going to their web site and downloading what they provide, and you’d have a working system.
Thank you for your input. According to the PCN, this issue relates to Nvidia TX2i PN 900-83489-0000-000 rev 312 or later. Because this modules are built with a new DRAM hardware, Jetpack 4.6.5 and r32.7.5 is required. We would like to get the system.img we created based Jetpack 4.2 to be compatible with the part number listed above. We can recompile and rebuild the system image if we get a patch or description of the necessary changes need on the r32.1.0 filesystem. According the the PCN, there is no physical way to determine if the module is with the new or “old” DRAM hw.
This is probably something for @WayneWWW or @KevinFFF to answer. Most of your rootfs can likely be saved, but I’m thinking the boot chain (which is where memory training occurs) needs update. You have to be aware that if you flash then the device tree must remain valid for that carrier board. My worry is that I can’t tell you how to flash the boot chain while being certain that the device tree is correct and not the one from R32.7.5.
I am thinking that if you set up the flash software for R32.7.5, then overwrite the “Linux_for_Tegra/rootfs/” with a clone of your image, that mostly this will work. You would also have to be certain that any device tree edits or other edits provided by the carrier board manufacturer are in place. After that it will probably work.
Just remember that you probably need to clone the system to save what is on the rootfs prior to doing anything (a backup lets you make mistakes and try different things without the risk). Those clone files are enormous, and even a copy of an image from one place to another takes a lot of time. Eventually you’d end up with this renamed as system.img and in “Linux_for_Tegra/bootloader/” prior to command line flash with the -r option to reuse the image or overwriting your image onto “rootfs/” and then flashing. If you overwrite “rootfs/”, then most will be verbatim, but some content (based on boot target) will be updated in that content prior to flash. I just don’t know enough about the requirements of your third party carrier board’s device tree to answer.
For PCN 210521, the Projected First Ship Date for Changed Product is at November 1st, 2024.
Are you sure your device is the one with this PCN change?
If you have received the sample to do the validation work, then please contact with the distributor to get the support to request the overlay patch.
Thanks for pointing this out, I agree it looks odd. I expect to receive a couple of units in the next few days. A PCN201541 was created last year, which also supposedly affects DRAM. I’ll have to check the details more closely, maybe I was too quick to assume it was the latest PCN we were dealing with.
To take a few steps back, do you know of other reasons why a series of TX2i modules fail with Cannot Open USB when using the flash utility(Jetpack 4.2)? When I receive the modules, I’m going to try Jetpack 4.6.4 with the supplied filesystem and image and see if I get the same error.
Thank you!
If we assume that we are dealing with the PCN, is the only way to obtain a patch for Jetpack 4.2, or is it still possible to combine Jetpack 4.6.4 and Jetpack 4.2 in a way as @linuxdev describes? Do you know if such a patch exists?
Thanks!
The purpose of saving the rootfs is not to directly flash with it. The purpose is to have a backup of what was there. There are a lot of things you could save, e.g., your home directory, maybe some settings in “/etc”, so on. You would flash with the most recent L4T R32.x which is compatible, but you can copy the parts you want to save which are not part of the actual flash within the host PC’s “Linux_for_Tegra/rootfs/” prior to flash.