STM32 MPUs Ecosytem Release V2.1 Distribution package not using device tree files from meta-st-stm32mp-addons.

[NBhat.1]

I've been using Ecosystem v2.0 without any issues now. We decided to move to v2.1 recently, followed the instructions from https://wiki.st.com/stm32mpu/wiki/STM32MP1_Distribution_Package to get the latest package. Then, as I did before, followed the instructions from https://wiki.st.com/stm32mpu/index.php/How_to_create_your_own_machine to create the distribution for our custom board. But running bitbake-st-image-weston failed because it could not create project.dtb as the project.dts files were not copied from the meta-st-stm32mp-addons folder to their respective folders in tf-a, u-boot and kernel.

Has anything changed in v2.1 with regards to custom device tree file placement?

[NBhat.1]

I also noticed that when I ran this command

$> MACHINE=stm32mp1-<ProjectName> DISTRO=openstlinux-weston source layers/meta-st/script/envsetup.sh

It didn't give me an option to agree to EULA certificate and printed the following (with ecosystem 2.0 it sued to give an option to accept EULA and WITH_EULA_ACCEPTED said Yes)

Configuration files have been created for the following configuration:

   DISTRO           : openstlinux-weston

   DISTRO_CODENAME  : dunfell

   MACHINE          : stm32mp1-midmark

   BB_NUMBER_THREADS : <no-custom-config-set>

   PARALLEL_MAKE    : <no-custom-config-set>

   BUILDDIR         : build-openstlinuxweston-stm32mp1-midmark

   DOWNLOAD_DIR     : <disable>

   SSTATE_DIR       : <disable>

   SOURCE_MIRROR_URL : <no-custom-config-set>

   SSTATE_MIRRORS   : <disable>

   WITH_EULA_ACCEPTED: <no-custom-config-set>

[NBhat.1]

I upgraded my system to from ubuntu 16.04 LTS 18.04 LTS (as required by ecosystem v2.1) and restarted the whole process of distribution package. Now I do get EULA acceptance pop-up, but still the build fails because the custom device tree files from the addons are not linked in tf-a, u-boot and kernel source folders.

[NBhat.1 · Accepted solution]

This issue is now fixed.

Root cause: In Ecosystem v2.0 ENABLE_CUBEMX_DTB ?= "1" was set in the cubemx-stm32mp.bbclass, but in ecosystem v2.1 this macro is supposed to be set in machine.conf file. It is set to 0 in cubemx-stm32mp.bbclass.