[PATCH] ARM: zImage: add support for ARMv7-M
Catalin Marinas
catalin.marinas at arm.com
Fri Sep 19 06:35:55 PDT 2014
On Fri, Sep 19, 2014 at 01:40:41PM +0100, Joachim Eastwood wrote:
> On 19 September 2014 12:33, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > On Thu, Sep 18, 2014 at 07:34:47PM +0100, Joachim Eastwood wrote:
> >> On 18 September 2014 19:38, Arnd Bergmann <arnd at arndb.de> wrote:
> >> > On Thursday 18 September 2014, Joachim Eastwood wrote:
> >> >> ARM( mov pc, r4 ) @ call kernel
> >> >> - THUMB( bx r4 ) @ entry point is always ARM
> >> >> +#ifdef CONFIG_CPU_V7M
> >> >> + add r4, r4, #1 @ enter in Thumb mode for ARMv7M
> >> >> +#endif
> >> >> + THUMB( bx r4 ) @ entry point is always ARM for non ARMv7M CPUs
> >> >>
> >> >
> >> > I think it would be much nicer to avoid sprinkling #ifdefs here. We already
> >> > have the ARM() and THUMB() macros to deal with the two cases we support, which
> >> > are booting in ARM mode vs ARMv7-A with THUMB2 mode. We can probably add
> >> > another macro like this to deal with the ARMv7-M case that does not have
> >> > ARM mode.
> >>
> >> Well, I guess I could make a THUMBONLY macro or something like that.
> >> But I think that the macro would only be useful in the case you quoted
> >> above. The other ifdefs in the patch are either for large blocks or
> >> removing code. So I don't think it would improve the patch a great
> >> deal.
> >>
> >> btw, do you have better name suggestion than THUMBONLY?
> >
> > It looks like you would need the reverse as well, !THUMBONLY. What about
> > M_CLASS and A_CLASS (with or without underscore and maybe AR_CLASS if we
> > ever need to differentiate between A and R)?
>
> Yes, that would remove more of the ifdefs.
> With M_CLASS/A_CLASS macros I could also wrap ".arch armv7-m" and
> ".arm" directives. But A_CLASS might look a bit strange when used for
> ARM CPUs that are not called Cortex.
'A' in this context does not refer to Cortex CPUs. The ARM Architecture
Reference Class defines three classes:
A - Application class (MMU)
R - Real-time class (no MMU, usually with an MPU, more deterministic)
M - Microcontroller class (no MMU, simpler exception model aimed at bare
metal applications)
The A and R class are covered by the same ARM ARM book while the M class
has a separate reference manual. That's why for some macros were we
target both A and R classes I suggested AR_CLASS.
--
Catalin
More information about the linux-arm-kernel
mailing list