On Tue, Feb 4, 2020 at 11:14 AM Adam Van Ymeren <adam@xxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-rockchip
