Hi, I connect nano to my pc via usb, and use USB Mass Storage, but only 16 MB space there, 1. Is there any way to expand capacity? 2.I cannot find the storage in nano
It is hard to answer without asking more, but if you run the command to monitor logs, “dmesg --follow”, and then plug in the USB storage device, what do you see? This should name the specific device.
Once the device is connected, what do you see from “lsblk -f”?
Just to let you know ahead of time, it is easy to expand storage to a mount point like “/usr/local” (which happens to be where CUDA and demo stuff is at), or with a slight bit more effort, to expand over “/home”. Mass storage to replace the whole rootfs is a different story, and has a learning curve.
I wanted to share the storage on the Nano via USB, so I could share the memory stored photos to Windows via USB.Now the problem is 1, I can’t find the Shared directory 2. The folder that appears under Windows is only 16MB
Probably Windows doesn’t understand the file systems exposed by the Nano. This might change if you install WSL2, but I kind of doubt it.
The best way to read the Nano file system is probably to set up SAMBA so you can access the files over the network (I would strongly recommend you share the file system read only).
Some background might be useful to you, but this is not in any particular order.
The micro-OTG USB connector accepts either a type-A connector (in which it acts as a host, and you can plug in devices like a mouse or keyboard), or a type-B connector (in which case the port acts like custom device or devices).
When you plug in the type-B cable (which is what Jetson dev kits ship with), and if that connector is not just for power, then it becomes possible for the Jetson to look like a device. As an example, it can appear to be a network device and cause the other side to be able to use ethernet over virtual USB. As the example you are more interested in (and the connector can do this simultaneously with ethernet function…it isn’t exclusive), this connector can appear to be mass storage.
You will find that the mass storage is just a sample. Many people have used cell phones and devices which were set up by default to provide access to the full filesystem and do not realize this is custom to each device. The sample mass storage of the Jetson is only a tiny file covered in loopback to create an independent sample virtual storage device.
The content where virtual USB device mode devices are described is at:
/opt/nvidia/l4t-usb-device-mode/
If you go there and run the command “file filesystem.img”, then you’ll find out that this is a binary image of a VFAT partition (meaning it looks like VFAT if covered by loopback, but is otherwise not a true partition…it is a “pretender”). A couple of files there stop or start the device mode service, but the file “nv-l4t-usb-device-mode-config.sh” is the file which actually defines the mass storage and virtual ethernet. This file is human readable, and you could for example look for a reference to setting up “filesystem.img” under loopback and then exporting it as if it were a VFAT formatted filesystem (and it is worth noting it is set up read-only).
The whole virtual USB system is part of what is known as the “gadget” API of the kernel. There are certain “standard” classes in USB, and they follow a template. The gadget is just a way to fill in details of different virtual devices and to use them with those custom details.
If you were to create a larger replacement to “filesystem.img” (it would have to be formatted correctly), and set it as read-write, then this would become more of what I think you are looking for. If you want other computers which are not Linux to be able to use this, then it would have to remain VFAT filesystem type.
If you were to export an actual directory tree running on the Jetson, then any computer not understanding the ext4 filesystem type would fail. It isn’t that you couldn’t for example export the entire “/home” directory tree so much as it is the computer looking at it not having a clue how to use ext4 filesystem type unless it is a Linux computer.
Now add in another problem with exporting directories directly: Linux will enforce permissions. Any computer using this content would probably result in needing to change permissions in some non-desirable way.
Another twist to the story: It is a problem if you want to mount a partition twice (there are reasons for shared filesystem types, such as network neighborhood or Samba or NFS). The loopback device is essentially a partition. If you cover it with loopback, and provide it to the USB virtual system, that’s fine. You could also mount this somewhere your user can reach it. Mount options can be used for read-write, read-only (the least problematic), ownership translations (remember that Linux understands user, group, and “other”, whereas VFAT has no understanding of “group”, so a translation of permissions must be used, and this is imperfect). Permissions on such a device can actually be complicated, and much depends on whether both local users and USB users can alter these files.
Just to give you an option, consider if you instead used Samba to export something which has better ability to deal with multiple simultaneous users and permissions (at the cost of great complexity and learning curve and resource usage, though often worthwhile). The USB virtual ethernet could then be used for the network connection and you’d still be using USB.
Would you be able to live with Windows being able to read the USB virtual storage, but not write to it, while a given user on your Jetson can write to it? If so, then setup would be simplified.
1 Like
Yes, That’s what I want to do.
yes,This is the easiest way. I will ask my boss if I agree with this.
Hi, now I find the way to extend the mass storag follow your suggest.
stops:
- cd /opt/nvidia/l4t-usb-device-mode/
- dd if=/dev/zero of=./disk.img bs=1M count=6144 //6GB
3… vi nv-l4t-usb-device-mode-config.sh， and modify the “fs_img” to
fs_img=“${script_dir}/disk.img”, - vi nv-l4t-usb-device-mode-start.sh, and remove
#umount “${mntpoint}”
#rm -rf “${mntpoint}”
echo 1 > “${func}/lun.0/ro”
,Then， I can visit the disk.img， in nano and in Windows.
But, I have a problem, too.
when I modiy something in nano ,I can not find the change unless I replug the usb in windows.
and , when I modify something in windows, I have to remount disk.img in nano to find the change.
Do you know how to sync the img both nano and windows?
Don’t forget you also have to format the file (via loopback) to be VFAT (“mkfs.vfat”). There might be another filesystem type which works, not sure, but definitely not ext4. Many of those other filesystem types will require installing a package either to format or to read that filesystem type.
What change are you speaking of needing replug? Details are important on this. A use case would help. Also, keep in mind that USB storage is not the same as a distributed filesystem for multiple simultaneous access of different users. If the filesystem behind the USB storage is for distributed access, then it will just “work right”, but that it isn’t the USB which performs the multiple simultaneous access operation.