[PATCH 1/1] ARM: dts: sunxi: Add a olinuxino-lime2-emmc

[Olliver Schinagl]

There are 3 kinds of OLinuXino Lime2 boards.
One without any on board storage, one with NAND storage and one with
eMMC storage. This patch adds the eMMC variant of boards.

eMMC storage is different from a regular SD card in that it is soldered
on the board and cannot be changed. Additionally, it shares pins with
the NAND module and with the second SPI port.

Signed-off-by: Olliver Schinagl <oli...@schinagl.nl>
---
.../boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts | 64 ++++++++++++++++++++++
1 file changed, 64 insertions(+)
create mode 100644 arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts

diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
new file mode 100644
index 0000000..689da36
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
@@ -0,0 +1,64 @@
+ /*
+ * Copyright 2015 - Ultimaker B.V.
+ * Author Olliver Schinagl <oli...@schinagl.nl>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "sun7i-a20-olinuxino-lime2.dts"
+
+/ {
+ model = "Olimex A20-OLinuXino-LIME2-eMMC";
+};
+
+&mmc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc2_pins_a>;
+ vmmc-supply = <&reg_vcc3v3>;
+ bus-width = <4>;
+ non-removable;
+ no-1-8-v;
+ status = "okay";
+
+ emmc: emmc@0 {
+ reg = <0>;
+ compatible = "mmc-card";
+ broken-hpi;
+ };
+};
--
2.8.0.rc3

[Maxime Ripard]

Hi,

On Thu, Apr 28, 2016 at 09:19:58AM +0200, Olliver Schinagl wrote:
> There are 3 kinds of OLinuXino Lime2 boards.
> One without any on board storage, one with NAND storage and one with
> eMMC storage. This patch adds the eMMC variant of boards.
>
> eMMC storage is different from a regular SD card in that it is soldered
> on the board and cannot be changed. Additionally, it shares pins with
> the NAND module and with the second SPI port.
>
> Signed-off-by: Olliver Schinagl <oli...@schinagl.nl>

Is it a publicly available board, or is it a private hack you made
yourself?

Maxime

--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Chen-Yu Tsai]

Hi,

Only 4 bits? We normally see eMMC with 8 bits. 4 bits are some kind of
embedded SD card.

> + non-removable;
> + no-1-8-v;

This flag is not supported on sunxi.

Instead, use the vqmmc-supply with the correct regulator and constraints.

ChenYu

[Olliver Schinagl]

Hey Chen,

On A20 as well? Our investigations so far have concluded that the A10
and A20 have those pins not mapped out to pads. The IP does support it
however we assume.

>
>> + non-removable;
>> + no-1-8-v;
> This flag is not supported on sunxi.
>
> Instead, use the vqmmc-supply with the correct regulator and constraints.

That was not supposed to be there, i'll fix it! Sorry.

[Chen-Yu Tsai]

On Tue, May 3, 2016 at 3:21 PM, Olliver Schinagl <oli...@schinagl.nl> wrote:
> Hey Chen,

ChenYu :)

You're right. My bad. First time A10/A20 sees eMMC support.

>>
>>
>>> + non-removable;
>>> + no-1-8-v;
>>
>> This flag is not supported on sunxi.
>>
>> Instead, use the vqmmc-supply with the correct regulator and constraints.
>
> That was not supposed to be there, i'll fix it! Sorry.

Thanks
ChenYu

[Olliver Schinagl]

There are 3 kinds of OLinuXino Lime2 boards.
One without any on board storage, one with NAND storage and one with
eMMC storage. This patch adds the eMMC variant of boards.

eMMC storage is different from a regular SD card in that it is soldered
on the board and cannot be changed. Additionally, it shares pins with
the NAND module and with the second SPI port.

Signed-off-by: Olliver Schinagl <oli...@schinagl.nl>
---
.../boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts | 64 ++++++++++++++++++++++
1 file changed, 64 insertions(+)
create mode 100644 arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts

diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
new file mode 100644

index 0000000..b49aafe

+ vqmmc-supply = <&reg_vcc3v3>;
+ bus-width = <4>;
+ non-removable;

+ status = "okay";
+
+ emmc: emmc@0 {
+ reg = <0>;
+ compatible = "mmc-card";
+ broken-hpi;
+ };
+};
--

2.8.1

[Maxime Ripard]

Hi,

On Tue, May 03, 2016 at 12:12:06AM -0700, christ...@gmail.com wrote:
> Hi to All,
>
> I have already solved and tested this issue on Armbian build. Find
> patches for both legacy (3.4.111) and mainline (4.5.2) kernels on:
> http://forum.armbian.com/index.php/topic/853-armbian-customization/page-2#entry7494
> There it is also described how to do eMMC bootable and much more.
>
> About the board - Olimex already sold all 3 kinds after migration to
> their HW rev. E. One have to specify Lime2-eMMC as
> A20-Olinuxino-Lime2-eMMC instead of their old 2 options
> A20-Olinuxino-Lime2(-4GB).

Interesting, you have a link to that device?

Thanks,

[christ...@gmail.com]

Hi to All,

I have already solved and tested this issue on Armbian build.
Find patches for both legacy (3.4.111) and mainline (4.5.2) kernels on:
http://forum.armbian.com/index.php/topic/853-armbian-customization/page-2#entry7494
There it is also described how to do eMMC bootable and much more.

About the board - Olimex already sold all 3 kinds after migration to their HW rev. E. One have to specify Lime2-eMMC as A20-Olinuxino-Lime2-eMMC instead of their old 2 options A20-Olinuxino-Lime2(-4GB).

Regards
Chris

[christ...@gmail.com]

On Tuesday, May 3, 2016 at 4:14:41 PM UTC+3, Maxime Ripard wrote:
> Hi,
>

I have really 2 boards delivered by their local distributor.

Unfortunately, they do not update their site. Use the link for NAND option:
https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXIno-LIME2-4GB/open-source-hardware
There you can find Users Manual where it is described that eMMC option is available from HW rev. D. The schematic for HW rev. E is also available on their repository:
https://github.com/OLIMEX/OLINUXINO/tree/master/HARDWARE/A20-OLinuXino-LIME2

On the board both 4GB NAND and eMMC Flash chips can be placed alternatively on the same place. There is difference in some other components as well.

If one want to order it from the site probably has to order A20-Olinuxino-Lime2-4GB with note that eMMC option is required. The price is the same.

[Olliver Schinagl]

Hey all,

Sorry for the late reply, but yeah the board exists, we asked Olimex to
develop the eMMC variant for us. I currently have a dozen or so on my
desk :)

I don't know when Olimex will update their webshop with the new designs,
but they simply might not have enough eMMC chips available yet?

[Christo Radev]

Hi Oliver,

Nice to hear it. Thanks to Olimex I also have 2 board and make series of tests and customization effort based on Armbian build scripts.
I have passed through patching and customization of U-Boot, Kernel (both legacy 3.4.111 and mainline 4.5.2), Debian Jessie as FS, RPI Monitor etc.
All my steps are described in a couple of posts on Armbian forum where the main one is:
http://forum.armbian.com/index.php/topic/853-armbian-customization
There one can find all patches I have used, step by step instruction on how to install and boot from eMMC, SD/MMC, SATA, some measurements and tests.
One of the useful things in my opinion is U-Boot script to boot from available boot devices in given order and usage of user button for emergency boot from eMMC or SD/MMC.

Of course, my customization effort is not finished so some help in USB OTG activation and read-only rootfs preparation will be welcome.

Any help or notes on how the things can be done in a better way will be appreciated as well.

Regards
Chris

[Priit Laes]

On Tue, 2016-05-03 at 17:52 +0200, Olliver Schinagl wrote:
> Hey all,
>
> On 03-05-16 17:02, christ...@gmail.com wrote:
> > On Tuesday, May 3, 2016 at 4:14:41 PM UTC+3, Maxime Ripard wrote:
> > > Hi,
> > >
> > > On Tue, May 03, 2016 at 4:12:06 PM UTC+3, Christo Radev wrote:
> > > > Hi to All,
> > > >
> > > > I have already solved and tested this issue on Armbian build.
> > > > Find
> > > > patches for both legacy (3.4.111) and mainline (4.5.2) kernels
> > > > on:
> > > > http://forum.armbian.com/index.php/topic/853-armbian-customizat
> > > > ion/page-2#entry7494
> > > > There it is also described how to do eMMC bootable and much
> > > > more.
> > > >
> > > > About the board - Olimex already sold all 3 kinds after
> > > > migration to
> > > > their HW rev. E. One have to specify Lime2-eMMC as
> > > > A20-Olinuxino-Lime2-eMMC instead of their old 2 options
> > > > A20-Olinuxino-Lime2(-4GB).
> > > Interesting, you have a link to that device?

I guess, it is this one:

https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXino-LIME2-eMMC/
open-source-hardware

[Christo Radev]

Exactly, the site is finally updated.

[Radoslav Kolev]

I can't say anything about A10/A20, but I have a board with A13 and
the same eMMC chip and it works fine in 8 bit mode.

Regards,
Radoslav

[Olliver Schinagl]

Hey Radoslav,

Yep, sun5i actually brings them all out to pads, the A20 however does
not :( We first thought that the A20 would also be an 8bitter, because
the mmc IP appears to be the same as sun5i, but initial tests show it is
not. As for A10, it has older IP and it might not even support 8 bit
mode, let alone bring out the pins.

But with A20's + eMMC being available via the lime2, others may repeat
my experiments! The lime2 is 8 bit connected.

Olliver
>
> Regards,
> Radoslav

[Christo Radev]

Hi Olliver,

I have already test it a few weeks ago and definitely can say that 8-bit bus did not work on A20-Olinuxino-Lime2-eMMC with mainline kernel.
See may post here.

Best regards

Chris

[Olliver Schinagl]

There are 3 kinds of OLinuXino Lime2 boards.
One without any on board storage, one with NAND storage and one with
eMMC storage. This patch adds the eMMC variant of boards.

eMMC storage is different from a regular SD card in that it is soldered
on the board and cannot be changed. Additionally, it shares pins with
the NAND module and with the second SPI port.

Signed-off-by: Olliver Schinagl <oli...@schinagl.nl>
---

.../boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts | 81 ++++++++++++++++++++++
1 file changed, 81 insertions(+)

create mode 100644 arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts

diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
new file mode 100644

index 0000000..9680fcb
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
@@ -0,0 +1,81 @@

+ mmc2_pwrseq: pwrseq {
+ pinctrl-0 = <&mmc2_pins_nrst>;
+ pinctrl-names = "default";
+ compatible = "mmc-pwrseq-emmc";
+ reset-gpios = <&pio 2 16 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&pio {
+ mmc2_pins_nrst: mmc2@0 {
+ allwinner,pins = "PC16";
+ allwinner,function = "gpio_out";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };

+};
+
+&mmc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc2_pins_a>;
+ vmmc-supply = <&reg_vcc3v3>;
+ vqmmc-supply = <&reg_vcc3v3>;
+ bus-width = <4>;
+ non-removable;

+ mmc-pwrseq = <&mmc2_pwrseq>;

[Olliver Schinagl]

Hey Christo,

On 04-05-16 15:07, Christo Radev wrote:

Hi Olliver,

I have already test it a few weeks ago and definitely can say that 8-bit bus did not work on A20-Olinuxino-Lime2-eMMC with mainline kernel.
See may post here.

I saw, but you forgot to define the pins for 4.x :)

See my patch from earlier: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-September/368887.html

Olliver

[Christo Radev]

Hi Oliver,

I do: that http://forum.armbian.com/index.php/topic/853-armbian-customization/page-2#entry7359
The syntax error seen there was fixed and the result is: http://forum.armbian.com/index.php/topic/853-armbian-customization/page-2#entry7361

The same tests was done on legacy kernel 3.4.111 modifying fex file and the result is the same: http://forum.armbian.com/index.php/topic/853-armbian-customization/page-2#entry7265


Best regards
Chris

[Olliver Schinagl]

Hey Christo,

On 04-05-16 15:32, Christo Radev wrote:

Hi Oliver,

I do: that http://forum.armbian.com/index.php/topic/853-armbian-customization/page-2#entry7359
The syntax error seen there was fixed and the result is: http://forum.armbian.com/index.php/topic/853-armbian-customization/page-2#entry7361

Nope, you are still forgetting and seeing an 'unsupported function' error because of it.

You forgot to add:

>>>          SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 12),
>>>                    SUNXI_FUNCTION(0x0, "gpio_in"),
>>>                    SUNXI_FUNCTION(0x1, "gpio_out"),
>>> -                 SUNXI_FUNCTION(0x2, "nand0")),        /* NDQ4 */
>>> +                 SUNXI_FUNCTION(0x2, "nand0"),         /* NDQ4 */
>>> +                 SUNXI_FUNCTION(0x3, "mmc2")),         /* D4 */
>>>          SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 13),
>>>                    SUNXI_FUNCTION(0x0, "gpio_in"),
>>>                    SUNXI_FUNCTION(0x1, "gpio_out"),
>>> -                 SUNXI_FUNCTION(0x2, "nand0")),        /* NDQ5 */
>>> +                 SUNXI_FUNCTION(0x2, "nand0"),         /* NDQ5 */
>>> +                 SUNXI_FUNCTION(0x3, "mmc2")),         /* D5 */
>>>          SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 14),
>>>                    SUNXI_FUNCTION(0x0, "gpio_in"),
>>>                    SUNXI_FUNCTION(0x1, "gpio_out"),
>>> -                 SUNXI_FUNCTION(0x2, "nand0")),        /* NDQ6 */
>>> +                 SUNXI_FUNCTION(0x2, "nand0"),         /* NDQ6 */
>>> +                 SUNXI_FUNCTION(0x3, "mmc2")),         /* D6 */
>>>          SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 15),
>>>                    SUNXI_FUNCTION(0x0, "gpio_in"),
>>>                    SUNXI_FUNCTION(0x1, "gpio_out"),
>>> -                 SUNXI_FUNCTION(0x2, "nand0")),        /* NDQ7 */
>>> +                 SUNXI_FUNCTION(0x2, "nand0"),         /* NDQ7 */
>>> +                 SUNXI_FUNCTION(0x3, "mmc2")),         /* D7 */

