For a test setup I have mutiple jetsons connected to a pc and would like to flash them. To make sure to flash the correct images on the correct jetsons I wan to uniquely identify them after they entered recovery mode.
So far I was not able to do this. The jetsons in recovery just report serial number 0
Jul 17 14:59:59 kernel: usb 1-6.3: Manufacturer: NVIDIA Corp.
Jul 17 14:59:59 kernel: usb 1-6.3: Product: APX
Jul 17 14:59:59 kernel: usb 1-6.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jul 17 14:59:59 kernel: usb 1-6.3: New USB device found, idVendor=0955, idProduct=7023, bcdDevice= 4.01
Jul 17 14:59:59 kernel: usb 1-6.3: new high-speed USB device number 61 using xhci_hcd
Also the usb topology changes quite randomly if i enter recovery mode
A jetson goes from usb device 4-2 to 1-5 in recovery
But if I add it to another port it goes from
4-1.3 to 1-6.3
So I see no way to keep track which device is which.
Is there any easy way to get an identifier from a jetson in recovery mode? Also for the future I think the jetsons should report their serial number via USB also in recovery mode.
*** Please note that this reply is generated by LLM automatically ***
I understand your concern about uniquely identifying multiple Jetson devices connected to a PC in recovery mode. Unfortunately, the current behavior of Jetson devices in recovery mode is to report a serial number of 0, which makes it difficult to distinguish between devices.
The issue you’re facing is that the USB device identifier changes randomly when you enter recovery mode, making it challenging to keep track of which device is which. This is because the USB topology changes when the device enters recovery mode, and the device is assigned a new USB device number.
After analyzing the provided context, I couldn’t find a straightforward solution to obtain a unique identifier from a Jetson device in recovery mode. However, I can offer a few potential workarounds:
- Use the
lsusb command with the -t option: This command can help you identify the USB topology and device numbers. By running lsusb -t, you can see the USB device tree and identify the device numbers. However, this method is not foolproof, as the device numbers can change when the device enters recovery mode.
- Use the
flash.sh script with the -i option: The flash.sh script allows you to specify the device identifier using the -i option. You can try using this option to specify the device identifier, but this may not work if the device is not properly identified in recovery mode.
- Use a USB hub with a fixed device number: If you’re using a USB hub, you can try connecting the Jetson devices to the hub and see if the device numbers remain consistent. This method is not guaranteed to work, but it might help in some cases.
- Modify the recovery mode behavior: As you suggested, it would be beneficial if the Jetson devices reported their serial number via USB in recovery mode. You may want to consider filing a feature request with NVIDIA to implement this behavior in future firmware updates.
In summary, while there is no easy way to obtain a unique identifier from a Jetson device in recovery mode, you can try using the workarounds mentioned above. However, these methods are not guaranteed to work, and the best solution would be for NVIDIA to modify the recovery mode behavior to report the serial number via USB.
*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***
I don’t think any of those ideas apply / work. I also consulted some LLMs myself before posting here so I would appreciate a human response.
USB does not normally have “fixed” setup. Every time a USB device is detected it gets enumerated based on order of load. If you have two USB devices and they happen to load in a different order, then their slot will also differ.
The manufacturer and product ID can do a lot to filter out other devices, but a recovery mode Jetson is just a custom USB device, and you won’t see much which lets you positively ID a recovery mode versus simply a device mode of a running Jetson. To get fully verbose USB information you have to use sudo, and this is a lot of information, but if you look closely maybe there will be something you can use to ID a more specific case like this:
sudo lsusb -d 0955:7023 -vvv
One could write a custom udev rule to rename a USB device, or to add a symbolic link to another name while leaving the original device name alone. The trouble there is that you’d still have to identify which device belongs to which Jetson, so it wouldn’t be of much use. Add to this the fact that the flash software is designed to use the existing ID format, and I think it might not be worth considering.
I don’t know of a good way to deal with this. Also consider that if you enter a command to a recovery mode device, then once that command completes, you would probably need to restart recovery mode for the next command (recovery mode state has to be reset between flash or clone commands).
If you were to power up each Jetson one at a time, in a particular order, and with a short time gap between plugging another Jetson in, then likely you could assume that the USB logical port named in logs also names the Jetson in the physical order they were plugged in. Your best bet, if you really need to know individual Jetsons, might be nothing more than plugging them in physically in order and watching logs.
What Jetpack version?
Are you using massflash
Linux_for_Tegra/tools/kernel_flash/README_initrd_flash.txt
or
Linux_for_Tegra/tools/ota_tools/version_upgrade/Image_based_OTA_Examples.txt
You could look at and grab the Jetson device identification plumbing from
Linux_for_Tegra/nvautoflash.sh
Thanks for the good ieads I think sequencing is the last thing i can do. something like:
- Make sure no etsons in recovery
- rebotte the first into recovery
- detect usb instance
- put the second one in recovery
- detect usb isntance
Which will probably work but it is very clumsy and probably not 100% reliable. But it probably the best option that is left.
I think not providing a serial in the recovery mode is a big oversight for production use cases.
We use our own image and flashing process, which is based on JP 6.1 and initrd_flash atm but I dont think it really depends for what I am trying to achieve.