[OpenWrt-Devel] [PATCH 3/3] ipq40xx: add support for FritzBox 7530
David Bauer
mail at david-bauer.net
Tue Feb 12 14:55:37 EST 2019
Hi Christian,
On 11.02.19 23:15, Christian Lamparter wrote:
> 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?
You will need to adjust the ranges of the PCIe bus, but nothing more is
required to get the endpoint atleast detected. See here:
https://github.com/blocktrron/openwrt/commit/1766b385d6500abdd6a32c33007c47da62e2b757
Maybe we sould add this commented-out to the devicetree? I see no point
in enabling the PCIe bus for a currently non-working device.
>> DECT: Dialog SC14448
>> currently not supported
> (hm, seems to be a spi? chip)
It seems to be UART and PCM attached. At least the AVM Firmware smashes
the Firmware for the chip over the UART while booting. There is very
little information about the Chip available only. I assume it's AVM
proprietary so i didn't bother with it.
>> 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.
I would prefer the above solution to keep it target-consistent.
> 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.
Great info, i'm going to check this!
>
>> + ;;
>> 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")
Yeah, this is possible as the data is stored in both partitions. I
decided to go for urlader1 as the pointers for the mac-address point
into urlader1, even the ones in urlader0 (see the U-Boot for the device).
I assume urlader1 is the backup in case uralder0 gets corrupted, but as
it's the first box I've seen with such a dual-bootloader setup I'm not
really sure.
>> 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.
> */
I've re-checked the device-tree from AVM. They are not referencing a
gpio52 anywhere. So i assume this pin is indeed not related to the NAND
chip.
>> + 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.)
You got me there ;) It's a mistake this is indeed the SBL1 partition.
The label is a mistake.
>> + 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")
Woopsy, missed this one while rebasing
>> 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?
Yeah, i've had a modified version working with this box. There is
another effort getting the tool into OpenWRT and i commented about the
issue i faced with the 7530. Let's see if this is going somewhere.
https://github.com/openwrt/openwrt/pull/1766/files#r254196732
Best wishes
David
>> + 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