Mender integration of STM32MP157C on dunfell

Thanks for the reply @mirzak .

we have 4 files in /etc related to fw_env :

fw_env.config (symbolic link to /data/u-boot/fw_env.config)

the content of fw_env.config file in /data/u-boot/ is:

/dev/mmcblk0 0x800000 0x20000
/dev/mmcblk0 0x1000000 0x20000

Maybe the problem is that we have a symbolic link in /etc insted of the real file?
We aren’t able to undestand if this file is correct. There are two refs to mmcblk0 is this correct?

thank you

This file should be a symbolic link.

There are two refs to mmcblk0 is this correct?

This is correct, these are redundant environment for robustness.

I am curious, if you can halt U-Boot and share the output of printenv to start off.

How can i do that? It’s not the same as fw_printenv command?

Hi @mirzak,

Here our printenv

altbootcmd=run bootcmd
android_mmc_boot=mmc dev {devnum};run android_mmc_splash;run android_mmc_fdt;run android_mmc_kernel;bootm {kernel_addr_r} - {fdt_addr_r}; android_mmc_fdt=if part start mmc {devnum} dt_{suffix} dt_start &&part size mmc {devnum} dt_{suffix} dt_size;then mmc read {dtimg_addr} {dt_start} {dt_size};dtimg getindex {dtimg_addr} {board_id} {board_rev} dt_index;dtimg start {dtimg_addr} {dt_index} fdt_addr_r;fi android_mmc_kernel=if part start mmc {devnum} boot_{suffix} boot_start &&part size mmc {devnum} boot_{suffix} boot_size;then mmc read {kernel_addr_r} {boot_start} {boot_size};part nb mmc {devnum} system_{suffix} rootpart_nb;env set bootargsroot=/dev/mmcblk${devnum}p${rootpart_nb} androidboot.serialno={serial#} androidboot.slot_suffix=_{suffix};fi
android_mmc_splash=if part start mmc {devnum} splash splash_start && part size mmc {devnum} splash splash_size;then mmc read {splashimage} {splash_start} {splash_size};cls; bmp display {splashimage} m m;fi
boot_a_script=load {devtype} {devnum}:{distro_bootpart} {scriptaddr} {prefix}{script}; source {scriptaddr} boot_device=mmc boot_efi_binary=if fdt addr {fdt_addr_r}; then bootefi bootmgr {fdt_addr_r};else bootefi bootmgr {fdtcontroladdr};fi;load {devtype} {devnum}:{distro_bootpart} {kernel_addr_r} efi/boot/bootarm.efi; if fdt addr {fdt_addr_r}; then bootefi {kernel_addr_r} {fdt_addr_r};else bootefi {kernel_addr_r} {fdtcontroladdr};fi boot_extlinux=sysboot {devtype} {devnum}:{distro_bootpart} any {scriptaddr} {prefix}{boot_syslinux_conf} boot_instance=0 boot_m4fw=rproc init; rproc load 0 {m4fw_addr} {filesize}; rproc load_rsc 0 {m4fw_addr} {filesize}; rproc start 0 boot_net_usb_start=true boot_prefixes=/ /boot/ boot_script_dhcp=boot.scr.uimg boot_scripts=boot.scr.uimg boot.scr boot_syslinux_conf=extlinux/extlinux.conf boot_targets=mmc0 bootargs=root={mender_kernel_root} rootwait rw console=ttySTM0,115200
bootcmd=run bootcmd_stm32mp
bootcmd_android=env set mmc_boot run android_mmc_boot;run bootcmd_stm32mp
bootcmd_mmc0=devnum=0; run mmc_boot
bootcmd_mmc1=devnum=1; run mmc_boot
bootcmd_mmc2=devnum=2; run mmc_boot
bootcmd_pxe=run boot_net_usb_start; dhcp; if pxe get; then pxe boot; fi
bootcmd_stm32mp=echo “Boot over {boot_device}{boot_instance}!”;if test {boot_device} = serial || test {boot_device} = usb;then stm32prog {boot_device} {boot_instance}; else run env_check;if test {boot_device} = mmc;then env set boot_targets "mmc{boot_instance}"; fi;if test {boot_device} = nand || test {boot_device} = spi-nand ;then env set boot_targets ubifs0; fi;if test {boot_device} = nor;then env set boot_targets mmc0; fi;run distro_bootcmd;fi; bootcmd_ubifs0=devnum=0; run ubifs_boot bootcount=1 bootdelay=1 bootfstype=fat bootlimit=1 cpu=armv7 devplist=4 distro_bootcmd=for target in {boot_targets}; do run bootcmd_{target}; done dtimg_addr=0xc4500000 efi_dtb_prefixes=/ /dtb/ /dtb/current/ env_check=env exists env_ver || env set env_ver {ver};if env info -p -d -q; then env save; fi;if test “$env_ver” != “ver"; then echo "*** Warning: old environment {env_ver}”; echo ‘* set default: env default -a; env save; reset’; echo '* update current: env set env_ver {ver}; env save';fi; env_ver=U-Boot 2020.01-stm32mp-r1 (Jan 06 2020 - 20:56:31 +0000) ethaddr=00:80:e1:42:75:c6 fdt_addr_r=0xc4000000 fdtcontroladdr=d7aec960 fdtfile=stm32mp157c-dk2.dtb fileaddr=c4100000 filesize=3ba kernel_addr_r=0xc2000000 load_efi_dtb=load {devtype} {devnum}:{distro_bootpart} {fdt_addr_r} {prefix}{efi_fdtfile} loadaddr=0xc2000000 m4fw_addr=0xc2000000 m4fw_name=rproc-m4-fw.elf mender_altbootcmd=if test {mender_boot_part} = 5; then setenv mender_boot_part 6; setenv mender_boot_part_hex 6; else setenv mender_boot_part 5; setenv mender_boot_part_hex 5; fi; setenv upgrade_available 0; saveenv; run mender_setup
mender_setup=if test “{mender_saveenv_canary}" != "1"; then setenv mender_saveenv_canary 1; saveenv; fi; if test "{mender_pre_setup_commands}” != “”; then run mender_pre_setup_commands; fi; if test “{mender_systemd_machine_id}" != ""; then setenv bootargs systemd.machine_id={mender_systemd_machine_id} {bootargs}; fi; setenv mender_kernel_root /dev/mmcblk0p{mender_boot_part}; if test {mender_boot_part} = 5; then setenv mender_boot_part_name /dev/mmcblk0p5; else setenv mender_boot_part_name /dev/mmcblk0p6; fi; setenv mender_kernel_root_name {mender_boot_part_name}; setenv mender_uboot_root mmc 0:{mender_boot_part_hex}; setenv mender_uboot_root_name {mender_boot_part_name}; setenv expand_bootargs “setenv bootargs \”{bootargs}\\""; run expand_bootargs; setenv expand_bootargs; if test "{mender_post_setup_commands}” != “”; then run mender_post_setup_commands; fi
mender_try_to_recover=if test {upgrade_available} = 1; then reset; fi mender_uboot_boot=mmc 0:4 mender_uboot_dev=0 mender_uboot_if=mmc mmc_boot=if mmc dev {devnum}; then devtype=mmc; run scan_dev_for_boot_part; fi
scan_dev_for_boot=echo Scanning {devtype} {devnum}:{distro_bootpart}...; for prefix in {boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi;
scan_dev_for_boot_part=part list {devtype} {devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in {devplist}; do if fstype {devtype} {devnum}:{distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done; setenv devplist
scan_dev_for_efi=setenv efi_fdtfile {fdtfile}; if test -z "{fdtfile}" -a -n "{soc}"; then setenv efi_fdtfile {soc}-{board}{boardver}.dtb; fi; for prefix in {efi_dtb_prefixes}; do if test -e {devtype} {devnum}:{distro_bootpart} {prefix}{efi_fdtfile}; then run load_efi_dtb; fi;done;if test -e {devtype} {devnum}:{distro_bootpart} efi/boot/bootarm.efi; then echo Found EFI removable media binary efi/boot/bootarm.efi; run boot_efi_binary; echo EFI LOAD FAILED: continuing...; fi; setenv efi_fdtfile scan_dev_for_extlinux=if test -e {devtype} {devnum}:{distro_bootpart} {prefix}{boot_syslinux_conf}; then echo Found {prefix}{boot_syslinux_conf}; run boot_extlinux; echo SCRIPT FAILED: continuing…; fi
scan_dev_for_scripts=for script in {boot_scripts}; do if test -e {devtype} {devnum}:{distro_bootpart} {prefix}{script}; then echo Found U-Boot script {prefix}{script}; run boot_a_script; echo SCRIPT FAILED: continuing…; fi; done
scan_m4fw=if test -e {mender_kernel_root} /boot/{m4fw_name};then echo Found M4 FW m4fw_name; if load {mender_uboot_boot} {m4fw_addr} /boot/{m4fw_name}; then run boot_m4fw; fi; fi;
ubifs_boot=env exists bootubipart || env set bootubipart UBI; env exists bootubivol || env set bootubivol boot; if ubi part {bootubipart} && ubifsmount ubi{devnum}:{bootubivol}; then devtype=ubi; run scan_dev_for_boot; fi upgrade_available=0 usb_boot=usb start; if usb dev {devnum}; then devtype=usb; run scan_dev_for_boot_part; fi
ver=U-Boot 2020.01-stm32mp-r1 (Jan 06 2020 - 20:56:31 +0000)
Environment size: 7560/8187 bytes

Edit :
Looking at our boot process we get an error related to a mender service : mender-grow-data
Going in deep we get the failure:

root@stm32mp1-disco:~# systemctl status mender-grow-data
mender-grow-data.service - Mender service to grow data partition size
Loaded: loaded (/lib/systemd/system/mender-grow-data.service; disabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Mon 2020-11-16 12:35:13 UTC; 1min 3s ago
Process: 425 ExecStart=/usr/bin/mender-client-resize-data-part (code=exited, status=1/FAILURE)
Main PID: 425 (code=exited, status=1/FAILURE)
Nov 16 12:35:12 stm32mp1-disco systemd[1]: Starting Mender service to grow data partition size…
Nov 16 12:35:13 stm32mp1-disco mender-client-resize-data-part[444]: Warning: Partition /dev/mmcblk0p4 is being used. Are you sure you want to continue?
Nov 16 12:35:13 stm32mp1-disco systemd[1]: mender-grow-data.service: Main process exited, code=exited, status=1/FAILURE
Nov 16 12:35:13 stm32mp1-disco systemd[1]: mender-grow-data.service: Failed with result ‘exit-code’.
Nov 16 12:35:13 stm32mp1-disco systemd[1]: Failed to start Mender service to grow data partition size.

Edit 2 :
We fix the mender-grow-data error changing the partition number from 4 (p4 is our boot partition) to 7 (p7 is our data partition). We aren’t getting anymore the mender-grow-data fail and the data partition size is now 4Gb instead of 1Gb.
However we still have the real problem with mender and fw_env.

Hope this can help us,
Thank you

Hi @mirzak,
have you any idea for our problem? We are literally stucked

Thank You

Hi @mirzak,

we managed to get fw_printenv correctly working.

However the updated fails for : Expected “upgrade_available” flag to be true but it was false. Either the switch to the new partition was unsuccessful, or the bootloader rolled back

This is the full log :

2020-12-04 15:25:56 +0000 UTC info: Running Mender client version: 2.4.0
2020-12-04 15:25:57 +0000 UTC info: State transition: update-fetch [Download_Enter] -> update-store [Download_Enter]
2020-12-04 15:25:57 +0000 UTC info: Update Module path “/usr/share/mender/modules/v3” could not be opened (open /usr/share/mender/modules/v3: no such file or directory). Update modules will not be available
2020-12-04 15:25:57 +0000 UTC info: Installer: authenticated digital signature of artifact
2020-12-04 15:25:57 +0000 UTC info: Opening device “/dev/mmcblk0p6” for writing
2020-12-04 15:25:57 +0000 UTC info: Native sector size of block device /dev/mmcblk0p6 is 512 bytes. Mender will write in chunks of 1048576 bytes
2020-12-04 16:03:05 +0000 UTC info: All bytes were successfully written to the new partition
2020-12-04 16:03:05 +0000 UTC info: The optimized block-device writer wrote a total of 5112 frames, where 1010 frames did need to be rewritten (i.e., skipped)
2020-12-04 16:03:05 +0000 UTC info: Wrote 5360316416/5360316416 bytes to the inactive partition
2020-12-04 16:03:06 +0000 UTC info: State transition: update-store [Download_Enter] -> update-after-store [Download_Leave]
2020-12-04 16:03:06 +0000 UTC info: State transition: update-after-store [Download_Leave] -> update-install [ArtifactInstall]
2020-12-04 16:03:06 +0000 UTC info: Enabling partition with new image installed to be a boot candidate: 6
2020-12-04 16:03:06 +0000 UTC info: State transition: update-install [ArtifactInstall] -> reboot [ArtifactReboot_Enter]
2020-12-04 16:03:07 +0000 UTC info: Rebooting device(s)
2020-12-04 16:03:07 +0000 UTC info: Mender rebooting from active partition: /dev/mmcblk0p5
2020-12-04 16:05:38 +0000 UTC info: Running Mender client version: 2.4.0
2020-12-04 16:05:38 +0000 UTC info: Update Module path “/usr/share/mender/modules/v3” could not be opened (open /usr/share/mender/modules/v3: no such file or directory). Update modules will not be available
2020-12-04 16:05:38 +0000 UTC info: State transition: init [none] -> after-reboot [ArtifactReboot_Leave]
2020-12-04 16:05:38 +0000 UTC error: transient error: Reboot to the new update failed. Expected “upgrade_available” flag to be true but it was false. Either the switch to the new partition was unsuccessful, or the bootloader rolled back
2020-12-04 16:05:38 +0000 UTC info: State transition: after-reboot [ArtifactReboot_Leave] -> rollback [ArtifactRollback]
2020-12-04 16:05:38 +0000 UTC info: Performing rollback
2020-12-04 16:05:38 +0000 UTC info: State transition: rollback [ArtifactRollback] -> rollback-reboot [ArtifactRollbackReboot_Enter]
2020-12-04 16:05:38 +0000 UTC info: Rebooting device(s) after rollback
2020-12-04 16:05:38 +0000 UTC info: Mender rebooting from inactive partition: /dev/mmcblk0p5
2020-12-04 16:08:09 +0000 UTC info: Running Mender client version: 2.4.0
2020-12-04 16:08:09 +0000 UTC info: Mender shut down in state: rollback-reboot
2020-12-04 16:08:09 +0000 UTC info: Update Module path “/usr/share/mender/modules/v3” could not be opened (open /usr/share/mender/modules/v3: no such file or directory). Update modules will not be available
2020-12-04 16:08:09 +0000 UTC info: State transition: init [none] -> verify-rollback-reboot [ArtifactRollbackReboot_Leave]
2020-12-04 16:08:09 +0000 UTC info: State transition: verify-rollback-reboot [ArtifactRollbackReboot_Leave] -> after-rollback-reboot [ArtifactRollbackReboot_Leave]
2020-12-04 16:08:09 +0000 UTC info: State transition: after-rollback-reboot [ArtifactRollbackReboot_Leave] -> update-error [ArtifactFailure]
2020-12-04 16:08:09 +0000 UTC info: State transition: update-error [ArtifactFailure] -> cleanup [Error]
2020-12-04 16:08:09 +0000 UTC info: State transition: cleanup [Error] -> update-status-report [none]

Any idea?

Thank you

Hello @ASerr @mirzak

I experience the same issue on Raspberry PI CM3. Was reported at Mender with Yocto, RPI3 and No match between root & boot partitions - #4 by joelguittet.

@ASerr maybe you find a solution since December ?



could you share how did you fix fw_printenv issue ?

I’m also seeing the fw_printenv issue

If anyone is curious, I made a fork of meta-mender-community that has all of the changes I made in order to get as far as the fw_printenv bug mentioned above. You should be able to follow the instructions in the parent thread but slightly modified for Dunfell:

Download OpenSTLinux for Dunfell, per this wiki:

repo init -u -b refs/tags/openstlinux-5.10-dunfell-mp1-21-03-31

Download Manifest for meta-mender-st-stm32mp from my fork:

wget --directory-prefix .repo/manifests
instead of the original.

Modify OpenSTLinux Configuration Files

  1. Diff the conf files in the Mender-generated build directory versus the conf files in the OpenSTLinux-generated build-openstlinuxweston-stm32mp1 directory.
  2. Apply the Mender differences to the OpenSTLinux conf files. For me, I took lines 73-75 of bblayers.conf, as well as everything after ACCEPT_EULA_stm32mp1= "1" of local.conf and copy/pasted them over to the ST generated conf directories.

@mirzak I know it’s been a while since you were mentioned in this thread, but I was curious if you had any further insight on the fw_printenv/“Failed to read the current active partition: No match between boot and root partitions.: exit status 243” issue(s).

EDIT: my branch was also modified for 157D-DK1 but it should be relatively straightforward to change to 157C-EV1 or others

@drewmoseley any guidance on who I could ask about the above/any insight?

Honestly you probably have the most experience of anyone with this platform. We did the initial port but then it doesn’t seem to be used. That error is generally an issue with the u-boot environment but beyond that, it’s hard to say.


1 Like

thanks for the honesty, I’ll keep digging then. I appreciate the quick response!

@lizziemac Did you end up solving this? Whats the status of your fork?

I unfortunately did not end up solving this, I transitioned teams at my job and no longer had to pursue this. The fork as it is currently should get you as far as I got with it as of June 2nd. Sorry I can’t be of more help!

1 Like

Ok, I’ll be working on completing lizziemac’s work to get the stm32mp1 working with Yocto (dunfell) and Mender.

1 Like

I am very interested to hear about your progress @grahas. Did you get it working? I would like to get Mender going with a custom Yocto for a custom board with the STM32MP153C based Octavo SIP.

Kind of not really, I got the whole thing to build but I got stuck on creating the final gpt image with WIC, it kept crashing for me. I’m still working on it but I am focused on another higher priority project right now. Once I complete it I’ll be back to working on the Yocto port. We are also working on getting it to work with the Octavo based SIP but, the DK2 and the Seed SoM. I can give the specific build issues I am having if you think you can help fix them.

@grahas Can you share how/what patches you generated to get this going on Dunfell? I am also working with the SeeedSom. Thanks.

Yes, I am working on getting our device tree configured for all our peripherals and what not, I don’t have a patch for it yet but I’ll be working on it after I get this done. I’ll probably have it in a few months.

1 Like