From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?J=F6rg_Krause?= Date: Sat, 28 Jun 2014 01:16:44 +0200 Subject: [U-Boot] [PATCH] usb: ci_udc: fix interaction with CONFIG_USB_ETH_CDC In-Reply-To: <53ADE847.8080104@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> Message-ID: <53ADFB5C.1040108@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/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.