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
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:
Regards,
Fabio Estevam
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
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
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
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
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.
I haven't tried to applying all the series, but probably you will be able to apply it against linux-next tree.
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
No, I have not.
Please report this issue to Dong Aisheng with the linux-mmc@vger.kernel.org list on Cc.
Thanks,
Fabio Estevam
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
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
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
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
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
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
I do not remember the exact CONFIG_* but make sure you have it on your 3.11's .config.
Leo
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