[PATCH 2/2] arm: invalidate TLBs when enabling mmu

[Eric Miao]

On Thu, Apr 15, 2010 at 8:24 PM, Eric Miao <eric.y.miao at gmail.com> wrote:
> On Thu, Apr 15, 2010 at 2:27 AM, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
>> On Tue, Mar 09, 2010 at 04:07:03PM +0200, Saeed Bishara wrote:
>>> Signed-off-by: Saeed Bishara <saeed at marvell.com>
>>> ---
>>>  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 ??
>