U-Boot build fails in Yocto for STM32MP1 with “work-shared source is not clean” error

[shreyaschandran]

I am building a custom Yocto image for STM32MP1 (STM32MP157) using ST OpenSTLinux (dunfell-based) and I am facing a persistent U-Boot build failure.

Environment:

SoC: STM32MP157 (custom board)

Yocto: ST OpenSTLinux (dunfell)

U-Boot: v2020.10-stm32mp-r2.2

Recipe: u-boot-stm32mp

Machine: stm32mp1

Issue:

During bitbake u-boot-stm32mp, the build fails in do_compile with the following error:

.../tmp-glibc/work-shared/stm32mp1/uboot-source is not clean,

please run 'make mrproper'

This error is triggered by U-Boot’s internal check that aborts when generated files are found in the shared source tree.

Observations:

The error occurs even after running:

bitbake -c clean u-boot-stm32mp

The failure persists until I manually remove:

tmp-glibc/work-shared/stm32mp1/uboot-source

and then run:

bitbake -c cleansstate u-boot-stm32mp

At some point earlier, I ran make menuconfig manually in the U-Boot source to inspect SPI configuration, which may have introduced .config or include/config/* into the shared tree.

I also attempted to add SPI-related configuration, but I now understand that adding invalid symbols like CONFIG_SPI directly is not correct for U-Boot ≥2020.

Questions:

Is manually deleting work-shared/stm32mp1/uboot-source the correct and recommended recovery method once the shared tree is polluted?

Is there a Yocto-sanctioned way to reset or protect the shared U-Boot source tree from accidental manual builds?

For enabling SPI / SPI NOR on STM32MP1, what is the recommended approach:

defconfig fragment only?

DTS-only enablement?

specific ST-supported Kconfig symbols?

Are there any ST guidelines or best practices to avoid this class of failure when customizing U-Boot for STM32MP platforms?

Any guidance from ST or Yocto maintainers would be appreciated.

[Erwan SZYMANSKI]

Hello @shreyaschandran ,
Your recovery method looks good for me.

Concerning your question, the cleanest way for me would be to add into your own layer, a bbappend on u-boot recipe to include the patch/fragments you need. This a a clean way to say "I start from the baseline, and I modify it according to my needs in my own bbappend recipe".

Concerning your DT, you adapt it as you need of course.

Note sure to understand exactly the difference you make between defconfig fragment and ST fragments, but in theory you should just create your fragment files, and apply it thanks to your bbappend recipe. It should be applied at the top of all the existing fragment so that you are sure that your own one is the highest prio one (natural behavior with a bbappend if rightly written).

Kind regards,
Erwan.

[shreyaschandran]

The build error is attached and occurs while trying to build the st-image-weston image. How can I fix this?

[Erwan SZYMANSKI]

@shreyaschandran ,
Can you attach your Yocto layer / recipe so that I can see how you try to apply changes on your u-boot config ? 

Rgs,
Erwan

[shreyaschandran]

I am applying the U-Boot configuration changes through a custom Yocto layer using a .bbappend on the U-Boot recipe.

In this setup, I hook into the do_patch task and apply the required configuration changes by modifying the stm32mp15_trusted_defconfig file directly after patches are applied. The intention was to enable SPI-related options consistently during the build without relying on manual menuconfig changes.

I have attached the relevant .bbappend from my custom layer (my-layer/recipes-bsp/u-boot/) for your reference so that you can review the exact mechanism being used.

Please let me know if this approach is not recommended in OpenSTLinux and if there is a preferred method (for example, using config fragments or a different bbappend mechanism) to persist U-Boot configuration changes.

u-boot-stm32mp_2020.10.bbappend:

FILESEXTRAPATHS_prepend := ":${THISDIR}/files:"

do_patch[postfuncs] += "add_spi_config"

add_spi_config() {
# Pure shell - no backslashes, no Python
sed -i '/CONFIG_SYS_VSNPRINTF=y/i CONFIG_SPI=y' ${S}/configs/stm32mp15_trusted_defconfig
sed -i '/CONFIG_SYS_VSNPRINTF=y/i CONFIG_SPI_MEM=y' ${S}/configs/stm32mp15_trusted_defconfig
sed -i '/CONFIG_SYS_VSNPRINTF=y/i CONFIG_SPI_FLASH=y' ${S}/configs/stm32mp15_trusted_defconfig
sed -i '/CONFIG_SYS_VSNPRINTF=y/i CONFIG_DM_SPI=y' ${S}/configs/stm32mp15_trusted_defconfig
sed -i '/CONFIG_SYS_VSNPRINTF=y/i CONFIG_DM_SPI_FLASH=y' ${S}/configs/stm32mp15_trusted_defconfig

[Erwan SZYMANSKI]

@shreyaschandran ,
The clean method would consist of creating fragments file next to your bbappend recipe.
Look at how it is managed in the original recipe here: https://github.com/STMicroelectronics/meta-st-stm32mp/tree/scarthgap/recipes-bsp/u-boot/u-boot-stm32mp

In your recipes-bsp/u-boot (where you should have your u-boot-stmmp_%.bbappend or something like that), you should create a folder as it is done in original recipe, named files or u-boot-stm32mp and place your own fragment file inside.

Then in your bbappend recipe, you should add the fragment in your SRC_URI.

As you well indicated the FILESEXTRAPATHS_prepend, I think u-boot should take your own fragment into account and apply the necessary configuration (because of do_generate_defconfig in u-boot-stm32mp.inc file).

After doing this, and see if compilation runs good, you can verify in the work Yocto folder, if your .config file for u-boot matches with your expectations.

Kind regards,
Erwan.

PS: take care to respect the name format for the fragment, so that it can be recognized by the do_generate_defconfig function. Just get inspired by existing ones.

[shreyaschandran]

Thank you for the detailed explanation regarding the use of defconfig fragments and do_generate_defconfig. I followed the recommended approach and would like to share my current status along with the build logs and directory structure.

What I have done

I created the fragment file and bbappend structure as per the upstream ST recipe layout.

Layer structure:

i added fragment-06-spi.cfg here:

CONFIG_SPI=y

CONFIG_DM_SPI=y

CONFIG_SPI_FLASH=y

CONFIG_SPI_FLASH_STMICRO=y

CONFIG_SPI_FLASH_MTD=y

bbappend:

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

SRC_URI += "file://stm32mp15_trusted_defconfig_fragments/fragment-06-spi.cfg"

As expected, do_generate_defconfig picked up the fragment and merged it into the generated defconfig.

Build failure

The build now fails during do_compile with the following error:

.../tmp-glibc/work-shared/stm32mp1/uboot-source is not clean,

please run 'make mrproper'

This error comes from U-Boot itself, when it detects generated files in the shared source tree. The failure is triggered during:

make -f scripts/Makefile.build obj=scripts

I am attaching:

log.do_compile

It seems that once a .config is generated in work-shared/uboot-source, U-Boot refuses to proceed because Yocto is using an out-of-tree build with O=....

Additional observation

Earlier, I had also hit the check-config.sh failure for CONFIG_SPI being an ad-hoc symbol, which I understand now is because CONFIG_SPI does not exist as a Kconfig symbol in U-Boot 2020.10. I have removed that and now only use symbols that exist in drivers/spi/Kconfig (e.g. CONFIG_DM_SPI, CONFIG_STM32_QSPI, etc.).

However, even after correcting the symbols, the work-shared tree contamination persists, causing the build to abort.

Is there a recommended way to prevent defconfig fragments or do_generate_defconfig from leaving .config inside work-shared?

Thank you again for your guidance. I am attaching the full build logs and directory snapshot for reference.

[Niyas]

I am facing the same issue. Could you please let me know how to fix it?