| Message ID | 87imkryz5t.fsf@vany.ca (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | arm64: dts: rockchip: Fix rk3328-roc-cc sdmmcio-regulator | expand |
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@vany.ca> > > 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. Robin. > states = <1800000 0x1 > 3300000 0x0>; > regulator-name = "vcc_sdio"; > > _______________________________________________ > Linux-rockchip mailing list > Linux-rockchip@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip >
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@vany.ca> >> >> 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
On 2020-02-01 3:41 pm, Adam Van Ymeren wrote: > > 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@vany.ca> >>> >>> 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? My preferred method is to stick a meter on either the uSD socket pins or the regulator itself and wiggle the GPIO from userspace, but preferably only if the board can run without a card inserted. That said, I just suddenly remembered about regulator GPIOs being quirky for legacy ABI reasons - I'm now 99% sure that you should simply need to add the "enable-active-high" property to make it actually work as expected. Robin. > > [1] > https://github.com/FireflyTeam/kernel/blob/rk3328/firefly/arch/arm64/boot/dts/rockchip/rk3328-firefly-core.dtsi#L89 > > > Thanks for the review! > > -Adam >
On 2020-02-01 12:46 p.m., Robin Murphy wrote: > On 2020-02-01 3:41 pm, Adam Van Ymeren wrote: >> >> 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@vany.ca> >>>> >>>> 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? > > My preferred method is to stick a meter on either the uSD socket pins > or the regulator itself and wiggle the GPIO from userspace, but > preferably only if the board can run without a card inserted. > > That said, I just suddenly remembered about regulator GPIOs being > quirky for legacy ABI reasons - I'm now 99% sure that you should > simply need to add the "enable-active-high" property to make it > actually work as expected. > Whelp I did a whole bunch of tracing and debugging only to realize that I didn't have CONFIG_GPIO_SYSCON enabled, so big suprise the gpio-syscon driver needed for grf-gpio never came online. After turning that on I get [ 1.277115] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0) in my dmesg, which is more than I used to get. However it fails to detect the SDCard. I tried with and without enable-active-high; on the sdmmcio-regulator entry, neither seemed to make a difference. I'll do some more debugging in a bit, its always possible I did something stupid like use the wrong .dtb file (or build without CONFIG_GPIO_SYSCON). Thanks again! -Adam | | || | | | |||
On Sat, Feb 1, 2020 at 5:10 PM Adam Van Ymeren <adam@vany.ca> wrote: > > > On 2020-02-01 12:46 p.m., Robin Murphy wrote: > > On 2020-02-01 3:41 pm, Adam Van Ymeren wrote: > >> > >> 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@vany.ca> > >>>> > >>>> 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? > > > > My preferred method is to stick a meter on either the uSD socket pins > > or the regulator itself and wiggle the GPIO from userspace, but > > preferably only if the board can run without a card inserted. > > > > That said, I just suddenly remembered about regulator GPIOs being > > quirky for legacy ABI reasons - I'm now 99% sure that you should > > simply need to add the "enable-active-high" property to make it > > actually work as expected. > > > > Whelp I did a whole bunch of tracing and debugging only to realize that > I didn't have CONFIG_GPIO_SYSCON enabled, so big suprise the gpio-syscon > driver needed for grf-gpio never came online. After turning that on I get > > [ 1.277115] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req > 400000Hz, actual 400000HZ div = 0) > > in my dmesg, which is more than I used to get. However it fails to > detect the SDCard. I tried with and without enable-active-high; on the > sdmmcio-regulator entry, neither seemed to make a difference. I'll do > some more debugging in a bit, its always possible I did something stupid > like use the wrong .dtb file (or build without CONFIG_GPIO_SYSCON). I'm interested in this, since I've encountered some oddities with the sdcard on this board. With the recent addition of support for ddr4 tpl init in u-boot I started playing with it again. I couldn't get the sdcard to detect leaving tpl into spl, causing a boot failure. The exact same image works when flashed to the emmc though. Once we are in the kernel the sdcard detects fine. I noticed u-boot doesn't have a grf-gpio driver, so the 3.3v/1.8v regulator is unavailable. root@firefly:/sys/kernel/debug/mmc1# cat ios clock: 150000000 Hz actual clock: 150000000 Hz vdd: 21 (3.3 ~ 3.4 V) bus mode: 2 (push-pull) chip select: 0 (don't care) power mode: 2 (on) bus width: 2 (4 bits) timing spec: 6 (sd uhs SDR104) signal voltage: 1 (1.80 V) driver type: 0 (driver type B) root@firefly:/sys/kernel/debug# cat gpio gpiochip0: GPIOs 0-31, parent: platform/pinctrl, gpio0: gpio-0 ( |vcc-host-5v-regulato) out hi gpio-30 ( |sdmmc-regulator ) out lo ACTIVE LOW gpiochip1: GPIOs 32-63, parent: platform/pinctrl, gpio1: gpio-50 ( |snps,reset ) out hi ACTIVE LOW gpio-58 ( |vcc-host1-5v-regulat) out hi gpiochip2: GPIOs 64-95, parent: platform/pinctrl, gpio2: gpiochip3: GPIOs 96-127, parent: platform/pinctrl, gpio3: gpiochip5: GPIOs 509-510, parent: platform/rk805-pinctrl, rk805-gpio, can sleep: gpio-509 ( |? ) out hi ACTIVE LOW gpio-510 ( |? ) out hi ACTIVE LOW gpiochip4: GPIOs 511-511, parent: platform/ff100000.syscon:grf-gpio, ff100000.syscon:grf-gpio: gpio-511 ( |vcc_sdio ) out hi > > > Thanks again! > > -Adam > > | > > | > > || > > | > > | > > | > > ||| > > > _______________________________________________ > Linux-rockchip mailing list > Linux-rockchip@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip
On 2020-02-04 10:15 a.m., Peter Geis wrote: > I'm interested in this, since I've encountered some oddities with the > sdcard on this board. > With the recent addition of support for ddr4 tpl init in u-boot I > started playing with it again. > I couldn't get the sdcard to detect leaving tpl into spl, causing a > boot failure. > The exact same image works when flashed to the emmc though. Awesome I was hoping to get mainline u-boot loading this board as well. However I don't know how to setup the sdram-params for the dd4 on this board. Do you have the appropriate config? Would be great not to require the vendor's blob for booting. > > Once we are in the kernel the sdcard detects fine. > > I noticed u-boot doesn't have a grf-gpio driver, so the 3.3v/1.8v > regulator is unavailable. > > root@firefly:/sys/kernel/debug/mmc1# cat ios > clock: 150000000 Hz > actual clock: 150000000 Hz > vdd: 21 (3.3 ~ 3.4 V) > bus mode: 2 (push-pull) > chip select: 0 (don't care) > power mode: 2 (on) > bus width: 2 (4 bits) > timing spec: 6 (sd uhs SDR104) > signal voltage: 1 (1.80 V) > driver type: 0 (driver type B) > > root@firefly:/sys/kernel/debug# cat gpio > gpiochip0: GPIOs 0-31, parent: platform/pinctrl, gpio0: > gpio-0 ( |vcc-host-5v-regulato) out hi > gpio-30 ( |sdmmc-regulator ) out lo ACTIVE LOW > > gpiochip1: GPIOs 32-63, parent: platform/pinctrl, gpio1: > gpio-50 ( |snps,reset ) out hi ACTIVE LOW > gpio-58 ( |vcc-host1-5v-regulat) out hi > > gpiochip2: GPIOs 64-95, parent: platform/pinctrl, gpio2: > > gpiochip3: GPIOs 96-127, parent: platform/pinctrl, gpio3: > > gpiochip5: GPIOs 509-510, parent: platform/rk805-pinctrl, rk805-gpio, can sleep: > gpio-509 ( |? ) out hi ACTIVE LOW > gpio-510 ( |? ) out hi ACTIVE LOW > > gpiochip4: GPIOs 511-511, parent: platform/ff100000.syscon:grf-gpio, > ff100000.syscon:grf-gpio: > gpio-511 ( |vcc_sdio ) out hi On my board I tried every combination of GPIO_ACTIVE_HIGH/LOW, enable-active-high or not, and state = <18... 0x1 33... 0x0> vs state = <18... 0x0 33...0x1> for the vcc_sdio regulator. None of those allowed my kernel to detect the SD Card. The only reliable method so far seem to be setting the gpio of the regulator to some non existent pin, but that clearly isn't the corrent answer. Both gpios = <&gpio0 25 GPIO_ACTIVE_HIGH> and gpios = <&gpio2 RK_PD3 GPIO_ACTIVE_HIGH> allow the board to board, both of which are non-existent pins from my reading of the datasheet. I'm beginning to suspect that it may be a bug in the gpio-syscon driver, or that the actual circuit on the board just doesn't work as the vendor intended. In my dmesg I see [ 0.406830] gpio-syscon ff100000.syscon:grf-gpio: can't read the data register offset! which is awfully suspicious. But this doesn't appear to be a fatal error for the driver, logging _regmap_write calls shows that it appears to be updating the correct register (0x428) From gpio-syscon.c:134 | static void rockchip_gpio_set(struct gpio_chip *chip, unsigned int offset, int val) { struct syscon_gpio_priv *priv = gpiochip_get_data(chip); unsigned int offs; u8 bit; u32 data; int ret; offs = priv->dreg_offset + priv->data->dat_bit_offset + offset; bit = offs % SYSCON_REG_BITS; data = (val ? BIT(bit) : 0) | BIT(bit + 16); ret = regmap_write(priv->syscon, (offs / SYSCON_REG_BITS) * SYSCON_REG_SIZE, data); if (ret < 0) dev_err(chip->parent, "gpio write failed ret(%d)\n", ret); } Calling regmap_write seems wrong, as we end up setting all bits in the register, so this should probably be regmap_update_bits. The top 16-bits are write-enable for the lower 16-bits, but I can't find documentation if it works to set both the write enable bit and the target bit at the same time. Tonight I will try splitting that into two calls to update the high bit first as well as changing to regmap_update_bits. Any other ideas welcome. Sorry if this was too verbose or too much context, I'm new to this kind of work. |
On Tue, Feb 4, 2020 at 11:14 AM Adam Van Ymeren <adam@vany.ca> wrote: > > > On 2020-02-04 10:15 a.m., Peter Geis wrote: > > I'm interested in this, since I've encountered some oddities with the > > sdcard on this board. > > With the recent addition of support for ddr4 tpl init in u-boot I > > started playing with it again. > > I couldn't get the sdcard to detect leaving tpl into spl, causing a > > boot failure. > > The exact same image works when flashed to the emmc though. > > Awesome I was hoping to get mainline u-boot loading this board as well. > However I don't know how to setup the sdram-params for the dd4 on this > board. Do you have the appropriate config? Would be great not to > require the vendor's blob for booting. > > > > > Once we are in the kernel the sdcard detects fine. > > > > I noticed u-boot doesn't have a grf-gpio driver, so the 3.3v/1.8v > > regulator is unavailable. > > > > root@firefly:/sys/kernel/debug/mmc1# cat ios > > clock: 150000000 Hz > > actual clock: 150000000 Hz > > vdd: 21 (3.3 ~ 3.4 V) > > bus mode: 2 (push-pull) > > chip select: 0 (don't care) > > power mode: 2 (on) > > bus width: 2 (4 bits) > > timing spec: 6 (sd uhs SDR104) > > signal voltage: 1 (1.80 V) > > driver type: 0 (driver type B) > > > > root@firefly:/sys/kernel/debug# cat gpio > > gpiochip0: GPIOs 0-31, parent: platform/pinctrl, gpio0: > > gpio-0 ( |vcc-host-5v-regulato) out hi > > gpio-30 ( |sdmmc-regulator ) out lo ACTIVE LOW > > > > gpiochip1: GPIOs 32-63, parent: platform/pinctrl, gpio1: > > gpio-50 ( |snps,reset ) out hi ACTIVE LOW > > gpio-58 ( |vcc-host1-5v-regulat) out hi > > > > gpiochip2: GPIOs 64-95, parent: platform/pinctrl, gpio2: > > > > gpiochip3: GPIOs 96-127, parent: platform/pinctrl, gpio3: > > > > gpiochip5: GPIOs 509-510, parent: platform/rk805-pinctrl, rk805-gpio, can sleep: > > gpio-509 ( |? ) out hi ACTIVE LOW > > gpio-510 ( |? ) out hi ACTIVE LOW > > > > gpiochip4: GPIOs 511-511, parent: platform/ff100000.syscon:grf-gpio, > > ff100000.syscon:grf-gpio: > > gpio-511 ( |vcc_sdio ) out hi > > > On my board I tried every combination of GPIO_ACTIVE_HIGH/LOW, > enable-active-high or not, and state = <18... 0x1 33... 0x0> vs state = > <18... 0x0 33...0x1> for the vcc_sdio regulator. None of those allowed > my kernel to detect the SD Card. The only reliable method so far seem > to be setting the gpio of the regulator to some non existent pin, but > that clearly isn't the corrent answer. Both gpios = <&gpio0 25 > GPIO_ACTIVE_HIGH> and gpios = <&gpio2 RK_PD3 GPIO_ACTIVE_HIGH> allow the > board to board, both of which are non-existent pins from my reading of > the datasheet. First question, which kernel are you running? Current mainline (5.4.17) works out of the box for the rk3328-roc-cc. Second question, do you have the libre board or the team firefly board? Third question, what is the current state of the grf-gpio pin? Also, what is the state of the regmap for register 428 at /sys/kernel/debug/regmap/dummy-syscon@ff100000/registers Also, it likely works because those GPIOs don't exist, as such it is leaving the grf registers as is from u-boot. > > I'm beginning to suspect that it may be a bug in the gpio-syscon driver, > or that the actual circuit on the board just doesn't work as the vendor > intended. > > In my dmesg I see > > [ 0.406830] gpio-syscon ff100000.syscon:grf-gpio: can't read the data > register offset! > > which is awfully suspicious. But this doesn't appear to be a fatal > error for the driver, logging _regmap_write calls shows that it appears > to be updating the correct register (0x428) I get the same error, it doesn't appear to affect the end behavior. > > > From gpio-syscon.c:134 > > | > > static void rockchip_gpio_set(struct gpio_chip *chip, unsigned int offset, > int val) > { > struct syscon_gpio_priv *priv = gpiochip_get_data(chip); > unsigned int offs; > u8 bit; > u32 data; > int ret; > > offs = priv->dreg_offset + priv->data->dat_bit_offset + offset; > bit = offs % SYSCON_REG_BITS; > data = (val ? BIT(bit) : 0) | BIT(bit + 16); > ret = regmap_write(priv->syscon, > (offs / SYSCON_REG_BITS) * SYSCON_REG_SIZE, > data); > if (ret < 0) > dev_err(chip->parent, "gpio write failed ret(%d)\n", ret); > } > > Calling regmap_write seems wrong, as we end up setting all bits in the register, so this should probably be regmap_update_bits. The top 16-bits are write-enable for the lower 16-bits, but I can't find documentation if it works to set both the write enable bit and the target bit at the same time. data = (val ? BIT(bit) : 0) | BIT(bit + 16); handles setting both the bit and the write bit. > > Tonight I will try splitting that into two calls to update the high bit first as well as changing to regmap_update_bits. Any other ideas welcome. > > Sorry if this was too verbose or too much context, I'm new to this kind of work. I hate to say it, but you probably have something else going on here. From my ouya porting experience, sdmmc can be very touchy in odd configurations. I would try reducing the clock rate and trying again, also you can limit the timing spec mode as well. Could you send the data from the following sources? /sys/kernel/debug/mmc1/ios /sys/kernel/debug/gpio Also, try reseating the sdcard. I submitted a patch in October which fixes the sdcard on boot. Recently gpio functionality on the rk3328 was fixed which allowed vcc_sd to shut down during boot. Reseating the card would trigger card detection, which powers the regulator back up and the card enumerates. Check that regulator-boot-on; is under the vcc_sd: sdmmc-regulator. > > | > > > _______________________________________________ > Linux-rockchip mailing list > Linux-rockchip@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip
Thanks for the ideas Peter! On 2020-02-04 12:25 p.m., Peter Geis wrote: > On Tue, Feb 4, 2020 at 11:14 AM Adam Van Ymeren <adam@vany.ca> wrote: >> >> On 2020-02-04 10:15 a.m., Peter Geis wrote: >>> I'm interested in this, since I've encountered some oddities with the >>> sdcard on this board. >>> With the recent addition of support for ddr4 tpl init in u-boot I >>> started playing with it again. >>> I couldn't get the sdcard to detect leaving tpl into spl, causing a >>> boot failure. >>> The exact same image works when flashed to the emmc though. >> Awesome I was hoping to get mainline u-boot loading this board as well. >> However I don't know how to setup the sdram-params for the dd4 on this >> board. Do you have the appropriate config? Would be great not to >> require the vendor's blob for booting. >> >>> Once we are in the kernel the sdcard detects fine. >>> >>> I noticed u-boot doesn't have a grf-gpio driver, so the 3.3v/1.8v >>> regulator is unavailable. >>> >>> root@firefly:/sys/kernel/debug/mmc1# cat ios >>> clock: 150000000 Hz >>> actual clock: 150000000 Hz >>> vdd: 21 (3.3 ~ 3.4 V) >>> bus mode: 2 (push-pull) >>> chip select: 0 (don't care) >>> power mode: 2 (on) >>> bus width: 2 (4 bits) >>> timing spec: 6 (sd uhs SDR104) >>> signal voltage: 1 (1.80 V) >>> driver type: 0 (driver type B) >>> >>> root@firefly:/sys/kernel/debug# cat gpio >>> gpiochip0: GPIOs 0-31, parent: platform/pinctrl, gpio0: >>> gpio-0 ( |vcc-host-5v-regulato) out hi >>> gpio-30 ( |sdmmc-regulator ) out lo ACTIVE LOW >>> >>> gpiochip1: GPIOs 32-63, parent: platform/pinctrl, gpio1: >>> gpio-50 ( |snps,reset ) out hi ACTIVE LOW >>> gpio-58 ( |vcc-host1-5v-regulat) out hi >>> >>> gpiochip2: GPIOs 64-95, parent: platform/pinctrl, gpio2: >>> >>> gpiochip3: GPIOs 96-127, parent: platform/pinctrl, gpio3: >>> >>> gpiochip5: GPIOs 509-510, parent: platform/rk805-pinctrl, rk805-gpio, can sleep: >>> gpio-509 ( |? ) out hi ACTIVE LOW >>> gpio-510 ( |? ) out hi ACTIVE LOW >>> >>> gpiochip4: GPIOs 511-511, parent: platform/ff100000.syscon:grf-gpio, >>> ff100000.syscon:grf-gpio: >>> gpio-511 ( |vcc_sdio ) out hi >> >> On my board I tried every combination of GPIO_ACTIVE_HIGH/LOW, >> enable-active-high or not, and state = <18... 0x1 33... 0x0> vs state = >> <18... 0x0 33...0x1> for the vcc_sdio regulator. None of those allowed >> my kernel to detect the SD Card. The only reliable method so far seem >> to be setting the gpio of the regulator to some non existent pin, but >> that clearly isn't the corrent answer. Both gpios = <&gpio0 25 >> GPIO_ACTIVE_HIGH> and gpios = <&gpio2 RK_PD3 GPIO_ACTIVE_HIGH> allow the >> board to board, both of which are non-existent pins from my reading of >> the datasheet. > First question, which kernel are you running? > Current mainline (5.4.17) works out of the box for the rk3328-roc-cc. Not from my experience. I'm trying 5.5, but I also tried a fresh build ot 5.4.17 and neither will load from the sdcard in their default configuration. If you have this working can you share your kernel config? > > Second question, do you have the libre board or the team firefly board? The libre.computer board. > > Third question, what is the current state of the grf-gpio pin? > Also, what is the state of the regmap for register 428 at > /sys/kernel/debug/regmap/dummy-syscon@ff100000/registers > > Also, it likely works because those GPIOs don't exist, as such it is > leaving the grf registers as is from u-boot. Makes sense. If I remove vcc_sdio from the device tree, and remove the vqmmc entry from the sdmmc node, then the kernel continues to boot. In that case I have # cat /sys/kernel/debug/regmap/dummy-syscon\@ff100000/registers | grep 428 428: 0000f800 # cat /sys/kernel/debug/mmc1/ios clock: 0 Hz vdd: 0 (invalid) bus mode: 2 (push-pull) chip select: 0 (don't care) power mode: 0 (off) bus width: 0 (1 bits) timing spec: 0 (legacy) signal voltage: 0 (3.30 V) driver type: 0 (driver type B) # cat /sys/kernel/debug/gpio gpiochip0: GPIOs 0-31, parent: platform/pinctrl, gpio0: gpio-30 ( |sdmmc-regulator ) out lo ACTIVE LOW gpiochip1: GPIOs 32-63, parent: platform/pinctrl, gpio1: gpio-58 ( |vcc-host1-5v-regulat) out hi gpiochip2: GPIOs 64-95, parent: platform/pinctrl, gpio2: gpiochip3: GPIOs 96-127, parent: platform/pinctrl, gpio3: gpiochip4: GPIOs 511-511, parent: platform/ff100000.syscon:grf-gpio, ff100000.syscon:grf-gpio: I notice that I don't have the entry for vcc-host-5v-regulator. In fact vcc-host-5v-regulator doesn't appear in the device tree anywhere that I can find. It only appears in the rock64 device tree. What device tree/kernel version are you using? $ grep -R vcc-host-5v-regulat linux-5.5/ linux-5.5/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts: vcc_host_5v: vcc-host-5v-regulator { $ grep -R vcc-host-5v-regulat linux-5.4.17/ linux-5.4.17/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts: vcc_host_5v: vcc-host-5v-regulator { >> >> Calling regmap_write seems wrong, as we end up setting all bits in the register, so this should probably be regmap_update_bits. The top 16-bits are write-enable for the lower 16-bits, but I can't find documentation if it works to set both the write enable bit and the target bit at the same time. > data = (val ? BIT(bit) : 0) | BIT(bit + 16); handles setting both the > bit and the write bit. Right I saw that, I was more wondering if it's legal to set both in the same operation, or if the chip requires you to set the write bit, and then the data bit in a subsequent write. >> Tonight I will try splitting that into two calls to update the high bit first as well as changing to regmap_update_bits. Any other ideas welcome. >> >> Sorry if this was too verbose or too much context, I'm new to this kind of work. > I hate to say it, but you probably have something else going on here. > From my ouya porting experience, sdmmc can be very touchy in odd configurations. > I would try reducing the clock rate and trying again, also you can > limit the timing spec mode as well. Any advice on how to reduce the clock rate/timing spec mode? I also just found a PDF showing the position of the components on the board, so I should be able to find a test point to see if the regulator is producing 1.8V vs 3.3V as its supposed to. > > Could you send the data from the following sources? > /sys/kernel/debug/mmc1/ios > /sys/kernel/debug/gpio Pasted above. > Also, try reseating the sdcard. > I submitted a patch in October which fixes the sdcard on boot. > Recently gpio functionality on the rk3328 was fixed which allowed > vcc_sd to shut down during boot. > Reseating the card would trigger card detection, which powers the > regulator back up and the card enumerates. > Check that regulator-boot-on; is under the vcc_sd: sdmmc-regulator. I've re-seated the sdcard a bunch. If I do nothing but reboot the board and toggle between the stock device tree and one with vcc_sdio/vqmmc removed I can reliably boot vs not-boot the board. regulator-boot-on is there for vcc_sd. I really appreciate the help!
On 05/02/2020 4:14 pm, Adam Van Ymeren wrote: [...] >>> Calling regmap_write seems wrong, as we end up setting all bits in the register, so this should probably be regmap_update_bits. The top 16-bits are write-enable for the lower 16-bits, but I can't find documentation if it works to set both the write enable bit and the target bit at the same time. >> data = (val ? BIT(bit) : 0) | BIT(bit + 16); handles setting both the >> bit and the write bit. > Right I saw that, I was more wondering if it's legal to set both in the > same operation, or if the chip requires you to set the write bit, and > then the data bit in a subsequent write. The point of this particular hardware idiom is that the mask indicates which data bits to update, and both mask and data are part of a single write, thus there is no need for a non-atomic read-modify-write sequence. For example: - register value is 0x00000000 - write 0xffffffff (mask all set, data all 1s) - register value is now 0x0000ffff - write 0x00090000 (mask bits 0 and 3 set, corresponding data bit values 0) - register value is now 0x0000fff6 FWIW I've confirmed on my box that there doesn't seem to be any problem with the grf-gpio driver itself - setting the value to 1 or 0 from userspace shows up as the enable pin on the audio line driver (per the RK3328 reference design) going high and low respectively. One thing I did notice, though, is that GPIO_MUTE seems to have some inherent coupling to the analog codec, as the value automatically goes high when starting to play audio, and low again when stopping (but can still be manually toggled in between). Thus unless there's some secret to disabling that behaviour then it might not be safe to enable analog audio on these ROC-CC boards for fear of messing up peoples' SD cards. Robin.
> > First question, which kernel are you running? > > Current mainline (5.4.17) works out of the box for the rk3328-roc-cc. > > Not from my experience. I'm trying 5.5, but I also tried a fresh build > ot 5.4.17 and neither will load from the sdcard in their default > configuration. If you have this working can you share your kernel config? Considering all of the components to boot off emmc (which you are clearly doing since you boot at all) are the same as the ones required for sdmmc I doubt it's a configuration issue. But to answer your question, I used the defconfig, stripped all of the non rockchip components out, and made the base drivers builtin. > > > > > Second question, do you have the libre board or the team firefly board? > > The libre.computer board. > > > > > Third question, what is the current state of the grf-gpio pin? > > Also, what is the state of the regmap for register 428 at > > /sys/kernel/debug/regmap/dummy-syscon@ff100000/registers > > > > Also, it likely works because those GPIOs don't exist, as such it is > > leaving the grf registers as is from u-boot. > > Makes sense. If I remove vcc_sdio from the device tree, and remove the > vqmmc entry from the sdmmc node, then the kernel continues to boot. In > that case I have > > # cat /sys/kernel/debug/regmap/dummy-syscon\@ff100000/registers | grep 428 > > 428: 0000f800 As it should be, this should mean your mute pin is off (default state) and the vqmmc voltage should be 3.3v. > > # cat /sys/kernel/debug/mmc1/ios > clock: 0 Hz > vdd: 0 (invalid) > bus mode: 2 (push-pull) > chip select: 0 (don't care) > power mode: 0 (off) > bus width: 0 (1 bits) > timing spec: 0 (legacy) > signal voltage: 0 (3.30 V) > driver type: 0 (driver type B) It's not detecting anything at all. You say you booted off this card? Could you run a `dmesg | grep mmc` and send all the results? > > # cat /sys/kernel/debug/gpio > gpiochip0: GPIOs 0-31, parent: platform/pinctrl, gpio0: > gpio-30 ( |sdmmc-regulator ) out lo ACTIVE LOW > > gpiochip1: GPIOs 32-63, parent: platform/pinctrl, gpio1: > gpio-58 ( |vcc-host1-5v-regulat) out hi > > gpiochip2: GPIOs 64-95, parent: platform/pinctrl, gpio2: > > gpiochip3: GPIOs 96-127, parent: platform/pinctrl, gpio3: > > gpiochip4: GPIOs 511-511, parent: platform/ff100000.syscon:grf-gpio, > ff100000.syscon:grf-gpio: > > > I notice that I don't have the entry for vcc-host-5v-regulator. In fact > vcc-host-5v-regulator doesn't appear in the device tree anywhere that I > can find. It only appears in the rock64 device tree. What device > tree/kernel version are you using? I've got usb 2 and 3 fully working, that regulator is part of the usb subsystem. > > $ grep -R vcc-host-5v-regulat linux-5.5/ > linux-5.5/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts: > vcc_host_5v: vcc-host-5v-regulator { > > $ grep -R vcc-host-5v-regulat linux-5.4.17/ > linux-5.4.17/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts: > vcc_host_5v: vcc-host-5v-regulator { > > >> > >> Calling regmap_write seems wrong, as we end up setting all bits in the register, so this should probably be regmap_update_bits. The top 16-bits are write-enable for the lower 16-bits, but I can't find documentation if it works to set both the write enable bit and the target bit at the same time. > > data = (val ? BIT(bit) : 0) | BIT(bit + 16); handles setting both the > > bit and the write bit. > Right I saw that, I was more wondering if it's legal to set both in the > same operation, or if the chip requires you to set the write bit, and > then the data bit in a subsequent write. > >> Tonight I will try splitting that into two calls to update the high bit first as well as changing to regmap_update_bits. Any other ideas welcome. > >> > >> Sorry if this was too verbose or too much context, I'm new to this kind of work. > > I hate to say it, but you probably have something else going on here. > > From my ouya porting experience, sdmmc can be very touchy in odd configurations. > > I would try reducing the clock rate and trying again, also you can > > limit the timing spec mode as well. > > Any advice on how to reduce the clock rate/timing spec mode? I also > just found a PDF showing the position of the components on the board, so > I should be able to find a test point to see if the regulator is > producing 1.8V vs 3.3V as its supposed to. Documentation/devicetree/bindings/mmc/mmc-controller.yaml max-frequency for frequency cap. sd-uhs-sdr12 through sd-uhs-ddr50 set sd card modes. You can also try bus-width = <1>; > > > > > Could you send the data from the following sources? > > /sys/kernel/debug/mmc1/ios > > /sys/kernel/debug/gpio > > > Pasted above. > > > > Also, try reseating the sdcard. > > I submitted a patch in October which fixes the sdcard on boot. > > Recently gpio functionality on the rk3328 was fixed which allowed > > vcc_sd to shut down during boot. > > Reseating the card would trigger card detection, which powers the > > regulator back up and the card enumerates. > > Check that regulator-boot-on; is under the vcc_sd: sdmmc-regulator. > > I've re-seated the sdcard a bunch. If I do nothing but reboot the board > and toggle between the stock device tree and one with vcc_sdio/vqmmc > removed I can reliably boot vs not-boot the board. regulator-boot-on is > there for vcc_sd. > > > I really appreciate the help! > I hate to ask the dumb questions, but I have a few just for clarity. With no emmc attached, does your board boot off the sdcard? Are you sure the sdcard is good? > One thing I did notice, though, is that GPIO_MUTE seems to have some > inherent coupling to the analog codec, as the value automatically goes > high when starting to play audio, and low again when stopping (but can > still be manually toggled in between). Thus unless there's some secret > to disabling that behaviour then it might not be safe to enable analog > audio on these ROC-CC boards for fear of messing up peoples' SD cards. Robin, Do you know if that is the SOC doing that or the drivers?
On 05/02/2020 6:43 pm, Peter Geis wrote: [...] >> One thing I did notice, though, is that GPIO_MUTE seems to have some >> inherent coupling to the analog codec, as the value automatically goes >> high when starting to play audio, and low again when stopping (but can >> still be manually toggled in between). Thus unless there's some secret >> to disabling that behaviour then it might not be safe to enable analog >> audio on these ROC-CC boards for fear of messing up peoples' SD cards. > > Robin, > Do you know if that is the SOC doing that or the drivers? Ha, once again I hastily jump to a conclusion without fully investigating... I'm really not doing too well in this thread :) You're absolutely right; on closer inspection rk3328_analog_output() in the codec driver is poking GRF_SOC_CON10 directly. That should be straightforward enough to sort out, phew! Cheers, Robin.
On 2/5/2020 2:02 PM, Robin Murphy wrote: > On 05/02/2020 6:43 pm, Peter Geis wrote: > [...] >>> One thing I did notice, though, is that GPIO_MUTE seems to have some >>> inherent coupling to the analog codec, as the value automatically goes >>> high when starting to play audio, and low again when stopping (but can >>> still be manually toggled in between). Thus unless there's some secret >>> to disabling that behaviour then it might not be safe to enable analog >>> audio on these ROC-CC boards for fear of messing up peoples' SD cards. >> >> Robin, >> Do you know if that is the SOC doing that or the drivers? > > Ha, once again I hastily jump to a conclusion without fully > investigating... I'm really not doing too well in this thread :) > > You're absolutely right; on closer inspection rk3328_analog_output() > in the codec driver is poking GRF_SOC_CON10 directly. That should be > straightforward enough to sort out, phew! > > Cheers, > Robin. > I've had random reports of SD problems from people using our mainline images with Armbian on RK3328, I recently enabled the audio codec since it looked like all the pieces were in place. I'll take a look at the GPIO_MUTE patchset I saw just landed. -Tony > _______________________________________________ > Linux-rockchip mailing list > Linux-rockchip@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip
Got it working. Robin you were right, it just needed enable-active-high; added to the regulator, updated patch at the end of this message. I went back over my config with a fine tooth comb and found a few rockchip drivers I was missing including PINCTRL_RK805 which seems related but I honestly can't figure out how. I will try to narrow down which specific driver was missing. It was odd because it would find the mmc host but just fail notice that a card was present. It seemed to set the register correctly and identify the mmc host, but failed to notice any card present. I haven't yet tested this with a high speed card yet to verify 1.8v signaling works but I'll find one and give it a shot. Thanks a ton to both of your for the help On 2020-02-05 1:43 p.m., Peter Geis wrote: >>> First question, which kernel are you running? >>> Current mainline (5.4.17) works out of the box for the rk3328-roc-cc. >> Not from my experience. I'm trying 5.5, but I also tried a fresh build >> ot 5.4.17 and neither will load from the sdcard in their default >> configuration. If you have this working can you share your kernel config? > Considering all of the components to boot off emmc (which you are > clearly doing since you boot at all) are the same as the ones required > for sdmmc I doubt it's a configuration issue. > But to answer your question, I used the defconfig, stripped all of the > non rockchip components out, and made the base drivers builtin. So I wasn't booting off of emmc. I was booting from the sdcard, it would work so long as I prevented the kernel from trying to initialize the vcc_sdio regulator (by removing it or changing the gpio pin), presumably as u-boot left it in a reasonable state. > Makes sense. If I remove vcc_sdio from the device tree, and remove the >> vqmmc entry from the sdmmc node, then the kernel continues to boot. In >> that case I have >> >> # cat /sys/kernel/debug/regmap/dummy-syscon\@ff100000/registers | grep 428 >> >> 428: 0000f800 > As it should be, this should mean your mute pin is off (default state) > and the vqmmc voltage should be 3.3v. Gotcha. I also managed to verify this works as expected on my board with a multimeter and toggling the register from the u-boot shell. > >> # cat /sys/kernel/debug/mmc1/ios >> clock: 0 Hz >> vdd: 0 (invalid) >> bus mode: 2 (push-pull) >> chip select: 0 (don't care) >> power mode: 0 (off) >> bus width: 0 (1 bits) >> timing spec: 0 (legacy) >> signal voltage: 0 (3.30 V) >> driver type: 0 (driver type B) > It's not detecting anything at all. > You say you booted off this card? So this is booting when I disabled vcc_sdio and just left it in the state that u-boot left it in, which is probably where the nonsensical output comes from. > > Could you run a `dmesg | grep mmc` and send all the results? Here's a slightly scrubbed log of one of my failed boots. I left in my traces of register writes to 428 and gpio-regulator state changes. [ 0.000000] Kernel command line: earlycon=uart8250,mmio32,0xff130000 console=ttyS2,1500000 rw root=/dev/mmcblk0p5 init=/sbin/init kgdboc=ttyS2,1500000 dynamic_debug.verbose=1 loglevel=7 dyndbg="module dw_mmc +p ; module dw_mmc_rockchip +p ; module mmc_core +p" <snip> [ 0.793750] dwmmc_rockchip ff500000.dwmmc: IDMAC supports 32-bit address mode. [ 0.794402] dwmmc_rockchip ff500000.dwmmc: Using internal DMA controller. [ 0.798582] dwmmc_rockchip ff500000.dwmmc: Version ID is 270a [ 0.801194] dwmmc_rockchip ff500000.dwmmc: DW MMC controller at irq 29,32 bit host data width,256 deep fifo [ 0.815437] dwmmc_rockchip ff520000.dwmmc: IDMAC supports 32-bit address mode. [ 0.820273] dwmmc_rockchip ff520000.dwmmc: Version ID is 270a [ 0.822904] dwmmc_rockchip ff520000.dwmmc: DW MMC controller at irq 30,32 bit host data width,256 deep fifo [ 0.825527] mmc_host mmc0: card is non-removable. [ 0.838770] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0) [ 0.888886] ADAMVY Regmap write 428 <= 2f802 [ 0.904218] dwmmc_rockchip ff500000.dwmmc: IDMAC supports 32-bit address mode. [ 0.904870] dwmmc_rockchip ff500000.dwmmc: Using internal DMA controller. [ 0.909055] dwmmc_rockchip ff500000.dwmmc: Version ID is 270a [ 0.911637] dwmmc_rockchip ff500000.dwmmc: DW MMC controller at irq 29,32 bit host data width,256 deep fifo [ 0.913954] ADAMVY Setting gpio regulator to value 3300000 state 0 [ 0.914503] ADAMVY Regmap write 428 <= 2f800 [ 0.927612] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0) [ 0.950160] VFS: Cannot open root device "mmcblk0p5" or unknown-block(0,0): error -6 Finally here's an updated patch for the device tree with Robin's original suggestion. Index: 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 +++ linux-5.5/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts @@ -45,6 +45,7 @@ vcc_sdio: sdmmcio-regulator { compatible = "regulator-gpio"; gpios = <&grf_gpio 0 GPIO_ACTIVE_HIGH>; + enable-active-high; states = <1800000 0x1 3300000 0x0>; regulator-name = "vcc_sdio";
On 09/02/2020 1:07 am, Adam Van Ymeren wrote: > Got it working. Robin you were right, it just needed enable-active-high; > added to the regulator, updated patch at the end of this message. Weird... after my initial excitement I went back and looked more closely at the binding and gpiolib-of code, only to realise that that property is only supposed to apply to specific 'enable' GPIOs (of which there are none here since it's always-on), and that the 'state' GPIOs were a separate thing and I'd jumped to the wrong conclusion. So now I'm doubly surprised that it actually makes a difference :/ > I went back over my config with a fine tooth comb and found a few > rockchip drivers I was missing including PINCTRL_RK805 which seems > related but I honestly can't figure out how. I will try to narrow down > which specific driver was missing. It was odd because it would find the > mmc host but just fail notice that a card was present. It seemed to set > the register correctly and identify the mmc host, but failed to notice > any card present. PINCTRL_RK805 should only be for the couple of GPIO pins on the PMIC itself which IIRC the reference design uses for the ethernet LEDs, so I wouldn't expect it to be relevant. Those symptoms make sense for the voltages being backwards (or just stuck at 1.8V) though - when the I/O domain is configured to expect 3.3V, 1.8V is too low to register as a logic high, so Linux will always think that something is inserted in the slot, but not talking back. Robin. > I haven't yet tested this with a high speed card yet to verify 1.8v > signaling works but I'll find one and give it a shot. > > Thanks a ton to both of your for the help > > > On 2020-02-05 1:43 p.m., Peter Geis wrote: >>>> First question, which kernel are you running? >>>> Current mainline (5.4.17) works out of the box for the rk3328-roc-cc. >>> Not from my experience. I'm trying 5.5, but I also tried a fresh build >>> ot 5.4.17 and neither will load from the sdcard in their default >>> configuration. If you have this working can you share your kernel config? >> Considering all of the components to boot off emmc (which you are >> clearly doing since you boot at all) are the same as the ones required >> for sdmmc I doubt it's a configuration issue. >> But to answer your question, I used the defconfig, stripped all of the >> non rockchip components out, and made the base drivers builtin. > > So I wasn't booting off of emmc. I was booting from the sdcard, it > would work so long as I prevented the kernel from trying to initialize > the vcc_sdio regulator (by removing it or changing the gpio pin), > presumably as u-boot left it in a reasonable state. > >> Makes sense. If I remove vcc_sdio from the device tree, and remove the >>> vqmmc entry from the sdmmc node, then the kernel continues to boot. In >>> that case I have >>> >>> # cat /sys/kernel/debug/regmap/dummy-syscon\@ff100000/registers | grep 428 >>> >>> 428: 0000f800 >> As it should be, this should mean your mute pin is off (default state) >> and the vqmmc voltage should be 3.3v. > > Gotcha. I also managed to verify this works as expected on my board > with a multimeter and toggling the register from the u-boot shell. > >> >>> # cat /sys/kernel/debug/mmc1/ios >>> clock: 0 Hz >>> vdd: 0 (invalid) >>> bus mode: 2 (push-pull) >>> chip select: 0 (don't care) >>> power mode: 0 (off) >>> bus width: 0 (1 bits) >>> timing spec: 0 (legacy) >>> signal voltage: 0 (3.30 V) >>> driver type: 0 (driver type B) >> It's not detecting anything at all. >> You say you booted off this card? > So this is booting when I disabled vcc_sdio and just left it in the > state that u-boot left it in, which is probably where the nonsensical > output comes from. >> >> Could you run a `dmesg | grep mmc` and send all the results? > > Here's a slightly scrubbed log of one of my failed boots. I left in my > traces of register writes to 428 and gpio-regulator state changes. > > [ 0.000000] Kernel command line: earlycon=uart8250,mmio32,0xff130000 > console=ttyS2,1500000 rw root=/dev/mmcblk0p5 init=/sbin/init > kgdboc=ttyS2,1500000 dynamic_debug.verbose=1 loglevel=7 dyndbg="module > dw_mmc +p ; module dw_mmc_rockchip +p ; module mmc_core +p" > <snip> > [ 0.793750] dwmmc_rockchip ff500000.dwmmc: IDMAC supports 32-bit > address mode. > [ 0.794402] dwmmc_rockchip ff500000.dwmmc: Using internal DMA controller. > [ 0.798582] dwmmc_rockchip ff500000.dwmmc: Version ID is 270a > [ 0.801194] dwmmc_rockchip ff500000.dwmmc: DW MMC controller at irq > 29,32 bit host data width,256 deep fifo > [ 0.815437] dwmmc_rockchip ff520000.dwmmc: IDMAC supports 32-bit > address mode. > [ 0.820273] dwmmc_rockchip ff520000.dwmmc: Version ID is 270a > [ 0.822904] dwmmc_rockchip ff520000.dwmmc: DW MMC controller at irq > 30,32 bit host data width,256 deep fifo > [ 0.825527] mmc_host mmc0: card is non-removable. > [ 0.838770] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req > 400000Hz, actual 400000HZ div = 0) > [ 0.888886] ADAMVY Regmap write 428 <= 2f802 > [ 0.904218] dwmmc_rockchip ff500000.dwmmc: IDMAC supports 32-bit > address mode. > [ 0.904870] dwmmc_rockchip ff500000.dwmmc: Using internal DMA controller. > [ 0.909055] dwmmc_rockchip ff500000.dwmmc: Version ID is 270a > [ 0.911637] dwmmc_rockchip ff500000.dwmmc: DW MMC controller at irq > 29,32 bit host data width,256 deep fifo > [ 0.913954] ADAMVY Setting gpio regulator to value 3300000 state 0 > [ 0.914503] ADAMVY Regmap write 428 <= 2f800 > [ 0.927612] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req > 400000Hz, actual 400000HZ div = 0) > [ 0.950160] VFS: Cannot open root device "mmcblk0p5" or > unknown-block(0,0): error -6 > > > > Finally here's an updated patch for the device tree with Robin's > original suggestion. > > > Index: 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 > +++ linux-5.5/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts > @@ -45,6 +45,7 @@ > vcc_sdio: sdmmcio-regulator { > compatible = "regulator-gpio"; > gpios = <&grf_gpio 0 GPIO_ACTIVE_HIGH>; > + enable-active-high; > states = <1800000 0x1 > 3300000 0x0>; > regulator-name = "vcc_sdio"; > >
On 2020-02-10 8:37 a.m., Robin Murphy wrote: > On 09/02/2020 1:07 am, Adam Van Ymeren wrote: >> Got it working. Robin you were right, it just needed enable-active-high; >> added to the regulator, updated patch at the end of this message. > > Weird... after my initial excitement I went back and looked more > closely at the binding and gpiolib-of code, only to realise that that > property is only supposed to apply to specific 'enable' GPIOs (of > which there are none here since it's always-on), and that the 'state' > GPIOs were a separate thing and I'd jumped to the wrong conclusion. So > now I'm doubly surprised that it actually makes a difference :/ Yeah you're right, it doesn't make a difference, it was just coincidence. It just seems to be really flaky, it's booting successfully about 20-30% of the time, I kept drawing conclusions based on one or two successful boots, but from now on I'll try 10 boots before With no changes and just unplugging/replugging the board, the kernel only finds mmcblk1 20-30% of the time. What's weird though is that the first stage idbloader and u-boot so far have worked 100% of the time on the same sdcard. As I said early in the thread, if I remove vcc_sdio/vqmmc from the device tree, then the kernel finds mmcblk1 every time I've attempted it so far, although I haven't done extensive tests to see if i/o is stable. So there seems to be _something_ about how the kernel is interacting with the regulator and/or the mmc host, otherwise I see no explanation for why the kernel would fail where u-boot had succeeded. I logged writes to register 0x428, and voltage changes in gpio-regulator, with the default device tree when asking for 3.3V it sets 0x428 to 0x20000, which is as expected, I verified the output of the voltage regulator with a multimeter and it does appear to be 3.3V. I notice however that early in the gpio setup it first writes 0x20002 to 0x428 before later writing 0x20000 what initializing the mmc driver [ 0.545007] ADAMVY regmap 428 <= 20002 [ 0.549348] dwmmc_rockchip ff500000.dwmmc: IDMAC supports 32-bit address mode. [ 0.550012] dwmmc_rockchip ff500000.dwmmc: Using internal DMA controller. [ 0.550615] dwmmc_rockchip ff500000.dwmmc: Version ID is 270a [ 0.551154] dwmmc_rockchip ff500000.dwmmc: DW MMC controller at irq 29,32 bit host data width,256 deep fifo [ 0.552527] ADAMVY: gpio_regulator_set_voltage vcc_sdio: uv: 3300000 state: 0 [ 0.553158] ADAMVY regmap 428 <= 20000 [ 0.566133] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0) My best guess is there's some sort of race condition? Maybe a capacitor is still charging and holding the voltage low just long enough that the kernel gives up? Or maybe the kernel is just not waiting long enough for the mmc host to finish initializing. In about 50% of my failed boots I see this debug messages about mmc1 mixed into the kernel panic like so. [ 0.662428] VFS: Cannot open root device "mmcblk1p5" or unknown-block(0,0): error -6 [ 0.663107] Please append a correct "root=" boot option; here are the available partitions: [ 0.663847] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [ 0.663872] mmc1: starting CMD6 arg 00fffff0 flags 000000b5 [ 0.664578] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.5.0 #37 [ 0.665061] mmc1: blksz 64 blocks 1 flags 00000200 tsac 100 ms nsac 0 [ 0.665572] Hardware name: Firefly roc-rk3328-cc (DT) [ 0.666600] Call trace: [ 0.666832] dump_backtrace+0x0/0x1b4 [ 0.667161] show_stack+0x14/0x1c [ 0.667461] dump_stack+0xb4/0x100 [ 0.667768] panic+0x120/0x2f4 [ 0.668046] mount_block_root+0x2a0/0x328 [ 0.668401] mount_root+0x7c/0x88 [ 0.668457] mmc1: req done (CMD6): 0: 00000900 00000000 00000000 00000000 [ 0.668700] prepare_namespace+0x154/0x164 [ 0.669288] mmc1: 64 bytes transferred: 0 [ 0.669642] kernel_init_freeable+0x1d0/0x254 [ 0.670040] mmc1: clock 25000000Hz busmode 2 powermode 2 cs 0 Vdd 21 width 1 timing 0 [ 0.670404] kernel_init+0x10/0xf8 [ 0.671131] mmc_host mmc1: Bus speed (slot 0) = 25000000Hz (slot req 25000000Hz, actual 25000000HZ div = 0) [ 0.671378] ret_from_fork+0x10/0x18 [ 0.672230] mmc1: starting CMD55 arg af530000 flags 00000095 suggesting that the kernel is still doing stuff with mmc1 after it's already given up on finding the root device. Here's dmesg from a successful boot | grep mmc $ grep mmc success.txt [ 0.000000] Kernel command line: earlycon=uart8250,mmio32,0xff130000 console=ttyS2,1500000 rw root=/dev/mmcblk1p5 init=/sbin/init kgdboc=ttyS2,1500000 loglevel=7 dyndbg="module dw_mmc +p ; module dw_mmc_rockchip +p ; module mmc_core +p" [ 0.123714] ADAMVY gpio fixed regulator quirks device: sdmmc-regulator active_low: 1 [ 0.485215] dwmmc_rockchip ff500000.dwmmc: IDMAC supports 32-bit address mode. [ 0.485879] dwmmc_rockchip ff500000.dwmmc: Using internal DMA controller. [ 0.486482] dwmmc_rockchip ff500000.dwmmc: Version ID is 270a [ 0.487054] dwmmc_rockchip ff500000.dwmmc: DW MMC controller at irq 29,32 bit host data width,256 deep fifo [ 0.489495] dwmmc_rockchip ff520000.dwmmc: IDMAC supports 32-bit address mode. [ 0.490153] dwmmc_rockchip ff520000.dwmmc: Using internal DMA controller. [ 0.490758] dwmmc_rockchip ff520000.dwmmc: Version ID is 270a [ 0.491313] dwmmc_rockchip ff520000.dwmmc: DW MMC controller at irq 30,32 bit host data width,256 deep fifo [ 0.492952] mmc_host mmc0: card is non-removable. [ 0.506161] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0) [ 0.559169] dwmmc_rockchip ff500000.dwmmc: IDMAC supports 32-bit address mode. [ 0.559834] dwmmc_rockchip ff500000.dwmmc: Using internal DMA controller. [ 0.560437] dwmmc_rockchip ff500000.dwmmc: Version ID is 270a [ 0.560980] dwmmc_rockchip ff500000.dwmmc: DW MMC controller at irq 29,32 bit host data width,256 deep fifo [ 0.575968] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0) [ 0.650647] mmc_host mmc1: Bus speed (slot 0) = 25000000Hz (slot req 25000000Hz, actual 25000000HZ div = 0) [ 0.657873] mmc1: new SD card at address af53 [ 0.659091] mmcblk1: mmc1:af53 SU02G 1.84 GiB [ 0.677231] mmcblk1: p1 p2 p3 p4 p5 [ 0.695708] EXT4-fs (mmcblk1p5): warning: mounting unchecked fs, running e2fsck is recommended [ 0.700796] EXT4-fs (mmcblk1p5): mounted filesystem without journal. Opts: (null) [ 1.029332] dwmmc_rockchip ff520000.dwmmc: Busy; trying anyway [ 1.529858] mmc_host mmc0: Timeout sending command (cmd 0x202000 arg 0x0 status 0x80202000) [ 1.544526] mmc_host mmc0: Bus speed (slot 0) = 300000Hz (slot req 300000Hz, actual 300000HZ div = 0) [ 2.067046] dwmmc_rockchip ff520000.dwmmc: Busy; trying anyway [ 2.567565] mmc_host mmc0: Timeout sending command (cmd 0x202000 arg 0x0 status 0x80202000) [ 2.582199] mmc_host mmc0: Bus speed (slot 0) = 200000Hz (slot req 200000Hz, actual 200000HZ div = 0) [ 3.107353] dwmmc_rockchip ff520000.dwmmc: Busy; trying anyway [ 3.607889] mmc_host mmc0: Timeout sending command (cmd 0x202000 arg 0x0 status 0x80202000) [ 3.622620] mmc_host mmc0: Bus speed (slot 0) = 100000Hz (slot req 100000Hz, actual 100000HZ div = 0) [ 4.155300] dwmmc_rockchip ff520000.dwmmc: Busy; trying anyway [ 4.655839] mmc_host mmc0: Timeout sending command (cmd 0x202000 arg 0x0 status 0x80202000) and for a failed boot $ grep mmc fail.txt [ 0.000000] Kernel command line: earlycon=uart8250,mmio32,0xff130000 console=ttyS2,1500000 rw root=/dev/mmcblk1p5 init=/sbin/init kgdboc=ttyS2,1500000 loglevel=7 dyndbg="module dw_mmc +p ; module dw_mmc_rockchip +p ; module mmc_core +p" [ 0.123799] ADAMVY gpio fixed regulator quirks device: sdmmc-regulator active_low: 1 [ 0.485295] dwmmc_rockchip ff500000.dwmmc: IDMAC supports 32-bit address mode. [ 0.485955] dwmmc_rockchip ff500000.dwmmc: Using internal DMA controller. [ 0.486560] dwmmc_rockchip ff500000.dwmmc: Version ID is 270a [ 0.487128] dwmmc_rockchip ff500000.dwmmc: DW MMC controller at irq 29,32 bit host data width,256 deep fifo [ 0.489584] dwmmc_rockchip ff520000.dwmmc: IDMAC supports 32-bit address mode. [ 0.490243] dwmmc_rockchip ff520000.dwmmc: Using internal DMA controller. [ 0.490849] dwmmc_rockchip ff520000.dwmmc: Version ID is 270a [ 0.491400] dwmmc_rockchip ff520000.dwmmc: DW MMC controller at irq 30,32 bit host data width,256 deep fifo [ 0.493043] mmc_host mmc0: card is non-removable. [ 0.506248] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0) [ 0.559249] dwmmc_rockchip ff500000.dwmmc: IDMAC supports 32-bit address mode. [ 0.559960] dwmmc_rockchip ff500000.dwmmc: Using internal DMA controller. [ 0.560564] dwmmc_rockchip ff500000.dwmmc: Version ID is 270a [ 0.561108] dwmmc_rockchip ff500000.dwmmc: DW MMC controller at irq 29,32 bit host data width,256 deep fifo [ 1.063521] dwmmc_rockchip ff520000.dwmmc: Busy; trying anyway [ 1.564049] mmc_host mmc0: Timeout sending command (cmd 0x202000 arg 0x0 status 0x80202000) [ 1.564925] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0) [ 1.579671] mmc_host mmc0: Bus speed (slot 0) = 300000Hz (slot req 300000Hz, actual 300000HZ div = 0) [ 2.109484] dwmmc_rockchip ff520000.dwmmc: Busy; trying anyway [ 2.610015] mmc_host mmc0: Timeout sending command (cmd 0x202000 arg 0x0 status 0x80202000) [ 2.612411] VFS: Cannot open root device "mmcblk1p5" or unknown-block(0,0): error -6 > >> I went back over my config with a fine tooth comb and found a few >> rockchip drivers I was missing including PINCTRL_RK805 which seems >> related but I honestly can't figure out how. I will try to narrow down >> which specific driver was missing. It was odd because it would find the >> mmc host but just fail notice that a card was present. It seemed to set >> the register correctly and identify the mmc host, but failed to notice >> any card present. > > PINCTRL_RK805 should only be for the couple of GPIO pins on the PMIC > itself which IIRC the reference design uses for the ethernet LEDs, so > I wouldn't expect it to be relevant. Indeed. I was drawing connections that weren't there due to the flakiness. > > Those symptoms make sense for the voltages being backwards (or just > stuck at 1.8V) though - when the I/O domain is configured to expect > 3.3V, 1.8V is too low to register as a logic high, so Linux will > always think that something is inserted in the slot, but not talking back. Hmm. I tried adding broken-cd, but I couldn't tell any significant difference in the rate of successful boots. I have an emmc module coming so hopefully I can have something reliable to boot from and can iterate faster without having to physically move an sdcard back and forth every time. > Robin.
I'm dumb, I forgot about the rootwait kernel parameter... 15 successful boots in a row so far after adding that. Sorry for all the noise. Thanks for the help and patience, -Adam On 2020-02-10 8:37 a.m., Robin Murphy wrote: > On 09/02/2020 1:07 am, Adam Van Ymeren wrote: >> Got it working. Robin you were right, it just needed enable-active-high; >> added to the regulator, updated patch at the end of this message. > > Weird... after my initial excitement I went back and looked more > closely at the binding and gpiolib-of code, only to realise that that > property is only supposed to apply to specific 'enable' GPIOs (of > which there are none here since it's always-on), and that the 'state' > GPIOs were a separate thing and I'd jumped to the wrong conclusion. So > now I'm doubly surprised that it actually makes a difference :/ > >> I went back over my config with a fine tooth comb and found a few >> rockchip drivers I was missing including PINCTRL_RK805 which seems >> related but I honestly can't figure out how. I will try to narrow down >> which specific driver was missing. It was odd because it would find the >> mmc host but just fail notice that a card was present. It seemed to set >> the register correctly and identify the mmc host, but failed to notice >> any card present. > > PINCTRL_RK805 should only be for the couple of GPIO pins on the PMIC > itself which IIRC the reference design uses for the ethernet LEDs, so > I wouldn't expect it to be relevant. > > Those symptoms make sense for the voltages being backwards (or just > stuck at 1.8V) though - when the I/O domain is configured to expect > 3.3V, 1.8V is too low to register as a logic high, so Linux will > always think that something is inserted in the slot, but not talking > back. > > Robin. > >> I haven't yet tested this with a high speed card yet to verify 1.8v >> signaling works but I'll find one and give it a shot. >> >> Thanks a ton to both of your for the help >> >> >> On 2020-02-05 1:43 p.m., Peter Geis wrote: >>>>> First question, which kernel are you running? >>>>> Current mainline (5.4.17) works out of the box for the rk3328-roc-cc. >>>> Not from my experience. I'm trying 5.5, but I also tried a fresh >>>> build >>>> ot 5.4.17 and neither will load from the sdcard in their default >>>> configuration. If you have this working can you share your kernel >>>> config? >>> Considering all of the components to boot off emmc (which you are >>> clearly doing since you boot at all) are the same as the ones required >>> for sdmmc I doubt it's a configuration issue. >>> But to answer your question, I used the defconfig, stripped all of the >>> non rockchip components out, and made the base drivers builtin. >> >> So I wasn't booting off of emmc. I was booting from the sdcard, it >> would work so long as I prevented the kernel from trying to initialize >> the vcc_sdio regulator (by removing it or changing the gpio pin), >> presumably as u-boot left it in a reasonable state. >> >>> Makes sense. If I remove vcc_sdio from the device tree, and remove the >>>> vqmmc entry from the sdmmc node, then the kernel continues to >>>> boot. In >>>> that case I have >>>> >>>> # cat /sys/kernel/debug/regmap/dummy-syscon\@ff100000/registers | >>>> grep 428 >>>> >>>> 428: 0000f800 >>> As it should be, this should mean your mute pin is off (default state) >>> and the vqmmc voltage should be 3.3v. >> >> Gotcha. I also managed to verify this works as expected on my board >> with a multimeter and toggling the register from the u-boot shell. >> >>> >>>> # cat /sys/kernel/debug/mmc1/ios >>>> clock: 0 Hz >>>> vdd: 0 (invalid) >>>> bus mode: 2 (push-pull) >>>> chip select: 0 (don't care) >>>> power mode: 0 (off) >>>> bus width: 0 (1 bits) >>>> timing spec: 0 (legacy) >>>> signal voltage: 0 (3.30 V) >>>> driver type: 0 (driver type B) >>> It's not detecting anything at all. >>> You say you booted off this card? >> So this is booting when I disabled vcc_sdio and just left it in the >> state that u-boot left it in, which is probably where the nonsensical >> output comes from. >>> >>> Could you run a `dmesg | grep mmc` and send all the results? >> >> Here's a slightly scrubbed log of one of my failed boots. I left in my >> traces of register writes to 428 and gpio-regulator state changes. >> >> [ 0.000000] Kernel command line: earlycon=uart8250,mmio32,0xff130000 >> console=ttyS2,1500000 rw root=/dev/mmcblk0p5 init=/sbin/init >> kgdboc=ttyS2,1500000 dynamic_debug.verbose=1 loglevel=7 dyndbg="module >> dw_mmc +p ; module dw_mmc_rockchip +p ; module mmc_core +p" >> <snip> >> [ 0.793750] dwmmc_rockchip ff500000.dwmmc: IDMAC supports 32-bit >> address mode. >> [ 0.794402] dwmmc_rockchip ff500000.dwmmc: Using internal DMA >> controller. >> [ 0.798582] dwmmc_rockchip ff500000.dwmmc: Version ID is 270a >> [ 0.801194] dwmmc_rockchip ff500000.dwmmc: DW MMC controller at irq >> 29,32 bit host data width,256 deep fifo >> [ 0.815437] dwmmc_rockchip ff520000.dwmmc: IDMAC supports 32-bit >> address mode. >> [ 0.820273] dwmmc_rockchip ff520000.dwmmc: Version ID is 270a >> [ 0.822904] dwmmc_rockchip ff520000.dwmmc: DW MMC controller at irq >> 30,32 bit host data width,256 deep fifo >> [ 0.825527] mmc_host mmc0: card is non-removable. >> [ 0.838770] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req >> 400000Hz, actual 400000HZ div = 0) >> [ 0.888886] ADAMVY Regmap write 428 <= 2f802 >> [ 0.904218] dwmmc_rockchip ff500000.dwmmc: IDMAC supports 32-bit >> address mode. >> [ 0.904870] dwmmc_rockchip ff500000.dwmmc: Using internal DMA >> controller. >> [ 0.909055] dwmmc_rockchip ff500000.dwmmc: Version ID is 270a >> [ 0.911637] dwmmc_rockchip ff500000.dwmmc: DW MMC controller at irq >> 29,32 bit host data width,256 deep fifo >> [ 0.913954] ADAMVY Setting gpio regulator to value 3300000 state 0 >> [ 0.914503] ADAMVY Regmap write 428 <= 2f800 >> [ 0.927612] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req >> 400000Hz, actual 400000HZ div = 0) >> [ 0.950160] VFS: Cannot open root device "mmcblk0p5" or >> unknown-block(0,0): error -6 >> >> >> >> Finally here's an updated patch for the device tree with Robin's >> original suggestion. >> >> >> Index: 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 >> +++ linux-5.5/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts >> @@ -45,6 +45,7 @@ >> vcc_sdio: sdmmcio-regulator { >> compatible = "regulator-gpio"; >> gpios = <&grf_gpio 0 GPIO_ACTIVE_HIGH>; >> + enable-active-high; >> states = <1800000 0x1 >> 3300000 0x0>; >> regulator-name = "vcc_sdio"; >> >>
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>; states = <1800000 0x1 3300000 0x0>; regulator-name = "vcc_sdio";
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@vany.ca>