i.MX6Q boot with eMMC v5.1

cancel
Showing results for 
Search instead for 
Did you mean: 

i.MX6Q boot with eMMC v5.1

Jump to solution
2,345 Views
frederic_coiffi
Contributor II

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 ?

Labels (2)
0 Kudos
1 Solution
603 Views
frederic_coiffi
Contributor II

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.

View solution in original post

0 Kudos
4 Replies
604 Views
frederic_coiffi
Contributor II

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.

View solution in original post

0 Kudos
603 Views
gusarambula
NXP TechSupport
NXP TechSupport

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,

0 Kudos
603 Views
frederic_coiffi
Contributor II

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.

0 Kudos
603 Views
gusarambula
NXP TechSupport
NXP TechSupport

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,

0 Kudos