Jetson TX2 otg Mount device read only

We want to use TX2’s otg to transfer data, but find that the directory mounted on the PC is read-only. Use mount to manually modify the permissions, but prompt the device to write protection. Is there a way to change it to read/write?

Error message:
mount: cannot remount /dev/sdb read-write, is write-protected

Are you using the script from here?

/opt/nvidia/l4t-usb-device-mode/nv-l4t-usb-device-mode.sh

This file has this particular code black, and the “echo 1” could be commented out:

if [ ${enable_ums} -eq 1 ]; then
    cfg_str="${cfg_str}+UMS"
    func=functions/mass_storage.0
    mkdir -p "${func}"
    ln -sf "${func}" "${cfg}"
    [i][u][b]# Prevent users from corrupting the disk image; make it read-only
    echo 1 > "${func}/lun.0/ro"[/b][/u][/i]
    echo /opt/nvidia/l4t-usb-device-mode/filesystem.img > "${func}/lun.0/file"
fi

If i comment the above line, still i get same issue. So is there any other way to mount it in read write mode.

Did you chmod the underlying file itself to be read/write? I’m not sure which user the gadget mode actually runs as…if it runs as root, then you wouldn’t need to change anything. It is easy to be sure though:

sudo chmod ugo+w /opt/nvidia/l4t-usb-device-mode/filesystem.img
# Or to put it back the way it was:
sudo chmod go-w /opt/nvidia/l4t-usb-device-mode/filesystem.img

(you would still comment out the echo 1 to ro)

Also, check to see if something is showing the file system as filled…which would behave as read-only…but the fix would differ.

Currently we are working on jetson tx2 board R28.2, and our requirement is to transfer data from usb 2.0 (which is in device mode) to PC using bulk transfer. Currently we dont find any driver which support bulk transfer from USB 2.0 as device mode to PC other than mass storage. Only support is of mass storage to transfer data from device to PC. All other drivers like CDC ACM, Serial, Ethernet work in USB host mode.

We also tried to integrate usb-skeleton driver in usb device mode to transfer data from jetson tx2 usb 2.0 to PC, but probe of the skeleton driver is not getting called and because of that we are not getting any node configured to device side which is /dev/skel0.

Is there any other way or how to configure driver which should work in USB 2.0 device mode other than mass storage mode, which is the only way available to transfer data from usb to PC in jetson tx2.

If usb-skeleton driver is configured in device mode, then how it should be configured?

Other than this, how to configure any driver in USB device mode to transfer data from usb device to PC.

In addition to above comment:

For mass storage, f_mass_storage.c file used from drivers/usb/gadget/function, in which mass storage bulk transfer is used, which configures l4t on PC. Is this the only way to transfer data from USB device to PC on jetson tx2.

We tested CSC ACM and usb-storage drivers, which only work when USB device is set as host.

So what will be the approach in USB device mode to configure drivers like usb-skeleton, usb-storage etc to transfer data from USB device to PC using bulk mode using DMA.

usb-skeleton driver we tried because it has bulk transfer using DMA, so how to configure/probe this driver in USB device mode.

The OTG port of the TX2 supports all USB modes except for isochronous. Mass storage is a standard driver class, bulk transfer is a USB transfer mode. The sample in “/opt/nvidia/l4t-usb-device-mode/” shows how to set it up in R28.2 and R28.2.1.

It sounds like you are working directly in kernel code, which isn’t really necessary for mass storage (gadget doesn’t support anything for custom devices not from a standard class). Linux has a “gadget” framework which sets up part of what is needed to pretend a device mode port is any of a number of standard class devices (such as bulk storage). You’d still fill in some details before a virtual “gadget” device would work, but the “/opt/nvidia/l4t-usb-device-mode/” content shows how to do that for both a virtual hard drive and a virtual ethernet card.

Indeed, most of the drivers you find are for the host using a remote device, and not for creating a device on the host. The host/Jetson doesn’t need a driver in the usual sense when serving as a device since it isn’t the host using the device…and in fact is completely wrong to call the Jetson a host in this case…it is the other end of the USB pipe which is the host where the driver is needed.

I don’t know if DMA is supported under gadget, but device mode doesn’t probe…the host probes and controls the device (the emulation works with what the host asks for…in this case it is a standardized set of responses for mass storage…which happens to use bulk transfer mode for data). Somewhere there might be DMA code under gadget, but I don’t know. You might be interested in these (in addition to “/opt/nvidia/l4t-usb-device-mode/” content):
https://www.kernel.org/doc/Documentation/usb/gadget_configfs.txt
http://www.linux-usb.org/gadget/

Can anyone from NVIDIA comment if DMA is available to gadget framework mass storage devices?

Thank you linuxdev for the info.

Is there any way to configure provided usb-skeleton driver in usb device mode. With jetson tx2, we want to configure usb as device and PC as host.

So with above scenario, how we can configure usb-skeleton driver in device mode which transfers data using bulk mode.

I have not used this file, so I am not certain what it can or cannot do. Although it is still in DocBook format, this file is still readable in the kernel source (mostly there are just tags around paragraphs, but otherwise it is basically plain text):

Documentation/DocBook/writing_usb_driver.tmpl

…which lists usb-skeleton.c comments on how it is intended to be used.

I do see DMA used in usb-skeleton.c (function “skel_write_bulk_callback”), but otherwise have no advice on that.

Many people are out for the holiday, so someone may comment…but I wouldn’t expect anything until at least this Wednesday (or later). Perhaps someone from NVIDIA has used this function before and can comment on the DMA part of it. Many times if there is a DMA issue the code will need to be modified to use a virtual address through the SMMU instead of direct physical address. If you’ve worked on this and have DMA errors, do say which errors you get, and whether your address is physical or virtual.