We tried to integrate the meta-mender-core layer into our WP76XX board (more precisely, a Sierra Wireless FX-30 modem)
We tried two options :
Integrate meta-mender-core layer into a fresh Yocto build
Integrate meta-mender-core layer into our custom Yocto build
In both cases, we faced the same issue when building the app :
ERROR: Unable to parse /home/faunbe/yocto-fx30/swi-linux-src/poky/bitbake/lib/bb/data_smart.py
Traceback (most recent call last):
File "/home/xxx/yocto-fx30/swi-linux-src/poky/bitbake/lib/bb/data_smart.py", line 400, in DataSmart.expandWithRefs(s=":${@mender_features(d, separator=':')}", varname='OVERRIDES_append'):
except Exception as exc:
> raise ExpansionError(varname, s, exc) from exc
bb.data_smart.ExpansionError: Failure expanding variable OVERRIDES_append, expression was :${@mender_features(d, separator=':')} which triggered exception TypeError: getVar() missing 1 required positional argument: 'expand'
Makefile:261: recipe for target 'image_bin' failed
make: *** [image_bin] Error 1
We set the following variables into the local.conf file :
• INHERIT += “mender-full-abi”
• MENDER_FEATURES_ENABLE_append = " mender-image"
• MENDER_SERVER_URL = “https://hosted.mender.io”
• MENDER_TENANT_TOKEN = “our_token”
The bblayers.conf file is correctly filled with meta-mender-core.
We looked at the Mender Hub, but no one seems to have dealt with our board.
We also tried to use the “mender-full” feature, deactivating grub and activating ubi (like in here : Integrating mender on kontron board), but got the same :
• INHERIT += “mender-full”
• MENDER_FEATURES_ENABLE_append = “ mender-uboot mender-image-sd mender-image”
• MENDER_FEATURES_DISABLE_append = “ mender-grub mender-image-uefi”
In fact, any change in locals.conf since to have no effect.
In fact we already have our firmware running on this board, and the bootloader we are using is u-boot.
We “just” want to add the mender layer to this stack.
yeah, you use u-boot on your board, but the GRUB integration (as someone told me yesterday on the mender IRC channel) is the simplest and most times works out of the box , and does not require to patch u-boot .
In that case the boot process goes like this u-boot->GRUB->Linux , so GRUB is just called as a second stage.
If you are stuck , try that , maybe wil work ( BTW i was unlucky on that too XD but i think it’s worth give it a try).
Are you really basing a product on the “Morty” release which is EOL since almost 4 years now? This is strongly discouraged, as you will probably ship a boatload if vulnerabilities straight away, completely negating the idea to make devices more secure.
If I had to guess, then my bet would be on the Yocto builds failing because of release version mixing. Those quite often include changes in the API of bitbake and its libraries, so this would be the first thing to check.
@jkern we support the active LTS releases of Yocto, which at the current moment is only “dunfell”. After the release of the upcoming “kirkstone” it will see the same support.
If you need more help, just let me know. Is the BSP you are using public?
@jkern on a very quick look into the very BSP layer that you linked, i see this which also suggests that it is meant for dunfell (amongst others). So all in all, I would strongly recommend to revisit your build setup, bring it up to a coherent dunfell state and then work out problems from there.
@TheYoctoJester Sorry for the late reply.
In the version we use of this BSP we do not have the information represented by the variable LAYERSERIES_COMPAT_swi-mdm9x28.
# We have a conf and classes directory, add to BBPATH
BBPATH .= ":${LAYERDIR}"
# We have a recipes directory, add to BBFILES
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "swi-mdm9x28"
BBFILE_PATTERN_swi-mdm9x28 := "^${LAYERDIR}/"
BBFILE_PRIORITY_swi-mdm9x28 = "11"
Anyway, we receive the board as is, and it is our work to update.
I know it sounds a bit like making fun of you, but IIRC the LAYERSERIES_COMPAT variable was added in a later release than Morty. So its another peculiarity brought to you by an outdated BSP
But, good news: a layer should (AFAIK) work, respectively parse, without having a declared compatibility. So this won’t be a showstopper.
