ARM: decompressor: Fix mmu mapping for non-DRAM address space.

From: R Sricharan <[email protected]>

ARM decompressor code setups entire 4GB address space pages. Out of the 4GB, about 256MB are setup with normal memory attributes for needed DRAM and the rest of the address space as Strongly ordered.

But since all the sections are mapped in DOMAIN0(Manager), processor like Cortex-A15, can speculatively prefetch from non-DRAM read sensitive areas even in the presence of XN(Non-executable). This is because XN attribute is ignored when domain is Manager.

This can lead to accesses to non-accessible address regions leading to various interconnect violations. The issue is observed on OMAP5.

This patch tries to fix the issue by ensuring that non-DRAM region is marked as a client domain so that XN attribute is effective.

A better alternative is to not map un-used regions but since the decompressor code is generic, there might be many exceptions for the devices used like debug console etc.

Signed-off-by R Sricharan <[email protected]>

Signed-off-by Santosh Shilimkar <[email protected]>

Cc Russell King <[email protected]>

Cc Catalin Marinas <[email protected]>

---
 arch/arm/boot/compressed/head.S |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

arch/arm/boot/compressed/head.S +1 -1

index dc7e8ce..4dc799b 100644
@@ -578,7 +578,7 @@ __setup_mmu:	sub	r3, r4, #16384		@ Page directory size
 		mov	r9, r0, lsr #18
 		mov	r9, r9, lsl #18		@ start of RAM
 		add	r10, r9, #0x10000000	@ a reasonable RAM size
-		mov	r1, #0x12
+		mov	r1, #0x32		@ set domain1, XN, valid
 		orr	r1, r1, #3 << 10
 		add	r2, r3, #16384
 1:		cmp	r1, r9			@ if virt > start of RAM

Quoted 47 lines · Santosh Shilimkar

From: R Sricharan <[email protected]>

ARM decompressor code setups entire 4GB address space pages. Out of the 4GB, about 256MB are setup with normal memory attributes for needed DRAM and the rest of the address space as Strongly ordered.

But since all the sections are mapped in DOMAIN0(Manager), processor like Cortex-A15, can speculatively prefetch from non-DRAM read sensitive areas even in the presence of XN(Non-executable). This is because XN attribute is ignored when domain is Manager.

This can lead to accesses to non-accessible address regions leading to various interconnect violations. The issue is observed on OMAP5.

This patch tries to fix the issue by ensuring that non-DRAM region is marked as a client domain so that XN attribute is effective.

A better alternative is to not map un-used regions but since the decompressor code is generic, there might be many exceptions for the devices used like debug console etc.

Signed-off-by R Sricharan <[email protected]>

Signed-off-by Santosh Shilimkar <[email protected]>

Cc Russell King <[email protected]>

Cc Catalin Marinas <[email protected]>

---
?arch/arm/boot/compressed/head.S | ? ?7 ++++++-
?1 files changed, 6 insertions(+), 1 deletions(-)

arch/arm/boot/compressed/head.S +0 -0

index dc7e8ce..4dc799b 100644
@@ -578,7 +578,7 @@ __setup_mmu: ? ? ?sub ? ? r3, r4, #16384 ? ? ? ? ?@ Page directory size

? ? ? ? ? ? ? mov ? ? r9, r0, lsr #18
? ? ? ? ? ? ? mov ? ? r9, r9, lsl #18 ? ? ? ? @ start of RAM ? ? ? ? ? ? ? add ? ? r10, r9, #0x10000000 ? ?@ a reasonable RAM size
- ? ? ? ? ? ? mov ? ? r1, #0x12
+ ? ? ? ? ? ? mov ? ? r1, #0x32 ? ? ? ? ? ? ? @ set domain1, XN, valid ? ? ? ? ? ? ? orr ? ? r1, r1, #3 << 10
? ? ? ? ? ? ? add ? ? r2, r3, #16384
?1: ? ? ? ? ? cmp ? ? r1, r9 ? ? ? ? ? ? ? ? ?@ if virt > start of RAM

arch/arm/boot/compressed/head.S +0 -0

@@ -587,8 +587,10 @@ __setup_mmu: ? ? sub ? ? r3, r4, #16384 ? ? ? ? ?@ Page directory size

