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

Stephen Warren swarren at wwwdotorg.org
Fri Oct 14 22:29:57 CEST 2016


On 10/14/2016 02:17 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 at nxp.com>
>
> ---
> Stephen Warren, your recently added flushing L3 cache for tegra (8e5d804).
> Can you check if your board still works with this proposed change?

I'm not convinced this is safe. If we do flush by VA rather than any 
other mechanism, we should at least iterate over the entire page table 
and find all regions marked cacheable, rather than assuming the delta 
between stack pointer and ram_top is the only relevant region. That 
said, I'm not sure even doing that will completely guarantee that the 
cache is fully clean; I think by-set/-way is the only way. I think it's 
better to leave this part as-is.

BTW, in the very near future (I've been meaning to do this for the last 
couple of days), I expect to send a patch which adds hooks for 
SoC-/CPU-/system-specific hooks to all 3 of invalidate_dcache_all(), 
flush_dcache_all(), invalidate_icache_all(). That patch will rename 
__asm_flush_l3_cache() for consistency with the other hooks, and remove 
"l3" from the function name because the function isn't only necessary 
for L3 flushing, but can also be required by other aspects of 
multi-cluster systems. As such, the following definitely won't work for 
Tegra:

> -	ret = __asm_flush_l3_cache();



More information about the U-Boot mailing list