[U-Boot] [RFC PATCH 0/2] Fix armv8 cache flushing

[U-Boot] [RFC PATCH 0/2] Fix armv8 cache flushing

[York Sun]

I have been puzzled by the need to flush external L3 cache for Freescale
Layerscape series SoCs. Flushing L3 requires EL3. It is the case now, but
this may change in the future. Implementing a SMC call to perform this
task is possible but only if necessary. Recent investigation shows we can
flush by virtual address most of the time. The only exception is when
dcache_disable() is called. I think this can be addressed by flushing
the stack U-Boot is using and skip flushing L3 totally.

Once this is proved to work, we can drop flushing L3 all together.

During this investigation, I found the procedure of turning off d-cache
seems wrong. The data is lost if d-cache is off first. I am not sure
if this only happens to Freescale Layerscape SoCs. Wondering why no
one else reports any issue, expecially those SoCs without L3 cache.


York Sun (2):
  armv8: Fix dcache disable function
  armv8: Fix flush_dcache_all function

 arch/arm/cpu/armv8/cache_v8.c | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

-- 
2.7.4

[U-Boot] [RFC PATCH 1/2] armv8: Fix dcache disable function

[York Sun]

Current code turns off d-cache first, then flush all levels of cache.
This results data loss. As soon as d-cache is off, the dirty cache
is discarded according to the test on LS2080A. This issue was not
seen as long as external L3 cache was flushed to push the data to
main memory. However, external L3 cache is not guaranteed to have
the data. To fix this, flush the d-cache by way/set first to make
sure cache is clean before turning it off.

Signed-off-by: York Sun <york.sun@nxp.com>
CC: David Feng <fenghua@phytium.com.cn>
---

 arch/arm/cpu/armv8/cache_v8.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index cd3f6c1..92d6277 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -478,9 +478,9 @@ void dcache_disable(void)
 	if (!(sctlr & CR_C))
 		return;
 
+	flush_dcache_all();
 	set_sctlr(sctlr & ~(CR_C|CR_M));
 
-	flush_dcache_all();
 	__asm_invalidate_tlb_all();
 }
 
-- 
2.7.4

[U-Boot] [RFC PATCH 2/2] armv8: Fix flush_dcache_all function

[York Sun]

Previously it was believed L3 cache has to be flushed in order to guarantee
data integrity in main memory. However, flushing L3 cache may require EL3,
depending on SoC implementation. Flushing with virtual address can also
put data into main memory. The trick is to find the correct address range.
For U-Boot to function correctly, the stack needs to be flushed, up to the
top of ram used by U-Boot.

Signed-off-by: York Sun <york.sun@nxp.com>

	Thierry Reding <treding@nvidia.com>,
	Radha Mohan Chintakuntla <rchintakuntla@cavium.com>,
	Alison Wang <b18965@freescale.com>,
	Albert Aribaud <albert.u.boot@aribaud.net>,
	Sergey Temerkhanov <s.temerkhanov@gmail.com>,
	Stephen Warren <swarren@nvidia.com>

---
Stephen Warren, your recently added flushing L3 cache for tegra (8e5d804).
Can you check if your board still works with this proposed change?

 arch/arm/cpu/armv8/cache_v8.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index 92d6277..f5494f8 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -430,14 +430,13 @@ void invalidate_dcache_all(void)
  */
 inline void flush_dcache_all(void)
 {
-	int ret;
+	ulong sp;
 
+	asm("mov %0, sp" : "=r"(sp) : );
+	/* Flush stack to the top of ram */
+	__asm_flush_dcache_range(sp, gd->ram_top);
+	/* Flush cache by way/set */
 	__asm_flush_dcache_all();
-	ret = __asm_flush_l3_cache();
-	if (ret)
-		debug("flushing dcache returns 0x%x\n", ret);
-	else
-		debug("flushing dcache successfully.\n");
 }
 
 /*
-- 
2.7.4

[U-Boot] [RFC PATCH 2/2] armv8: Fix flush_dcache_all function

[york sun]

On 10/14/2016 01:01 PM, York Sun wrote:
> Previously it was believed L3 cache has to be flushed in order to guarantee
> data integrity in main memory. However, flushing L3 cache may require EL3,
> depending on SoC implementation. Flushing with virtual address can also
> put data into main memory. The trick is to find the correct address range.
> For U-Boot to function correctly, the stack needs to be flushed, up to the
> top of ram used by U-Boot.
>
> Signed-off-by: York Sun <york.sun@nxp.com>
>

Pardon me for this mess up. I thought I put the following addresses in 
Series-cc. But evidentially I did it wrong.

York


> 	Thierry Reding <treding@nvidia.com>,
> 	Radha Mohan Chintakuntla <rchintakuntla@cavium.com>,
> 	Alison Wang <b18965@freescale.com>,
> 	Albert Aribaud <albert.u.boot@aribaud.net>,
> 	Sergey Temerkhanov <s.temerkhanov@gmail.com>,
> 	Stephen Warren <swarren@nvidia.com>