Patchwork ARM: let CPUs not being able to run in ARM mode enter in THUMB mode

login
register
mail settings
Submitter Uwe Kleine-König
Date Jan. 11, 2013, 11:39 a.m.
Message ID <1357904397-8476-1-git-send-email-u.kleine-koenig@pengutronix.de>
Download mbox | patch
Permalink /patch/211311/
State New
Headers show

Comments

Uwe Kleine-König - Jan. 11, 2013, 11:39 a.m.
Some ARM cores are not capable to run in ARM mode (e.g. Cortex-M3). So
obviously these cannot enter the kernel in ARM mode. Make an exception
for them and let them enter in THUMB mode.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
 arch/arm/kernel/head-nommu.S |    8 +++++++-
 arch/arm/kernel/head.S       |    8 +++++++-
 arch/arm/mm/Kconfig          |    6 ++++++
 3 files changed, 20 insertions(+), 2 deletions(-)
Jonathan Austin - Jan. 11, 2013, 3:34 p.m.
Hi Uwe,
On 11/01/13 11:39, Uwe Kleine-König wrote:
> Some ARM cores are not capable to run in ARM mode (e.g. Cortex-M3). So
> obviously these cannot enter the kernel in ARM mode. Make an exception
> for them and let them enter in THUMB mode.

Clearly something like this is necessary, but it isn't something I'd 
like for people to start using *unless* they have a THUMB only CPU (for 
example, to work around dodgy boot-loaders, etc)

Seeing as there are no THUMB-only CPUs with an MMU, I think we could 
safely constrain this change to:
a) depend on !MMU
b) only touch head-nommu.S

Does that cause any issue for what you're doing.

[...]

> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index 3fd629d..bc3150c 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -1,5 +1,11 @@
>   comment "Processor Type"
>
> +# Select this if your CPU doesn't support the 32 bit ARM instructions.
> +config THUMBONLY_CPU
> +	bool
> +	select THUMB2_KERNEL
> +	select ARM_THUMB
> +
>   # Select CPU types depending on the architecture selected.  This selects
>   # which CPUs we support in the kernel image, and the compiler instruction
>   # optimiser behaviour.

Also, a couple of minor questions about this:
- What's the rationale for the placement within the file - it looks a 
bit curious up the top there.
- Given the fact that we don't want people using this except in very 
specific circumstances, should we write a little bit of help for the option?


Jonny
Uwe Kleine-König - Jan. 11, 2013, 3:51 p.m.
Hi Jonny,

On Fri, Jan 11, 2013 at 03:34:39PM +0000, Jonathan Austin wrote:
> Hi Uwe,
> On 11/01/13 11:39, Uwe Kleine-König wrote:
> >Some ARM cores are not capable to run in ARM mode (e.g. Cortex-M3). So
> >obviously these cannot enter the kernel in ARM mode. Make an exception
> >for them and let them enter in THUMB mode.
> 
> Clearly something like this is necessary, but it isn't something I'd
> like for people to start using *unless* they have a THUMB only CPU
> (for example, to work around dodgy boot-loaders, etc)
> 
> Seeing as there are no THUMB-only CPUs with an MMU, I think we could
> safely constrain this change to:
> a) depend on !MMU
> b) only touch head-nommu.S
> 
> Does that cause any issue for what you're doing.
Would be ok for me, too. I don't care much.

> >diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> >index 3fd629d..bc3150c 100644
> >--- a/arch/arm/mm/Kconfig
> >+++ b/arch/arm/mm/Kconfig
> >@@ -1,5 +1,11 @@
> >  comment "Processor Type"
> >
> >+# Select this if your CPU doesn't support the 32 bit ARM instructions.
> >+config THUMBONLY_CPU
> >+	bool
> >+	select THUMB2_KERNEL
> >+	select ARM_THUMB
> >+
> >  # Select CPU types depending on the architecture selected.  This selects
> >  # which CPUs we support in the kernel image, and the compiler instruction
> >  # optimiser behaviour.
> 
> Also, a couple of minor questions about this:
> - What's the rationale for the placement within the file - it looks
> a bit curious up the top there.
Conceptually it's a symbol that is selected by the different processor
symbols. So IMHO it's fine to have it in front of the processor symbols.
Maybe it should even go before the line reading:

	comment "Processor Type"

. OTOH similar symbols (like CPU_32v4, CPU_CP15) are at the end, too.
So yes, probably it's better to move it further down. And maybe rename
it to CPU_THUMBONLY?

> - Given the fact that we don't want people using this except in very
> specific circumstances, should we write a little bit of help for the
> option?
I can move what I wrote in the comment above the symbol into a help text
instead.

Best regards
Uwe
Russell King - ARM Linux - Jan. 11, 2013, 4:07 p.m.
On Fri, Jan 11, 2013 at 12:39:57PM +0100, Uwe Kleine-König wrote:
> +# Select this if your CPU doesn't support the 32 bit ARM instructions.
> +config THUMBONLY_CPU
> +	bool
> +	select THUMB2_KERNEL
> +	select ARM_THUMB

Hmm, not convinced this is the best solution.  Yes, fine for there to be
a THUMBONLY_CPU option, _but_ not the select statements onto user visible
symbols.  We can get this instead by:

config THUMB2_KERNEL
        bool "Compile the kernel in Thumb-2 mode" if !THUMBONLY_CPU
        depends on (CPU_V7 && !CPU_V6 && !CPU_V6K) || THUMBONLY_CPU
	default y if THUMBONLY_CPU
        select AEABI
        select ARM_ASM_UNIFIED
        select ARM_UNWIND

and:

config ARM_THUMB
        bool "Support Thumb user binaries" if !THUMBONLY_CPU
        depends on CPU_ARM720T || CPU_ARM740T || CPU_ARM920T || \
		   CPU_ARM922T || CPU_ARM925T || CPU_ARM926T || \
		   CPU_ARM940T || CPU_ARM946E || CPU_ARM1020 || \
		   CPU_ARM1020E || CPU_ARM1022 || CPU_ARM1026 || \
		   CPU_XSCALE || CPU_XSC3 || CPU_MOHAWK || CPU_V6 || \
		   CPU_V6K || CPU_V7 || CPU_FEROCEON || THUMBONLY_CPU
        default y

And... I'm left wondering - should we have this instead:

config CPU_ARM
	bool

config CPU_THUMB
	bool

which indicates whether the CPU supports the ARM instruction set or the
Thumb instruction set (or both) - that should then allow us to select
those from the individual CPU_xxx options and eliminate that big long
list of dependencies against ARM_THUMB.
Uwe Kleine-König - Jan. 11, 2013, 4:20 p.m.
Hi Russell,

