This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: [Patch ARM] Fix up some issues with init-cpu code in T32 state.
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Ramana Radhakrishnan <ramrad01 at arm dot com>
- Cc: "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Mon, 14 Oct 2013 16:16:19 +0100
- Subject: Re: [Patch ARM] Fix up some issues with init-cpu code in T32 state.
- Authentication-results: sourceware.org; auth=none
- References: <5256710A dot 6030406 at arm dot com>
On 10/10/13 10:19, Ramana Radhakrishnan wrote:
> Hi,
>
> This fixes up some issues uncovered while building the cpu-init code in
> a default T32 state, apparently the cpu-init code was always only built
> in ARM state and not T32 state which is strange. Additionally it wasn't
> always built for the right multilib sometimes and I tracked that down to
> the CPU_INIT_OBJS rule in the makefile.in fragment not having the right
> CFLAGS.
>
> * Turn rdimon-aem.S into an empty file for M class cores.
> * Additionally not call _rdimon_hw_init_hook from crt0.S
> * Force everything into ARM state anyway as it really doesn't matter.
>
> <DATE> Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>
>
> * libgloss/arm/cpu-init/rdimon-aem.S: Disable for M class cores.
> * libgloss/arm/crt0.S: Don't call _rdimon_hw_init_hook for non-A class
> cores.
> * libgloss/arm/cpu-init/Makefile.in (CPU_INIT_OBJS): Use CFLAGS.
>
>
> Tested on arm-none-eabi with a set of multilibs with no regressions and
> Joey confirms that it fixes his issues.
>
> Ok ? if so can someone commit this for me please ?
>
I've put this in. For next time, libgloss has its own ChangeLog file,
so libgloss/ as a prefix is not needed.
R.