| Message ID | 1512742277-28205-2-git-send-email-ludovic.Barre@st.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Dec 8, 2017 at 3:11 PM, Ludovic Barre <ludovic.Barre@st.com> wrote: > From: Ludovic Barre <ludovic.barre@st.com> > > 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. > > Signed-off-by: Ludovic Barre <ludovic.barre@st.com> 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. It happened quicker than I thought though, interesting. Yours, Linus Walleij
On Mon, Dec 11, 2017 at 11:25 AM, Linus Walleij <linus.walleij@linaro.org> wrote: > On Fri, Dec 8, 2017 at 3:11 PM, Ludovic Barre <ludovic.Barre@st.com> wrote: > >> From: Ludovic Barre <ludovic.barre@st.com> >> >> 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. >> >> Signed-off-by: Ludovic Barre <ludovic.barre@st.com> 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, especially if we ever get to a chip that has both types of cores. What exactly would we miss if we do away with the ARCH_STM32_MCU symbol here? > 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. > > It happened quicker than I thought though, interesting. I think there is still lots of room for smaller RTOS in the long run, but it's likely that the 'MPU + external DRAM' design point will shift further to Linux, as there isn't really a benefit in squeezing in anything smaller when the minimum is 32MB or 128MB of RAM, depending on the interface. For on-chip eDRAM or SRAM based MPUs, that doesn't hold true, the memory size is what drives the cost here. Arnd
On 12/11/2017 02:40 PM, Arnd Bergmann wrote: > On Mon, Dec 11, 2017 at 11:25 AM, Linus Walleij > <linus.walleij@linaro.org> wrote: >> On Fri, Dec 8, 2017 at 3:11 PM, Ludovic Barre <ludovic.Barre@st.com> wrote: >> >>> From: Ludovic Barre <ludovic.barre@st.com> >>> >>> 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. >>> >>> Signed-off-by: Ludovic Barre <ludovic.barre@st.com> > > 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, especially if > we ever get to a chip that has both types of cores. What > exactly would we miss if we do away with the ARCH_STM32_MCU > symbol here? This patch series extends the existing STM32 microcontrollers (MCUs) family to microprocessors (MPUs). Now, ARCH_STM32 groups STM32 chips with Cortex-M or Cortex-A cores. But each core has different infrastructure mpu vs mmu; nvic vs gic; systick vs arch_timer ... So, ARCH_STM32_MCU/ARCH_STM32_MPU allow to define these specific blocks. br Ludo > >> 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. >> >> It happened quicker than I thought though, interesting. > > I think there is still lots of room for smaller RTOS in the long run, > but it's likely that the 'MPU + external DRAM' design point will > shift further to Linux, as there isn't really a benefit in squeezing > in anything smaller when the minimum is 32MB or 128MB of > RAM, depending on the interface. > > For on-chip eDRAM or SRAM based MPUs, that doesn't hold > true, the memory size is what drives the cost here. > > Arnd >
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
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 >
diff --git a/Documentation/arm/stm32/overview.txt b/Documentation/arm/stm32/overview.txt index a03b035..384cc7f 100644 --- a/Documentation/arm/stm32/overview.txt +++ b/Documentation/arm/stm32/overview.txt @@ -4,17 +4,17 @@ Introduction ------------ - The STMicroelectronics family of Cortex-M based MCUs are supported by the - 'STM32' platform of ARM Linux. Currently only the STM32F429 (Cortex-M4) - and STM32F746 (Cortex-M7) are supported. - + The STMicroelectronics STM32 family of Cortex-A microprocessors (MPUs) and + Cortex-M microcontrollers (MCUs) are supported by the 'STM32' platform of + ARM Linux. Configuration ------------- - A generic configuration is provided for STM32 family, and can be used as the - default by + For MCUs, use the provided default configuration: make stm32_defconfig + For MPUs, use multi_v7 configuration: + make multi_v7_defconfig Layout ------ @@ -22,12 +22,13 @@ Layout All the files for multiple machine families are located in the platform code contained in arch/arm/mach-stm32 - There is a generic board board-dt.c in the mach folder which support - Flattened Device Tree, which means, it works with any compatible board with - Device Trees. - + There are generic boards board-mcu-dt.c and board-mpu-dt.c files in the mach + folder which support Flattened Device Tree, which means, they work with any + compatible board with Device Trees. Document Author --------------- Maxime Coquelin <mcoquelin.stm32@gmail.com> + Ludovic Barre <ludovic.barre@st.com> + Gerald Baeza <gerald.baeza@st.com> diff --git a/arch/arm/mach-stm32/Kconfig b/arch/arm/mach-stm32/Kconfig index 0d1889b..c8059ea 100644 --- a/arch/arm/mach-stm32/Kconfig +++ b/arch/arm/mach-stm32/Kconfig @@ -1,31 +1,43 @@ -config ARCH_STM32 - bool "STMicrolectronics STM32" - depends on ARM_SINGLE_ARMV7M +menuconfig ARCH_STM32 + bool "STMicrolectronics STM32 family" if ARM_SINGLE_ARMV7M select ARCH_HAS_RESET_CONTROLLER - select ARMV7M_SYSTICK select CLKSRC_STM32 select PINCTRL select RESET_CONTROLLER select STM32_EXTI help - Support for STMicroelectronics STM32 processors. + Support for STMicroelectronics STM32 MCU family + +if ARCH_STM32 + +if ARM_SINGLE_ARMV7M + +config ARCH_STM32_MCU + bool "STMicrolectronics STM32 MCU" + select ARMV7M_SYSTICK + help + Support for STMicroelectronics STM32 Microcontrollers. config MACH_STM32F429 bool "STMicrolectronics STM32F429" - depends on ARCH_STM32 + depends on ARCH_STM32_MCU default y config MACH_STM32F469 bool "STMicrolectronics STM32F469" - depends on ARCH_STM32 + depends on ARCH_STM32_MCU default y config MACH_STM32F746 bool "STMicrolectronics STM32F746" - depends on ARCH_STM32 + depends on ARCH_STM32_MCU default y config MACH_STM32H743 bool "STMicrolectronics STM32H743" - depends on ARCH_STM32 + depends on ARCH_STM32_MCU default y + +endif + +endif diff --git a/arch/arm/mach-stm32/Makefile b/arch/arm/mach-stm32/Makefile index bd0b7b5..90c1b71 100644 --- a/arch/arm/mach-stm32/Makefile +++ b/arch/arm/mach-stm32/Makefile @@ -1 +1 @@ -obj-y += board-dt.o +obj-$(CONFIG_ARCH_STM32_MCU) += board-mcu-dt.o diff --git a/arch/arm/mach-stm32/board-dt.c b/arch/arm/mach-stm32/board-mcu-dt.c similarity index 100% rename from arch/arm/mach-stm32/board-dt.c rename to arch/arm/mach-stm32/board-mcu-dt.c