On 2020-02-01 5:51 a.m., Robin Murphy wrote:
> Hi Adam,
>
> On 2020-01-31 11:38 pm, Adam Van Ymeren wrote:
>> With this change the kernel successfully finds the SD Card and can load
>> a rootfs from it. Tested on hardware.
>>
>> Signed-off-by: Adam Van Ymeren <adam@xxxxxxx>
>>
>> diff -uprN -X linux-5.5/Documentation/dontdiff
>> linux-5.5-orig/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
>> linux-5.5/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
>> --- linux-5.5-orig/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
>> 2020-01-26 19:23:03.000000000 -0500
>> +++ linux-5.5/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
>> 2020-01-31 16:26:35.377075419 -0500
>> @@ -44,7 +44,7 @@
>> vcc_sdio: sdmmcio-regulator {
>> compatible = "regulator-gpio";
>> - gpios = <&grf_gpio 0 GPIO_ACTIVE_HIGH>;
>> + gpios = <&gpio0 RK_PD1 GPIO_ACTIVE_HIGH>;
>
> Given that the RK3328 datasheet has no mention of GPIO0_D1 existing at
> all, how sure are you that this is correct - have you tested cards in
> both 3.3V and 1.8V (UHS-1) signalling modes?
>
> The ROC-RK3328-CC schematics show GPIO_MUTE being used to bias the
> feedback pin of an adjustable regulator supplying the SDMMC0 I/O
> domain, so it seems more likely that the pin is correct but the states
> (or the polarity) are backwards.
Hmm yeah after reading the schematics this doesn't make sense. I took
it from the vendors source tree[1], and it definitely allowed my system
to boot when it wouldn't before, but I only tried a 3.3V card. I'll try
just changing the polarity. I'll also find a UHS-1 card and test that,
any advice on how to verify that it's running in the 1.8V mode?
[1]
https://github.com/FireflyTeam/kernel/blob/rk3328/firefly/arch/arm64/boot/dts/rockchip/rk3328-firefly-core.dtsi#L89
Thanks for the review!
-Adam
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-rockchip
