2020-09-28 09:08 AM
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.
2020-09-29 05:09 AM
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
2020-09-30 12:48 AM
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
2020-09-30 12:52 AM
Also the installed ecosystem is STM32MP15-Ecosystem-v1.2.0
2020-09-30 12:54 AM
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
2020-09-30 12:58 AM
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
2020-10-13 12:51 AM
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.
2020-10-14 03:09 AM
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
2024-06-27 03:20 AM
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