TX2 not able connect with Ethernet cable after installing linux image

Hello bro how can we let the Jetpack 4.4.1 's device update to Jetpack 4.5.1 before flush?as your mean is first just need update the device to jetpack4.5.1 then can been flush right?

we had both try on single device and the different device ,It’s just that this problem does not occur in a fixed way. Repeated brushing of a device may lead to different situations

file a new topic for yourself.

Good day Wayne,

Both the original author ssabuwala and liaochun are part of my team. We’re asking the question as a continuation of the original problem.

What we’re trying to do, is to create an image, such that given a new TX2, we can simply load that image.

So far, we’re not sure what the advice from NVidia is to do this.

From your guidance, we are currently doing this:

  1. Use Nvidia SDK manager to flash 4.5.1 to the TX2.
  2. Use .flash to flash our image onto the machine.

This works well, and we can locate “eth0” interface now.

What we like to understand, is that whether there is a way to do this in 1 step. Given a new TX2, how can we “load” our image inside?

Thank you Wayne.

Is there any problem understanding this comment?

So far, for all the discussion here, which has etherent problem, is because someone only updates the kernel but not update the kernel dtb along.

If you only want to clone system.img out and apply to other device, make sure all the other components are applied too.

system.img does not update those bootloader and device tree partitions.

And what is the definition of yoru “image”? Kernel image? System image? What is your expected files in those “image”?

If you don’t know why there is ethernet problem here, let me explain again.

You have 2 jetson tx2, name it A and B.

A is flashed with jetpack4.5.1.

B is flashed with jetpack4.4.1.

You use below command to clone APP partition outs from device A.

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

And then you use this command to flash APP partition on device B with the backup image from A.

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

The only thing updated here is the APP partition. Which means your rootfs and kernel is being updated to same as A device.

Thus, B devices now has jetapck4.5.1 kerenl, but rest of partitions all stay as jetapck4.4.1 and cause etherent problem.

Hi Wayne,

Thank you for the clear explanation. I think we were not so familiar with the imaging process.

In this case, is there a way for us to get a full image, which we can use to flash B?

ie: in B, can we replace “everything”, including rootfs, and kernel, and everything possible, as though it is a 100% replica from A?

Is this possible? Tx.

By Image, we mean that these 2 machines will be 100% the same given what we “save” from A, and “apply” to B.

We have several tx2 devices, and we want a single step to make them all 100% the same.

Because it takes very long to install our packages on each of them, and doing so many steps have room for human error. That’s why we like to use an “image” procedure to “capture” from A, and “apply” to B, C, D, E… Z.

Thank you for your assistance.

You can refer to the massflash utility.

thank you, we will try it out. thanks wayne.

Some information for clarification which might or might not be useful to you…

eMMC models of Jetson (of which the TX2 is one) have a QSPI memory which only gets updated during a flash. Then other partitions are added in the eMMC, some of which are “sort of” equivalent to a BIOS, and are not actual bootloader stages (imagine setting up power rails, clocks, so on). Other partitions become the bootloader or similar stages (think of this as a simple operating system which has as its only purpose overwriting itself with a Linux kernel after the supporting environment becomes what that kernel needs). Finally, there is the “APP” (rootfs) partition, which is the actual operating system, and is last to load (this can contain the kernel itself, but also contains whatever the kernel first executes…namely “init”, possibly via a ramdisk in some cases).

The environment which sets up clocks and rails may need to be closely tied to what the QSPI memory has in it. Think of this as needing a different BIOS if the setup to the motherboard is itself different between two models. The two must be compatible. If a unit has been flashed with content to the QSPI which has not changed over several releases, then the other content (that which I am calling somewhat equivalent to a BIOS, but within partitions) would not need to be flashed with new releases (at least not due to that particular software). Software such as bootloaders would be compatible, but as soon as something changes in board setup for clocks, rails, so on, then changes in QSPI imply there must also be changes in early bootloader stages (U-Boot is only the last bootloader stage, there are several others before this).

If you clone the entire eMMC, and directly write that to another Jetson, then if and only if the QSPI is compatible will that “entire eMMC” clone be useful. If the module has never been flashed, or if the module was flashed with an incompatible release, then restoring by such a clone will be at least partially failing.

The operating system itself is entirely in the root/APP partition. If boot stages have created an environment compatible with the Linux kernel, then transferring execution to that kernel will succeed. Two systems with a matching cloned rootfs/APP partition will do as expected. Arguments passed to the kernel will also match, as will device tree content were not altered in earlier boot stages (which could be viewed as arguments passed to drivers within the kernel). The matching of arguments and environment which the kernel lives in must match before a clone will be guaranteed to act exactly the same when restored to different Jetsons. The stages which come before the operating system itself are irrelevant once execution transfers to the Linux kernel such that the environments were a match at the start of Linux kernel execution.

There is no true clone of an entire disk (including non-rootfs partitions) unless the QSPI also matches. QSPI changes require flashing.

