# Bootloader upgrade process
**URL:** https://hub.mender.io/t/bootloader-upgrade-process/7165
**Category:** General Discussions
**Tags:** yocto, u-boot, zeus, kirkstone
**Created:** [September 9, 2024, 2:19pm UTC](https://hub.mender.io/t/bootloader-upgrade-process/7165 "2024-09-09T14:19:09Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@amalle](https://hub.mender.io/u/amalle)
#### Post date: [September 9, 2024, 2:19pm UTC](https://hub.mender.io/t/bootloader-upgrade-process/7165/1 "2024-09-09T14:19:09Z")
Hi,
I am in the process of upgrading from zeus to kirkstone.
My new image now works correctly when installing it from scratch on a device, even mender updades from new versions are good.
But I have devices in the wild with the old zeus version and the old bootloader build (u-boot) is not compatible with the new version of the image.
The process of update seams simple :
- Create a zeus image that we can mender update with the bootloader (lets call this version _ **AA** _)
- Pack the new bootloader (compatible with zeus images) and upgrade the bootloader creating an intermediate version (lets call it version _ **BA** _)
- Upgrade the rootfs to the new kirkstone image giving us _ **BB** _ the image we wanted all allong
However, I can’t figure out how to upgrade the bootloader.
My approach :
Install from scratch version _ **BA** _ (or version _ **BB** _) and create a binary of the bootloader :
```auto
dd if=/dev/mmcblk2boot0 of=backup_mmcblk2boot0.bin
dd if=/dev/mmcblk2boot1 of=backup_mmcblk2boot1.bin
```
On a _ **AA** _ version overide the bootloader with the BA one :
```auto
echo 0 > /sys/block/mmcblk2boot0/force_ro
dd if=backup_mmcblk2boot0.bin of=/dev/mmcblk2boot0
sync
echo 1 > /sys/block/mmcblk2boot0/force_ro
echo 0 > /sys/block/mmcblk2boot1/force_ro
dd if=backup_mmcblk2boot1.bin of=/dev/mmcblk2boot1 bs=128
sync
echo 1 > /sys/block/mmcblk2boot1/force_ro
reboot
```
My results :
When booting u-boot logs show the new version
```auto
U-Boot 2022.04-lf_v2022.04+g333abc82094 (Sep 06 2024 - 08:27:05 +0000)
```
It’s actually not the new version, the rest of the logs like `mmcboot` command logs don’t mach the new version…
I have a bunch more logs and informations. I’ll keep it short to start with.
What I’m I missing ?
Thanks
---
### Author:  [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)
#### Post date: [September 9, 2024, 2:49pm UTC](https://hub.mender.io/t/bootloader-upgrade-process/7165/2 "2024-09-09T14:49:48Z")
Hi @amalle,
Just so I understand it correctly. The problem at the moment is about how to get the new bootloader version into flash on a live device, not about how to automate it with Mender yet, right?
My first question would be on the flash technology involved. Is it NAND or NOR? Why `dd`, and not the matching tool from `mid-utils`, like `flashcp` or `nandwrite`? Additionally, does reading back the newly flashed loader yield the correct binary?
Plus, what parts are involved in the boot chain? Is there maybe some secondary loader?
In general, more details on the specific hardware would be helpful.
Greets,
Josef
---
### Author:  [@amalle](https://hub.mender.io/u/amalle)
#### Post date: [September 9, 2024, 3:24pm UTC](https://hub.mender.io/t/bootloader-upgrade-process/7165/3 "2024-09-09T15:24:47Z")
Hi @TheYoctoJester,
Thank you for your quick response.
We have a SOM with an imx8mm on it with emmc.
You understood correctly, I’m looking to have a working “manual” update before automating it with Mender.
The flash is eMMC.
I guess `dd` was used because it was the one available on the image.
The flash of the bootloader seams to work properly :
```auto
$ dd if=/dev/mmcblk2boot0 of=backup_mmcblk2boot0_AA.bin
4096+0 records in
4096+0 records out
$ md5sum /dev/mmcblk2boot0
9cc18b40c567ac6e4ee69d1db384370c /dev/mmcblk2boot0
$ md5sum backup_mmcblk2boot0_AA.bin
9cc18b40c567ac6e4ee69d1db384370c backup_mmcblk2boot0_AA.bin
$ dd if=/dev/mmcblk2boot1 of=backup_mmcblk2boot1_AA.bin
4096+0 records in
4096+0 records out
$ md5sum /dev/mmcblk2boot1
b2d1236c286a3c0704224fe4105eca49 /dev/mmcblk2boot1
$ md5sum backup_mmcblk2boot1_AA.bin
b2d1236c286a3c0704224fe4105eca49 backup_mmcblk2boot1_AA.bin
## Updating
$ echo 0 > /sys/block/mmcblk2boot0/force_ro
$ dd if=mmcblk2boot0_BA.bin of=/dev/mmcblk2boot0
4096+0 records in
4096+0 records out
$ sync
$ echo 1 > /sys/block/mmcblk2boot0/force_ro
$ md5sum mmcblk2boot0_BA.bin
a8c0d8eeddabfd35aa0fd0d704786bef mmcblk2boot0_BA.bin
$ md5sum /dev/mmcblk2boot0
a8c0d8eeddabfd35aa0fd0d704786bef /dev/mmcblk2boot0
$ echo 0 > /sys/block/mmcblk2boot1/force_ro
$ dd if=mmcblk2boot1_BA.bin of=/dev/mmcblk2boot1
4096+0 records in
4096+0 records out
$ sync
$ echo 1 > /sys/block/mmcblk2boot1/force_ro
$ md5sum mmcblk2boot1_BA.bin
b2d1236c286a3c0704224fe4105eca49 mmcblk2boot1_BA.bin
$ md5sum /dev/mmcblk2boot1
b2d1236c286a3c0704224fe4105eca49 /dev/mmcblk2boot1
```
I’m not sure about that secondary loader / bootchain.
How can I check for that ?
I don’t know if that helps but the mender patch is pretty straightforward :
---
### Author:  [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)
#### Post date: [September 9, 2024, 3:28pm UTC](https://hub.mender.io/t/bootloader-upgrade-process/7165/4 "2024-09-09T15:28:33Z")
@amalle, got it. I have a suspicion. What is the size of the binary that you’re flashing to the boot sectors there?
Greets,
Josef
---
### Author:  [@amalle](https://hub.mender.io/u/amalle)
#### Post date: [September 10, 2024, 9:35am UTC](https://hub.mender.io/t/bootloader-upgrade-process/7165/5 "2024-09-10T09:35:09Z")
@TheYoctoJester .bin files are 2 MB each
---
### Author:  [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)
#### Post date: [September 10, 2024, 12:47pm UTC](https://hub.mender.io/t/bootloader-upgrade-process/7165/6 "2024-09-10T12:47:08Z")
@amalle ok, then something is at least a _bit_ off.
The iMX8s which I have worked on usually require an SPL to be in the boot sector, and the full `u-boot` binary to be located on the FAT-formatted boot partition. This full binary requires the RAM, clocks and storage to be already initialized. So this is what the SPL does, before loading and jumping to full `u-boot`.
My _guess_ is that you are just swapping out the SPL, which gives you the new version string, but the jumps into the old `u-boot` which it loads from the partition. Without knowing the board configuration and metadata in use, I can’t say anything more detailed, but my advice therefore is to really look at the `u-boot` binaries which are produced, and then replicate the full provisioning process, not just a single file.
Greets,
Josef
---
### Author:  [@amalle](https://hub.mender.io/u/amalle)
#### Post date: [September 11, 2024, 2:23pm UTC](https://hub.mender.io/t/bootloader-upgrade-process/7165/7 "2024-09-11T14:23:24Z")
Ok I see.
What I find somewhat weird it that the difference when installing from scratch (using `uuu`) is the `imx-boot` file and it’s size is lower than 2MB. Changing this file give me a fully working and updated u-boot (and SPL probably).
Anyway I when further and here are some more information :
Same for results on _ **AA** _/_ **BA** _/_ **BB** _ :
```auto
$ fdisk -l /dev/mmcblk2
Disk /dev/mmcblk2: 3616 MB, 3791650816 bytes, 7405568 sectors
57856 cylinders, 4 heads, 32 sectors/track
Units: sectors of 1 * 512 = 512 bytes
Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type
/dev/mmcblk2p1 * 384,0,1 1023,3,32 49152 573439 524288 256M c Win95 FAT32 (LBA)
/dev/mmcblk2p2 1023,3,32 1023,3,32 573440 2244607 1671168 816M 83 Linux
/dev/mmcblk2p3 1023,3,32 1023,3,32 2244608 3915775 1671168 816M 83 Linux
/dev/mmcblk2p4 1023,3,32 1023,3,32 3915776 4177919 262144 128M 83 Linux
```
Equivalent results between _ **AA** _/_ **BA** _ :
```auto
$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 481704 353180 91332 79% /
devtmpfs 172140 0 172140 0% /dev
tmpfs 501292 0 501292 0% /dev/shm
tmpfs 501292 74608 426684 15% /run
tmpfs 501292 0 501292 0% /sys/fs/cgroup
tmpfs 501292 4 501288 0% /tmp
tmpfs 501292 8 501284 0% /var/volatile
/dev/mmcblk2p1 261868 88 261780 0% /uboot
/dev/mmcblk2p4 122835 1600 112061 1% /data
$ ls -lah /uboot
drwxr-xr-x 2 root root 16.0K Jan 1 1970 .
drwxr-xr-x 21 root root 4.0K Apr 17 2023 ..
-rwxr-xr-x 1 root root 6.2K Apr 17 2023 imx8mm_m4_TCM_hello_world.bin
-rwxr-xr-x 1 root root 16.8K Apr 17 2023 imx8mm_m4_TCM_rpmsg_lite_pingpong_rtos_linux_remote.bin
-rwxr-xr-x 1 root root 16.3K Apr 17 2023 imx8mm_m4_TCM_rpmsg_lite_str_echo_rtos.bin
-rwxr-xr-x 1 root root 39.6K Apr 17 2023 imx8mm_m4_TCM_sai_low_power_audio.bin
```
Specific to _ **BB** _ :
```auto
$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 593852 429156 119056 78% /
devtmpfs 367472 0 367472 0% /dev
tmpfs 500016 0 500016 0% /dev/shm
tmpfs 200008 26056 173952 13% /run
tmpfs 4096 0 4096 0% /sys/fs/cgroup
tmpfs 500016 4 500012 0% /tmp
tmpfs 500016 16 500000 0% /var/volatile
/dev/mmcblk2p1 261868 30916 230952 12% /uboot
/dev/mmcblk2p4 117203 64 107965 0% /data
$ ls -lah /uboot
drwxr-xr-x 2 root root 16.0K Jan 1 1970 .
drwxr-xr-x 22 root root 4.0K Sep 3 09:17 ..
-rwxr-xr-x 1 root root 29.6M Apr 5 2011 Image
-rwxr-xr-x 1 root root 47.5K Apr 5 2011 imx8mm-evk-8mic-revE.dtb
-rwxr-xr-x 1 root root 47.9K Apr 5 2011 imx8mm-evk-8mic-swpdm.dtb
-rwxr-xr-x 1 root root 45.6K Apr 5 2011 imx8mm-evk-ak4497.dtb
-rwxr-xr-x 1 root root 44.9K Apr 5 2011 imx8mm-evk-ak5558.dtb
-rwxr-xr-x 1 root root 45.0K Apr 5 2011 imx8mm-evk-audio-tdm.dtb
-rwxr-xr-x 1 root root 3.1K Apr 5 2011 imx8mm-evk-inmate.dtb
-rwxr-xr-x 1 root root 44.9K Apr 5 2011 imx8mm-evk-pcie-ep.dtb
-rwxr-xr-x 1 root root 45.0K Apr 5 2011 imx8mm-evk-pu5xx.dtb
-rwxr-xr-x 1 root root 45.1K Apr 5 2011 imx8mm-evk-qca-wifi.dtb
-rwxr-xr-x 1 root root 45.1K Apr 5 2011 imx8mm-evk-revb-qca-wifi.dtb
-rwxr-xr-x 1 root root 45.4K Apr 5 2011 imx8mm-evk-rm67191.dtb
-rwxr-xr-x 1 root root 45.5K Apr 5 2011 imx8mm-evk-root.dtb
-rwxr-xr-x 1 root root 46.2K Apr 5 2011 imx8mm-evk-rpmsg.dtb
-rwxr-xr-x 1 root root 44.9K Apr 5 2011 imx8mm-evk-usd-wifi.dtb
```
It seams that we have a `uboot` partitition in the form of `/dev/mmcblkp1`
I’ve `dd`’ed `/dev/mmcblkp1` from _ **BB** _ to _ **AA** _ and it didn’t change anything more.
So i’ve when into [I.MX Linux User’s Guide](https://www.nxp.com/docs/en/user-guide/IMX_LINUX_USERS_GUIDE.pdf) and found the following :
That seams to match with your guess.
The `imx-boot` file is still ~1.5Mo and using it (with the seek offset) seams to give me the same results as `dd`’ing the `/dev/mmcblk2boot0` from BA.
I feel like I am close… But still missing something ?
---
### Author:  [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)
#### Post date: [September 11, 2024, 5:35pm UTC](https://hub.mender.io/t/bootloader-upgrade-process/7165/8 "2024-09-11T17:35:31Z")
@amalle indeed close, but missing something. I’d now take a really close look at the image generation used in your builds, possibly the `.wks` files which define the resulting `.wic` image structure, because those definitely have to contain the logic on which piece goes where exactly.
Greets,
Josef
---
### Author:  [@amalle](https://hub.mender.io/u/amalle)
#### Post date: [September 17, 2024, 10:27am UTC](https://hub.mender.io/t/bootloader-upgrade-process/7165/9 "2024-09-17T10:27:49Z")
Hi again,
`.wks` is definitely a good lead :
```auto
# short-description: Create SD card image with a boot partition
# long-description:
# Create an image that can be written onto a SD card using dd for use
# with i.MX SoC family
# It uses u-boot + other binaries gathered together on imx-boot file
#
# The disk layout used is:
# - ---------- -------------- --------------
# | | imx-boot | boot | rootfs |
# - ---------- -------------- --------------
# ^ ^ ^ ^ ^
# | | | | |
# 0 | 8MiB 72MiB 72MiB + rootfs + IMAGE_EXTRA_SPACE (default 10MiB)
# 33 32 or 33kiB, see reference manual
#
part u-boot --source rawcopy --sourceparams="file=imx-boot" --ondisk mmcblk --no-table --align 33
part /boot --source bootimg-partition --ondisk mmcblk --fstype=vfat --label boot --active --align 8192 --size 64
part / --source rootfs --ondisk mmcblk --fstype=ext4 --label root --align 8192
bootloader --ptable msdos
```
But, from there I’ve started to try to split work in 2 updating `imx-boot` and `boot`.
Taking a closer look to the difference between the `imx-boot` file and the `dd`’ed `mmcblk2boot0` :
We can see that `imx-boot` starts at the address `0x008400` in `mmcblk2boot0` not sure how that match with the 33kiB.
Length seams to match between `imx-boot` and `mmcblk2boot0` (accounting the offset) but again not with the `.wks` for some reason ?
Both contain the modified uboot logs and script witch give me the impression I should be able to make it work by updating `mmcblk2boot0`.
I’ve tried to dump `boot` using dd on `mmcblk2p1` but it’s mostly empty…
Going through the build files i’ve found `xxx.testdata.json` here are some the of the informations that seemed relevant :
```auto
"IMAGE_OVERHEAD_FACTOR": "1.5",
"IMAGE_ROOTFS_ALIGNMENT": "1",
"IMAGE_ROOTFS_EXCLUDE_PATH": " data/ uboot/",
"IMX_BOOT_SEEK": "33",
"IMX_BOOT_SOC_TARGET": "iMX8MM",
"IMX_DEFAULT_ATF_PROVIDER": "imx-atf",
"IMX_DEFAULT_BOOTLOADER": "u-boot-imx",
"MENDER_BOOT_PART": "/dev/mmcblk2p1",
"MENDER_BOOT_PART_DEFAULT": "/dev/mmcblk2p1",
"MENDER_BOOT_PART_DEFAULT:mender-ubi": "",
"MENDER_BOOT_PART_FSOPTS": "",
"MENDER_BOOT_PART_FSOPTS_DEFAULT": "",
"MENDER_BOOT_PART_FSTAB_OPTS": "defaults,sync",
"MENDER_BOOT_PART_FSTAB_OPTS_DEFAULT": "defaults,sync",
"MENDER_BOOT_PART_FSTYPE": "auto",
"MENDER_BOOT_PART_FSTYPE_DEFAULT": "auto",
"MENDER_BOOT_PART_FSTYPE_TO_GEN": "vfat",
"MENDER_BOOT_PART_FSTYPE_TO_GEN_DEFAULT": "vfat",
"MENDER_BOOT_PART_LABEL": "boot",
"MENDER_BOOT_PART_MOUNT_LOCATION": "/uboot",
"MENDER_BOOT_PART_MOUNT_LOCATION:mender-grub:mender-bios": "/boot/grub",
"MENDER_BOOT_PART_MOUNT_LOCATION:mender-systemd-boot": "/boot",
"MENDER_BOOT_PART_MOUNT_LOCATION:mender-uboot": "/uboot",
"MENDER_BOOT_PART_NUMBER": "1",
"MENDER_BOOT_PART_NUMBER_DEFAULT": "1",
"MENDER_BOOT_PART_NUMBER_DEFAULT:mender-ubi": "",
"MENDER_BOOT_PART_SIZE_MB": "256",
"MENDER_BOOT_PART_SIZE_MB_DEFAULT": "16",
"MENDER_BOOT_PART_SIZE_MB_DEFAULT:mender-systemd-boot": "64",
"MENDER_BOOT_PART_SIZE_MB_DEFAULT:mender-ubi": "0",
"MENDER_CALC_ROOTFS_SIZE": "835584",
"MENDER_CONFIGURATION_VARS": " RootfsPartA RootfsPartB InventoryPollIntervalSeconds RetryPollIntervalSeconds ArtifactVerifyKey ServerCertificate ServerURL UpdatePollIntervalSeconds",
"MENDER_CONNECT_USER": "root",
"MENDER_DATA_PART": "/dev/mmcblk2p4",
"MENDER_DATA_PART_DEFAULT": "/dev/mmcblk2p4",
"MENDER_DATA_PART_DEFAULT:mender-ubi": "/dev/mmcblk2p2",
"MENDER_DATA_PART_FSOPTS": "",
"MENDER_DATA_PART_FSOPTS_DEFAULT": "",
"MENDER_DATA_PART_FSTAB_OPTS": "defaults",
"MENDER_DATA_PART_FSTAB_OPTS_DEFAULT": "defaults",
"MENDER_DATA_PART_FSTYPE": "auto",
"MENDER_DATA_PART_FSTYPE_DEFAULT": "auto",
"MENDER_DATA_PART_FSTYPE_DEFAULT:mender-ubi": "ubifs",
"MENDER_DATA_PART_FSTYPE_TO_GEN": "ext4",
"MENDER_DATA_PART_FSTYPE_TO_GEN_DEFAULT": "ext4",
"MENDER_DATA_PART_LABEL": "data",
"MENDER_DATA_PART_NUMBER": "4",
"MENDER_DATA_PART_NUMBER_DEFAULT": "4",
"MENDER_DATA_PART_SIZE_MB": "128",
"MENDER_DATA_PART_SIZE_MB_DEFAULT": "128",
"MENDER_DEVICE_TYPE": "awpu510",
"MENDER_DEVICE_TYPES_COMPATIBLE": "awpu510",
"MENDER_DEVICE_TYPES_COMPATIBLE_DEFAULT": "awpu510",
"MENDER_DEVICE_TYPE_DEFAULT": "awpu510",
"MENDER_DEVICE_TYPE_DEFAULT:beaglebone-yocto:mender-grub": "awpu510-grub",
"MENDER_EFI_LOADER": "u-boot",
"MENDER_EXTRA_PARTS": "",
"MENDER_EXTRA_PARTS_TOTAL_SIZE_MB": "0",
"MENDER_FEATURES": "mender-image mender-uboot mender-image-sd mender-client-install mender-auth-install mender-update-install",
"MENDER_FEATURES_DISABLE": " mender-grub mender-image-uefi",
"MENDER_FEATURES_ENABLE": "mender-image mender-uboot mender-image-sd mender-client-install",
"MENDER_FLASH_MINIMUM_IO_UNIT": "512",
"MENDER_IMAGE_BOOTLOADER_BOOTSECTOR_OFFSET": "2",
"MENDER_IMAGE_BOOTLOADER_BOOTSECTOR_OFFSET_DEFAULT": "2",
"MENDER_IMAGE_BOOTLOADER_BOOTSECTOR_OFFSET_DEFAULT:mender-grub:mender-bios:mender-image-bios": "1",
"MENDER_IMAGE_BOOTLOADER_BOOTSECTOR_OFFSET_DEFAULT:mender-grub:mender-bios:mender-image-gpt": "34",
"MENDER_IMAGE_BOOTLOADER_BOOTSECTOR_OFFSET_DEFAULT:mender-ubi": "0",
"MENDER_IMAGE_BOOTLOADER_FILE": "",
"MENDER_IMAGE_BOOTLOADER_FILE:imx8mnevk": "imx-boot",
"MENDER_IMAGE_BOOTLOADER_FILE_DEFAULT": "",
"MENDER_IMAGE_BOOTLOADER_FILE_DEFAULT:mender-grub:mender-bios": "grub-core.img",
"MENDER_IMAGE_BOOTLOADER_FILE_DEFAULT:mender-ubi": "u-boot.bin",
"MENDER_IMAGE_ROOTFS_MAXSIZE_DEFAULT:mender-ubi": "",
"MENDER_IMAGE_ROOTFS_SIZE_DEFAULT": "835584",
"MENDER_IS_ON_MTDID": "",
"MENDER_MACHINE": "awpu510",
"MENDER_MAXIMUM_LEB_COUNT": "1024",
"MENDER_MBR_BOOTLOADER_FILE": "",
"MENDER_MBR_BOOTLOADER_FILE_DEFAULT": "",
"MENDER_MBR_BOOTLOADER_FILE_DEFAULT:mender-grub:mender-bios": "boot.img",
"MENDER_MBR_BOOTLOADER_LENGTH": "446",
"MENDER_MTDIDS": "",
"MENDER_MTDPARTS": "",
"MENDER_MTD_UBI_DEVICE_NAME": "",
"MENDER_MTD_UBI_DEVICE_NAME_DEFAULT": "",
"MENDER_MTD_UBI_DEVICE_NAME_DEFAULT:mender-ubi": "ubi",
"MENDER_NAND_FLASH_PAGE_SIZE": "2048",
"MENDER_PARTITIONING_OVERHEAD_KB": "16384",
"MENDER_PARTITIONING_OVERHEAD_KB_DEFAULT": "16384",
"MENDER_PARTITIONING_OVERHEAD_KB_DEFAULT:mender-ubi": "2129920",
"MENDER_PARTITION_ALIGNMENT": "8388608",
"MENDER_PARTITION_ALIGNMENT_DEFAULT": "8388608",
"MENDER_PARTITION_ALIGNMENT_DEFAULT:mender-ubi": "8388608",
"MENDER_PERSISTENT_CONFIGURATION_VARS": "RootfsPartA RootfsPartB",
"MENDER_RESERVED_SPACE_BOOTLOADER_DATA": "16777216",
"MENDER_RESERVED_SPACE_BOOTLOADER_DATA_DEFAULT": "16777216",
"MENDER_RESERVED_SPACE_BOOTLOADER_DATA_DEFAULT:mender-uboot": "16777216",
"MENDER_ROOTFS_PART_A": "/dev/mmcblk2p2",
"MENDER_ROOTFS_PART_A_DEFAULT": "/dev/mmcblk2p2",
"MENDER_ROOTFS_PART_A_NAME": "/dev/mmcblk2p2",
"MENDER_ROOTFS_PART_A_NAME_DEFAULT": "/dev/mmcblk2p2",
"MENDER_ROOTFS_PART_A_NAME_DEFAULT:mender-ubi": "/dev/mmcblk2:rootfsa",
"MENDER_ROOTFS_PART_A_NUMBER": "2",
"MENDER_ROOTFS_PART_A_NUMBER_DEFAULT": "2",
"MENDER_ROOTFS_PART_A_NUMBER_DEFAULT:mender-ubi": "0",
"MENDER_ROOTFS_PART_B": "/dev/mmcblk2p3",
"MENDER_ROOTFS_PART_B_DEFAULT": "/dev/mmcblk2p3",
"MENDER_ROOTFS_PART_B_NAME": "/dev/mmcblk2p3",
"MENDER_ROOTFS_PART_B_NAME_DEFAULT": "/dev/mmcblk2p3",
"MENDER_ROOTFS_PART_B_NAME_DEFAULT:mender-ubi": "/dev/mmcblk2:rootfsb",
"MENDER_ROOTFS_PART_B_NUMBER": "3",
"MENDER_ROOTFS_PART_B_NUMBER_DEFAULT": "3",
"MENDER_ROOTFS_PART_B_NUMBER_DEFAULT:mender-ubi": "1",
"MENDER_SERVER_URL": "https://hosted.mender.io",
"MENDER_STATE_SCRIPTS_VERSION": "3",
"MENDER_STORAGE_DEVICE": "/dev/mmcblk2",
"MENDER_STORAGE_DEVICE_BASE": "/dev/mmcblk2p",
"MENDER_STORAGE_DEVICE_BASE_DEFAULT": "/dev/mmcblk2p",
"MENDER_STORAGE_DEVICE_BASE_DEFAULT:mender-ubi": "/dev/mmcblk2_",
"MENDER_STORAGE_DEVICE_DEFAULT": "/dev/mmcblk0",
"MENDER_STORAGE_DEVICE_DEFAULT:mender-ubi": "ubi0",
"MENDER_STORAGE_PEB_SIZE": "8388608",
"MENDER_STORAGE_TOTAL_SIZE_MB": "2048",
"MENDER_STORAGE_TOTAL_SIZE_MB_DEFAULT": "1024",
"MENDER_SWAP_PART_SIZE_MB": "0",
"MENDER_SWAP_PART_SIZE_MB_DEFAULT": "0",
"MENDER_UBI_LEB_PEB_BLOCK_OVERHEAD": "0",
"MENDER_UBI_LEB_SIZE": "8388608",
"MENDER_UBI_TOTAL_BAD_PEB_OVERHEAD": "0",
"MENDER_UBI_TOTAL_FIXED_OVERHEAD": "33554432",
"MENDER_UBI_TOTAL_LEB_PEB_OVERHEAD": "0",
"MENDER_UBOOT_ENV_STORAGE_DEVICE_OFFSET": "8388608",
"MENDER_UBOOT_ENV_UBIVOL_NUMBER_1": "3",
"MENDER_UBOOT_ENV_UBIVOL_NUMBER_2": "4",
"MENDER_UBOOT_POST_SETUP_COMMANDS": "",
"MENDER_UBOOT_POST_SETUP_COMMANDS_DEFAULT": "",
"MENDER_UBOOT_PRE_SETUP_COMMANDS": "",
"MENDER_UBOOT_PRE_SETUP_COMMANDS_DEFAULT": "",
"MENDER_UBOOT_STORAGE_DEVICE": "",
"MENDER_UBOOT_STORAGE_DEVICE_DEFAULT": "",
"MENDER_UBOOT_STORAGE_DEVICE_DEFAULT:mender-ubi": "dummy",
"MENDER_UBOOT_STORAGE_INTERFACE": "",
"MENDER_UBOOT_STORAGE_INTERFACE_DEFAULT": "",
"MENDER_UBOOT_STORAGE_INTERFACE_DEFAULT:mender-ubi": "dummy",
```
That seems to confirm the partitions layout, the `33` KiB/KB/B/? offset.
I’m still missing something…