cancel
Showing results for 
Search instead for 
Did you mean: 

FIP_CONFIG must be set in the stm32mp1 when building custom dts

JPabl.1
Senior

I'm using STM32MP157F-DK2 with the distribution package and x-linux-qt to build the st-image-qt image. So far I've been able to work with this image and my custom recipe in the target.

Now, I've been trying to add UART5 support using CubeMX tool.

I followed the tutorial on: https://wiki.st.com/stm32mpu/wiki/How_to_create_your_own_machine

1. In cubemx my project name is "demo-dts" and inside meta-st-stm32mp-addons layer, I created a "mx" folder.

2. From cubemx I browsed to this folder and generated the code. Here's the folder structure after generating the code

meta-st-stm32mp-addons/mx/demo-dts
Inside demo-dts -> CA7  CM4  Common  demo-dts.ioc  Drivers  EWARM  Middlewares

3. Inside conf/machine I created stm32mp1-demo-dts.conf and added:

CUBEMX_DTB = "stm32mp157f-demo-dts-mx"
CUBEMX_PROJECT ="mx/demo-dts/CA7/DeviceTree/demo-dts"

4. I created a new build environment with:

DISTRO=openstlinux-weston MACHINE=stm32mp15-mx BSP_DEPENDENCY="layers/meta-qt6 layers/meta-st/meta-st-x-linux-qt" source layers/meta-st/scripts/envsetup.sh

5. bitbake st-image-qt

The first time I tried I got a meta-qt6 layers is not added... but that was solved in the bblayers. After that, I'm getting this error:

ERROR: Nothing PROVIDES 'virtual/trusted-firmware-a'
nativesdk-tf-a-stm32mp PROVIDES virtual/trusted-firmware-a but was skipped: FIP_CONFIG must be set in the stm32mp1-demo-dts machine configuration.
tf-a-stm32mp PROVIDES virtual/trusted-firmware-a but was skipped: FIP_CONFIG must be set in the stm32mp1-demo-dts machine configuration.
tf-a-stm32mp PROVIDES virtual/trusted-firmware-a but was skipped: FIP_CONFIG must be set in the stm32mp1-demo-dts machine configuration.
ERROR: Required build target 'st-image-qt' has no buildable providers.
Missing or unbuildable dependency chain was: ['st-image-qt', 'virtual/trusted-firmware-a']
1 REPLY 1
TBind.2
Associate II

We had the same problem when we migrated from kirkstone to scarthgap.

In our machine config we set the BOOTSCHEME_LABELS to trusted, which seems to no long be valid. Valid values can be found in the scarthgap release notes:

https://wiki.st.com/stm32mpu/wiki/STM32_MPU_OpenSTLinux_release_note_-_v6.0.0#Bootscheme_labels