# CM4 + Yocto: MMC device number with U-Boot

**URL:** <https://hub.mender.io/t/cm4-yocto-mmc-device-number-with-u-boot/7657>\
**Category:** Board Integrations\
**Tags:** yocto, raspberry-pi-cm4\
**Created:** [March 20, 2025, 6:41am UTC](https://hub.mender.io/t/cm4-yocto-mmc-device-number-with-u-boot/7657 "2025-03-20T06:41:43Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![lukehatpadl](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/lukehatpadl/32/2454_2.png) [@lukehatpadl](https://hub.mender.io/u/lukehatpadl)\
**Post date:** [March 20, 2025, 6:41am UTC](https://hub.mender.io/t/cm4-yocto-mmc-device-number-with-u-boot/7657/1 "2025-03-20T06:41:43Z")

</div>

I haven’t _quite_ got to the bottom of this, but it appears the default community RPi Yocto integration fails on the CM4 because the eMMC device number is 1, rather than 0. On boot:

```auto
U-Boot> boot
Card did not respond to voltage select! : -110
** Booting bootflow 'mmc@7e340000.bootdev.part_1' with script
Working FDT set to 2eff6200
Card did not respond to voltage select! : -110
Card did not respond to voltage select! : -110
**Bad device specification mmc 0**
Couldn't find partition mmc 0:2
Can't set block device
Bad Linux ARM64 Image magic!
Boot failed (err=-14)

```

If I hand-modify `mender_setup` from the U-Boot console so that it sets `mender_uboot_root` to `mmc 1:${mender_boot_part_hex}` then the kernel boots.

So you would think I just needed to set `MENDER_STORAGE_DEVICE` to `/dev/mmcblk1`, so `MENDER_UBOOT_STORAGE_DEVICE` would be `1`. However when I do this:

```auto
ERROR: u-boot-1_2024.01-r0 do_configure: U-Boot configuration rpi_arm64_config has setting:
CONFIG_SYS_MMC_ENV_DEV=0
but Mender expects:
CONFIG_SYS_MMC_ENV_DEV=1
Please fix U-Boot's configuration file.
ERROR: u-boot-1_2024.01-r0 do_configure: ExecutionError('/BuildRoot/build/tmp-glibc/work/xebra_cm4-oe-linux/u-boot/2024.01/temp/run.do_configure.1549453', 1, None, None)
ERROR: Logfile of failure stored in: /BuildRoot/build/tmp-glibc/work/xebra_cm4-oe-linux/u-boot/2024.01/temp/log.do_configure.1549453
ERROR: Task (/BuildRoot/meta/recipes-bsp/u-boot/u-boot_2024.01.bb:do_configure) failed with exit code '1'

```

Pre-Mender integration, the CM4 booted fine with U-Boot.

---

<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:** [March 20, 2025, 2:09pm UTC](https://hub.mender.io/t/cm4-yocto-mmc-device-number-with-u-boot/7657/2 "2025-03-20T14:09:45Z")

</div>

Hi @lukehatpadl,

Thanks for reaching out! Judging just from your description, adjusting the two `*_STORAGE_DEVICE` assignments should do the trick. If I remember correctly, then the warning about `CONFIG_SYS_MMC_DEV_ENV` checks if the `MENDER_UBOOT_STORAGE_DEVICE` matches what is given in the `u-boot` configuration. So you need to also adjust this in the `u-boot` config, possibly through a patch. Then I think you should be good.

Greetz,  
Josef

---

<div class="post-metadata">

**Author:** ![lukehatpadl](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/lukehatpadl/32/2454_2.png) [@lukehatpadl](https://hub.mender.io/u/lukehatpadl)\
**Post date:** [March 21, 2025, 4:06am UTC](https://hub.mender.io/t/cm4-yocto-mmc-device-number-with-u-boot/7657/3 "2025-03-21T04:06:46Z")

</div>

Thank you, that fixed the build, will test shortly.

---

<div class="post-metadata">

**Author:** ![lukehatpadl](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/lukehatpadl/32/2454_2.png) [@lukehatpadl](https://hub.mender.io/u/lukehatpadl)\
**Post date:** [March 26, 2025, 12:27am UTC](https://hub.mender.io/t/cm4-yocto-mmc-device-number-with-u-boot/7657/4 "2025-03-26T00:27:05Z")

</div>

Now that I’m a little deeper in the world of device trees, it turns out this was a red herring. The build was picking up the wrong device tree, which was assigning the builtin eMMC to the `mmc1` node. Switching back to the correct device tree solved this.

The underlying fix was to ensure `RPI_KERNEL_DEVICETREE` has only a single value:

```auto
RPI_KERNEL_DEVICETREE = "broadcom/bcm2711-rpi-cm4.dtb"

```

and also, as Mender appears to pick the last element in `KERNEL_DEVICETREE`, that the overlays precede the device tree:

```auto
KERNEL_DEVICETREE = "\
    ${RPI_KERNEL_DEVICETREE_OVERLAYS} \
    ${RPI_KERNEL_DEVICETREE} \
"

```

If anyone knows a better way to solve this, I am all ears!