Re: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
On Wed, May 9, 2012 at 4:40 PM, Russell King - ARM Linux li...@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 li...@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 li...@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.buck...@ti.com ? If still applicable, yes that is fine. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
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 li...@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.shilim...@ti.com Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
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.) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
On Wed, May 9, 2012 at 3:25 AM, Russell King - ARM Linux li...@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.sricha...@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.sricha...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Catalin Marinas catalin.mari...@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, #0x1000@ 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
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 li...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
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. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
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 li...@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, #0x1000@ 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, #0xfffd @ 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 @@
Re: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
On Wed, May 9, 2012 at 10:48 AM, Russell King - ARM Linux li...@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 li...@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, #0x1000 @ 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 +
Re: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
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 li...@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 li...@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.buck...@ti.com ? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
On Mon, May 07, 2012 at 02:42:29PM +0100, Santosh Shilimkar wrote: From: R Sricharan r.sricha...@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.sricha...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Catalin Marinas catalin.mari...@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, #0x1000@ 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
On Tue, May 8, 2012 at 6:11 PM, Catalin Marinas catalin.mari...@arm.com wrote: On Mon, May 07, 2012 at 02:42:29PM +0100, Santosh Shilimkar wrote: From: R Sricharan r.sricha...@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.sricha...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Catalin Marinas catalin.mari...@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, #0x1000 @ 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.sricha...@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.sricha...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Catalin Marinas catalin.mari...@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, #0x1000@ a reasonable RAM size - mov r1, #0x12 + mov r1, #0x02 @ Default executable section orr r1, r1, #3 10 add r2, r3, #16384 1: cmp
Re: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
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.sricha...@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.sricha...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Catalin Marinas catalin.mari...@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, #0x1000@ 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
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.sricha...@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.sricha...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Catalin Marinas catalin.mari...@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, #0x1000@ 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
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.sricha...@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.sricha...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Catalin Marinas catalin.mari...@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, #0x1000@ 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
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. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@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.
From: R Sricharan r.sricha...@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.sricha...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Catalin Marinas catalin.mari...@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, #0x1000@ 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
