Hello Christian,
first of all, thanks for the review!
On 08.03.19 22:23, Christian Lamparter wrote:
> 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?
Will be contained in the v2. In the meantime:
RAM: NANYA NT5CC128M16JR-EK
NAND: Macronix MX30LF1G18AC-XKI
> [...]
>> 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.
Thanks, will fix that.
>
>> + 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?
It's 3 separate LEDs on the PCB, but they are directed to the same spot
on the case, so technically it works like a 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.
You are right. I will alter this in v2 and prepare a patch to remove
this property from the 7530. Thanks for spotting this!
>> + 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?
I can do that. In fact, the BDF from the 7530 is identical with a
reference boardfile (although this one has another chip-id). I only
noticed this while calculating the checksums for submitting.
Best wishes
David
>> +};
>> +
>> +&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
