Jetson Nano not detected as USB by specific device

I got a Jetson Nano dev kit, powered by the barrel cable.
When I use the micro-USB to connect to PC (Win/Linux), it works fine and PC can read/write to the board.
I have a 3rd party device that is able to read/write to USB flash drive, and I wish it to write to the Jetson, but for some reason, when I plug them together, it don’t detect it as a USB flash drive…

Said 3rd party device worked fine when I used raspberry-Pi board (g_mass_storage module), so I assumed that the Jetson kit will work too (and better)…

Does anyone have any idea what i’m missing?
(Do I have to add the g_mass_storage module my current Tegra/Jetson kernel? How?)



I don’t think those drivers are ever enabled on jetson side. What is your exact usecase here?

I mean what is going to be written to jetson? And what is the role of jetson here? A usb device?

Currently I use a PC to run python script that effects the 3rd party device. That device eventually emits log file to a USB flash drive that plugged into it. Instead of a flash drive, I used raspberry Pi, that was configured as act as flash drive to the device logs, and Pi to transfer them to the PC…

What I hope to achieve is to replace both PC and Pi with the one Jetson board - running python to process the 3rd device and also get its logs directly…

I don’t think that thing was supported on jetson.

And I have no idea what driver is needed to achieve your request.

You would have to make modifications, which might have a learning curve. I will suggest that if you monitor “dmesg --follow” on a Linux host PC, and you plug this into the PC, you will see log messages from the insert event. One of those will be about mass storage, and there will possibly be a note about a README file (actually, it is about the partition label with that in its name, not the actual README file, though there is a README file). That content is read-only.

The background is that the Linux kernel has something it calls the Gadget API. There are many devices which use a “standard” device driver, and USB always comes with that driver (there are also many custom devices needing a non-standard driver which must be installed for the USB device to work). Gadget is a framework to make it easier to set up some of the “standard” driver class devices. One is mass storage, and this is what the README is using.

That particular README is limited due to being read-only. The filesystem behind a mass storage Gadget is usually what determines this, perhaps also along with Gadget setup. If you want to adapt this for your own use, then you have to understand what mass storage devices Gadget can work with.

In the sample which runs on a Jetson a file is added, that file is then covered with loopback, and the loopback device appears to be a partition. That loopback device is formatted, and the README file is added to that after mounting the loopback device at a mount point. This is a small file, and thus the partition is also small (even smaller due to filesystem overhead during formatting). The file is read-only, so loopback could not mount this as writable (or it might be able to do so, but modification at the file level would then break the write).

One could also use an actual partition. If you have extra storage on your Nano, e.g., in the form of an NVMe or other drive, then you are in luck. You could use a partition tool which understands formatting, and slice off a new partition, format that, and simply rename the loop device as that partition (after formatting), set it as read-write, and it would mostly “just work” (I don’t know if there is another detail, but probably this would work with not much effort).

Keep in mind that this is always appearing as a formatted partition regardless of whether it is a loopback file or a partition. The partition could even be the actual Nano’s content (though that is not wise for some reasons I’ll mention below). However, the system which uses the Gadget device must understand the partition type. If your other system is Linux, then an ext4 partition is a great choice. If your other system is Windows, then you’ll need either VFAT or NTFS. Remember when I mentioned the actual Nano content as the partition possibility? You can’t do this with VFAT or NTFS, it has to remain ext4, so there is a limitation.

Beyond limitations, if you do make the ext4 of the root filesystem available, it means you are exposing system files for modification and read. There might be some options available to adjust what user the rootfs is accessed as, but I have not tried to make such adjustments, so I can’t tell you what to do to change this or help with security. There is a much bigger learning curve if you want to modify this to access the actual Nano rootfs as a whole and deal with security.

You might want to examine “/opt/nvidia/l4t-usb-device-mode”. You might also want to examine the output of this command:
systemctl status nv-l4t-usb-device-mode.service

The systemd daemon (controlled with systemctl, also known as “init” in recent Ubuntu) is being used to start and stop this “README” mass storage example. In the directory mentioned above you will find files related to the Gadget setup (this includes both a virtual network device over that USB cable and mass storage…same cable, two devices). The actual loopback covered file is the “filesystem.img” file (indeed, cd there, and examine the output of “file filesystem.img”; then examine the output of “losetup --list”). Much of the Gadget setup is in human-readable bash script files in that directory. Some are related to stopping or starting the Gadget. Others are related to sytemd stopping and starting as a service (which indirectly calls the other scripts that stop and start).

That’s a starting point.

1 Like

we got the board to be read as USB device on the non-PC device.
here are the steps we took-
open terminal and go to /opt/nvidia/l4t-usb-device-mode/
make sure time is setup correctly
set enable_rndis=0
set enable_acm=0
set enable_ecm=0
set fs_img=“${script_dir}/usb-drive.img”
comment out all code that cpoies system version information into the exposed filesystem
comment out echo 1 > “${func}/lun.0/ro”
remove the -r argument from /sbin/losetup -f “${fs_img}”
run the command: dd if=/dev/zero of=./usb-drive.img bs=1M count=2048
run the command fdisk ./usb-drive.img
enter the following commands:
(hit enter to use default)
(hit enter to use default)
(hit enter to use default)
run the SH script ./
sudo losetup -o $((2048*521)) /dev/loop0 ./usb-drive.img
if loop got busy error: sudo losetup -d /dev/loop0
and run 12 again.
sudo mkfs -t vfat -v /dev/loop0 -n USB-drive
sudo losetup -d /dev/loop0
run the SH script ./

mount drive to self, so the board can “read” the what been written to the “USB” portion:
run the SH script ./
sudo losetup -d /dev/loop0
sudo mkdir -p ./usb-drive
sudo mount -o loop,offset=$((2048*521)) -t vfat ./usb-drive.img ./usb-drive
cd usb-drive and see the files

unmount drive from self:
sudo umount ./usb-drive
sudo run the SH script ./

hope this will help anyone else who face this niche case :)

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.