On Thursday, June 12, 2014 at 10:36:55 AM, Jörg Krause wrote: > 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.
I sense buffer alignment issue. MXS aligns some buffer to 32b , but the CI block expects the buffer to be aligned to 64b or somesuch weird stuff. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