On Fri, Jan 11, 2013 at 04:07:53PM +0000, Russell King - ARM Linux wrote:
> On Fri, Jan 11, 2013 at 12:39:57PM +0100, Uwe Kleine-König wrote:
> > +# Select this if your CPU doesn't support the 32 bit ARM instructions.
> > +config THUMBONLY_CPU
> > +	bool
> > +	select THUMB2_KERNEL
> > +	select ARM_THUMB
> 
> Hmm, not convinced this is the best solution.  Yes, fine for there to be
> a THUMBONLY_CPU option, _but_ not the select statements onto user visible
> symbols.  We can get this instead by:
> 
> config THUMB2_KERNEL
>         bool "Compile the kernel in Thumb-2 mode" if !THUMBONLY_CPU
>         depends on (CPU_V7 && !CPU_V6 && !CPU_V6K) || THUMBONLY_CPU
> 	default y if THUMBONLY_CPU
>         select AEABI
>         select ARM_ASM_UNIFIED
>         select ARM_UNWIND
> 
> and:
> 
> config ARM_THUMB
>         bool "Support Thumb user binaries" if !THUMBONLY_CPU
>         depends on CPU_ARM720T || CPU_ARM740T || CPU_ARM920T || \
> 		   CPU_ARM922T || CPU_ARM925T || CPU_ARM926T || \
> 		   CPU_ARM940T || CPU_ARM946E || CPU_ARM1020 || \
> 		   CPU_ARM1020E || CPU_ARM1022 || CPU_ARM1026 || \
> 		   CPU_XSCALE || CPU_XSC3 || CPU_MOHAWK || CPU_V6 || \
> 		   CPU_V6K || CPU_V7 || CPU_FEROCEON || THUMBONLY_CPU
>         default y
> 
> And... I'm left wondering - should we have this instead:
> 
> config CPU_ARM
> 	bool
> 
> config CPU_THUMB
> 	bool
> 
> which indicates whether the CPU supports the ARM instruction set or the
> Thumb instruction set (or both) - that should then allow us to select
> those from the individual CPU_xxx options and eliminate that big long
> list of dependencies against ARM_THUMB.
I like your idea and I will come up with a patch.

Thanks
Uwe
Jonathan Austin - Jan. 11, 2013, 6 p.m.
Hi Russell, Uwe

On 11/01/13 16:07, Russell King - ARM Linux wrote:
> On Fri, Jan 11, 2013 at 12:39:57PM +0100, Uwe Kleine-König wrote:
>> +# Select this if your CPU doesn't support the 32 bit ARM instructions.
>> +config THUMBONLY_CPU
>> +	bool
>> +	select THUMB2_KERNEL
>> +	select ARM_THUMB
> 
> Hmm, not convinced this is the best solution.  Yes, fine for there to be
> a THUMBONLY_CPU option, _but_ not the select statements onto user visible
> symbols.  We can get this instead by:

I'm curious what it is about having the select statements onto user
visible symbols that isn't good. Is it just that it will manipulate
things underneath the users' feet? 

(I'm not disagreeing! I like your proposal, but when I saw the
original patch this didn't raise flags with me, so I'd like to
understand the reasons)

> config CPU_ARM
> 	bool
> 
> config CPU_THUMB
> 	bool

The only thing I might add is that we don't want people confusing
the selection of THUMB2_KERNEL with exclusively selecting CPU_THUMB
(which should be very rare). The latter would imply the former, but
in almost all cases where THUMB2_KERNEL is selected we should also
have CPU_ARM selected...

However things fall out, I'd still like to be *unable* to use
THUMBONLY_CPU *with* an MMU, as it is a clear sign (at least for the
foreseeable future) that something has been misunderstood.

Jonny
Russell King - ARM Linux - Jan. 11, 2013, 6:12 p.m.
On Fri, Jan 11, 2013 at 06:00:28PM +0000, Jonathan Austin wrote:
> Hi Russell, Uwe
> 
> On 11/01/13 16:07, Russell King - ARM Linux wrote:
> > On Fri, Jan 11, 2013 at 12:39:57PM +0100, Uwe Kleine-König wrote:
> >> +# Select this if your CPU doesn't support the 32 bit ARM instructions.
> >> +config THUMBONLY_CPU
> >> +	bool
> >> +	select THUMB2_KERNEL
> >> +	select ARM_THUMB
> > 
> > Hmm, not convinced this is the best solution.  Yes, fine for there to be
> > a THUMBONLY_CPU option, _but_ not the select statements onto user visible
> > symbols.  We can get this instead by:
> 
> I'm curious what it is about having the select statements onto user
> visible symbols that isn't good. Is it just that it will manipulate
> things underneath the users' feet? 

Consider this: you run make xconfig (or whatever config tool you
prefer).  You're presented with an option, which you want to disable.
It says the possible values for it are 'Y' (n and m are not possible).

So, you start to wonder why this is - why you're even being presented
with an option where it only has one allowable state.  That's not an
option, that's an ultimatum!

Now, you ask the config tool for the reason why the symbol is selected.
It gives you a big long list of dependencies - I've seen some of these
which are over 50 lines long.  A complex nest of options which are &&
and ||'d together.  You've no clue which one(s) result in the symbol
being selected.

So, the presentation of that symbol is nothing more than pure noise
and in some cases just leads to frustration at not being able to achieve
the configuration that's desired.

> (I'm not disagreeing! I like your proposal, but when I saw the
> original patch this didn't raise flags with me, so I'd like to
> understand the reasons)
> 
> > config CPU_ARM
> > 	bool
> > 
> > config CPU_THUMB
> > 	bool
> 
> The only thing I might add is that we don't want people confusing
> the selection of THUMB2_KERNEL with exclusively selecting CPU_THUMB
> (which should be very rare).

Note: these aren't user visible symbols (note the lack of option text
after 'bool' - that makes them hidden).  Instead, these symbols are
to be selected from the CONFIG_CPU_ARM926T etc symbols - so it's a
choice that the developers are making.

We can also add a "help" stanza to both these to describe what they're
representing, or if people prefer a comment before the option.
Nicolas Pitre - Jan. 12, 2013, 5:19 p.m.
On Fri, 11 Jan 2013, Uwe Kleine-König wrote:

> Hi Jonny,
> 
> On Fri, Jan 11, 2013 at 03:34:39PM +0000, Jonathan Austin wrote:
> > Hi Uwe,
> > On 11/01/13 11:39, Uwe Kleine-König wrote:
> > >Some ARM cores are not capable to run in ARM mode (e.g. Cortex-M3). So
> > >obviously these cannot enter the kernel in ARM mode. Make an exception
> > >for them and let them enter in THUMB mode.
> > 
> > Clearly something like this is necessary, but it isn't something I'd
> > like for people to start using *unless* they have a THUMB only CPU
> > (for example, to work around dodgy boot-loaders, etc)
> > 
> > Seeing as there are no THUMB-only CPUs with an MMU, I think we could
> > safely constrain this change to:
> > a) depend on !MMU
> > b) only touch head-nommu.S
> > 
> > Does that cause any issue for what you're doing.
> Would be ok for me, too. I don't care much.

Please do so then.  I had the same concern.


Nicolas
Uwe Kleine-König - Jan. 14, 2013, 9:50 a.m.
Hello Russell,

On Fri, Jan 11, 2013 at 05:20:16PM +0100, Uwe Kleine-König wrote:
> On Fri, Jan 11, 2013 at 04:07:53PM +0000, Russell King - ARM Linux wrote:
> > On Fri, Jan 11, 2013 at 12:39:57PM +0100, Uwe Kleine-König wrote:
> > > +# Select this if your CPU doesn't support the 32 bit ARM instructions.
> > > +config THUMBONLY_CPU
> > > +	bool
> > > +	select THUMB2_KERNEL
> > > +	select ARM_THUMB
> > 
> > Hmm, not convinced this is the best solution.  Yes, fine for there to be
> > a THUMBONLY_CPU option, _but_ not the select statements onto user visible
> > symbols.  We can get this instead by:
> > 
> > config THUMB2_KERNEL
> >         bool "Compile the kernel in Thumb-2 mode" if !THUMBONLY_CPU
> >         depends on (CPU_V7 && !CPU_V6 && !CPU_V6K) || THUMBONLY_CPU
> > 	default y if THUMBONLY_CPU
> >         select AEABI
> >         select ARM_ASM_UNIFIED
> >         select ARM_UNWIND
> > 
> > and:
> > 
> > config ARM_THUMB
> >         bool "Support Thumb user binaries" if !THUMBONLY_CPU
> >         depends on CPU_ARM720T || CPU_ARM740T || CPU_ARM920T || \
> > 		   CPU_ARM922T || CPU_ARM925T || CPU_ARM926T || \
> > 		   CPU_ARM940T || CPU_ARM946E || CPU_ARM1020 || \
> > 		   CPU_ARM1020E || CPU_ARM1022 || CPU_ARM1026 || \
> > 		   CPU_XSCALE || CPU_XSC3 || CPU_MOHAWK || CPU_V6 || \
> > 		   CPU_V6K || CPU_V7 || CPU_FEROCEON || THUMBONLY_CPU
> >         default y
> > 
> > And... I'm left wondering - should we have this instead:
> > 
> > config CPU_ARM
> > 	bool
> > 
> > config CPU_THUMB
> > 	bool
> > 
> > which indicates whether the CPU supports the ARM instruction set or the
> > Thumb instruction set (or both) - that should then allow us to select
> > those from the individual CPU_xxx options and eliminate that big long
> > list of dependencies against ARM_THUMB.
> I like your idea and I will come up with a patch.
This looks nice and clean, but after having thought about it for a while
it turns out not to be that easy.

For THUMB2_KERNEL only CPUs must be supported that can do Thumb2. That
means the logic must be something like:

	config THUMB2_KERNEL
		bool "Compile the kernel in Thumb-2 mode" if ALL_CONFIGURED_CPUS_SUPPORT_ARM
		depends on ALL_CONFIGURED_CPUS_SUPPORT_THUMB2
		default y if !ALL_CONFIGURED_CPUS_SUPPORT_ARM

for the ALL_CONFIGURED_CPUS_SUPPORT_ARM and .._THUMB2 symbols to do the
right thing, we'd need something like:

	config CPU_32v4
		bool
		...
		select ISA_ARM
		select ISA_THUMB_NONE

	config CPU_32v4T
		bool
		...
		select ISA_ARM
		select ISA_THUMB1
	...
	config CPU_32v7
		bool
		select ISA_ARM
		select ISA_THUMB2

	config CPU_32v7M
		bool
		select ISA_ARM_NONE
		select ISA_THUMB2

	config ALL_CONFIGURED_CPUS_SUPPORT_ARM
		bool
		default ISA_ARM && !ISA_ARM_NONE

	config ALL_CONFIGURED_CPUS_SUPPORT_THUMB2
		bool
		default ISA_THUMB2 && !ISA_THUMB1 && !ISA_THUMB_NONE

which looks less nice than what I thought first.

What do you think? Is it still worthwhile to implement this?

Best regards
Uwe
Dave Martin - Jan. 29, 2013, 12:44 p.m.
On Fri, Jan 11, 2013 at 12:39:57PM +0100, Uwe Kleine-König wrote:
> Some ARM cores are not capable to run in ARM mode (e.g. Cortex-M3). So
> obviously these cannot enter the kernel in ARM mode. Make an exception
> for them and let them enter in THUMB mode.
> 
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
>  arch/arm/kernel/head-nommu.S |    8 +++++++-
>  arch/arm/kernel/head.S       |    8 +++++++-
>  arch/arm/mm/Kconfig          |    6 ++++++
>  3 files changed, 20 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
> index 3782320..ae7ed46 100644
> --- a/arch/arm/kernel/head-nommu.S
> +++ b/arch/arm/kernel/head-nommu.S
> @@ -32,15 +32,21 @@
>   * numbers for r1.
>   *
>   */
> -	.arm
>  
>  	__HEAD
> +
> +#ifdef CONFIG_THUMBONLY_CPU
> +	.thumb
> +ENTRY(stext)
> +#else
> +	.arm
>  ENTRY(stext)
>  
>   THUMB(	adr	r9, BSYM(1f)	)	@ Kernel is always entered in ARM.
>   THUMB(	bx	r9		)	@ If this is a Thumb-2 kernel,
>   THUMB(	.thumb			)	@ switch to Thumb now.
>   THUMB(1:			)
> +#endif