?#else
? ? ? ? ? ? ? orrhs ? r1, r1, #0x0c ? ? ? ? ? @ set cacheable, bufferable ?#endif
+ ? ? ? ? ? ? bichs ? r1, r1, #0x20 ? ? ? ? ? @ set domain0 for DRAM

Quoted 3 lines

? ? ? ? ? ? ? cmp ? ? r1, r10 ? ? ? ? ? ? ? ? @ if virt > end of RAM ? ? ? ? ? ? ? bichs ? r1, r1, #0x0c ? ? ? ? ? @ clear cacheable, bufferable
+ ? ? ? ? ? ? orrhs ? r1, r1, #0x20 ? ? ? ? ? @ set domain1

I would leave the same domain (0, set as client) and rather change the XN and cacheability bits once we finished with the DRAM. I think it's cleaner assuming we have two domains and the manager one overrides the XN bit.

From b906ef372f0e2dfa7e1fbc3c87406b1c303d8975 Mon Sep 17 00:00:00 2001

From b906ef372f0e2dfa7e1fbc3c87406b1c303d8975 Mon Sep 17 00:00:00 2001
From: R Sricharan <[email protected]>
Date: Mon, 7 May 2012 15:11:58 +0530
Subject: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address
space.

ARM decompressor code setups entire 4GB address space pages. Out of the 4GB, about 256MB are setup with normal memory attributes for needed DRAM and the rest of the address space as Strongly ordered.

But since all the sections are mapped in DOMAIN0(Manager), processor like Cortex-A15, can speculatively prefetch from non-DRAM read sensitive areas even in the presence of XN(Non-executable). This is because XN attribute is ignored when domain is Manager.

This can lead to accesses to non-accessible address regions leading to various interconnect violations. The issue is observed on OMAP5.

This patch tries to fix the issue by ensuring that all regions are marked as a client domain so that XN attribute is effective.

Signed-off-by R Sricharan <[email protected]>

Signed-off-by Santosh Shilimkar <[email protected]>

Cc Russell King <[email protected]>

Cc Catalin Marinas <[email protected]>

---
 arch/arm/boot/compressed/head.S |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)

arch/arm/boot/compressed/head.S +0 -0

index dc7e8ce..a2602b8 100644

Quoted 29 lines · Santosh

From b906ef372f0e2dfa7e1fbc3c87406b1c303d8975 Mon Sep 17 00:00:00 2001
From: R Sricharan <[email protected]>
Date: Mon, 7 May 2012 15:11:58 +0530
Subject: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address
space.

ARM decompressor code setups entire 4GB address space pages. Out of the 4GB, about 256MB are setup with normal memory attributes for needed DRAM and the rest of the address space as Strongly ordered.

But since all the sections are mapped in DOMAIN0(Manager), processor like Cortex-A15, can speculatively prefetch from non-DRAM read sensitive areas even in the presence of XN(Non-executable). This is because XN attribute is ignored when domain is Manager.

This can lead to accesses to non-accessible address regions leading to various interconnect violations. The issue is observed on OMAP5.

This patch tries to fix the issue by ensuring that all regions are marked as a client domain so that XN attribute is effective.

Signed-off-by R Sricharan <[email protected]>

Signed-off-by Santosh Shilimkar <[email protected]>

Cc Russell King <[email protected]>

Cc Catalin Marinas <[email protected]>

---
 arch/arm/boot/compressed/head.S |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)

arch/arm/boot/compressed/head.S __setup_mmu: sub r3, r4, #16384 @ Page directory size · line 581

Quoted 10 lines

arch/arm/boot/compressed/head.S +1 -1

index dc7e8ce..a2602b8 100644
@@ -578,10 +578,12 @@ __setup_mmu:	sub	r3, r4, #16384		@ Page directory size
 		mov	r9, r0, lsr #18
 		mov	r9, r9, lsl #18		@ start of RAM
 		add	r10, r9, #0x10000000	@ a reasonable RAM size
-		mov	r1, #0x12
+		mov	r1, #0x02		@ Default executable section

I think it is simpler if you leave the original code here (with XN)

Quoted 30 lines · Catalin Marinas

Quoted 29 lines · Santosh