to actually get the pin functions.

[Christo Radev]

Tanks Oliver,

It could be the problem to get 8-bit access working.

Unfortunately, I do not see where to make this changes because original dts files are used in Armbian build.
I also see 'SUNXI_PINCTRL_PIN' and 'SUNXI_FUNCTION' may require some patches in addition.

I am ready to make 8-bit eMMC access tests again so could you help me with the needed staff it has to be used.

Best regards
Chris

[Olliver Schinagl]

Christo,

On 04-05-16 16:31, Christo Radev wrote:

Tanks Oliver,

It could be the problem to get 8-bit access working.

Unfortunately, I do not see where to make this changes because original dts files are used in Armbian build.
I also see 'SUNXI_PINCTRL_PIN' and 'SUNXI_FUNCTION' may require some patches in addition.

check out drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c

my patch should still work aginst that.

I am ready to make 8-bit eMMC access tests again so could you help me with the needed staff it has to be used.

I don't mind, but lets take it off list for that :)

[Christo Radev]

Thanks Oliver,

I find it and will be back with the test results.

Best regards
Chris

[Christo Radev]

Hi Oliver,

I have just tested your patch and the access to eMMC is working.
There you are complete patch I have applied against kernel 4.5.2:

index d5c796c..1f5339d 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
@@ -188,6 +188,15 @@
     status = "okay";
 };

 
+&mmc2 {
+    pinctrl-names = "default";
+    pinctrl-0 = <&mmc2_pins_a>;
+    vmmc-supply = <&reg_vcc3v3>;

+    bus-width = <8>;
+    non-removable;

+    status = "okay";
+};
+

 &ohci0 {
     status = "okay";
 };
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 3d5087b..78668aa 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -504,7 +504,7 @@ static int mmc_decode_ext_csd(struct mmc_card *card, u8 *ext_csd)
                 pr_info("%s: MAN_BKOPS_EN bit is not set\n",
                     mmc_hostname(card->host));
         }
-
+#if 0
         /* check whether the eMMC card supports HPI */
         if (!broken_hpi && (ext_csd[EXT_CSD_HPI_FEATURES] & 0x1)) {
             card->ext_csd.hpi = 1;
@@ -519,7 +519,7 @@ static int mmc_decode_ext_csd(struct mmc_card *card, u8 *ext_csd)
             card->ext_csd.out_of_int_time =
                 ext_csd[EXT_CSD_OUT_OF_INTERRUPT_TIME] * 10;
         }
-
+#endif
         card->ext_csd.rel_param = ext_csd[EXT_CSD_WR_REL_PARAM];
         card->ext_csd.rst_n_function = ext_csd[EXT_CSD_RST_N_FUNCTION];
 
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c b/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
index cf1ce0c..9fc12d2 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
@@ -314,19 +314,23 @@ static const struct sunxi_desc_pin sun7i_a20_pins[] = {

     SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 12),
           SUNXI_FUNCTION(0x0, "gpio_in"),
           SUNXI_FUNCTION(0x1, "gpio_out"),
-          SUNXI_FUNCTION(0x2, "nand0")),    /* NDQ4 */
+          SUNXI_FUNCTION(0x2, "nand0"),        /* NDQ4 */
+          SUNXI_FUNCTION(0x3, "mmc2")),         /* D4 */
     SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 13),
           SUNXI_FUNCTION(0x0, "gpio_in"),
           SUNXI_FUNCTION(0x1, "gpio_out"),
-          SUNXI_FUNCTION(0x2, "nand0")),    /* NDQ5 */
+          SUNXI_FUNCTION(0x2, "nand0"),    /* NDQ5 */
+          SUNXI_FUNCTION(0x3, "mmc2")),         /* D5 */
     SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 14),
           SUNXI_FUNCTION(0x0, "gpio_in"),
           SUNXI_FUNCTION(0x1, "gpio_out"),
-          SUNXI_FUNCTION(0x2, "nand0")),    /* NDQ6 */
+          SUNXI_FUNCTION(0x2, "nand0"),    /* NDQ6 */
+          SUNXI_FUNCTION(0x3, "mmc2")),         /* D6 */
     SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 15),
           SUNXI_FUNCTION(0x0, "gpio_in"),
           SUNXI_FUNCTION(0x1, "gpio_out"),
-          SUNXI_FUNCTION(0x2, "nand0")),    /* NDQ7 */
+          SUNXI_FUNCTION(0x2, "nand0"),    /* NDQ7 */
+          SUNXI_FUNCTION(0x3, "mmc2")),         /* D7 */

     SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 16),

           SUNXI_FUNCTION(0x0, "gpio_in"),
           SUNXI_FUNCTION(0x1, "gpio_out"),

And the boot messages:

