BPI-R3 button connections

Banana Pi Router design BPI-R3/R3 Mini(MT7986)
1

I am investigating a pinctrl conflict error in the Linux device tree file for the BPI-R3.

The issue is that the reset and WPS push buttons are connected to GPIO9 and GPIO10 (aka GPIO_4 & GPIO_5 "Pin Name"s). The device tree claims these two GPIOs for use with a button device.

These two pins can also be used for PCIE_CLK_REQ (GPIO9) and PCIE_WAKE_N (GPIO10) for the PCIe port. The device tree tries to also claim PCIE_CLK_REQ for the PCIe device thus the conflict with the button device.

The BPI-R3 schematic shows the GPIO_4 pin connected to the PWAKE#0 and WPS_PBC nets, and both are interconnected via 0R resistors. PWAKE#0 goes to the CN10 M.2 socket, and WPS_PBC to the push button.

The schematic also shows the GPIO_4 pin connected to the PCK_REQ#0 and RST_PBC nets, and both are interconnected via 0R resistors. PCK_REQ#0 goes to the CN10 M.2 socket, and RST_PBC to the push button.

Looking at my board none of the resistors are labelled so I can’t work out if those resistors are actually connected up or not to work out which function they are actually being used for - either the push button or both at the same time.

Does anyone know where I can find out which resistors on the board are which ones in the schematic?

Does anyone know if the PCIe or push button resistors have been connected?

Otherwise I will have to bust out my multimeter and start probing things.

2

I found another conflict, in the device tree the GPIO5 (aka GPIO_0 “pin name”) is assigned as the reset pin for the MDIO/MT7531 device, but in the schematic this is one of the boot select switch inputs.

The schematic is missing the MT7531 chip so I can’t see if this GPIO5 is actually hooked up to the reset pin.

Does anyone know if this pin is connected? I think it is unlikely otherwise the boot selection switch would disable the MT7531 chip.

3

in my schematic for R3 v1.1 GbE_RESET/GPIO32 is connected over rg32 (0R) to mt7531 reset pin (MT7531_RST,PAD_SYS_RSTB, pin86)

i have no assembly file for bpi-r3, so cannot tell you where the resistors are located for pcie

4

@frank-w thanks for the help - is your copy of the schematic publicly available?

Using GPIO32 as the reset makes sense as avoids the push button conflict.

I see you authored the upstream Linux DTS file for the board, so I would like to coordinate a few fixes with you to get patched. I am still learning about the process for submitting fixes.

The fixes I have made so far:

uart0 There is no default pin group, so I added:

&pio {
...
	uart0_pins: uart0-pins {
		mux {
			function = "uart";
			groups = "uart0";
		};
	};
...
};
...

&uart0 {
	pinctrl-names = "default";
	pinctrl-0 = <&uart0_pins>;
	status = "okay";
};

uart1 The RTS CTS pins for UART1 are available on the CON1 header but are not in the pin group, so I changed from “uart1_rx_tx” to “uart1” group which includes RTS/CTS pins:

&pio {
...
	uart1_pins: uart1-pins {
		mux {
			function = "uart";
			groups = "uart1";
		};
	};
...
};

pcie: The pin group “pcie_clk” has a conflict between PCIE_CLK_REQ and GPIO9 for reset-key device, so I removed the “pcie_clk” pin group:

&pio {
...
	pcie_pins: pcie-pins {
		mux {
			function = "pcie";
			groups = "pcie_pereset";
		};
	};
...
};

This fixes a kernel boot log error:

[    3.741529] mt7986a-pinctrl 1001f000.pinctrl: pin GPIO_4 already requested by pinctrl_moore:521; cannot claim for 11280000.pcie
[    3.753137] mt7986a-pinctrl 1001f000.pinctrl: pin-9 (11280000.pcie) status -22

which was preventing the pcie driver from loading.

ssusb: The required voltage regulator supply entries were missing, so I added a fixed 3.3V and 5V regulator:

/ {
...
	reg_5v: regulator-5v {
		compatible = "regulator-fixed";
		regulator-name = "5vd";
		regulator-min-microvolt = <5000000>;
		regulator-max-microvolt = <5000000>;
		regulator-boot-on;
		regulator-always-on;
		vin-supply = <&dcin>;
	};
...
};
...
&ssusb {
	status = "okay";
	vbus-supply = <&reg_5v>;
	vusb33-supply = <&reg_3p3v>;
};

