USB Storage Gadget driver issue

Dear TI experts,

In AM335x PSP 04.06.00.03 Release Notes I've found two known issues that seem to be related to what I see: SDOCM00085673 and SDOCM00087173. Descriptions are really poor of details, both are focused on the fact that USB Pendrive or MMC card is used as backend file, but it's not clear if g_mass_storage is used as Gadget.

Please note that if I use g_file_storage instead of g_mass_storage everything works fine, with USB Pendrive and MMC card too. Is this your case, too?

How can I follow these known issues more in details? Is there any other instruments that this forum?
By the way is this the right forum or should I post on AM335x forum?

Thanks in advance.
Best regards,
Max

Max,

PSP releases has been tested with g_mass_storage gadget only. The issue SDOCM00087173 is seems with Linux PC while using MMC card as storage media using g_mass_storage. SDOCM00085673 is seen both with Windows and Linux PC in DMA mode when a USB HDD connected to port2 (in host mode) is used as storage media got gadget on port1.

As we have not tested deprecated g_file_stoarge gadget and based on your test results it seems these issues are related to new gadget g_mass_storage, We are yet to analyze and confirm on this.

This is right forum for Linux PSP related issues.

Further to answer on "stall option" is that we have not used this at all in PSP testing. It was used in g_file_stoarge gadget as "stall=0".

Regards,
Ajay

Hi Ajay,

First of all thanks for these further info.

After this post I've found other related info in latest Sitara SDK 5.3.2.0 Release Note, and written another post in Sitara AM335x forum (yet do not know if that was the right place). Please have a look at it: the issue seems related to DMA and affects different ARM architectures, Kernel and PSP versions! This asks me a lot of urgent and really critical questions for my project.

If the problem is USB+DMA, I cannot understand why it was not evident with g_storage_file in older SDK, e.g. with Kernel 3.6.32 on AM1808...

Ajay said:

Further to answer on "stall option" is that we have not used this at all in PSP testing. It was used in g_file_stoarge gadget as "stall=0".

The stall option value should depend on HW USB Controller and its driver: "A module parameter tells the driver to avoid stalling the bulk endpoints wherever the transport specification allows.  This is necessary for some UDCs like the SuperH, which cannot reliably clear a halt on a bulk endpoint."  And not on USB Gadget driver: it makes no sense to use "stall=0" with g_file_storage, and use the default value (i.e. "stall=1") with g_mass_storge. My question is: does the USB controller used in Sitara AM1808 and AM335x support "stalling"?

Happy new year.

Max

Max,

You particular issue is not due to DMA as confirmed by g_file_storage. The DMA issue mentioned in release document is the one which have been seen in host mode with wifi dongles using Ralink chipset. The debugging is still going on and would keep you updated. The musb gadget driver does support "stall" as I have seen patches on them in community

but have not verified it personally.

Regards,
Ajay

So, is the MUSB DMA issue related just to host mode and when specific WiFi dongles are connected?

This is quite surprising because note in Kconfig description is much more frightening: "MUSB_PIO_ONLY ... On CPPI 4.1 DMA based systems (AM335x, AM35x, and AM180x) DMA support is considered unstable and this option should be enabled in production". Moreover the tisdk_am335x-evm_defconfig configuration file has changed from version 5.3.0.0:

# CONFIG_MUSB_PIO_ONLY is not set
CONFIG_USB_TI_CPPI41_DMA_HW=y
CONFIG_USB_TI_CPPI41_DMA=y

to version 5.3.2.0:

CONFIG_MUSB_PIO_ONLY=y
# CONFIG_USB_TI_CPPI41_DMA is not set

The same seems to happen for AM1808 Kernel configuration: by the way there are two Kernel configuration in latest 5.3.2.0, the old da850_omapl138_defconfig and a new tisdk_am180x-evm_defconfig (and the latest is exactly the same of .config file). Which do I have to use? Sitara Linux SDG has not yet been updated to support SDK 5.03.02.00 so I do not know if its info are up-to-date.

