From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Rutland Date: Mon, 7 Nov 2016 14:11:37 +0000 Subject: [U-Boot] [Resend RFC PATCH 1/2] armv8: Fix dcache disable function In-Reply-To: References: <20161024105911.GE15620@leverpostej> <060025e2-128b-8c11-1804-fab1aa686f85@nxp.com> <04fda8db-ee07-5469-f9e5-29af5062fbe0@wwwdotorg.org> <80005fc9-0dc3-39cc-768c-1ec561981190@wwwdotorg.org> Message-ID: <20161107141136.GH19796@leverpostej> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Fri, Oct 28, 2016 at 09:35:37PM +0000, york sun wrote: > I am struggling on the dcache_disable() which implies all dcache is > flushed. I don't have a reasonable way to flush all if I want to skip > L3. I tried to benchmark flushing by VA to cover my entire 16GB memory. > It took 30+ seconds. On the other side, flushing by set/way and flushing > L3 together took 7 ms. If I only flush U-Boot stack in this function, it > can run really fast, but that defeats the purpose of flush all cache. > > I thought of parsing each set/way to find the address of each cache line > (I don't know how to do that yet), but the tag only contains physical > address not VA. With the MMU off, translation is an idmap (i.e. VA == PA), so if you have physical addresses, you can use those directly. That said, the presence and implementation of any mechanism to read addresses from the cache is IMPLEMENTATION DEFINED, so this will not be portable. > The ARM document shows example code to clean entire data or unified > cache to PoC, very similar to the code we have in U-Boot armv8/cache.S. Do you mean the "Example code for cache maintenance instructions"? In recent versions of the ARM ARM there's a large note explaining why this only works in very restricted scenarios (and cannot be used to affect system caches such as your L3). In the latest ARM ARM ("ARM DDI 0487A.k"), see page D3-1710. > Unless there are other cache maintenance instruction I am not aware of, > I don't see how to flush to PoC by set/way. Architecturally, Set/Way operations are not guaranteed to affect al caches prior to the PoC, and may require other IMPLEMENTATION DEFINED maintenance (e.g. MMIO control of system-level caches). Thanks, Mark.