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

[Mark Rutland]

[...]

> >>> 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.