[OpenWrt-Devel] [PATCH 3/3] ipq40xx: add support for FritzBox 7530

Christian Lamparter chunkeey at gmail.com
Mon Feb 11 17:15:08 EST 2019


Comments inline.

On Sunday, February 10, 2019 2:34:30 PM CET David Bauer wrote:
> Hardware
> --------
> CPU:   Qualcomm IPQ4019
> RAM:   256M
> FLASH: 128M NAND
> ETH:   QCA8075
> VDSL:  Intel/Lantiq VRX518 PCIe attached
>        currently not supported

Does the pcie device show up during boot when
you add and enable the pcie nodes in the dts?
Or is more work required to get at least "lspci" working?

> DECT:  Dialog SC14448
>        currently not supported
(hm, seems to be a spi? chip)

> WiFi2: IPQ4019 2T2R 2SS b/g/n
> WiFi5: IPQ4019 2T2R 2SS n/ac
> LED:    - Power/DSL green
>         - WLAN green
>         - FON/DECT green
>         - Connect/WPS green
>         - Info green
>         - Info red
> BTN:    - WLAN
>         - FON
>         - WPS/Connect
> UART:  115200n8 3.3V (located under the Dialog chip)
>        VCC - RX - TX - GND (Square is VCC)
>  [...]
> diff --git a/target/linux/ipq40xx/base-files/etc/board.d/01_leds b/target/linux/ipq40xx/base-files/etc/board.d/01_leds
> index 9105bf2452..39383f4fa8 100755
> --- a/target/linux/ipq40xx/base-files/etc/board.d/01_leds
> +++ b/target/linux/ipq40xx/base-files/etc/board.d/01_leds
> @@ -28,6 +28,7 @@ engenius,eap1300)
>  	ucidef_set_led_wlan "wlan5g" "WLAN5G" "${boardname}:yellow:wlan5g" "phy1tpt"
>  	ucidef_set_led_default "mesh" "MESH" "${boardname}:blue:mesh" "0"
>  	;;
> +avm,fritzbox-7530 |\
With this addtion, you could just move the ucidef_set_led_wlan entry in front
of engenius,eap1300 device.

Or you could maybe instead place the

linux,default-trigger = "phy0tpt";

property into the DTS (fritzbox-7530:green:wlan's node) to do the same job.
 
>  glinet,gl-b1300)
>  	ucidef_set_led_wlan "wlan" "WLAN" "${boardname}:green:wlan" "phy0tpt"
>  	;;
> diff --git a/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata b/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> index 69b6c2591c..b4252f0ea6 100644
> --- a/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> +++ b/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> @@ -126,6 +126,9 @@ case "$FIRMWARE" in
>  	avm,fritzbox-4040)
>  		/usr/bin/fritz_cal_extract -i 1 -s 0x400 -e 0x207 -l 12064 -o /lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader_config")
>  		;;
> +	avm,fritzbox-7530)
> +		/usr/bin/fritz_cal_extract -i 1 -s 0x3C000 -e 0x207 -l 16384 -o /lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader0")
Oh, I think I remember this from the FB4040 as well. It too had 16384 long
caldata. But everything after byte 12064 was just more padding. That why
I cut it down to make sure not to push any garbage into the running firmware,
because from what I remember, the ath10k will take anything from the pre-cal
at face-value.

> +		;;
>  	meraki,mr33)
>  		ath10kcal_ubi_extract "ART" 4096 12064
>  		ath10kcal_is_caldata_valid "202f" || ath10kcal_extract "ART" 4096 12064
> @@ -164,6 +167,9 @@ case "$FIRMWARE" in
>  	avm,fritzbox-4040)
>  		/usr/bin/fritz_cal_extract -i 1 -s 0x400 -e 0x208 -l 12064 -o /lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader_config")
>  		;;
> +	avm,fritzbox-7530)
> +		/usr/bin/fritz_cal_extract -i 1 -s 0x3C800 -e 0x208 -l 16384 -o /lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader1")
> +		;;
Oh, so if the urlader1 has the same values as urlader0, you could check the return
status of fritz_cal_extract and if it failed, then follow up with a fallback to read
from the other urlader config area.

something like:

/usr/bin/fritz_cal_extract -i 1 -s 0x3C800 -e 0x208 -l 12064 -o /lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader0") || \
/usr/bin/fritz_cal_extract -i 1 -s 0x3C800 -e 0x208 -l 12064 -o /lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader1")

> diff --git a/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
> new file mode 100644
> index 0000000000..ea2d70a8bd
> --- /dev/null
> +++ b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
> +	leds {
> +		compatible = "gpio-leds";
> +
> +		info_red: info_red {
> +			label = "fritzbox-7530:red:info";
> +			gpios = <&tlmm 32 GPIO_ACTIVE_LOW>;
> +		};
> +
> +		info_green: info {
> +			label = "fritzbox-7530:green:info";
> +			gpios = <&tlmm 33 GPIO_ACTIVE_LOW>;
> +		};
> +
> +		wlan {
> +			label = "fritzbox-7530:green:wlan";
> +			gpios = <&tlmm 34 GPIO_ACTIVE_LOW>;
          <this place> (and the same place in 4.19's dts)
> +		};
> +
> +		fon {
> +			label = "fritzbox-7530:green:fon";
> +			gpios = <&tlmm 35 GPIO_ACTIVE_LOW>;
> +		};
> +
> [...]
> +
> +	nand_pins: nand_pins {
> +		pullups {
> +			pins = "gpio52", "gpio53", "gpio58",
> +				"gpio59";
Just a word of warning here. The gpio52 might not be necessary for the
functioning of the attached nand flash. We put this warning in the
MR33's dts:

/*
 * There are 18 pins. 15 pins are common between LCD and NAND.
 * The QPIC controller arbitrates between LCD and NAND. Of the
 * remaining 4, 2 are for NAND and 2 are for LCD exclusively.
 *
 * The meraki source hints that the bluetooth module claims
 * pin 52 as well. But sadly, there's no data whenever this
 * is a NAND or LCD exclusive pin or not.
 */

> +			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;
> +		};
> +	};
> +
> +	usb-power {
> +		line-name = "enable USB3 power";
> +		gpios = <49 GPIO_ACTIVE_HIGH>;
> +		gpio-hog;
> +		output-high;
In the future, this will hopefully become a regulator.
But so far there's no support for it upstream. Hence this is fine.

> +	};
> +};
> +
> +&nand {
> +	pinctrl-0 = <&nand_pins>;
> +	pinctrl-names = "default";
> +	status = "okay";
> +	cs-gpios = <&tlmm 54 GPIO_ACTIVE_HIGH>;
> +
> +	nand at 0 {
> +		partitions {
> +			compatible = "fixed-partitions";
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +
> +			partition at 0 {
> +				label = "MIBIB";
This is strange, is there really a MIBIB partition there? Not that it makes any
difference since we are not going to mess with the bootloaders. But from all the
different Qcom devices I had my hands on, the first partition always contained
the SBL1 (Secondary Bootloader 1). (If it is a copy of the MIBIB, then...
is there another hidden flash chip?! And please give one of the partitions
a (slightly) different name in this case.)
 
> +				reg = <0x000000 0x80000>;
> +				read-only;
> +			};
> +
> +			partition at 80000 {
> +				label = "MIBIB";
> +				reg = <0x080000 0x80000>;
> +				read-only;
> +			};
> +
[...]
> +
> +			partition at 2c0000 {
> +				label = "nand-tffs";
> +				reg = <0x2c0000 0x840000>;
> +				read-only;
> +			};
> +
[...]
> diff --git a/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
> new file mode 100644
> index 0000000000..ea2d70a8bd
> --- /dev/null
> +++ b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
> @@ -0,0 +1,281 @@
> +// 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!Box 7530";
> +	compatible = "avm,fritzbox-7530", "qcom,ipq4019";
The "qcom,ipq4019"; can be dropped. Upstream dropped them
as well see commit a2501ebfb066 ("ipq40xx: remove qcom,ipq4019 on all devices")

> diff --git a/target/linux/ipq40xx/image/Makefile b/target/linux/ipq40xx/image/Makefile
> index a670380ab3..ca5a453b47 100644
> --- a/target/linux/ipq40xx/image/Makefile
> +++ b/target/linux/ipq40xx/image/Makefile
> @@ -97,6 +97,15 @@ define Device/avm_fritzbox-4040
>  endef
>  TARGET_DEVICES += avm_fritzbox-4040
>  
> +define Device/avm_fritzbox-7530
> +	$(call Device/FitImageLzma)
> +	DEVICE_DTS := qcom-ipq4019-fritzbox-7530
> +	DEVICE_TITLE := AVM Fritz!Box 7530
> +	DEVICE_PACKAGES := fritz-caldata ipq-wifi-fritz7530
I remember seeing a fritz_tffs_nand_read utility:

https://lists.openwrt.org/pipermail/openwrt-devel/2018-March/011501.html
maybe it could be of use?

> +	IMAGES := sysupgrade.bin
> +endef
> +TARGET_DEVICES += avm_fritzbox-7530
> +
>  define Device/compex_wpj428
>  	$(call Device/FitImage)
>  	DEVICE_DTS := qcom-ipq4028-wpj428

Regards,
Christian



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



More information about the openwrt-devel mailing list