From b906ef372f0e2dfa7e1fbc3c87406b1c303d8975 Mon Sep 17 00:00:00 2001
From: R Sricharan <[email protected]>
Date: Mon, 7 May 2012 15:11:58 +0530
Subject: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address
space.

ARM decompressor code setups entire 4GB address space pages. Out of the 4GB, about 256MB are setup with normal memory attributes for needed DRAM and the rest of the address space as Strongly ordered.

But since all the sections are mapped in DOMAIN0(Manager), processor like Cortex-A15, can speculatively prefetch from non-DRAM read sensitive areas even in the presence of XN(Non-executable). This is because XN attribute is ignored when domain is Manager.

This can lead to accesses to non-accessible address regions leading to various interconnect violations. The issue is observed on OMAP5.

This patch tries to fix the issue by ensuring that all regions are marked as a client domain so that XN attribute is effective.

Signed-off-by R Sricharan <[email protected]>

Signed-off-by Santosh Shilimkar <[email protected]>

Cc Russell King <[email protected]>

Cc Catalin Marinas <[email protected]>

---
 arch/arm/boot/compressed/head.S |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)

Quoted 12 lines

arch/arm/boot/compressed/head.S __setup_mmu: sub r3, r4, #16384 @ Page directory size · line 581

Quoted 10 lines

arch/arm/boot/compressed/head.S +1 -1

index dc7e8ce..a2602b8 100644
@@ -578,10 +578,12 @@ __setup_mmu:	sub	r3, r4, #16384		@ Page directory size
 		mov	r9, r0, lsr #18
 		mov	r9, r9, lsl #18		@ start of RAM
 		add	r10, r9, #0x10000000	@ a reasonable RAM size
-		mov	r1, #0x12
+		mov	r1, #0x02		@ Default executable section

I think it is simpler if you leave the original code here (with XN)

Sounds good. With that updated can I add your ack

and push it to the patch system ?

Quoted 44 lines · Santosh Shilimkar

Quoted 42 lines · Catalin Marinas

Quoted 34 lines · Santosh

From b906ef372f0e2dfa7e1fbc3c87406b1c303d8975 Mon Sep 17 00:00:00 2001
From: R Sricharan <[email protected]>
Date: Mon, 7 May 2012 15:11:58 +0530
Subject: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address
space.

ARM decompressor code setups entire 4GB address space pages. Out of the 4GB, about 256MB are setup with normal memory attributes for needed DRAM and the rest of the address space as Strongly ordered.

But since all the sections are mapped in DOMAIN0(Manager), processor like Cortex-A15, can speculatively prefetch from non-DRAM read sensitive areas even in the presence of XN(Non-executable). This is because XN attribute is ignored when domain is Manager.

This can lead to accesses to non-accessible address regions leading to various interconnect violations. The issue is observed on OMAP5.

This patch tries to fix the issue by ensuring that all regions are marked as a client domain so that XN attribute is effective.

Signed-off-by R Sricharan <[email protected]>

Signed-off-by Santosh Shilimkar <[email protected]>

Cc Russell King <[email protected]>

Cc Catalin Marinas <[email protected]>

---
 arch/arm/boot/compressed/head.S |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)

arch/arm/boot/compressed/head.S +0 -0

index dc7e8ce..a2602b8 100644

arch/arm/boot/compressed/head.S __setup_mmu: sub r3, r4, #16384 @ Page directory size · line 581

Quoted 5 lines

arch/arm/boot/compressed/head.S +1 -1

@@ -578,10 +578,12 @@ __setup_mmu:	sub	r3, r4, #16384		@ Page directory size
 		mov	r9, r0, lsr #18
 		mov	r9, r9, lsl #18		@ start of RAM
 		add	r10, r9, #0x10000000	@ a reasonable RAM size
-		mov	r1, #0x12
+		mov	r1, #0x02		@ Default executable section

I think it is simpler if you leave the original code here (with XN)

Quoted 1 line

Sounds good. With that updated can I add your ack

Yes.

Quoted 2 lines

and push it to the patch system ?

That's up to Russell.

Ok. Assuming you mean " it's _not_ cleaner to have two domains where manager overrides XN attributes" Note that DRAM can be in the middle of 4GB address space, so we need to take care of bottom and top address space.

Update patch end of the email. Is that fine with you ?

Quoted 6 lines · Santosh

Ok. Assuming you mean " it's _not_ cleaner to have two domains where manager overrides XN attributes" Note that DRAM can be in the middle of 4GB address space, so we need to take care of bottom and top address space.

Update patch end of the email. Is that fine with you ?

This is certainly not cleaner because this will break non-ARMv7.

From a52613d1adc38651bf0fb824700efeb2fa02f1a2 Mon Sep 17 00:00:00 2001

Quoted 9 lines · Russell King - ARM Linux

Quoted 6 lines · Santosh

Ok. Assuming you mean " it's _not_ cleaner to have two domains where manager overrides XN attributes" Note that DRAM can be in the middle of 4GB address space, so we need to take care of bottom and top address space.

Update patch end of the email. Is that fine with you ?

This is certainly not cleaner because this will break non-ARMv7.

The only change done common code is clearing 'XN' bit for DRAM region in page table entries. The other change of setting the DACR register is done in ARMv7 specific code.

So it should work as long as XN bit supported or that bit position is not used. I checked ARMv6(OMAP2) and that seems to be fine.

Can you please help me to understand which ARM version will be broken because of this change and how ? I only have access to ARMv6 and ARMv7 specs.

The only change done common code is clearing 'XN' bit for DRAM region in page table entries. The other change of setting the DACR register is done in ARMv7 specific code.

Quoted 3 lines · Santosh

The only change done common code is ?clearing 'XN' bit for DRAM region in page table entries. The other change of setting the DACR register is done in ARMv7 specific code.

Yes, XN is an ARMv6+ thing. ?Before ARMv5, it was implementation defined.

Some implementations used the bit to mean "allow writes to update the cache". ?Other implementations labelled this bit as "should be zero" while others labelled it as "should be one".

The upshot of this is, we know that having this bit as '1' means that all the CPUs we support today work. ?I would be _very_ concerned to change this bit to zero as we _really_ don't know how the pre-ARMv6 CPUs would react.

The solution to this is pretty simple - if ARMv6+ needs a different base section mapping value, then we need to extract that from the code and pass in the base section mapping value.

I'll sort out a patch later today for this.

Quoted 11 lines · Russell King - ARM Linux

Quoted 3 lines · Santosh

The only change done common code is ?clearing 'XN' bit for DRAM region in page table entries. The other change of setting the DACR register is done in ARMv7 specific code.

Yes, XN is an ARMv6+ thing. ?Before ARMv5, it was implementation defined.

Some implementations used the bit to mean "allow writes to update the cache". ?Other implementations labelled this bit as "should be zero" while others labelled it as "should be one".

Good to know.

Quoted 5 lines

The upshot of this is, we know that having this bit as '1' means that all the CPUs we support today work. ?I would be _very_ concerned to change this bit to zero as we _really_ don't know how the pre-ARMv6 CPUs would react.

I agree.

Quoted 5 lines

The solution to this is pretty simple - if ARMv6+ needs a different base section mapping value, then we need to extract that from the code and pass in the base section mapping value.

I'll sort out a patch later today for this.

Great.

Quoted 26 lines · Santosh

Quoted 11 lines · Russell King - ARM Linux

Quoted 3 lines · Santosh

The only change done common code is ?clearing 'XN' bit for DRAM region in page table entries. The other change of setting the DACR register is done in ARMv7 specific code.

Yes, XN is an ARMv6+ thing. ?Before ARMv5, it was implementation defined.

Some implementations used the bit to mean "allow writes to update the cache". ?Other implementations labelled this bit as "should be zero" while others labelled it as "should be one".

Good to know.

Quoted 5 lines

The upshot of this is, we know that having this bit as '1' means that all the CPUs we support today work. ?I would be _very_ concerned to change this bit to zero as we _really_ don't know how the pre-ARMv6 CPUs would react.

I agree.

Quoted 4 lines

The solution to this is pretty simple - if ARMv6+ needs a different base section mapping value, then we need to extract that from the code and pass in the base section mapping value.

Quoted 2 lines

Quoted 1 line

I'll sort out a patch later today for this.

Great.

This works for my 4430SDP board. ?I haven't booted it on anything else yet. Please can you check that this solves the issue for you? ?Thanks.

