Aha! That does change things…a lot. I do not know what changes that board introduces, but I’ll restate a few things and relate to custom boards…
Actual flash requires the TX2 to be in recovery mode. The micro-B USB connector turns into a custom device when in recovery mode, and the driver package used in flashing understands this custom device.
Extra packages are not added during flash…the flash results in the unit rebooting, and then the extra packages are added over wired ethernet. SDK Manager is aware of an ability to use the micro-B USB to create a virtual network interface, and that network interface runs on the TX2, but is loaded over USB by the PC host (the older JetPack used actual wired ethernet…technically the USB virtual is wired ethernet, but the host sets this up differently than the case of a real ethernet). Thus you must have the micro-B USB, and that USB must be set up to work with device mode.
Normally a USB connector is host mode and you can plug in a keyboard/mouse. In device mode the Jetson becomes a device itself (as an example a device mode port could make the Jetson appear that it is a mass storage device or a keyboard…in this case it has become a virtual/synthetic ethernet adapter). Recovery mode is one example, but during normal non-recovery-mode operation this connector has an ability to become different devices. The port is actually a “micro-OTG” (“on the go”) port and accepts either a type-A or type-B connector, and has a detect pin to see when the inserted cable is a type-B. The type-B triggers device mode and triggers the appearance of being a network card (when booted normally and using this L4T release device mode cables the micro-B cable will pretend to be a network card).
The device tree and some software is required for the virtual NIC to show up, and your custom carrier needs some support package edits for this to work. Those edits appear to be missing and must be provided by the manufacturer of the carrier board. Thus the micro-B cannot become a virtual NIC. Without this you cannot install extra packages without manual intervention (in past JetPack releases the real ethernet could be used for this purpose, but was eliminated in SDKM).
Your first choice is to get whatever customization content is required for that carrier board and flash using that. This would make enable micro-B port…which in turn would make the USB virtual ethernet card work.
If you cannot get the device tree or other modifications for using this alternate carrier board, then you have to install the “.deb” files manually. I will assume this is the case, but there will be other non-functional components to your TX2 if the device tree from the particular carrier board is not put in place…I do not know what piece of the TX2 will be failing since I do not know what customizations this alternate carrier board uses.
However, to install the packages manually, notice that if you didn’t tell SDK Manager to clean up after, then even the failed extra package step will have produced files you can add manually. In what follows I won’t guarantee that install order won’t need to change since I’m only doing this from memory and not testing, but keep in mind that if something is missing in a dpkg install step, or if out of order, then you simply need to name all of the packages in a single “dpkg -i …” install step and dpkg should sort it out. One thing which is certain is that the repos must be added first, and that the CUDA repo must be the first of all repos.
On your host PC these will be located at “~/Downloads/nvidia/sdkm_downloads/”. Within these the install order matters. I am going to assume you have copied any relevant files over to your Jetson. As an example I am assuming your login on the TX2 is user “ubuntu” and that you have actual ssh access. I am abbreviating the TX2 IP address as “”. From the host PC:
cd ~/Downloads/nvidia/sdkm_downloads
# We will make a mirror of this directory on the Jetson, though only for Jetson related files.
ssh ubuntu@<tx2>
cd Downloads
mkdir -p nvidia/sdkm_downloads
exit
# You are now back on the PC. "arm64" is the Jetson architecture, amd64 is the PC architecture.
scp *arm64*.deb ubuntu@<tx2>:~/Downloads/nvidia/sdkm_downloads/
ssh ubuntu@<tx2>
sudo -s
cd Downloads/nvidia/sdkm_downloads
dpkg -i cuda*repo*.deb
apt update
# At this point you have the CUDA repos and apt can use them. Now add the VisionWorks repos:
dpkg -i libvisionworks*repo*.deb
apt update
# At this point you also have the VisionWorks repos and can add those packages.
# Now add what remains (those back quotes are important and executes the ls command and
# substitutes the result):
dpkg -i `ls *.deb | grep -v repo`
You may be interested to know these non-deb files are present:
devtools_docs.zip
Jetson_Linux_R32.1.0_aarch64.tbz2
NVIDIA_VisionWorks_References.zip
sdkml3_jetpack_l4t_42.json
Tegra_Linux_Sample-Root-Filesystem_R32.1.0_aarch64.tbz2
Tegra_Multimedia_API_R32.1.0_aarch64.tbz2
The sample root filesystem is used for flash. The json file is a manifest for finding and downloading files. The Tegra_Multimedia_API_R32.1.0_aarch64.tbz2 file is for the multimedia API support and example code (you can unpack it and see if you want it). NVIDIA_VisionWorks_References.zip is what it looks like. All of those files being added in the right order is what SDKM would have done if the micro-B USB were set up with the correct device tree for the custom carrier board.