[U-Boot] [PATCH] usb: ci_udc: fix interaction with CONFIG_USB_ETH_CDC

[Jörg Krause]

On 06/28/2014 01:37 AM, Stephen Warren wrote:
> On 06/27/2014 05:16 PM, Jörg Krause wrote:
>> On 06/27/2014 11:55 PM, Stephen Warren wrote:
>>> On 06/27/2014 03:37 PM, Jörg Krause wrote:
>>>> I added the last series of patches beginning from 2014-06-10 for testing
>>>> purposes. The patches from 2014-05-29 were already applied.
>>>>
>>>> First series of patches:
>>>>
>>>>      Applying: usb: ci_udc: call udc_disconnect() from ci_pullup()
>>>>      Applying: usb: ci_udc: fix freeing of ep0 req
>>>>      Applying: usb: ci_udc: fix probe error cleanup
>>>>      Applying: usb: ci_udc: clean up all allocations in unregister
>>>>
>>>> Calling tftp the first time after a reset runs fine,
>>> I thought the issue you reported was that the *first* time you run the
>>> "tftp" command, it has issues such as timeouts? Did I misunderstand, or
>>> did that issue somehow go away?
>> That's right! This was the state before applying a series of patches
>> after allow multiple buffer allocs per ep. Now, the first run of tftp
>> runs without any errors.
> Just to make sure I understand, here's what you saw:
>
> 1) tftp works fine to start with. No timeouts even on repeated invocation.
I went back in time and now I can be more precise. Everything worked 
fine until commit usb: ci_udc: allow multiple buffer allocs per ep which 
introduces timeouts in almost all tftp file downloads. Even the first 
run of tfpt can end in a timeout.

>
> 2) You applied "allow multiple buffer allocs per ep"
Setting #define CONFIG_SYS_CACHELINE_SIZE 32 to my config file helped 
here. But still timeouts. First run almost always runs fine, only 
sometimes timeouts while receiving a packet, but always running to the 
end. Running tftp after this a second time and more fails with a ERROR: 
The remote end did not respond in time. at 
drivers/usb/gadget/ether.c:2388/usb_eth_init(), but sometimes it works.

Setting CONFIG_SYS_CACHELINE_SIZE 32 does not make it better (as I 
previously wrote it).

Removing CONFIG_USB_GADGET_DUALSPEED helps a little bit, but I am 
getting also errors after the second or third run.
>
> 3) Now, you see tftp timeouts.
>
> 4) You applied "a series of patches *after* allow multiple buffer allocs
> per ep"
Applying: usb: ci_udc: parse QTD before over-writing it
Applying: usb: ci_udc: detect queued requests on ep0
Applying: usb: ci_udc: use a single descriptor for ep0
Applying: usb: ci_udc: pre-allocate ep0 req
Applying: usb: ci_udc: complete ep0 direction handling
Applying: usb: ci_udc: call udc_disconnect() from ci_pullup()
Applying: usb: ci_udc: fix freeing of ep0 req
Applying: usb: ci_udc: fix probe error cleanup
Applying: usb: ci_udc: clean up all allocations in unregister
Applying: usb: ci_udc: terminate ep0 INs with a zlp when required
Applying: usb: ci_udc: fix interaction with CONFIG_USB_ETH_CDC
Applying: usb: ci_udc: fix typo in debug message
>
> 5) Now, the first tftp command works fine, but repeated invocations fail
> (intermittently).
Now tftp runs fine the first time (and sometimes more often) after a 
reboot, but after some tftp runs I am getting the ERROR: The remote end 
did not respond in time. at 
drivers/usb/gadget/ether.c:2388/usb_eth_init(), as mentioned above.
>
> And in (4) above the patch you applied that solved the problem was
> "Applying: usb: ci_udc: fix interaction with CONFIG_USB_ETH_CDC"?
>
>>>> But there is still a problem:
>>>> I have to wait some seconds before I can run a second time tftp. This is
>>>> the output from U-Boot:
>>>>
>>>>      => run update_rootfs
>>>>      Updating rootfs ...
>>>>      using ci_udc, OUT ep- IN ep- STATUS ep-
>>>>      high speed config #1: 2 mA, Ethernet Gadget, using CDC Ethernet
>>>>      USB network up!
>>>>      Using usb_ether device
>>>>      [snip]
>>>>
>>>>      => run update_rootfs
>>>>      Updating rootfs ...
>>>>      using ci_udc, OUT ep- IN ep- STATUS ep-
>>>>      high speed config #1: 2 mA, Ethernet Gadget, using CDC Ethernet
>>>>      ERROR: The remote end did not respond in time.
>>>>      at drivers/usb/gadget/ether.c:2388/usb_eth_init()
>>>>
>>>> Wait some seconds ...
>>>>
>>>>      => run update_rootfs
>>>>      Updating rootfs ...
>>>>      using ci_udc, OUT ep- IN ep- STATUS ep-
>>>>      high speed config #1: 2 mA, Ethernet Gadget, using CDC Ethernet
>>>>      USB network up!
>>>>      Using usb_ether device
>>>>      [snip]
>>> Hmm. That's odd. I didn't notice that, but I'll try retesting sometime.
>>> What exactly does $update_rootfs contain? It might be useful to know
>>> some details of your network topology (e.g. is the TFTP server on the
>>> machine that the USB cable is plugged into or further away, and are the
>>> machine and network lightly loaded) and rough sizes of the files you're
>>> downloading.
>> This is what update_rootfs is doing:
>>
>>        "update_rootfs=echo Updating rootfs ...; " \
>>          "if tftp ${rootfs_file}; then " \
>>            "mtdparts default; " \
>>            "nand erase.part rootfs; " \
>>            "ubi part rootfs; " \
>>            "ubi create rootfs; " \
>>            "ubi write ${loadaddr} rootfs ${filesize}; " \
> I wonder if there's some kind of memory corruption caused by the
> mtdparts, nand, or ubi commands? I'm especially curious about this,
> since your other email mentioned that some mtd/ubi patches cause
> complete networking failures.
>
> If you *just* run "tftp ${rootfs_file}" over and over, does that work?
> If so, perhaps try running more and more of the commands from
> $update_rootfs above until you find the one that causes problems.
For all tests I only run tftp rootfs.ubifs. The mtd patches from Heiko 
Schocher make some changes to the gadget driver. Maybe that's the cause, 
that it fails together.
>>          "fi; " \
>>          "\0" \
>>
>> Filesize of rootfs.ubifs is about 13 MB.
>>
>> The tftp server (tftp-hpa 5.2-4) is running on my notebook (running Arch
>> Linux), where the device is plugged via USB cable. Ethernet is not used,
>> but wireless network, which is used "normal" I would say.
> OK, that's basically the same setup I used for testing, network/USB-wise.
>
> Unfortunately, I don't have and NAND or ubifs to test with.