| Message ID | 1357904397-8476-1-git-send-email-u.kleine-koenig@pengutronix.de |
|---|---|
| State | New |
| Headers | show |
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
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
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.
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
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
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.
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
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
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
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
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
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.
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(-)