Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754594AbdLLNdu (ORCPT ); Tue, 12 Dec 2017 08:33:50 -0500 Received: from mx08-00178001.pphosted.com ([91.207.212.93]:36302 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754023AbdLLNdn (ORCPT ); Tue, 12 Dec 2017 08:33:43 -0500 Subject: Re: [PATCH 1/6] ARM: stm32: prepare stm32 family to welcome armv7 architecture To: afzal mohammed , Arnd Bergmann CC: Linus Walleij , Russell King , Rob Herring , Maxime Coquelin , Alexandre Torgue , Linux ARM , "linux-kernel@vger.kernel.org" , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" References: <1512742277-28205-1-git-send-email-ludovic.Barre@st.com> <1512742277-28205-2-git-send-email-ludovic.Barre@st.com> <20171212110315.GA4118@afzalpc> From: Ludovic BARRE Message-ID: <051ef09d-d77b-a657-d041-86e976ba98df@st.com> Date: Tue, 12 Dec 2017 14:32:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171212110315.GA4118@afzalpc> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.75.127.51] X-ClientProxiedBy: SFHDAG5NODE2.st.com (10.75.127.14) To SFHDAG6NODE1.st.com (10.75.127.16) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-12-12_09:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3139 Lines: 78 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 >