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