1. Introduction[edit | edit source]
For your own needs, you can add in the Yocto project a new machine reflecting your own board and your own features.
This article is reserved to Yocto experts or at least people who have already practiced with the Yocto environmment.
This section describes how to add and configure a machine that is similar to those that the OpenSTLinux Distribution Package already supports.
This customer machine is associated to STM32CubeMX tool which provides DeviceTree files per component (tf-a, u-boot and kernel).
We suppose here that all the material described below is done inside an existing STM32MP BSP layer 'addons'.
For reminder this addons layer is deployed here in our delivery : <path of STM32_MPU_Distribution_Package>/layers/meta-st/meta-st-stm32mp-addons/
2. Generate device tree[edit | edit source]
The principle is that the user generates device tree files from the STM32CubeMX tool.
With the STM32CubeMX tool, the user browses inside the OpenSTLinux Distribution Package file system until mx folder located into STM32MP BSP layer addons :
<path of STM32_MPU_Distribution_Package>/layers/meta-st/meta-st-stm32mp-addons/mx/
- several sub-folders are created and populated with generated device tree files :
mx └── <ProjectPath> ├── <CortexA> │ └── DeviceTree │ └── <ProjectName> │ ├── kernel Device tree files for Linux kernel │ │ │── <soc-machine>-<ProjectName>-mx.dts │ │ └── [...] │ ├── optee-os Device tree files for OP-TEE │ │ │── <soc-machine>-<ProjectName>-mx.dts │ │ └── [...] │ ├── tf-a Device tree files for TF-A │ │ │── <soc-machine>-<ProjectName>-mx.dts │ │ └── [...] │ └── u-boot Device tree files for U-BOOT │ │── <soc-machine>-<ProjectName>-mx.dts │ └── [...] ├── CM33 (Availability depending of configuration used with STM32CubeMX tool) │ └── DeviceTree │ └── <ProjectName> │ ├── mcuboot Device tree files for MCUBOOT │ │ │── <soc-machine>-<ProjectName>-mx.dts │ │ └── [...] │ └── tf-m Device tree files for TF-M │ │── <soc-machine>-<ProjectName>-mx.dts │ └── [...] └── ExtMemLoader (Availability depending of configuration used with STM32CubeMX tool) └── <ProjectName> ├── optee-os Specific device tree files to generate FIP programmer binary │ │── <soc-machine>-<ProjectName>-mx.dts │ └── [...] ├── tf-a Specific device tree files to generate TF-A and FIP programmer binaries │ │── <soc-machine>-<ProjectName>-mx.dts │ └── [...] └── u-boot Specific device tree files to generate FIP programmer binary │── <soc-machine>-<ProjectName>-mx.dts └── [...]
Description:
<CortexA>: CA7 or CA35 depending of configuration selected with STM32CubeMX tool <ProjectPath>: the sub-path of STM32CubeMX user project within mx folder <ProjectName>: the STM32CubeMX user project name <soc-machine>: the soc name without '-dkX' or '-evX' extension (e.g. stm32mp135f, stm32mp157f, stm32mp257f, etc)
3. Create a customer machine[edit | edit source]
Create a machine based on the one provided by ST and align some environment variables with the content of mx/<ProjectName> sub-folders
3.1. Create the new machine[edit | edit source]
<path of STM32_MPU_Distribution_Package>/layers/meta-st/meta-st-stm32mp-addons/conf/machine cp <stm32mp1x|stm32mp2x>-mx.conf <stm32mp1x|stm32mp2x>-<ProjectName>.confcd
3.2. Edit the new machine file[edit | edit source]
In the customer machine file, move to User machine customization sections paragraph to configure your machine:
- Boot Scheme
- To select your boot scheme configuration(s), comment and uncomment the BOOTSCHEME_LABELS lines.
- Boot Device Choice
- To select your boot device configuration(s), comment and uncomment the BOOTDEVICE_LABELS lines.
- Support Feature Choice
- To select additional features to enable on board, uncomment the "MACHINE_FEATURES" proposed lines.
- Specific firmware and kernel modules configuration
- This section allows user to configure some specificities related to its board hardware.
- - KERNEL_MODULE_AUTOLOAD you may need to feed this variable with the list of kernel modules that need to be loaded at boot time, such as 'goodix' for current touch-screen used on STM32MP157F-EV1 evaluation board.
- - BLUETOOTH_LIST in case you enable the bluetooth feature for your machine, you should set, at least, the firmware module to use for your hardware (e.g. 'linux-firmware-bluetooth-bcm4343' for STM32MP157F-DK2 discovery board).
- - WIFI_LIST in case you enable the wifi feature for your machine, you should set, at least, the firmware module to use for your hardware (e.g.'linux-firmware-bcm43430' for STM32MP157F-DK2 discovery board).
- CubeMX Project config
- You have to uncomment and configure the following variables to set your CubeMX project:
- - CUBEMX_DTB name of CubeMX generated device tree files, without file extension (e.g. stm32mp135f-<ProjectName>-mx)
- - CUBEMX_PROJECT path of CubeMX generated device tree files relative to layer path folder (e.g. mx/<ProjectPath>)
- - CUBEMX_PROJECT_NAME name of CubeMX project (e.g. <ProjectName>)
- Optionally you can also uncomment and configure the CUBEMX_BOARD_DDR_SIZE variable to set the size of DDR available on BOARD in MB unit. This is no more needed as now configuration is already done in OP-TEE conf.mk file generated with CubeMX through CFG_DRAM_SIZE config switch.
In order to give a better view on how to configure these variables, some machine samples are provided to show how to set-up a disco and eval board CubeMX machine: refer to conf/machine/examples from meta-st-stm32mp-addons layer.
3.3. Create symbolic link for EULA with new machine created[edit | edit source]
To support GPU and third party content, you need to accept the EULA. So a symbolic link must be created with the EULA existing file and the new machine :
<path of STM32_MPU_Distribution_Package>/layers/meta-st/meta-st-stm32mp-addons/conf/eula ln -s ST_EULA_SLA <stm32mp1x|stm32mp2x>-<ProjectName>cd
4. Miscellaneous[edit | edit source]
4.1. STM32CubeMX class[edit | edit source]
A dedicated class is provided here :
<STM32MP BSP layer addons>/classes/cubemx-stm32mp.bbclass
The main goal of this class is to manage any change done by the customer in sub folders mx/<ProjectName>/...
So if a device tree file is updated for one or more of components, this change will be taken into account automatically during the next compilation done in the Distribution Package.
5. Compile your image with the yocto build process[edit | edit source]
<path of yocto delivery> (directory which contains meta-st, openembedded-core, meta-openembedded)cd
MACHINE=<stm32mp1x|stm32mp2x>-<ProjectName> DISTRO=openstlinux-weston source layers/meta-st/scripts/envsetup.sh Accept the term of EULA (if you agree with)
bitbake st-image-weston The generated images are available on build-openstlinuxweston-<stm32mp1x|stm32mp2x>-<ProjectName>/tmp-glibc/deploy/images/<stm32mp1x|stm32mp2x>-<ProjectName>