From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?J=F6rg_Krause?= Date: Sat, 28 Jun 2014 02:09:07 +0200 Subject: [U-Boot] [PATCH] usb: ci_udc: fix interaction with CONFIG_USB_ETH_CDC In-Reply-To: <53AE003E.8090207@wwwdotorg.org> References: <1403546568-30830-1-git-send-email-swarren@wwwdotorg.org> <201406251551.29728.marex@denx.de> <53AAF389.3010204@wwwdotorg.org> <53ADE412.5060902@posteo.de> <53ADE847.8080104@wwwdotorg.org> <53ADFB5C.1040108@posteo.de> <53AE003E.8090207@wwwdotorg.org> Message-ID: <53AE07A3.4090509@posteo.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.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.