From: "Jörg Krause" <jkrause@posteo.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] netconsole: USB Ethernet connection dropping with ping or tftpboot
Date: Fri, 06 Feb 2015 00:19:53 +0100 [thread overview]
Message-ID: <1423178393.1232.48.camel@posteo.de> (raw)
In-Reply-To: <54D3ED62.7030208@wwwdotorg.org>
On Do, 2015-02-05 at 15:23 -0700, Stephen Warren wrote:
> On 02/05/2015 03:10 PM, J?rg Krause wrote:
> > On Do, 2015-02-05 at 08:33 -0700, Stephen Warren wrote:
> >> On 02/05/2015 04:21 AM, J?rg Krause wrote:
> ...
> >>> This reminded me about an issue I had some months ago:
> >>> http://lists.denx.de/pipermail/u-boot/2014-July/182885.html
> >>>
> >>> I enabled debug output in arch/arm/cpu/arm926ejs/cache.c and I get
> >>> error:
> >>> => tftp u-boot.sb
> >>> using ci_udc, OUT ep- IN ep- STATUS ep-
> >>> CACHE: Misaligned operation at range [43f7b010, 43f7b070]
> >>>
> >>> I removed the flush_cache() call in cmd_net.c:netboot_common() as
> >>> suggested by Marek in the thread. But the error message is still there.
> >>
> >> Perhaps make flush_cache() a macro that also passes in the file/line
> >> number where it's called from, and print those out along with he
> >> "misaligned operation" error message?
> >>
> >> (or find some other way to perform a stack dump from within that function).
> >
> > I've added in each function in ci_udc a printf statement before a cache
> > function is called, eg:
> >
> > static void ci_flush_qh(int ep_num)
> > {
> > [..]
> > printf("CACHE: flush_dcache_range %s %d
> > \n",__FUNCTION__,__LINE__);
> > flush_dcache_range(start, end);
> > }
> >
> > I've also looked at all calling functions of flush_cache or
> > flush_dcache_range, but I think there is nothing of relevance.
> >
> > This is a snippet of the output:
> >
> ...
> > CACHE: flush_dcache_range ci_bounce 356
> > CACHE: Misaligned operation at range [43f7b010, 43f7b070]
> > timeout sending packets to usb ethernet
> > ping failed; host 10.0.0.1 is not alive
>
> Which git commit did you build, and which board?
Building tag v2015.01 for a custom i.MX28 board which is not upstream.
It's configuration mainly based on mx28evk and m28evk.
>
> I'm curious what values you have for ARCH_DMA_MINALIGN and
> CONFIG_SYS_CACHELINE_SIZE.
I defined CONFIG_SYS_CACHELINE_SIZE 32 in the config. ARCH_DMA_MINALIGN
is also 32.
>
> Are you sure flush_dcache_range() is the code printing the alignment
> error, not e.g. invalidate_dcache_range()?
I've also added a printf statement to all functions in ci_udc which
calls invalidate_dcache_range(), but it is not logged when the alignment
error occurs. e.g.
using ci_udc, OUT ep- IN ep- STATUS ep-
MAC 00:19:b8:00:00:02
HOST MAC 00:19:b8:00:00:01
CACHE: flush_dcache_range ci_flush_qh 166
CACHE: invalidate_dcache_range ci_invalidate_qh 182
CACHE: flush_dcache_range ci_bounce 356
CACHE: flush_dcache_range ci_flush_qtd 199
CACHE: flush_dcache_range ci_flush_qh 166
>
> The reason I ask most of these questions is that line 356 mentioned in
> your debug spew is in function ci_debounce() in the code I have; no
> doubt I have a different git commit than you have checked out, and the
> debug printfs you added changed the line numbers too.
You're right, the debug printfs changed the line number. It's the
flush_dcache_range() call at line 348 in ci_bounce(). I checked this
after removing all printfs.
> About the only thing I can think of is that:
>
> a) You're not using an up-to-date ci_udc.c; IIRC I fixed quite a few
> cache issues when I reworked it a while back.
Yes, we had a troubleshooting about this last summer. I had problems
with timeouts using tftp. Marek and you worked on this issue.
>
> b) In ci_bounce(), the bounce buffer is only allocated if the
> user-buffer is already aligned, and if a large-enough bounce buffer
> wasn't previously allocated. If ci_req->b_buf was uninitialized it could
> be non-zero (thus preventing the expected aligned allocation) yet not
> actually aligned enough.
Maybe, we should work on this?
>
> c) Perhaps ARCH_DMA_MINALIGN or CONFIG_SYS_CACHELINE_SIZE aren't correct
> or are inconsistent.
>
> Ah. I note that check_cache_range() in either arch/arm/cpu/arm1136/cpu.c
> or arch/arm/cpu/arm926ejs/cache.c uses CONFIG_SYS_CACHELINE_SIZE to
> check for alignment, whereas ci_udc.c uses ARCH_DMA_MINALIGN.
> Inconsistency between those two could be at fault.
Both are set to 32, so this should not be the problem.
next prev parent reply other threads:[~2015-02-05 23:19 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-03 21:44 [U-Boot] netconsole: USB Ethernet connection dropping with ping or tftpboot Jörg Krause
2015-02-05 11:21 ` Jörg Krause
2015-02-05 15:33 ` Stephen Warren
2015-02-05 22:10 ` Jörg Krause
2015-02-05 22:23 ` Stephen Warren
2015-02-05 23:19 ` Jörg Krause [this message]
2015-02-06 1:06 ` Jörg Krause
2015-02-06 18:06 ` Stephen Warren
2015-02-08 21:25 ` Jörg Krause
2015-02-09 17:38 ` Stephen Warren
2015-02-11 22:08 ` Jörg Krause
2015-02-05 19:20 ` Joe Hershberger
2015-02-05 20:39 ` Jörg Krause
2015-02-05 20:48 ` Joe Hershberger
2015-02-05 22:28 ` Jörg Krause
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=1423178393.1232.48.camel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.