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@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@0,0 { > + reg = <0x00000000 0 0 0 0>; > + #address-cells = <3>; > + #size-cells = <2>; > + ranges; > + > + wifi@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@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel