Mass storage gadget support

[davidcoo882]

Hi,

How should I implement mass storage gadget on AGX Xavier and I would like to access eMMC or SSD on Devkit through USB cable? Thanks.

[WayneWWW]

Hi,

What we support now is using “opt/nvidia/l4t-usb-device-mode/nv-l4t-usb-device-mode-start.sh”.

In this line, the fs_image is a default one from /opt/nvidia/l4t-usb-device-mode/filesystem.img

echo “${fs_img}” > “${func}/lun.0/file”

You can try to write other node like /dev/sda1 and see if it can access it.

[HuiW]

Hi WayneWWW,

Thank you for your prompt support.
However, we tried to use /dev/sda1 and /dev/mmcblk0p1 to replace fs_img in nv-l4t-usb-device-mode-start.sh and got no storage.

Did I miss any?

Thank you,

[WayneWWW]

Hi HuiW,

We didn’t try it on our side either. So currently there is no official support for it.

We can only suggest to use the NCM driver, which is the usb network interface (192.168.55.1).

[WayneWWW]

Hi,

There is more example in nv_enable_remote.sh which also uses msc interface. This one has internal emmc as example. You can refer to it.

Linux_for_Tegra/tools/kernel_flash/initrd_flash/nv_enable_remote.sh

[linuxdev]

The example uses loopback to cover a formatted file. Actual use of sda1 would not use loopback. Be certain that when you use sda1 that loopback is not covering it.

[kayccc]

Hi @davidcoo882 and @HuiW

Is this still an issue to support? Any result can be shared? Thanks

[HuiW]

Hi Kay,

Sorry for late replied.

Hi WayneWWW,
Thank you for the information.

Sorry. it did not work.
Here are the steps I did. Please correct me if it’s not expected.

1. Add external_device part of nv_enable_remote.sh into nv-l4t-usb-device-mode-start.sh.
2. reboot

Got "l4tbr0: port 2(usb0) " in dmesg.
But could not see the usb device on another host.
(No matter, if "/sbin/losetup " added or not.

dmesg:
[ 179.501654] android_work: sent uevent USB_STATE=CONNECTED
[ 179.654406] configfs-gadget gadget: super-speed config #1: c
[ 179.654475] tegra-xudc-new 3550000.xudc: ep 5 (type: 3, dir: in) enabled
[ 179.654500] tegra-xudc-new 3550000.xudc: ep 3 (type: 2, dir: in) enabled
[ 179.654529] tegra-xudc-new 3550000.xudc: ep 2 (type: 2, dir: out) enabled
[ 179.654704] tegra-xudc-new 3550000.xudc: ep 9 (type: 3, dir: in) enabled
[ 179.654725] tegra-xudc-new 3550000.xudc: ep 7 (type: 2, dir: in) enabled
[ 179.654743] tegra-xudc-new 3550000.xudc: ep 4 (type: 2, dir: out) enabled
[ 179.654959] tegra-xudc-new 3550000.xudc: ep 15 (type: 3, dir: in) enabled
[ 179.655052] tegra-xudc-new 3550000.xudc: ep 11 (type: 2, dir: in) enabled
[ 179.655088] tegra-xudc-new 3550000.xudc: ep 6 (type: 2, dir: out) enabled
[ 179.655211] IPv6: ADDRCONF(NETDEV_CHANGE): rndis0: link becomes ready
[ 179.655832] android_work: sent uevent USB_STATE=CONFIGURED
[ 179.690387] tegra-xudc-new 3550000.xudc: ep 13 (type: 2, dir: in) enabled
[ 179.690423] tegra-xudc-new 3550000.xudc: ep 8 (type: 2, dir: out) enabled
[ 179.690796] IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready
[ 179.692006] tegra-xudc-new 3550000.xudc: ep 13 disabled
[ 179.692213] tegra-xudc-new 3550000.xudc: ep 8 disabled
[ 179.714912] tegra-xudc-new 3550000.xudc: ep 13 (type: 2, dir: in) enabled
[ 179.714951] tegra-xudc-new 3550000.xudc: ep 8 (type: 2, dir: out) enabled
[ 183.433303] l4tbr0: port 2(usb0) entered blocking state
[ 183.433324] l4tbr0: port 2(usb0) entered forwarding state
[ 183.433553] l4tbr0: port 1(rndis0) entered blocking state
[ 183.433562] l4tbr0: port 1(rndis0) entered forwarding state
[ 183.434300] IPv6: ADDRCONF(NETDEV_UP): l4tbr0: link is not ready
[ 183.434579] IPv6: ADDRCONF(NETDEV_CHANGE): l4tbr0: link becomes ready

Thank you for any advice,

[HuiW]

Hi linuxdev,

Thank you for your information.
Sorry. Not sure the meaning of " Be certain when you use sda1 that loopback is not covering it"
Would you address more about it?

Thank you,

[WayneWWW]

Hi HuiW,

Just let you know. This whole function is not a special function from NVIDIA. This is MSC function from upstream Linux usb usecase.

Please try to get this info over the Internet. The two services we provided are not the direct solution for your requirement.

What you want is already out of what we support.

[HuiW]

Hi WayneWWW,

Thank you for your prompt support.

[linuxdev]

When a file emulates a block device it requires an extra layer of software. This is loopback which causes a file to behave as storage. The example code uses loopback since it points to a file. sda1 has no such need, but if the sample code is edited to work with a real devices it is possible to accidentally leave loopback in the chain.