From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?J=F6rg_Krause?= Date: Sat, 28 Jun 2014 03:34:33 +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: <53AE1BA9.9000401@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. I went back in time and now I can be more precise. Everything worked fine until commit usb: ci_udc: allow multiple buffer allocs per ep which introduces timeouts in almost all tftp file downloads. Even the first run of tfpt can end in a timeout. > > 2) You applied "allow multiple buffer allocs per ep" Setting #define CONFIG_SYS_CACHELINE_SIZE 32 to my config file helped here. But still timeouts. First run almost always runs fine, only sometimes timeouts while receiving a packet, but always running to the end. Running tftp after this a second time and more fails with a ERROR: The remote end did not respond in time. at drivers/usb/gadget/ether.c:2388/usb_eth_init(), but sometimes it works. Setting CONFIG_SYS_CACHELINE_SIZE 32 does not make it better (as I previously wrote it). Removing CONFIG_USB_GADGET_DUALSPEED helps a little bit, but I am getting also errors after the second or third run. > > 3) Now, you see tftp timeouts. > > 4) You applied "a series of patches *after* allow multiple buffer allocs > per ep" Applying: usb: ci_udc: parse QTD before over-writing it Applying: usb: ci_udc: detect queued requests on ep0 Applying: usb: ci_udc: use a single descriptor for ep0 Applying: usb: ci_udc: pre-allocate ep0 req Applying: usb: ci_udc: complete ep0 direction handling 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 Applying: usb: ci_udc: terminate ep0 INs with a zlp when required Applying: usb: ci_udc: fix interaction with CONFIG_USB_ETH_CDC Applying: usb: ci_udc: fix typo in debug message > > 5) Now, the first tftp command works fine, but repeated invocations fail > (intermittently). Now tftp runs fine the first time (and sometimes more often) after a reboot, but after some tftp runs I am getting the ERROR: The remote end did not respond in time. at drivers/usb/gadget/ether.c:2388/usb_eth_init(), as mentioned above. > > And in (4) above the patch you applied that solved the problem was > "Applying: usb: ci_udc: fix interaction with CONFIG_USB_ETH_CDC"? > >>>> 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. For all tests I only run tftp rootfs.ubifs. The mtd patches from Heiko Schocher make some changes to the gadget driver. Maybe that's the cause, that it fails together. >> "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.