From: Jonas Karlman <jonas@kwiboo.se> To: Robin Murphy <robin.murphy@arm.com>, Soeren Moch <smoch@web.de>, Shawn Lin <shawn.lin@rock-chips.com>, Heiko Stuebner <heiko@sntech.de> Cc: "linux-rockchip@lists.infradead.org" <linux-rockchip@lists.infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH 3/3] arm64: dts: rockchip: fix RockPro64 sdmmc settings【请注意,邮件由linux-rockchip-bounces+shawn.lin=rock-chips.com@lists.infradead.org代发】 Date: Fri, 4 Oct 2019 14:42:42 +0000 [thread overview] Message-ID: <HE1PR06MB4011FC12B5F4D3C455DEF738AC9E0@HE1PR06MB4011.eurprd06.prod.outlook.com> (raw) In-Reply-To: <fc7dce53-ad39-26e3-7c19-ab60ff4cc332@arm.com> On 2019-10-04 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". > >>> 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. Correct, I never got around to complete testing on other devices. Maybe someone more familiar with mmc subsystem can pick that up if it now turns out other devices show the same/similar issue? fwiw the "mmc: core: set initial signal voltage on power off" rfc/patch have been used in LibreELEC rockchip builds for well over a year now. Regards, Jonas > > Robin. >
WARNING: multiple messages have this Message-ID (diff)
From: Jonas Karlman <jonas@kwiboo.se> To: Robin Murphy <robin.murphy@arm.com>, Soeren Moch <smoch@web.de>, Shawn Lin <shawn.lin@rock-chips.com>, Heiko Stuebner <heiko@sntech.de> Cc: "linux-rockchip@lists.infradead.org" <linux-rockchip@lists.infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH 3/3] arm64: dts: rockchip: fix RockPro64 sdmmc settings【请注意,邮件由linux-rockchip-bounces+shawn.lin=rock-chips.com@lists.infradead.org代发】 Date: Fri, 4 Oct 2019 14:42:42 +0000 [thread overview] Message-ID: <HE1PR06MB4011FC12B5F4D3C455DEF738AC9E0@HE1PR06MB4011.eurprd06.prod.outlook.com> (raw) In-Reply-To: <fc7dce53-ad39-26e3-7c19-ab60ff4cc332@arm.com> On 2019-10-04 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". > >>> 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. Correct, I never got around to complete testing on other devices. Maybe someone more familiar with mmc subsystem can pick that up if it now turns out other devices show the same/similar issue? fwiw the "mmc: core: set initial signal voltage on power off" rfc/patch have been used in LibreELEC rockchip builds for well over a year now. Regards, Jonas > > Robin. > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-10-04 14:42 UTC|newest] Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-03 21:50 [PATCH 1/3] arm64: dts: rockchip: fix RockPro64 vdd-log regulator settings Soeren Moch 2019-10-03 21:50 ` Soeren Moch 2019-10-03 21:50 ` Soeren Moch 2019-10-03 21:50 ` [PATCH 2/3] arm64: dts: rockchip: fix RockPro64 sdhci settings Soeren Moch 2019-10-03 21:50 ` Soeren Moch 2019-10-04 20:05 ` Heiko Stuebner 2019-10-04 20:05 ` Heiko Stuebner 2019-10-03 21:50 ` [PATCH 3/3] arm64: dts: rockchip: fix RockPro64 sdmmc settings Soeren Moch 2019-10-03 21:50 ` Soeren Moch 2019-10-04 0:01 ` Robin Murphy 2019-10-04 0:01 ` Robin Murphy 2019-10-04 0:53 ` Soeren Moch 2019-10-04 0:53 ` Soeren Moch 2019-10-04 2:13 ` [PATCH 3/3] arm64: dts: rockchip: fix RockPro64 sdmmc settings【请注意,邮件由linux-rockchip-bounces+shawn.lin=rock-chips.com@lists.infradead.org代发】 Shawn Lin 2019-10-04 2:13 ` Shawn Lin 2019-10-04 2:13 ` Shawn Lin 2019-10-04 3:39 ` Soeren Moch 2019-10-04 3:39 ` Soeren Moch 2019-10-04 14:20 ` Robin Murphy 2019-10-04 14:20 ` Robin Murphy 2019-10-04 14:42 ` Jonas Karlman [this message] 2019-10-04 14:42 ` Jonas Karlman 2019-10-04 14:42 ` Jonas Karlman 2019-10-04 15:33 ` Shawn Lin 2019-10-04 15:33 ` Shawn Lin 2019-10-04 15:33 ` Shawn Lin 2019-10-04 17:24 ` Sören Moch 2019-10-04 17:24 ` Sören Moch 2019-10-04 20:15 ` Soeren Moch 2019-10-04 20:15 ` Soeren Moch 2019-10-04 20:18 ` Heiko Stuebner 2019-10-04 20:18 ` Heiko Stuebner 2019-10-04 20:39 ` Sören Moch 2019-10-04 20:39 ` Sören Moch 2019-10-04 20:39 ` Sören Moch 2019-10-11 8:22 ` Jonas Karlman 2019-10-11 8:22 ` Jonas Karlman 2019-10-11 8:22 ` Jonas Karlman 2019-10-11 11:40 ` [PATCH 3/3] arm64: dts: rockchip: fix RockPro64 sdmmc settings Soeren Moch 2019-10-11 11:40 ` Soeren Moch 2019-10-11 13:00 ` Robin Murphy 2019-10-11 13:00 ` Robin Murphy 2019-10-11 13:00 ` Robin Murphy 2019-10-11 14:16 ` Soeren Moch 2019-10-11 14:16 ` Soeren Moch 2019-10-11 14:16 ` Soeren Moch 2019-10-12 4:09 ` Shawn Lin 2019-10-12 4:09 ` Shawn Lin 2019-10-12 12:45 ` Soeren Moch 2019-10-12 12:45 ` Soeren Moch 2019-10-12 12:45 ` Soeren Moch 2019-10-04 16:39 ` [PATCH 3/3] arm64: dts: rockchip: fix RockPro64 sdmmc settings【请注意,邮件由linux-rockchip-bounces+shawn.lin=rock-chips.com@lists.infradead.org代发】 Soeren Moch 2019-10-04 16:39 ` Soeren Moch 2019-10-04 20:04 ` [PATCH 1/3] arm64: dts: rockchip: fix RockPro64 vdd-log regulator settings Heiko Stuebner 2019-10-04 20:04 ` Heiko Stuebner
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=HE1PR06MB4011FC12B5F4D3C455DEF738AC9E0@HE1PR06MB4011.eurprd06.prod.outlook.com \ --to=jonas@kwiboo.se \ --cc=heiko@sntech.de \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-rockchip@lists.infradead.org \ --cc=robin.murphy@arm.com \ --cc=shawn.lin@rock-chips.com \ --cc=smoch@web.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.