Mender on iMX8 Plus U-Boot Setup Errors

Board description

AvNet IMX8 Plus

Hello,

I’m new to mender and trying to run it in conjunction with a demo server on an avnet imx8 board. After following the instructions in the docs and fixing some other build errors, the build is completing and the built image boots on the board. However, whenever I try to perform an update or mender setup or mender bootstrap I receive the following error:

Failed to read the current active partition: No match between boot and root partitions.

In following the steps from the integration checklist, I noticed that in my /etc/fw_env.config the wrong device is referenced. It initially referenced /dev/mmcblk0 so I changed it to reference the proper device which is /dev/mmcblk1 (this device is shown in the first line of output after running mount). After this change the error expands to the following:

ERRO[0000] Failed to read the current active partition: No match between boot and root partitions.: Failed mender_saveenv_canary check. There is an error in the U-Boot setup. Likely causes are: 1) Mismatch between the U-Boot boot loader environment location and the location specified in /etc/fw_env.config. 2) ‘mender_setup’ is not run by the U-Boot boot script: exit status 1

I am suspecting that it is cause number 2. When I interrupt the board’s boot to enter u-boot config, the printenv command yields entirely different variables than those that appear when I run fw_printenv in the linux environment. So I don’t think that the system is using the mender-modified version of u-boot or it for some reason isn’t getting modified.

The yocto build currently has MENDER_UBOOT_AUTO_CONFIGURE enabled and like I said I have followed the listed steps for U-Boot integration from here:

If anyone has seen an issue like this or has any insight, I would greatly appreciate your help.
Thanks

Hi @pgthompson24!

It’s somewhat ‘hidden’ in the last paragraph, but this is a Yocto build that you set up, right? So I would suggest to start out by diagnosing the bootloader in use. An idea on how to get going would be bitbake -e virtual/bootloader | less and see which u-boot is being put to use. If you do not see the Mender integration kicking in there, then this is probably the culprit.

If you can link to the BSP/Documentation you used for the integration build then I can also have a look.

Greetz,
Josef

Hi Josef,

Thanks for the reply. I realize now I didn’t make this very clear but yes this is a yocto build using the zeus branches of the meta-mender-core and meta-mender-demo layers. I followed this guide to integrate mender with the build in addition to these steps for u-boot.

That bitbake command you gave gives a lot of output but from what I can glean from it the build is using the u-boot-imx bootloader which is the one we made a bbappend for so that it would use mender. Is there something in there I can look at so make sure it is specifically doing the mender stuff to the bootloader?

I would probably check if the mender layers are patching the necessary uboot related recipes. You can use bitbake-layers show-appends command and/or bitbake -c patch <recipe> and check the patched sources to make sure mender integration is inplace.

Use bitbake -vn virtual/bootloader to check which bootloader recipe your build is using.

The other recipe of note of u-boot-distro-boot as there’s some mender specific setup there as well

1 Like

Thanks whsplk,

When checking the show-appends, it does appear my patch is being applied

u-boot-imx_2018.03.bb:
/workdir/osdev/fng-bsp/sources/01047/msc-ldk-bsp-recipes.git/meta/recipes-bsp/u-boot/u-boot-imx_%.bbappend
/workdir/osdev/fng-bsp/sources/meta-fng/recipes-bsp/u-boot/u-boot-imx_%.bbappend
u-boot-imx_2020.04.bb:
/workdir/osdev/fng-bsp/sources/01047/msc-ldk-bsp-recipes.git/meta/recipes-bsp/u-boot/u-boot-imx_%.bbappend
/workdir/osdev/fng-bsp/sources/meta-fng/recipes-bsp/u-boot/u-boot-imx_%.bbappend

And according to bitbake -vn virtual/bootloader | grep boot, the right bootloader is being used:

NOTE: selecting u-boot-imx to satisfy virtual/bootloader due to PREFERRED_PROVIDERS
NOTE: selecting u-boot-imx to satisfy runtime u-boot-imx-dev due to PREFERRED_PROVIDER_virtual/bootloader = u-boot-imx
NOTE: selecting u-boot-imx to satisfy runtime u-boot-imx due to PREFERRED_PROVIDER_virtual/bootloader = u-boot-imx

And bitbake couldn’t find anything when I searched that last recipe you mentioned. Maybe that is my issue? Also for clarity, this is the patch I am applying to u-boot-imx:

u-boot has to integrate directly with mender

require recipes-bsp/u-boot/u-boot-mender.inc
PROVIDES += “u-boot”
RPROVIDES_${PN} += “u-boot”

So is there something wrong with my append file or is there more I need to add to it? Or should I try to track down why I don’t have the u-boot-distro-boot recipe? Thanks again for any help here.

yea probably, Im not an uboot expert but for my board (from toradex), their recipes have a patch to the boot script (meta-mender-community/0001-Adapt-boot.cmd.in-to-Mender.patch at dunfell · mendersoftware/meta-mender-community · GitHub). This gets compiled down to a boot.scr file in my boot directory which reflects these changes.

Several other bsp layers does this too (for e.g meta-mender-community/boot.cmd.in at dunfell · mendersoftware/meta-mender-community · GitHub and meta-mender/boot.cmd.in at master · mendersoftware/meta-mender · GitHub)

I would imagine you would need to implement something similar as well (or atleast check that the mender_* commands are being called during boot