With wrynose layer of meta-st-stm32mp, can't set ST_OPTEE_CORE_DEBUG

[rpjday]

This might be my misunderstanding of how OVERRIDES work, but I'm building with the recently-released "wrynose_v26.02.18" branch of meta-st-stm32mp and, for the purpose of debugging, I wanted to set:

ST_OPTEE_CORE_DEBUG = "y"

so I did that in my local.conf file, but after I set it, it still had the value of "n" for the build, so I dumped the value to see how it was (or was not) being set:

bitbake-getvar -r optee-os-stm32mp ST_OPTEE_CORE_DEBUG
... snip ...
# $ST_OPTEE_CORE_DEBUG [3 operations]
# set /home/rpjday/BOARDS/nexus/wrynose/build/conf/local.conf:13
# "y"
# set /home/rpjday/Layers/wrynose/st/meta-st-stm32mp/recipes-security/optee/optee-os-stm32mp-common.inc:37
# [_defaultval] "y"
# override[stm32mp15common]:set? /home/rpjday/Layers/wrynose/st/meta-st-stm32mp/recipes-security/optee/optee-os-stm32mp-common.inc:38
# "n"
# pre-expansion value:
# "n"
ST_OPTEE_CORE_DEBUG="n"

You can see how the first line seems to show that I am explicitly setting it in my local.conf, then the processing continues through these lines in the file optee-os-stm32mp-common.inc:

# default core debug
ST_OPTEE_CORE_DEBUG ??= "y"
ST_OPTEE_CORE_DEBUG:stm32mp15common ?= "n"

But those lines are both conditional assignments which should not come into play since I have already assigned a value. But the second line has a "stm32mp15common" override (which is in effect) and that seems to be setting the value back to "n" -- not what I expected.

Am I just misunderstanding how these override assignments work?

[PatrickF · Accepted solution]

Hi,

Wrynose is not supported yet, latest supported Yocto release is Scarthgap.
5.0.15-openstlinux-6.6-yocto-scarthgap-mpu-v26.02.18 
https://wiki.st.com/stm32mpu/wiki/STM32_MPU_ecosystem_release_note#Yocto-based_OpenSTlinux_embedded_software

Regards.

[rpjday]

I realize wrynose is not "officially" supported yet, but there is a pre-release wrynose branch that I'm playing with. In any event, it turns out this has nothing to do with that branch, it was a misunderstanding on my part on how basic overrides and conditional assignments worked together in OpenEmbededed. So we're all good here.

rday

[sonicmenu]

Very informative thread regarding STM32MP secure boot and OP-TEE integration challenges. Problems related to st-optee-core settings often come down to layer dependencies, version mismatches, or configuration overrides, so it’s useful to see practical debugging insights shared here. Discussions like this are valuable for embedded Linux developers working on secure and stable MPU deployments.