[    3.598495] sunxi-mmc 1c0f000.mmc: Got CD GPIO
[    3.631826] sunxi-mmc 1c0f000.mmc: base:0xf08da000 irq:26
[    3.668943] mmc0: host does not support reading read-only switch, assuming write-enable
[    3.671887] sunxi-mmc 1c11000.mmc: base:0xf08de000 irq:27
[    3.671935] mmc0: new high speed SDHC card at address 0007
[    3.672939] mmcblk0: mmc0:0007 SD04G 3.71 GiB
[    3.674799]  mmcblk0: p1
[    3.682634] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 8, RTO !!
[    3.687921] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[    3.688785] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[    3.689643] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[    3.690477] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[    3.725492] mmc1: MAN_BKOPS_EN bit is not set
[    3.729187] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 8, RD EBE !!
[    3.729228] sunxi-mmc 1c11000.mmc: data error, sending stop command
[    3.729247] sunxi-mmc 1c11000.mmc: send stop command failed
[    3.729270] mmc1: switch to bus width 2 failed
[    3.733592] mmc1: new high speed MMC card at address 0001
[    3.734478] mmcblk1: mmc1:0001 P1XXXX 3.60 GiB
[    3.734889] mmcblk1boot0: mmc1:0001 P1XXXX partition 1 16.0 MiB
[    3.735305] mmcblk1boot1: mmc1:0001 P1XXXX partition 2 16.0 MiB
[    3.736551]  mmcblk1: p1
[    4.155620] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data mode. Opts: (null)
[    8.163191] EXT4-fs (mmcblk0p1): re-mounted. Opts: commit=600,errors=remount-ro

where mmc0 is SD/MMC card and mmc1 is eMMC on my A20-Olinuxino-Lime2-eMMC board.

Fortunately or not the same error and fail messages can be observed in my board log.

How can I verify how wide is the eMMC bus used in real?

Best regards
Chris

[Maxime Ripard]

On Wed, May 04, 2016 at 03:17:33PM +0200, Olliver Schinagl wrote:
> There are 3 kinds of OLinuXino Lime2 boards.
> One without any on board storage, one with NAND storage and one with
> eMMC storage. This patch adds the eMMC variant of boards.
>
> eMMC storage is different from a regular SD card in that it is soldered
> on the board and cannot be changed. Additionally, it shares pins with
> the NAND module and with the second SPI port.
>
> Signed-off-by: Olliver Schinagl <oli...@schinagl.nl>

As a general comment, having a log of the changes helps a lot,
especially when you roll new versions quiclky.

You should have a compatible here too.

Thanks!

[Christo Radev]

Hi Oliver,

I start performance tests for eMMC, SD/MMC, USB, SATA SSD devices and will post the result when ready.

As a beginning I can say that eMMC is accessed via 4-bit bus without matter of the patch used.
There you are the content of /sys/kernel/debug/mmcX/ios (where X is number of eMMC or SD/MMC device).

Booted from SD card with 8-bit patched kernel
root@egpr:~# dmesg | grep mmc
[    3.599625] sunxi-mmc 1c0f000.mmc: Got CD GPIO
[    3.631883] sunxi-mmc 1c0f000.mmc: base:0xf08da000 irq:26
[    3.669058] mmc0: host does not support reading read-only switch, assuming write-enable
[    3.671674] sunxi-mmc 1c11000.mmc: base:0xf08de000 irq:27
[    3.672064] mmc0: new high speed SDHC card at address 0007
[    3.673068] mmcblk0: mmc0:0007 SD04G 3.71 GiB
[    3.674785]  mmcblk0: p1
[    3.682261] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 8, RTO !!
[    3.689280] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[    3.690146] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[    3.690977] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[    3.691808] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[    3.745505] mmc1: MAN_BKOPS_EN bit is not set
[    3.749187] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 8, RD EBE !!
[    3.749229] sunxi-mmc 1c11000.mmc: data error, sending stop command
[    3.749247] sunxi-mmc 1c11000.mmc: send stop command failed
[    3.749268] mmc1: switch to bus width 2 failed
[    3.753586] mmc1: new high speed MMC card at address 0001
[    3.754479] mmcblk1: mmc1:0001 P1XXXX 3.60 GiB
[    3.754961] mmcblk1boot0: mmc1:0001 P1XXXX partition 1 16.0 MiB
[    3.755604] mmcblk1boot1: mmc1:0001 P1XXXX partition 2 16.0 MiB
[    3.757045]  mmcblk1: p1
[    4.216879] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data mode. Opts: (null)
[    7.907002] EXT4-fs (mmcblk0p1): re-mounted. Opts: commit=600,errors=remount-ro

root@egpr:~# cat /sys/kernel/debug/mmc0/ios
clock:          50000000 Hz
vdd:            21 (3.3 ~ 3.4 V)
bus mode:       2 (push-pull)
chip select:    0 (don't care)
power mode:     2 (on)
bus width:      2 (4 bits)
timing spec:    2 (sd high-speed)
signal voltage: 0 (3.30 V)
driver type:    0 (driver type B)
root@egpr:~# cat /sys/kernel/debug/mmc1/ios
clock:          50000000 Hz
vdd:            21 (3.3 ~ 3.4 V)
bus mode:       2 (push-pull)
chip select:    0 (don't care)
power mode:     2 (on)
bus width:      2 (4 bits)
timing spec:    1 (mmc high-speed)
signal voltage: 0 (3.30 V)
driver type:    0 (driver type B)

Booted from SATA SSD with 4-bit patched kernel
[    3.598868] sunxi-mmc 1c0f000.mmc: Got CD GPIO
[    3.631154] sunxi-mmc 1c0f000.mmc: base:0xf08da000 irq:26
[    3.668313] mmc0: host does not support reading read-only switch, assuming write-enable
[    3.670908] sunxi-mmc 1c11000.mmc: base:0xf08de000 irq:27
[    3.671324] mmc0: new high speed SDHC card at address 0007
[    3.672302] mmcblk0: mmc0:0007 SD04G 3.71 GiB
[    3.674067]  mmcblk0: p1
[    3.681882] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 8, RTO !!
[    3.686129] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[    3.686996] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[    3.687843] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[    3.688672] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[    3.724762] mmc1: MAN_BKOPS_EN bit is not set
[    3.731196] mmc1: new high speed MMC card at address 0001
[    3.732141] mmcblk1: mmc1:0001 P1XXXX 3.60 GiB
[    3.732553] mmcblk1boot0: mmc1:0001 P1XXXX partition 1 16.0 MiB
[    3.732960] mmcblk1boot1: mmc1:0001 P1XXXX partition 2 16.0 MiB
[    3.734186]  mmcblk1: p1

root@egpr:~# cat /sys/kernel/debug/mmc0/ios
clock:          50000000 Hz
vdd:            21 (3.3 ~ 3.4 V)
bus mode:       2 (push-pull)
chip select:    0 (don't care)
power mode:     2 (on)
bus width:      2 (4 bits)
timing spec:    2 (sd high-speed)
signal voltage: 0 (3.30 V)
driver type:    0 (driver type B)
root@egpr:~# cat /sys/kernel/debug/mmc1/ios
clock:          50000000 Hz
vdd:            21 (3.3 ~ 3.4 V)
bus mode:       2 (push-pull)
chip select:    0 (don't care)
power mode:     2 (on)
bus width:      2 (4 bits)
timing spec:    1 (mmc high-speed)
signal voltage: 0 (3.30 V)
driver type:    0 (driver type B)

The brief performance test using dd shows the similar results to both 4- and 8-bit patches

eMMC 8-bit patch R/W test with dd
root@egpr:/mnt# dd if=/dev/zero of=1GBfile bs=1M count=1K
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 79.9305 s, 13.4 MB/s
root@egpr:/mnt# dd of=/dev/null if=1GBfile
2097152+0 records in
2097152+0 records out
1073741824 bytes (1.1 GB) copied, 49.5899 s, 21.7 MB/s

eMMC 4-bit patch R/W test with dd
root@egpr:/mnt# dd if=/dev/zero of=1GBfile bs=1M count=1K
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 78.7925 s, 13.6 MB/s
root@egpr:/mnt# dd of=/dev/null if=1GBfile
2097152+0 records in
2097152+0 records out
1073741824 bytes (1.1 GB) copied, 53.8002 s, 20.0 MB/s

In my opinion 8-bit access to eMMC is broken in Allwinned A20 or in the mmc driver.

Best regards
Chris

[Olliver Schinagl]

Hey Christo,

Nah, it's not broken. But Allwinner 'forgot' to map the mmc controller pins to the mux and thus the additional 4 bits are not on the actual pins. It is sad and wasn't necessary, I'm sure it's just a small over sight, which is costing us performance now. But we get a big improvement by using the latest 4.6-rc1+ kernel by using HS-DDR mode. In my early tests I saw 40 MB/s read and 17 MB/s write speeds. It would be nice to imagine what the additional 8 bits would have brought us, but alas.

As I said however, the Lime2 PCB brings out all 8 bits and if we ever get a pin-compatible A40, there is a chance it will have 8 bit emmc. The Lime2 does not have 1.8 3.3 switcher on the vqmmc lines however, but I am not sure if we need this at all for higher speeds.

If 8 bit would give us double the bandwith, it could be we'd get 80 MB/s/40 MB/s in theory, but I think that's already beyond the current chip anyway.

Comparing it to the current NAND chips, which top ou at 4MB/s read if memory serves me, eMMC makes the boards quite capable :)

olliver

Best regards
Chris

[Olliver Schinagl]

There are 3 kinds of OLinuXino Lime2 boards.
One without any on board storage, one with NAND storage and one with
eMMC storage. This patch adds the eMMC variant of boards.

eMMC storage is different from a regular SD card in that it is soldered
on the board and cannot be changed. Additionally, it shares pins with
the NAND module and with the second SPI port.

Changeslog:

v4:
Add board compatibles

v3:
Add pwr-seq-emmc with the reset gpio

v2:
Remove unsupported no-1.8-v property, add vqmmc property

v1:
Initial bare bone version

Signed-off-by: Olliver Schinagl <oli...@schinagl.nl>
---

.../boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts | 82 ++++++++++++++++++++++
1 file changed, 82 insertions(+)

create mode 100644 arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts

diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
new file mode 100644

index 0000000..5ea4915
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
@@ -0,0 +1,82 @@

+ compatible = "olimex,a20-olinuxino-lime2-emmc", "allwinner,sun7i-a20";

+
+ mmc2_pwrseq: pwrseq {
+ pinctrl-0 = <&mmc2_pins_nrst>;

+ pinctrl-names = "default";

+ compatible = "mmc-pwrseq-emmc";
+ reset-gpios = <&pio 2 16 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&pio {
+ mmc2_pins_nrst: mmc2@0 {
+ allwinner,pins = "PC16";
+ allwinner,function = "gpio_out";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+};
+

+&mmc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc2_pins_a>;
+ vmmc-supply = <&reg_vcc3v3>;

+ vqmmc-supply = <&reg_vcc3v3>;
+ bus-width = <4>;
+ non-removable;
+ mmc-pwrseq = <&mmc2_pwrseq>;

+ status = "okay";
+

[Maxime Ripard]

On Thu, May 05, 2016 at 11:08:52AM +0200, Olliver Schinagl wrote:
> There are 3 kinds of OLinuXino Lime2 boards.
> One without any on board storage, one with NAND storage and one with
> eMMC storage. This patch adds the eMMC variant of boards.
>
> eMMC storage is different from a regular SD card in that it is soldered
> on the board and cannot be changed. Additionally, it shares pins with
> the NAND module and with the second SPI port.
>
> Changeslog:
>
> v4:
> Add board compatibles
>
> v3:
> Add pwr-seq-emmc with the reset gpio
>
> v2:
> Remove unsupported no-1.8-v property, add vqmmc property
>
> v1:
> Initial bare bone version

This is not something we want in the commit log. This should go below
the --- so that it's dropped when applied.

Removed and applied.

Thanks,

[Olliver Schinagl]

Hey Maxime,

On 08-05-16 20:09, Maxime Ripard wrote:
> On Thu, May 05, 2016 at 11:08:52AM +0200, Olliver Schinagl wrote:
>> There are 3 kinds of OLinuXino Lime2 boards.
>> One without any on board storage, one with NAND storage and one with
>> eMMC storage. This patch adds the eMMC variant of boards.
>>
>> eMMC storage is different from a regular SD card in that it is soldered
>> on the board and cannot be changed. Additionally, it shares pins with
>> the NAND module and with the second SPI port.
>>
>> Changeslog:
>>
>> v4:
>> Add board compatibles
>>
>> v3:
>> Add pwr-seq-emmc with the reset gpio
>>
>> v2:
>> Remove unsupported no-1.8-v property, add vqmmc property
>>
>> v1:
>> Initial bare bone version
> This is not something we want in the commit log. This should go below
> the --- so that it's dropped when applied.

Sorry about that, I didn't know the --- trick. ChenYu reminded of it
however, so that'll go into my toolblox.
>
> Removed and applied.
Thanks for fixing it, much appreciated :)
>
> Thanks,
> Maxime
>

[Christo Radev]

Hi Olliver,

Sorry for the delay but I was on a place without Internet access.

Is there something wrong with the logs?

signal voltage: 0 (3.30<span s

[Christo Radev]

Hi to All,

On Wednesday, May 4, 2016 at 10:40:37 PM UTC+3, Christo Radev wrote:

Hi Oliver,

I start performance tests for eMMC, SD/MMC, USB, SATA SSD devices and will post the result when ready.

Some results from the performance tests done by me can be found on the following  post:
http://forum.armbian.com/index.php/topic/853-armbian-customization/page-4#entry8846

Best regards
Chris

[Christo Radev]

Hi Olliver,

I try to build Armbian with kernel 4.5.0-rc6 by adding the patch as discussed here.
In addition I have to add following as well:

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 95c1923..9d6cfa8 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -695,6 +696,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
     sun7i-a20-olimex-som-evb.dtb \
     sun7i-a20-olinuxino-lime.dtb \
     sun7i-a20-olinuxino-lime2.dtb \
+    sun7i-a20-olinuxino-lime2-emmc.dtb \
     sun7i-a20-olinuxino-micro.dtb \
     sun7i-a20-orangepi.dtb \
     sun7i-a20-orangepi-mini.dtb \

to be able to compile the new sun7i-a20-olinuxino-lime2-emmc.dts file.

After booting I have renamed it to sun7i-a20-olinuxino-lime2.dts and reboot lime-eMMC board.

Unfortunately, I get some error messages:

root@lime2:~# dmesg | grep mmc
[    0.000000] Kernel command line: console=tty1 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 cgroup_enable=memory swapaccount=1 sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=16 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 panic=10 consoleblank=0 enforcing=0 loglevel=1
[    3.721024] sunxi-mmc 1c0f000.mmc: Got CD GPIO
[    3.758926] sunxi-mmc 1c0f000.mmc: base:0xf08dc000 irq:26
[    3.759832] sunxi-mmc 1c11000.mmc: allocated mmc-pwrseq
[    4.528643] sunxi-mmc 1c11000.mmc: fatal err update clk timeout
[    4.535700] mmc0: host does not support reading read-only switch, assuming write-enable
[    4.538253] mmc0: new high speed SDHC card at address 0002
[    4.539066] mmcblk0: mmc0:0002 00000 3.70 GiB
[    4.540959]  mmcblk0: p1
[    4.548773] sunxi-mmc 1c11000.mmc: base:0xf08f2000 irq:27
[    6.418686] sunxi-mmc 1c11000.mmc: fatal err update clk timeout
[    6.600359] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data mode. Opts: (null)
[    7.168650] sunxi-mmc 1c11000.mmc: fatal err update clk timeout
[    7.918646] sunxi-mmc 1c11000.mmc: fatal err update clk timeout
[    9.875182] EXT4-fs (mmcblk0p1): re-mounted. Opts: commit=600,errors=remount-ro

Where could be the problem?

Best regards
Chris

[Olliver Schinagl]

Hey Christo,

On 10-05-16 19:25, Christo Radev wrote:

Hi Olliver,

I try to build Armbian with kernel 4.5.0-rc6 by adding the patch as discussed here.
In addition I have to add following as well:

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 95c1923..9d6cfa8 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -695,6 +696,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
     sun7i-a20-olimex-som-evb.dtb \
     sun7i-a20-olinuxino-lime.dtb \
     sun7i-a20-olinuxino-lime2.dtb \
+    sun7i-a20-olinuxino-lime2-emmc.dtb \
     sun7i-a20-olinuxino-micro.dtb \
     sun7i-a20-orangepi.dtb \
     sun7i-a20-orangepi-mini.dtb \

to be able to compile the new sun7i-a20-olinuxino-lime2-emmc.dts file.

Good point, I actually forgot that bit in my own Makefile.

After booting I have renamed it to sun7i-a20-olinuxino-lime2.dts and reboot lime-eMMC board.

why rename it to dts? i'm sure you mean dtb, and I'm guessing because armbian loads that per default.

Unfortunately, I get some error messages:

root@lime2:~# dmesg | grep mmc
[    0.000000] Kernel command line: console=tty1 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 cgroup_enable=memory swapaccount=1 sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=16 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 panic=10 consoleblank=0 enforcing=0 loglevel=1
[    3.721024] sunxi-mmc 1c0f000.mmc: Got CD GPIO
[    3.758926] sunxi-mmc 1c0f000.mmc: base:0xf08dc000 irq:26
[    3.759832] sunxi-mmc 1c11000.mmc: allocated mmc-pwrseq
[    4.528643] sunxi-mmc 1c11000.mmc: fatal err update clk timeout
[    4.535700] mmc0: host does not support reading read-only switch, assuming write-enable
[    4.538253] mmc0: new high speed SDHC card at address 0002
[    4.539066] mmcblk0: mmc0:0002 00000 3.70 GiB
[    4.540959]  mmcblk0: p1
[    4.548773] sunxi-mmc 1c11000.mmc: base:0xf08f2000 irq:27
[    6.418686] sunxi-mmc 1c11000.mmc: fatal err update clk timeout
[    6.600359] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data mode. Opts: (null)
[    7.168650] sunxi-mmc 1c11000.mmc: fatal err update clk timeout
[    7.918646] sunxi-mmc 1c11000.mmc: fatal err update clk timeout
[    9.875182] EXT4-fs (mmcblk0p1): re-mounted. Opts: commit=600,errors=remount-ro

Where could be the problem?

Not exactly sure, are you using the correct lime ;)

It does look like the correct dtb was used, since the second mmc controller is available. Maybe the bootloader prepares/inits something that is missing? sounds unlikly but possible. Maybe armbian does more changes?

Best regards
Chris

[Christo Radev]

Hi Olliver,

On Tuesday, May 10, 2016 at 9:46:45 PM UTC+3, Olliver Schinagl wrote:

Hey Christo,

On 10-05-16 19:25, Christo Radev wrote:

Hi Olliver,

I try to build Armbian with kernel 4.5.0-rc6 by adding the patch as discussed here.
In addition I have to add following as well:

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 95c1923..9d6cfa8 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -695,6 +696,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
     sun7i-a20-olimex-som-evb.dtb \
     sun7i-a20-olinuxino-lime.dtb \
     sun7i-a20-olinuxino-lime2.dtb \
+    sun7i-a20-olinuxino-lime2-emmc.dtb \
     sun7i-a20-olinuxino-micro.dtb \
     sun7i-a20-orangepi.dtb \
     sun7i-a20-orangepi-mini.dtb \

to be able to compile the new sun7i-a20-olinuxino-lime2-emmc.dts file.

Good point, I actually forgot that bit in my own Makefile.

After booting I have renamed it to sun7i-a20-olinuxino-lime2.dts and reboot lime-eMMC board.

why rename it to dts? i'm sure you mean dtb, and I'm guessing because armbian loads that per default.

Yes, currently I use LIME2 configuration and this way is faster. Later on I will make new configuration set for Lime2-eMMC.

Unfortunately, I get some error messages:

root@lime2:~# dmesg | grep mmc
[    0.000000] Kernel command line: console=tty1 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 cgroup_enable=memory swapaccount=1 sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=16 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 panic=10 consoleblank=0 enforcing=0 loglevel=1
[    3.721024] sunxi-mmc 1c0f000.mmc: Got CD GPIO
[    3.758926] sunxi-mmc 1c0f000.mmc: base:0xf08dc000 irq:26
[    3.759832] sunxi-mmc 1c11000.mmc: allocated mmc-pwrseq
[    4.528643] sunxi-mmc 1c11000.mmc: fatal err update clk timeout
[    4.535700] mmc0: host does not support reading read-only switch, assuming write-enable
[    4.538253] mmc0: new high speed SDHC card at address 0002
[    4.539066] mmcblk0: mmc0:0002 00000 3.70 GiB
[    4.540959]  mmcblk0: p1
[    4.548773] sunxi-mmc 1c11000.mmc: base:0xf08f2000 irq:27
[    6.418686] sunxi-mmc 1c11000.mmc: fatal err update clk timeout
[    6.600359] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data mode. Opts: (null)
[    7.168650] sunxi-mmc 1c11000.mmc: fatal err update clk timeout
[    7.918646] sunxi-mmc 1c11000.mmc: fatal err update clk timeout
[    9.875182] EXT4-fs (mmcblk0p1): re-mounted. Opts: commit=600,errors=remount-ro

Where could be the problem?

Not exactly sure, are you using the correct lime ;)

Of course,  I use A20-Olinuxino-Lome2-eMMC boards for testing.

It does look like the correct dtb was used, since the second mmc controller is available. Maybe the bootloader prepares/inits something that is missing? sounds unlikly but possible. Maybe armbian does more changes?

For sure in the beginning I have patched and enabled eMMC in the kernel only (without any changes in u-boot). And it has worked fine. Later on I have patched u-boot to recognize eMMC as second MMC device.

Meanwhile, I have build Armbian dev image with u-boot v2016.05-rc3 and kernel 4.6-rc7 using may patch for eMMC:

diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
index d5c796c..1f5339d 100644

--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
@@ -188,6 +188,15 @@
     status = "okay";
 };
 

+&mmc2 {
+    pinctrl-names = "default";
+    pinctrl-0 = <&mmc2_pins_a>;
+    vmmc-supply = <&reg_vcc3v3>;

+    bus-width = <8>;
+    non-removable;

+    status = "okay";
+};
+

     SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 12),
           SUNXI_FUNCTION(0x0, "gpio_in"),
           SUNXI_FUNCTION(0x1, "gpio_out"),
-          SUNXI_FUNCTION(0x2, "nand0")),    /* NDQ4 */
+          SUNXI_FUNCTION(0x2, "nand0"),        /* NDQ4 */
+          SUNXI_FUNCTION(0x3, "mmc2")),         /* D4 */
     SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 13),
           SUNXI_FUNCTION(0x0, "gpio_in"),
           SUNXI_FUNCTION(0x1, "gpio_out"),
