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

[york sun]

On 10/14/2016 01:30 PM, Stephen Warren wrote:
> 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.

I agree this is not same as flush_all. I had internal discussion with 
our people. I acknowledge we have other memory potentially needs a 
flush. There are many possibility that a user put something in the 
memory and expect the data persists when OS comes up. My target is to 
eliminate flushing external cache.

Consider how we boot Linux. The kernel image is flushed by VA, then 
d-cache off, MMU off. When kernel comes up, it enables d-cache. As far 
as the data is not accessed for that, we don't have to flush it in 
U-Boot. I understand this is only not the whole picture. Sending out 
this RFC patch meant to start this discussion.

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

Let's see what the patches will be.

York