[L4T 32.3.1] nvmflash.sh cannot detect connected USB devices

Hello,

I am trying to create a mass img to flash to multiple production modules at once.
We are using a “Master Nano” with the mass img inside, and that Master Nano flashes the actual target Nano’s. When we connect our target Nano, it is in recovery mode and can be found through ‘lsusb’. But when we run ./nvmflash.sh, we get the following error in the mfilogs:

*** Sending BCTs
/home/user/mfi_jetson-nano-emmc/tegrarcm --instance 1-2.3 --download bct
P3448_A00_4GB_Micron_4GB_lpddr4_204Mhz_P987.bct
unsupported ioctl: cmd=0xffffffff8004550f
Cannot open usb device.Check if device is in recovery
*** Error: Sending BCTs failed.

I don’t see a problem with using a Nano as a host pc for the mass img, so can you please explain why this issue would happen?

Unless you are speaking of a master Nano image, then it won’t work. It sounds like you want to use a Nano as a host PC to perform a flash, and if that is the case, then the architecture of a Nano won’t work…the flash software is strictly x86 style PC architecture, and the Nano is arm64.

Generally speaking, *NIX tends to make all I/O basically look like a file. However, sometimes that file is really a driver to hardware, and hardware tends to need extra commands which a regular file does not need. Those commands are specific to the driver, and the call to run those extra config settings is the “ioctl” call. Any “unsupported ioctl” is basically the driver telling you that you tried to use some custom command which that driver does not understand. In this case perhaps the lack of understanding is that the code was meant for a different CPU architecture.

1 Like

Hello @linuxdev
I see. So theoretically if we had an SBC that had an x86 processor, then we can use it as a flashing host?

Yes. Command line flash would work with most any standard flavor of Linux (my PC runs Fedora). Using SDKM/JetPack implies this computer would need to run Ubuntu 18.04 (the GUI front end to flash and optional package install requires this, the flash back end does not care).

I do have to warn you though, there are some Intel NUCs people have used which fail. In theory those NUCs should work, but there seems to be some steps in designing those NUCs which may not be compatible (not all NUCs would fail, but some will). If you use some form of miniature NUC, then you should test it once before committing to it.

I tried to flash a Jetson TX1 (Target) with flash software running on the Nano (Host), and I ran into the following error as well.

Is it possible or worthwhile to cross-compile the flash software to run on Arm? The mobile industry seems to be trending towards Arm…

What if we do not use the Flash GUI software and install packages by hand (manually) as a work-around?

sudo ./flash.sh jetson-tx1 mmcblk0p1
###############################################################################

L4T BSP Information:

R32 , REVISION: 4.3

###############################################################################
Unsupported ioctl: cmd=0xffffffff8004550f
Error: probing the target board failed.
Make sure the target board is connected through
USB port and is in recovery mode

NOTE: This all sort of applies the same for both Nano and TX1, but I am wording for Nano since this is the Nano forum.

I’m not sure if I am just reading the language incorrectly or not, but the Nano would be the target. Host would have to be a desktop PC format amd64/x86_64 Ubuntu. The result of this would install to the Nano when run for flashing the Nano.

The actual flash software is available only in binary form and is not publicly available. There are no options for running this flash software anywhere except on a regular host PC (to emphasize, the GUI requires Ubuntu 18.04 PC, but command line flash works from most any Linux PC using any distribution). It is a common topic in the forum to talk about options for self-flash (doesn’t really exist). The more recent L4T releases (the part which actually gets flashed to the Jetson) are able to do release upgrades via packages and thus avoid needing a host PC for version upgrades. Older L4T releases do not have that ability.

I usually use Fedora, and so I cannot use the GUI (I have a dual atom 10" laptop running Ubuntu 18.04 I can remote display to Fedora if I have to). Command line flash works quite well from virtually any Linux PC.

You can download the “driver package” and “sample root filesystem” without JetPack/SDKM. A list of releases are here (you may need to log in, and then go there again…only the more recent release allows future upgrades without SDKM):
https://developer.nvidia.com/linux-tegra

In the case of using JetPack/SDKM, if you know where to look, there is a file called “repository.json”. This contains a base URL address, and various locations to download specific content. You can in fact download these manually. In the case of “.deb” files for packages to optionally install to the Jetson, then after flash you can copy these to the Jetson and manually install them with dpkg or apt. The nice part about SDKM/JetPack is that it understands dependencies and install orders…if you do this manually you may need to experiment to find the correct install order.

Tip: If you use dpkg to install, and name several .deb files at the same time, then dpkg is at least smart enough to correctly order install for those particular packages. Using apt-get adds resolving dependencies over the internet.

Issues with not being in recovery mode are often due to using a charger cable instead of the dev kit cable, or using a VM (VMs don’t handle USB correctly unless you configure them to).

Thanks for responding.

Just to clarify. In my set-up, the Nano is the Host and the TX1 is the Target machine for the flash. The Nano has already been flashed and works well with Jetpack 4.4. (L4T 4.3).

I have already downloaded the L4T 4.3 “driver package” and “sample root filesystem” to the Nano and I ran into the “Unsupported ioctl: cmd=0xffffffff8004550f” error when I tried to flash the TX1 using the micro-USB and the following command:

sudo ./flash.sh jetson-tx1 mmcblk0p1

What are the steps involved in the Command line flash??? Nvidia should make a video detailing the command line method steps…

Thanks.

The Nano is not capable of acting as a host using the flash software. It is the wrong architecture, and the binaries used for flashing are not able to run on arm64/aarch64.

Regarding “Unsupported ioctl”, consider that on anything *NIX that almost everything can be accessed as a file for read and/or write. However, the files which are “pseudo files” are not true files, and are instead a kernel feature or driver pretending to be a file. The IOCTL is needed to access features of that driver which do not correspond to a regular file operation. For example, one can read and write to/from a UART, but a UART also needs a speed and parity setting…which does not exist for a regular file. An IOCTL allows this. Any time you see an “unsupported ioctl” you are trying to use a custom feature of a driver which does not exist for that driver. This in turn is often because the hardware behind the driver is not the hardware which would provide that feature.

To add to this, despite some of the flash software being portable shell script, the binary content behind this is amd64/x86_64 and there is no possibility of this running on arm64/aarch64 without an emulator.

There is no possibility of flashing a TX1 from a Nano. The binary content is for the wrong architecture, and apparently drivers (and probably hardware behind the drivers) do not understand a required IOCTL.

Technically, if you were not flashing a TX1 and if the TX1 were fully operating, then you could use the Nano to perform some update operations, but it would be risky and difficult, e.g., using dd to copy partitions for overwrite on a running system.