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

[Jörg Krause]

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.
> [snip]
> Yes, that is certainly expected to solve issues with *multiple*
> invocations of "tftp" or similar commands and ethernet over ci_udc. The
> first hunk in that patch fixes something I probably introduced during
> one of my ci_udc patches (probably the one that you originally replied
> to "usb: ci_udc: allow multiple buffer allocs per ep"), but the second
> hunk fixes a problem that I /think/ has always been there. Did multiple
> invocations of "tftp" using ci_udc as the network device ever work for
> you before, without random crashes or memory leaks?
Yes, it did. If I can remember right it stopped working after a series 
of patches from 2014-04-24. But I am not sure.
>> 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}; " \
         "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.