From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olliver Schinagl Subject: Re: [PATCH 1/1] ARM: dts: sunxi: Add a olinuxino-lime2-emmc Date: Thu, 5 May 2016 10:43:44 +0200 Message-ID: <572B07C0.7080601@schinagl.nl> References: <1461827998-12192-1-git-send-email-oliver@schinagl.nl> <57285162.2000704@schinagl.nl> <5729F07C.3080308@schinagl.nl> <948be370-4401-43cb-862e-d4376755a75d@googlegroups.com> <5729F6D6.8030100@schinagl.nl> <4704fa35-9a2a-4e6e-8fd4-f4778405c598@googlegroups.com> <572A0052.9060202@schinagl.nl> <2e745ef7-ddc0-40fc-b867-414543690276@googlegroups.com> <572A10B3.2020803@schinagl.nl> <4375220a-f939-4ed0-a6d7-2cf887b07509@googlegroups.com> Reply-To: oliver-dxLnbx3+1qmEVqv0pETR8A@public.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------070101080301000702070106" Return-path: Sender: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org In-Reply-To: <4375220a-f939-4ed0-a6d7-2cf887b07509-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , To: Christo Radev , linux-sunxi Cc: radoslav.kolev-1W28NRE8jL9DPfheJLI6IQ@public.gmane.org, wens-jdAy2FN1RRM@public.gmane.org, maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org, tsvetan-kyXcfZUBQGPQT0dZR+AlfA@public.gmane.org, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, pawel.moll-5wv7dgnIgG8@public.gmane.org, mark.rutland-5wv7dgnIgG8@public.gmane.org, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org, galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org, hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, dev-3kdeTeqwOZ9EV1b7eY7vFQ@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: devicetree@vger.kernel.org This is a multi-part message in MIME format. --------------070101080301000702070106 Content-Type: text/plain; charset=UTF-8; format=flowed Hey Christo, On 04-05-16 21:40, Christo Radev wrote: > 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). > | > BootedfromSD card with8-bit patched kernel > root@egpr:~# dmesg | grep mmc > [3.599625]sunxi-mmc 1c0f000.mmc:GotCD GPIO > [3.631883]sunxi-mmc 1c0f000.mmc:base:0xf08da000irq:26 > [3.669058]mmc0:host does notsupport reading read-only switch,assuming > write-enable > [3.671674]sunxi-mmc 1c11000.mmc:base:0xf08de000irq:27 > [3.672064]mmc0:newhigh speed SDHC card at address 0007 > [3.673068]mmcblk0:mmc0:0007SD04G 3.71GiB > [3.674785] mmcblk0:p1 > [3.682261]sunxi-mmc 1c11000.mmc:smc 1err,cmd 8,RTO !! > [3.689280]sunxi-mmc 1c11000.mmc:smc 1err,cmd 55,RTO !! > [3.690146]sunxi-mmc 1c11000.mmc:smc 1err,cmd 55,RTO !! > [3.690977]sunxi-mmc 1c11000.mmc:smc 1err,cmd 55,RTO !! > [3.691808]sunxi-mmc 1c11000.mmc:smc 1err,cmd 55,RTO !! > [3.745505]mmc1:MAN_BKOPS_EN bit isnotset > [3.749187]sunxi-mmc 1c11000.mmc:smc 1err,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:switchto bus width 2failed > [3.753586]mmc1:newhigh speed MMC card at address 0001 > [3.754479]mmcblk1:mmc1:0001P1XXXX 3.60GiB > [3.754961]mmcblk1boot0:mmc1:0001P1XXXX partition 116.0MiB > [3.755604]mmcblk1boot1:mmc1:0001P1XXXX partition 216.0MiB > [3.757045] mmcblk1:p1 > [4.216879]EXT4-fs (mmcblk0p1):mounted filesystem withwriteback 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:50000000Hz > vdd:21(3.3~3.4V) > 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(4bits) > timing spec:1(mmc high-speed) > signal voltage:0(3.30V) > driver type:0(driver type B) > > BootedfromSATA SSD with4-bit patched kernel > [3.598868]sunxi-mmc 1c0f000.mmc:GotCD GPIO > [3.631154]sunxi-mmc 1c0f000.mmc:base:0xf08da000irq:26 > [3.668313]mmc0:host does notsupport reading read-only switch,assuming > write-enable > [3.670908]sunxi-mmc 1c11000.mmc:base:0xf08de000irq:27 > [3.671324]mmc0:newhigh speed SDHC card at address 0007 > [3.672302]mmcblk0:mmc0:0007SD04G 3.71GiB > [3.674067] mmcblk0:p1 > [3.681882]sunxi-mmc 1c11000.mmc:smc 1err,cmd 8,RTO !! > [3.686129]sunxi-mmc 1c11000.mmc:smc 1err,cmd 55,RTO !! > [3.686996]sunxi-mmc 1c11000.mmc:smc 1err,cmd 55,RTO !! > [3.687843]sunxi-mmc 1c11000.mmc:smc 1err,cmd 55,RTO !! > [3.688672]sunxi-mmc 1c11000.mmc:smc 1err,cmd 55,RTO !! > [3.724762]mmc1:MAN_BKOPS_EN bit isnotset > [3.731196]mmc1:newhigh speed MMC card at address 0001 > [3.732141]mmcblk1:mmc1:0001P1XXXX 3.60GiB > [3.732553]mmcblk1boot0:mmc1:0001P1XXXX partition 116.0MiB > [3.732960]mmcblk1boot1:mmc1:0001P1XXXX partition 216.0MiB > [3.734186] mmcblk1:p1 > > root@egpr:~# cat /sys/kernel/debug/mmc0/ios > clock:50000000Hz > vdd:21(3.3~3.4V) > 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(4bits) > timing spec:1(mmc high-speed) > signal voltage:0(3.30V) > 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 withdd > root@egpr:/mnt# dd if=/dev/zero of=1GBfilebs=1Mcount=1K > 1024+0records in > 1024+0records out > 1073741824bytes (1.1GB)copied,79.9305s,13.4MB/s > root@egpr:/mnt# dd of=/dev/nullif=1GBfile > 2097152+0records in > 2097152+0records out > 1073741824bytes (1.1GB)copied,49.5899s,21.7MB/s > > eMMC 4-bit patch R/W test withdd > root@egpr:/mnt# dd if=/dev/zero of=1GBfilebs=1Mcount=1K > 1024+0records in > 1024+0records out > 1073741824bytes (1.1GB)copied,78.7925s,13.6MB/s > root@egpr:/mnt# dd of=/dev/nullif=1GBfile > 2097152+0records in > 2097152+0records out > 1073741824bytes (1.1GB)copied,53.8002s,20.0MB/s > | > > In my opinion 8-bit access to eMMC is broken in Allwinned A20 or in > the mmc driver. 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 > -- 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 linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit https://groups.google.com/d/optout. --------------070101080301000702070106 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hey Christo,

On 04-05-16 21:40, Christo Radev wrote:<= br>
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 car= d with 8-bit patched kernel
root@egpr
:~# dmesg | grep mmc
[ =C2=A0 =C2=A03.59962= 5
] sunxi<= /span>-mmc 1c0f000= .mmc: Got CD GPI= O
[ =C2=A0 =C2=A03.63188= 3
] sunxi<= /span>-mmc 1c0f000= .mmc: base:0xf08da= 000 irq:26
[ =C2=A0 =C2=A03.66905= 8
] mmc0: host does not support reading read-only switch<= /span>, assuming write-enable
[ =C2=A0 =C2=A03.67167= 4
] sunxi<= /span>-mmc 1c11000= .mmc: base:0xf08de= 000 irq:27
[ =C2=A0 =C2=A03.67206= 4
] mmc0: new high speed SDHC card at address 0007
[ =C2=A0 =C2=A03.67306= 8
] mmcblk= 0: mmc0:0007 SD04G = 3.71 GiB
[ =C2=A0 =C2=A03.67478= 5
] =C2=A0mmcblk0: p1
[ =C2=A0 =C2=A03.68226= 1
] sunxi<= /span>-mmc 1c11000= .mmc: smc 1 err, cmd 8, RTO !!
[ =C2=A0 =C2=A03.68928= 0
] sunxi<= /span>-mmc 1c11000= .mmc: smc 1 err, cmd 55, RTO !!
[ =C2=A0 =C2=A03.69014= 6
] sunxi<= /span>-mmc 1c11000= .mmc: smc 1 err, cmd 55, RTO !!
[ =C2=A0 =C2=A03.69097= 7
] sunxi<= /span>-mmc 1c11000= .mmc: smc 1 err, cmd 55, RTO !!
[ =C2=A0 =C2=A03.69180= 8
] sunxi<= /span>-mmc 1c11000= .mmc: smc 1 err, cmd 55, RTO !!
[ =C2=A0 =C2=A03.74550= 5
] mmc1: MAN_BKOPS_EN bit is not set
[ =C2=A0 =C2=A03.74918= 7
] sunxi<= /span>-mmc 1c11000= .mmc: smc 1 err, cmd 8, RD EBE !!
[ =C2=A0 =C2=A03.74922= 9
] sunxi<= /span>-mmc 1c11000= .mmc: data error, sending stop command [ =C2=A0 =C2=A03.74924= 7] sunxi<= /span>-mmc 1c11000= .mmc: send stop command failed
[ =C2=A0 =C2=A03.74926= 8
] mmc1: switch<= /span> to bus width 2 failed
[ =C2=A0 =C2=A03.75358= 6
] mmc1: new high speed MMC card at address 0001
[ =C2=A0 =C2=A03.75447= 9
] mmcblk= 1: mmc1:0001 P1XXXX 3.60 GiB
[ =C2=A0 =C2=A03.75496= 1
] mmcblk1boot0: mmc1:0001 P1XXXX partition 1 16.0 MiB
[ =C2=A0 =C2=A03.75560= 4
] mmcblk1boot1: mmc1:0001 P1XXXX partition 2 16.0 MiB
[ =C2=A0 =C2=A03.75704= 5
] =C2=A0mmcblk1: p1
[ =C2=A0 =C2=A04.21687= 9
] EXT4-fs (mmcblk0= p1): mounte= d filesystem with writeback data mode. Opts: (null)
[ =C2=A0 =C2=A07.90700= 2
] EXT4-fs (mmcblk0= p1): re-mounted= . Opts: commit= =3D600,errors<= /span>=3Dremount= -ro