This fixes a kernel log warning:

[    3.836017] xhci-mtk 11200000.usb: supply vbus not found, using dummy regulator
[    3.843721] xhci-mtk 11200000.usb: supply vusb33 not found, using dummy regulator

The schematic shows the USB 3 socket and USB 2 pin header each have their own 5V regulator coming off the main 5V regulator, but seems unnecessary to add that detail as all the regulators are always on and don’t have an enable GPIO.

There are a few other changes I am considering but I need to do more testing: Add a gpio-decoder device for the boot mode DIP switch 2 bits - this will occupy GPIO5 and GPIO6 which will help detect future conflicts and provide a convenient way to check the switch position.

Add an audio device (which now has in-tree drivers) and hook up pin groups for the CON1 PCM pins - this could be an overlay file. I have ordered an audio codec breakout board to test this.

Add the SNFI/SNAND device. This is not populated on the board I have so might need to leave it as disabled, and use this as documentation of the pin connections. Though without populating the chip I can’t test this so perhaps that won’t be allowed in the Linux tree.

5

Also to correct the GPIO32 MT7531 reset pin:

&mdio {
	switch: switch@31 {
...
		reset-gpios = <&pio 32 GPIO_ACTIVE_HIGH>;
	};
};
6

my schematic is not the public one and cannot be shared.

I had used the rx/tx here as there are conflicts (afair with spi),so you can do in your tree but not upstream.

Yes thats because in openwrt reset key is disabled. One of the patches i wanted to post upstream,but no time yet…still waiting for requested change for overlays to be accepted.

7

Hmm on the public schematic the UART1_CTS & UART1_RTS are only shared with GPIO44 and GPIO45. And those nets are not connected to anything else.

The pinctrl driver shows that these two pins can only be configured for UART or GPIO as well. So I can’t see why these pins can’t be enabled.

Of course a user might decide to use these for GPIO and change the configuration in their own overlay, but that also applies to all the other CON1 pins.

8

Will there be an overlay to choose between the buttons or the PCIe connector? The PCIe also has a the same conflict with the WPS key and the wake line.

I don’t understand why the board designers did things this way. There are plenty of other unused GPIO lines they could have wired the buttons up to.

9

Then this was changed in revisions…i had a conflict where i splitted the uart…

You can of course change it in your source and maybe send patch to ML if you checked this and it is working.But afaik only a few users use cts/rts lines and want to use the gpio.

More interesting is the reset/pcie part…do you really think we can drop pcie_clk? For me it sounds required…i thought more about removing the reset button.

10

I need to get my hands on a NVMe SSD card to confirm this change. That is my next task. The boot log indicates that the PCIe driver doesn’t manage to set the pin to PCIe clock mode as the buttons are loaded first. So in the current state is the clock line is required for PCIe, then it will be broken.

I will not submit this change until I get a change to test it well.

11

Maybe this is the cause i sometimes see pcie clock issues in some bootlogs…did have them,but i guess i have not added buttons option in kernel as i do not need them.

12

I just found your patch email. I will try to find some time to test that SATA overlay and give you a tested by - maybe it will help it get picked up?

13

Yes,maybe it helps to not stall again…but first patch is only for building purposes requested by rob…so i wonder he does not comment it with an ack/nack

14

I did try to test the SATA power overlay file, but ran into some problem with U-boot not applying the overlay, I wonder if its because I was trying to apply 3 overlays now instead of 2.

Also I got a NVMe SSD this week and put it into the M.2 slot. With the GPIO pins set to the push buttons and not the pcie_clk function everything seems to be working fine. So I am not sure what that function is required for.

15

Google turned up this reference on the different PCIe pins - https://www.ti.com/lit/an/snla415/snla415.pdf

It seems these pin functions are only used for a power saving mode, so that is why the SSD still works normally. I guess it might draw some more power.

16

how did you try to apply the overlay? my way is via fit and afair this was working when using config applying all overlays (mmc+spi+sata)

17

I was doing it via “fdt apply” in U-boot

I will try again so I can grab the error message.