We are trying to flash an industrialized Jetson AGX Xavier board with a custom image. The host being used to flash is a corporate Ubuntu 18.04. machine with extensive security restrictions.
Whenever we run the flashing script using:
sudo ./nvmflash.sh
*** Checking CPU Bootloader
///mfi_jetson-xavier-maxn2/tegradevflash_v2 --instance 1-1 --iscpubl
Cannot Open USB
*** Error: Checking CPU Bootloader failed.
After downloading SDK manager on the same host (Corporate ubuntu 18.04) then running the flashing script, the process works as expected.
It is also important to note that performing the same flashing process from an unmodified Ubuntu 18.04 host machine works without this error.
Unfortunately, installing the SDK manager on all host systems in impossible for us so we would like assistance in figuring out exactly which driver or kernel module is fixing the CANNOT OPEN USB error in “****/mfi_jetson-xavier-maxn2/tegradevflash_v2”
Maybe also an explanation of why this script outputs this exact text would point us in the right direction.
It seems you are using the custom board for AGX Xavier.
Do you mean your custom board could be flashed and boot up successfully with SDK Manger but flashed failed with custom image?
Have you tried to use the BSP package downloaded through SDK Manager and use flash.sh to flash your board?
That’s correct we’re using a custom board and our supplier provides us with the flashing environment and all scripts needed to flash.
We’re not using the SDK Manager to flash the board, we’re just installing it on the host machine, then when we flash using the provided custom flashing environment the flash succeeds without the CANNOT OPEN USB error.
SDK Manager is installing something on the host machine that allows this script:
The issue is that we can’t install the SDK Manager and what it downloads on all the host machines that need to be capable of flashing. It is too big in size and has too many unneeded packages.
We want to know which package specifically fixes the “CANNOT OPEN USB ERROR” to install just that.
Do you mean that your host PC doesn’t have enough space for SDK Manager and its packages?
Sorry, nothing would fix this, it is directly causing from USB connection from your host PC and the board. You could try changing another USB port or cold reboot your host PC.
Hi Kevin, I apologize for any confusion. To clarify, our issue is not with the USB connection itself, but with some component that the SDK Manager installs on our corporate host machine. When the SDK Manager is installed, the flashing process works without any errors. However, we can’t install the SDK Manager on all our host machines due to space constraints and unneeded packages.
What we need to know is which specific component or package within the SDK Manager installation resolves the “CANNOT OPEN USB ERROR” so that we can install only that component on our host machines, instead of the entire SDK Manager. Any guidance on identifying that component or package would be greatly appreciated.
If you want to flash the board, then the BSP package downloaded from SDKM is neccessary.
The SDK component is not necessary for the board to boot up. It depends on your application and you could install them after enter in to desktop with apt command.
But if there’s no specific component in the SDK manager fixing this error, how does it get fixed after I install the SDK manager?
I will reiterate on the fact that BEFORE I INSTALL SDK Manager, the flashing script throws the error and doesn’t succeed. AFTER I INSTALL SDK Manager, the flashing script succeeds with no errors.
How could that happen if there’s no specific component fixing this error?
Hi,
Did this 3rd party board provider provided a way to flash the board using SDK Manager?
Did install SDK Manager client itself helped you to resolve this issue, or did using SDK Manager to install Jetpack host components helped you to resolve this issue?
We finally figured that the issue was that the Host machines were laptops running on battery power instead of being plugged in.
This was causing the USB to disconnect and automatically reconnect whenever we run the Flashing script.
When we connected the hosts to their power adapters, the flashing works as expected.
Unfortunately every-time we were installing and testing with SDK manager, host machines were plugged in.