On 06/10/2014 09:34 PM, Stephen Warren wrote:
On 06/02/2014 05:02 PM, Jörg Krause wrote:
Sorry, my previous post was not shown correctly. The raw text was missing. I
removed the annotation.
Since this commit my Ethernet Gadget on a custom Freescale i.MX28 board is
broken. Using tftp to download files I get in almost all cases a timeout:
Sorry for the slow response; for some reason I didn't get a copy of the
message so I didn't notice it.
Could you tell me which include/config/xxx.h file you're using? I guess
if it's a custom board, perhaps that file isn't upstream. If so, I'm
particularly interested in whether you have CONFIG_USB_GADGET or
CONFIG_USB_ETHER enabled.
You're right, it's not upstream. This is a part of my config:
# define CONFIG_CI_UDC /* ChipIdea CI13xxx UDC */
# define CONFIG_USB_REG_BASE 0x80080000
# define CONFIG_USBD_HS /* High speed support for usb device and
usbtty. */
# define CONFIG_USB_GADGET_DUALSPEED
# define CONFIG_USB_ETHER
# define CONFIG_USB_ETH_CDC
I wonder if applying the following series rather than reverting this
commits solves the issue?
[U-Boot,1/4] usb: ci_udc: detect queued requests on ep0
http://patchwork.ozlabs.org/patch/353926/
[U-Boot,2/4] usb: ci_udc: use a single descriptor for ep0
http://patchwork.ozlabs.org/patch/353932/
[U-Boot,3/4] usb: ci_udc: pre-allocate ep0 req
http://patchwork.ozlabs.org/patch/353931/
[U-Boot,4/4] usb: ci_udc: complete ep0 direction handling
http://patchwork.ozlabs.org/patch/353941/
Applied, but the error still exists.
The only other thing I can think of is that there's some issue with the
bounce buffer alignment or size being wrong somehow. Perhaps try
increasing those?
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.
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.
Or, perhaps req->actual ends up being wrong, so ci_debounce() isn't
cache-invalidating or copying enough data? Perhaps try rounding up
req->len instead of req->actual when performing the cache invalidate?
I tried this, but with no success.
I'm slightly confused by this log. Do you have 2 boards running U-Boot,
one running the USB controller in device mode, and this is the log from
some other board that's talking to that first board?
I have one board connect to a PC. The log shows two different errors
happening on the board. The first log shows a tftp command on the board
stopping with a timeout after receiving some packets. The second log
shows a tftp command on the same board throwing an error before
receiving any packet.
_______________________________________________
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
