Skip to content

Fix issues with ARMv6+v6k+v7 kernels

Tony Lindgren linux-arm-kernel linux-omap 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest0 of 14 patches 0 repliesNew

Patches in v1 No applies recorded yet

None of the 14 patches the cover letter announces are in this archive.

Reviews trailers per patch

PatchTony Lindgren
SeriesA-b

Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.

Read the v1 thread

Cover letter [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
Quoted 31 lines · Nicolas Pitre
Quoted 29 lines · Russell King - ARM Linux
Quoted 8 lines · Tony Lindgren
Quoted 7 lines · Santosh Shilimkar
Quoted 7 lines

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.

Quoted 8 lines
Quoted 4 lines

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)
Quoted 8 lines
Quoted 4 lines

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.

This should be good enough. We're looking for a temporary stopgate solution to prevent people from corrupting their data, and the real fix will be available in the next kernel.

OK. This patch will be needed anyways for the real fixes. And no temporary apply-undo type patching needed. The only drawback is that omap2420 and 2430 won't boot with omap2plus_defconfig, but that will be only for a few weeks.