Hi,
Are you talking about this host PC can flash NV devkit but could not flash your custom board?
I don’t get your point of same carrier board here. What I want you to test here is this host PC with devkit and your custom board. Carrier board won’t be the same …
Hi Wayne,
Sorry maybe I describe again:
We have and linux PC1, we used it before to flash orin devices with our custom carrier board, and it works fine.
Now we wish to setup another linux PC2, and flash the same set of orin with the same custom carrier board, and it fails.
Linux PC1 + custom carrier board + orin NX — works
Linux PC2 + custom carrier board + orin NX — failed
Yes, I totally know what you are trying to say. But that dose not matter about the result of PC1.
What I want to know is
Linux PC2 +NV devkit+ orin NX —> will it work or not?
Hi Wayne,
Linux PC2 + NV Dev Kit + orin is not working either, the symptom is the same.
Do you have the device UART log for devkit + PC2 situation and host side flash log?
Just in case we are on the same page. I am talking about running initrd flash command directly and saw flash failure.
Is that the “same symptom” we are discussing here?
Attached flash log for PC2 + DEVKit
flash_uart_devkit.log.txt (12.7 KB)
The flashing process is done using l4t_initrd_flash.sh
Do you have the device UART log for devkit + PC2 situation and host side flash log?
I need UART + host side log.
So I need 2 attachments here. You only attached one. Please give out another one too.
This the corresponding log file at host side
flash_uart_devkit_hostside.log (301.5 KB)
Are you sure your UART side log is really completed one?
Your host side log proceed to very late stage already but device side (UART) does not look like matching to that status.
Sorry maybe the previous uart log is incomplete due to laptop went into sleep mode. Repost as below:
flash_uart_devkit_20260109_1700.log (88.9 KB)
flash_uart_devkit_hostside_20260109_1700.log (301.5 KB)
I feel your host PC has some driver missing there.
Is that a real native Ubuntu host? (non VM)
Incidentally, it isn’t unusual for a USB sleep or low power mode to interfere with a flash. If the sleep setting or trigger event differs between the two PCs, then this could cause the issue (however, it would most likely trigger on all of the flashes of that specific software and not be specific to a particular carrier board since flash times would be the same).
It is a native host with ubuntu 22.04
When your host PC keeps spewing “Waiting for target to boot-up…”, is your host side “lsusb” command able to see the Jetson device?
Yes ubuntu host could detect jetson by lsusb, and it’s ID changes to 0955:7035
Then it indeed some drivers are missing from your host PC side.
I would say you could directly change to other kind of host PC and it shall work.
It is hard for us to check your host PC situation in such remote way.
Btw, when actually flashing the Jetson is a custom USB device which the flash software understands. Once the o/s is installed the Jetson automatically reboots. The ID from “lsusb” is the same, but the nature of the USB port is quite different when fully booted. When fully booted the Jetson is a virtual network device like a router; this is used for adding optional software over ssh such that the host PC treats the Jetson like any other networked device. The shorter meaning is that if flash actually worked, and then it is simply waiting for networking, that you can use alternate network devices instead.
If the USB virtual network fails, then it is often due to the host PC having security setup to not allow random network devices to simply activate without user permission. Or it can be a missing network device content of some sort on the host PC side. If you look at the GUI for JetPack/SDK Manager you should notice at some stage where it offers a default network address of the Jetson at 192.168.55.1. This is the virtual network over USB if it works, but you can substitute another address if desired.
If you can actually log in to the Jetson (first boot setup would need to complete, and this should be sufficient), then you can run “ifconfig” or “ip -s addr” (depends on Ubuntu release) and find the wired ethernet IP address. Put that address into the GUI as a replacement to 192.168.55.1 and it should work (I’m assuming you have the wired Ethernet port of the Jetson plugged in to the same network switch that the PC is plugged in to).