I fell into equipment that has been running JetPack 4.2 at a new job and is being used to flash TX2’s. There has been a product change that currently makes it impossible to flash certain equipment we have received. I have been notified by the vendor we purchased from that 4.2 is incompatible and I will have to switch to JP 4.4.1 or higher to be able to flash them or I receive and error during flashing “Cannot open USB”.
Things to note currently:
The system must remain air-gapped (I can use a VM as a go between for pulling things but I need this working on the physical laptop)
I cannot set up an offline repository at the moment for pulling dependencies (I had one set up but there was a recent change that made this option unavailable).
Because of the above I have been having to pull /var/cache/apt/archives from my VM, port them over, and install them in a janky way. The laptop and VM both have the same architecture and are both running Ubuntu 18.04. (If you have a better option please let me know).
I will be able to post logs after setting the physical laptop up again.
I’ve been stuck on this, uninstalling, re-installing, re-imaging and I’m kind of hitting a wall after almost 2 months. I’d like to start from scratch and get input on how to start this process. I’ve tried with SDK Manager and 4.6.2, I’ve also tried just using the L4T driver package, and sample root filesystem and omitting the SDK manager.
I would appreciate any help available to remedy this issue.
I am not using a VM to flash, this is from the physical laptop. The VM is only being used as an in between to grab packages and dependencies. The “Cannot open usb” error came about when flashing from the laptop that worked correctly TX2s that we’re pre-product change. When flashing the new TX2 we have received (same make and model but a different eMMC) with the JP 4.2 L4T we get this error and have been instructed to upgrade to JetPack 4.4.1 or above.
No, they were not. When I tried flashing with the new Jetpack the system would load a Nvidia splash screen and reboot and would get stuck in that infinite loop. So, I guess I’m wondering if there’s any advice on how to correctly on an air-gapped system I am unaware of. I feel it’s not as easy as just using install later and porting it over due to SDK manager using apt-get looking for dependencies during install. I want to look at this from a “fresh” install mindset to make sure I’m not missing anything in the process as my other attempts haven’t worked.
Sorry I should note that the image I tried to flash was a backup taken with 4.4. That didn’t work, however flashing the vanilla image did. I’m assuming that because the backup was taken with 4.4 that it might be incompatible with the 4.6.2 when trying to flash it. But also wanted to make sure I even followed the correct steps to begin with.
This is not an answer, but here is some information related to this…
Whenever you flash, the part which goes into the Jetson is L4T (which is Ubuntu plus NVIDIA drivers). The software which does the flashing is the “driver package”, and any image going into rootfs is from the “sample rootfs” after using “sudo ./apply_binaries.sh” to install the NVIDIA drivers. JetPack is a GUI front end to the driver package, and is not strictly required to flash, but it does add the ability to add optional components like CUDA after the flash completes (and the Jetson auto reboots). SDK Manager is a network layer on top of JetPack.
You can run sdkmanager and cause a download of the “~/nvidia/nvidia_sdk/Linux_for_Tegra/” directory. The content of “Linux_for_Tegra/” is basically the “driver package” (a recovery mode Jetson is a custom USB device needing a custom driver…and this “driver package” is the driver). The “Linux_for_Tegra/rootfs/” content is from the “sample rootfs”. JetPack will automatically perform the “sudo ./apply_binaries.sh” to this (it is needed only once). However, if you were to manually unpack and install the driver package and sample rootfs, then you’d need to manually also apply_binaries.sh. This is the setup which must exist before an actual flash. Once this is done, you could flash with either GUI JetPack or command line.
Not being able to see a Jetson during a flash implies that USB has failed to see the device (the host PC does not see a Jetson in device mode). A very common reason for this is using a VM which is not configured correctly (even if the Jetson is initially visible, USB will disconnect and reconnect during flash, and tends to lose USB upon reconnect). The second common problem is that often people use a “charger cable” not shipped by NVIDIA. Charger cables “technically” should work, but I would say about 2 out of 3 brands fail. Those cables have maybe 2 strands of 32 gauge or 34 gauge copper for the data wires, and are absolutely terrible. Their only real use is charging due to the poor quality of data lines.
The failure to see your recovery mode Jetson could be:
Using a VM without proper configuration.
The Jetson is not in recovery mode.
You are using a low quality “charger” cable.
The signal quality, for reasons other than the charger cable, is too low. Sometimes switching ports or going through a HUB can change signal quality (RF square waves are a very complicated topic, and 100% functional hardware in different combinations can fail).
There is actual hardware failure (this is quite rare).
If you don’t mind could you close this topic? I believe this error has something to do with another companies BSP and not JetPack itself. I will be creating a new thread for an issue I’m having. Sorry for my novice experience I kind of got thrown into this and am learning as I go. Moving forward I will try to do a better job of conveying my issues in a clear, concise, and more technical manner.