# Dd vs wic for raspberry-pi-3 provisioning

**URL:** <https://hub.mender.io/t/dd-vs-wic-for-raspberry-pi-3-provisioning/5308>\
**Category:** Yocto Project\
**Tags:** yocto, raspberry-pi-3, uboot, kirkstone\
**Created:** [October 12, 2022, 4:43pm UTC](https://hub.mender.io/t/dd-vs-wic-for-raspberry-pi-3-provisioning/5308 "2022-10-12T16:43:14Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Tamis](https://avatars.discourse-cdn.com/v4/letter/t/2acd7d/32.png) [@Tamis](https://hub.mender.io/u/Tamis)\
**Post date:** [October 12, 2022, 4:43pm UTC](https://hub.mender.io/t/dd-vs-wic-for-raspberry-pi-3-provisioning/5308/1 "2022-10-12T16:43:14Z")

</div>

Hello to all,

I have recently started using a raspberry pi 3 with yocto kirkstone branch and meta-mender at the same branch for constructing an image for my pi. After following all the guidelines at [System updates: Yocto Project | Mender documentation](https://docs.mender.io/system-updates-yocto-project) I was able create the sdimg image and successfully boot my target.

I have some questions though and I would like some clarifications if possible.  
The image constructed from yocto / mender if I make an fdisk I get the following:

```auto
fdisk -l core-image-raspberrypi3.sdimg
Disk core-image-raspberrypi3.sdimg: 1,18 GiB, 1262485504 bytes, 2465792 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x86882af8

Device Boot Start End Sectors Size Id Type
core-image-raspberrypi3.sdimg1 * 24576 106495 81920 40M c W95 FAT32 (LBA)
core-image-raspberrypi3.sdimg2 106496 1155071 1048576 512M 83 Linux
core-image-raspberrypi3.sdimg3 1155072 2203647 1048576 512M 83 Linux
core-image-raspberrypi3.sdimg4 2203648 2465791 262144 128M 83 Linux

```

I see that the starting sector is the **24576** while the previous sectors are used for the uboot.env file.  
So the first 8MB (uboot.env) + 4MB alignment? = 12MBs are used for the uboot.env file  
As also stated from the wks file:

```auto
cat mender-sdimg.wks
part --source rawcopy --sourceparams="file=/home/<path>/uboot.env" --ondisk "mmcblk0" --align 4096 --no-table
part --source rawcopy --sourceparams="file=/home/<path>/core-image-raspberrypi3.bootimg" --ondisk "mmcblk0" --align 4096 --fixed-size 40 --active 
part --source rawcopy --sourceparams="file=/home/<path>/care-image-raspberrypi3.ext4" --ondisk "mmcblk0" --align 4096 --fixed-size 524288k 
part --ondisk "mmcblk0" --fstype=ext4 --align 4096 --fixed-size 524288k 
part --source rawcopy --sourceparams="file=/home/<path>/core-image-raspberrypi3.dataimg" --ondisk "mmcblk0" --align 4096 --fixed-size 128

```

According to the provisioning instructions stated here:  
[https://docs.mender.io/system-updates-yocto-project/provisioning-a-new-device](https://docs.mender.io/system-updates-yocto-project/provisioning-a-new-device)

Use of the dd command is the method for the first provisioning of the target.

But I also used the yocto **wic** command to provision the target due to the expand option it has for the data partition to take up all the remaining space.

So after using the following wic command:

```auto
wic write core-image-raspberrypi3.dataimg /dev/sdb --expand 1:0,2:0,3:0,4:26G

```

I get the following partitioning at the target:

```auto
fdisk -l /dev/mmcblk0
Disk /dev/mmcblk0: 28.5 GiB, 30601641984 bytes, 59768832 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x86882af8

Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 * 2048 83967 81920 40M c W95 FAT32 (LBA)
/dev/mmcblk0p2 83968 1132543 1048576 512M 83 Linux
/dev/mmcblk0p3 1132544 2181119 1048576 512M 83 Linux
/dev/mmcblk0p4 2181120 59768831 57587712 27.5G 83 Linux

```

Again the target seems to boot and operate fine.

The starting sector now is **2048**.  
So my question now is:  
Where is the uboot.env now is stored?

In both situations the contents of fw\_env.config is:  
/dev/mmcblk0 0x400000 0x4000  
/dev/mmcblk0 0x800000 0x4000

and fw\_printenv works normally.

Is there a change that the uboot.env being written with the wic method to the boot partition and overwrite some files there or happens to being written to an empty space and my target just happens to boot or the whole procedure even with the **wic** command is accepted?

Finally my target has an eMMC card which has two special partitions:  
/dev/mmcblk0boot0  
/dev/mmcblk0boot1

Which seems to be completely empty now.  
Are there any variables in mender which enable to use those partitions in order to store there the uboot.env?  
And is it possible to write to those partitions via the sdimg via the initial provisioning?

Thanks a lot in advance,  
Any help is welcome!

---

<div class="post-metadata">

**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\
**Post date:** [October 18, 2022, 11:03am UTC](https://hub.mender.io/t/dd-vs-wic-for-raspberry-pi-3-provisioning/5308/2 "2022-10-18T11:03:29Z")

</div>

Hi @Tamis!

First, thanks a lot for the elaborate description. I would love to help, but a number of things are still not clear to me.

- the RPi3 in itself does not have an eMMC. So are we actually talking about a CM3 based thing?
- if you want to provision said eMMC through the `sdimg`, what do you exactly mean? Writing the image to the eMMC, or writing it to a SD card and using some mechanism to provision the eMMC additionally?
- your `wic write` example refers to the `dataimg`, which is probably an error.

I’m currently looking into the U-Boot env topic, and once I know we can start to put the puzzle pieces together.

Greetz,  
Josef

---

<div class="post-metadata">

**Author:** ![Tamis](https://avatars.discourse-cdn.com/v4/letter/t/2acd7d/32.png) [@Tamis](https://hub.mender.io/u/Tamis)\
**Post date:** [November 1, 2022, 3:44pm UTC](https://hub.mender.io/t/dd-vs-wic-for-raspberry-pi-3-provisioning/5308/3 "2022-11-01T15:44:40Z")

</div>

Hello @TheYoctoJester,

And thank you for your answer!  
Sorry for my late answer. It seems the notification email somewhere slipped ☹

About your questions now:

1. Yeah you are actually correct. This is a custom HW based on CM3 that has eMMC only onboard.
2. I am writing to the eMMC directly. I plug the target to my machine via a USB cable, I then use the rpiboot program provided from: [GitHub - raspberrypi/usbboot: Raspberry Pi USB booting code, moved from tools repository](https://github.com/raspberrypi/usbboot.git)  
This will give direct access to eMMC so I am doing dd or wic (this was the question if wic is OK)
3. This is a copy - paste error. I doing the correct:

> wic write core-image-raspberrypi3.sdimg /dev/sdb --expand 1:0,2:0,3:0,4:26G

Actually after further investigation I am pretty sure that uboot env corrupts the boot partition and the files being residing at the below affected areas if **wic** is used

/dev/mmcblk0 0x400000 0x4000  
/dev/mmcblk0 0x800000 0x4000

I executed a stings command to the elf files of boot partition and found in there uboot env parts which it shouldn’t exist. I compared them also with the ones produced in my host machine. So I am pretty sure now about the corruption.  
The fortunate or unfortunate thing is that it seems that the files being corrupted do not play sometime a significant role so the target might boot.

wic command whatever the start sector is in sdimg always starts from 2048 sector. So this seems to be a bug in wic command, or wic is totally not accepted for writing the image to the target.  
Should this be fixed in wic?  
But I guess this is a rather yocto related question and not a mender related one.

With **dd** I always get the correct start sector as it is reported by fdisk in sdimg.  
So the sections that uboot env will be written is empty and no corruption happens.

So the findings suggest that **wic** is not to be trusted to provision and flush the sdimg into the target.

Lastly about the mmcblk0boot partitions.

I have found that writing to the mmcblk0boot partitions directly via flashing an image is not possible but uboot can use them to save its environment there. But uboot needs to be patched.

So I changed the mender patches and I added those variables:

```auto
diff --git a/meta-mender-raspberrypi/recipes-bsp/u-boot/patches/0001-configs-rpi-enable-mender-requirements.patch b/meta-mender-raspberrypi/recipes-bsp/u-boot/patches/0001-configs-rpi-enable-mender-requirements.patch
index a84c6208..9de576a8 100644
--- a/meta-mender-raspberrypi/recipes-bsp/u-boot/patches/0001-configs-rpi-enable-mender-requirements.patch
+++ b/meta-mender-raspberrypi/recipes-bsp/u-boot/patches/0001-configs-rpi-enable-mender-requirements.patch
@@ -79,14 +79,16 @@ index f4fdb455f4..0aec385bf7 100644
  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
  CONFIG_MMC_SDHCI=y
-@@ -43,3 +43,7 @@ CONFIG_SYS_WHITE_ON_BLACK=y
+@@ -43,3 +43,9 @@ CONFIG_SYS_WHITE_ON_BLACK=y
  CONFIG_CONSOLE_SCROLL_LINES=10
  CONFIG_PHYS_TO_BUS=y
  CONFIG_OF_LIBFDT_OVERLAY=y
 +CONFIG_ENV_IS_IN_MMC=y
-+CONFIG_ENV_OFFSET=0x800000
-+CONFIG_ENV_OFFSET_REDUND=0x1000000
++CONFIG_ENV_OFFSET=0x0
++CONFIG_ENV_OFFSET_REDUND=0x0
 +CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
++CONFIG_SYS_MMC_ENV_PART=1
++CONFIG_SUPPORT_EMMC_BOOT=y

```

CONFIG\_ENV\_OFFSET says that the uboot env is at offset 0x0  
CONFIG\_ENV\_OFFSET\_REDUND use the same offset also 0x0  
This will enable into uboot the **hardware** redundant so uboot will use both mmcblk0boot0 and mmcblk0boot1 eMMC partitions

CONFIG\_SYS\_MMC\_ENV\_PART=1 for the boot partitions  
CONFIG\_SUPPORT\_EMMC\_BOOT=y in order uboot to have access to those partitions

In mender layer the following might be required:

```auto
diff --git a/meta-mender-core/recipes-bsp/u-boot/u-boot-mender-helpers.inc b/meta-mender-core/recipes-bsp/u-boot/u-boot-mender-helpers.inc
index 6eb17583..16b31926 100644
--- a/meta-mender-core/recipes-bsp/u-boot/u-boot-mender-helpers.inc
+++ b/meta-mender-core/recipes-bsp/u-boot/u-boot-mender-helpers.inc
@@ -20,6 +20,7 @@ def mender_get_uboot_env_mmc_linux_device_path(d):
     return storage_device + env_part_append
 
 MENDER_UBOOT_MMC_ENV_LINUX_DEVICE_PATH ?= "${@mender_get_uboot_env_mmc_linux_device_path(d)}"
+MENDER_UBOOT_MMC_ENV_LINUX_DEVICE_PATH_REDUND ?= "${@mender_get_uboot_env_mmc_linux_device_path(d)}"
 
 # This should evaluate to the same as MENDER_RESERVED_SPACE_BOOTLOADER_DATA.
 # The only reason it's not evaluated the same way is that we don't have the
@@ -52,7 +53,7 @@ mender_create_fw_env_config_file() {
     # create fw_env.config file
     cat > $1 <<EOF
 ${MENDER_UBOOT_MMC_ENV_LINUX_DEVICE_PATH} ${MENDER_UBOOT_ENV_STORAGE_DEVICE_OFFSET_1} $HEX_BOOTENV_SIZE
-${MENDER_UBOOT_MMC_ENV_LINUX_DEVICE_PATH} ${MENDER_UBOOT_ENV_STORAGE_DEVICE_OFFSET_2} $HEX_BOOTENV_SIZE
+${MENDER_UBOOT_MMC_ENV_LINUX_DEVICE_PATH_REDUND} ${MENDER_UBOOT_ENV_STORAGE_DEVICE_OFFSET_2} $HEX_BOOTENV_SIZE
 EOF
 }

```

Above code will created the correct fw\_env.config file in /etc/ in order for the fw\_printenv command to be working correctly.

It will create this:

```auto
cat /etc/fw_env.config
/dev/mmcblk0boot0 0x0 0x4000
/dev/mmcblk0boot1 0x0 0x4000

```

Finally in local.conf or distro.conf you will need the following variables set:

```auto
# HW REDUND BOOT PARTITION
# /dev/mmcblk0boot0 0x0 0x4000
# /dev/mmcblk0boot1 0x0 0x4000
MENDER_PARTITION_ALIGNMENT = "4194304"
MENDER_UBOOT_ENV_STORAGE_DEVICE_OFFSET = ""
MENDER_UBOOT_CONFIG_SYS_MMC_ENV_PART = "1"
MENDER_UBOOT_MMC_ENV_LINUX_DEVICE_PATH = "${MENDER_STORAGE_DEVICE}boot0"
MENDER_UBOOT_MMC_ENV_LINUX_DEVICE_PATH_REDUND = "${MENDER_STORAGE_DEVICE}boot1"
MENDER_UBOOT_ENV_STORAGE_DEVICE_OFFSET_1 = "0x0"
MENDER_UBOOT_ENV_STORAGE_DEVICE_OFFSET_2 = "0x0"

```

As you see I created a new MENDER variable the

> MENDER\_UBOOT\_MMC\_ENV\_LINUX\_DEVICE\_PATH\_REDUND

in order to make MENDER to also use HW redundancy.

Would it worth above modifications a PR in order mender fully supports the placement of uboot environment in eMMC boot partitions?  
It seems a partial support to exist but the HW redundancy does not exist.

Best regards,  
Tamis

---

<div class="post-metadata">

**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\
**Post date:** [November 18, 2022, 3:38pm UTC](https://hub.mender.io/t/dd-vs-wic-for-raspberry-pi-3-provisioning/5308/4 "2022-11-18T15:38:17Z")

</div>

Hi @Tamis,

Thanks a lot for sharing your elaborate analysis! Yes, I agree with the conclusion that some addition to the Mender layers could be helpful, but not really sure how and where to package it. My best guess is that adding it to the [`meta-mender-raspberrypi`](https://github.com/mendersoftware/meta-mender-community/tree/kirkstone/meta-mender-raspberrypi) partial in [`meta-mender-community`](https://github.com/mendersoftware/meta-mender-community). The reason is that the main layers are meant to support the standard Raspis, and using CMs will always lead to a custom board to some extent - so the result would be more like an example/blueprint, not so much a full blown integration.

Having said that, the function expansions to evaluate the variables obviously would need to go into the main layer. I’ll try to find out how we can proceed there.

One observation from the Yocto side: the example set that you provided for `local.conf` actually serves as a perfect example of what should go into a custom derived machine.

So all in all - this is a perfect example of a custom board integration - I just am not completely clear about how to put it in a way that others can benefit from.

Let me think a bit and hopefully get back to you soon!  
Josef