Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1480198 > unrolled thread

Improper TTBCR for arm 32bit kernel decompression

Started bySrinivas Ramana <sramana@codeaurora.org>
First post2016-09-09 18:40 +0200
Last post2016-09-13 17:00 +0200
Articles 8 — 4 participants

Back to article view | Back to linux.kernel


Contents

  Improper TTBCR for arm 32bit kernel decompression Srinivas Ramana <sramana@codeaurora.org> - 2016-09-09 18:40 +0200
    Re: Improper TTBCR for arm 32bit kernel decompression Nicolas Pitre <nicolas.pitre@linaro.org> - 2016-09-09 19:40 +0200
      Re: Improper TTBCR for arm 32bit kernel decompression Srinivas Ramana <sramana@codeaurora.org> - 2016-09-10 08:00 +0200
      Re: Improper TTBCR for arm 32bit kernel decompression Srinivas Ramana <sramana@codeaurora.org> - 2016-09-10 10:20 +0200
        [PATCH] ARM: decompressor: reset ttbcr fields to use TTBR0 on ARMv7 Srinivas Ramana <sramana@codeaurora.org> - 2016-09-12 09:00 +0200
          Re: [PATCH] ARM: decompressor: reset ttbcr fields to use TTBR0 on  ARMv7 Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-09-12 12:30 +0200
          Re: [PATCH] ARM: decompressor: reset ttbcr fields to use TTBR0 on  ARMv7 Robin Murphy <robin.murphy@arm.com> - 2016-09-12 20:00 +0200
            Re: [PATCH] ARM: decompressor: reset ttbcr fields to use TTBR0 on  ARMv7 Srinivas Ramana <sramana@codeaurora.org> - 2016-09-13 17:00 +0200

#1480198 — Improper TTBCR for arm 32bit kernel decompression

FromSrinivas Ramana <sramana@codeaurora.org>
Date2016-09-09 18:40 +0200
SubjectImproper TTBCR for arm 32bit kernel decompression
Message-ID<sfx0m-5nv-39@gated-at.bofh.it>
Hello,

While trying to boot arm-32 bit kernel, I came across a problem where 
TTBCR is in improper state. If the bootloader uses the long descriptor 
format and jumps to kernel decompressor code, TTBCR may not be in the 
right state. So, as soon as the MMU is enabled, execution can not 
proceed further.

