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 [off-list ref] wrote:

quoted

On 2020-02-04 10:15 a.m., Peter Geis wrote:

quoted

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.

quoted

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 {

quoted

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.

quoted

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-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel