On 06/27/2014 03:52 PM, Jörg Krause wrote: > I have tested a little bit more. > > It does NOT help waiting some seconds before running tftp again. > Sometimes it just works running tfpd immediately after a previous tfpd. > Sometimes waiting even a minute ends up in the described error. > > Odd, very odd, sorry :-)
OK, that makes a little more sense. Intermittent issues are fine, but intermittent issues affected by time delays are odd! Does the *first* invocation of "tftp" after the board is powered on always work perfectly? > On 06/27/2014 11: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, but calling it a >> second time ends always in a crash. I have to reset the device. >> >> Next patch: >> >> Applying: usb: ci_udc: terminate ep0 INs with a zlp when required >> >> Did not help. >> >> Next patch: >> >> Applying: usb: ci_udc: fix interaction with CONFIG_USB_ETH_CDC >> >> This helps! U-Boot does not crash anymore. 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] >> >> Best regards >> Jörg Krause >> >> On 06/25/2014 06:06 PM, Stephen Warren wrote: >>> On 06/25/2014 07:51 AM, Marek Vasut wrote: >>>> On Monday, June 23, 2014 at 08:02:48 PM, Stephen Warren wrote: >>>> >>>> +CC Jorg, rest of email is intact. Jorg, does this patch fix your >>>> issue? >>> Jorg's issue was timeouts during transfers, whereas this patch addresses >>> cleanup issues once the device isn't being used any more. I can't >>> imagine how this patch could influence the issue Jorg is seeing. >>> >>>>> From: Stephen Warren <swar...@nvidia.com> >>>>> >>>>> ci_udc.c's usb_gadget_unregister_driver() doesn't call >>>>> driver->unbind() >>>>> unlike other USB gadget drivers. Fix it to do this. >>>>> >>>>> Without this, when ether.c's CDC Ethernet device is torn down, >>>>> eth_unbind() is never called, so dev->gadget is never set to NULL. >>>>> For some reason, usb_eth_halt() is called both at the end of the first >>>>> use of the Ethernet device, and prior to any subsequent use. Since >>>>> dev->gadget is never cleared, all calls to usb_eth_halt() attempt to >>>>> stop, disconnect, and clean up the device, resulting in double >>>>> cleanup, >>>>> which hangs U-Boot on my Tegra device at least. >>>>> >>>>> ci_udc allocates its own singleton EP0 request object, and cleans >>>>> it up >>>>> during usb_gadget_unregister_driver(). This appears necessary when >>>>> using >>>>> the USB gadget framework in U-Boot, since that does not allocate/free >>>>> the EP0 request. However, the CDC Ethernet driver *does* allocate and >>>>> free its own EP0 requests. Consequently, we must protect >>>>> ci_ep_free_request() against double-freeing the request. >> >> >> >> >> _______________________________________________ >> U-Boot mailing list >> U-Boot@lists.denx.de >> http://lists.denx.de/mailman/listinfo/u-boot > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot