From mboxrd@z Thu Jan 1 00:00:00 1970 From: eric.y.miao@gmail.com (Eric Miao) Date: Thu, 15 Apr 2010 20:24:48 +0800 Subject: [PATCH 2/2] arm: invalidate TLBs when enabling mmu In-Reply-To: References: <1268143623-22361-1-git-send-email-saeed@marvell.com> <1268143623-22361-2-git-send-email-saeed@marvell.com> <1268143623-22361-3-git-send-email-saeed@marvell.com> <20100414182726.GB13275@n2100.arm.linux.org.uk> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, Apr 15, 2010 at 8:24 PM, Eric Miao wrote: > On Thu, Apr 15, 2010 at 2:27 AM, Russell King - ARM Linux > wrote: >> On Tue, Mar 09, 2010 at 04:07:03PM +0200, Saeed Bishara wrote: >>> Signed-off-by: Saeed Bishara >>> --- >>> ?arch/arm/boot/compressed/head.S | ? ?1 + >>> ?1 files changed, 1 insertions(+), 0 deletions(-) >>> >>> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S >>> index 4fddc50..a1ab79f 100644 >>> --- a/arch/arm/boot/compressed/head.S >>> +++ b/arch/arm/boot/compressed/head.S >>> @@ -489,6 +489,7 @@ __armv7_mmu_cache_on: >>> ? ? ? ? ? ? ? mcr ? ? p15, 0, r0, c1, c0, 0 ? @ load control register >>> ? ? ? ? ? ? ? mrc ? ? p15, 0, r0, c1, c0, 0 ? @ and read it back >>> ? ? ? ? ? ? ? mov ? ? r0, #0 >>> + ? ? ? ? ? ? mcr ? ? p15, 0, r0, c8, c7, 0 ? @ invalidate I,D TLBs >>> ? ? ? ? ? ? ? mcr ? ? p15, 0, r0, c7, c5, 4 ? @ ISB >>> ? ? ? ? ? ? ? mov ? ? pc, r12 >>> >> >> This can't be unconditional - if we're running on PMSA (iow, uclinux) >> we should not execute this instruction. ?Notice that the previous one >> is conditional. >> > > This is true and needs to be fixed. > >> The other question is whether this should be done before or after the >> ISB - if it's done before, my understanding is that it could occur >> unordered with respect to the MMU being enabled - if that's indeed >> the problem. >> > > Another noticeable difference is the slow decompressing happens so far on > kexec only, a normal boot without this additional "invalidate" does not > exhibit such slowness. This leads to me to suspect that the MMU state might > not be same between a normal bootup and a kexec soft reboot. > BTW: this happens on imx51 as well, so I suspect it's not Marvell dove specific. > I may overlooked, but it looks to me that after a 1:1 mapping of ther user > space area (from 0x0000_0000 to TASK_SIZE, which I guess will cause some > other issue if the kexec kernel start entry starts beyond TASK_SIZE?), the > MMU is NOT actually turned off through the reset. This might cause weird > behavior with the original sequence of __armv7_mmu_cache_on ?? >