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

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

[Santosh Shilimkar]

From: R Sricharan <r.sricharan@ti.com>

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 <r.sricharan@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
---
 arch/arm/boot/compressed/head.S |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index dc7e8ce..4dc799b 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -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
@@ -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
 		cmp	r1, r10			@ if virt > end of RAM
 		bichs	r1, r1, #0x0c		@ clear cacheable, bufferable
+		orrhs	r1, r1, #0x20		@ set domain1
 		str	r1, [r0], #4		@ 1:1 mapping
 		add	r1, r1, #1048576
 		teq	r0, r2
@@ -658,6 +660,9 @@ __armv7_mmu_cache_on:
 		movne	r1, #-1
 		mcrne	p15, 0, r3, c2, c0, 0	@ load page table pointer
 		mcrne	p15, 0, r1, c3, c0, 0	@ load domain access control
+		bic	r1, r1, #0xc
+		orr	r1, r1, #0x4
+		mcr	p15, 0, r1, c3, c0, 0   @ set domain1 as client
 #endif
 		mcr	p15, 0, r0, c7, c5, 4	@ ISB
 		mcr	p15, 0, r0, c1, c0, 0	@ load control register
-- 
1.7.5.4

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

[Catalin Marinas]

On Mon, May 07, 2012 at 02:42:29PM +0100, Santosh Shilimkar wrote:
> From: R Sricharan <r.sricharan@ti.com>
> 
> 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 <r.sricharan@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> ---
>  arch/arm/boot/compressed/head.S |    7 ++++++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index dc7e8ce..4dc799b 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -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
> @@ -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
>  		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.

>  		str	r1, [r0], #4		@ 1:1 mapping
>  		add	r1, r1, #1048576
>  		teq	r0, r2
> @@ -658,6 +660,9 @@ __armv7_mmu_cache_on:
>  		movne	r1, #-1
>  		mcrne	p15, 0, r3, c2, c0, 0	@ load page table pointer
>  		mcrne	p15, 0, r1, c3, c0, 0	@ load domain access control
> +		bic	r1, r1, #0xc
> +		orr	r1, r1, #0x4
> +		mcr	p15, 0, r1, c3, c0, 0   @ set domain1 as cliento

So here just set domain 0 as client.

-- 
Catalin

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

[Shilimkar, Santosh]

On Tue, May 8, 2012 at 6:11 PM, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Mon, May 07, 2012 at 02:42:29PM +0100, Santosh Shilimkar wrote:
>> From: R Sricharan <r.sricharan@ti.com>
>>
>> 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 <r.sricharan@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> ---
>> ?arch/arm/boot/compressed/head.S | ? ?7 ++++++-
>> ?1 files changed, 6 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
>> index dc7e8ce..4dc799b 100644
>> --- a/arch/arm/boot/compressed/head.S
>> +++ b/arch/arm/boot/compressed/head.S
>> @@ -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
>> @@ -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
>> ? ? ? ? ? ? ? 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.
>
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 ?

Regards
Santosh

>From b906ef372f0e2dfa7e1fbc3c87406b1c303d8975 Mon Sep 17 00:00:00 2001
From: R Sricharan <r.sricharan@ti.com>
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 <r.sricharan@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
---
 arch/arm/boot/compressed/head.S |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index dc7e8ce..a2602b8 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -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
 		orr	r1, r1, #3 << 10
 		add	r2, r3, #16384
 1:		cmp	r1, r9			@ if virt > start of RAM
+		orrlo	r1, r1, #0x10		@ Mark XN for non DRAM
+		bichs	r1, r1, #0x10		@ clear XN for DRAM
 #ifdef CONFIG_CPU_DCACHE_WRITETHROUGH
 		orrhs	r1, r1, #0x08		@ set cacheable
 #else
@@ -589,6 +591,7 @@ __setup_mmu:	sub	r3, r4, #16384		@ Page directory size
 #endif
 		cmp	r1, r10			@ if virt > end of RAM
 		bichs	r1, r1, #0x0c		@ clear cacheable, bufferable
+		orrhs	r1, r1, #0x10		@ Mark XN for non DRAM
 		str	r1, [r0], #4		@ 1:1 mapping
 		add	r1, r1, #1048576
 		teq	r0, r2
@@ -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
+		mov	r1, #0x0e		@ Clear XN
 		orr	r1, r1, #3 << 10
 		mov	r2, pc
 		mov	r2, r2, lsr #20
