Re: [PATCH 1/6] ARM: stm32: prepare stm32 family to welcome armv7 architecture

[Ludovic BARRE]

Hi all

-This patch serie hasn't goal to create a platform with
asymmetric linux processor (like vf610).

-Today, STM32 family have several boards with mcu microcontroler
Cortex-M like stm32f429, stm32f746...
And this patch serie prepare new board with support of Cortex-A
instead-of Cortex-M. (that's all)

BR
Ludo

On 12/12/2017 12:03 PM, afzal mohammed wrote:
> Hi,
>
> On Mon, Dec 11, 2017 at 02:40:43PM +0100, Arnd Bergmann wrote:
> > On Mon, Dec 11, 2017 at 11:25 AM, Linus Walleij
>
> > > > This patch prepares the STM32 machine for the integration of Cortex-A
> > > > based microprocessor (MPU), on top of the existing Cortex-M
> > > > microcontroller family (MCU). Since both MCUs and MPUs are sharing
> > > > common hardware blocks we can keep using ARCH_STM32 flag for most of
> > > > them. If a hardware block is specific to one family we can use either
> > > > ARCH_STM32_MCU or ARCH_STM32_MPU flag.
>
> > To what degree do we need to treat them as separate families
> > at all then? I wonder if the MCU/MPU distinction is always that
> > clear along the Cortex-M/Cortex-A separation,
>
> > What
> > exactly would we miss if we do away with the ARCH_STM32_MCU
> > symbol here?
>
> Based on this patch series, the only difference seems to be w.r.t ARM
> components, not peripherals outside ARM subystem. Vybrid VF610 is a
> similar case, though not identical (it can have both instead of
> either), deals w/o extra symbols,
>
> 8064887e02fd6 (ARM: vf610: enable Cortex-M4 configuration on Vybrid SoC)
>
> > especially if
> > we ever get to a chip that has both types of cores.
>
> Your wish fulfilled, Vybrid VF610 has both A5 & M4F and mainline Linux
> boots on both (simultaneously as well), and the second Linux support,
> i.e. on M4 went thr' your keyboard, see above commit :)
>
> There are quite a few others as well, TI's AM335x (A8 + M3), AM437x
> (A9 + M3), AM57x (A15 + M4), but of these Cortex M's, the one in AM57x
> only can be Linux'able. On others they are meant for PM with limited
> resources.
>
> > > So yesterdays application processors are todays MCU processors.
> > >
> > > I said this on a lecture for control systems a while back and
> > > stated it as a reason I think RTOSes are not really seeing a bright
> > > future compared to Linux.
>
> > I think there is still lots of room for smaller RTOS in the long run,
>
> Me being an electrical engineer & worked to some extent in motor
> control on RTOS/no OS (the value of my opinion is questionable
> though), the thought of handling the same in Linux (even RT) sends
> shivers down my spine. Here, case being considered is the type of
> motor (like permanent magnet ones) where each phase of the motor has
> to be properly excited during every PWM period (say every 100us,
> depending on the feedback, algorithm, other synchronization) w/o which
> the motor that has been told to run might try to fly. This is
> different from stepper motor where if control misbehaves/stops nothing
> harmful normally happens.
>
> But my opinion is a kind of knee-jerk reaction and based on prevalent
> atitude in that field, hmm.., probably i should attempt it first.
>
> Regards
> afzal