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

Jörg Krause
2014-06-28T00:09:07Z

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.
True.
>
> 2) You applied "allow multiple buffer allocs per ep"
I did a pull from the u-boot-imx branch. I am not sure which date it
stop working.
>
> 3) Now, you see tftp timeouts.
At the beginning I had random timeouts even running update_rootfs the
first time after a reset.
>
> 4) You applied "a series of patches *after* allow multiple buffer allocs
> per ep"
Yes. I applied these patches:

[U-Boot,1/4] usb: ci_udc: detect queued requests on ep0
[U-Boot,2/4] usb: ci_udc: use a single descriptor for ep0
[U-Boot,3/4] usb: ci_udc: pre-allocate ep0 req
[U-Boot,4/4] usb: ci_udc: complete ep0 direction handling

But the error still existed. I found out that setting #define CONFIG_SYS_CACHELINE_SIZE 32 in my config file helped. This is a quotation from my mail from 06/12/2014:

> I checked this and I found that ARCH_DMA_MINALIGN is set to 64, which
> is not true for Freescale i.MX28. This processor has an ARM926EJ-S,
> which has an cache line size of 32. In arch/arm/include/asm/cache.h
> the macro ARCH_DMA_MINALIGN is defined as followed: #ifdef
> CONFIG_SYS_CACHELINE_SIZE #define ARCH_DMA_MINALIGN
> CONFIG_SYS_CACHELINE_SIZE #else #define ARCH_DMA_MINALIGN 64 #endif
> And in /arch/arm/cpu/arm926ejs/cache.c as followed: #ifndef
> CONFIG_SYS_CACHELINE_SIZE #define CONFIG_SYS_CACHELINE_SIZE 32
> #endif arch/arm/include/asm/cache.h does not see the definition of
> CONFIG_SYS_CACHELINE_SIZE in /arch/arm/cpu/arm926ejs/cache.c, so it's
> a bad place to put it in there.

>
> 5) Now, the first tftp command works fine, but repeated invocations fail
> (intermittently).
Yes. The first tftp command almost always works fine. Sometimes I have a
timeout in between, but it runs to the end. But the timeouts are really
rare.
>
> And in (4) above the patch you applied that solved the problem was
> "Applying: usb: ci_udc: fix interaction with CONFIG_USB_ETH_CDC"?
This is also a quotation from my previous mail:

> I defined CONFIG_SYS_CACHELINE_SIZE to 32 in my config header file and
> it works under the following circumstances: I have to disable the
> macro CONFIG_USB_GADGET_DUALSPEED. But, and this is strange, it works
> only the first time of a tftp download after a reset of the board. If
> I try to use tftp a second time, I get the same timeout error as before.
>
> So, in short:
>
> => reset
> => run update_rootfs
> [...]
> done
> => reset
> => run update_rootfs
> [...]
> done
>
> works and
>
> => reset
> => run update_rootfs
> [...]
> done
> => run update_rootfs
> [...]
> timeout sending packets to usb ethernet
>
> results in a timeout. Strange.
>
> Lastly, I changed CONFIG_SYS_CACHELINE_SIZE to 16 and this works for
> me in normal mode an in dual speed mode.

So it worked, but there was already the error with running ftpd a second
time. I am not so sure about the setting of the
CONFIG_SYS_CACHELINE_SIZE to 16, because I did not used it anymore after
some test runs.

>>>> 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.

I will check this.
>
>> "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.