A typical method of cloning the rootfs partition on a TX2 is, with the TX2 in recovery mode and having the micro-B USB connected to the host PC using an R32.x L4T release:
sudo ./flash.sh -r -k APP -G my_backup.img jetson-tx2 mmcblk0p1

The above would produce a “sparse” copy named “my_backup.img”, and a “raw” image named “my_backup.img.raw”. Either could be used to restore an exact match of the rootfs partition, but the sparse image is smaller. The sparse image cannot be loopback mounted, examined, or edited, but the raw image can. I throw away the sparse image and keep the raw image only, but when not in use I compress the raw image (which takes a long time since it is such a huge file).

When you clone a system (the rootfs only), due to differences in different L4T releases (JetPack/SDK Manager is just a front end to what actually gets flashed…L4T is Ubuntu with hardware-specific drivers…see “head -n 1 /etc/nv_tegra_release”), you should perform restore using only the same release and not mix with newer releases. This is how you guarantee those earlier stages match. Most people will not customize those earlier stages and in most cases any customization there is irrelevant (except perhaps if you have a custom carrier board). Flashing everything new (except for the rootfs being a clone) guarantees the QSPI and all of that “equivalent to BIOS” setup will be compatible. You’ll then have multiple Jetsons which are exact matches.

To complicate this the non-rootfs partitions are signed (even though it is a NULL signature if the security fuses were not burned). Simply copying the non-rootfs partitions from one system to another might or might not work depending on signatures, but a flash as a method of restoring a clone performs all signing work, so once more it is better to freshly flash everything except for the rootfs being a clone in order to get that content to be consistent with matching the environment the rootfs clone expects.

One interesting rare problem with a clone is the udev system. If you are not aware, there are some device special files in “/dev” which might have a rule to rename them or perform some operating on them. You won’t see it a lot, but there are times when an ethernet MAC address is used to determine whether or not a device special file gets renamed. Two different Jetsons with a matching rootfs will fail to match in behavior if udev depends on a unique MAC address…at least for that ethernet device. You’d end up having to edit the clone’s udev content to name the correct MAC address if that occurs (most of the time you can ignore udev in clones).

If you wanted to restore a clone to a different TX2 using the same L4T release, then you could restore via copy of either the “my_backup.img” or the “my_backup.img.raw” to the PC’s “Linux_for_Tegra/bootloader/system.img” file, followed by this flash:
sudo ./flash.sh -r jetson-tx2 mmcblk0p1

The “-r” says to not generate a new system.img and to use whatever is already there. All other partitions and QSPI will be flashed with the content intended for that L4T release, and any signing needed will be performed (even if signing is just a NULL key).

Once a Jetson has had one flash with a particular L4T release (meaning QSPI has been set up) completed, then QSPI would be correct, and you could in theory use tools like dd to copy a signed partition in place and it would work. If QSPI was never set up correctly, then boot would fail when copying an incorrect version of a non-rootfs partition in place (or at least would not be matching behavior).

If you think about cloning “everything”, then on a Jetson it implies you are also cloning the equivalent to “BIOS”, which is something you’d never do with a PC. Cloning everything would also have the weakness/flaw that it can’t clone the QSPI content, at least not via eMMC copy. Such a clone would not really be a true clone since QSPI could be wrong for that “equivalent to BIOS” content. If you want a clone, then you want to clone the rootfs/APP partition, and flash the rest of it with the stock content for that other content. If you have a customized carrier board, then you would perhaps have to put the modifications in the PC’s correct “Linux_for_Tegra/” subdirectory before restoring clones.

Thank you so much for the information, let us digest your solid information!

Hello engineering ,what’s the Massflash utility is? same with the sdkmanager it’s a flushing tools? can give the correct download page here ,the link you give The corresponding document was not found thanks

If you are using jetpack4.5.1 driver package, then it has a readme file here.

~/nvidia/nvidia_sdk/JetPack_4.5.1_Linux_JETSON_TX2_NX/Linux_for_Tegra$ ls README_Massflash.txt
README_Massflash.txt

Massflash enables an end user to do simultaneous flashing to multiple target devices with same content.

So we are facing the eth0 problem. According to your suggestion, the first step is to upgrade the device of jetpack 4.4 to jetpack 4.5.1 through sdkmanager. On this basis, there is no problem in writing our image, right? Is there any way to omit the first step to achieve the same goal?

This has nothing to do with sdkmanager. It is just separate tools.

Operating this tool according to the guidance file can solve the problem that our image can’t find eth0, right?

…No, it has nothing to do with eth0 issue. I already shared the cause of your etherent problem in previous comment…

So what’s the purpose of this massbrush? and then According to your suggestion, the first step is to upgrade the device of jetpack 4.4 to jetpack 4.5.1 through sdkmanager. On this basis, there is no problem in writing our image, right? Is there any way to omit the first step to achieve the same goal?