From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20293 invoked by alias); 3 Mar 2009 11:45:18 -0000 Received: (qmail 20280 invoked by uid 22791); 3 Mar 2009 11:45:15 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 Mar 2009 11:45:05 +0000 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1LeT3W-0007RC-Mz for ecos-patches@sources.redhat.com; Tue, 03 Mar 2009 11:45:02 +0000 Received: from pro1.proekspert.ee ([212.47.207.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Mar 2009 11:45:02 +0000 Received: from tarmo.kuuse by pro1.proekspert.ee with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Mar 2009 11:45:02 +0000 To: ecos-patches@sources.redhat.com From: Tarmo Kuuse Subject: Fix potential stall with Coldfire Ethernet Date: Tue, 03 Mar 2009 11:45:00 -0000 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------000701080607050401060208" User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) X-IsSubscribed: yes Mailing-List: contact ecos-patches-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-patches-owner@ecos.sourceware.org X-SW-Source: 2009-03/txt/msg00008.txt.bz2 This is a multi-part message in MIME format. --------------000701080607050401060208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 813 Hi, While struggling with eCos on Coldfire 5208 I stumbled on a nasty bug. The fast ethernet controller often stalls if transmission is flagged immediately after copying data to buffer. I have no idea why this happens. Maybe my compiler (from CodeSourcery, not eCos) does something to confuse the FEC. Maybe the 5208 hardware is buggy. Hopefully the currently supported devices (5282 and 532x) are safe when built with eCos toolchain (I cannot test it). The patch could save a few neurons for someone. Patch adds a NOP between filling the buffer and flagging the transmitter. There is also a small change on how TX buffer descriptors are allocated - a loop is used instead of two individual statements. It was quite annoying having to debug after changing the BD count. -- Kind regards, Tarmo Kuuse --------------000701080607050401060208 Content-Type: text/x-patch; name="if_mcf5272_fix_stall.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="if_mcf5272_fix_stall.patch" Content-length: 3076 Index: devs/eth/m68k/mcf5272/current/ChangeLog =================================================================== RCS file: /cvs/ecos/ecos/packages/devs/eth/m68k/mcf5272/current/ChangeLog,v retrieving revision 1.3 diff -u -5 -p -r1.3 ChangeLog --- devs/eth/m68k/mcf5272/current/ChangeLog 29 Jan 2009 17:48:09 -0000 1.3 +++ devs/eth/m68k/mcf5272/current/ChangeLog 3 Mar 2009 10:05:48 -0000 @@ -1,5 +1,10 @@ +2009-03-03 Tarmo Kuuse + + * src/if_mcf5272.c: Fix potential stall on transmission; TX buffer + descriptors are initialized in loop + 2008-11-17 Bart Veer * cdl/mcf5272.cdl, doc/mcf5272_eth.sgml, src/if_mcf5272.c: minor clean-ups. Index: devs/eth/m68k/mcf5272/current/src/if_mcf5272.c =================================================================== RCS file: /cvs/ecos/ecos/packages/devs/eth/m68k/mcf5272/current/src/if_mcf5272.c,v retrieving revision 1.2 diff -u -5 -p -r1.2 if_mcf5272.c --- devs/eth/m68k/mcf5272/current/src/if_mcf5272.c 29 Jan 2009 17:48:09 -0000 1.2 +++ devs/eth/m68k/mcf5272/current/src/if_mcf5272.c 3 Mar 2009 10:05:49 -0000 @@ -288,10 +288,16 @@ mcfxxxx_eth_ramfn(void) // This #elif should probably become a #else #elif defined(CYGPKG_HAL_M68K_MCF5282) || defined(CYGPKG_HAL_M68K_MCF532x) # define TX_NEEDS_ALIGNMENT 1 # define TX_BUFFER_SIZE 1520 +// It's currently safe to use only 2 TX BD-s since +// one BD is declared free at any given time. +// Freescale however recommends having at least 3 TX +// buffers (see MCF5208 Reference Manual, Rev. 2 or newer, +// section 19.5.7.1 "Duplicate Frame Transmission"). +// Note: Don't use an odd number. # define TX_BUFFER_DESCRIPTOR_COUNT 2 #else # error Current processor unsupported @@ -520,12 +526,13 @@ mcfxxxx_eth_init(struct cyg_netdevtab_en // Ditto for the tx buffers, if tx involves copying into an // aligned buffer. Only one entry in the ring buffer will be used // at a time, so the two buffer descriptors can share the same // buffer. #ifdef TX_NEEDS_ALIGNMENT - eth->txbds[0].ethbd_buffer = txbuffer; - eth->txbds[1].ethbd_buffer = txbuffer; + for (i = 0; i < TX_BUFFER_DESCRIPTOR_COUNT; i++) { + eth->txbds[i].ethbd_buffer = txbuffer; + } #endif // rx_next_buffer tracks the next rx buffer descriptor which the // hardware may process. eth->rx_next_buffer = 0; @@ -737,10 +744,15 @@ mcfxxxx_eth_send(struct eth_drv_sc* sc, // for any bits changed by the hardware except on the xxxx which // does not have a data cache at all. #ifdef HAL_DCACHE_STORE HAL_DCACHE_STORE(&(eth->txbds[0]), TX_BUFFER_DESCRIPTOR_COUNT * sizeof(hal_mcfxxxx_eth_buffer_descriptor)); #endif + + // A NOP is needed before flagging the transmitter. + // Otherwise the FEC could stall. + asm volatile ("nop"); + WRITE32(TDAR(eth), HAL_MCFxxxx_ETHx_TDAR_X_DES_ACTIVE); } // The TX interrupt should only trigger when a whole frame has been // transmitted. There is no need to worry about nested tx interrupts, --------------000701080607050401060208--