From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?J=F6rg?= Krause Date: Fri, 06 Feb 2015 00:19:53 +0100 Subject: [U-Boot] netconsole: USB Ethernet connection dropping with ping or tftpboot In-Reply-To: <54D3ED62.7030208@wwwdotorg.org> References: <1422999858.2688.14.camel@posteo.de> <1423135265.26058.11.camel@posteo.de> <54D38D2E.50102@wwwdotorg.org> <1423174204.1232.25.camel@posteo.de> <54D3ED62.7030208@wwwdotorg.org> Message-ID: <1423178393.1232.48.camel@posteo.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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.