DRA76P: DRA76P no booting from eMMC 5.1

Hi,

Userdata partition to start with is empty (first time boot after flashing userdata.img), as Android boots for the first time, the userdata partition is filled with contents. Userdata is the only r/w partition by default in Android.

If the eMMC part is 5.1, I am not sure why mmcinfo would show the version as 4.0. Are you sure the part you are using is eMMC 5.1?

When you say no boot what do you mean? the bootloader itself is not coming up from eMMC?

Regards,
Vishal

Also, is the SYSBOOT setting updated to boot from eMMC?

Hi Vishal,

Thank for your first analisys. Yes SYSBOOT are well configured to boot first from SD Card (no card is connected) and then from eMMC.

I was placing some traces in order to let you know better what it happens. Kernel tries to boot but get stucked when it is not able to recognize the eMMC partitions (and it is not able because kernel is not able to mount the device). Here you have the mmc0 traces both from custom and EMV boards:

EVM

[    2.550066] mmc0: 1.8v !!!
[    2.771326] mmc0: mmc_rescan_try_freq: trying to init card at 400000 Hz
[    2.779454] mmc0: mmc_hw_reset_for_init: salida return
[    2.789362] mmc0: DENTRO mmc_attach_sdio
[    2.794827] mmc0: DENTRO mmc_attach_sd
[    2.800120] mmc0: mmc_attach_mmc !!!
[    2.803748] mmc0: mmc_send_op_cond !!!
[    2.807510] mmc0: mmc_send_op_cond !!!
[    2.811288] AQUÍ LLAMAMOS A WAIT_FOR_CMD100
[    2.815905] ERROR 2
[    2.817838] mmc0: mmc_attach_bus done !!![    2.821887]
[    2.821887] mmc_init_card
[    2.849688] mmc0: mmc_send_op_cond !!!
[    2.853467] mmc0: mmc_send_op_cond !!!
[    2.857228] CALL TO WAIT_FOR_CMD iteration:100
[    2.971520] CALL TO WAIT_FOR_CMD iteration:99
[    2.976052] mmc_all_send_cid
[    2.980695] mmc0: Read extended CSD
[    2.996982] mmc0:NOT_ERR  EXT_CSD  version 2
[    3.001284] mmc0:NOT_ERR  EXT_CSD  rev 6
[    3.005224] mmc0: MAN_BKOPS_EN bit is not set
[    3.009598] mmc0:NOT_ERR  EXT_CSD   eMMC v4.5 or later
[    3.024177] mmc0: init the card. 0 !!!
[    3.027770] mmc0: >> mmc_add_card :0001
[    3.031950] mmc0: new HS200 MMC card at address 0001
[    3.037391] mmcblk0: mmc0:0001 MMC08G 7.25 GiB
[    3.037391] mmcblk0: mmc0:0001 MMC08G 7.25 GiB
[    3.042218] mmcblk0boot0: mmc0:0001 MMC08G partition 1 8.00 MiB
[    3.058458] mmcblk0boot1: mmc0:0001 MMC08G partition 2 8.00 MiB
[    3.175593] mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12 p13 p14 p15 p16 p17

CUSTOM

[    2.854788] mmc0: 1.8v !!!
[    3.099249] mmc0: mmc_rescan_try_freq: trying to init card at 400000 Hz
[    3.120293] mmc0: mmc_hw_reset_for_init: salida return
[    3.388423] mmc0: DENTRO mmc_attach_sdio
[    3.389893] mmc0: DENTRO mmc_attach_sd
[    3.391381] mmc0: mmc_attach_mmc !!!
[    3.391389] mmc0: mmc_send_op_cond !!!
[    3.391391] mmc0: mmc_send_op_cond !!!
[    3.391397] CALL TO WAIT_FOR_CMD
[    3.391769] ERROR 1, iteration=100 err=-110
[    3.391772] mmc0: PM mmc_send_op_cond. -110 !!!
[    3.391779] mmc0: mmc_power_off !!!

Then kernel continues untill it gets stuck in the last line:

[    3.893424] init: bool android::init::FirstStageMount::InitRequiredDevices(): partition(s) not found in /sys, waiting for their uevent(s): system, vendor

CALL TO WAIT_FOR_CMD is a trace placed in *mmc_send_op_cond * (mmc_ops.c). Iteration is the value of i inside the loop.

ERROR X is located on the same function

mmc_init_card is a trace placed in the mm_init_card function.

It seems to us that there is a timming problem (error -110 seems to be that), but why? Where? Could it be related to the fact that version is also not well detected in uboot?

Best regards.

So, u-boot is able to load Kernel from eMMC, but Kernel is not able to initialize eMMC?
Error code -110 is timeout.

Can you check if data lines are routed correctly? 

Also, check the below e2e link. Pull up resistors are recommended for data lines.
https://e2e.ti.com/support/processors/f/791/t/839278

Hi Vishal,

Yes, the PU resistor are in the data lines and in the cmd line (please, check the first post of this thread) but not in the clk line. 

I just measured the CLK line and I see a 400KHz clk, is this ok?

We've follow this thread to edit mux_data according to the output of our Pinmux setup:

Pinmux configuration: MMC2 mode HS200 and all lines with internal PU (as I told you before, PU resistor are in the data lines and in the cmd line)

Is there any tool to configure iodelay in order to take into account the routing length?

Regards,

Hi Vishal,

We have just solved the uboot problem. It is due to the fact that u-boot was not ready to detect eMMC memories newer than 5.0. We have patched (the lines starting + were added by us):

drivers/mmc/mmc.c

switch (ext_csd[EXT_CSD_REV]) {
		case 1:
			mmc->version = MMC_VERSION_4_1;
			break;
		case 2:
			mmc->version = MMC_VERSION_4_2;
			break;
		case 3:
			mmc->version = MMC_VERSION_4_3;
			break;
		case 5:
			mmc->version = MMC_VERSION_4_41;
			break;
		case 6:
			mmc->version = MMC_VERSION_4_5;
			break;
		case 7:
			mmc->version = MMC_VERSION_5_0;
			break;
+		case 8:
+			mmc->version = MMC_VERSION_5_1;
+			break;
+		default:
+			mmc->version = MMC_VERSION_NEWER;
+			break;
		}

And include/mmc.h

     #define MMC_VERSION_UNKNOWN	MAKE_MMC_VERSION(0, 0, 0)
     #define MMC_VERSION_1_2		MAKE_MMC_VERSION(1, 2, 0)
     #define MMC_VERSION_1_4		MAKE_MMC_VERSION(1, 4, 0)
     #define MMC_VERSION_2_2		MAKE_MMC_VERSION(2, 2, 0)
     #define MMC_VERSION_3		MAKE_MMC_VERSION(3, 0, 0)
     #define MMC_VERSION_4		MAKE_MMC_VERSION(4, 0, 0)
     #define MMC_VERSION_4_1		MAKE_MMC_VERSION(4, 1, 0)
     #define MMC_VERSION_4_2		MAKE_MMC_VERSION(4, 2, 0)
     #define MMC_VERSION_4_3		MAKE_MMC_VERSION(4, 3, 0)
     #define MMC_VERSION_4_41     	MAKE_MMC_VERSION(4, 4, 1)
     #define MMC_VERSION_4_5		MAKE_MMC_VERSION(4, 5, 0)
     #define MMC_VERSION_5_0		MAKE_MMC_VERSION(5, 0, 0)
+    #define MMC_VERSION_5_1		MAKE_MMC_VERSION(5, 1, 0)
+    #define MMC_VERSION_NEWER	        MAKE_MMC_VERSION(X, X, 0)

With this code, we get a right mmcinfo answer:

Device: OMAP SD/MMC
Manufacturer ID: 13
OEM: 14e
Name: S0J35
Tran Speed: 200000000
Rd Block Len: 512
MMC version 4.5
High Capacity: Yes
Capacity: 7.3 GiB
Bus Width: 8-bit
Erase Group Size: 512 KiB
HC WP Group Size: 8 MiB
User Capacity: 7.3 GiB WRREL
Boot Capacity: 31.5 MiB ENH
RPMB Capacity: 4 MiB ENH

Sorry for the SPAM the capture of "MMC version 4.5" it was another capture. This is the good one:

Device: OMAP SD/MMC
Manufacturer ID: 13
OEM: 14e
Name: S0J35
Tran Speed: 200000000
Rd Block Len: 512
MMC version 5.1
High Capacity: Yes
Capacity: 7.3 GiB
Bus Width: 8-bit
Erase Group Size: 512 KiB
HC WP Group Size: 8 MiB
User Capacity: 7.3 GiB WRREL
Boot Capacity: 31.5 MiB ENH
RPMB Capacity: 4 MiB ENH

What TI SDK version are you using? our code base has covered for up to version 5.0.

Could you generate Kernel logs with MMC_DEBUG enabled in Kernel defconfig? you may also have to change loglevel to 9 in Kernel (append loglevel=9 in kernel bootargs)

We are using SDK 3.02. I will add the traces support and send them to you.

We have added some traces to the kernel and we have arrive to the -110 error sorce. It comes from "mmc_wait_for_req_done" function in mmc/core/core.c

It gets this error from the "wait_for_completion" call. There is no delay between we call the function and we get the error as response. We tried to use "wait_for_completion_timeout" with a timeout of 5000ms (wait_for_completion_timeout(&mrq->completion, msecs_to_jiffies(5000));) but also we get the same error.

But the more strange thing it is that this error does not occur when you call "mmc_go_idle" funcion (when you send command 0). With this command you get no error, but with any other, you get -110

The MMC_DEBUG logs would provide information on what CMD were sent to emmc card and which CMD resulted in timeout error (-110).

Another thing to check in dts is the mmc supply parameters.
- vmmc-supply property should be set to Vdd voltage supply of the card
- vmmc_aux-supply property should be set to Vio voltage supply for I/O lines

Hi Vishal,

We have tried to update the dts changes you suggested (althouth it is not done that way for the EVM), and we get the same result.

The CMD that are been sending are: 0x00, 0x05, 0x08, 0x05, 0x55, 0x55, 0x55 0x55. All of them but 0x00 returns -110 (timeout error). And 0x00 seems not to give timeout error because it is called with MMC_RSP_NONE flag option...

We have painted the ios structure values, and all of them are similar but for "ios.vdd" that is 15 for the EVM and 7 for ours.

Best regards.

Hi, is there any script to read eMMC with XDS probe? I'm talking about something like this: http://git.ti.com/sitara-dss-files/am57xx-dss-files/blobs/raw/master/am57xx-ddr.dss

Regards,

Hi Roxu,

Vdd value 0x15 implies 3.3 V,  I think 0x7 is for 1.65 to 1.95 volts.

Regards,
Vishal

Could you share the full Kernel log which has CONFIG_MMC enabled?

Thanks for the update. Glad it's resolved.