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