I apologize if this isn’t the right category, please feel free to move it if needed.
We’re working with a customer to integrate Yocto Kirkstone with Mender on one of our platforms. Using “master-next” for a proof of concept, I wanted to make that clear just in case it is important to the issue at hand.
The specific platform in question we already have a U-Boot integration for the necessary Mender variables, etc. However we did that work with Buildroot. Moving to Yocto and meta-mender, it seems building U-Boot is a requirement of Mender.
The U-Boot version is ancient, so much so that using newer compilers results in inexplicable issues with RAM.
The U-Boot binary is booted from an embedded storage device, it is not a part of the final disk image.
For all of these reasons, we need to be able to build just mender-client via Yocto. The rest of the integration is manual and should only ever be done once. Any pointers on how to either prevent Mender from trying to build U-Boot (or any bootloader) or create a dummy recipe that claims to provide U-Boot but that the meta-mender layer also doesn’t try to patch?
Set this this package as providing virtual/bootloader and u-boot The current docs say it only needs to provide U-Boot, but, testing shows that virtual/bootloader may be more important here?
cat conf/machine/<machine>.conf
...
# Disable building u-boot
IMAGE_BOOTLOADER = ""
# Tricking Mender to thinking U-Boot is being built
# PREFERRED_PROVIDER_u-boot = "u-boot-fake"
PREFERRED_PROVIDER_virtual/bootloader = "u-boot-fake"
...
And I’m not sure if these are important to the equation or not, but, I did tune what specific features were enabled and disabled:
cat conf/local.conf
# Trying to tune mender features to only what we need
MENDER_FEATURES_DISABLE:append = " mender-bios mender-grub mender-image-bios imender-image-gpt mender-image-ubi mender-image-uefi mender-partuuid mender-ubi mender-uboot"
MENDER_FEATURES_ENABLE:append = " mender-growfs-data mender-image mender-image-sd mender-client-install mender-systemd mender-persist-systemd-machine-id"
Actually (without testing, just looking at the code) there is only one place through which mender-client has a dependency on u-boot, namely here. That depends on the packageconfig, so if
MENDER_FEATURES_DISABLE:append = " mender-uboot"
is set, and you make sure that your build does not add u-boot to the packageconfig (maybe hidden somewhere in an INHERIT, then I think it should build fine without the u-boot dependency.
I may be running in to complications from other Yocto layers. Specifically NXP/Freescale layers as this is an i.MX6 device. See the error below when I remove the fake U-Boot package and removing calling out that virtual/bootloader is provided by it in the machine .conf:
ERROR: Nothing PROVIDES 'virtual/bootloader'
u-boot-variscite PROVIDES virtual/bootloader but was skipped: incompatible with machine <mach> (not in COMPATIBLE_MACHINE)
u-boot-toradex PROVIDES virtual/bootloader but was skipped: Either UBOOT_MACHINE or UBOOT_CONFIG must be set in the <mach> machine configuration.
u-boot-qoriq PROVIDES virtual/bootloader but was skipped: incompatible with machine <mach> (not in COMPATIBLE_MACHINE)
u-boot PROVIDES virtual/bootloader but was skipped: Either UBOOT_MACHINE or UBOOT_CONFIG must be set in the <mach> machine configuration.
u-boot-boundary PROVIDES virtual/bootloader but was skipped: incompatible with machine <mach> (not in COMPATIBLE_MACHINE)
u-boot-qoriq PROVIDES virtual/bootloader but was skipped: incompatible with machine <mach> (not in COMPATIBLE_MACHINE)
u-boot-fslc PROVIDES virtual/bootloader but was skipped: Either UBOOT_MACHINE or UBOOT_CONFIG must be set in the <mach> machine configuration.
u-boot-imx PROVIDES virtual/bootloader but was skipped: Either UBOOT_MACHINE or UBOOT_CONFIG must be set in the <mach> machine configuration.
u-boot-kontron PROVIDES virtual/bootloader but was skipped: incompatible with machine <mach> (not in COMPATIBLE_MACHINE)
ERROR: Required build target '<target>-image' has no buildable providers.
Missing or unbuildable dependency chain was: ['<target>-image', 'virtual/bootloader']
<mach> and <target> are customized machine and target types. Before adding Mender layers to the mix, this error did not appear and no U-Boot was ever built despite the NXP layers really wanting to build u-boot-imx.
I’d appreciate any pointers on tracking down where this sudden dependency is coming from. I’m currently staring at bitbake -e to see if anything stands out. Simply grepping for INHERIT with u-boot through all of the sources doesn’t return any matches.