From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30923 invoked by alias); 5 Mar 2009 10:29:55 -0000 Received: (qmail 30914 invoked by uid 22791); 5 Mar 2009 10:29:53 -0000 X-SWARE-Spam-Status: No, hits=-2.9 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; Thu, 05 Mar 2009 10:29:45 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LfApf-0004xe-PV for ecos-patches@sources.redhat.com; Thu, 05 Mar 2009 10:29:39 +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 ; Thu, 05 Mar 2009 10:29:39 +0000 Received: from tarmo.kuuse by pro1.proekspert.ee with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Mar 2009 10:29:39 +0000 To: ecos-patches@sources.redhat.com From: Tarmo Kuuse Subject: Re: Fix potential stall with Coldfire Ethernet Date: Thu, 05 Mar 2009 10:29:00 -0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) In-Reply-To: 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/msg00014.txt.bz2 Bart Veer wrote: > This is not the right fix, and the problem is nothing to do with the > toolchain. > > FreeScale have redefined the nop instruction for ColdFires to act as a > barrier instruction. When the cpu executes nop it stalls the > instruction pipeline until all previous instructions have completed. > Also, if the processor has some kind of write buffer between the cache > and external memory then nop will stall until the write buffer has > been emptied. Most of the time you do not need to worry about pipeline > effects like this, but DMA engines and cache interactions nearly > always need very special care. > > The operation immediately before starting the transmit is a > HAL_DCACHE_STORE(). Without the nop that macro may not have finished > executing, so the cache store is still happening at the point that the > ethernet engine fetches the buffer descriptors. Hence the ethernet > engine may see bogus buffer descriptors, and confusion results. > > The correct solution is to incorporate the nop into your processor's > HAL_DCACHE_STORE() macro, thus making the macro do precisely what it > is supposed to do. That will fix any other uses of HAL_DCACHE_STORE(), > not just the ethernet driver. It also avoids adding an unnecessary nop > instruction on processors which do not need it, e.g. the mcf5272 which > does not have a data cache at all. You are 100% correct about cache/DMA interactions. The MCF5208 Device Errdata document admits that the micro's cache implementation is buggy and each cache clear operation must be followed by NOP. Also, all cache synchronisation essentially boils down to cache clear because there are no advanced operations. I was about to reply that we know about this and have a NOP where needed but upon looking closer it turns out HAL_DCACHE_STORE() is not implemented at all. Ahh - the pride, thrill and exitement of finding totally stupid errors that have consumed hours and days of your life. It's not all that simple, though. Stalling occurs also when cache is disabled. I'll do some more reserarch on this issue next week. -- Kind regards, Tarmo Kuuse