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

Jörg Krause
2014-06-27T23:16:44Z

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.