• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 106 subscribers
  • Views 6977 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

USB DMA Critical issue (ARM_MPU.KERNEL.39)

Qmax
Expert 2280 points
Other Parts Discussed in Thread: AM1808, AM3517, OMAPL138

Dear all, I need urgent clarifications about this issue.

Looking at Sitara SDK 5.3.2.0 Release Note a new critical issue ARM_MPU.KERNEL.39 has arisen: DMA support in Mentor MUSB driver is considered unstable and therefore it is suggested to disable it (of course with performance degradation).

The issue affects all platforms, i.e. AM180x and AM335x too: in fact in both platform Kernel configurations CONFIG_USB_TI_CPPI41_DMA has been replaced by CONFIG_MUSB_PIO_ONLY, and looking at Kconfig the following comment has appeared: "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". This surprises me because AM180x and AM335x have different ARM core architectures and also different PSP and Kernel versions, so I am wondering about the root cause of this issue: HW or SW?

It would be nice to have some clarifications about that, because planning to develop USB-based products with no DMA will have critical impact on.

I am also wondering if the same issue affects AM180x with Kernel 2.6.32 from older PSP (Sitara SDK 4.01).

Not sure this is the best forum, or Kernel one instead. I am interested in both AM1808 and AM335x products. Please move to the more appropriate.

Regards, Max

  • 0
    TI__Genius 15510 points

    The issue with DMA is in host mode only, not peripheral mode. It shows up only when you have DMA activity on bulk endpoints and activity on endpoint zero (EP0). EP0 can only use PIO mode. There is a timing issue when you have PIO activity on EP0 and DMA activity on other EP that can sometimes fail. EP0 is typically used for set up when you insert a device. We did see failures when MSC was doing bulk transfers with DMA and we inserted/removed other USB devices so that EP0 was doing PIO transfers. Some USB WiFi device, such as the D-Link DWA-125B, use the Ralink rt3070 chipset. These use EP0 for control/status so that if other devices use bulk endpoints, with DMA, the bulk data transfer could fail. PIO mode never failed. Our design team and PSP team are looking into a workaround or a fix for the problem.

    So you have to really look at your use-case. If you know you'll only have bulk transfer like MSC and not inserting/removing other devices, you'd be safe to use DMA. If your use-case had a hub and you have MSC and the D-Link DWA-125B, DMA wouldn't be safe. I haven't looked at other USB WiFi devices.

    Steve K.

  • 0 in reply to Steve Kipisz
    Expert 2280 points

    Hi Steve,

    Thanks for your clarification. I'm having some troubles with USB in pheriperal mode and DMA, using some composite gadget modules. Probably it is something completely different from this case (ARM_MPU.KERNEL.39), but I would ask if you could help me in some way. I'm facing this issue just with AM1808: this is the thread about.

    Thanks in advance. Best regards,

    Max

  • 0 in reply to Steve Kipisz
    Prodigy 190 points

    Hi,

    I'm trying to get USB DMA working as host on a proprietary am3505-based platform with Linux kernel 2.6.33+backported am35x DMA support from 2 years ago.  I've experienced this bug on all Wifi USB dongles/sticks that I tried.  Putting the USB host in PIO mode works fine on some USB wifi sticks.  Is there any update/workaround/fix to this issue, one year later?

    Thanks in advance.

  • 0 in reply to Rick Ung
    TI__Guru*** 133096 points

    Rick,

    I assume you use the MUSB controller in host mode, and run into the issue as in the first post. It has a s/w workaround which uses CPPI DMA transparent mode for RX, checks the DATA Toggle for every 512-byte USB packet received, and corrects it if DATA Toggle got mismatch.

    This workaround has be implemented for AM335x device, which is based on 3.2.0 kernel. Please check the following patches.

    usb: musb: cppi41: use transparent mode to fix extra IN token issue
    http://arago-project.org/git/projects/?p=linux-am33x.git;a=commit;h=9596c83241d84ff6b3c0e757569f55029e2a915d

    usb: musb: cppi41: correct data toggle mismatch to fix extra IN token issue
    http://arago-project.org/git/projects/?p=linux-am33x.git;a=commit;h=baaa0c0425528486efcc70b7696dd6359f10b5bd

    usb: musb: fix bug in data toggle sw workaround
    http://arago-project.org/git/projects/?p=linux-am33x.git;a=commit;h=a9e9e758646ee41289c0030645bbdd43c711e9c1

  • 0 in reply to Bin Liu
    Prodigy 190 points

    Thank you for the prompt response, Bin!  Yes, your assumption is correct; I am using MUSB in host only mode.

    Here is a snippet of the MUSB info from dmesg:

    musb_hdrc: version 6.0, cppi4.1-dma, host, debug=0
    AM3517 OTG revision 4ea41001, PHY f0836e2, control 00
    musb_hdrc: ConfigData=0x1e (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
    musb_hdrc: MHDRC RTL version 1.900
    musb_hdrc: setup fifo_mode 4
    musb_hdrc: 28/31 max ep, 16384/32768 memory
    musb_hdrc: USB Host mode controller at d0810000 using DMA, IRQ 71
    musb_hdrc musb_hdrc: MUSB HDRC host driver
    musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1

    I am currently using kernel 2.6.33; is there a backport of the patches for 2.6.33 that you or anybody know of?  The reason for my asking is because my current kernel is heavily patched with custom code such that migrating to a new kernel would entail a huge time investment in development and testing.

    Thanks.



  • 0 in reply to Rick Ung
    TI__Guru*** 133096 points

    Rick,


    Unfortunately I am not aware of any backport for 2.6.33.

    But this workaround has been implemented for AM387x device family as while, which is based on 2.6.37 kernel. It is closer to 2.6.33 which you are using, I hope it is easier for you to back port. Please check the following branch.

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

  • 0 in reply to Bin Liu
    Intellectual 530 points

    Hi,

    I want to ask that is this issue also present on OmapL138 platform? Since this platform is almost binary compatible with AM1808. Will the workaround suggested work for Omapl138? The data toggle issue is present for OUT endpoints also. Thank You.

    Regards,

    Mughees Ahmed Chohan

  • 0 in reply to Steve Kipisz
    Expert 1100 points

    Hi,


    I hate to dig up an old thread but we have the TI816x and are having USB issues that I've been told are related to this same DMA EP0 issue that was discussed here.

    We did not hook up USB1 to anything and so the default case of the kernel being in host only mode causes continual usb overcurrent messages to be displayed on the console.

    I got around the overcurrent problem by enabling OTG mode and making USB0 a gadget host and USB1 a gadget device.

    My question is should I be using DMA or PIO_ONLY in this configuration?  We have a USB hub with a cold plugged Micron SSD flash hanging off the hub and when I load down the USB testing the Micron flash file system ... I see journal errors and believe they are coming from these USB issues.

    Regards,


    Brian

  • 0 in reply to hutchman
    TI__Guru*** 133096 points

    Brian,

    hutchman said:
    My question is should I be using DMA or PIO_ONLY in this configuration?

    Since you have multiple USB devices connected through a USB hub which could trigger the DMA hw bug, only the PIO mode should be used.

  • 0 in reply to hutchman
    TI__Guru*** 133096 points

    hutchman said:
    We have a USB hub with a cold plugged Micron SSD flash hanging off the hub and when I load down the USB testing the Micron flash file system ... I see journal errors and believe they are coming from these USB issues.

    With multiple MSC device connected, I believe the DMA hw bug could only be triggered when there is any new device plugged in - basically during usb enumeration while other DMA transfer is active. So I don't think the test failure you are seeing is related to the hw bug. It either could be DMA driver problem which corrupts USB packets, or not USB related at all.

  • 0 in reply to Bin Liu
    Prodigy 120 points

    Is there already a solution for this bug now?

    We're planning to use a AM335x in a new product in future, which also uses USB for WIFI +Bluetooth Dongles.

    Is only the PIO mode possible or can DMA be used now?

    Is there any support contact from TI for this USB-Issues ?

    Best Regards

    Pascal Speck