?arch/arm/boot/compressed/head.S | ? 29 ++++++++++++++++++----------- ?1 files changed, 18 insertions(+), 11 deletions(-)

arch/arm/boot/compressed/head.S +0 -0

index dc7e8ce..5ad33a4 100644
@@ -567,6 +567,12 @@ __armv3_mpu_cache_on:

? ? ? ? ? ? ? ?mcr ? ? p15, 0, r0, c7, c0, 0 ? @ invalidate whole cache v3 ? ? ? ? ? ? ? ?mov ? ? pc, lr

arch/arm/boot/compressed/head.S +6 -0

+#ifdef CONFIG_CPU_DCACHE_WRITETHROUGH
+#define CB_BITS 0x08
+#else
+#define CB_BITS 0x0c
+#endif
+

?__setup_mmu: ? sub ? ? r3, r4, #16384 ? ? ? ? ?@ Page directory size ? ? ? ? ? ? ? ?bic ? ? r3, r3, #0xff ? ? ? ? ? @ Align the pointer ? ? ? ? ? ? ? ?bic ? ? r3, r3, #0x3f00

arch/arm/boot/compressed/head.S +0 -0

@@ -578,17 +584,14 @@ __setup_mmu: ? ? ?sub ? ? r3, r4, #16384 ? ? ? ? ?@ Page directory size

? ? ? ? ? ? ? ?mov ? ? r9, r0, lsr #18
? ? ? ? ? ? ? ?mov ? ? r9, r9, lsl #18 ? ? ? ? @ start of RAM ? ? ? ? ? ? ? ?add ? ? r10, r9, #0x10000000 ? ?@ a reasonable RAM size
- ? ? ? ? ? ? ? mov ? ? r1, #0x12
- ? ? ? ? ? ? ? orr ? ? r1, r1, #3 << 10
+ ? ? ? ? ? ? ? mov ? ? r1, #0x12 ? ? ? ? ? ? ? @ XN|U + section mapping
+ ? ? ? ? ? ? ? orr ? ? r1, r1, #3 << 10 ? ? ? ?@ AP=11
? ? ? ? ? ? ? ?add ? ? r2, r3, #16384
?1: ? ? ? ? ? ? cmp ? ? r1, r9 ? ? ? ? ? ? ? ? ?@ if virt > start of RAM

arch/arm/boot/compressed/head.S +4 -7

-#ifdef CONFIG_CPU_DCACHE_WRITETHROUGH
- ? ? ? ? ? ? ? orrhs ? r1, r1, #0x08 ? ? ? ? ? @ set cacheable
-#else
- ? ? ? ? ? ? ? orrhs ? r1, r1, #0x0c ? ? ? ? ? @ set cacheable, bufferable
-#endif
- ? ? ? ? ? ? ? cmp ? ? r1, r10 ? ? ? ? ? ? ? ? @ if virt > end of RAM
- ? ? ? ? ? ? ? bichs ? r1, r1, #0x0c ? ? ? ? ? @ clear cacheable, bufferable
+ ? ? ? ? ? ? ? cmphs ? r10, r1 ? ? ? ? ? ? ? ? @ ? && end of RAM > virt
+ ? ? ? ? ? ? ? bic ? ? r1, r1, #0x1c ? ? ? ? ? @ clear XN|U + C + B
+ ? ? ? ? ? ? ? orrlo ? r1, r1, #0x10 ? ? ? ? ? @ Set XN|U for non-RAM
+ ? ? ? ? ? ? ? orrhs ? r1, r1, r6 ? ? ? ? ? ? ?@ set RAM section settings

? ? ? ? ? ? ? ?str ? ? r1, [r0], #4 ? ? ? ? ? ?@ 1:1 mapping ? ? ? ? ? ? ? ?add ? ? r1, r1, #1048576
? ? ? ? ? ? ? ?teq ? ? r0, r2

arch/arm/boot/compressed/head.S +0 -0

@@ -599,7 +602,7 @@ __setup_mmu: ? ? ? ?sub ? ? r3, r4, #16384 ? ? ? ? ?@ Page directory size

