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 unregisterCalling 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:
- 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.
- 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.
Now, you see tftp timeouts.
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
- 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.