Cloning Jetson Orin NX shows ERROR: might be timeout in USB write. Error: Return value 3

Robotics & Edge Computing Jetson & Embedded Systems Jetson Orin NX
1

While Cloning the Jetson Orin NX backup image to another Jetson Orin NX device shows,

Waiting for device to expose ssh …Error: ipv6: address already assigned.
Error: ipv6: address already assigned.
Device has booted into initrd. You can ssh to the target by the command:
$ ssh root@fe80::1%enx4e16134d969c
Cleaning up…
Log is saved to Linux_for_Tegra/initrdlog/flash_3-1_0_20250520-100241.log
Run command:
ln -s /proc/self/fd /dev/fd && mount -o nolock [fc00:1:1::1]:/home/spotless/nvidia/nvidia_sdk/JetPack_5.1.5_Linux_JETSON_ORIN_NX_TARGETS/Linux_for_Tegra/tools/backup_restore /mnt && /mnt/nvrestore_partitions.sh -e nvme0n1 -n
on root@fc00:1:1::2
/mnt/images ~
nvrestore_partitions.sh: Use the default nvpartitionmap.txt as the index file.
nvrestore_partitions.sh: You are trying to flash images from a board model that does not
match the current board you’re flashing onto.

So, I have tried to flash that Jetson Orin NX through SDK manager and manual flashing through terminal shows the same error as,

Terminal error,

ERROR: might be timeout in USB write.
Error: Return value 3
Command tegrarcm_v2 --new_session --chip 0x23 0 --uid --download bct_br br_bct_BR.bct --download mb1 mb1_t234_prod_aligned_sigheader.bin.encrypt --download psc_bl1 psc_bl1_t234_prod_aligned_sigheader.bin.encrypt --download bct_mb1 mb1_bct_MB1_sigheader.bct.encrypt
Reading board information failed.

SDK Manager error,

13:10:35 INFO: Flash Jetson Linux - flash: [ 0.1193 ] Assuming zero filled SBK key
13:10:35 INFO: Flash Jetson Linux - flash: [ 0.1205 ] Warning: pub_key.key is not found
13:10:35 INFO: Flash Jetson Linux - flash: [ 0.1201 ] tegrahost_v2 --chip 0x23 0 --updatesigheader mb1_bct_MB1_aligned_sigheader.bct.encrypt mb1_bct_MB1_aligned_sigheader.bct.hash zerosbk
13:10:35 ERROR: Flash Jetson Linux - flash: [ 0.1211 ] Error: Skip generating mem_bct because sdram_config is not defined
13:10:35 ERROR: Flash Jetson Linux - flash: [ 0.1211 ] Error: Skip generating mem_bct because sdram_config is not defined
13:10:35 INFO: Flash Jetson Linux - flash: [ 0.1211 ] Copying signatures
13:10:35 INFO: Flash Jetson Linux - flash: [ 0.1218 ] tegrahost_v2 --chip 0x23 0 --partitionlayout readinfo_t234_min_prod.xml.bin --updatesig images_list_signed.xml
13:10:35 INFO: Flash Jetson Linux - flash: [ 0.1255 ] Boot Rom communication
13:10:35 INFO: Flash Jetson Linux - flash: [ 0.1262 ] tegrarcm_v2 --new_session --chip 0x23 0 --uid --download bct_br br_bct_BR.bct --download mb1 mb1_t234_prod_aligned_sigheader.bin.encrypt --download psc_bl1 psc_bl1_t234_prod_aligned_sigheader.bin.encrypt --download bct_mb1 mb1_bct_MB1_sigheader.bct.encrypt
13:10:35 INFO: Flash Jetson Linux - flash: [ 0.1269 ] BR_CID: 0x80012344705DD3E31000000019030100
13:10:35 INFO: Flash Jetson Linux - flash: [ 0.1646 ] Sending bct_br
13:10:40 ERROR: Flash Jetson Linux - flash: [ 0.2483 ] ERROR: might be timeout in USB write.
13:10:40 ERROR: Flash Jetson Linux - flash: Error: Return value 3
13:10:40 INFO: Flash Jetson Linux - flash: Command tegrarcm_v2 --new_session --chip 0x23 0 --uid --download bct_br br_bct_BR.bct --download mb1 mb1_t234_prod_aligned_sigheader.bin.encrypt --download psc_bl1 psc_bl1_t234_prod_aligned_sigheader.bin.encrypt --download bct_mb1 mb1_bct_MB1_sigheader.bct.encrypt
13:10:40 ERROR: Flash Jetson Linux - flash: — Error: Reading board information failed.
13:10:40 ERROR: Flash Jetson Linux - flash: *** ERROR: Parsing boardid failed
13:10:40 ERROR: Flash Jetson Linux - flash: [exec_command]: /bin/bash -c /home/spotless/.nvsdkm/replays/scripts/JetPack_5.1.5_Linux/NV_L4T_FLASH_JETSON_LINUX_COMP.sh; [error]: *** ERROR: Parsing boardid failed
13:10:40 INFO: Flash Jetson Linux - flash: [ Component Install Finished with Error ]
13:10:40 INFO: Flash Jetson Linux - flash: [host] [ 2.99 MB released. Disk Avail on Partition /dev/nvme0n1p7: 23.96 GB ]
13:10:40 INFO: Flash Jetson Linux - flash: [ NV_L4T_FLASH_JETSON_LINUX_COMP Install took 5s ]
13:10:40 ERROR: Flash Jetson Linux - flash: command terminated with error
13:10:40 SUMMARY: Flash Jetson Linux - flash: First Error: Installation failed

Can you please help me to recover from this issue. Can you help me to identify why it is raised?

Thanks in Advance…

2

I know very little about details, but the above makes me wonder this: Do both Jetsons use static network address setting? If not, did the cloning cause both to have the same Ethernet MAC addresses (which would make DHCP addresses collide between two units)? You might include this information for both units (make sure to label which Jetson each goes to):

  • Either “ifconfig” (preferred, but an older command)
  • or “ip -a -s addr” (a newer version of that command if you don’t have ifconfig).

Other than that part of the question someone else will probably need to answer.

3

Yeah, Thank you for response.

Yes, I will try to clear it.

But, Now I got stuck here, for flashing through SDK manager or cloning from previous image. for both it shows

ERROR: might be timeout in USB write.
Error: Return value 3

Can you help me in clearing this issue.

Thanks in Advance.

Regards,
Pon Dinesh S

4

The most common reason for this is using a VM for the host PC, and not configuring the USB to “own” the recovery mode Jetson. During flash (including cloning) USB will disconnect and reconnect; VMs will lose the reconnect event if not configured for that.

In some cases using a generic USB cable is a problem. This is not an issue for USB-C cables, but in cases where flash uses the micro-OTC (“charger”) cable, then about two out of three “charger” cables are incapable of continuous data transfer without errors (quite literally those charger cables have maybe 2 very tiny strands of copper; those with quality for data transfer and not just charging have significantly better copper layout).

There is also a possibility of something going on with the port. In the case of using a HUB there might be a HUB issue, and in the case of using a port directly, sometimes adding a HUB will help adapt to the RF issues. This is usually not an issue though, it is more rare.

Are you using a VM? Is it a native Linux host PC? Which type of USB cable is used for your particular Jetson during flash (there are different models)? If USB-C, then I would doubt that is an issue since every USB-C cable seems to have a reasonable quality.

5

No, I have using Native Linux as host PC (Ubuntu 20.04). My USB-C cable also checked and I have flashed for another jetson device. My Jetson device also detected on the SDK manager shows jetson-orin-nx-8gb. I didn’t using hub for flashing.

Thanks in Advance.

Regards,
Pon Dinesh S.

6

Hi, I have forget to mention you that In my Jetson Orin Nx firmware is not showing while connecting display without flashing the OS.

Because, On the another Jetson Orin NX before flashing OS firmware shows the Nvidia logo. But On the Jetson Orin NX blackout on display.

Can you help me please to find out the solution.

Thanks in Advance,

Regards,
Pon Dinesh S.

7

Hi,
I have find out that Error USB timeout is not coming. But ipv6 assigned is still rising.

I have assigned my PC to static IP address. Now, I have removed it even though same error arise.

Sometimes, I can able to see the ipv6 address without any device mention on the

ifconfig

Can you please help me to identify it?

Thanks in Advance.

Regards,
Pon Dinesh S

8

You said this is shown as jetson-orin-nx-8gb. This sounds like it is a commercial module mounted on a third party carrier board. If that is the case:

  • The carrier board changes the firmware requirement.
  • The module will not arrive with any programming (“development” kits arrive with some software already on them, despite that software normally being outdated).

To start we have to verify the carrier board model. What brand and/or model is the carrier board? Carrier board firmware can change whether or not video shows up even if the unit is otherwise still functioning, and using the NVIDIA firmware for some other manufacturer’s carrier board would also leave parts of the Jetson non-functional (the exception is if the third party carrier board is an exact match for the Jetson carrier board).

9

Yes, We have purchased separately each module. Our Carrier board from the wave share.

I have tested many times, It shows only the

Error: ipv6: address already assigned.
Error: ipv6: address already assigned.

