From mboxrd@z Thu Jan 1 00:00:00 1970 From: York Sun Date: Fri, 6 Jun 2014 10:37:12 -0700 Subject: [U-Boot] [Patch v4 2/5] ARMv8: Adjust MMU setup In-Reply-To: <20140606173243.GC18918@leverpostej> 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> <20140606173243.GC18918@leverpostej> Message-ID: <5391FC48.2060002@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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