-          SUNXI_FUNCTION(0x2, "nand0")),    /* NDQ5 */
+          SUNXI_FUNCTION(0x2, "nand0"),    /* NDQ5 */
+          SUNXI_FUNCTION(0x3, "mmc2")),         /* D5 */
     SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 14),
           SUNXI_FUNCTION(0x0, "gpio_in"),
           SUNXI_FUNCTION(0x1, "gpio_out"),
-          SUNXI_FUNCTION(0x2, "nand0")),    /* NDQ6 */
+          SUNXI_FUNCTION(0x2, "nand0"),    /* NDQ6 */
+          SUNXI_FUNCTION(0x3, "mmc2")),         /* D6 */
     SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 15),
           SUNXI_FUNCTION(0x0, "gpio_in"),
           SUNXI_FUNCTION(0x1, "gpio_out"),
-          SUNXI_FUNCTION(0x2, "nand0")),    /* NDQ7 */
+          SUNXI_FUNCTION(0x2, "nand0"),    /* NDQ7 */
+          SUNXI_FUNCTION(0x3, "mmc2")),         /* D7 */

     SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 16),

           SUNXI_FUNCTION(0x0, "gpio_in"),
           SUNXI_FUNCTION(0x1, "gpio_out"),

and it recognizes eMMC without problems.

Using dd for performance measure it gives:

root@egpr:/mnt# dd if=/dev/zero of=1GBfile bs=1M count=1K
1024+0 records in
1024+0 records out

1073741824 bytes (1.1 GB) copied, 78.7895 s, 13.6 MB/s
root@egpr:/mnt# dd of=/dev/null if=1GBfile

2097152+0 records in
2097152+0 records out

1073741824 bytes (1.1 GB) copied, 28.6025 s, 37.5 MB/s

Compared to my last results write is the same (13.6 vs. 13.5 MB/s) as speed but the read is 80% faster (37.5 vs. 20.8 MB/s).

Best regards
Chris

[Olliver Schinagl]

Hey Christo,

you should remove this ...

         /* check whether the eMMC card supports HPI */
         if (!broken_hpi && (ext_csd[EXT_CSD_HPI_FEATURES] & 0x1)) {
             card->ext_csd.hpi = 1;
@@ -519,7 +519,7 @@ static int mmc_decode_ext_csd(struct mmc_card *card, u8 *ext_csd)
             card->ext_csd.out_of_int_time =
                 ext_csd[EXT_CSD_OUT_OF_INTERRUPT_TIME] * 10;
         }
-
+#endif

and this from your own patch-set.

Instead, the broken-hpi flag should be set in the mcc section, from my patch:


    emmc: emmc@0 {
        reg = <0>;
        compatible = "mmc-card";
        broken-hpi;
    };



you really don't need these, they dont' work anyway, especially without modifying the mmc2_pins_a set.

Using dd for performance measure it gives:

root@egpr:/mnt# dd if=/dev/zero of=1GBfile bs=1M count=1K
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 78.7895 s, 13.6 MB/s
root@egpr:/mnt# dd of=/dev/null if=1GBfile
2097152+0 records in
2097152+0 records out
1073741824 bytes (1.1 GB) copied, 28.6025 s, 37.5 MB/s

Compared to my last results write is the same (13.6 vs. 13.5 MB/s) as speed but the read is 80% faster (37.5 vs. 20.8 MB/s).

Yeah i got 40 mb/s but i used a blocksize of 16M. So slightly better, as for writes, i got 17mb/s also slightly better.

As for why it worked now and not before, seems like something went wrong with the patching of things?

Best regards
Chris

[Christo Radev]

Hi Olliver,

Unfortunately, I have a problem to see and use quoted text so I delete it.

I saw broken-hpi option but currently I use mainly kernel 4.5.3 so not sure if it is available there.
About 8-bit staff in my patch it is there by error. I really use 4-bit bus without additional pins definitions.

About better results measured by you it is definitely because of larger buffers.
If you want to get a real figures you have to measure performance for a set of buffer sizes like I do with iozone tool:

root@egpr:~# uname -a
Linux egpr 4.6.0-sunxi #1 SMP Tue May 10 20:50:21 EEST 2016 armv7l GNU/Linux

root@egpr:/mnt# iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
        Iozone: Performance Test of File I/O
                Version $Revision: 3.429 $
                Compiled for 32 bit mode.
                Build: linux

        Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                     Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                     Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                     Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                     Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                     Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                     Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
                     Vangel Bojaxhi, Ben England, Vikentsi Lapa.

        Run began: Tue May 10 23:28:08 2016

        Include fsync in write timing
        O_DIRECT feature enabled
        Auto Mode
        File size set to 102400 kB
        Record Size 4 kB
        Record Size 16 kB
        Record Size 512 kB
        Record Size 1024 kB
        Record Size 16384 kB
        Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
        Output is in kBytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 kBytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     3653     4003    12637    12521     9501     3997
          102400      16     7277     7531    16300    16413    14910     7392
          102400     512    11733    11739    39496    39444    39254    11718
          102400    1024    11793    11843    40015    40086    39951    11887
          102400   16384    11977    11895    40680    40781    40656    11952

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     3768     4008    12458    12432     9565     3895
          102400      16     7231     7526    16488    16634    15085     7432
          102400     512    11608    11700    38424    38358    38172    11655
          102400    1024    11841    11853    39543    39736    39573    10977
          102400   16384    11923    11950    40756    40823    40824    11994

iozone test complete.

It is strange that read speed of ~40 MB/s is reached at 512+ kB buffers but write speed of 17MB/s (as you mention) is never reached at my tests.

For reference iozone test gives eMMC speeds at kernel 4.5.3:

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     3444     3677     9663     9626     7801     3577
          102400      16     6290     6514    13084    12740    11873     6409
          102400     512    11623    11653    21592    21567    21485    10617
          102400    1024    11787    11859    21862    21907    21811    11805
          102400   16384    11944    11914    22131    22125    22147    11947

4GB SD card class 10 speeds at kernel 4.6.0 are:

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4      630      736     5242     5149     4683      171
          102400      16     1140     1507    11630    11651    11517      331
          102400     512     6247     6465    21572    20748    21567      945
          102400    1024     6297     6521    20707    21943    21901     1945
          102400   16384     6363     6416    22209    21001    22208     6459

4GB SD card class 10 speeds at kernel 4.5.3 are:

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4      222      227     5790     5821     4180      203
          102400      16     5681     6149     9470     9661     8340       62
          102400     512    12033    11656    21194    21194    20982     2199
          102400    1024    12548    11792    21606    21616    20760     4737
          102400   16384    12755    11831    21929    21964    21214    10531

Strange is that SD card write speed is better at kernel 4.5.3 than at kernel 4.6.0 while read speed is almost the same.

About using your patch in kernel 4.6 at Armbian build I did not see any errors at patching phase.
Maybe I have to try patched with my patches u-boot and kernel 4.6 patched with your patch.
But I am not sure that u-boot has to do something for kernel to work with eMMC.

I am ready to test if you have some ideas because your patch is probably better than one used by me at the moment.

Best regards
Chris

[Christo Radev]

Hi to All,

I have extend performance tests with measurement of eMMC, SD/MMC and SATA SSD R/W speed with kernel 4.6-rc7.

The results and comments are posted on: http://forum.armbian.com/index.php/topic/853-armbian-customization/page-4#entry8908

Best regards
Chris

[Olliver Schinagl]

Christo,

nice results! Remember though, i just ran 2 dd tests and was happy to see the results. Your testing is far more extensive then mine :)

Good job!

Olliver

Best regards
Chris

[stefan.m...@gmail.com]

Hi Olliver,

Why are you using nRST signal?
What I mean is this pin is inactive on this eMMC chip. To use the signal
byte 162 of ECSD registers should be written.

On my board, this "reset" signal causes eMMC not to work.

Best regards,
Stefan Mavrodiev

[Olliver Schinagl]

On 15-07-16 10:39, stefan.m...@gmail.com wrote:
> Hi Olliver,
>
> Why are you using nRST signal?
> What I mean is this pin is inactive on this eMMC chip. To use the signal
> byte 162 of ECSD registers should be written.

Then that sounds like a bug in the mmc layer I would say (or a missing
attribute in the dts), we have a nRST signal it is wired, if the chip
ignores it, then nothing lost, if the chip needs to be initialized with
byte 162 of the ECSD register to make the nRST work, then that it sounds
like it should be fixed there?

By ommitting the nRST signal just because the chip isn't properly
initialized sounds more like a work-around to me, but I could be wrong
and see things wrong.

What do the mmc guys, who have far more experience here, say?

>
> On my board, this "reset" signal causes eMMC not to work.

That supprises me, as afaik I was using it just fine...

Olliver
>
> Best regards,
> Stefan Mavrodiev

[Olliver Schinagl]

Stefan,

On 15-07-16 10:57, Olliver Schinagl wrote:

On 15-07-16 10:39, stefan.m...@gmail.com wrote:

Hi Olliver,

Why are you using nRST signal?
What I mean is this pin is inactive on this eMMC chip. To use the signal
byte 162 of ECSD registers should be written.

Then that sounds like a bug in the mmc layer I would say (or a missing attribute in the dts), we have a nRST signal it is wired, if the chip ignores it, then nothing lost, if the chip needs to be initialized with byte 162 of the ECSD register to make the nRST work, then that it sounds like it should be fixed there?

By ommitting the nRST signal just because the chip isn't properly initialized sounds more like a work-around to me, but I could be wrong and see things wrong.

I just did a quick google query, and found the following post [0]. And it appears it's a fuse in the eMMC chip to enable/disable this functionality. I guess, but not sure, that our mmc driver in u-boot/kernel does not use the reset flag properly (always high) if that fuse has been enabled. I can imagine when using older u-boots this flag isn't enabled, the fuse is not triggered yet and the pin is thus ignored?

What do the mmc guys, who have far more experience here, say?

On my board, this "reset" signal causes eMMC not to work.

That supprises me, as afaik I was using it just fine...

Olliver

Best regards,
Stefan Mavrodiev

[0] https://groups.google.com/forum/#!category-topic/beagleboard/u-boot/1XwSNdZii1Y

-- 
Met vriendelijke groeten, Kind regards, 与亲切的问候

Olliver Schinagl
Software Engineer
Research & Development
Ultimaker B.V.