Raspberry Pi 3 with mender zeus error "u-boot-1_2020.01-r0 do_configure: U-Boot configuration rpi_3_32b_config has setting...but Mender expects: CONFIG_ENV_OFFSET=0x400000"

General Discussions
, ,
1

I’m trying mender with raspberry pi 3 on Zeus (latest version on zeus branch) but I’m receiving this error:

ERROR: u-boot-1_2020.01-r0 do_configure: U-Boot configuration rpi_3_32b_config has setting:
CONFIG_ENV_OFFSET=0x800000
CONFIG_ENV_OFFSET_REDUND=0x1000000
but Mender expects:
CONFIG_ENV_OFFSET=0x400000
Please fix U-Boot's configuration file.
(...)
#
# configuration written to .config
#
make[1]: Leaving directory '/home/user/git/zeus/poky/build/tmp/work/my-image1-poky-linux-gnueabi/u-boot/1_2020.01-r0/build'
make: Leaving directory '/home/user/git/zeus/poky/build/tmp/work/my-image1-poky-linux-gnueabi/u-boot/1_2020.01-r0/git'
CONFIG_ENV_SIZE=0x4000
CONFIG_ENV_SIZE=0x4000
CONFIG_ENV_OFFSET=0x800000
WARNING: exit code 1 from a shell command.

The same of this discussion Raspberrypi cm3 zeus-test issues.

I applied the suggested config in meta-mender-raspberrypi readme.md fil,

bitbake -e my-image | grep ^MENDER_PARTITION_ALIGNMENT= returns MENDER_PARTITION_ALIGNMENT="4194304"

and

bitbake -e my-image | grep ^MENDER_BOOT_PART_SIZE_MB= returns
MENDER_BOOT_PART_SIZE_MB="40"

My configuration is:

RPI_USE_U_BOOT = "1"

IMAGE_INSTALL_append = " kernel-image kernel-devicetree"

IMAGE_FSTYPES_remove += " rpi-sdimg"
SDIMG_ROOTFS_TYPE = "ext4"

DISTRO_FEATURES_append = " systemd"
VIRTUAL-RUNTIME_init_manager = "systemd"
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
VIRTUAL-RUNTIME_initscripts = ""

MENDER_FEATURES_ENABLE_append = " mender-image mender-uboot mender-image-sd"
MENDER_FEATURES_DISABLE_append = " mender-grub mender-image-uefi"
 
MENDER_PARTITION_ALIGNMENT = "4194304"
MENDER_BOOT_PART_SIZE_MB = "40"

Do you have any suggestions?

2

Did you check if mentioned patches are applied: Raspberrypi cm3 zeus-test issues ?

3

I checked with devtool modify u-boot and I can see these patches applied:

  • Add missing header which fails on recent GCC
  • Generic boot code for mender
  • Integration of mender boot code into u-boot
  • configs: rpi: enable mender requirements
  • rpi: Drop reading of fdt_addr from environment

In the rpi 3 3b git config I can see that CONFIG_ENV_OFFSET=0x800000 is the wrong value, but also in the patch file there is this wrong value.
Patch file called “0001-configs-rpi-enable-mender-requirements.patch” contains this:

…
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_ENV_OFFSET=0x800000
+CONFIG_ENV_OFFSET_REDUND=0x1000000
+CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
…

Instead in a patch posted in the other discussion contains this:

+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_ENV_OFFSET=0x400000
+CONFIG_ENV_OFFSET_REDUND=0x800000
+CONFIG_SYS_REDUNDAND_ENVIRONMENT=y

I thought that this patch was already applied to the zeus branch, but these files are different. However the date is the same “371400a8772d5f6ae4b819ef91cd36b883a8d313 Mon Sep 17 00:00:00 2001 and Tue, 26 Sep 2017 06:23:52 -0400”.

Should I replace the current patch file with this one? If yes, there is a reason why this wasn’t applied to zeus branch? Something that I should check before to say “it’s ok”.

Thanks.

4

@kacf ideas? @Ks89 any reason why you cannot bump to dunfell? It’s LTS relase so much longer supported then zeus.

5

No specific reason, but I was already using zeus, so to not re-init the environment again downloading everything I decided to use zeus.
I can upgrade to dunfell. Do you think that it’s more stable than the zeus branch?

6

Remove this part. Previously, it was (incorrectly) documented that this should be added to local.conf, but this brought RPi out of line with all other boards, so we removed it for zeus. The reason it worked in previous branches is that the patching methods were different, and they automatically fixed this behind your back. This is no longer possible for zeus and later branches, the alignment and the patch need to match.

Note that even if you have devices that are deployed with the old setting, it is safe to upgrade them, because the setting is only used in fw_env.config, which is stored on the data partition. Hence existing devices will retain their existing alignment, even if you upgrade.

2 Likes
7

thank you, it worked