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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox