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.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
