Bleeding edge Yocto and raspberry pi 4

Due to the requirements of some very recent software packages we are building our system using Yocto master. Even Mender master does not seem to have the changes re override syntax introduced with Honister. I found mention on the on the Arm Research SMARTER site re them using a local repo for Mender with the related changes applied but the repo that they have does not appear to actually have these changes. Is anybody aware of any other existing repos with fixed up Mender? I have had a go at running the later conversion scripts but currently trying to get to the bottom of it causing a circular dependency loop in grub, which seems odd as mender for our target (RPi cm4) is supposed to be using u-boot.

I have found some borkage and missing changes from the layer conversion script which is the reason for it trying to use grub still. but still if anybody knows of an already working version of mender anyway do pipe up :slight_smile:

Take a look at the master-next branch. It’s not maintained currently, but this branch holds some commits that we have collected which will eventually be needed when we move meta-mender to a new stable poky branch, including the one you need. You can try to cherry-pick from there.

I have made it to the point where the image tries to build but it is failing. One of the errors I’m trying to understand now is saying:

the basehash value changed from <hash 1> to <hash 2>. The metadata is not deterministic and th
is needs to be fixed.

Having looked into it a bit it would appear something strange is happening.

I have enabled the sigbasedata files as per yocto - Bitbake: "The metadata is not deterministic and this needs to be fixed" - Stack Overflow.

In the mender-bootimg.bblcass file the following is used a couple of times to build a path ${WORKDIR}/bootfs.${BB_CURRENTTASK}/

bitbake-diffsigs shows that the thing that is changing is the string derived from the variable BB_CURRENTTASK, but I don’t understand quite how this can happen.

e.g. under my image stamps dir I have a bunch of different 1.0-r0.do_image_bootimg.sigbasedata. files.

In each one the value from BB_CURRENTTASK is something different! I don’t understand how it is anything other than image_bootimg, i.e. the taskname recorded in the log filename.

I have

  • image_tar
  • image_ext3
  • image_bootimg
  • image_wic
  • image_mender
  • image
  • flush_pseudodb
  • rootfs
  • image_dataimg
  • image_ext4
  • rootfs_wicenv

There is also one or more .sigbasedata files for each of the above which is as I would expect.

Any ideas what might be going on?

Actually it appears that wic-tools unconditionally pulls in grub.

Having slogged away at this a bit more i have an image, and u-boot starts… but it stops and says nothing further at “Starting kernel …”
I have seen some comments re this and needing to use KERNEL_IMAGETYPE = “uImage”, however this is not an option as we are using aarch64.

I should add that there are still a load of errors output during the build re things not being deterministic. Also having looked at the content of the BOOT filesystem produced, there is a whole bunch of files and dirs named with random chars that looks like a corrupt filesystem.

ah, wrote it with dd instead of bmaptool and it booted! weird, the sdimg has a .bmap counterpart so assumed it was ok to use bmaptool with it.

For anybody else who might be interested I have this seemingly all working now. GitHub - mangodan2003/meta-mender: Yocto Project meta layer for the Mender client

The only outstanding issue I have atm is re flashing the image with bmaptool which for somereason results in a system that wont boot.

The issue with using bmaptool seems to be something to do with the random data that might be on the device in the holes that it doesn’t write too. Maybe u-boot scans this space for non zero values and gets confused by it, just a guess. anyway it can be worked around by zeroing out the first area of the target device with dd. I haven’t experimented much but writing 128MB of zeros resolves the issue.