Can't access eMMC when using LTIB rootfs with newer (3.11.4) kernel, why?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Can't access eMMC when using LTIB rootfs with newer (3.11.4) kernel, why?

3,579 Views
EdSutter
Senior Contributor II

Hi,

I'm using mainline kernel 3.11.4 with SABRESDB and the LTIB-supplied rootfs, and just noticed that I can't see the eMMC.

If I insert the SD card, then "cat /proc/partitions" shows me:

major minor  #blocks  name

179        0    7761920 mmcblk0

179        1    7753728 mmcblk0p1

But with it removed, there's nothing listed (even though eMMC is there).

If I switch back to using the LTIB-based kernel, eMMC shows up in /proc/partitions.

What is it in the kernel that I need to tweak to see eMMC?

Ed

Labels (2)
17 Replies

1,779 Views
fabio_estevam
NXP Employee
NXP Employee

Looking at the sabresd dts file in 3.11/3.12 we will see that there are only 2 sdhc ports instead of 3.

You need to manually add the sdhc4 node, as this is the port connected to the eMMC.

You can refer how this was implemented in the 3.10 FSL kernel:

http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/boot/dts/imx6qdl-sabresd.d...

Regards,

Fabio Estevam

1,779 Views
EdSutter
Senior Contributor II

Fabio,

