Mender integration of STM32MP157C on dunfell

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 ?

Regards,
Joel

@ASerr

could you share how did you fix fw_printenv issue ?

I’m also seeing the fw_printenv issue

1 Like

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 GitHub - STMicroelectronics/oe-manifest: oe-manifest -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 https://raw.githubusercontent.com/lizziemac/meta-mender-community/dunfell-stm32mp/meta-mender-st-stm32mp/scripts/stm32mp-mender.xml
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.

Drew

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

I completed the other projects I was working on and am back on this one. If anyone wants to work on this together to create a community release of mender for stm32mp1 with dunfel that would be really helpful. I made a discord server here mender stm32mp1 dunfell integration for anyone that is also working on it. I am going to be trying to get it working on with the octavo osd32mp1 as well.

1 Like

Late but I got it working on the Octavo osd32mp1

1 Like

looks like the discord invite expired - I’d be curious to see the final result!

@grahas is the current state somewhere visible, or even better, plan to submit a PR?

For the record, kirkstoneis also just about to be finished, see Stm32mp1 Yocto Kirkstone issues

Okay here is the new link. mender stm32mp1 dunfell integration @lizziemac I think yours was actually really close to working. The issue with locating the uboot enviroment was with what you had in for the gptimage and the uboot offset variables. My current branch is kinda hardcoded to my board so I’ll probably need to spend time to get that removed. idk what the uboot partition is for but its like 20 somthing mb and I ended up deleting it and adding the uboot env to the end of FIP. FIP is allocated 4MB but only takes one. So I have the last 16K for uboot env information. I can try to get a PR for dunfel but it might take me a bit to clean everything up and get some time to do it.

Uboot defconfig
---------
CONFIG_ENV_OFFSET=0x480400
CONFIG_ENV_OFFSET_REDUND=0x482400

local.conf
---------
# Maps to CONFIG_ENV_OFFSET 0x480400
# Maps to CONFIG_ENV_OFFSET_REDUND 0x486400 
MENDER_UBOOT_ENV_STORAGE_DEVICE_OFFSET_1 = "4719616"
MENDER_UBOOT_ENV_STORAGE_DEVICE_OFFSET_2 = "4727808"

stm32mp-gptimg.bbclass
---------
    cat >> "$wks" <<EOF
part fsbl1 --source rawcopy --fstype=ext4 --fsoptions "noauto" --part-name=fsbl1 --sourceparams="file=${DEPLOY_DIR_IMAGE}/arm-trusted-firmware/tf-a-stm32mp157c-osd32mp1-system-controller-sdcard.stm32" --ondisk mmcblk --part-type 0x8301 --fixed-size 256K --align 17
part fsbl2 --source rawcopy --fstype=ext4 --fsoptions "noauto" --part-name=fsbl2 --sourceparams="file=${DEPLOY_DIR_IMAGE}/arm-trusted-firmware/tf-a-stm32mp157c-osd32mp1-system-controller-sdcard.stm32" --ondisk mmcblk --part-type 0x8301 --fixed-size 256K
part fip  --source rawcopy --fstype=ext4 --fsoptions "noauto" --part-name=fip --sourceparams="file=${DEPLOY_DIR_IMAGE}/fip/fip-stm32mp157c-osd32mp1-system-controller-trusted.bin" --ondisk mmcblk --part-type 0x8301 --fixed-size 4096K
part --source rootfs --rootfs-dir ${WORKDIR}/bootfs.${BB_CURRENTTASK} --ondisk "$ondisk_dev" --fstype=vfat --label boot --align $alignment_kb --fixed-size ${MENDER_BOOT_PART_SIZE_MB} --active $boot_part_params
part --source rootfs --ondisk "$ondisk_dev" --fstype=${ARTIFACTIMG_FSTYPE} --label primary --align $alignment_kb --fixed-size ${MENDER_CALC_ROOTFS_SIZE}k $exclude_path_options
part --source rootfs --ondisk "$ondisk_dev" --fstype=${ARTIFACTIMG_FSTYPE} --label secondary --align $alignment_kb --fixed-size ${MENDER_CALC_ROOTFS_SIZE}k $exclude_path_options
part --source rootfs --rootfs-dir ${IMAGE_ROOTFS}/data --ondisk "$ondisk_dev" --fstype=${ARTIFACTIMG_FSTYPE} --label data --align $alignment_kb --fixed-size ${MENDER_DATA_PART_SIZE_MB}
bootloader --ptable gpt
EOF

also there was a something wierd with my uboot where I needed to do a bitbake -c clean u-boot-stm32mp && bitbake u-boot-stm32mp in order to get changes to take effect. I tossed the uboot partition that was using the uboot.env file. Hex edit shows its just a block of zeros. Other issues might exist but I think that is a solution for the fw_printenv.

1 Like