[OpenWrt-Devel] [PATCH 2/2] ipq40xx: add support for AVM FRITZ!Repeater 3000

[Christian Lamparter]

On Tuesday, March 5, 2019 7:38:38 PM CET David Bauer wrote:
> Hardware
> --------
> CPU:   Qualcomm IPQ4019
> RAM:   256M
> FLASH: 128M NAND
Sorry for being nosy. Did you get any chance to open up the device
and write down what RAM and flash chips are used in your unit?

[...]
> diff --git a/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzrepeater-3000.dts b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzrepeater-3000.dts
> new file mode 100644
> index 0000000000..b73a214c09
> --- /dev/null
> +++ b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzrepeater-3000.dts
> @@ -0,0 +1,261 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +
> +#include "qcom-ipq4019.dtsi"
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/soc/qcom,tcsr.h>
> +
> +/ {
> +	model = "AVM FRITZ!Repeater 3000";
> +	compatible = "avm,fritzrepeater-3000";
> +
> +	aliases {
> +		led-boot = &power_led;
> +		led-failsafe = &power_led;
> +		led-running = &power_led;
> +		led-upgrade = &power_led;
> +	};
> +
> +	keys {
Since it's a single "key" or "button" you can of course
also call this node "key" or "button". Whatever fits the
best.

> +		compatible = "gpio-keys";
> +
> +		connect {
> +			label = "Connect";
> +			gpios = <&tlmm 10 GPIO_ACTIVE_LOW>;
> +			linux,code = <KEY_WPS_BUTTON>;
> +		};
> +	};
> +
> +	leds {
> +		compatible = "gpio-leds";
> +
> +		connect_red {
> +			label = "fritzwlan-3000:red:connect";
> +			gpios = <&tlmm 30 GPIO_ACTIVE_LOW>;
> +		};
> +
> +		connect_green {
> +			label = "fritzwlan-3000:green:connect";
> +			gpios = <&tlmm 31 GPIO_ACTIVE_LOW>;
> +		};
> +
> +		connect_blue {
> +			label = "fritzwlan-3000:blue:connect";
> +			gpios = <&tlmm 32 GPIO_ACTIVE_LOW>;
> +		};
Just a question: Are the "connect" LED three different LEDs
or just one RGB LED?

> +
> +		power_led: power {
> +			label = "fritzwlan-3000:green:power";
> +			gpios = <&tlmm 33 GPIO_ACTIVE_LOW>;
> +		};
> +	};
> +};
> +
> +&tlmm {
> +	serial_0_pins: serial_pinmux {
> +		mux {
> +			pins = "gpio16", "gpio17";
> +			function = "blsp_uart0";
> +			bias-disable;
> +		};
> +	};
> +
> +	nand_pins: nand_pins {
> +		pullups {
> +			pins = "gpio53", "gpio58", "gpio59";
> +			function = "qpic";
> +			bias-pull-up;
> +		};
> +
> +		pulldowns {
> +			pins = "gpio54", "gpio55", "gpio56",
> +				"gpio57", "gpio60", "gpio61",
> +				"gpio62", "gpio63", "gpio64",
> +				"gpio65", "gpio66", "gpio67",
> +				"gpio68", "gpio69";
> +			function = "qpic";
> +			bias-pull-down;
> +		};
> +	};
> +};
> +
> +&nand {
> +	pinctrl-0 = <&nand_pins>;
> +	pinctrl-names = "default";
> +	status = "okay";
> +	cs-gpios = <&tlmm 54 GPIO_ACTIVE_HIGH>;
cs-gpios? Oh no! the qcom,ipq4019-nand does not have this property binding.
<https://www.kernel.org/doc/Documentation/devicetree/bindings/mtd/qcom_nandc.txt>

It looks like this error also slipped by in the 7530 Image. It must have been
copy&pasted from a spi device-tree since gpio54 shows up there.

Luckily, the driver does not do anything with it so gpio54 does not get
reassigned as a gpio pin, otherwise this would be a desaster.

> +	nand at 0 {
> +		partitions {
> +			compatible = "fixed-partitions";
> [...]
> +
> +&wifi0 {
> +	status = "okay";
> +	/* BDFs are identical for the FRITZ!Box 7530 and the FRITZ!Repeater 3000 */
> +	qcom,ath10k-calibration-variant = "AVM-FRITZBox-7530";
Didn't find any GPL sources or firmware releases for this device yet. So, I
would much rather err on the side of caution and change this so that the 
device gets its own variant. Even if the boarddata is seemingly shared between
"different" devices from the same vendor.

I'm suggesting this because Qualcomm does this as well for their QCA9377 and
QCA6174 customer cards. Each card has its own copy of the boardfiles even if
it could be shared among two, three or ten. But that's how Qualcomm works.

So, can you please jump through the robes and send the boardfiles upstream?
> +};
> +
> +&wifi1 {
> +	status = "okay";
> +	ieee80211-freq-limit = <5170000 5350000>;
> +	/* BDFs are identical for the FRITZ!Box 7530 and the FRITZ!Repeater 3000 */
> +	qcom,ath10k-calibration-variant = "AVM-FRITZBox-7530";
>
> +};
> +
> +&pcie0 {
> +	status = "okay";
> +
> +	perst-gpio = <&tlmm 35 GPIO_ACTIVE_LOW>;
> +	wake-gpio = <&tlmm 50 GPIO_ACTIVE_LOW>;
> +
> +	bridge at 0,0 {
> +		reg = <0x00000000 0 0 0 0>;
> +		#address-cells = <3>;
> +		#size-cells = <2>;
> +		ranges;
> +
> +		wifi at 1,0 {
> +			/* QCA9984 */
> +			compatible = "qcom,ath10k";
> +			status = "okay";
> +			reg = <0x00010000 0 0 0 0>;
> +			ieee80211-freq-limit = <5470000 5875000>;
> +			/* Uses the reference BDF */
Ok, never got a QCA9984 or QCA9980 so that's fine. (Yes, I'm aware that this seems to
contradict the wish from the IPQ4019 above. However, apart from a few QCA9984 pci
cards, I haven't heard of any major issue with the boardfiles there, whereas with
IPQ4019 we had many).

Cheers,
Christian



_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel