g_mass_storage windows seeing something different

[dluberger]

I'm installing the standard list of modules to get g_mass_storage up and running. I created a partition and formatted it as fat32 on my host linux computer.  this shows up as /dev/mmcblk0p3 on my target

with the prerequisite modules running, i run:

insmod /lib/modules/4*/kernel/drivers/usb/gadget/legacy/g_mass_storage.ko file=/dev/mmcblk0p3

and the device appears to be up and running. I plug in the usb cable to my windows host, and it connects. it shows "unallocated" for the device that shows up in disk manager, so i create a fat32 partition (although i had done that with cfdisk and mkfs.vfat F=32 on my linux host already). to test things out, i create a file called "test" from within the new drive in windows.  i mount the partition in my target to a dummy folder and look inside, and it shows nothing. so from within my target i create a file called "test2" and i look in windows and nothing is there except the original file "test" i created. thinking i wasn't mounted properly, i unmount the partition in my target, the dummy folder is empty, i remount and the "test2" file is there.  i unplug the windows host usb connection and plug it back in, and the drive comes back, and the file "test" is there! what is going on? windows reports the correct partition size, so i know it's connected to the partition i made, but why do my target and windows host see different contents??

if anyone could help i would appreciate it, but please don't point me to a document like the linux reference manual. it doesn't help. i need concise instructions on how to get g_mass_storage working between my embedded linux target and my windows host pc. thanks.

[dluberger · Accepted solution]

Unfortunately typical of the documentation for these processors, the answer ended up being something not apparently documented anywhere.  I found another thread with a similar question in which a download was given for test software for various peripherals. Digging through that source code, I found a readme with correct, working steps used for activating the mass storage gadget:

1. The kernel should be built with the chipidea usb drivers install statically and the mass storage gadget drivers installed as modules.
2. If the partition to be shared via mass storage connection isn't setup already, create one as win95 16 or 32 bit, and format. Since the yocto image I built didn't come with formatting tools, I had to do this on my linux host using cfdisk and mkfs.vfat commands.  I used the remaining, unused space on the target board's SD card.
3. Test steps state that the host pc usb cable should not be plugged in prior to running the following commands, however, it has worked fine for me to have the usb cable plugged in ahead of time. Probably a good idea not to have it plugged in on first initialization.
4. The following commands should be run in order; I did this with a shell script that's run every time the device boots; note that the partition I'm specifying is unique to my situation:
   1. modprobe phy_mxs_usb
   2. modprobe ci_hdrc_imx
   3. modprobe g_mass_storage file=/dev/mmcblk0p3 removable=1
5. In order to see the files added, modified, or removed by the host pc, it's necessary to mount the partition in question.  I did this with "mount /dev/mmcblk0p3 /mnt".

Again, these steps aren't listed anywhere that I can find, and in fact they differ significantly from the i.mx linux user guide that's listed all the time on this site.  It's unfortunate and frustrating that I had to do so much digging to get to this answer on my own when it seems to me to be something anyone who uses these processors would need to know.  Hopefully this post will help someone else get to the answer a lot more quickly than I did.

[chris_f]

dluberger‌ How are you getting on with this solution? Is it reliable?

I've read in a number of places that the only _safe_ way to have a filesystem mounted both on the host PC and the i.mx board is if they're _both_ read-only. That's no use to me at all.

A quick test here suggests that temporarily mounting the filesystem on the i.mx to look for changes will be OK but it would be good to hear your experience.

[b36401]

Please try to reload g_mass_storage module after filesystem creation.

Have a great day,
Victor

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------