 Welcome to this training describing the embedded software architecture and the software distribution, primarily targeting the STM32MP1 microprocessor series. Microcontroller units, so-called MCU, are built around MMU-less cores such as ARM Cortex-M that are very efficient for deterministic operations in a bare-metal or real-time operating system context. STM32MCUs embed enough static RAM and flash memory for many applications and can be completed with external memories. Microprocessor units, so-called MPU, rely on cores such as ARM Cortex-A with a memory management unit to manage virtual memory spaces, opening the door to an efficient support of a rich operating system like Linux. A fast interconnect makes the bridge between the processing unit, high-bandwidth peripherals, external memories, and an optional graphical processing unit or GPU. This first MPU platform, referenced as STM32MP1, is built around dual-core ARM Cortex-A7 and an ARM Cortex-M4 core. This platform aims at addressing multiple market segments such as industrial, consumer, healthcare, home and building automation. STMicroelectronics' approach for a smooth transition to the MPU world consists of putting both worlds in a device, seeing the MCU as a subsystem of the MCU. Some new concepts need to be introduced for a good understanding of multiple-core architecture such as the STM32MP1 one. First of all, a hardware execution context is defined by a core and a security mode. On the STM32MP1 microprocessor, there are three hardware execution contexts. ARM Cortex-A is secure, also called trust zone, ARM Cortex-A non-secure, and ARM Cortex-M supporting only the non-secure mode. Each hardware execution context may support a part of the boot chain execution at boot time and supports the execution of a firmware at runtime. On the STM32MP1 microprocessor, there are also three runtime contexts. ARM Cortex-A is secure, executes opti-secure OS. ARM Cortex-A non-secure executes Linux OS. And ARM Cortex-M executes STM32 cube. The term peripheral assignment is used to identify the action of assigning a set of peripherals to a runtime context. Each peripheral can be assigned to a runtime context or shared across several contexts. Shared peripherals are typically system resources like RCC for the reset and clock control. In line with the concepts introduced on the previous slide, the legend of this diagram distinguishes two possible states for each peripheral. Assigned means that only one hardware execution context is using the peripheral at runtime. A single color box means that the assignment is static, whereas a double or triple color box with vertical separator means that a user choice is needed to assign the peripheral to a given context, depending on its application needs. This assignment can either be done with STM32 cube MX tool or manually, and it is reinforced by hardware isolation for the Cortex-A7 secure and for the Cortex-M4. Shared means that the peripheral can be concurrently used by two or even three different execution contexts. This mode implies registers banking or other mechanisms that ensure there is no contention between the given context when they access a common resource. For instance, TIM instances on the left can be assigned to one runtime context and will only be used by this one. RCC, just below, is a system peripheral that can be concurrently accessed by the three runtime contexts. This screenshot shows an example of the assignment as it can be done with STM32 cube MX tool. USART-1 is assigned to the Cortex-A7 secure for opt-in. USART-2 is assigned to the Cortex-A7 non-secure for linux. USART-3 is assigned to the Cortex-M4 for distribution. Additional possibilities might be described in STM32 MP15 reference manual and may be considered later on in our distribution. Note the two columns that were never mentioned up to now on the left used for USART-6. The boot ROM column allows the ROM code to be able to boot from this instance. This choice limits the TIM's possibilities to the one supported by the ROM code since it is connected to the ML-AHV interconnected peripheral for the boot loader. Listed below and shown in this figure is to limit the size of the device to be generated for the boot loader in the 0x0000 to 0x1FFFFFF address range. D-Bus is used to read or write data in the 0x000000 to 0x1FFFFFF address range. And S-Bus is used for all accesses in the 0x20000000 to 0xFFFFFFFF address range. All STM32 MP15 internal peripherals registers are mapped in this range. Balancing the Cortex-M4 firmware accesses among these ports enables the tuning of the system performances. This is why the MCUS RAM is defined in the first address range from 0x100000000 but it is also visible in the second range from 0x300000000. For the sake of simplicity, this second range is not shown in the next slides but keep in mind that it exists. The diagram maps the various RAM and ROM regions on the different execution contexts that use them in STM32-MPU embedded distribution. It is important to notice that the RET RAM appears twice here. One time on the Cortex-A7 non-secure side for coprocessor firmware loading and one time on the Cortex-M4 side for coprocessor firmware execution that starts to boot from the 0x0000000000 address. This diagram is available on the same STWiki article as the previous one, STM32 MP1 RAM mapping. The Wiki also gives information on the way each one of those regions is used. This slide shows the RAM banks available on STM32 MP1 microprocessors and the typical mapping applied to STM32-MPU embedded software distribution. RET RAM is used by the Cortex-M4 to put its vector table plus some code and data. MCU SRAM1 and SRAM2 can be used to put the remaining Cortex-M4 firmware code and data. MCU SRAM3 is typically used to map the inter-process communication buffers that are further described in the coprocessor management training. And MCU SRAM4 can be used to put DMA buffers for the Cortex-A7 core when high bandwidth is needed when using DMA1 or DMA2 instances. It is not mandatory to align this mapping on regions' borders, but this can be of interest since hardware isolation for Cortex-M4 memory is supported with a per-mpu embedded software distribution. This diagram explains the terminology used to define the main components of the STM32-MPU embedded software. The OpenST Linux distribution running on the ARM Cortex-A includes the OpenST Linux BSP with the boot chain based on TFA and U-boot, the Opti Secure OS running on the ARM Cortex-A in secure mode, and the Linux kernel running on the ARM Cortex-A in non-secure mode. The application frameworks are the middleware relying on the BSP and providing APIs. On the Opti side to run the trusted applications that allow manipulation of secrets, not visible from the Linux and STM32-Cube-MPU package, and on the Linux side to run applications that typically interact with the user via a display, a touchscreen, etc. The STM32-Cube-MPU package is running on the ARM Cortex-M. It is based on HAL drivers and the middleware, like other STM32 microcontrollers, completed with co-processor management. This slide aims at giving a very high-level overview of how a Linux system is organized allowing you to easily jump into the end to explore and get more details about it. On the user side, we have applications that usually rely on middleware to invoke the Linux kernel. Linux drivers are not directly exposing their API to the user space. Instead of that, they are registered to frameworks that themselves expose unified APIs to the user space. The framework concept is very important because it ensures that an application working on a stable framework API will also work on a future Linux kernel version, and that it can as well work on other platforms implementing other drivers. On the left, you can see that some frameworks may even have some sub-frameworks. This is, for instance, the case with SD card support that is a sub-part of the MMC framework. This slide shows the STM32-MP1 peripheral drivers and their respective Linux frameworks. The framework's names are written in lower case. The peripheral driver names are written in upper case. The color code indicates the origin of the source code for each component, third-party, community, or ST microelectronics. This view is also available in the ST Wiki. The STM32-MPU embedded software distribution is built thanks to the open embedded build framework for embedded Linux platforms. This diagram shows the usual components that are embedded in our distribution. Feel free to explore the ST Wiki and open embedded online distribution to customize this setup for your needs.