On Tue, Sep 20, 2016 at 11:50 AM, Andre Przywara <andre.przyw...@arm.com> wrote:
> Hi,
>
> On 20/09/16 15:49, jonsm...@gmail.com wrote:
>> On Tue, Sep 20, 2016 at 10:45 AM, jonsm...@gmail.com <jonsm...@gmail.com> 
>> wrote:
>>> On Tue, Sep 20, 2016 at 10:10 AM, TsvetanUsunov <tsvetanusu...@gmail.com> 
>>> wrote:
>>>>
>>>>
>>>> понеделник, 19 септември 2016 г., 20:06:13 UTC+3, Hans de Goede написа:
>>>>>
>>>>> Hi,
>>>>>
>>>>> On 19-09-16 18:07, TsvetanUsunov wrote:
>>>>>> Hi,
>>>>>>
>>>>>> We make our final touch of A64-OLinuXino PCB and there we add option
>>>>>> eMMC Flash to work on dual voltages 1.8V and 3.3V.
>>>>>> The eMMC is connected to AXP803 pin.34 GPIO1/LDO. The problem is that
>>>>>> when A64 boots and AXP803 is not initialized it outputs default 0.8V then
>>>>>> after initialization driver takes care to drive it  1.8V or 3.3V.
>>>>>> This makes impossible to boot from eMMC which is not good. We now think
>>>>>> for solution which to drive eMMC at 3.3V initially when AXP803 output is
>>>>>> below 1.8V but this adds unnecessary hardware complexity.
>>>>>> For hardware point of view it will be much more simplier if dedigated
>>>>>> A64 GPIO is used and initially is pulled down and after AXP803 is
>>>>>> initialized is pulled up.
>>>>>
>>>>> Ok, so what your suggesting is:
>>>>>
>>>>> axp803-ldo-io1  -\
>>>>>                    [mux]---> mmc-supply
>>>>> Fixed-3.3v ------/  |
>>>>>                      |
>>>>>                      |mux-control
>>>>> A64 gpio out--------/
>>>>>
>>>>> Note the above ascii-art requires a fixed-width font.
>>>>>
>>>>> With a pull-down (or pull-up) to fix the mux in a certain position when
>>>>> the gpio is in tri-state ?
>>>>>
>>>>> As long as we pin the axp803-ldo-io1 at 1.8v then the Linux regulator
>>>>> framework should be able to deal with, and in u-boot we can just
>>>>> keep things at 3.3v.
>>>>>
>>>>>> How would you suggest us to implement it? Will this additional GPIO
>>>>>> create troubles in eMMC driver philosophy?
>>>>>
>>>>> For the Linux mmc driver the mmc-supply is abstracted as a regulator,
>>>>> and the regulator framework should be able to deal with any setup
>>>>> you can come up with.
>>>>>
>>>>>> For the SDMMC we are still hesitating what to do as we don't know if the
>>>>>> card which will be inserted will support low voltage and higher speeds at
>>>>>> all.
>>>>>
>>>>> As long as you default to 3.3v then the kernel's sd subsystem can
>>>>> dynamically switch voltage (through e.g. the gpio) if the card
>>>>> advertises it supports low voltage. Note that you're planning
>>>>> the first board to implement this that I know off, so the sunxi-mmc
>>>>> kernel driver will need some work to support voltage switching,
>>>>> but in the mean time things should work fine at 3.3v.
>>>>>
>>>>>> Also eMMC Flash and SDMMC card should be driven by separate voltages, as
>>>>>> they may work in any combinations.
>>>>>
>>>>> Ack, right, as said both cards should come up with 3.3v and then
>>>>> a new voltage will be negotiated before switching, so this definitely
>>>>> needs to be per card.
>>>>>
>>>>>> This means we need another AXP803 LDO and another GPIO for the SDMMC
>>>>>> card.
>>>>>
>>>>> Right
>>>>
>>>>
>>>> Micron eMMC chips we use do not support higher clock at lower voltage, so
>>>> the way we wired the schematic right now makes no much sense.
>>>> I check for other vendors but also can't find such eMMC chip, if someone
>>>> knows please let us know to investigate more?
>>>>
>>>> So in this case makes sense to move the dual voltage supply to the SD-MMC
>>>> card only but this rise some more issues :)
>>>>
>>>> The card is currently wired to port F which Vcc is internally connected
>>>> together with port B and H where is WiFi SIDO , I2C UARTs etc which will be
>>>> lost if we power with 1.8V, so no go.
>>>>
>>>> We can swap the SD-MMC and eMMC ports, port F and port C, but in this case
>>>> we will lose the NAND Flash option i.e. the possibility to run Android.
>>>>
>>>> I still can't find SD-MMC card which to work on 1.8 and 3.3V can you point
>>>> me to some model so we perform test and see if this is really good to have
>>>> feature, or we will cut this and wire 3.3V permanently :)
>>>
>>> I have not tried low voltage SD Cards but...
>>>
>>> Here is a chart of the UHS modes
>>> http://panasonic.net/avc/sdcard/industrial_sd/performance.html
>>>
>>> Here are UHS SD Cards for sale:
>>> http://www.lexar.com/products.html
>>>
>>> I was unaware of 0.4V UHS-II, but Lexar is selling UHS-II cards. Don't
>>> know what supply voltage they need.
>>>
>>> -------------------------------------------------------
>>>
>>> For eMMC I believe you are looking for:
>>> eMMC 4.5 HS200
>>> eMMC 5.0 HS400
>>
>> A64 only has a eMMC 4.5 controller so forget about HS400.
>
> But both the manual and the data sheet mention eMMC 5.0 and HS400
> explicitly several times.
> So do you have knowledge beyond that?

Searching in the manual for HS400 was a better idea, I tried to search
for eMMC 5.0.

I just checked the Allwinner source code, there are references to HS400 in it.
https://gitlab.com/pine64-android/linux-3.10/blob/master/drivers/mmc/host/sunxi-mmc-sun50iw1p1-2.c

[SM4_HS400] = { .spm  = SM4_HS400, .mod_str =  "HS400",
.raw_tm_sm_str[0] = "sdc_tm4_sm4_freq0", .raw_tm_sm_str[1] =
"sdc_tm4_sm4_freq1", .raw_tm_sm [0] = 0, .raw_tm_sm [1] = 0x00000608,
.raw_tm_sm_def [0] = 0, .raw_tm_sm_def [1] = 0x00000408, },};

So now all we need is for someone to make a board with an eMMC 5.0 chip on it.


>
> Cheers,
> Andre.
>
>>>
>>> Kingston sells these, I think Samsung does too.
>>> http://www.kingston.com/us/embedded/emmc
>>>
>>> They come in wide temp
>>> https://media.kingston.com/pdfs/emmc/i_temp_eMMC_Product_Flyer.pdf
>>>
>>> About $5 for 4GB from US distributors, so probably $3 from Chinese one.
>>> Random check of similar Kingston part from Chinese supplier - $3.38
>>>
>>> Support for HS200/HS400 is already in kernel so someone is using it.
>>>
>>>>
>>>> Tsvetan
>>>>
>>>> --
>>>> 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+unsubscr...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>
>>> --
>>> Jon Smirl
>>> jonsm...@gmail.com
>>
>>
>>



-- 
Jon Smirl
jonsm...@gmail.com

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to