Before enabling the MMU, it is required to clear the TTBCR.PD0 field to 
use TTBR0 for translation table walks. Also, TTBCR.N should be reset to 
'0' to indicate the correct base address width. The 'commit 
dbece45894d3a ("ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 
cores")' does the reset of TTBCR.N, but doesn't consider all the bits 
for the size of TTBCR.N.

when i tried the below change where i explicitly clear TTBCR.PD0 and use 
correct mask for TTBCR.N, I see proper memory after MMU is enabled and 
decompression succeeds.

Request your comments on the change below. If it looks good, I can 
submit a patch for inclusion.

---------------------8<----------------------------------
diff --git a/arch/arm/boot/compressed/head.S 
b/arch/arm/boot/compressed/head.S
index af11c2f..5769f1f 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -779,7 +779,8 @@ __armv7_mmu_cache_on:
                 orrne   r0, r0, #1              @ MMU enabled
                 movne   r1, #0xfffffffd         @ domain 0 = client
                 bic     r6, r6, #1 << 31        @ 32-bit translation system
-               bic     r6, r6, #3 << 0         @ use only ttbr0
+               bic     r6, r6, #7 << 0         @ width of base address 
field
+               bic     r6, r6, #1 << 4         @ use only ttbr0
                 mcrne   p15, 0, r3, c2, c0, 0   @ load page table pointer
                 mcrne   p15, 0, r1, c3, c0, 0   @ load domain access 
control
                 mcrne   p15, 0, r6, c2, c0, 2   @ load ttb control
---------------------8<----------------------------------

Thanks,
-- Srinivas R

-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, 
Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative 
Project.

[toc] | [next] | [standalone]


#1480220

FromNicolas Pitre <nicolas.pitre@linaro.org>
Date2016-09-09 19:40 +0200
Message-ID<sfxWp-5Vo-5@gated-at.bofh.it>
In reply to#1480198
On Fri, 9 Sep 2016, Srinivas Ramana wrote:

> Hello,
> 
> While trying to boot arm-32 bit kernel, I came across a problem where TTBCR is
> in improper state. If the bootloader uses the long descriptor format and jumps
> to kernel decompressor code, TTBCR may not be in the right state. So, as soon
> as the MMU is enabled, execution can not proceed further.
> 
> Before enabling the MMU, it is required to clear the TTBCR.PD0 field to use
> TTBR0 for translation table walks. Also, TTBCR.N should be reset to '0' to
> indicate the correct base address width. The 'commit dbece45894d3a ("ARM:
> 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores")' does the reset of
> TTBCR.N, but doesn't consider all the bits for the size of TTBCR.N.
> 
> when i tried the below change where i explicitly clear TTBCR.PD0 and use
> correct mask for TTBCR.N, I see proper memory after MMU is enabled and
> decompression succeeds.
> 
> Request your comments on the change below. If it looks good, I can submit a
> patch for inclusion.
> 
> ---------------------8<----------------------------------
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index af11c2f..5769f1f 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -779,7 +779,8 @@ __armv7_mmu_cache_on:
>                 orrne   r0, r0, #1              @ MMU enabled
>                 movne   r1, #0xfffffffd         @ domain 0 = client
>                 bic     r6, r6, #1 << 31        @ 32-bit translation system
> -               bic     r6, r6, #3 << 0         @ use only ttbr0
> +               bic     r6, r6, #7 << 0         @ width of base address field
> +               bic     r6, r6, #1 << 4         @ use only ttbr0

You could combine those instructions like this:

		bic	r6, r6, #(7 << 0) | (1 << 4) @ use only ttbr0


Nicolas

[toc] | [prev] | [next] | [standalone]


#1480507

FromSrinivas Ramana <sramana@codeaurora.org>
Date2016-09-10 08:00 +0200
Message-ID<sfJux-4CL-7@gated-at.bofh.it>
In reply to#1480220
On 09/09/2016 11:06 PM, Nicolas Pitre wrote:
> On Fri, 9 Sep 2016, Srinivas Ramana wrote:
>
>> Hello,
>>
>> While trying to boot arm-32 bit kernel, I came across a problem where TTBCR is
>> in improper state. If the bootloader uses the long descriptor format and jumps
>> to kernel decompressor code, TTBCR may not be in the right state. So, as soon
>> as the MMU is enabled, execution can not proceed further.
>>
>> Before enabling the MMU, it is required to clear the TTBCR.PD0 field to use
>> TTBR0 for translation table walks. Also, TTBCR.N should be reset to '0' to
>> indicate the correct base address width. The 'commit dbece45894d3a ("ARM:
>> 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores")' does the reset of
>> TTBCR.N, but doesn't consider all the bits for the size of TTBCR.N.
>>
>> when i tried the below change where i explicitly clear TTBCR.PD0 and use
>> correct mask for TTBCR.N, I see proper memory after MMU is enabled and
>> decompression succeeds.
>>
>> Request your comments on the change below. If it looks good, I can submit a
>> patch for inclusion.
>>
>> ---------------------8<----------------------------------
>> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
>> index af11c2f..5769f1f 100644
>> --- a/arch/arm/boot/compressed/head.S
>> +++ b/arch/arm/boot/compressed/head.S
>> @@ -779,7 +779,8 @@ __armv7_mmu_cache_on:
>>                  orrne   r0, r0, #1              @ MMU enabled
>>                  movne   r1, #0xfffffffd         @ domain 0 = client
>>                  bic     r6, r6, #1 << 31        @ 32-bit translation system
>> -               bic     r6, r6, #3 << 0         @ use only ttbr0
>> +               bic     r6, r6, #7 << 0         @ width of base address field
>> +               bic     r6, r6, #1 << 4         @ use only ttbr0
>
> You could combine those instructions like this:
>
> 		bic	r6, r6, #(7 << 0) | (1 << 4) @ use only ttbr0
Sure, Thanks for the suggestion. I can incorporate this and submit a 
patch. Can i use your Acked-by?

Thanks,
-- Srinivas R

>
> Nicolas
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, 
Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative 
Project.

[toc] | [prev] | [next] | [standalone]


#1480532

FromSrinivas Ramana <sramana@codeaurora.org>
Date2016-09-10 10:20 +0200
Message-ID<sfLG2-69t-41@gated-at.bofh.it>
In reply to#1480220
On 09/09/2016 11:06 PM, Nicolas Pitre wrote:
> On Fri, 9 Sep 2016, Srinivas Ramana wrote:
>
>> Hello,
>>
>> While trying to boot arm-32 bit kernel, I came across a problem where TTBCR is
>> in improper state. If the bootloader uses the long descriptor format and jumps
>> to kernel decompressor code, TTBCR may not be in the right state. So, as soon
>> as the MMU is enabled, execution can not proceed further.
>>
>> Before enabling the MMU, it is required to clear the TTBCR.PD0 field to use
>> TTBR0 for translation table walks. Also, TTBCR.N should be reset to '0' to
>> indicate the correct base address width. The 'commit dbece45894d3a ("ARM:
>> 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores")' does the reset of
>> TTBCR.N, but doesn't consider all the bits for the size of TTBCR.N.
>>
>> when i tried the below change where i explicitly clear TTBCR.PD0 and use
>> correct mask for TTBCR.N, I see proper memory after MMU is enabled and
>> decompression succeeds.
>>
>> Request your comments on the change below. If it looks good, I can submit a
>> patch for inclusion.
>>
>> ---------------------8<----------------------------------
>> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
>> index af11c2f..5769f1f 100644
>> --- a/arch/arm/boot/compressed/head.S
>> +++ b/arch/arm/boot/compressed/head.S
>> @@ -779,7 +779,8 @@ __armv7_mmu_cache_on:
>>                  orrne   r0, r0, #1              @ MMU enabled
>>                  movne   r1, #0xfffffffd         @ domain 0 = client
>>                  bic     r6, r6, #1 << 31        @ 32-bit translation system
>> -               bic     r6, r6, #3 << 0         @ use only ttbr0
>> +               bic     r6, r6, #7 << 0         @ width of base address field
>> +               bic     r6, r6, #1 << 4         @ use only ttbr0
>
> You could combine those instructions like this:
>
> 		bic	r6, r6, #(7 << 0) | (1 << 4) @ use only ttbr0

Sure, I can do that. Thanks for the suggestion. Will send out a patch 
for review.

Thanks,
-- Srinivas R

-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, 
Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative 
Project.

[toc] | [prev] | [next] | [standalone]


#1480957 — [PATCH] ARM: decompressor: reset ttbcr fields to use TTBR0 on ARMv7

FromSrinivas Ramana <sramana@codeaurora.org>
Date2016-09-12 09:00 +0200
Subject[PATCH] ARM: decompressor: reset ttbcr fields to use TTBR0 on ARMv7
Message-ID<sgtnI-8f3-21@gated-at.bofh.it>
In reply to#1480532
If the bootloader uses the long descriptor format and jumps to
kernel decompressor code, TTBCR may not be in a right state.
Before enabling the MMU, it is required to clear the TTBCR.PD0
field to use TTBR0 for translation table walks.

The 'commit dbece45894d3a ("ARM: 7501/1: decompressor:
reset ttbcr for VMSA ARMv7 cores")' does the reset of TTBCR.N, but
doesn't consider all the bits for the size of TTBCR.N.

Clear TTBCR.PD0 field and reset all the three bits of TTBCR.N to
indicate the use of TTBR0 and the correct base address width.

Signed-off-by: Srinivas Ramana <sramana@codeaurora.org>
---
 arch/arm/boot/compressed/head.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index af11c2f8f3b7..fc6d541549a2 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -779,7 +779,7 @@ __armv7_mmu_cache_on:
 		orrne	r0, r0, #1		@ MMU enabled
 		movne	r1, #0xfffffffd		@ domain 0 = client
 		bic     r6, r6, #1 << 31        @ 32-bit translation system
-		bic     r6, r6, #3 << 0         @ use only ttbr0
+		bic     r6, r6, #(7 << 0) | (1 << 4)	@ use only ttbr0
 		mcrne	p15, 0, r3, c2, c0, 0	@ load page table pointer
 		mcrne	p15, 0, r1, c3, c0, 0	@ load domain access control
 		mcrne   p15, 0, r6, c2, c0, 2   @ load ttb control
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., 
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

[toc] | [prev] | [next] | [standalone]


#1481125 — Re: [PATCH] ARM: decompressor: reset ttbcr fields to use TTBR0 on ARMv7

FromRussell King - ARM Linux <linux@armlinux.org.uk>
Date2016-09-12 12:30 +0200
SubjectRe: [PATCH] ARM: decompressor: reset ttbcr fields to use TTBR0 on ARMv7
Message-ID<sgwEW-1Zi-43@gated-at.bofh.it>
In reply to#1480957
On Mon, Sep 12, 2016 at 12:27:00PM +0530, Srinivas Ramana wrote:
> If the bootloader uses the long descriptor format and jumps to
> kernel decompressor code, TTBCR may not be in a right state.
> Before enabling the MMU, it is required to clear the TTBCR.PD0
> field to use TTBR0 for translation table walks.
> 
> The 'commit dbece45894d3a ("ARM: 7501/1: decompressor:
> reset ttbcr for VMSA ARMv7 cores")' does the reset of TTBCR.N, but

There's no need to single-quote the commit part of this sentence.

> doesn't consider all the bits for the size of TTBCR.N.
> 
> Clear TTBCR.PD0 field and reset all the three bits of TTBCR.N to
> indicate the use of TTBR0 and the correct base address width.
> 

Adding a properly formatted Fixes: line here would be a bonus if we
need to backport it to stable trees.

> Signed-off-by: Srinivas Ramana <sramana@codeaurora.org>
> ---
>  arch/arm/boot/compressed/head.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index af11c2f8f3b7..fc6d541549a2 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -779,7 +779,7 @@ __armv7_mmu_cache_on:
>  		orrne	r0, r0, #1		@ MMU enabled
>  		movne	r1, #0xfffffffd		@ domain 0 = client
>  		bic     r6, r6, #1 << 31        @ 32-bit translation system
> -		bic     r6, r6, #3 << 0         @ use only ttbr0
> +		bic     r6, r6, #(7 << 0) | (1 << 4)	@ use only ttbr0

Provided this is correct (I've not checked, I'd like an ack from one of
the ARM people, and I'd prefer to see a tested-by as well), and the above
points are addressed, it can be dropped into the patch system.  Thanks.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[toc] | [prev] | [next] | [standalone]


#1481769 — Re: [PATCH] ARM: decompressor: reset ttbcr fields to use TTBR0 on ARMv7

FromRobin Murphy <robin.murphy@arm.com>
Date2016-09-12 20:00 +0200
SubjectRe: [PATCH] ARM: decompressor: reset ttbcr fields to use TTBR0 on ARMv7
Message-ID<sgDGq-6uu-37@gated-at.bofh.it>
In reply to#1480957
On 12/09/16 07:57, Srinivas Ramana wrote:
> If the bootloader uses the long descriptor format and jumps to
> kernel decompressor code, TTBCR may not be in a right state.
> Before enabling the MMU, it is required to clear the TTBCR.PD0
> field to use TTBR0 for translation table walks.
> 
> The 'commit dbece45894d3a ("ARM: 7501/1: decompressor:
> reset ttbcr for VMSA ARMv7 cores")' does the reset of TTBCR.N, but
> doesn't consider all the bits for the size of TTBCR.N.
> 
> Clear TTBCR.PD0 field and reset all the three bits of TTBCR.N to
> indicate the use of TTBR0 and the correct base address width.
> 
> Signed-off-by: Srinivas Ramana <sramana@codeaurora.org>
> ---
>  arch/arm/boot/compressed/head.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index af11c2f8f3b7..fc6d541549a2 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -779,7 +779,7 @@ __armv7_mmu_cache_on:
>  		orrne	r0, r0, #1		@ MMU enabled
>  		movne	r1, #0xfffffffd		@ domain 0 = client
>  		bic     r6, r6, #1 << 31        @ 32-bit translation system

Hmm, if TTBCR.EAE _was_ actually set...

> -		bic     r6, r6, #3 << 0         @ use only ttbr0
> +		bic     r6, r6, #(7 << 0) | (1 << 4)	@ use only ttbr0
>  		mcrne	p15, 0, r3, c2, c0, 0	@ load page table pointer
>  		mcrne	p15, 0, r1, c3, c0, 0	@ load domain access control
>  		mcrne   p15, 0, r6, c2, c0, 2   @ load ttb control

...then strictly the TLBIALL needs to happen after the ISB following
this update. Otherwise per B3.10.2 of DDI406C.c I think we might be into
unpredictable territory - i.e. if the TLB happens to treat long- and
short-descriptor entries differently then the TLBI beforehand (with EAE
set) may be at liberty to only discard long-descriptor entries and leave
bogus short-descriptor entries sitting around.

In other words, something like (completely untested):

---8<---
diff --git a/arch/arm/boot/compressed/head.S
b/arch/arm/boot/compressed/head.S
index af11c2f8f3b7..536b7781024a 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -764,7 +764,6 @@ __armv7_mmu_cache_on:
                mov     r0, #0
                mcr     p15, 0, r0, c7, c10, 4  @ drain write buffer
                tst     r11, #0xf               @ VMSA
-               mcrne   p15, 0, r0, c8, c7, 0   @ flush I,D TLBs
 #endif
                mrc     p15, 0, r0, c1, c0, 0   @ read control reg
                bic     r0, r0, #1 << 28        @ clear SCTLR.TRE
@@ -783,8 +782,11 @@ __armv7_mmu_cache_on:
                mcrne   p15, 0, r3, c2, c0, 0   @ load page table pointer
                mcrne   p15, 0, r1, c3, c0, 0   @ load domain access control
                mcrne   p15, 0, r6, c2, c0, 2   @ load ttb control
-#endif
                mcr     p15, 0, r0, c7, c5, 4   @ ISB
+               mcrne   p15, 0, r0, c8, c7, 0   @ flush I,D TLBs
+#else
+               mcr     p15, 0, r0, c7, c5, 4   @ ISB
+#endif
                mcr     p15, 0, r0, c1, c0, 0   @ load control register
                mrc     p15, 0, r0, c1, c0, 0   @ and read it back
---8<---

Robin.

[toc] | [prev] | [next] | [standalone]


#1482562 — Re: [PATCH] ARM: decompressor: reset ttbcr fields to use TTBR0 on ARMv7

FromSrinivas Ramana <sramana@codeaurora.org>
Date2016-09-13 17:00 +0200
SubjectRe: [PATCH] ARM: decompressor: reset ttbcr fields to use TTBR0 on ARMv7
Message-ID<sgXlM-3gI-31@gated-at.bofh.it>
In reply to#1481769
On 09/12/2016 11:21 PM, Robin Murphy wrote:
> On 12/09/16 07:57, Srinivas Ramana wrote:
>> If the bootloader uses the long descriptor format and jumps to
>> kernel decompressor code, TTBCR may not be in a right state.
>> Before enabling the MMU, it is required to clear the TTBCR.PD0
>> field to use TTBR0 for translation table walks.
>>
>> The 'commit dbece45894d3a ("ARM: 7501/1: decompressor:
>> reset ttbcr for VMSA ARMv7 cores")' does the reset of TTBCR.N, but
>> doesn't consider all the bits for the size of TTBCR.N.
>>
>> Clear TTBCR.PD0 field and reset all the three bits of TTBCR.N to
>> indicate the use of TTBR0 and the correct base address width.
>>
>> Signed-off-by: Srinivas Ramana <sramana@codeaurora.org>
>> ---
>>   arch/arm/boot/compressed/head.S | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
>> index af11c2f8f3b7..fc6d541549a2 100644
>> --- a/arch/arm/boot/compressed/head.S
>> +++ b/arch/arm/boot/compressed/head.S
>> @@ -779,7 +779,7 @@ __armv7_mmu_cache_on:
>>   		orrne	r0, r0, #1		@ MMU enabled
>>   		movne	r1, #0xfffffffd		@ domain 0 = client
>>   		bic     r6, r6, #1 << 31        @ 32-bit translation system
>
> Hmm, if TTBCR.EAE _was_ actually set...
>
>> -		bic     r6, r6, #3 << 0         @ use only ttbr0
>> +		bic     r6, r6, #(7 << 0) | (1 << 4)	@ use only ttbr0
>>   		mcrne	p15, 0, r3, c2, c0, 0	@ load page table pointer
>>   		mcrne	p15, 0, r1, c3, c0, 0	@ load domain access control
>>   		mcrne   p15, 0, r6, c2, c0, 2   @ load ttb control
>
> ...then strictly the TLBIALL needs to happen after the ISB following
> this update. Otherwise per B3.10.2 of DDI406C.c I think we might be into
> unpredictable territory - i.e. if the TLB happens to treat long- and
> short-descriptor entries differently then the TLBI beforehand (with EAE
> set) may be at liberty to only discard long-descriptor entries and leave
> bogus short-descriptor entries sitting around.
Yes, it seems this has to be taken care of, along with resetting 
TTBCR.PD0 and TTBCR.N. Do you say that this needs to be done in the same 
patch or a different one?
>
> In other words, something like (completely untested):
>
> ---8<---
> diff --git a/arch/arm/boot/compressed/head.S
> b/arch/arm/boot/compressed/head.S
> index af11c2f8f3b7..536b7781024a 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -764,7 +764,6 @@ __armv7_mmu_cache_on:
>                  mov     r0, #0
>                  mcr     p15, 0, r0, c7, c10, 4  @ drain write buffer
>                  tst     r11, #0xf               @ VMSA
> -               mcrne   p15, 0, r0, c8, c7, 0   @ flush I,D TLBs

Shouldn't this be still there for the same reason you explained above? I 
mean to discard the long descriptor entries when EAE was 1 (before we 
reset it).
>   #endif
>                  mrc     p15, 0, r0, c1, c0, 0   @ read control reg
>                  bic     r0, r0, #1 << 28        @ clear SCTLR.TRE
> @@ -783,8 +782,11 @@ __armv7_mmu_cache_on:
>                  mcrne   p15, 0, r3, c2, c0, 0   @ load page table pointer
>                  mcrne   p15, 0, r1, c3, c0, 0   @ load domain access control
>                  mcrne   p15, 0, r6, c2, c0, 2   @ load ttb control
> -#endif
>                  mcr     p15, 0, r0, c7, c5, 4   @ ISB
> +               mcrne   p15, 0, r0, c8, c7, 0   @ flush I,D TLBs
> +#else
> +               mcr     p15, 0, r0, c7, c5, 4   @ ISB
> +#endif
>                  mcr     p15, 0, r0, c1, c0, 0   @ load control register
>                  mrc     p15, 0, r0, c1, c0, 0   @ and read it back
> ---8<---
>
> Robin.
>
i have tested this change (flush I, D, TLBs after TTB control is 
written) and don't see any issue. But on my setup decompression is 
successful even without this (probably not hitting the case in discussion).


Thanks,
-- Srinivas R

-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, 
Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative 
Project.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web