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

["Jörg Krause" <jkrause@posteo.de>]

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.