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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