@@ -658,6 +661,9 @@ __armv7_mmu_cache_on:
 		movne	r1, #-1
 		mcrne	p15, 0, r3, c2, c0, 0	@ load page table pointer
 		mcrne	p15, 0, r1, c3, c0, 0	@ load domain access control
+		bic	r1, r1, #0x03		@ Clear domain0 bits
+		orr	r1, r1, #0x01		@ Set domain0 as client
+		mcr	p15, 0, r1, c3, c0, 0
 #endif
 		mcr	p15, 0, r0, c7, c5, 4	@ ISB
 		mcr	p15, 0, r0, c1, c0, 0	@ load control register
-- 
1.7.5.4

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

[Catalin Marinas]

On Tue, May 08, 2012 at 03:01:57PM +0100, Shilimkar, Santosh wrote:
> From b906ef372f0e2dfa7e1fbc3c87406b1c303d8975 Mon Sep 17 00:00:00 2001
> From: R Sricharan <r.sricharan@ti.com>
> 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 <r.sricharan@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> ---
>  arch/arm/boot/compressed/head.S |   10 ++++++++--
>  1 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index dc7e8ce..a2602b8 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -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)

>  		orr	r1, r1, #3 << 10
>  		add	r2, r3, #16384
>  1:		cmp	r1, r9			@ if virt > start of RAM
> +		orrlo	r1, r1, #0x10		@ Mark XN for non DRAM
> +		bichs	r1, r1, #0x10		@ clear XN for DRAM

and just do the bichs above.

-- 
Catalin

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

[Santosh Shilimkar]

On Tuesday 08 May 2012 07:46 PM, Catalin Marinas wrote:
> On Tue, May 08, 2012 at 03:01:57PM +0100, Shilimkar, Santosh wrote:
>> From b906ef372f0e2dfa7e1fbc3c87406b1c303d8975 Mon Sep 17 00:00:00 2001
>> From: R Sricharan <r.sricharan@ti.com>
>> 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 <r.sricharan@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> ---
>>  arch/arm/boot/compressed/head.S |   10 ++++++++--
>>  1 files changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
>> index dc7e8ce..a2602b8 100644
>> --- a/arch/arm/boot/compressed/head.S
>> +++ b/arch/arm/boot/compressed/head.S
>> @@ -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 ?

Regards
Santosh

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

[Catalin Marinas]

On Tue, May 08, 2012 at 03:20:43PM +0100, Santosh Shilimkar wrote:
> On Tuesday 08 May 2012 07:46 PM, Catalin Marinas wrote:
> > On Tue, May 08, 2012 at 03:01:57PM +0100, Shilimkar, Santosh wrote:
> >> From b906ef372f0e2dfa7e1fbc3c87406b1c303d8975 Mon Sep 17 00:00:00 2001
> >> From: R Sricharan <r.sricharan@ti.com>
> >> 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 <r.sricharan@ti.com>
> >> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> >> Cc: Russell King <linux@arm.linux.org.uk>
> >> Cc: Catalin Marinas <catalin.marinas@arm.com>
> >> ---
> >>  arch/arm/boot/compressed/head.S |   10 ++++++++--
> >>  1 files changed, 8 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> >> index dc7e8ce..a2602b8 100644
> >> --- a/arch/arm/boot/compressed/head.S
> >> +++ b/arch/arm/boot/compressed/head.S
> >> @@ -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

Yes.

> and push it to the patch system ?

That's up to Russell.

-- 
Catalin

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

[Santosh Shilimkar]

On Tuesday 08 May 2012 07:53 PM, Catalin Marinas wrote:
> On Tue, May 08, 2012 at 03:20:43PM +0100, Santosh Shilimkar wrote:
>> On Tuesday 08 May 2012 07:46 PM, Catalin Marinas wrote:
>>> On Tue, May 08, 2012 at 03:01:57PM +0100, Shilimkar, Santosh wrote:
>>>> From b906ef372f0e2dfa7e1fbc3c87406b1c303d8975 Mon Sep 17 00:00:00 2001
>>>> From: R Sricharan <r.sricharan@ti.com>
>>>> 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 <r.sricharan@ti.com>
>>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>>> Cc: Russell King <linux@arm.linux.org.uk>
>>>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>>>> ---
>>>>  arch/arm/boot/compressed/head.S |   10 ++++++++--
>>>>  1 files changed, 8 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
>>>> index dc7e8ce..a2602b8 100644
>>>> --- a/arch/arm/boot/compressed/head.S
>>>> +++ b/arch/arm/boot/compressed/head.S
>>>> @@ -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
> 
> Yes.
Great. Thanks
> 
>> and push it to the patch system ?
> 
> That's up to Russell.
> 
Ofcourse after Russell's ok.