I have assigned the static IP to the Jetson Orin NX before taking the backup image. While first time cloning it is working good. I have found out the one of the Jetson Orin has Boot crashed due to Memory mapped on the UEFI shell is appeared. So. I have tried to re-flash the module with formatting the SSD on the Jetson device (Nvme) and Again I did same process for cloning image to Jetson Orin,

sudo ./tools/backup_restore/l4t_backup_restore.sh -e nvme0n1 -r jetson-orin-nano-devkit

Can you please help me to clear ipv6 assigned?

Thanks in Advance.

Regards,
Pon Dinesh S.

10

I want to first state this:

  • The Waveshare carrier board will have different firmware than what the NVIDIA developer kits use. Using the wrong firmware is highly likely to break some hardware function, including your USB issue. This error would occur once a flash reaches the point where it automatically reboots (at a stage when technically flash is complete, but the unit needs to still install optional software over ssh after first boot account setup). You will need Waveshare’s flash content to correctly flash.
  • None of the commercial modules will have any software on them when they first arrive. This differs from dev kit modules which have an outdated software on them when they arrive.
  • A VM also typically fails USB, but this is prior to reaching reboot (and possibly after reboot).

For setting up networking I usually use the GUI app nm-connection-editor. There is a command line version of this too. The app will be installed if you have the package “network-manager-gnome”. There are also alternative apps. There is a separate tab in this app for setting up IPv4 and IPv6, but the default is to just use DHCP.

If you have a router assigning addresses, and you do not let DHCP make the assignments, then this will often lead to some sort of network issue (such as collision of two NICs). Very often any setup is related via MAC address. There are some cases where the MAC address of the unit can be overridden via udev setup, but this is not normally the case. However, if you have used the same MAC address on two computers, then there will be a collision. Do not manually assign addresses if you can avoid it, or if you do not have a purpose for doing so (for example, sometimes a camera over Ethernet would be a reason to do so).

Having an IPv6 address already assigned says nothing about the original cause. Anything you do could be an issue if the cause is not known. On the unit which has that error it could be important to list all interfaces via either of these (the old method and new method are shown):

  • ifconfig
  • ip -s addr

The listing of interfaces using the above allows you to see categories of errors. It is important to know if any error, drop, collision, or overrun occurs. These errors provide data not only about the local function and setup of the interface, but also provide information on how those interfaces are being treated over the network to the outside world. Those should all be zero, and any other value is a serious problem.

On Jetsons with eMMC (which includes all commercial modules purchased separately) the software related to the equivalent of a BIOS (and UEFI) exist on partitions of the module itself. That content is not part of the root filesystem, although some firmware might exist on the rootfs. This means that flashing the NVMe will not solve an issue with UEFI in most cases. The module itself must be flashed.

In theory the l4t_backup_restore.sh would also save and restore those odd partitions in eMMC which are equivalent to a BIOS and UEFI, but I have not experimented with them and will not guarantee this. In particular, the Jetson being restored has to be the same exact model, including revision. Imagine if a different revision uses a different brand of RAM chip, and that support for that brand only occurred in a later release. Also, there is some setup of options in the UEFI which have to be set up again after a restore of clone; the software would already be there, but the configuration might not be. I simply don’t know in your case.

Also, if you change units, then the UIDs associated with a partition or disk might change, and if that UID is required to find a filesystem, then the UID would have to be updated.

A workaround to what I just mentioned would be to avoid overwriting your cloned NVMe, and then flashing the exact same release to the new Jetson (or the old Jetson). Before going through all of that try “sudo nm-connection-editor” and see if everything is DHCP assigned (you can use “sudo apt-get install network-manager-gnome”, or you can use a text console tool.

Note: IPv6 is supposed to be “mature” at this point, but in reality some IPv6 devices and software are not what I would consider universally reliable. I tend to force my NICs to use IPv4, but allow IPv6 to exist since outside devices might use IPv6. IPv6 can be somewhat more complicated than IPv4. I don’t know where the IPv6 address is from (perhaps it is from the router?). Any time you want to debug something like this though you will need to have a serial console boot log. Unlike regular logs the serial console exists prior to the Linux kernel loading, and can show some boot stage setup issues. Always provide a serial console boot log if the boot stages are where an issue occurs, and make sure the log is named with a good description since there might be multiple logs before a bug or issue is resolved.

A summary of what is most important right now:

  • The network statistics via either ifconfig or “ip -s addr”.
  • A serial console boot log if other steps do not solve the IPv6 issue.
  • Note if you can use nm-connection-editor (requires a GUI). If not, then something else can be worked out.
  • If the firmware is wrong on the unit being cloned, then it will also be wrong on the unit restored from a clone.
11

Hi, Thank you for response.

I will try this and update you.

Regards,
Pon Dinesh S