The behaviour is that we start the file is kernel entry state, then
we switch to kernel run state.

The switch is only needed for kernels which run on CPUs supporting
both states, where the run state is not ARM.

So, it would be neater for these entry sequences to look something
like:

HAS_ARM(.arm)	@ because -mthumb is default for Thumb kernels anyway

ENTRY(stext)
HAS_ARM(THUMB(	@ code to switch to Thumb ))

	@ real code starts here, in run state.



Where

#ifdef CONFIG_THUMBONLY_CPU
#define HAS_ARM(x...)
#else
#define HAS_ARM(x...) x
#endif

(I haven't read the whole thread yet, so decisions about what
config variables and macro names should be used may be overridden
by other people...)


Thoughts?

Cheers
---Dave
Uwe Kleine-König - Jan. 31, 2013, 3:51 p.m.
Hello Dave,

On Tue, Jan 29, 2013 at 12:44:27PM +0000, Dave Martin wrote:
> On Fri, Jan 11, 2013 at 12:39:57PM +0100, Uwe Kleine-König wrote:
> > Some ARM cores are not capable to run in ARM mode (e.g. Cortex-M3). So
> > obviously these cannot enter the kernel in ARM mode. Make an exception
> > for them and let them enter in THUMB mode.
> > 
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > ---
> >  arch/arm/kernel/head-nommu.S |    8 +++++++-
> >  arch/arm/kernel/head.S       |    8 +++++++-
> >  arch/arm/mm/Kconfig          |    6 ++++++
> >  3 files changed, 20 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
> > index 3782320..ae7ed46 100644
> > --- a/arch/arm/kernel/head-nommu.S
> > +++ b/arch/arm/kernel/head-nommu.S
> > @@ -32,15 +32,21 @@
> >   * numbers for r1.
> >   *
> >   */
> > -	.arm
> >  
> >  	__HEAD
> > +
> > +#ifdef CONFIG_THUMBONLY_CPU
> > +	.thumb
> > +ENTRY(stext)
> > +#else
> > +	.arm
> >  ENTRY(stext)
> >  
> >   THUMB(	adr	r9, BSYM(1f)	)	@ Kernel is always entered in ARM.
> >   THUMB(	bx	r9		)	@ If this is a Thumb-2 kernel,
> >   THUMB(	.thumb			)	@ switch to Thumb now.
> >   THUMB(1:			)
> > +#endif
> 
> The behaviour is that we start the file is kernel entry state, then
> we switch to kernel run state.
> 
> The switch is only needed for kernels which run on CPUs supporting
> both states, where the run state is not ARM.
> 
> So, it would be neater for these entry sequences to look something
> like:
> 
> HAS_ARM(.arm)	@ because -mthumb is default for Thumb kernels anyway
> 
> ENTRY(stext)
> HAS_ARM(THUMB(	@ code to switch to Thumb ))
> 
> 	@ real code starts here, in run state.
> 
> 
> 
> Where
> 
> #ifdef CONFIG_THUMBONLY_CPU
> #define HAS_ARM(x...)
> #else
> #define HAS_ARM(x...) x
> #endif
> 
> (I haven't read the whole thread yet, so decisions about what
> config variables and macro names should be used may be overridden
> by other people...)
I don't agree on better readability, the result would look like:

		__HEAD

	HAS_ARM(.arm)

		ENTRY(stext)

	HAS_ARM(THUMB(adr	r9, BSYM(1f)	)
	HAS_ARM(THUMB(bx	r9		)
	HAS_ARM(THUMB(.thumb			)
	HAS_ARM(THUMB(1:			)

in contrast to:

		__HEAD

	#ifdef CONFIG_CPU_THUMBONLY
		.thumb
	ENTRY(stext)
	#else
		.arm
	ENTRY(stext)

	 THUMB( adr     r9, BSYM(1f)    )       @ Kernel is always entered in ARM.
	 THUMB( bx      r9              )       @ If this is a Thumb-2 kernel,
	 THUMB( .thumb                  )       @ switch to Thumb now.
	 THUMB(1:                       )
	#endif

(modulo comments and indention maybe). Even though it uses an #ifdef I
consider the latter variant more readable.  Maybe it's only me? Other
than that I'd probably choose a longer name instead of HAS_ARM to make
it more self-documenting what it is about (something with _ISA_ in its
name). This obviously makes readability worse.

So I'm still happy with the version I sent.

Best regards
Uwe
Dave Martin - Feb. 19, 2013, 11:39 a.m.
On Thu, Jan 31, 2013 at 04:51:59PM +0100, Uwe Kleine-König wrote:
> Hello Dave,
> 
> On Tue, Jan 29, 2013 at 12:44:27PM +0000, Dave Martin wrote:
> > On Fri, Jan 11, 2013 at 12:39:57PM +0100, Uwe Kleine-König wrote:
> > > Some ARM cores are not capable to run in ARM mode (e.g. Cortex-M3). So
> > > obviously these cannot enter the kernel in ARM mode. Make an exception
> > > for them and let them enter in THUMB mode.
> > > 
> > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > > ---
> > >  arch/arm/kernel/head-nommu.S |    8 +++++++-
> > >  arch/arm/kernel/head.S       |    8 +++++++-
> > >  arch/arm/mm/Kconfig          |    6 ++++++
> > >  3 files changed, 20 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
> > > index 3782320..ae7ed46 100644
> > > --- a/arch/arm/kernel/head-nommu.S
> > > +++ b/arch/arm/kernel/head-nommu.S
> > > @@ -32,15 +32,21 @@
> > >   * numbers for r1.
> > >   *
> > >   */
> > > -	.arm
> > >  
> > >  	__HEAD
> > > +
> > > +#ifdef CONFIG_THUMBONLY_CPU
> > > +	.thumb
> > > +ENTRY(stext)
> > > +#else
> > > +	.arm
> > >  ENTRY(stext)
> > >  
> > >   THUMB(	adr	r9, BSYM(1f)	)	@ Kernel is always entered in ARM.
> > >   THUMB(	bx	r9		)	@ If this is a Thumb-2 kernel,
> > >   THUMB(	.thumb			)	@ switch to Thumb now.
> > >   THUMB(1:			)
> > > +#endif
> > 
> > The behaviour is that we start the file is kernel entry state, then
> > we switch to kernel run state.
> > 
> > The switch is only needed for kernels which run on CPUs supporting
> > both states, where the run state is not ARM.
> > 
> > So, it would be neater for these entry sequences to look something
> > like:
> > 
> > HAS_ARM(.arm)	@ because -mthumb is default for Thumb kernels anyway
> > 
> > ENTRY(stext)
> > HAS_ARM(THUMB(	@ code to switch to Thumb ))
> > 
> > 	@ real code starts here, in run state.
> > 
> > 
> > 
> > Where
> > 
> > #ifdef CONFIG_THUMBONLY_CPU
> > #define HAS_ARM(x...)
> > #else
> > #define HAS_ARM(x...) x
> > #endif
> > 
> > (I haven't read the whole thread yet, so decisions about what
> > config variables and macro names should be used may be overridden
> > by other people...)
> I don't agree on better readability, the result would look like:
> 
> 		__HEAD
> 
> 	HAS_ARM(.arm)
> 
> 		ENTRY(stext)
> 
> 	HAS_ARM(THUMB(adr	r9, BSYM(1f)	)
> 	HAS_ARM(THUMB(bx	r9		)
> 	HAS_ARM(THUMB(.thumb			)
> 	HAS_ARM(THUMB(1:			)
> 
> in contrast to:
> 
> 		__HEAD
> 
> 	#ifdef CONFIG_CPU_THUMBONLY
> 		.thumb
> 	ENTRY(stext)
> 	#else
> 		.arm
> 	ENTRY(stext)
> 
> 	 THUMB( adr     r9, BSYM(1f)    )       @ Kernel is always entered in ARM.
> 	 THUMB( bx      r9              )       @ If this is a Thumb-2 kernel,
> 	 THUMB( .thumb                  )       @ switch to Thumb now.
> 	 THUMB(1:                       )
> 	#endif
> 
> 
> (modulo comments and indention maybe). Even though it uses an #ifdef I
> consider the latter variant more readable.  Maybe it's only me? Other
> than that I'd probably choose a longer name instead of HAS_ARM to make
> it more self-documenting what it is about (something with _ISA_ in its
> name). This obviously makes readability worse.

Well, maybe so.

Note that Thumb is also the default instruction set for any Thumb-2
kernel; that's why we needed .arm in the first place.


We could turn the switch to Thumb into a macro in assembler.h -- that's
actually needed elsewhere:

#if defined(CONFIG_THUMB2_KERNEL) && !defined(CONFIG_CPU_THUMBONLY)

.macro entry_isa
	.arm
.endm

.macro switch_to_kernel_isa rtemp
 THUMB(		adr	\rtemp, BSYM(9999f)	)
 THUMB(		bx	\rtemp			)
 THUMB(		.thumb				)
 THUMB(	9999:					)
.endm

#else

.macro entry_isa
.endm
.macro switch_to_kernel_isa rtemp
.endm

#endif


Then head.S becomes

	__HEAD

	entry_isa

ENTRY(stext)
	switch_to_kernel_isa r9



The macros can be reused in the zImage decompressor, the mcpm low-level
entry point and possibly elsewhere.

What do you think?

Cheers
---Dave

Patch

diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
index 3782320..ae7ed46 100644
--- a/arch/arm/kernel/head-nommu.S
+++ b/arch/arm/kernel/head-nommu.S
@@ -32,15 +32,21 @@ 
  * numbers for r1.
  *
  */
-	.arm
 
 	__HEAD
+
+#ifdef CONFIG_THUMBONLY_CPU
+	.thumb
+ENTRY(stext)
+#else
+	.arm
 ENTRY(stext)
 
  THUMB(	adr	r9, BSYM(1f)	)	@ Kernel is always entered in ARM.
  THUMB(	bx	r9		)	@ If this is a Thumb-2 kernel,
  THUMB(	.thumb			)	@ switch to Thumb now.
  THUMB(1:			)
+#endif
 
 	setmode	PSR_F_BIT | PSR_I_BIT | SVC_MODE, r9 @ ensure svc mode
 						@ and irqs disabled
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 4eee351..0af2749 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -73,15 +73,21 @@ 
  * crap here - that's what the boot loader (or in extreme, well justified
  * circumstances, zImage) is for.
  */
-	.arm
 
 	__HEAD
+
+#ifdef CONFIG_THUMBONLY_CPU
+	.thumb
+ENTRY(stext)
+#else
+	.arm
 ENTRY(stext)
 
  THUMB(	adr	r9, BSYM(1f)	)	@ Kernel is always entered in ARM.
  THUMB(	bx	r9		)	@ If this is a Thumb-2 kernel,
  THUMB(	.thumb			)	@ switch to Thumb now.
  THUMB(1:			)
+#endif
 
 #ifdef CONFIG_ARM_VIRT_EXT
 	bl	__hyp_stub_install
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 3fd629d..bc3150c 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -1,5 +1,11 @@ 
 comment "Processor Type"
 
+# Select this if your CPU doesn't support the 32 bit ARM instructions.
+config THUMBONLY_CPU
+	bool
+	select THUMB2_KERNEL
+	select ARM_THUMB
+
 # Select CPU types depending on the architecture selected.  This selects
 # which CPUs we support in the kernel image, and the compiler instruction
 # optimiser behaviour.