We have a custom i.MX6Q design using a eMMC to boot a Linux. We run a u-boot based on rel_imx_4.1.15_1.0.0_ga tag and a Linux based on rel_imx_4.1.15_1.1.1_patch tag.
Until now, we used an eMMC v4.5 (Kingston KE4CN2H5) : our boards booted and worked fine
As the reference is now obsolete, we replaced it by an eMMC v5.1 (Kingston EMMC04G-W627-X01U) : our boards are unable to boot.
Until now, we didn't use mmcblk0boot0 and mmcblk0boot1 partitions, only the usual mmcblk0 device programmed with dd :
dd if=u-boot.imx of=/dev/mmcblk0 seek=2 bs=512
So we tried to program boot0 and setting it bootable (after enabling CONFIG_SUPPORT_EMMC_BOOT in u-boot) :
mmc bootbus 0 2 0 1 mmc partconf 0 1 1 0
But, without success.
As in Linux 4.1, the sysfs files named 'boot_bus_config' and 'boot_config' don't exist, we used mmc-utils to change the eMMC configuration at boot :
# mmc bootbus set single_hs x1 x4 /dev/mmcblk0 Changing ext_csd[BOOT_BUS_CONDITIONS] from 0x00 to 0x09
But, without success.
Concerning the hardware, our eMMC is connected to SD1. Our design differs from a SabreSD i.MX6Q as we have serial 33R on the eMMC bus.
So :
- Is there someone using eMMC v5.1 successfully on their design ?
- If someone has encountered problems with eMMC v5/5.1, how have you solved your problems ?
Solved! Go to Solution.
Hello gusarambula,
We just found why the boot was not working.
Our design was based on an old eMMC version, at the time the manufacturer we used on our first prototypes (not Kingston) had defined a ball as N/C, but should have flagged it as RFU.
We used this ball to route a data signal, and on eMMC5.1, the ball is now a GND.
We can still boot on 4-bits (we just validated this point), but can’t use 8-bit configuration. We might have to modify our design for future projects.
Hello gusarambula,
We just found why the boot was not working.
Our design was based on an old eMMC version, at the time the manufacturer we used on our first prototypes (not Kingston) had defined a ball as N/C, but should have flagged it as RFU.
We used this ball to route a data signal, and on eMMC5.1, the ball is now a GND.
We can still boot on 4-bits (we just validated this point), but can’t use 8-bit configuration. We might have to modify our design for future projects.
Hello Frederic COIFFIER,
There are some threads with similar symptoms. You may also refer to the following document:
https://community.nxp.com/docs/DOC-332187
After modify the kernel code as follows, the emmc5.0/5.1 should work on emmc 4.4 mode.
/drivers/mmc/core/mmc.c :
if (card->ext_csd.rev > 6) { // The '6' has to be replaced with '7' For EMMC5.0
// The '6' has to be replaced with '8' For EMMC5.1
pr_err("%s: unrecognised EXT_CSD revision %d\n",
mmc_hostname(card->host), card->ext_csd.rev);
err = -EINVAL;
goto out;
}
I hope this helps!
Regards,
Unfortunately, this post refers a problem with old Linux as the modified code is a Linux 3.0.35 kernel.
We're using a Linux 4.1 which works fine with the eMMC : it recognizes the eMMC and can flash it (as explained in my post).
The problem is that the i.MX6 silicon can't boot on it.
Hello Frederic Coiffier,
I understand, my apologies. However, I would still like to confirm if you made the change to the mmc.c file and had recompiled u-boot as without this change the eMMC operation may be unreliable.
Are the geometry of both memories identical?
You can flash the eMMC but it’s the booting what is failing? If that’s the case, is there any message or error being shown? If not, does SDCKE ever go high? This would indicate that the processor successfully received the first part of the boot code and acted on it.
Regards,