root@egpr
:~# cat /sys/kernel/debug/mmc0/ios
clock
: =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A05000000= 0 Hz
vdd
: =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A021 (3.3 ~ 3.4 V)
bus mode
: =C2=A0 =C2=A0 =C2=A0 <= /span>2 (push-pull)
chip
select: =C2=A0= =C2=A00 (don't care= )
power mode: =C2=A0 =C2=A0 2 (on)
bus width: =C2=A0 =C2=A0 =C2=A02 (4 bits)
timing spec: =C2=A0 =C2=A02 (sd high-speed)
signal voltage: 0 (3.30 V)
driver type: =C2=A0 =C2=A00 (driver type B)
root@egpr:~# cat /sys/kernel/debug/mmc1/ios
clock: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A050000000 Hz
vdd: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A021 (3.3 ~ 3.4= V)
bus mode: =C2=A0 =C2=A0 =C2=A0 2 (push-pull)
chip select: =C2=A0 =C2=A00 (don'
t care)
power mode
: =C2=A0 =C2=A0 <= span style=3D"color: #066;" class=3D"styled-by-prettify">2 (on)
bus width
: =C2=A0 =C2=A0 =C2=A02 (4 bits)
timing spec
: =C2=A0 =C2=A01 (mmc hig= h-speed)
signal voltage
: 0 (3.30
V)
driver type
: =C2=A0 =C2=A00 (driver type B)

Booted from
SATA SSD with 4-bit patched kernel
[ =C2=A0 =C2=A03.59886= 8
] sunxi<= /span>-mmc 1c0f000= .mmc: Got CD GPI= O
[ =C2=A0 =C2=A03.63115= 4
] sunxi<= /span>-mmc 1c0f000= .mmc: base:0xf08da= 000 irq:26
[ =C2=A0 =C2=A03.66831= 3
] mmc0: host does not support reading read-only switch<= /span>, assuming write-enable
[ =C2=A0 =C2=A03.67090= 8
] sunxi<= /span>-mmc 1c11000= .mmc: base:0xf08de= 000 irq:27
[ =C2=A0 =C2=A03.67132= 4
] mmc0: new high speed SDHC card at address 0007
[ =C2=A0 =C2=A03.67230= 2
] mmcblk= 0: mmc0:0007 SD04G = 3.71 GiB
[ =C2=A0 =C2=A03.67406= 7
] =C2=A0mmcblk0: p1
[ =C2=A0 =C2=A03.68188= 2
] sunxi<= /span>-mmc 1c11000= .mmc: smc 1 err, cmd 8, RTO !!
[ =C2=A0 =C2=A03.68612= 9
] sunxi<= /span>-mmc 1c11000= .mmc: smc 1 err, cmd 55, RTO !!
[ =C2=A0 =C2=A03.68699= 6
] sunxi<= /span>-mmc 1c11000= .mmc: smc 1 err, cmd 55, RTO !!
[ =C2=A0 =C2=A03.68784= 3
] sunxi<= /span>-mmc 1c11000= .mmc: smc 1 err, cmd 55, RTO !!
[ =C2=A0 =C2=A03.68867= 2
] sunxi<= /span>-mmc 1c11000= .mmc: smc 1 err, cmd 55, RTO !!
[ =C2=A0 =C2=A03.72476= 2
] mmc1: MAN_BKOPS_EN bit is not set
[ =C2=A0 =C2=A03.73119= 6
] mmc1: new high speed MMC card at address 0001
[ =C2=A0 =C2=A03.73214= 1
] mmcblk= 1: mmc1:0001 P1XXXX 3.60 GiB
[ =C2=A0 =C2=A03.73255= 3
] mmcblk1boot0: mmc1:0001 P1XXXX partition 1 16.0 MiB
[ =C2=A0 =C2=A03.73296= 0
] mmcblk1boot1: mmc1:0001 P1XXXX partition 2 16.0 MiB
[ =C2=A0 =C2=A03.73418= 6
] =C2=A0mmcblk1: p1

root@egpr
:~# cat /sys/kernel/debug/mmc0/ios
clock
: =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A05000000= 0 Hz
vdd
: =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A021 (3.3 ~ 3.4 V)
bus mode
: =C2=A0 =C2=A0 =C2=A0 <= /span>2 (push-pull)
chip
select: =C2=A0= =C2=A00 (don't care= )
power mode: =C2=A0 =C2=A0 2 (on)
bus width: =C2=A0 =C2=A0 =C2=A02 (4 bits)
timing spec: =C2=A0 =C2=A02 (sd high-speed)
signal voltage: 0 (3.30 V)
driver type: =C2=A0 =C2=A00 (driver type B)
root@egpr:~# cat /sys/kernel/debug/mmc1/ios
clock: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A050000000 Hz
vdd: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A021 (3.3 ~ 3.4= V)
bus mode: =C2=A0 =C2=A0 =C2=A0 2 (push-pull)
chip select: =C2=A0 =C2=A00 (don'
t care)
power mode
: =C2=A0 =C2=A0 <= span style=3D"color: #066;" class=3D"styled-by-prettify">2 (on)
bus width
: =C2=A0 =C2=A0 =C2=A02 (4 bits)
timing spec
: =C2=A0 =C2=A01 (mmc hig= h-speed)
signal voltage
: 0 (3.30
V)
driver type
: =C2=A0 =C2=A00 (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=3D/<= span style=3D"color: #000;" class=3D"styled-by-prettify">dev/zero of= =3D1GBfile= bs=3D1M count<= /span>=3D1K
1024+0 record= s in
1024+0 record= s out
1073741824 bytes = (1.1 GB) copied= , 79.9305= s, 13.4 MB/s
root@egpr
:/mnt# dd of=3D/<= span style=3D"color: #000;" class=3D"styled-by-prettify">dev/null if=3D1GBfile=
2097152+0 record= s in
2097152+0 record= s 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=3D/<= span style=3D"color: #000;" class=3D"styled-by-prettify">dev/zero of= =3D1GBfile= bs=3D1M count<= /span>=3D1K
1024+0 record= s in
1024+0 record= s out
1073741824 bytes = (1.1 GB) copied= , 78.7925= s, 13.6 MB/s
root@egpr
:/mnt# dd of=3D/<= span style=3D"color: #000;" class=3D"styled-by-prettify">dev/null if=3D1GBfile=
2097152+0 record= s in
2097152+0 record= s 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.
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


--
You received this message because you are subscribed to the Google Groups &= quot;linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to linux-s= unxi+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit http= s://groups.google.com/d/optout.
--------------070101080301000702070106--