Do you confirm that I can re-enable USB DMA support in Kernel configuration if I use MUSB in peripheral mode?

Regards, Max

Max,

yes, so far the issue has been observed in host mode with specific wifi devices. You can enable DMA mode and post a query if you face any issue.

Regards,

Ajay

Hi Ajay

Regarding USB Mass Storage, I can confirm g_mass_storage issues with latest AM335x SDK 05.03.02.00 and related kernel.

I've used tisdk_am335x-evm_defconfig kernel configuration (where CONFIG_MUSB_PIO_ONLY is enabled instead of CONFIG_USB_TI_CPPI41_DMA), and loading g_mass_storage with MMC as backing-file causes the device to be reset by the USB host, with errors and faults.

Instead, everything seems fine with g_file_storage (but I need f_mass_storage for composite gadgets).

Please, keep me up to date on issue analysis and let me know if I can help you in any way.

Best regards,
Max

Max,

Thanks for update. The problem is inside g_mass_storage driver and so it will be good if you can send the findings in linux-usb@vger.kernel.org list where writers of g_mass_storage driver would comment and this issue can be fixed much faster.

Regards,
Ajay

Max,

I am also seeing instability issues with g_mass_storage driver whereas g_file_stoarge is working fine. I did below tests:

1. Use a nfs file as storage media and connect to XP PC. Getting reset errors with MSG
2. Use  usb hdd connected to other usb port as storage media. getting reset error or delayed enumerations if cable disconnected while read/write was in progress.

It seems not many people are using MSG and so issues are present in it.

Ajay

Ajay

Thanks for the update. File-Storage Gadget has been declared deprecated so I would expect people moving to Mass-Storage, which is not experimental so should be quite stable. I will try some further analysis, because this is a really blocking issue for our project.

If you could give me any suggestion on this other thread too, I would really appreciate. It's related to composite gadget: kernel crashes when USB is configured to use DMA, and when traffic starts on network interface over USB (just on AM1808). No crash when USB uses PIO. Thanks in advance.

Best regards, Max

Ajay,

Finally I've got AM335x EVM board, and I've run the same tests (previously run on beaglebone) on it.

I confirm the issue using g_mass_storage when the MUSB Controller works in DMA mode: device is reset frequently.

This happens both using SD card partition (/dev/mmcblk0p1) or USB storage connected to other USB port (dev/sda).

But when MUSB is in PIO mode, g_mass_storage works fine.

Gadget g_file_storage works fine both in PIO and DMA mode, too.

So the problem seems really related to Gadget g_mass_storage && MUSB controller in DMA mode, not to the gadget itself.

Please have a look also at this similar thread.

Regards

Max

Max,

Thanks for the update. I have checked other thread as well.

Ajay

Hi Max,

I've had a few problems with g_mass_storage on the AM335x too.  For my product, I'm using a disk image in RAM (/var/volatile/disk.img) and losetup.

Things I did to get it going:

1) Use the latest v3.2-staging kernel:

git clone http://arago-project.org/git/projects/linux-am33x.git

git checkout -b v3.2-staging origin/v3.2-staging

2) Configure with CONFIG_MUSB_PIO_ONLY=y

3) Configure with USB gadget as module: CONFIG_USB_GADGET=m and CONFIG_USB_MASS_STORAGE=m

4) load/unload/re-load the mass storage gadget, seems to help when usb is connected to PC when AM335x turned on.

dd if=/dev/zero of=/var/volatile/disk.img bs=1M count=16
losetup /dev/loop0 /var/volatile/disk.img
mkfs.vfat -n DEVICE /dev/loop0
modprobe ti81xx; modprobe g_mass_storage file=/dev/loop0
rmmod g_mass_storage
modprobe g_mass_storage file=/dev/loop0

Maybe this will help.  Did you get the mass storage working OK?

John, which type of problems exactly?

With latest repo kernel and PIO mode I'm working with g_mass_storage with no issue. Are you building ti81xx as kernel module? BTW you can use a standard file as backend file instead of 'wrapping' trough losetup: file=/var/volatile/disk.img.

