On 25 November 2014 at 19:58, Liviu Ionescu <i...@livius.net> wrote:
> As mentioned in a previous message, I started work on a more detailed
> implementation for the M profile.
>
> At first I defined in target-arm/cpu.c the cpu-s for all variants
> (M0/M0+/M1/M3/M4/M7).
>
> /* Cortex-M cores. Currently only M3 is tested and fully functional. */
> { .name = "cortex-m0", .initfn = cortex_m0_initfn,
> .class_init = arm_v6m_class_init },
> { .name = "cortex-m0p", .initfn = cortex_m0p_initfn,
> .class_init = arm_v6m_class_init },
> { .name = "cortex-m1", .initfn = cortex_m1_initfn,
> .class_init = arm_v6m_class_init },
> { .name = "cortex-m3", .initfn = cortex_m3_initfn,
> .class_init = arm_v7m_class_init },
> { .name = "cortex-m4", .initfn = cortex_m4_initfn,
> .class_init = arm_v7m_class_init },
> { .name = "cortex-m7", .initfn = cortex_m7_initfn,
> .class_init = arm_v7m_class_init },
>
> The proper flags might still need adjustments, but at least we have a
> starting point.
I would recommend concentrating on one of these and getting
it right, rather than defining five new cores and dozens
of MCUs none of which are actually implemented to their
specifications.
> According to my tests, the core initialisations are enough
> to run a simple SysTick timer application.
This just means that code that doesn't really care what
CPU it runs on will run on a CPU that claims to be an
M0/M4/M7 but is actually more or less an M3. If your
code really doesn't care then just run it on our
existing Cortex-M3 CPU.
Patches which can be integrated into mainline will need
to make a reasonable attempt at implementing the actual
correct functionality of whichever CPU you pick (either
adding the extra features in an M4 or cutting out
the features which don't exist in v6M).
I'd also strongly prefer not to implement three dozen
boards unless we really need them all. Again, start
with one and implement a decent subset of the devices
it has on it.
thanks
-- PMM
