Imx8mp u-boot-toradex recipe for torizon-core-docker not stable/reproducible

I am running into an issue with the recipes for torizon-core-docker not being stable/rebuildable.

Specifically, I have a meta-layer which has u-boot patches made against torizoncore-6.2.0 (in May of 2023) that no longer compiles due to those same patches now failing to apply against the manifest revision tagged 6.2.0

Further investigation reveals that this is due to u-boot-toradex not being pinned at a specific git revision. meta-toradex-nxp/recipes-bsp/u-boot/
explcitly calls out SRCREV a7d6442796bfd642d680e020ca0a1ce5e9f185b8, but if I go and inspect the fetched version of u-boot-toradex in tmp/work when the build fails, to my surprise it is on 7588eb559ca2bb8b879b87eb2785bcdb423db428 which is the current head of the branch.

This is consistent with the breaking change, which was introduced with a defconfig change in 29db9bfe340d15106c286d5f052d9b6e6bfe7f62, several months after the changes I made were first built.

This seems like a major issue; Yocto builds should be highly reproducible with the same set of layer inputs and not arbitrarily move packages ahead to newer versions just by being built on a different day in the future.

Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:


To address the issue of your U-Boot patches for TorizonCore 6.2.0 not being stable or rebuildable due to changes in the U-Boot Toradex recipe, it’s important to ensure that your Yocto builds are reproducible, which indeed is a fundamental principle of Yocto Project builds.

The problem you’re encountering stems from the SRCREV variable not being used in the SRC_URI for the U-Boot recipe, causing the recipe to fetch the latest commit from the branch instead of a specific commit. This can lead to inconsistencies and build failures if the upstream repository is updated after your patches were created.

To resolve this issue and ensure reproducibility, you can take the following steps:

  1. Pin the SRCREV in Your Layer: Modify your layer’s U-Boot recipe to explicitly set the SRCREV to the commit hash you want to build against. This ensures that Yocto fetches the exact version of U-Boot you have tested your patches with, regardless of future changes to the U-Boot repository.

  2. Use BBMASK to Override the Default Recipe: If your layer includes a modified version of the U-Boot recipe, you can use the BBMASK variable in your local.conf or a distro configuration file to mask the default U-Boot recipe provided by Toradex. This prevents Yocto from considering the default recipe and ensures that your version is used instead.

  3. Review and Update Patches as Necessary: Given that upstream projects like U-Boot are continuously evolving, it’s possible that your patches may need to be updated or reworked to apply cleanly to newer versions of the codebase. Regularly review and test your patches against the latest versions to minimize disruptions.

  4. Leverage Yocto’s SRC_URI Features for Patch Management: When adding patches to a recipe, ensure they are properly managed through the SRC_URI variable, including setting the apply=yes parameter if necessary to automatically apply patches during the build process.

  5. Document and Version-Control Your Changes: Keep detailed records of the changes you make, including the specific commits or tags your patches are based on. Use version control for your meta-layer and document the compatible versions of upstream layers and recipes.

By following these steps, you can improve the stability and reproducibility of your Yocto builds for TorizonCore, ensuring that your U-Boot modifications are applied consistently across builds.

Best regards

Please, also check if these links can help you solve your problem:

Qt for Device Creation (Boot to Qt) | Toradex Developer Center.

Update: I just found the cause after reading about a similar problem caused by unintended forcing of :use-head-next in auto.conf.

Checking my auto.conf reveals this is indeed the case, this flag is present, and after some digging it seems the offending culprit is the following code:

if [ -L "$MANIFEST_FILE" ]; then
    if [ "$(basename `readlink -f "$MANIFEST_FILE"`)" != "default.xml" ]; then
    if ! cat $MANIFEST_FILE | grep -q "torizoncore/default.xml"; then

if [ "$INTEGRATION_BUILD" = "1" ] && [ "$AUTO_CONF_CREATED" = "0" ]; then
    cat > conf/auto.conf <<EOF
# This is needed when building on integration. With use-head-next you
# always get the newest software (u-boot, kernel, aktualizr-torizon, etc).
# Building on integration without use-head-next your build may fail.
DISTROOVERRIDES .= ":use-head-next"


in the setup-environment-internal script.
in my case it is being triggered because I have forked the toradex-manifest repo, added an additional xml file that inherits from default.xml while also including my custom meta-layers (rather than modifying default.xml directly)

I see that makes sense, since your manifest file wasn’t the default the script assumed it was an INTEGRATION_BUILD and thus set use-head-next. This behavior is used in our CI/CD builds for testing.

I suppose you plan to fix this on your side for the time-being. I can bring this up internally if it makes sense to improve this behavior for users with use-cases similar to yours.

Best Regards,

1 Like

Yes, I can work around it on our end for now, but it seems like a subtle-but-dangerous trap that would trip up anyone trying to ensure GPL compliance by way of publishing their layer recipes and an amended/forked manifest that includes them. Definitely had me scratching my head for the better part of a morning why I could no longer get my build to work.

Naturally I don’t have an appreciation for your internal use-case of this capability, but perhaps a happy medium that reduces this risk would be by making the filter/check positive rather than negative - e.g. “if manifest is in (list, presumably integration.xml and next.xml) then…” rather than “if manifest is not default.xml”.

I think the workaround I will implement will make things simpler to manage/move versions ahead on our end so there is no particular pressure from me to address this - at the very least it might be worth adding a note on this in the documentation regarding raw yocto builds and/or the pages relating to license compliance to advise folks of this pitfall.

Good to hear it’s not urgent on your end then. As I said I’ll bring this up to our team for further discussion and consideration.

Best Regards,

1 Like

Just to inform you. Our team has improved the script as seen here: setup-environment-internal: fix detection of integration manifests · torizon/meta-toradex-torizon@7ce1665 · GitHub

Best Regards,

1 Like

Awesome, thank you!