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