From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Jander Date: Wed, 20 Jul 2011 13:31:00 +0200 Subject: [U-Boot] i.MX51: FEC: Cache coherency problem? In-Reply-To: <4E26AE16.4050000@ti.com> References: <20110718171836.67bfe605@archvile> <4E245C5C.4030303@ti.com> <4E256588.4010301@arcor.de> <20110719131744.403a81e6@archvile> <20110719112026.C303D17E88C9@gemini.denx.de> <20110719141048.72d67cb3@archvile> <20110720082902.0d544f00@archvile> <4E269827.7040804@aribaud.net> <20110720112113.575c96fa@archvile> <4E26AE16.4050000@ti.com> Message-ID: <20110720133100.0bebb959@archvile> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Aneesh, On Wed, 20 Jul 2011 15:59:42 +0530 Aneesh V wrote: > On Wednesday 20 July 2011 02:51 PM, David Jander wrote: > > On Wed, 20 Jul 2011 10:56:07 +0200 > > [snip ..] > > >>> Any ideas? > >> > >> Yes, one: I had issues with the Marvell Ethernet adapter, which has DMA > >> as well, not because of cache (it was not active at the time) but > >> because of instruction reordering done by the compiler when optimizing, > >> which resulted in out-of-order accesses to the descritpors and DMA > >> registered, so that the DMA start was written before the descriptors > >> were set up. The (proper and clean) solution was to introduce memory > >> barriers at strategic points of the driver to ensure that specific DMA > >> starts were done only after all writes to the descriptors (and possibly > >> buffers). > > > > Hmmm. I know that issue, but AFAICS, the driver already uses readX() and > > writeX() macros when accessing register and DMA memory. Those macros have > > compiler barriers included.... and armv7 is still in-order execution ;-) > > 1. armv7 is not necessarily in-order. Cortex-A8 is in-order while > Cortex-A9 is out-of-order. > 2. I am not sure if in-order execution guarantees memory ordering. My > understanding is that it doesn't. > 3. In u-boot's implementation of MMU for ARM, the register > space(everything other than SDRAM) is 'strongly-ordered' memory. > Strongly ordered accesses will be correctly ordered w.r.to all other > accesses in program order. Wow, I hadn't noticed dcache_enable() also enables the MMU. Cool. One step closer to splitting the mapping between a cached and uncached, strongly-ordered region of RAM. > 4. Compiler barriers prevent the compiler from doing certain > optimizations, but doesn't help in these situations. Thanks for this excellent summary! > In short, I think you don't need to worry about ordering, but not > because of compiler barriers or armv7 being in-order. Well, I do need to worry about the buffer-descriptors and buffers then, since they are in SDRAM, right? Best regards, -- David Jander Protonic Holland.