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....@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();

U-Boot mailing list

Reply via email to