Mass storage gadget support


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.


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

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.

Hi WayneWWW,

Thank you for your prompt support.
However, we tried to use /dev/sda1 and /dev/mmcblk0p1 to replace fs_img in and got no storage.

Did I miss any?

Thank you,

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 (


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


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.

Hi @davidcoo882 and @HuiW

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

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 into
  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.

[ 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,

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,

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.

Hi WayneWWW,

Thank you for your prompt support.

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.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.