PR 1659 breaks my build for machine `imx8mm-var-dart`. Variable `UBOOT_CONFIG_EXTRA` is not set.

[otavio]

          Looks like this PR breaks my build for machine `imx8mm-var-dart`. Variable `UBOOT_CONFIG_EXTRA` is not set.

If I check the error message then following line 94/imx-boot_1.0.bb has changed and results in u-boot-spl.bin-imx8mm-var-dart- instead of u-boot-spl.bin-imx8mm-var-dart-sd.

How to fix UBOOT_CONFIG_EXTRA?

Originally posted by @Umdrahschua in https://github.com/Freescale/meta-freescale/issues/1659#issuecomment-1757021752

[JPSGoncalves]

I took a look at this. For me this is working fine (testing on a imx8mm too). UBOOT_CONFIG_EXTRA must be the same as the values in UBOOT_CONFIG, even for only one configuration. I think we need to know a bit more like what are the values in UBOOT_CONFIG and UBOOT_DTB_NAME as these are the ones that set the value in UBOOT_CONFIG_EXTRA. One thing, if you try to use compile_mx8m on its own (outside do_compile of imx-boot), this will fail and you need to set UBOOT_CONFIG_EXTRA manually.

[Umdrahschua]

I'm using an eval kit from Variscite. The conf file for machine can be find here imx8mm-var-dart.conf.

$ bitbake-getvar -r core-image-minimal UBOOT_CONFIG
#
# $UBOOT_CONFIG [3 operations]
#   set .../meta-variscite-bsp-imx/conf/machine/imx8mm-var-dart.conf:33
#     [_defaultval] "sd"
#   set .../meta-variscite-bsp-imx/conf/machine/imx8mm-var-dart.conf:34
#     [sd] "imx8mm_var_dart_config,sdcard"
#   set .../poky/meta/conf/documentation.conf:447
#     [doc] "Configures the UBOOT_MACHINE and can also define IMAGE_FSTYPES for individual cases."
# pre-expansion value:
#   "sd"
UBOOT_CONFIG="sd"
$ bitbake-getvar -r core-image-minimal UBOOT_CONFIG_EXTRA
#
# $UBOOT_CONFIG_EXTRA
#   [no history recorded]
#
#   "None"
$ bitbake-getvar -r core-image-minimal UBOOT_DTB_NAME    
#
# $UBOOT_DTB_NAME
#   set .../meta-variscite-bsp-imx/conf/machine/imx8mm-var-dart.conf:52
#     "imx8mm-var-dart-customboard.dtb"
UBOOT_DTB_NAME="imx8mm-var-dart-customboard.dtb"

One thing, if you try to use compile_mx8m on its own (outside do_compile of imx-boot), this will fail and you need to set UBOOT_CONFIG_EXTRA manually.

Do I understand this correct. My imx-boot_1.0.bbappend file overrides do_compile(). The origin do_compile sets UBOOT_CONFIG_EXTRA. And this means, I have to set it manually (or fix layer meta-variscite-bsp-imx).

[JPSGoncalves]

If you are overriding do_compile() of imx-boot on your .bbappend, you will need to set UBOOT_CONFIG_EXTRA manually to the same value as UBOOT_CONFIG ( UBOOT_CONFIG_EXTRA="sd" or UBOOT_CONFIG_EXTRA=${UBOOT_CONFIG} ). However, this only work when you have only one configuration (and this seems to be your case). Maybe is better to fix your layer to work with meta-freescale without overriding do_compile() as a more general solution.

[Umdrahschua]

Okay. Thank you very much @JPSGoncalves. I think I understand the issue.

Maybe is better to fix your layer to work with meta-freescale without overriding do_compile() as a more general solution.

Yes, this sounds good. But it's not my layer, I'm just using it. I have to see how I can get this solved well.

[otavio]

Yes, Variscite must fix it. Closing it.

[manszigher]

A potential workaround for this issue is to make sure that we keep the previous do_compile that Variscite seems to depend on. The way todo that is to define your own imx-boot_1.0.bbappend and include the following

UBOOT_NAME = "u-boot-${MACHINE}.bin-${UBOOT_CONFIG}"
BOOT_CONFIG_MACHINE = "${BOOT_NAME}-${MACHINE}-${UBOOT_CONFIG}.bin"
compile_mx8m() {
    bbnote 8MQ/8MM/8MN/8MP boot binary build
    for ddr_firmware in ${DDR_FIRMWARE_NAME}; do
        bbnote "Copy ddr_firmware: ${ddr_firmware} from ${DEPLOY_DIR_IMAGE} -> ${BOOT_STAGING} "
        cp ${DEPLOY_DIR_IMAGE}/${ddr_firmware}               ${BOOT_STAGING}
    done
    cp ${DEPLOY_DIR_IMAGE}/signed_dp_imx8m.bin               ${BOOT_STAGING}
    cp ${DEPLOY_DIR_IMAGE}/signed_hdmi_imx8m.bin             ${BOOT_STAGING}
    cp ${DEPLOY_DIR_IMAGE}/u-boot-spl.bin-${MACHINE}-${UBOOT_CONFIG} \
        ${BOOT_STAGING}/u-boot-spl.bin
    cp ${DEPLOY_DIR_IMAGE}/${BOOT_TOOLS}/${UBOOT_DTB_NAME}   ${BOOT_STAGING}
    if [ "x${UBOOT_SIGN_ENABLE}" = "x1" ] ; then
        # Use DTB binary patched with signature node
        cp ${DEPLOY_DIR_IMAGE}/${UBOOT_DTB_BINARY} ${BOOT_STAGING}/${UBOOT_DTB_NAME}
    fi
    cp ${DEPLOY_DIR_IMAGE}/${BOOT_TOOLS}/u-boot-nodtb.bin-${MACHINE}-${UBOOT_CONFIG} \
        ${BOOT_STAGING}/u-boot-nodtb.bin
    cp ${DEPLOY_DIR_IMAGE}/${ATF_MACHINE_NAME}               ${BOOT_STAGING}/bl31.bin
    cp ${DEPLOY_DIR_IMAGE}/${UBOOT_NAME}                     ${BOOT_STAGING}/u-boot.bin
}

This is a simple way to revert the change in kirkstone that breaks the Variscite docompile. Comes with some risks since we will not follow the meta-freescale intended result but could be used as a workaround until Variscite fixes this not sure when that will happen since they seem to be stuck on an old kirkstone release. Keep in mind that you should override the corresponding compile${SOC_FAMILY} to your machine since that is what variscite do_compile will call when building.