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.