Regards
Santosh

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

[Russell King - ARM Linux]

On Tue, May 08, 2012 at 07:31:57PM +0530, Shilimkar, Santosh wrote:
> 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.

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

[Shilimkar, Santosh]

On Wed, May 9, 2012 at 3:25 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, May 08, 2012 at 07:31:57PM +0530, Shilimkar, Santosh wrote:
>> 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 updated patch looks like below after fixing last comments from
Catalin.

Regards
Santosh

>From a52613d1adc38651bf0fb824700efeb2fa02f1a2 Mon Sep 17 00:00:00 2001
From: R Sricharan <r.sricharan@ti.com>
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 <r.sricharan@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
---
 arch/arm/boot/compressed/head.S |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index dc7e8ce..0faadf8 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -578,10 +578,11 @@ __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, #0x12		@ Default executable section
 		orr	r1, r1, #3 << 10
 		add	r2, r3, #16384
 1:		cmp	r1, r9			@ if virt > start of RAM
+		bichs	r1, r1, #0x10		@ clear XN for DRAM
 #ifdef CONFIG_CPU_DCACHE_WRITETHROUGH
 		orrhs	r1, r1, #0x08		@ set cacheable
 #else
@@ -589,6 +590,7 @@ __setup_mmu:	sub	r3, r4, #16384		@ Page directory size
 #endif
 		cmp	r1, r10			@ if virt > end of RAM
 		bichs	r1, r1, #0x0c		@ clear cacheable, bufferable
+		orrhs	r1, r1, #0x10		@ Mark XN for non DRAM
 		str	r1, [r0], #4		@ 1:1 mapping
 		add	r1, r1, #1048576
 		teq	r0, r2
@@ -599,7 +601,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
+		mov	r1, #0x0e		@ Clear XN
 		orr	r1, r1, #3 << 10
 		mov	r2, pc
 		mov	r2, r2, lsr #20
@@ -658,6 +660,9 @@ __armv7_mmu_cache_on:
 		movne	r1, #-1
 		mcrne	p15, 0, r3, c2, c0, 0	@ load page table pointer
 		mcrne	p15, 0, r1, c3, c0, 0	@ load domain access control
+		bic	r1, r1, #0x03		@ Clear domain0 bits
+		orr	r1, r1, #0x01		@ Set domain0 as client
+		mcr	p15, 0, r1, c3, c0, 0
 #endif
 		mcr	p15, 0, r0, c7, c5, 4	@ ISB
 		mcr	p15, 0, r0, c1, c0, 0	@ load control register
-- 
1.7.5.4

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

[Catalin Marinas]

On Wed, May 09, 2012 at 09:50:28AM +0100, Shilimkar, Santosh wrote:
> On Wed, May 9, 2012 at 3:25 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Tue, May 08, 2012 at 07:31:57PM +0530, Shilimkar, Santosh wrote:
> >> 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.

It's probably ARMv5 and earlier that didn't have an XN bit (introduced
with ARMv6).

I have an old ARM ARM on my desk and it looks like bit 4 is XN on ARMv6+
and Implementation Defined on ARMv5 and earlier.  It looks like we set
it all the time in the current decompressor.

Looking at the arch/arm/mm/mmu.c file, there is this PMD_BIT4 which is
always set on ARMv5 and earlier except Xscale and XSC3 (see the comment
in build_mem_type_table).

-- 
Catalin

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

[Russell King - ARM Linux]

On Wed, May 09, 2012 at 02:20:28PM +0530, Shilimkar, Santosh wrote:
> 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.

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

[Shilimkar, Santosh]

On Wed, May 9, 2012 at 5:53 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, May 09, 2012 at 02:20:28PM +0530, Shilimkar, Santosh wrote:
>> 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.

> 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.

> 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.

Regards
Santosh

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

[Russell King - ARM Linux]

