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

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

On Tue, Jan 18, 2011 at 04:44:52PM +0200, Kirill A. Shutemov wrote:
> On Tue, Jan 18, 2011 at 02:40:14PM +0000, Russell King - ARM Linux wrote:
> > On Tue, Jan 18, 2011 at 04:30:41PM +0200, Kirill A. Shutemov wrote:
> > > On Mon, Jan 17, 2011 at 07:20:50PM +0000, Russell King - ARM Linux wrote:
> > > > This patch series reworks the ARMv6/ARMv6K support options, code
> > > > selection, and bit operations such that it's possible to safely
> > > > build a kernel which supports ARMv6, ARMv6K, ARMv7 and ARMv7 SMP
> > > > in one image.
> > > 
> > > Is it posible to implement CPU_ARCH_ARMv6K as well for runtime checks?
> > 
> > Err what?  There's no CPU_ARCH_ARMv6K.
> 
> I some cases we need runtime check for K extention (see exceptions_init())
> Is there any facility for it?

From what I can tell there's no hard and fast way to say at runtime
"this CPU has K extensions" as it appears possible from the ARM ARM to
have a CPU which is ARMv6K (eg, the CPU in Dove) which does not support
SMP.  Whether that identifies itself as ARMv6 in the architecture field
of the main ID register, or uses the new CPUID scheme is not clear.
If it identifies itself as ARMv6, then there's no CPUID registers to
detect what it supports.

If it's the new CPUID scheme, while we can tell that a CPU has CLREX
support, that doesn't necessary mean that it has the access fault stuff.
That just means that a greater range of exclusive operations are
supported.

Also:

| An implementation that provides hardware management of the access flag:
| • does not generate Access Flag faults when the access flag is enabled
| ...

So, if we don't enable the access flag support, then we shouldn't see
them (we don't enable them.)

What's more:

| Memory Model Feature Register 2 (ID_MMFR2)
| HW access flag, bits [31:28]
| Indicates support for a Hardware access flag, as part of the VMSAv7 implementation.
| Permitted values are:
| 0b0000 Not supported.
| 0b0001 Support for VMSAv7 access flag, updated in hardware.

That doesn't suggest that it's valid to assume that this will be '1' on
ARMv6K - and istr there's some subtle differences between the various
CPUID registers for different architectures as well - to make the CPUID
scheme just that little more complicated to use, so these bits may not
even be defined that way for ARMv6K.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html