STM32MP157C custom machine dts compile error

[EButl.1]

So I got the basic yocto build working for the STM32MP157C-DK2 and have been able to modify it to add/ remove/ modify features without any problems both st-image-core and st-image-weston.

Then I come to do a custom machine and add it to the build by following:

https://wiki.st.com/stm32mpu/index.php/How_to_create_your_own_machine

This build runs until I get the following error:

arch/arm/dts/.stm32mp1-test.dtb.pre.tmp:14:10: fatal error: stm32mp157.dtsi: No such file or directory

| #include "stm32mp157.dtsi"

|          ^~~~~~~~~~~~~~~~~

| compilation terminated.

I have a feeling I have missed something simple but any advice greatly appreciated.

[Olivier GALLIEN]

Hi @EButl.1​ ,

Could you please confirm you are using a complete and consistant ecosystem V2.0 delivery ?

Complete trace of Yocto build may help to analyze the issue.

Olivier

[EButl.1]

So this is the script that I run for setting up the build

repo init -u https://github.com/STMicroelectronics/oe-manifest.git -b refs/tags/openstlinux-4.19-thud-mp1-19-10-09

repo sync

cd layers/meta-openembedded ; git checkout thud

cd ../meta-qt5 ; git checkout thud

cd ../meta-st/meta-st-openstlinux ; git checkout thud

cd ../meta-st-stm32mp ; git checkout thud

cd ../meta-st-stm32mp-addons ; git checkout thud

cd ../../meta-timesys ; git checkout thud

cd ../openembedded-core ; git checkout thud

cd bitbake ; git checkout 1.40

cd ../..

cp -r ../../../../meta-my-test-layer .

cd ../

mkdir git-repos

cd git-repos

git clone https://github.com/STMicroelectronics/STM32CubeMP1.git STM32CubeMP1.git

git clone https://github.com/STMicroelectronics/linux.git linux.git

cd ..

DISTRO=openstlinux-weston MACHINE=stm32mp1-test source layers/meta-st/scripts/envsetup.sh

bitbake st-image-weston

################################################################################################

The stm32mp1-test.conf is below:

#@TYPE: Machine

#@NAME: stm32mp1-test

#@DESCRIPTION: Configuration for STM32CubeMX generated project

#@NEEDED_BSPLAYERS: layers/meta-openembedded/meta-oe layers/meta-openembedded/meta-python

include conf/machine/include/st-machine-common-stm32mp.inc

include conf/machine/include/stm32mp1-mx-config.inc

include conf/machine/include/stm32mp1-mx-extlinux-config.inc

include conf/machine/include/stm32mp1-mx-common.inc

#require conf/machine/include/st-machine-common-stm32mp.inc

#require conf/machine/include/stm32mp1-mx-common.inc

# =========================================================================

# CubeMX extra config

# =========================================================================

# Set specific path by components for DT file location

CUBEMX_DTB_PATH_TFA    = "${STM32MP_MX_BASE}/mx/${CUBEMX_PROJECT}/tf-a"

CUBEMX_DTB_PATH_UBOOT  = "${STM32MP_MX_BASE}/mx/${CUBEMX_PROJECT}/u-boot"

CUBEMX_DTB_PATH_LINUX  = "${STM32MP_MX_BASE}/mx/${CUBEMX_PROJECT}/kernel"

#CUBEMX_DTB_PATH_OPTEEOS = "${STM32MP_MX_BASE}/mx/${CUBEMX_PROJECT}/optee-os"

# =========================================================================

# User customizing sections

# =========================================================================

# Override machine specific OPTEE config with generic DK2 one

#OPTEE_CONF = "stm32mp157c-dk2"

# Boot Scheme

# =========================================================================

# DISCO / EVAL : basic, trusted or optee

# =========================================================================

#BOOTSCHEME_LABELS += "basic"

#BOOTSCHEME_LABELS += "trusted"

BOOTSCHEME_LABELS += "optee"

# Boot Device Choice

# =========================================================================

# DISCO : sdcard

# EVAL : sdcard, emmc, nand-4-256, nor-sdcard, nor-emmc or nor-nand-4-256

# =========================================================================

# Define the boot device supported

BOOTDEVICE_LABELS += "sdcard"

# WARNING: configs below are only available with EVAL board

#BOOTDEVICE_LABELS += "emmc"

#BOOTDEVICE_LABELS += "nand-4-256"

#BOOTDEVICE_LABELS += "nor-emmc"

#BOOTDEVICE_LABELS += "nor-nand-4-256"

# Board Type Choice

# =========================================================================

# DISCO : stm32mp157a-dk1 or stm32mp157c-dk2

# EVAL : stm32mp157c-ev1

# =========================================================================

# Define the board reference devicetree name

# WARNING: only one setting allowed

#CUBEMX_BOARD_REFERENCE = "stm32mp157a-dk1"

CUBEMX_BOARD_REFERENCE = "stm32mp157c-dk2"

#CUBEMX_BOARD_REFERENCE = "stm32mp157c-ev1"

# CubeMX Project Config

# =========================================================================

# Assign CubeMX Board devicetree and project path name

CUBEMX_DTB = "stm32mp1-test"

CUBEMX_PROJECT = "../../../../../../../stm32mp1-test/CA7/DeviceTree/stm32mp1-test"

###################################################################################################

All of the missing files are in the https://github.com/STMicroelectronics/linux.git repo but I'm not sure where I should make that reference/ include or should they be downloaded automatically?

I also tried copying the missing file but it has it's own dependencies that are required

[EButl.1]

Also the installed ecosystem is STM32MP15-Ecosystem-v1.2.0

[Olivier GALLIEN]

Strange, Ecosystem V1.2 would have mean :

Openstlinux-20-02-19 not openstlinux-4.19-thud-mp1-19-10-09 you mention in above comment.

Olivier

[Olivier GALLIEN]

Hi @EButl.1​ 

A possible issue is that you are using STM32CubeMX V6.0.x to generate your Device Tree which are only compliant with Ecosystem V2.0.

>> repo init -u https://github.com/STMicroelectronics/oe-manifest.git -b refs/tags/openstlinux-4.19-thud-mp1-19-10-09

This is the quite old V1.1 ecosystem Distribution !?

For compatibility you may need to use STM32CubeMX V5.4 !

Please check-out :

https://wiki.st.com/stm32mpu-ecosystem-v1/wiki/STM32MP15_ecosystem_release_note_-_v1.1.0#STM32CubeMX

Olivier

[EButl.1]

Hi,

You were right about the revisions. It turned out that the dts' were produced with ecosystem 2.0 and were incompatible with the 4.9.

I moved over to the 5.4 Dunfell branch and was able to generate the dtbs.

I did notice that even when building a default image that build does not work straight out of the box, I'll get a few notes up here once I have have done a couple of clean builds and am happy it is working.

Thanks again.

[EButl.1]

So as promised a brief description on building the basic image with 5.4

(taken from a bash file I use to build it)

mkdir bin

PATH=$PWD/bin:$PATH

curl https://storage.googleapis.com/git-repo-downloads/repo > bin/repo

chmod a+x bin/repo

mkdir testBuild

cd testBuild

mkdir yocto

cd yocto

repo init -u https://github.com/STMicroelectronics/oe-manifest.git -b refs/tags/openstlinux-5.4-dunfell-mp1-20-06-24

repo sync

cd layers/meta-openembedded ; git checkout dunfell

cd ../meta-qt5 ; git checkout dunfell

cd ../meta-st/meta-st-openstlinux ; git checkout dunfell

cd ../meta-st-stm32mp ; git checkout dunfell

cd ../meta-st-stm32mp-addons ; git checkout dunfell

cd ../../meta-timesys ; git checkout dunfell

cd ../openembedded-core ; git checkout dunfell

cd bitbake ; git checkout 1.46

cd ../..

cp -r ../../../../meta-my-test-layer .

cd ../

# These were breaking the build

rm layers/meta-st/meta-st-openstlinux/recipes-multimedia/v4l2apps/v4l-utils_1.18.0.bbappend

rm layers/meta-st/meta-st-stm32mp/recipes-graphics/drm/libdrm_2.4.100.bbappend

# End

############################

I then needed to create a bbappend for linux-stm32mp_5.4.bb in my layer

BB_STRICT_CHECKSUM = "0"

It was a hacky work around and I need to find the md5 for the linux.tar it was faulting on.

Then call the standard:

DISTRO=openstlinux-weston MACHINE=stm32mp1 source layers/meta-st/scripts/envsetup.sh

bitbake-layers add-layer ../layers/meta-my-test-layer/

bitbake st-image-weston

This gives me an image I can deploy on the dk2 but using my own dts is a really painful process around the optee where I had to copy lots of files by hand to make it work. I'm trying to modify the recipes so this is an automated process and will report back when I get a robust solution

[Subhadeepiitkgp2024]

Hi @EButl.1 

Is there any update on this: "using my own dts is a really painful process around the optee where I had to copy lots of files by hand to make it work. I'm trying to modify the recipes so this is an automated process and will report back when I get a robust solution"

 

I am trying to building the image with the cubemx files generated for our SOM board but failing due to the above mentioned similar issue. 

 

Thanks