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
> <https://groups.google.com/d/msg/linux-sunxi/vSC4vx8_ok8/K0jW8bmcAQAJ>.
> 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 = <®_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 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
>
>
>
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
