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]

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?

[Niyas]

Hi @Erwan SZYMANSKI  

I have recently taken over this task from @shreyaschandran , as he is no longer working on it. I am currently stuck on this issue. Could you please guide me with the steps to resolve it?