<MoeIcenowy>
oops they give me the feel of just c-c c-v'ing the IP core doc to here
JohnDoe_71Rus has joined #linux-sunxi
chewitt has joined #linux-sunxi
<paulk>
finding the uMCTL2 docs is pretty straightforward, but finding the PHY that matches is more difficult
<paulk>
(or probably more uPCTL2 for Allwinner)
<hlauer>
I'm back with the banana m2u v1.1: the emmc chip on the board is a KLM8G1GETF-B041. a confidentional marked specsheet found somewhere from samsung tells it's capable of mmc 5.1
<apritzel>
hlauer: and what are you hoping for now? blazing fast transfer speeds? :-)
<apritzel>
in my experience the eMMCs used on Allwinner boards, especially the smaller ones (8GB), are severely limited by their flash storage performance, so interface speed is mostly irrelevant
<apritzel>
(and just ignoring that on all SoCs so far there is a 150MHz MMC bus clock limit, and we don't implement HS400 in mainline)
<apritzel>
... and this is all irrelevant, since the M2U seems to use 3.3V on the I/O lines, which means it's DDR50 at most
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<hlauer>
no, of course not ;-)
<hlauer>
and also I saw the remark about HS400 not supported in the driver
<apritzel>
so you can expect about 80 MB/s read speed. (Sustained) writes are typically much slower
<apritzel>
The datasheet says 50MB/s, but I have a hard time to believe that, often it's in the ballpark of 10 MB/s, especially with 8GB chips
<hlauer>
OTOH I saw the SMHC in the A40i with one of the ports beeing capable of dealing with the DS signal
<hlauer>
so I wonder if they may have changed ports between v1.0 and v1.1?
<hlauer>
and the main problem is the instability of the complete mmc system, even with the emmc disabled
<apritzel>
the IP supports HS400, you have the DS pin, and the BSP seems to use it for HS400. But you would still need 1.8V on the I/O lines for anything beyond DDR50
wingrime-ww has joined #linux-sunxi
<hlauer>
instable means the mmc driver goes dead, without being able to reset the hardware and after a while you get oopses
<apritzel>
what speed mode does it use? We have often seen that the boards cannot cope with higher speed modes, and you get weird errors. Limiting the speed modes often fixes the stability issues
<hlauer>
mmc0: new high speed SDXC card - does this tell the speed mode?
<apritzel>
well, that's the SD card, and "high speed" is the (basic) speed mode here: it means 50MHz, so at 4 bits that's 25MB/s max
<apritzel>
the controller could do more, but again you would need 1.8V on the I/O lines, which is only supported with H616 and later - supported by the h/w, but not implemented in mainline (yet)
<hlauer>
thanks for explaining! And with emmc at 8 bit it would be 50MB/s, which is the maximum of the emmc chip anyway?
<apritzel>
yes, but eMMC is slightly different: "High Speed SDR" means 52MHz@8 bits there, so max 52MB/s, but there is also "High Speed DDR", which also works at 3.3V, and that gives you 104MB/s max
ftg has joined #linux-sunxi
<hlauer>
thanks again. So no reason for changing anything at the layout on v1.1 because the newer emmc chip
<apritzel>
well, it would have been clever to connect VCC_PC to an 1.8V PMIC rail, so that you can use higher speed modes. Most newer boards do this, and you get up to 150MB/s out of this
<apritzel>
this might actually be change, but it's hard to say, really
<apritzel>
hlauer: you could actually try this: hack the DT to add a 1.8V fixed regulator, and then let mmc2's vqmmc-supply point to that
<apritzel>
or use ®_dldo1, which is already at 1.8V
<apritzel>
this would not change anything on the hardware side, but the MMC subsystem would then see that it's 1.8V, and would try to negotiate higher speed modes
<apritzel>
maybe that works more stable then?
<hlauer>
hmm - ATM my aim is first to get mmc0 (the SD card) stable while keeping emmc off - could this be influenced by what you propose?