From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ludovic BARRE Subject: Re: [PATCH 1/6] ARM: stm32: prepare stm32 family to welcome armv7 architecture Date: Tue, 12 Dec 2017 14:32:52 +0100 Message-ID: <051ef09d-d77b-a657-d041-86e976ba98df@st.com> References: <1512742277-28205-1-git-send-email-ludovic.Barre@st.com> <1512742277-28205-2-git-send-email-ludovic.Barre@st.com> <20171212110315.GA4118@afzalpc> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20171212110315.GA4118@afzalpc> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: afzal mohammed , Arnd Bergmann Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Alexandre Torgue , Linus Walleij , Russell King , "linux-kernel@vger.kernel.org" , Rob Herring , Maxime Coquelin , Linux ARM List-Id: devicetree@vger.kernel.org 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 >