Are you using a Linux o Windows PC on the USB host side?

Please note that iSerialNumber is mandatory for USB MSC, so I would add iSerialNumber=blablabla as module parameter when loading.

Let me know. Regards,

Max

Thanks for your advice, especially regarding iSerialNumber.  What kind of device is your backing file on?  RAM / NAND / SD-Card / USB-Memory-Stick?

I test against Windows XP and Linux (for diagnostics, i.e. dmesg), but for the product, the requirements will be Windows XP/Vista/7/8.

I'm using the AM335x EVM.  The main issue I ran into was the "USB Device Not Recognised" warning notification that appears on Windows XP when the AM335x turns on.  It appears during the kernel initialisation, by using CONFIG_USB_GADGET=m, this issue goes away.  IE Windows XP detects the generic usb gadget driver and complains when the USB hardware is initialised in the kernel, which is well before (> 10 sec) the g_mass_storage module is loaded by init in user-space.

Ref: http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/791/p/219180/772160.aspx#772160

Ref: http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/791/t/186665.aspx (near end of thread)

I also noticed the "Invalid PD" warnings coming out of cppi41_dma.c, so decided to PIO mode after seeing your posts.

I think the "USB Device Not Recognised" issue is a regression as I'm sure it wasn't a problem when I built the Linux v3.1 head of Arago with the default config, i.e. from git:

http://arago-project.org/git/projects/linux-am33x.git?p=projects/linux-am33x.git;a=shortlog;h=refs/heads/master

make CROSS_COMPILE=arm-arago-linux-gnueabi- ARCH=arm am335x_evm_defconfig

This sounds critical on your dmesg log:

[ 71.052037] usb 1-1: new high-speed USB device number 4 using ehci_hcd
[ 86.164042] usb 1-1: device descriptor read/64, error -110
[ 101.380051] usb 1-1: device descriptor read/64, error -110
[ 101.596037] usb 1-1: new high-speed USB device number 5 using ehci_hcd
[ 112.984028] usb 2-1: new full-speed USB device number 3 using uhci_hcd
[ 113.123647] usb 2-1: not running at top speed; connect to a high speed hub
[ 113.157831] usb-storage 2-1:1.0: Quirks match for vid 0525 pid a4a5: 10000

I've just run a quick test with the EVM and latest SDK 5.5.0.0 kernel (based on 4.6.0.8, just few commits behind head of staging branch) and rootfs, using a 2-partition micro-SD, and on my PC I have:

[88345.067426] usb 2-1.2: new high speed USB device using ehci_hcd and address 14
[88360.114512] usb 2-1.2: device descriptor read/64, error -110
[88363.201513] hub 2-1:1.0: unable to enumerate USB device on port 2
[88363.468981] usb 2-1.2: new high speed USB device using ehci_hcd and address 15
[88363.569161] usb-storage 2-1.2:1.0: Quirks match for vid 0525 pid a4a5: 10000

The first partition is seen correctly both by my Linux PC and by another Windows 7 PC, booting the EVM after plugging USB cable. But I have seen something similar to your case with another PC some times ago: the wrong speed 'detection', as the one stated on your dmesg log, caused the USB interface not to work, till I rmmod and then modprobed the g_mass_storage again. I supposed it can depends on the interaction between some specific USB hub or host on the PC side, and the OTG configuration of EVM USB interface. But I did not investigate more.

Also note that when cable is plugged after boot, there is no "device descriptor read/64, error -110" nor other error. What do you see when booting with cable already plugged and CONFIG_USB_GADGET=m? It would be interesting to understand the root cause, a USB protocol analyser would help but I do not have any.

The BBone has an USB configuration quite different, due to the FTDI and integrated hub.

I'm using SD-card and USB-mem-stick as backing file.

The issue in using DMA is the hardware bug on first revision of AM335x, see the silicon errata. But it could not affect your scenarios.

Thanks for your observation regarding "full-speed USB device".  This does seem to be the critical difference.

When I use 3.2-staging, and configure all USB as modules, and use the modprobe/rmmod/modprobe trick, the boot-up while USB cable connected works 100% reliably on this PC.  The complete PC log is:

[ 285.620031] usb 1-1: new high-speed USB device number 5 using ehci_hcd
[ 285.744045] hub 1-0:1.0: unable to enumerate USB device on port 1
[ 286.216028] usb 1-1: new high-speed USB device number 6 using ehci_hcd
[ 286.356210] usb-storage 1-1:1.0: Quirks match for vid 0525 pid a4a5: 10000
[ 286.356253] scsi6 : usb-storage 1-1:1.0
[ 287.356667] scsi 6:0:0:0: Direct-Access Linux File-CD Gadget 0316 PQ: 0 ANSI: 2
[ 287.357750] sd 6:0:0:0: Attached scsi generic sg6 type 0
[ 287.361532] sd 6:0:0:0: [sdf] 20480 512-byte logical blocks: (10.4 MB/10.0 MiB)
[ 287.466170] sd 6:0:0:0: [sdf] Write Protect is off
[ 287.466178] sd 6:0:0:0: [sdf] Mode Sense: 0f 00 00 00
[ 287.576197] sd 6:0:0:0: [sdf] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 287.797481] sdf:
[ 288.016157] sd 6:0:0:0: [sdf] Attached SCSI removable disk

Note the total time from the first message to the last message is 2.4 seconds which is good.

Details:

root@am335x-evm:~# uname -a
Linux am335x-evm 3.2.0-00030-gf6818a9-dirty #15 Tue Oct 16 11:21:12 NZDT 2012 armv7l unknown

echo ====
dd if=/dev/zero of=/var/volatile/disk.img bs=1M count=10
losetup /dev/loop0 /var/volatile/disk.img
mkfs.vfat -n DEVICE /dev/loop0
echo ====
modprobe ti81xx; modprobe g_mass_storage file=/dev/loop0
rmmod g_mass_storage
modprobe g_mass_storage file=/dev/loop0

root@am335x-evm:~# zcat /proc/config.gz | grep USB | grep -v ^#
CONFIG_USB_USBNET=y
CONFIG_USB_NET_CDCETHER=y
CONFIG_USB_NET_CDC_EEM=y
CONFIG_USB_NET_CDC_NCM=y
CONFIG_USB_NET_DM9601=y
CONFIG_USB_ZD1201=y
CONFIG_V4L_USB_DRIVERS=y
CONFIG_USB_VIDEO_CLASS=y
CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y
CONFIG_SND_USB=y
CONFIG_SND_USB_AUDIO=y
CONFIG_USB_HID=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
CONFIG_USB_DEVICEFS=y
CONFIG_USB_DEVICE_CLASS=y
CONFIG_USB_SUSPEND=y
CONFIG_USB_OTG=y
CONFIG_USB_MUSB_HDRC=m
CONFIG_USB_MUSB_TI81XX_GLUE=m
CONFIG_USB_MUSB_TI81XX=y
CONFIG_MUSB_PIO_ONLY=y
CONFIG_USB_STORAGE=y
CONFIG_USB_GADGET=m
CONFIG_USB_GADGET_VBUS_DRAW=2
CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2
CONFIG_USB_GADGET_MUSB_HDRC=m
CONFIG_USB_GADGET_DUALSPEED=y
CONFIG_USB_FILE_STORAGE=m
CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_OTG_UTILS=y
CONFIG_NOP_USB_XCEIV=y

I have seen this 'Full-speed' enumeration issue when connect the AM335xEVM to Linux Host PC, but not to Windows PC. The issue is on my TODO list, but I have not got time for it yet.

Thanks Bin Liu,

It would be most appreciated if you could look into it.  In the mean time, if you have any suggestions for me to try, e.g. kernel config options or patches or usb debugfs settings, please let me know.

Cheers,

    John.

Hi Bin Liu,  

I think the problem is related to the "soft connect" (MUSB_POWER_SOFTCONN) feature interacting poorly with the high speed chirp detection.  I tried this patch: "[PATCH] usb:musb: Fix for Full Speed issue" by Ajay M JAWADE.  But it didn't help when I had a hub between the AM335x and the PC and connected while bootup of AM335x.  

http://permalink.gmane.org/gmane.linux.usb.general/68295

The solution is to delay "soft connect" (i.e. D+ pullup) until after the g_storage_gadget module is loaded.  As a simple work-around (not a proper solution), I've used the /proc/driver/musb_hdrc.0 interface to control connection / disconnection ("C"/"c").  This works well in all tests so far.  The script below sends continuous disconnects in the background every 10 msec for about 3 seconds while loading the modules, and then sends a connect.

echo Handling soft-connect...
(for i in $(seq 1 1 300) ; do if [ -e /proc/driver/musb_hdrc.0 ]; then echo "c" > /proc/driver/musb_hdrc.0; fi; usleep 10000; done; echo "C" > /proc/driver/musb_hdrc.0) &

modprobe ti81xx
modprobe g_mass_storage file=/dev/loop0

John,

I have a further question on this topic. If I am not wrong you are using the AM335x EVM which has an OTG port on USB0 interface. And by default this interface is configured as OTG at MUSB driver level.

I would be interested to know if you see the same issue (speed detection) when the interface is configure as PERIPHERAL only. Just change the configuration in the board am335x-evm file, and patch the function in MUSB driver that set the mode so that it will write both bit 7 and bit 8 in USB0MODE register. I think this should be enough and work on EVM too: Bin Liu can confirm.

Regards, Max

Hi Max,

Thanks, that does the trick!!!

Cheers,

     John.

Details:

Kernel: git v3.2-staging branch of http://arago-project.org/git/projects/?p=linux-am33x.git;a=summary

In arch/arm/mach-omap2/board-am335xevm.c, I changed musb_board_data USB0 to MUSB_PERIPHERAL:

static struct omap_musb_board_data musb_board_data = {
.interface_type = MUSB_INTERFACE_ULPI,
/*
* mode[0:3] = USB0PORT's mode
* mode[4:7] = USB1PORT's mode
* AM335X beta EVM has USB0 in OTG mode and USB1 in host mode.
*/
// Was: .mode = (MUSB_HOST << 4) | MUSB_OTG,
.mode = (MUSB_HOST << 4) | MUSB_PERIPHERAL,
.power = 500,
.instances = 1,
};

In drivers/usb/musb/ti81xx.c:ti81xx_musb_set_mode(), changed:

else if (musb_mode == MUSB_PERIPHERAL) {
/* TODO commmented writing 8 to USB_MODE_REG device
mode is not working */
regval = musb_readl(reg_base, USB_MODE_REG);

regval |= USBMODE_USBID_HIGH;
// JFM removed: if (usbid_sw_ctrl && cpu_is_ti816x())
regval |= USBMODE_USBID_MUXSEL;

musb_writel(reg_base, USB_MODE_REG, regval);
dev_dbg(musb->controller, "device: value of mode reg=%x regval(%x)\n",
musb_readl(reg_base, USB_MODE_REG), regval);
}

Hi Bin,

BTW, I notice that with the MUSB_PERIPHERAL changes above, the behaviour of the soft connect (D+ pullup) changes.  Before I made the MUSB_PERIPHERAL changes, when I do "modprobe ti81xx", I see the LED on my USB hub come on (i.e. pullup is on).  After the changes, the LED on my USB hub doesn't come on when I do "modprobe ti81xx", i.e. no pullup.  After the changes, the LED on the hub only comes on after I load the gadget driver (e.g. "modprobe g_mass_storage file=..."), which is the correct behaviour for a USB gadget.

Cheers,

    John.

John,

This MUSB_PERIPHERAL configuration should work, but please run through all tests which your use case requires.

I have a customer reported that changing to MUSB_PERIPHERAL causes usb reset randomly. But I could not replicate the issue. That was in Android using android_usb composite gadget driver.

