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
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
