ARM: imx6: fix v7_invalidate_l1 by adding I-Cache invalidation
Subsystems (3)
PATCH 1/1 ARM: imx6: fix v7_invalidate_l1 by adding I-Cache invalidation
The recent suspend/resume and reset testing on imx6q discovers that not only D-Cache but also I-Cache has random data and validity when the core comes out of a power recycle.
This patch adds I-Cache invalidation into v7_invalidate_l1 to make sure both D-Cache and I-Cache invalidated on power-up.
--- arch/arm/mach-imx/head-v7.S | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
arch/arm/mach-imx/head-v7.S +1 -0
@@ -33,6 +33,7 @@ */ ENTRY(v7_invalidate_l1) mov r0, #0 + mcr p15, 0, r0, c7, c5, 0 @ invalidate I cache mcr p15, 2, r0, c0, c0, 0 mrc p15, 1, r0, c0, c0, 0
Signature · 1 line
1.7.4.1
PATCH 1/1 ARM: imx6: fix v7_invalidate_l1 by adding I-Cache invalidation
2011/12/30 Shawn Guo <[email protected]>:
Quoted 17 lines
The recent suspend/resume and reset testing on imx6q discovers that not only D-Cache but also I-Cache has random data and validity when the core comes out of a power recycle.
This patch adds I-Cache invalidation into
v7_invalidate_l1to make sure both D-Cache and I-Cache invalidated on power-up.Signed-off-by Shawn Guo <[email protected]>---
?arch/arm/mach-imx/head-v7.S | ? ?1 +
?1 files changed, 1 insertions(+), 0 deletions(-)arch/arm/mach-imx/head-v7.S +0
-0@@ -33,6 +33,7 @@
Quoted 6 lines
?*/
?ENTRY(v7_invalidate_l1)
? ? ? ?mov ? ? r0, #0
+ ? ? ? mcr ? ? p15, 0, r0, c7, c5, 0 ? @ invalidate I cache ? ? ? ?mcr ? ? p15, 2, r0, c0, c0, 0
? ? ? ?mrc ? ? p15, 1, r0, c0, c0, 0
I'm wondering why arm linux init core code does not try to invalidate i/d-cache before enable it?
As a formal procedure, we need invalidate i/d cache before actually enable it. right?
I looked the code: arch/arm/mm/proc-v7.S:
#ifdef HARVARD_CACHE
mcr p15, 0, r10, c7, c5, 0 @ I+BTB cache invalidate
#endif
dsb
#ifdef CONFIG_MMU
mcr p15, 0, r10, c8, c7, 0 @ invalidate I + D TLBs
mcr p15, 0, r10, c2, c0, 2 @ TTB control register
ALT_SMP(orr r4, r4, #TTB_FLAGS_SMP)
ALT_UP(orr r4, r4, #TTB_FLAGS_UP)
mcr p15, 0, r4, c2, c0, 1 @ load TTB1It seems that it will try to invalidate when HARVARD_CACHE define. But HARVARD_CACHE
only defined in v6, why?
Jason Liu
Quoted 9 lines
--
1.7.4.1_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 1/1 ARM: imx6: fix v7_invalidate_l1 by adding I-Cache invalidation
Quoted 13 lines · Jason Liu
2011/12/30 Shawn Guo <[email protected]>:
Quoted 12 lines
The recent suspend/resume and reset testing on imx6q discovers that not only D-Cache but also I-Cache has random data and validity when the core comes out of a power recycle.
This patch adds I-Cache invalidation into
v7_invalidate_l1to make sure both D-Cache and I-Cache invalidated on power-up.Signed-off-by Shawn Guo <[email protected]>---
?arch/arm/mach-imx/head-v7.S | ? ?1 +
?1 files changed, 1 insertions(+), 0 deletions(-)
Quoted 16 lines
Quoted 11 lines
arch/arm/mach-imx/head-v7.S +0
-0@@ -33,6 +33,7 @@?*/
?ENTRY(v7_invalidate_l1)
? ? ? ?mov ? ? r0, #0
+ ? ? ? mcr ? ? p15, 0, r0, c7, c5, 0 ? @ invalidate I cache ? ? ? ?mcr ? ? p15, 2, r0, c0, c0, 0
? ? ? ?mrc ? ? p15, 1, r0, c0, c0, 0I'm wondering why arm linux init core code does not try to invalidate i/d-cache before enable it?
As a formal procedure, we need invalidate i/d cache before actually enable it. right?
I was ever told by Russell that ARM_ARM permits that cache holds random data out of a power-up. But I'm not sure if the validity mark can also be randomized. If it can, this issue may need to be addressed in common place, otherwise it's really just a imx6q specific problem.
Regards,
Shawn
Quoted 18 lines
I looked the code:
arch/arm/mm/proc-v7.S:#ifdef
HARVARD_CACHE
mcr p15, 0, r10, c7, c5, 0 @ I+BTB cache invalidate
#endif
dsb#ifdef CONFIG_MMU mcr p15, 0, r10, c8, c7, 0 @ invalidate I + D TLBs mcr p15, 0, r10, c2, c0, 2 @ TTB control register ALT_SMP(orr r4, r4, #TTB_FLAGS_SMP) ALT_UP(orr r4, r4, #TTB_FLAGS_UP) mcr p15, 0, r4, c2, c0, 1 @ load TTB1It seems that it will try to invalidate when
HARVARD_CACHEdefine. ButHARVARD_CACHE
only defined in v6, why?
PATCH 1/1 ARM: imx6: fix v7_invalidate_l1 by adding I-Cache invalidation
Quoted 3 lines · Shawn Guo
I was ever told by Russell that
ARM_ARMpermits that cache holds random data out of a power-up. But I'm not sure if the validity mark can also be randomized.
It's worse than that: the ARM ARM says that some caches may require a CPU specific sequence to initialize them after power-up. It's also implemenation defined whether entries in the cache can be hit while the caches are disabled. I believe that there's nothing mentioned about the state of the validity bits either (which, from my reading, could be in a random state.)
As far as the architecture goes, it doesn't matter provided there is an implementation defined sequence which results in the caches being properly initialized.
I suspect that an implementation which choses to leave the validity bits in a random state _and_ which searches the instruction cache with I=0 in the control register would not be reasonable as each time you power up, you're playing russian roulette with the contents of the I cache interfering with the very first instruction to be executed by the CPU.
However, an implementation which guaranteed that there wouldn't be an I-cache entry at the reset vector, and specified a sequence which would fit inside one cache line, and which had the properties above _would_ conform.
So, this makes for a really interesting situation: by the time we get anywhere near the kernel, it may already be too late to invalidate the caches if it hasn't already been done.
We really need boot loaders to have already initialized the caches. In the case of secondary CPU bringup, it's possible that the secondary CPU may start executing from our trampoline code, and this is why platforms are able to specify their own initial code for this.
PATCH 1/1 ARM: imx6: fix v7_invalidate_l1 by adding I-Cache invalidation
In reply to Jason LiuQuoted 13 lines · Jason Liu
I looked the code:
arch/arm/mm/proc-v7.S:#ifdef
HARVARD_CACHE
mcr p15, 0, r10, c7, c5, 0 @ I+BTB cache invalidate
#endif
dsb#ifdef CONFIG_MMU mcr p15, 0, r10, c8, c7, 0 @ invalidate I + D TLBs mcr p15, 0, r10, c2, c0, 2 @ TTB control register ALT_SMP(orr r4, r4, #TTB_FLAGS_SMP) ALT_UP(orr r4, r4, #TTB_FLAGS_UP) mcr p15, 0, r4, c2, c0, 1 @ load TTB1
Quoted 2 lines
It seems that it will try to invalidate when
HARVARD_CACHEdefine. ButHARVARD_CACHEonly defined in v6, why?
It's probably a mistake caused when copying proc-v6.S to proc-v7.S and editing it - which I believe is how proc-v7.S was created. Suggest you ask Catalin to find out more details.
PATCH 1/1 ARM: imx6: fix v7_invalidate_l1 by adding I-Cache invalidation
Quoted 14 lines · Russell King - ARM Linux
Quoted 13 lines · Jason Liu
I looked the code:
arch/arm/mm/proc-v7.S:#ifdef
HARVARD_CACHE
mcr p15, 0, r10, c7, c5, 0 @ I+BTB cache invalidate
#endif
dsb#ifdef CONFIG_MMU mcr p15, 0, r10, c8, c7, 0 @ invalidate I + D TLBs mcr p15, 0, r10, c2, c0, 2 @ TTB control register ALT_SMP(orr r4, r4, #TTB_FLAGS_SMP) ALT_UP(orr r4, r4, #TTB_FLAGS_UP) mcr p15, 0, r4, c2, c0, 1 @ load TTB1
Quoted 6 lines
Quoted 2 lines
It seems that it will try to invalidate when
HARVARD_CACHEdefine. ButHARVARD_CACHEonly defined in v6, why?It's probably a mistake caused when copying
proc-v6.Stoproc-v7.Sand editing it - which I believe is howproc-v7.Swas created. Suggest you ask Catalin to find out more details.
It looks like a bug that has been around for nearly 5 years.
Signature · 1 line
Catalin
PATCH 1/1 ARM: proc-v7: remove harvard cache stuff
The harvard cache related comment and code in proc-v7.S were copied from proc-v6.S by mistake, so let's remove them.
--- arch/arm/mm/proc-v7.S | 7 ------- 1 files changed, 0 insertions(+), 7 deletions(-)
arch/arm/mm/proc-v7.S +0 -7
@@ -271,10 +271,6 @@ ENDPROC(cpu_v7_do_resume) * Initialise TLB, Caches, and MMU state ready to switch the MMU * on. Return in r0 the new CP15 C1 control register setting. * - * We automatically detect if we have a Harvard cache, and use the - * Harvard cache control instructions insead of the unified cache - * control instructions. - * * This should be able to cover all ARMv7 cores. * * It is assumed that:
@@ -373,9 +369,6 @@ __v7_setup: #endif 3: mov r10, #0 -#ifdef HARVARD_CACHE - mcr p15, 0, r10, c7, c5, 0 @ I+BTB cache invalidate -#endif dsb #ifdef CONFIG_MMU mcr p15, 0, r10, c8, c7, 0 @ invalidate I + D TLBs
Signature · 1 line
1.7.4.1
PATCH 1/1 ARM: proc-v7: remove harvard cache stuff
Quoted 42 lines · Shawn Guo
The harvard cache related comment and code in
proc-v7.Swere copied fromproc-v6.Sby mistake, so let's remove them.Signed-off-by Shawn Guo <[email protected]>--- arch/arm/mm/proc-v7.S | 7 ------- 1 files changed, 0 insertions(+), 7 deletions(-)arch/arm/mm/proc-v7.S +0
-8@@ -271,10 +271,6 @@ ENDPROC(cpu_v7_do_resume) * Initialise TLB, Caches, and MMU state ready to switch the MMU * on. Return in r0 the new CP15 C1 control register setting. * - * We automatically detect if we have a Harvard cache, and use the - * Harvard cache control instructions insead of the unified cache - * control instructions. - * * This should be able to cover all ARMv7 cores. * * It is assumed that:@@ -373,9 +369,6 @@ __v7_setup: #endif 3: mov r10, #0 -#ifdef HARVARD_CACHE - mcr p15, 0, r10, c7, c5, 0 @ I+BTB cache invalidate -#endif dsb #ifdef CONFIG_MMU mcr p15, 0, r10, c8, c7, 0 @ invalidate I + D TLBs --1.7.4.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 1/1 ARM: proc-v7: remove harvard cache stuff
In reply to Shawn GuoQuoted 24 lines · Shawn Guo
The harvard cache related comment and code in
proc-v7.Swere copied fromproc-v6.Sby mistake, so let's remove them.Signed-off-by Shawn Guo <[email protected]>--- arch/arm/mm/proc-v7.S | 7 ------- 1 files changed, 0 insertions(+), 7 deletions(-)arch/arm/mm/proc-v7.S +0
-4@@ -271,10 +271,6 @@ ENDPROC(cpu_v7_do_resume) * Initialise TLB, Caches, and MMU state ready to switch the MMU * on. Return in r0 the new CP15 C1 control register setting. * - * We automatically detect if we have a Harvard cache, and use the - * Harvard cache control instructions insead of the unified cache - * control instructions. - * * This should be able to cover all ARMv7 cores. * * It is assumed that:
arch/arm/mm/proc-v7.S __v7_setup: · line 378
Quoted 6 lines
arch/arm/mm/proc-v7.S +0
-3@@ -373,9 +369,6 @@ __v7_setup: #endif 3: mov r10, #0 -#ifdef HARVARD_CACHE - mcr p15, 0, r10, c7, c5, 0 @ I+BTB cache invalidate -#endif
I thought we still need to invalidate the I-cache, maybe moving it higher up after the v7_flush_dcache_all call.
Signature · 1 line
Catalin
PATCH 1/1 ARM: proc-v7: remove harvard cache stuff
Quoted 27 lines · Catalin Marinas
Quoted 26 lines · Shawn Guo
The harvard cache related comment and code in
proc-v7.Swere copied fromproc-v6.Sby mistake, so let's remove them.Signed-off-by Shawn Guo <[email protected]>--- arch/arm/mm/proc-v7.S | 7 ------- 1 files changed, 0 insertions(+), 7 deletions(-)arch/arm/mm/proc-v7.S +0
-4@@ -271,10 +271,6 @@ ENDPROC(cpu_v7_do_resume) * Initialise TLB, Caches, and MMU state ready to switch the MMU * on. Return in r0 the new CP15 C1 control register setting. * - * We automatically detect if we have a Harvard cache, and use the - * Harvard cache control instructions insead of the unified cache - * control instructions. - * * This should be able to cover all ARMv7 cores. * * It is assumed that:@@ -373,9 +369,6 @@ __v7_setup: #endif
Quoted 7 lines
arch/arm/mm/proc-v7.S __v7_setup: · line 378
Quoted 4 lines
arch/arm/mm/proc-v7.S +0
-33: mov r10, #0 -#ifdef HARVARD_CACHE - mcr p15, 0, r10, c7, c5, 0 @ I+BTB cache invalidate -#endifI thought we still need to invalidate the I-cache, maybe moving it higher up after the
v7_flush_dcache_allcall.
I agree. Although this does seem to be working without the invalidation, this might just be because everything tends to be shiny when we boot up.
Is anybody planning to follow up on this patch? I can't see it in any of the trees that I'm tracking.
Thanks,
Will