I added a correction to the previous post where I missed putting the file name in the loopback mount command:
sudo mount -o loop filesystem.img /mnt
Provided that the file filesystem.img is not already in use, you can also mount it on the Jetson itself. For example, if you momentarily stop nv-l4t-usb-device-mode.service, you could run that command on the Jetson itself. When the L4t device mode services run, it is set as read-only, and so that loopback mount is the only way to edit the file unless you’ve modified the arguments of the device mode setup script.
You should probably know that the gadget API is making available a partition, and is setting it to read-only. The partition in question is not a real partition, but is instead the file filesystem.img after being covered by loopback to pretend it is a partition. The script is mounting the loop device as a read-only partition, and this is what USB is making available.
If filesystem.img is itself made read-write for whichever user owns the mount, then this clears one constraint against read-write behavior. Within the loopback mounted system, if the contained L4T-README is writable by that user, then another constraint to read-write is lifted. If the argument to the loopback mount has read-only removed, then yet another constraint is lifted (note that in the manual loopback mount command I listed earlier it does not have a read-only constraint, plus the mount and other commands are sudo, and thus has full root authority). I think that would get the job done.
Note: Examine nv-l4t-usb-device-mode.sh. Take a close look at this line:
/sbin/losetup -f -r "${fs_img}"
(the command “mount -o loop” is a macro which first runs losetup to create a loop device, and then to mount the loop device rather than the file)
Also, if you have an actual partition, and not a loopback mounted file, then you could substitute that partition and all of its content instead of the file pretending to be a partition.