Ok, thanks, that appears to be a step in the right direction (I'll post the changes I made when everything works).

Its slightly different than the code you point to in git, I'm guessing simply due to some reorganization that has not found its way back to the mainline?

Anyway, now I see mmcblk0 in /proc/partitions...

# cat /proc/partitions

major minor  #blocks  name

179        0    7757824 mmcblk0

179        1    7749632 mmcblk0p1

179      24        128 mmcblk0rpmb

179      16      2048 mmcblk0boot1

179        8      2048 mmcblk0boot0


but still having issues:

1. At bootup I get a message: mmc2: Timeout waiting for hardware interrupt.

2. I do the following:

    $ mknod /dev/mmcblk0 b 179 0

     $ fdisk /dev/mmcblk0     # u d n p 1 16384 <ENTER> w

     $ mkfs.ext3 /dev/mmcblk0p1

and it is horribly slow at "Discarding device blocks:  NNNN/1937408"

Could this be related to the hardware interrupt timeout?

--EDIT--

Note that despite the time it took (close to 30 minutes) to complete the mkfs.ext3 step above,

I was able to copy a rootfs to the eMMC and boot off of it.  So, as far as I can tell, the only

remaining issue is the timeout (assuming that is the cause for the delay).

Ed

0 Kudos

1,779 Views
fabio_estevam
NXP Employee
NXP Employee

Hi Ed,

This morning I tried it on my mx6qsabresd and I got the same timeout issue that you mentioned.

I posted this on the linux-arm-kernel list with the maintainers on Cc:

http://marc.info/?l=linux-arm-kernel&m=138478621624345&w=2

Hopefully someone will give us some help with this problem.

Regards,

Fabio Estevam

0 Kudos

1,779 Views
EdSutter
Senior Contributor II

Fabio,

Great... Glad to hear we're seeing the same issue.

Looking forward to hearing back from them.

Note that IIRC, when I was working with LTIB versions of this stuff (rootfs/kernel) this was not a problem.

Ed

0 Kudos

1,779 Views
fabio_estevam
NXP Employee
NXP Employee

Ed,

Dong replied and told me that he prepared a series of patches that fixes this issue.

Please apply the series from:

http://comments.gmane.org/gmane.linux.kernel.mmc/23339

Regards,

Fabio Estevam

0 Kudos

1,779 Views
EdSutter
Senior Contributor II

Fabio,

What version/branch do these patches apply to?

I was able to install just the one patch you mention, but the others don't line up with

the source I have (mainline 3.11.4).  I tried looking at Freescale Public GIT but didn't see

what I thought was the right version there either.

0 Kudos

1,779 Views
fabio_estevam
NXP Employee
NXP Employee

I haven't tried to applying all the series, but probably you will be able to apply it against linux-next tree.

0 Kudos

1,779 Views
EdSutter
Senior Contributor II

Fabio,

Ok, I managed to pull in the patches using mainline 3.12 plus patch-v3.12-next-20131119 .

Still when I attempt to do a mkfs.ext3 it takes a ridiculously long time (over an hour).

Have you actually tried to do a mkfs.ext3 on the eMMC?

Ed

0 Kudos

1,779 Views
fabio_estevam
NXP Employee
NXP Employee

No, I have not.

Please report this issue to Dong Aisheng with the linux-mmc@vger.kernel.org list on Cc.

Thanks,

Fabio Estevam

0 Kudos

1,779 Views
EdSutter
Senior Contributor II

Fabio,

I have no idea if I'll get a response from that list, so I'm still hunting...

Is it possible I'm just doing something else wrong here?...

Here are my steps (with the goal being that I want to install rootfs directly on the eMMC)...

1. At startup, there are no mmc devices in /dev, so I run:

# cat /proc/partitions

  major minor  #blocks  name

   179    0    7757824 mmcblk0

   179    1    7749632 mmcblk0p1

   179    24       128 mmcblk0rpmb

   179    16      2048 mmcblk0boot1

   179    8       2048 mmcblk0boot0

2. Then  I do the following:

$ mknod /dev/mmcblk0 b 179 0

$ fdisk /dev/mmcblk0     # u d n p 1 16384 <ENTER> w

$ mkfs.ext3 /dev/mmcblk0p1    <<<This is the step that takes ridiculously long


Ed

0 Kudos

1,779 Views
fabio_estevam
NXP Employee
NXP Employee

I haven't seen your post in the list yet.

Does mkfs.ext3 perform faster if you run it for the regular SD card instead?

Usually this task is done on the host PC side;

Regards,

Fabio Estevam

0 Kudos

1,779 Views
EdSutter
Senior Contributor II

Fabio,

Sorry for the late response.  I was out-of-the-office Thurs-Fri.

What do you mean by "Usually this task is done on the host PC side"?

I assume you're thinking of the SD card case, where I could plug the card into the host box's SD card slot

and format it there, correct?  Can't do that with eMMC (as you know).

EDIT--- Forgot to mention that it did work for SD card on the SABRESD, so the issue is specific to eMMC.

Ed

0 Kudos

1,779 Views
EdSutter
Senior Contributor II

Ok, I didn't know how to email Dong Aisheng directly, so I sent the mail to linux-mmc@vger.kernel.org and addressed him.

Hopefully he'll get it.

Ed

0 Kudos

1,779 Views
fabio_estevam
NXP Employee
NXP Employee

Ed,

If you only apply this patch:

http://www.spinics.net/lists/arm-kernel/msg283251.html

,then the timeout issue does not happen.

Regards,

Fabio Estevam

1,779 Views
EdSutter
Senior Contributor II

Fabio,

Yep, I get the same result; however, when I try to do  "mkfs.ext3 /dev/mmcblk0p1" it appears to totally hang now.

The step "Discarding device blocks: NNNN/1933310", NNNN is not changing at all (or if it is, it even slower than

yesterday).

EDIT--- I had to go to a meeting while this "mkfs.ext3 /dev/mmcblk0p1" step was running, so I let it run.

Turns out it wasn't hung, it just took 80 minutes to complete! 

I'll try applying the other patches and let you know if it gets better.

Thanks,

Ed

0 Kudos

1,779 Views
LeonardoSandova
Specialist I

I do not remember the exact CONFIG_* but make sure you have it on your 3.11's .config.

Leo

0 Kudos

1,779 Views
EdSutter
Senior Contributor II

Leo,

Thanks, yea, that's the big unknown.  :-)

The 3.11.4 kernel does support SD-card MMC, but doesn't know about eMMC.

Referring to the startup logs for LTIB kernel...

...

sdhci: Secure Digital Host Controller Interface driver

sdhci: Copyright(c) Pierre Ossman

mmc0: SDHCI controller on platform [sdhci-esdhc-imx.3] using DMA

mmc1: SDHCI controller on platform [sdhci-esdhc-imx.1] using DMA

mmc2: SDHCI controller on platform [sdhci-esdhc-imx.2] using DMA

...


then, for the newer kerel...

...

sdhci: Secure Digital Host Controller Interface driver

sdhci: Copyright(c) Pierre Ossman

sdhci-pltfm: SDHCI platform and OF driver helper

mmc0: no vqmmc regulator found

mmc0: no vmmc regulator found

mmc0: SDHCI controller on 2194000.usdhc [2194000.usdhc] using ADMA

mmc1: no vqmmc regulator found

mmc1: no vmmc regulator found

mmc1: SDHCI controller on 2198000.usdhc [2198000.usdhc] using ADMA

...

Not sure why the 3.11.4 kernel only looks at mmc0 & 1; but the LTIB kernel looks at all three.

Ed

0 Kudos