On Wed, May 09, 2012 at 06:00:10PM +0530, Shilimkar, Santosh wrote:
> On Wed, May 9, 2012 at 5:53 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Wed, May 09, 2012 at 02:20:28PM +0530, Shilimkar, Santosh wrote:
> >> 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.
> 
> > 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.
> 
> > 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.

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

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index dc7e8ce..5ad33a4 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -567,6 +567,12 @@ __armv3_mpu_cache_on:
 		mcr	p15, 0, r0, c7, c0, 0	@ invalidate whole cache v3
 		mov	pc, lr
 
+#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
@@ -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
-#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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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

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

[Buckley, Bryan]

On Wed, May 9, 2012 at 10:48 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
>
> On Wed, May 09, 2012 at 06:00:10PM +0530, Shilimkar, Santosh wrote:
> > On Wed, May 9, 2012 at 5:53 PM, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> > > On Wed, May 09, 2012 at 02:20:28PM +0530, Shilimkar, Santosh wrote:
> > >> 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.
> >
> > > 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.
> >
> > > 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.
>

Solves the issue for OMAP5. Thanks Russel and company.

> ?arch/arm/boot/compressed/head.S | ? 29 ++++++++++++++++++-----------
> ?1 files changed, 18 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index dc7e8ce..5ad33a4 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -567,6 +567,12 @@ __armv3_mpu_cache_on:
> ? ? ? ? ? ? ? ?mcr ? ? p15, 0, r0, c7, c0, 0 ? @ invalidate whole cache v3
> ? ? ? ? ? ? ? ?mov ? ? pc, lr
>
> +#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
> @@ -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
> -#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
> @@ -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
> @@ -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
> @@ -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
> @@ -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
> @@ -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
> @@ -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

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

[Russell King - ARM Linux]

On Wed, May 09, 2012 at 03:44:08PM -0500, Buckley, Bryan wrote:
> On Wed, May 9, 2012 at 10:48 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> >
> > On Wed, May 09, 2012 at 06:00:10PM +0530, Shilimkar, Santosh wrote:
> > > On Wed, May 9, 2012 at 5:53 PM, Russell King - ARM Linux
> > > <linux@arm.linux.org.uk> wrote:
> > > > On Wed, May 09, 2012 at 02:20:28PM +0530, Shilimkar, Santosh wrote:
> > > >> 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.
> > >
> > > > 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.
> > >
> > > > 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.
> >
> 
> Solves the issue for OMAP5. Thanks Russel and company.

Can I add this attributation for this patch:

Tested-by: Bryan Buckley <bryan.buckley@ti.com>

?

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

[Santosh Shilimkar]

On Wednesday 09 May 2012 09:18 PM, Russell King - ARM Linux wrote:
> On Wed, May 09, 2012 at 06:00:10PM +0530, Shilimkar, Santosh wrote:
>> On Wed, May 9, 2012 at 5:53 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>> On Wed, May 09, 2012 at 02:20:28PM +0530, Shilimkar, Santosh wrote:
>>>> 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.
>>
>>> 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.
>>
>>> 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.
> 
Yes it does.
Are you planning to merge below patch as is or split
the patch like 1) Refactoring 2) ARMv7 fix

Either is fine with me.

Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

Regards
Santosh

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

[Russell King - ARM Linux]

On Thu, May 10, 2012 at 12:41:35PM +0530, Santosh Shilimkar wrote:
> 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.)

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

[Santosh Shilimkar]

On Thursday 10 May 2012 02:23 PM, Russell King - ARM Linux wrote:
> On Thu, May 10, 2012 at 12:41:35PM +0530, Santosh Shilimkar wrote:
>> 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.)

Fine with me.

Regards
santosh

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

[Buckley, Bryan]

On Wed, May 9, 2012 at 4:40 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
>
> On Wed, May 09, 2012 at 03:44:08PM -0500, Buckley, Bryan wrote:
> > On Wed, May 9, 2012 at 10:48 AM, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> > >
> > > On Wed, May 09, 2012 at 06:00:10PM +0530, Shilimkar, Santosh wrote:
> > > > On Wed, May 9, 2012 at 5:53 PM, Russell King - ARM Linux
> > > > <linux@arm.linux.org.uk> wrote:
> > > > > On Wed, May 09, 2012 at 02:20:28PM +0530, Shilimkar, Santosh wrote:
> > > > >> 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.
> > > >
> > > > > 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.
> > > >
> > > > > 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.
> > >
> >
> > Solves the issue for OMAP5. Thanks Russel and company.
>
> Can I add this attributation for this patch:
>
> Tested-by: Bryan Buckley <bryan.buckley@ti.com>
>
> ?

If still applicable, yes that is fine.