usb mass media storage

pHilipp Zabel philipp.zabel at
Fri Sep 5 13:04:52 CEST 2008

On Fri, Sep 5, 2008 at 4:41 AM, Dale Maggee <antisol at> wrote:
> Petr Vanek wrote:
>> I have spent a while googling this up and have no wiki skills but
>> someone might find this useful:
>> to make FR act as a memory stick, here is what my script does:
>> #!/bin/sh
>> /etc/init.d/networking stop
>> rmmod g_ether
>> modprobe g_file_storage file=/dev/mmcblk0p1
>> --
>> Petr Vaněk
> very cool, but before I test it out (potentially breaking my usb
> networking in the process), I have a couple of questions:
> 1. will this persist over a reboot, or will it revert back to being an
> ethernet gadget when I reboot?

It's not persistent unless you add something like this to the init
scripts. After rebooting the ethernet gadget will be back.

> 2. is the following sufficient to switch it back?
> #!/bin/sh
> rmmod g_file_storage
> modprobe g_ether
> ifup usb0
> (assuming I replaced '/etc/init.d/networking stop' with 'ifdown usb0' as
> recommended by Daniel)
> 3. can somebody point me to a resource for the g_file_storage module
> where I can learn more about it? I did a couple of quick googles but
> didn't see anything promising. specifically I'd like to know more about
> the file parameter - I assume that in this scenario our "usb stick" is
> using partition/device information from /dev/mmcblk0p1, and will be
> partitioned in the same way as the SD card? what If I wanted to have my
> home directory accessible in "usb stick" mode?

I suggest to read the comment in the source code, it's quite detailed:;a=blob;f=drivers/usb/gadget/file_storage.c;hb=HEAD

The file parameter determines the raw backing store for the storage
device, so if you
have file=/dev/mmcblk0p1, its contents will directly appear as
/dev/sdx on the host. As mmcblk0p1 doesn't contain a partition table,
so won't sdx. If you want to export the whole device, use
file=/dev/mmcblk0, you'll get the partition table in /dev/sdx and the
kernel will parse it and create /dev/sdx1 (containing the contents of
/dev/mmcblk0p1) etc.

The host has direct access to the block device, so it is important
that /dev/mmcblk0p1 is not mounted on both the phone and the host at
the same time (unless it's mounted ro on both).


More information about the community mailing list