From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mark Rutland <mark.rutland@arm.com>
Date: Fri, 6 Jun 2014 18:32:43 +0100
Subject: [U-Boot] [Patch v4 2/5] ARMv8: Adjust MMU setup
In-Reply-To: <5391D639.4080700@freescale.com>
References: <20140602113450.GD13573@leverpostej>
	<538CA0F5.2060103@freescale.com> <20140602180100.GA887@leverpostej>
	<538F48F2.3080408@freescale.com>
	<20140605100926.GA6430@leverpostej>
	<539087A5.4090803@freescale.com>
	<20140605174156.GG31564@leverpostej>
	<5390B82F.5040601@freescale.com>
	<20140606123312.GB18918@leverpostej>
	<5391D639.4080700@freescale.com>
Message-ID: <20140606173243.GC18918@leverpostej>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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.

Cheers,
Mark.