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.