[U-Boot] [Patch v4 2/5] ARMv8: Adjust MMU setup

[York Sun]

On 06/06/2014 10:32 AM, Mark Rutland wrote:
> On Fri, Jun 06, 2014 at 03:54:49PM +0100, York Sun wrote:
>> On 06/06/2014 05:33 AM, Mark Rutland wrote:
>>> [...]
>>>
>>>>>>> What you need to do to replace the active set of tables (assuming that
>>>>>>> the new mapping has the instruction stream mapped in an identical way)
>>>>>>> is:
>>>>>>>
>>>>>>> - Write the tables.
>>>>>>>
>>>>>>> - DSB to make them visible to the MMU.
>>>>>>>
>>>>>>> - Write to the appropriate TTBR_*.
>>>>>>>
>>>>>>> - ISB to complete the write to the TTBR_*.
>>>>>>>
>>>>>>> - TLBI to invalidate the old mappings the the TLBs.
>>>>>>>
>>>>>>> - DSB to complete the TLBI.
>>>>>>>
>>>>>>> - If you've changed the instruction stream or system state that will
>>>>>>>   affect the instruction stream, ISB to flush the CPU pipeline.
>>>>>>>
>>>>>>>
>>>>>> Here is the flow I have (as of v5 patch)
>>>>>>
>>>>>> Write the tables
>>>>>>
>>>>>> (I removed dsb here in v5, need to add back)
>>>>>>
>>>>>> Write TTBR
>>>>>>
>>>>>> (I missed isb here, need to add)
>>>>>>
>>>>>> Flush dcache (otherwise the table will not be in DDR. Yes, I verified)
>>>>>
>>>>> This looks odd -- why do we need the tables to be in DDR? Why would we
>>>>> flush them here, when the address is partially visible to the MMU?
>>>>
>>>> This sounds odd but it actually makes sense. Let's say we have new tables
>>>> created by u-boot. The new tables are in the address of DDR with D-cache
>>>> enabled. If we don't flush the cache, the moment TLBs are invalidated, MMU will
>>>> fetch the tables from TTBR which points to DDR. Without a valid TLB, MMU cannot
>>>> get the table from D-cache, it has to fetch from the DDR directly. I have
>>>> verified this by checking waveforms of the SoC and exercised code in both ways.
>>>
>>> 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.
> 

You may be right. I need to test it. It will take me a little while. In the
meantime, would you comment on v6 patches please? If flushing is the only
question left, I can address it after testing.

York