# Yocto imx8mmevk eMMC u-boot problem **URL:** \ **Category:** General Discussions\ **Tags:** yocto, sumo, nxp, imx8mm\ **Created:** [November 6, 2019, 1:26pm UTC](https://hub.mender.io/t/yocto-imx8mmevk-emmc-u-boot-problem/1216 "2019-11-06T13:26:37Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![bhstalel](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/bhstalel/32/855_2.png) [@bhstalel](https://hub.mender.io/u/bhstalel)\ **Post date:** [November 19, 2019, 12:36pm UTC](https://hub.mender.io/t/yocto-imx8mmevk-emmc-u-boot-problem/1216/21 "2019-11-19T12:36:18Z")
> u-boot=\> ext4load mmc 0:2 ${loadaddr} ${image} > Card did not respond to voltage select! > \*\* Bad device mmc 0 \*\* > u-boot=\> ext4load mmc 1:2 ${loadaddr} ${image} > 23163392 bytes read in 451 ms (49 MiB/s) I think because the partitions are in device 1 (eMMC) , and that’s what mmc part is showing : > u-boot=\> mmc part > > Partition Map for MMC device 1 – Partition Type: DOS > > Part Start Sector Num Sectors UUID Type > 1 49152 32768 d2e3c935-01 0c Boot > 2 81920 425984 d2e3c935-02 83 > 3 507904 425984 d2e3c935-03 83 > 4 933888 262144 d2e3c935-04 83 > u-boot=\> mmc list > FSL\_SDHC: 0 > FSL\_SDHC: 1 (eMMC) because the second part in mmc 1:2 is the rootfs\_partA I think. [EDIT] ![aaaa](https://canada1.discourse-cdn.com/flex036/uploads/mender/original/1X/66efb46e9121a3e37ad192d60a9130f0f0ecb61e.png) [EDIT2] I rebuilt the image with adding back the file name: ```auto MENDER_IMAGE_BOOTLOADER_FILE = " imx-boot-${MACHINE}-sd.bin " ``` and I found out that mmc 1:1 is type FAT: u-boot=\> fatls mmc 1:1 676901 u-boot-imx8mmevk.bin 1 file(s), 0 dir(s) ---
**Author:** ![bhstalel](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/bhstalel/32/855_2.png) [@bhstalel](https://hub.mender.io/u/bhstalel)\ **Post date:** [November 20, 2019, 2:01pm UTC](https://hub.mender.io/t/yocto-imx8mmevk-emmc-u-boot-problem/1216/22 "2019-11-20T14:01:30Z")
Any solutions ? [EDIT] I think the device part is okay, because when I try to load the boot.scr manually : fatload mmc 1:1 {loadaddr} {image} it gives me : Unable to load boot.scr But when I try with the part 0 it gives : unrecognized file system ,\* So the problem is with the u-boot generated with yocto itself i think . ---
**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\ **Post date:** [November 21, 2019, 7:24am UTC](https://hub.mender.io/t/yocto-imx8mmevk-emmc-u-boot-problem/1216/23 "2019-11-21T07:24:35Z")
> [@bhstalel](#): > > and I found out that mmc 1:1 is type FAT: > u-boot=\> fatls mmc 1:1 It might be, but by default Mender will load the Linux kernel from `mmc 1:2` which should be an `ext4` filesystem. That file in the FAT partition is actually not used and is there to satisfy a Yocto build dependency. ---
**Author:** ![bhstalel](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/bhstalel/32/855_2.png) [@bhstalel](https://hub.mender.io/u/bhstalel)\ **Post date:** [November 21, 2019, 8:13am UTC](https://hub.mender.io/t/yocto-imx8mmevk-emmc-u-boot-problem/1216/24 "2019-11-21T08:13:20Z")
Hi, Please I need to inform you that I need to flash and boot from the eMMC I’ve been testing this for more than a week now, Please if there is a solution help me. ---
**Author:** ![Tom](https://avatars.discourse-cdn.com/v4/letter/t/3d9bf3/32.png) [@Tom](https://hub.mender.io/u/Tom)\ **Post date:** [January 13, 2020, 11:42am UTC](https://hub.mender.io/t/yocto-imx8mmevk-emmc-u-boot-problem/1216/25 "2020-01-13T11:42:20Z")
Same issue here, any success? [Add:] I think I created a workaround for booting from eMMC, this worked for me… # 0] on my i.MX8M Mini board: SD card is /dev/mmcblk1 in linux and mmc dev 0 in u-boot eMMc is /dev/mmcblk2 in linux and mmc dev 1 in u-boot # 1] update the conf/local.conf ``` MENDER_STORAGE_DEVICE_imx8mmevk = "/dev/mmcblk2" \# Following is not essential MENDER_STORAGE_DEVICE = "/dev/mmcblk2" MENDER_BOOT_PART = "${MENDER_STORAGE_DEVICE_BASE}1" MENDER_DATA_PART = "${MENDER_STORAGE_DEVICE_BASE}4" MENDER_ROOTFS_PART_A = "${MENDER_STORAGE_DEVICE_BASE}2" MENDER_ROOTFS_PART_B = "${MENDER_STORAGE_DEVICE_BASE}3" ``` # 2] rebuild the image: `bitbake core-image-base` # 3] setup board (via DIP switches) to “Download Mode”, and flash the board with: `uuu -v -b emmc_all imx-boot-imx8mmevk-sd.bin core-image-base-imx8mmevk.sdimg` # 4] setup board to “eMMC / SDHC3” mode and enter u-boot note [chapter 4. errata of UG](https://static6.arrow.com/aropdfconversion/3eb66c6ff328259ad060ed3a1cb5b2e34dcaa693/imx8mmevkhug.pdf) # 5] once in u-boot console, enter following: ``` setenv mender_uboot_boot "mmc 1:1" setenv mender_uboot_dev 1 setenv 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/mmcblk2p${mender_boot_part}; if test ${mender_boot_part} = 2; then setenv mender_boot_part_name /dev/mmcblk2p2; else setenv mender_boot_part_name /dev/mmcblk2p3; fi; setenv mender_kernel_root_name ${mender_boot_part_name}; setenv mender_uboot_root mmc 1:${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' boot ``` # 6] Linux should boot successfully My speculation is, that the mmc dev number is set incorrectly in generated u-boot? I am trying to find a way to change it through some config. Is there such an option? ---
**Author:** ![Tom](https://avatars.discourse-cdn.com/v4/letter/t/3d9bf3/32.png) [@Tom](https://hub.mender.io/u/Tom)\ **Post date:** [January 13, 2020, 8:25pm UTC](https://hub.mender.io/t/yocto-imx8mmevk-emmc-u-boot-problem/1216/26 "2020-01-13T20:25:53Z")
Managed to force the boot (without cumbersome setenvs) by adding following to conf/local.conf (step 1] in previous post) ``` MENDER_STORAGE_DEVICE = "/dev/mmcblk2" MENDER_STORAGE_DEVICE_imx8mmevk = "/dev/mmcblk2" MENDER_UBOOT_POST_SETUP_COMMANDS = "setenv mender_uboot_root mmc 1:2" ``` Steps 4] and 5] are not necessary anymore, but following error pops up during boot: > … > switch to partitions #0, OK > mmc1(part 0) is current device > \*\* Unable to read file boot.scr \*\* > Saving Environment to MMC… Env export buffer too small: 4091, but need 4117 > Cannot export environment: errno = 12 > Failed (1) > 23163392 bytes read in 12620 ms (1.7 MiB/s) > Booting from mmc … > … Is this an approved approach? Will the failure to saveenv interfere with Mender working properly? Thanks for reply ---
**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\ **Post date:** [January 15, 2020, 10:35am UTC](https://hub.mender.io/t/yocto-imx8mmevk-emmc-u-boot-problem/1216/27 "2020-01-15T10:35:52Z")
> eMMc is /dev/mmcblk2 in linux and mmc dev 1 in u-boot In this case, it should be enough to set the following in `local.conf`: ```auto MENDER_UBOOT_STORAGE_DEVICE = "1" MENDER_STORAGE_DEVICE_imx8mmevk = "/dev/mmcblk2" ``` So the `MENDER_UBOOT_POST_SETUP_COMMANDS` should not be necessary. Additional documentation can be found [here](https://docs.mender.io/2.2/artifacts/yocto-project/variables#mender_uboot_storage_device), ---
**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\ **Post date:** [January 15, 2020, 10:38am UTC](https://hub.mender.io/t/yocto-imx8mmevk-emmc-u-boot-problem/1216/28 "2020-01-15T10:38:39Z")
> [@Tom](#): > > Saving Environment to MMC… Env export buffer too small: 4091, but need 4117 > Cannot export environment: errno = 12 > Failed (1) This error can show to be problematic as your environment is to big to fit in what is currently allocated by U-Boot. You will need to update the `CONFIG_ENV_SIZE` variable in your U-Boot source to allow it to fit. Note that you also need to update the `BOOTENV_SIZE` variable in Yocto to match what is set by `CONFIG_ENV_SIZE` ---
**Author:** ![Tom](https://avatars.discourse-cdn.com/v4/letter/t/3d9bf3/32.png) [@Tom](https://hub.mender.io/u/Tom)\ **Post date:** [January 15, 2020, 11:11am UTC](https://hub.mender.io/t/yocto-imx8mmevk-emmc-u-boot-problem/1216/29 "2020-01-15T11:11:22Z")
> [@mirzak](#): > > In this case, it should be enough to set the following in `local.conf` : > > MENDER\_UBOOT\_STORAGE\_DEVICE = “1” > MENDER\_STORAGE\_DEVICE\_imx8mmevk = “/dev/mmcblk2” This does not work for me… boot fails with: > switch to partitions #0, OK > mmc1(part 0) is current device > flash target is MMC:1 > Net: eth0: ethernet@30be0000 > Fastboot: Normal > Normal Boot > Hit any key to stop autoboot: 0 > switch to partitions #0, OK > mmc1(part 0) is current device > \*\* Unable to read file boot.scr \*\* > Card did not respond to voltage select! > \*\* Bad device mmc 0 \*\* > Booting from net … u-boot still does: `setenv mender_uboot_root mmc 0:${mender_boot_part_hex};`, as per `printenv`: > … > 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/mmcblk2p${mender\_boot\_part}; if test ${mender\_boot\_part} = 2; then setenv mender\_boot\_part\_name /dev/mmcblk2p2; else setenv mender\_boot\_part\_name /dev/mmcblk2p3; 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 > … would this be a bug? ---
**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\ **Post date:** [January 15, 2020, 2:19pm UTC](https://hub.mender.io/t/yocto-imx8mmevk-emmc-u-boot-problem/1216/30 "2020-01-15T14:19:17Z")
> u-boot still does: `setenv mender_uboot_root mmc 0:${mender_boot_part_hex};` , as per `printenv` : Hmm, are you sure that you get `MENDER_UBOOT_STORAGE_DEVICE = “1”` during you build, because `mender_uboot_root` is defined as such: ```auto "setenv mender_uboot_root " MENDER_UBOOT_STORAGE_INTERFACE " " __stringify(MENDER_UBOOT_STORAGE_DEVICE) ":${mender_boot_part_hex}; " \ ``` Can you run the following in your environment: ```auto bitbake -e | grep ^MENDER_UBOOT_STORAGE_DEVICE ``` ---
**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\ **Post date:** [January 15, 2020, 2:21pm UTC](https://hub.mender.io/t/yocto-imx8mmevk-emmc-u-boot-problem/1216/31 "2020-01-15T14:21:00Z")
It is defined here, [https://github.com/mendersoftware/meta-mender/blob/master/meta-mender-core/recipes-bsp/u-boot/patches/0002-Generic-boot-code-for-Mender.patch#L217](https://github.com/mendersoftware/meta-mender/blob/master/meta-mender-core/recipes-bsp/u-boot/patches/0002-Generic-boot-code-for-Mender.patch#L217) ---
**Author:** ![Tom](https://avatars.discourse-cdn.com/v4/letter/t/3d9bf3/32.png) [@Tom](https://hub.mender.io/u/Tom)\ **Post date:** [January 15, 2020, 2:35pm UTC](https://hub.mender.io/t/yocto-imx8mmevk-emmc-u-boot-problem/1216/32 "2020-01-15T14:35:26Z")
> [@mirzak](#): > > bitbake -e | grep ^MENDER\_UBOOT\_STORAGE\_DEVICE > MENDER\_UBOOT\_STORAGE\_DEVICE=“1” > MENDER\_UBOOT\_STORAGE\_DEVICE\_DEFAULT=“” > MENDER\_UBOOT\_STORAGE\_DEVICE\_DEFAULT\_mender-ubi=“dummy” I found the `0002-Generic-boot-code-for-Mender.patch` and it seems to be applied (e.g. changing `MENDER_UBOOT_STORAGE_INTERFACE` does manifest according to what the patch suggests), but how do I make sure? ---
**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\ **Post date:** [January 15, 2020, 2:50pm UTC](https://hub.mender.io/t/yocto-imx8mmevk-emmc-u-boot-problem/1216/33 "2020-01-15T14:50:26Z")
Make sure to clear the U-Boot environment when you flash the updated U-Boot binary, so you are not using an “old” environment. ---
**Author:** ![Tom](https://avatars.discourse-cdn.com/v4/letter/t/3d9bf3/32.png) [@Tom](https://hub.mender.io/u/Tom)\ **Post date:** [January 15, 2020, 2:59pm UTC](https://hub.mender.io/t/yocto-imx8mmevk-emmc-u-boot-problem/1216/34 "2020-01-15T14:59:54Z")
How would I go about clearing the “old” environment? ---
**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\ **Post date:** [January 15, 2020, 3:01pm UTC](https://hub.mender.io/t/yocto-imx8mmevk-emmc-u-boot-problem/1216/35 "2020-01-15T15:01:38Z")
You can run in U-Boot prompt: ```auto env default -a saveenv ``` ---
**Author:** ![Tom](https://avatars.discourse-cdn.com/v4/letter/t/3d9bf3/32.png) [@Tom](https://hub.mender.io/u/Tom)\ **Post date:** [January 15, 2020, 3:19pm UTC](https://hub.mender.io/t/yocto-imx8mmevk-emmc-u-boot-problem/1216/36 "2020-01-15T15:19:48Z")
Clearing the U-Boot environment did not help. How do I make sure the patch is applied? The `include/env_mender.h` file is nowhere to be found in the `build/tmp` folder. [Add:] Changing `MENDER_UBOOT_STORAGE_DEVICE_imx8mmevk` to `= "1"` in `sources/meta-mender-community/meta-mender-imx/recipes-bsp/u-boot/u-boot-imx_\%.bbappend` yields an error: > In file included from include/config.h:11:0, > from ./include/common.h:21: > include/config\_mender.h:73:5: error: #error CONFIG\_SYS\_MMC\_ENV\_DEV is not the same as MENDER\_UBOOT\_STORAGE\_DEVICE. Either set it to the same value (check for example in the defconfig file), or make sure it is not defined at all. Make sure that: 1) All the instructions at [docs.mender.io/devices/integrating-with-u-boot](http://docs.mender.io/devices/integrating-with-u-boot) have been followed. 2) All required layers are included in bblayers.conf, including any board specific layers such as meta-mender- [Add 2:] OK, after disabling `INHERIT += "rm_work"`, I can find the patch applied in: > build/tmp/work/imx8mmevk-poky-linux/u-boot-imx/2018.03-r0/git/include/env\_mender.h > and > build/tmp/work/aarch64-poky-linux/u-boot-fw-utils-mender-auto-provided/1.0-r0/git/include/env\_mender.h ---
**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\ **Post date:** [January 16, 2020, 7:20am UTC](https://hub.mender.io/t/yocto-imx8mmevk-emmc-u-boot-problem/1216/37 "2020-01-16T07:20:46Z")
> [@Tom](#): > > include/config\_mender.h:73:5: error: #error CONFIG\_SYS\_MMC\_ENV\_DEV is not the same as MENDER\_UBOOT\_STORAGE\_DEVICE. Either set it to the same value (check for example in the defconfig file), or make sure it is not defined at all. As the message says, it it is important that the CONFIG\_SYS\_MMC\_ENV\_DEV is not defined in your U-Boot sources, so remove that if possible. ---
**Author:** ![Tom](https://avatars.discourse-cdn.com/v4/letter/t/3d9bf3/32.png) [@Tom](https://hub.mender.io/u/Tom)\ **Post date:** [January 24, 2020, 1:00pm UTC](https://hub.mender.io/t/yocto-imx8mmevk-emmc-u-boot-problem/1216/38 "2020-01-24T13:00:42Z")
Hi > [@mirzak](#): > > As the message says, it it is important that the CONFIG\_SYS\_MMC\_ENV\_DEV is not defined in your U-Boot sources, so remove that if possible. I think I managed to do exactly that. It seems to be a bug in `meta-mender-community` project. Doing: ``` diff --git a/include/configs/imx8mm_evk.h b/include/configs/imx8mm_evk.h index 68d0643..c053ed3 100644 --- a/include/configs/imx8mm_evk.h +++ b/include/configs/imx8mm_evk.h @@ -249,7 +249,6 @@ #define CONFIG_ENV_OFFSET (60 << 20) #endif #define CONFIG_ENV_SIZE 0x1000 -#define CONFIG_SYS_MMC_ENV_DEV 0 /* USDHC2 */ #define CONFIG_MMCROOT "/dev/mmcblk1p2" /* USDHC2 */ ``` in `build/tmp/work/imx8mmevk-poky-linux/u-boot-imx/2018.03-r0/git/` solved the issue. ---
**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\ **Post date:** [January 24, 2020, 3:47pm UTC](https://hub.mender.io/t/yocto-imx8mmevk-emmc-u-boot-problem/1216/39 "2020-01-24T15:47:38Z")
PR with the fixes: [https://github.com/mendersoftware/meta-mender-community/pull/122](https://github.com/mendersoftware/meta-mender-community/pull/122) Thanks @Tom ---
**Author:** ![Tom](https://avatars.discourse-cdn.com/v4/letter/t/3d9bf3/32.png) [@Tom](https://hub.mender.io/u/Tom)\ **Post date:** [January 27, 2020, 11:40am UTC](https://hub.mender.io/t/yocto-imx8mmevk-emmc-u-boot-problem/1216/40 "2020-01-27T11:40:32Z")
Hi, just to clarify… it is not tested with the imx8mqevk board, right? Wouldn’t it be cleaner to split it into two distinct patches, making an eventual revert more straight forward? Of course if you tested the board, there will be no issue. [Previous page](https://hub.mender.io/t/yocto-imx8mmevk-emmc-u-boot-problem/1216.md?page=1) [Next page](https://hub.mender.io/t/yocto-imx8mmevk-emmc-u-boot-problem/1216.md?page=3)