Different Jetson TX2 modules?

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

Hi everyone,

I own 3 Developper Board Kits. On each of the TX2 modules, there is a green sticker mentioning “Can only be used with Developper Board”. I have been given a ConnectTech Spacely Carrier Board with a TX2 last week. This TX2 module doesn’t have the green sticker and seems slightly different than the Developper Kit TX2 modules. It has a green heatsink instead of the silver colored one and black stickers (mac address, L4T version, etc…). I was wondering if there are different TX2 modules ? If I want to use one of the TX2 modules that came with the Development Kit on that Carrier Board, can I or will I have some hardware/software issues ?

Thanks,
René

3

hello rene.desgagnes,

please refer to Jetson Module EEPROM Layout.
you may dump eeprom to check the product part number for confirmation.
for example, $ sudo i2cdump -y 7 0x50

4

I am Rene’s colleague who posted the original question above. The problem we are having is that we have created an image of a TX2 and cloned it on another TX2 but when we boot the board we have no USB capability and cannot operate the machine. The Display works fine and I can see that it is the cloned image but we have no USB. Furthermore, the networking was disabled on the original board so we cannot connect to the machine by any other means. We thought there maybe there was a different version of TX2 and that was the issue. We did a lsusb on both boards when in recovery mode and they and they both appear to be 7c18 which the documentation says is a TX2 NX. If there are any ideas on why the USB wouldn’t work I would be grateful to hear them.

5

Are these TX2 developer kits?

FYI, a clone is normally just a clone of the root filesystem. Many partitions are used for boot (Jetsons don’t have a BIOS so much of that boot content is the equivalent of the BIOS), and that content can change over time. A rootfs from one release typically won’t work with another release if there is a mismatch between the rootfs and non-rootfs boot content. When you say clone, how much is cloned? When restoring a clone, are you also correctly updating the non-rootfs content with the correct release?

6

Hi LinuxDev,

We have 3 developper board kits (developper carrier board w/ hdmi, usb, network, etc… with TX2 modules). We also have what appears to be a TX2 (part number 3310-1000 so original TX2) with a ConnectTech Spacely carrier board ASG006. We backed up the TX2+Spacely Carrier board with the following command:

sudo ./flash.sh -r -k APP -G tx2backup.img jetson-tx2 mmcblk0p1

We then tried to flash a “standard” TX2 developper kit modules with the following command:

sudo ./flash.sh -r -k APP jetson-tx2 mmcblk0p1

This will use system.img and system.img is a symlink to tx2backup.img.raw.

By using those commands, did we clone everything or only rootfs ? If only rootfs, how can we clone everything else if that is possible ?

Thanks,

René

7

The boot content for the Spacely will differ from that of the dev kits. The dev kits, if you stick to a single release, would all have the same boot content, but if different dev kits use different releases, then they too would have conflicting boot content.

Basically the failure is that the rootfs is not a clone of everything. This is just the operating system, and booting into the o/s does not mix well when using the wrong boot content.

To expand on this latter topic, consider that when you flash and do nothing but install a new rootfs, that you are (probably) mixing incompatible boot content. Once you use the “-k APP” option you’ve essentially told the system to not touch anything but rootfs. Whatever the release version is (including not just release, but also if it is Spacely versus dev kit) you need the matching non-rootfs content which was designed to work with that rootfs in combination with that carrier board.

Note that if a rootfs came from a dev kit originally flashed with some release, e.g., R32.1 (just a contrived example), then the rootfs clone could be passed to any other “same model of carrier” which had also been previously flashed with R32.1 non-rootfs content. Failure would be expected for this example if you put the rootfs on a Spacely carrier, or if you restored the clone to an R32.6 system without first setting non-rootfs content to R32.1.

8

hello rene.desgagnes,

there’re couple of things you should aware…

  1. the board configuration, jetson-tx2 it’s the one for Jetson TX2 DevKit. since you’re having a customer carrier board, once that board schematic differs from Jetson TX2 Developer Kit board, you must include specific pinmux configuration to flash the target.

  2. the JetPack release image version of the cloned and the target boards must be identical, or you’ll see some unexpected failures.

  3. could you please contact with your vendor, please confirm the board configuration file for image flashing,