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]
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 .
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.
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.
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?
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?
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
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
…
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?
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 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
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.
