linux-kernel - Re: [PATCH 3/3] arm64: dts: rockchip: fix RockPro64 sdmmc settings【请注意，邮件由linux-rockchip-bounces+shawn.lin=rock-chips.com@...ts.infradead.org代发】

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a5b7caab-ffde-30e0-88bc-53a53748701a@web.de>
Date:   Fri, 4 Oct 2019 18:39:09 +0200
From:   Soeren Moch <smoch@....de>
To:     Robin Murphy <robin.murphy@....com>,
        Shawn Lin <shawn.lin@...k-chips.com>,
        Heiko Stuebner <heiko@...ech.de>
Cc:     linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 3/3] arm64: dts: rockchip: fix RockPro64 sdmmc settings【请注意，邮件由linux-rockchip-bounces+shawn.lin=rock-chips.com@...ts.infradead.org代发】



On 04.10.19 16:20, Robin Murphy wrote:
> On 04/10/2019 04:39, Soeren Moch wrote:
>>
>>
>> On 04.10.19 04:13, Shawn Lin wrote:
>>> On 2019/10/4 8:53, Soeren Moch wrote:
>>>>
>>>>
>>>> On 04.10.19 02:01, Robin Murphy wrote:
>>>>> On 2019-10-03 10:50 pm, Soeren Moch wrote:
>>>>>> According to the RockPro64 schematic [1] the rk3399 sdmmc
>>>>>> controller is
>>>>>> connected to a microSD (TF card) slot, which cannot be switched to
>>>>>> 1.8V.
>>>>>
>>>>> Really? AFAICS the SDMMC0 wiring looks pretty much identical to the
>>>>> NanoPC-T4 schematic (it's the same reference design, after all),
>>>>> and I
>>>>> know that board can happily drive a UHS-I microSD card with 1.8v
>>>>> I/Os,
>>>>> because mine's doing so right now.
>>>>>
>>>>> Robin.
>>>> OK, the RockPro64 does not allow a card reset (power cycle) since
>>>> VCC3V0_SD is directly connected to VCC3V3_SYS (via R89555), the
>>>> SDMMC0_PWH_H signal is not connected. So the card fails to identify
>>>> itself after suspend or reboot when switched to 1.8V operation.
>
> Ah, thanks for clarifying - I did overlook the subtlety that U12 and
> friends have "NC" as alternative part numbers, even though they aren't
> actually marked as DNP. So it's still not so much "cannot be switched"
> as "switching can lead to other problems".
Agreed. I should have been more precise about this in the commit message.

Soeren
>
>>>
>>> I believe we addressed this issue long time ago, please check:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6a11fc47f175c8d87018e89cb58e2d36c66534cb
>>>
>>>
>> Thanks for the pointer.
>> In this case I guess I should use following patch instead:
>>
>> --- rk3399-rockpro64.dts.bak    2019-10-03 22:14:00.067745799 +0200
>> +++ rk3399-rockpro64.dts    2019-10-04 00:02:50.047892366 +0200
>> @@ -619,6 +619,8 @@
>>       max-frequency = <150000000>;
>>       pinctrl-names = "default";
>>       pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_bus4>;
>> +    sd-uhs-sdr104;
>> +    vqmmc-supply = <&vcc_sdio>;
>>       status = "okay";
>>   };
>>   When I do so, the sd card is detected as SDR104, but a reboot hangs:
>>
>> Boot1: 2018-06-26, version: 1.14
>> CPUId = 0x0
>> ChipType = 0x10, 286
>> Spi_ChipId = c84018
>> no find rkpartition
>> SpiBootInit:ffffffff
>> mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
>> mmc: ERROR: Card did not respond to voltage select!
>> emmc reinit
>> mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
>> mmc: ERROR: Card did not respond to voltage select!
>> emmc reinit
>> mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
>> mmc: ERROR: Card did not respond to voltage select!
>> SdmmcInit=2 1
>> mmc0:cmd5,32
>> mmc0:cmd7,32
>> mmc0:cmd5,32
>> mmc0:cmd7,32
>> mmc0:cmd5,32
>> mmc0:cmd7,32
>> SdmmcInit=0 1
>>
>> So I guess I should use a different miniloader for this reboot to work!?
>> Or what else could be wrong here?
>
> Hmm, I guess this is "the Tinkerboard problem" again - the patch above
> would be OK if we could get as far as the kernel, but can't help if
> the offending card is itself the boot medium. There was a proposal here:
>
> https://patchwork.kernel.org/patch/10817217/
>
> although I'm not sure what if any progress has been made since then.
>
> Robin.