public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: "Jörg Krause" <jkrause@posteo.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/2] usb: ci_udc: allow multiple buffer allocs per ep
Date: Thu, 12 Jun 2014 10:36:55 +0200	[thread overview]
Message-ID: <539966A7.7050503@posteo.de> (raw)
In-Reply-To: <53975DBF.70506@wwwdotorg.org>


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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

  reply	other threads:[~2014-06-12  8:36 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-05 23:48 [U-Boot] [PATCH 1/2] usb: ci_udc: allow multiple buffer allocs per ep Stephen Warren
2014-05-05 23:48 ` [U-Boot] [PATCH 2/2] usb: ums: remove ci_udc special case Stephen Warren
2014-05-07 21:31   ` Marek Vasut
2014-05-07 21:31 ` [U-Boot] [PATCH 1/2] usb: ci_udc: allow multiple buffer allocs per ep Marek Vasut
2014-06-02 22:57 ` Jörg Krause
2014-06-02 23:02   ` Jörg Krause
2014-06-10 19:34     ` Stephen Warren
2014-06-12  8:36       ` Jörg Krause [this message]
2014-06-12 12:59         ` Marek Vasut
2014-06-12 15:55         ` Stephen Warren
2014-06-12 17:30           ` Marek Vasut
2014-06-12 17:42             ` Stephen Warren
2014-06-16  1:00               ` Marek Vasut

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=539966A7.7050503@posteo.de \
    --to=jkrause@posteo.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox