On 06/18/2014 07:09 AM, fenghua@phytium.com.cn wrote:
hi York,
On 06/10/2014 02:15 AM, Mark Rutland wrote:
Hi,
Apologies for the delay in replying.
On Fri, Jun 06, 2014 at 11:14:23PM +0100, York Sun wrote:
On 06/06/2014 01:17 PM, York Sun wrote:
On 06/06/2014 10:32 AM, Mark Rutland wrote:
>> How is TCR_EL2.SH0 (or TCR_EL1.SH*) configured? >> >> You'll only need to flush the cache if they're configured non shareable. > > It is configured as non shareable.
Is there any reason not to configure them as inner shareable? That way the MMU will look in the D-cache, and you won't have to spend time flushing them.
Mark,
I appreciate the reminder. I tried on our emulator. With inner share set for TCR SH0 bits, u-boot works with the flushing, but doesn't work without flushing. It went to exception.
Can you share more information about the inner share? I need to follow up with our designer to confirm.
A second thought, do I need to set the first MMU table so DDR is inner shareable?
I assume you mean configuring MAIR_ELx such that the mapping covering DDR is cacheable for the inner shareable domain? If so, yes.
Mark,
I tried both inner share and outer. It doesn't work without flushing the cache. I will keep this part of code until I learn otherwise.
York
The shareability attribute is different with cacheablilty attribute, it means whether the memory region would be accessed by other processors. If a memory region is configured as non sharable the access will not be snooped but still can be cached. It is the situation that current u-boot-armv8 used due to only master processor is active. If secondary processors also access the same memory region it should be configured as inner-sharable or outer-sharable otherwise the cache coherence between processors will not be maintained. The above is what I know. Wish this could help.
David,
Thanks for chime in. It is not clear to me if I can put a new MMU table in d-cache and have MMU fetch from the d-cache. I tried several ways but it doesn't work.
York