On 02/10/2017 09:32 AM, Mark Rutland wrote: > Hi, > > On Fri, Feb 03, 2017 at 02:22:48PM -0800, York Sun wrote: >> We don't have to completely turn off MMU and cache to switch to >> another MMU table as far as the data is coherent before and after >> the switching. This patch relaxes the procedure. >> >> Signed-off-by: York Sun <york....@nxp.com> >> CC: Alexander Graf <ag...@suse.de> >> --- >> I found this issue while trying to change MMU table for a SPL boot. >> The RAM version U-Boot was copied to memory when d-cache was enabled. >> SPL code never flushed the cache (I will send another patch to fix that). >> With existing code, U-Boot stops running as soon as the MMU is diabled. >> With below propsed change, U-Boot continues to run. I have been in >> contact with ARM support and got very useful information. However, this >> switching TTBR method is "behavious that should work" but not well >> verified by ARM. During my debugging, I found other minor issue which >> convinced me this code wasn't exercised. I don't intend to use this >> method in long term, but figure it may help others by fixing it. > > I believe the approach taken in this patch is unsafe. > > Even if the resulting translations are identical across the old and new > tables, it is not valid to transition from one set of tables to another > unless: > > (a) the mappings in both cases are non-global, and the ASID is switched, > or: > > (b) A Break-Before-Make strategy is followed to ensure that the TLBs > contain no stale entries for the old tables. > > Even if the resulting translations are identical, you can be subject to > TLB conflict aborts and/or behaviours resulting from the amalgamation of > TLB entries. In Linux, we had to write special code [1] to switch tables > by using some trampoline code in the other TTBR. > > I believe that in this case, you only need to clean the MMU-off code to > the PoC (using DC DVAC), before temporarily turning the MMU off. > > Thanks, > Mark. > > [1] > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infradead.org%2Fpipermail%2Flinux-arm-kernel%2F2016-January%2F401434.html&data=01%7C01%7Cyork.sun%40nxp.com%7C12db759ec0a846ebf27308d451dad8ec%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=0gKNRAMUSKKuBAGYAmQOLtW8EOk1e6FOk9VZn50hYg8%3D&reserved=0 >
Thanks, Mark. Let's keep the current code. I will explore other ways to fix my issue. York _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot