Trying to adapt mender for honister (petalinux 2022.1)

not sure this belongs in board integration, this question is more relevant to newer petalinux/yocto build system. so not only board support exists, but also as i understand latest supported build system is dunfell.

Board description

MACHINE ??= “zynqmp-generic”

we have added mender layers, used meta-mender repository, also trying to test third party meta-mender-zynq repository.

that made us make some syntactic changes in meta-mender like:

SOMETHING_append = " something"

have been changed to

SOMETHING:apppend = " something"

by changing syntax in mender layers we were able to pass initial petalinux-config --get-hw-descriptor …

but with petalinux-config -c u-boot i am getting errors like:

[INFO] Configuring: u-boot
[INFO] bitbake virtual/bootloader -c menuconfig
NOTE: Started PRServer with DBfile: /path/to/our/petalinux/build/cache/prserv.sqlite3, Address: 127.0.0.1:40005, PID: 5376
ERROR: /path/to/our/petalinux/components/yocto/layers/core/meta/recipes-connectivity/openssh/openssh_8.7p1.bb: Variable RDEPENDS_${PN}-sshd_append_vexpress-qemu contains an operation using the old override syntax. Please convert this layer/metadata before attempting to use with a newer bitbake.

this is strange because the project was building fine without adding mender layers. then all the problems that occurred were inside the mender source tree and required changes there.

it looks like now the changes required by build system are inside our existing project. wild guess: maybe bitbake version might have supported both the old and new syntax previously, but with the addition of mender it might now enforce the newer syntax more strictly even in our existing files, which were building fine without mender layers.

p. s. when do you think honister (2022.1) support will be added to mender?

Hello @noch,

This one needs to be migrated to

RDEPENDS:${PN}...

Can you double check?

We only support Yocto LTS versions. We support Kirkstone and Scarthgap I think is almost there (it may be ready now, I am unsure). @TheYoctoJester can confirm.

Luis

1 Like

thank you. with your suggestion i was able to reach past that step.

then fixed a couple more problems. i will maybe update here or write another question.

scarthgap is fully ready :-), see GitHub - mendersoftware/meta-mender: Yocto Project meta layer for the Mender client

i tried kirkstone branch, renamed it as honister, and changed the ‘kirkstone’ name in configs to honister. it looks like kirkstone is much much closer to honister, than dunfell. it required no syntactic changes so far in mender sources.

then i am again trying to adapt it:

in project-spec/meta-user/conf/bblayers.conf (before i was adding the lines to build/conf/bblayers.conf):

BBLAYERS += "/some/absolute/path/layers/meta-mender/meta-mender-core"
BBLAYERS += "/some/absolute/path/layers/meta-mender/meta-mender-demo"

in the same directory i have created mender.conf (previously was including these lines in build/conf/local.conf):

MENDER_SERVER_URL = "https://hosted.mender.io"
MENDER_TENANT_TOKEN = "some test token of my account"

MENDER_FEATURES_ENABLE:append = " mender-uboot mender-client-install"
MENDER_FEATURES_DISABLE:append = " mender-grub mender-image-uefi mender-image-gpt mender-image-sd mender-partuuid"
MENDER_STORAGE_DEVICE = "/dev/mtd4"
MENDER_MTDPARTS = "40000000.flash:2m(boot),512k(bootenv),512k(bootscr),24m(kernel),-(rootfs)"
MENDER_MTDIDS = "nor0=40000000.flash"
MENDER_STORAGE_PEB_SIZE = "262144"
# Erase block size from mtdinfo -a

MENDER_STORAGE_TOTAL_SIZE_MB = "64"
MENDER_IMAGE_BOOTLOADER_FILE = "BOOT.BIN"

MENDER_ARTIFACT_NAME = "release-1"
ARTIFACTIMG_FSTYPE = "jffs2"

MENDER_UBOOT_STORAGE_INTERFACE = "spi"
MENDER_UBOOT_STORAGE_DEVICE = "0"
PREFERRED_PROVIDER_u-boot = "u-boot-xlnx"
PREFERRED_PROVIDER_virtual/bootloader = "u-boot-xlnx"

some comments. our board has 64mb of QSPI storage. it has only one rootfs as jffs2, all partitions are /dev/mtdX, and it would be very painful to change the partition layout again, but we have no specific partition for mender data like logs.

so first of all, i am not sure i correctly disabled features for having only one rootfs.
i also created meta-user/recipes-core/images directory and added ‘petalinux-custom-image.bb’ file there with the following content:

SUMMARY = "Our PetaLinux Image with Mender"
DESCRIPTION = "This is a custom image recipe for PetaLinux that includes Mender support."
LICENSE = "MIT"

IMAGE_INSTALL = "\
    base-files \
    packagegroup-core-boot \
    ${ROOTFS_PKGS} \
    mender-client \
    mtd-utils \
    "

IMAGE_FSTYPES = "jffs2"

when the file contains errors, the project doesn’t build, so the file gets picked up.

in build/conf/local.conf i added:

include ${TOPDIR}/../project-spec/meta-user/conf/mender.conf

so even petalinux-build -x cleanall now results in:

ERROR: Nothing RPROVIDES 'mender' (but /opt/data/norayr/MA-ZX2-20-2I-D9_ST3_QSPI/components/yocto/layers/meta-petalinux/recipes-core/images/petalinux-image-minimal.bb RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'mender' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['mender']
NOTE: Runtime target 'kernel-modules' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['kernel-modules', 'petalinux-image-minimal', 'mender']
ERROR: Required build target 'petalinux-image-minimal' has no buildable providers.
Missing or unbuildable dependency chain was: ['petalinux-image-minimal', 'mender']

so we’ve tried with:

IMAGE_INSTALL:append += " mender-client"
and
IMAGE_INSTALL:append += " mender"

it is not clear which recipe should be enabled for our setup.

when i was working on dunfell branch, eventually i reached the same state.

when i tried in layers directory: find . name "*.bb" | grep mender, i can see that there are no file named exactly ‘mender-client.bb’, but there are several recipes related to the mender client that are defined within the meta-mender repository.

the main recipe file for the mender client seems to be named mender_*.bb (e.g., mender_4.0.4.bb), not mender-client.bb.

more general questions are: so there is a userspace mender binary. at some point i managed to crosscompile it for arm, and add to petalinux as binary in /usr/bin. it didn’t start because it required systemd. was there a way to build it by disabling systemd dependency?
and if so, did it make sense?

would having only mender binary in rootfs allow to download an update image and flush to mtd partition?
why exactly should it be integrated with u-boot? in order to download and flash update on boot?

thank you.

@lramirez Could you please take a look on this issue?

Hello folks,

Some observations, please let me know if I left anything behind:

ERROR: Nothing RPROVIDES ‘mender’ (but /opt/data/norayr/MA-ZX2-20-2I-D9_ST3_QSPI/components/yocto/layers/meta-petalinux/recipes-core/images/petalinux-image-minimal.bb RDEPENDS on or otherwise requires it)

This problem comes from:

IMAGE_INSTALL:append += " mender-client"
and
IMAGE_INSTALL:append += " mender"

In the past (old releases) it was “mender”, then it changed to “mender-client” in more recent ones. After the release of Mender client 4 (based on C++) now there are multiple binaries instead of one. In summary, for Mender 3.XX, use mender-client, for Mender 4.XX add “mender-auth” and “mender-update”.

Yocto side note, the += is not necessary and the :append is enough.

On the other end, the following line should be enough:

MENDER_FEATURES_ENABLE:append = " mender-client-install" 

Regarding

MENDER_FEATURES_ENABLE:append = " mender-uboot mender-client-install"

You don’t need mender-uboot if you are not enabling A/B partitions. You can remove it or even add it to the DISABLE variable in case you inherit mender-full.

1 Like

ok, so if we don’t need u-boot in case of one rootfs, then i am right that the result of mender integration would mean to have a mender binary somewhere in rootfs, in /usr/bin for example? and mender config in /etc?

if so, i was able to crosscompile for arm mender once with cgo (maybe as described here mender command - github.com/mendersoftware/mender - Go Packages) and the resulting arm binary i was able to integrate in to the build, and it was possible to run it on our board, but it required systemd. since that’s a petalinux os, it has no systemd.

so since we only need mender on rootfs, may it be that our problems will be solved if we were able to build mender with cgo in a way that it would not require systemd? does it have such a build option, or is it possible to build it in such a way at all?

thank you.