question about l4t-usb-device-mode in writable mode (Solved)

/opt/nvidia/l4t-usb-device-mode/ setup filesystem.img as read-only. I am able to change that to writable. In Host side (X86) I can write file to it. On device side (Xavier), if I mount filesystem.img in loop back mode after file is written, I can see the file. If filesystem.img already mounted, I cannot see the new file. I can only see it if I umount it, and then mount it again.

Question: Are there way to immediately see the new created file in Xavier side? Any other better way to got notified once host side finished writing file, and being able to see the context of the new created file?


I’m unsure of what you are doing, but consider the file itself to be binary data you shouldn’t touch directly. The loopback device which covers this can be considered a disk partition. A given partition can only be mounted at one mount point, and thus only one loopback device can cover that file at a given time. Within the script it has “/sbin/losetup -f -r …”, and so if you already have this mounted the script will fail.

Within that losetup line of the script note the “-r” option. “man losetup” will show this as “read-only”, so this could be removed and the file, as mounted for device mode USB gadget, should then become writeable if other permissions allow.

Note that a real partition could be mounted to substitute for a loopback covered file pretending to be a partition, e.g., from an SD card.

A loopback file itself starts its life as an empty file with some size which is an exact multiple of a valid disk block size, e.g., 512 bytes repeated to be large enough to accept a file system. An example for creating a 1GiB version (102410241024 == 2097152):

# create an empty file...there are many ways to do this...via "dd":
dd if=/dev/zero of=custom_fake_partition.img bs=512 count=2097152
# Or via "truncate" (1024*1024*1024 == 1073741824...which is a multiple of 512):
truncate --size=1073741824 custom_fake_partition.img
# Then loopback cover this, but first note which device is used...a non-root user of losetup can read the next device name available for loopback, but it requires root to create one...using sudo or not using sudo here is intentional depending on whether I want "find" to create the device:
losetup --find
# ...if this responded "/dev/loop0", then covering this file with losetup while running as root will cause "/dev/loop0" to be created and become the device we are looking example will assume "loop0" was found.
sudo losetup --find ./custom_fake_partition.img
sudo mkfs.ext4 /dev/loop0
# Now detach:
sudo losetup -d /dev/loop0

Assuming you detached, then “–find” will again say “loop0” is the next available loop device. You could have directly used “mount” on the loop0 device prior to detaching, but I wanted to demonstrate the “mount” option “-o loop”. To mount this to “/mnt” (an arbitrary example typically used for mounting):

sudo mount -o loop /where/ever/it/is/custom_fake_partition.img /mnt
# can then explore "/mnt" as the content of your gigabyte image, e.g.:
df -H -T /mnt
# and umount (if you used "cd" to go into "/mnt", then you have to cd out before you can umount):
sudo umount /mnt
# ...this umount would also remove loopback coverage of the file and loop0 would again become available as the next loop device.

The script has a “-r” option causing the mount to be read-only. If you were to use mount to on the file instead of the loop device and wanted mount to be read-only, then this is equivalent (either “mount” can be read-only, or the loop device can be read-only…it is just a question of where you want to set that option):

sudo mount -o loop<i><u><b>,ro</b></u></i> /where/ever/it/is/custom_fake_partition.img /mnt