Thread (126 messages) 126 messages, 10 authors, 2011-02-18
STALE5584d
Revisions (9)
  1. v1 [diff vs current]
  2. v1 [diff vs current]
  3. v1 [diff vs current]
  4. v1 [diff vs current]
  5. v1 [diff vs current]
  6. v1 current
  7. v1 [diff vs current]
  8. v1 [diff vs current]
  9. v1 [diff vs current]

[PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels

From: Russell King - ARM Linux <hidden>
Date: 2011-02-09 16:44:41
Also in: linux-omap
Subsystem: arm port, the rest · Maintainers: Russell King, Linus Torvalds

On Wed, Feb 09, 2011 at 04:32:04PM +0000, Russell King - ARM Linux wrote:
On Wed, Feb 09, 2011 at 08:24:21AM -0800, Tony Lindgren wrote:
quoted
* Santosh Shilimkar [off-list ref] [110209 01:59]:
quoted
quoted
From: Dave Martin [mailto:dave.martin at linaro.org]

You could also have a "v7+" unified kernel -- i.e., supporting
OMAP3+4+SMP.
This is what we currently do in Linaro, since we're focusing on v7
and above.
This sounds good way forward considering future OMAP architectures
as well.

But I let Tony comment on this idea.
AFAIK these issues will be hopefully sorted out by the time the
next merge window opens. For the -rc cycle, disabling SMP in
config if ARMv6 is selected should do the trick.
That's not soo easy - as we don't know in the Kconfig whether we include
ARMv6 rather than ARMv6K.  It's exactly the same problem I ran into which
inflated the v6v7 patchset.

Maybe the best thing to do is:

config CPU_32v6K
        bool "Support ARM V6K processor extensions" if !SMP
        depends on CPU_V6 || CPU_V7
        default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)

drop the ' && !(ARCH_MX3 || ARCH_OMAP2)' and just let people run into the
resulting undefined instruction traps if they try to run the kernel on
V6 non-K hardware.  Not ideal, but I don't see any other 'simple' solution
to this.
Right, this is what I propose.  Merging this will cause conflicts with
the v6v7 patchset.

8<-----
Subject: [PATCH] ARM: Avoid building unsafe kernels on OMAP2 and MX3

OMAP2 (armv6) and MX3 turn off support for the V6K instructions, which
when they include support for SMP kernels means that the resulting
kernel is unsafe on SMP and can result in corrupted filesystems as we
end up using unsafe bitops.

Re-enable the use of V6K instructions on such kernels, and let such
kernels running on V6 CPUs eat undefined instruction faults which will
be much safer than filesystem corruption.  Next merge window we can fix
this properly (as it requires a much bigger set of changes.)

Signed-off-by: Russell King <redacted>
---
 arch/arm/mm/Kconfig |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 9d30c6f..c9d2d56 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -405,7 +405,7 @@ config CPU_V6
 config CPU_32v6K
 	bool "Support ARM V6K processor extensions" if !SMP
 	depends on CPU_V6 || CPU_V7
-	default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
+	default y if SMP
 	help
 	  Say Y here if your ARMv6 processor supports the 'K' extension.
 	  This enables the kernel to use some instructions not present
@@ -416,7 +416,7 @@ config CPU_32v6K
 # ARMv7
 config CPU_V7
 	bool "Support ARM V7 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX
-	select CPU_32v6K if !ARCH_OMAP2
+	select CPU_32v6K
 	select CPU_32v7
 	select CPU_ABRT_EV7
 	select CPU_PABRT_V7
-- 
1.6.2.5
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help