John,

I think I found the root cause. Please try the following patch and let me know if it works for you. I have tested it on my evm, it fixes the fullspeed enumeration issue.

From 406a09435be0101474f0cacbcc6dc71af38aa103 Mon Sep 17 00:00:00 2001
From: Bin Liu <b-liu@ti.com>
Date: Fri, 16 Nov 2012 12:37:54 -0600
Subject: [PATCH] usb: musb: ti81xx: fix gadget enumerated as Fullspeed device

When musb is in otg mode, no matter the gadget driver is built
in kernel or as a module, if connected to USB host before power on
the platform, the host enumerates the platform as Fullspeed device
after powered it on.

The root cause is that before the gadget driver is initialized,
otg_timer() toggles SESSION bit in devctl register which enables D+/D-
pullup, which causes host PC starts to enumerate before the gadget
driver notifying it is a Highspeed device.

The solution is that do not toggle the SESSION bit if VBUS presents,
which means already connected to a host.

Signed-off-by: Bin Liu <b-liu@ti.com>
---
 drivers/usb/musb/ti81xx.c |   28 +++++++++++++++++-----------
 1 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/musb/ti81xx.c b/drivers/usb/musb/ti81xx.c
index e7546bc..b006249 100644
--- a/drivers/usb/musb/ti81xx.c
+++ b/drivers/usb/musb/ti81xx.c
@@ -714,18 +714,24 @@ static void otg_timer(unsigned long _musb)
                devctl = musb_readb(mregs, MUSB_DEVCTL);
                if (devctl & MUSB_DEVCTL_HM) {
                        musb->xceiv->state = OTG_STATE_A_IDLE;
-               } else if ((devctl & MUSB_DEVCTL_SESSION) &&
-                               !(devctl & MUSB_DEVCTL_BDEVICE)) {
-                       mod_timer(&musb->otg_workaround,
-                                       jiffies + POLL_SECONDS * HZ);
-                       musb_writeb(musb->mregs, MUSB_DEVCTL, devctl &
-                               ~MUSB_DEVCTL_SESSION);
-               } else {
-                       mod_timer(&musb->otg_workaround,
-                                       jiffies + POLL_SECONDS * HZ);
-                       musb_writeb(musb->mregs, MUSB_DEVCTL, devctl |
-                               MUSB_DEVCTL_SESSION);
+                       break;
                }
+
+               /* don't toggle SESSION flag if VBUS presents - connected
+                * to Host already
+                */
+               if ((devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS)
+                       break;
+
+               if ((devctl & MUSB_DEVCTL_SESSION) &&
+                               !(devctl & MUSB_DEVCTL_BDEVICE))
+                       devctl &= ~MUSB_DEVCTL_SESSION;
+               else
+                       devctl |= MUSB_DEVCTL_SESSION;
+
+               mod_timer(&musb->otg_workaround,
+                               jiffies + POLL_SECONDS * HZ);
+               musb_writeb(musb->mregs, MUSB_DEVCTL, devctl);
                break;
        default:
                break;
--
1.7.0.4

Thanks, I'll give it a go in the next few days, when I do some more usb related work.  Are you planning to add this patch into the Arago git repo (v3.2-staging)?

ie: http://arago-project.org/git/projects/?p=linux-am33x.git;a=shortlog;h=refs/heads/v3.2-staging

This patch has been submitted to Arago for review. Hope it will be available on Arago git soon.

Hi Bin Liu,

Thanks, the patch works well.  

I tested it on my AM335x EVM, using the latest  Arago v3.2-staging Linux kernel branch, with the default am335x_evm_defconfig kernel config, and the standard AM335x EVM SD card rootfs.  (I only updated the uImage and modules).

It works fine on Windows XP and Linux, for both cases:  USB cable connected before AM335x powered on, and USB cable connected aftwards.

I haven't done any USB OTG testing.

Cheers,

    John.

John,

Thanks for confirming that.

I see this patch has been pushed to v3.2-staging branch this morning.