?* so there is no map overlap problem for up to 1 MB compressed kernel. ?* If the execution is in RAM then we would only be duplicating the above. ?*/
- ? ? ? ? ? ? ? mov ? ? r1, #0x1e
+ ? ? ? ? ? ? ? orr ? ? r1, r6, #0x04 ? ? ? ? ? @ ensure B is set for this ? ? ? ? ? ? ? ?orr ? ? r1, r1, #3 << 10
? ? ? ? ? ? ? ?mov ? ? r2, pc
? ? ? ? ? ? ? ?mov ? ? r2, r2, lsr #20

arch/arm/boot/compressed/head.S +0 -0

@@ -620,6 +623,7 @@ __arm926ejs_mmu_cache_on:

?__armv4_mmu_cache_on:
? ? ? ? ? ? ? ?mov ? ? r12, lr
?#ifdef CONFIG_MMU
+ ? ? ? ? ? ? ? mov ? ? r6, #CB_BITS | 0x12 ? ? @ U
? ? ? ? ? ? ? ?bl ? ? ?__setup_mmu
? ? ? ? ? ? ? ?mov ? ? r0, #0
? ? ? ? ? ? ? ?mcr ? ? p15, 0, r0, c7, c10, 4 ?@ drain write buffer

arch/arm/boot/compressed/head.S +0 -0

@@ -641,6 +645,7 @@ __armv7_mmu_cache_on:

?#ifdef CONFIG_MMU
? ? ? ? ? ? ? ?mrc ? ? p15, 0, r11, c0, c1, 4 ?@ read ID_MMFR0 ? ? ? ? ? ? ? ?tst ? ? r11, #0xf ? ? ? ? ? ? ? @ VMSA
+ ? ? ? ? ? ? ? movne ? r6, #CB_BITS | 0x02 ? ? @ !XN
? ? ? ? ? ? ? ?blne ? ?__setup_mmu
? ? ? ? ? ? ? ?mov ? ? r0, #0
? ? ? ? ? ? ? ?mcr ? ? p15, 0, r0, c7, c10, 4 ?@ drain write buffer

arch/arm/boot/compressed/head.S +0 -0

@@ -655,7 +660,7 @@ __armv7_mmu_cache_on:

? ? ? ? ? ? ? ?orr ? ? r0, r0, #1 << 25 ? ? ? ?@ big-endian page tables ?#endif
? ? ? ? ? ? ? ?orrne ? r0, r0, #1 ? ? ? ? ? ? ?@ MMU enabled
- ? ? ? ? ? ? ? movne ? r1, #-1
+ ? ? ? ? ? ? ? movne ? r1, #0xfffffffd ? ? ? ? @ domain 0 = client ? ? ? ? ? ? ? ?mcrne ? p15, 0, r3, c2, c0, 0 ? @ load page table pointer ? ? ? ? ? ? ? ?mcrne ? p15, 0, r1, c3, c0, 0 ? @ load domain access control ?#endif

arch/arm/boot/compressed/head.S +0 -0

@@ -668,6 +673,7 @@ __armv7_mmu_cache_on:
 

?__fa526_cache_on:
? ? ? ? ? ? ? ?mov ? ? r12, lr
+ ? ? ? ? ? ? ? mov ? ? r6, #CB_BITS | 0x12 ? ? @ U
? ? ? ? ? ? ? ?bl ? ? ?__setup_mmu
? ? ? ? ? ? ? ?mov ? ? r0, #0
? ? ? ? ? ? ? ?mcr ? ? p15, 0, r0, c7, c7, 0 ? @ Invalidate whole cache

arch/arm/boot/compressed/head.S +0 -0

@@ -682,6 +688,7 @@ __fa526_cache_on:
 

?__arm6_mmu_cache_on:
? ? ? ? ? ? ? ?mov ? ? r12, lr
+ ? ? ? ? ? ? ? mov ? ? r6, #CB_BITS | 0x12 ? ? @ U
? ? ? ? ? ? ? ?bl ? ? ?__setup_mmu
? ? ? ? ? ? ? ?mov ? ? r0, #0
? ? ? ? ? ? ? ?mcr ? ? p15, 0, r0, c7, c0, 0 ? @ invalidate whole cache v3 --
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo at vger.kernel.org
More majordomo info at ?http://vger.kernel.org/majordomo-info.html

