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