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@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.
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!
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-rockchip
