 Hello, and welcome to this overview of the OpenST Linux distribution. It describes the main components of this distribution and the way they are delivered. This training doesn't dive deep into technical explanations on open embedded, the underlying build system of OpenST Linux. This level of information can be found on community sites. OpenST Linux is a concept for an STM32-MPU embedded software package. Concept here means a naming associated with pillars or values. These pillars are usage of a standard kernel interface. The target is to use kernel versions from kernel.org with a minimal set of proprietary patches. Usage of open source software. Open source is a strong foundation of OpenST Linux. Link to community. Target is to upstream as much as possible the source code, not only the kernel drivers, but bootloader code or build system as well. Communities bring great advantages in term of standard conformity, quality of code, security and long-term support, not to mention development cost. Easy to use. The last pillar, but not the least, is the need for an easy-to-use solution addressing a wide range of customers, from a garage developer to an industrial devices maker, with various needs. Therefore, the target is a scalable, powerful and easy solution that allows customers to build what they need. Open embedded was selected as the OpenST Linux build process. Once again, the target is to comply with standards and upstream as much as possible. The STM32MPUBSP, or Board Support Package, is upstream to the Yocto community. There are three available software packages, the starter package, the developer package and the distribution package. These three packages are complementary and answer different needs throughout a product development cycle, platform evaluation, application or kernel development, and integration and product delivery. The starter package allows a quick and easy means to get any STM32 microprocessor development platform up and running. The developer package allows the modification of some pieces of software of the STM32MPU embedded software distribution, as well as the addition of applications in the platform software image. The distribution package allows the creation of a new distribution with a final objective of productization. The combination of these three packages covers all possible use cases, from discovery to productization. An STM32 microprocessor development platform, such as the STM32MP157CEV1 evaluation board and a microSD card populated with the software image delivered for this platform are all that is required to discover the platform capabilities. No integrated development environment or IDE, no software development kit or SDK are needed. Just use the development platform as a micro PC running Linux. The software image contains firmware delivered as examples with regards to the STM32CUBEMPU package if the considered development platform includes an ARM Cortex-M processor. What are the main use cases covered by this package? Evaluation of the STM32 microprocessor device and development platform, such as internal peripherals and performance. Execution of the CUBE M4 firmware projects delivered within each STM32MPU embedded software distribution starter package, such as the firmware available on the ARM Cortex-M processor. Direct development on the development platform of simple user examples in different languages Shell, Python, etc. To do so, the starter package contains ready to use binaries. These binaries have been generated using an ST Open Embedded image that uses Weston, a minimal and fast graphical compositor. Binaries can be loaded onto a microSD card using the Flash Loader tool. It is also possible to generate a custom microSD card content from a script. The possibilities of combinations to generate a software configuration being huge, the delivery only contains the most relevant set. The developer package provides, on top of the starter package, a software development kit or SDK for cross-development on a host PC. The following pieces of software of the OpenST Linux distribution in source code, Uboot, Trusted Firmware A or TFA, Linux Kernel, and optionally, Open Source Trusted Execution Environment or OPTI. The STM32-MPU package in source code, if the considered development platform includes an ARM Cortex-M processor, an Initialization Code Generator, STM32-CubeMX. This tool makes it possible to generate device tree for OpenST Linux distribution and generate the peripheral Initialization C code and IDE project creation files for STM32-CubeMPU package. An Eclipse-based Integrated Development Environment or IDE, STM32-CoproMPU. STM32-Cube Firmware projects are supported by STM32-CoproMPU Eclipse plugin. Project files generated by STM32-CubeMX can be directly opened by this IDE to continue CUBE firmware development. And IDE is optional for OpenST Linux development, since all actions can be achieved through a command line. What are the main use cases that can be covered with this package? Modification and tuning of the pieces of software delivered as source code. Code modification, efficient development cycle, compile, push on target, debug, tuning of the configuration options, for example for the Linux kernel, and adaptation of the device tree files for the microprocessor device and development platform. Development of the firmware running on the ARM Cortex-M processor, addition of your own Linux applications or Linux application frameworks, addition of your own trusted applications or TAs, if Opti is part of the software release, and addition of your own UBOOT applications. This package allows the creation of a new Linux distribution with a final objective of productization. It includes the source code of all the pieces of software of the STM32-MPU embedded software distribution, including the application frameworks, plus a build framework based on open embedded, also known as distribution builder. A host PC is required to operate this package, a Linux host PC is even strongly recommended. Some open embedded basic terms are introduced here, layer, meta, append. These terms are detailed in the next slides. What are the main use cases that can be covered with this package? To tune the system configuration options, such as memory sizes or debug options, to share all the developments within your team, software baseline, and to prepare the final software for productization. Integration of the following software in this distribution, any of your developments made thanks to the developer package, pieces of software coming from open source communities or third parties, and integrate your CUBE M4 firmware projects in your own distribution, binary or source code, generation of your own starter package images, and generation of your own developer package SDK. Generally speaking, few dedicated people from the project team use this distribution package to create and regularly enrich the project Linux distribution and generate the project developer package. Most developers use this developer package for their developments, since it is a light and efficient or short development cycle environment. Open embedded is a project initiated by the Linux Foundation in 2010 and is still managed by one of its fellows, Richard Purdy. Open embedded is a Linux based cross compilation framework. Cross compilation is the possibility on a machine with a given hardware architecture and a given operating system to compile programs for another hardware architecture or operating system. Open embedded is open source, but it can be used to build proprietary code. It is based on Git for software configuration management. People talk about Yachto, Pokey, or open embedded, and this can be confusing. Open embedded is a build framework for embedded Linux, is maintained by the community, is the source version of Pokey, and is mainly consolidated for ARM platforms. Yachto is a project that uses open embedded build system. Pokey is a reference system of the Yachto project, a collection of Yachto project tools and metadata that serves as a set of working examples. Pokey uses open embedded core. Pokey is maintained by Intel. This setup is mainly consolidated for Intel platforms. Some projects work on a Yachto base, some others on a Pokey base, but in the end, everything is compatible. Open embedded may be seen as a powerful yet quite complex build framework. To ease its understanding, let's sum up the main actions open embedded does during a compilation. Most of the operations below are defined in files named recipes. It downloads source code from various repositories. It applies patches to the source code. It cross-compiles this modified source code and prepares ready-to-deploy images. Eventually, it creates packages under different possible formats. In the end, thanks to the open embedded framework, these packages can be installed exactly the same way on an Ubuntu or Debian PC. As an example, an apt-get install on such a PC could also be done on the target. Remember, open embedded is a Linux distribution maker. In practice, open embedded generates a set of binaries. Binary packages, as explained previously. Linux-based system images, kernel images, device trees, everything your device will need to run the Linux system you have compiled. Toolchains. Before actually cross-compiling the source code, open embedded compiles the toolchain. This explains why the compilation may take a significant amount of time. However, this is quite powerful. Imagine what would happen if you had to find the right toolchain to download prior to compiling. Power distribution kit. This kit containing the toolchain is a ready-to-use SDK. Once the framework of your Linux distribution is defined for simple developments, SDK can be the best tool to work with. This graph coming from the Yachto project site sums up the compilation flow. Source code is downloaded from different locations. Patches are applied. The source code is cross-compiled. Images are generated. Images are generated, and SDK is generated. In addition, QA testing can be performed. A few more concepts first. Once again, basic vocabulary. Layers, machine, distribution, and image are words that are regularly used in the open embedded world. In practice, their content is defined by a limited number of people, typically integrators. A layer can be seen as a folder whose name starts with meta. It contains recipes and configuration files. Layers are organized so that they contain information describing a comprehensive set. For example, the definition of a BSP is done in a layer. Other frameworks such as QT can also be added in a specific layer. On the other hand, the resulting product software is defined by the combination of a machine, a distribution, also known as distro, and an image, each of them providing a different level of information. Why is this? Wouldn't it be easier to find all the information in a single place? Well, it may be, but splitting the software in these three levels allows their combination in many ways. I like my software content, but I want to compile it for another platform. Easy. I want to add a software package to my distribution. Easy as well. I want to configure my software differently. Easy as well. Layer provides software, machine, and distro metadata, machine, machine metadata, configuration of a hardware, distribution, distribution metadata, configuration of a software, functionality associated to hardware, Wi-Fi, network, Bluetooth, functionality associated to software, init, specific implementation of software, SDK name, image, set of software present on image ready to flash on board. Some software can be conditioned by the distro feature switch. Here is a graphic representation of the layers and their possible content. Each folder has a similar structure with configuration files and recipes. To assemble a distro, an image or software layer in the graph, and a machine or BSP layer in the graph, use the bitbake command, which is the command to compile with open embedded framework. The combination of the distro, machine, and image layers is done when the open embedded environment is initialized. It is time to connect all these concepts to what is actually implemented for OpenST Linux. The figure above shows the layers created by ST. MetaSTSTM32MP contains a BSP definition, well actually three BSPs. A generic one, STM32MP1 generates all the selected combinations in a single compilation. That is useful for testers, for instance. And two dedicated machines, STM32MP1 eval and STM32MP1 disco for the eval and disco boards. Then, MetaST OpenST Linux. Here the choice is to host both distro and images definitions. In white characters are the official offers. And italic green characters are the configurations that are delivered as examples without official support. Here are useful links for the deployment of the OpenST distribution.