Quoted 28 lines · Russell King - ARM Linux

Quoted 26 lines · Santosh

Quoted 11 lines · Russell King - ARM Linux

Quoted 3 lines · Santosh

The only change done common code is ?clearing 'XN' bit for DRAM region in page table entries. The other change of setting the DACR register is done in ARMv7 specific code.

Yes, XN is an ARMv6+ thing. ?Before ARMv5, it was implementation defined.

Some implementations used the bit to mean "allow writes to update the cache". ?Other implementations labelled this bit as "should be zero" while others labelled it as "should be one".

Good to know.

Quoted 5 lines

The upshot of this is, we know that having this bit as '1' means that all the CPUs we support today work. ?I would be _very_ concerned to change this bit to zero as we _really_ don't know how the pre-ARMv6 CPUs would react.

I agree.

Quoted 4 lines

The solution to this is pretty simple - if ARMv6+ needs a different base section mapping value, then we need to extract that from the code and pass in the base section mapping value.

Quoted 6 lines

Quoted 2 lines

Quoted 1 line

I'll sort out a patch later today for this.

Great.

This works for my 4430SDP board. ?I haven't booted it on anything else yet. Please can you check that this solves the issue for you? ?Thanks.

Solves the issue for OMAP5. Thanks Russel and company.

Quoted 37 lines · Bryan

Quoted 34 lines · Russell King - ARM Linux

Quoted 20 lines · Santosh

Quoted 11 lines · Russell King - ARM Linux

Quoted 3 lines · Santosh

The only change done common code is ?clearing 'XN' bit for DRAM region in page table entries. The other change of setting the DACR register is done in ARMv7 specific code.

Yes, XN is an ARMv6+ thing. ?Before ARMv5, it was implementation defined.

Some implementations used the bit to mean "allow writes to update the cache". ?Other implementations labelled this bit as "should be zero" while others labelled it as "should be one".

Good to know.

Quoted 5 lines

The upshot of this is, we know that having this bit as '1' means that all the CPUs we support today work. ?I would be _very_ concerned to change this bit to zero as we _really_ don't know how the pre-ARMv6 CPUs would react.

Quoted 8 lines

I agree.

Quoted 5 lines

The solution to this is pretty simple - if ARMv6+ needs a different base section mapping value, then we need to extract that from the code and pass in the base section mapping value.

I'll sort out a patch later today for this.

Great.

This works for my 4430SDP board. ?I haven't booted it on anything else yet. Please can you check that this solves the issue for you? ?Thanks.

Quoted 1 line

Solves the issue for OMAP5. Thanks Russel and company.

Can I add this attributation for this patch:

Tested-by Bryan Buckley <[email protected]>

?

Quoted 26 lines · Santosh

Quoted 11 lines · Russell King - ARM Linux

Quoted 3 lines · Santosh

The only change done common code is clearing 'XN' bit for DRAM region in page table entries. The other change of setting the DACR register is done in ARMv7 specific code.

Yes, XN is an ARMv6+ thing. Before ARMv5, it was implementation defined.

Some implementations used the bit to mean "allow writes to update the cache". Other implementations labelled this bit as "should be zero" while others labelled it as "should be one".

Good to know.

Quoted 5 lines

The upshot of this is, we know that having this bit as '1' means that all the CPUs we support today work. I would be _very_ concerned to change this bit to zero as we _really_ don't know how the pre-ARMv6 CPUs would react.

I agree.

Quoted 4 lines

The solution to this is pretty simple - if ARMv6+ needs a different base section mapping value, then we need to extract that from the code and pass in the base section mapping value.

Quoted 2 lines

Quoted 1 line

I'll sort out a patch later today for this.

Great.

This works for my 4430SDP board. I haven't booted it on anything else yet. Please can you check that this solves the issue for you? Thanks.

Are you planning to merge below patch as is or split the patch like 1) Refactoring 2) ARMv7 fix

Quoted 2 lines · Santosh Shilimkar

Are you planning to merge below patch as is or split the patch like 1) Refactoring 2) ARMv7 fix

I don't see any point in splitting this up, especially as the ARMv7 fix would involve merely changing two lines (the domain register value and the value passed into __setup_mmu via r6.)