From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Sat, 23 Jul 2011 15:04:21 +0200 Subject: [U-Boot] i.MX51: FEC: Cache coherency problem? In-Reply-To: <20110721084803.6d7b1278@archvile> References: <20110718171836.67bfe605@archvile> <4E246569.9020404@denx.de> <20110719094406.686e2a45@archvile> <4E253E78.4050801@aribaud.net> <20110719103702.087d4254@archvile> <4E2543B6.1060505@ti.com> <4E2548DE.6060705@aribaud.net> <4E259670.8030706@comcast.net> <4E25E4EC.70904@comcast.net> <4E26D1C9.50200@aribaud.net> <4E26DF9D.5070709@comcast.net> <4E26E7AA.9070001@aribaud.net> <4E26F5EC.3070708@comcast.net> <20110721084803.6d7b1278@archvile> Message-ID: <4E2AC6D5.1010709@aribaud.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Le 21/07/2011 08:48, David Jander a ?crit : >> However, it is still correct that copying from an non-cached area is >> slower than from cached areas, because of burst reads vs. individual >> reads. However, I doubt that the u-boot user can tell the difference, as >> the network latency will far exceed the difference in copy time. That's assuming cache is only for networking. There can be DMA engines in a lot of other peripherals which do not have the same latency as network (and then, even for networking, TFTP can be done from a very nearby server, possibly even on the same Ethernet segment). >> The >> question is, which is easier to do, and that is probably a matter of >> opinion. However, it is safe to say that so far a cached solution has >> eluded us. That may be changing, but it would still be nice to know how >> to allocate a section of un-cached RAM in the ARM processor, in so far >> as the question has a single answer! That would allow easy portability >> of drivers that do not know about caches, of which there seems to be many. That is one approach, which I think prevents cache from being used beyond caching pure CPU-used DRAM. > I agree. Unfortunately, my time is up for now, and I can't go on with trying > to fix this driver. Maybe I'll pick up after my vacation. > As for now I settled for the ugly solution of keeping dcache disabled while > ethernet is being used :-( Make sure you flush before disabling. :) > IMHO, doing cache maintenance all over the driver is not an easy or nice > solution. Implementing a non-cached memory pool in the MMU and a corresponding > dma_malloc() sounds like much more universally applicable to any driver. I think cache maintenance is feasible if one makes sure the cached areas used by the driver are properly aligned, which simplifies things a lot: you don't have to care for flush-invalidate or just-in-time invalidate, you just have to flush before sending and invalidate before reading. > Best regards, Amicalement, -- Albert.