[OpenWrt-Devel] [PATCH 3/3] ipq40xx: add support for FritzBox 7530
David Bauer
mail at david-bauer.net
Tue Feb 12 16:38:17 EST 2019
On 12.02.19 22:17, Christian Lamparter wrote:
> On Tuesday, February 12, 2019 8:55:37 PM CET David Bauer wrote:
>> 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.
>
> Man, this "just" (in QCOM time) got patched :-/.
>
> (This went into 4.20):
>
> <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/qcom-ipq4019.dtsi?id=da89f500cb55fb3f19c4b399b46d8add0abbd4d6>
I'm aware of this patch but i'm not aure if we might indeed have
problems with other devices and the bigger memory space. But i also have
no other device to test this with, soo.
>
> From what I can tell, the pcie DSL device just does not
> have enough "real-estate". Do you maybe have some bootlogs
> of your 7530 device around when it's doing the pcie initialization?
> (Having bootlogs of both the vendor and openwrt would be great, especially
> openwrt in both configurations: the current, failing one and the working one).
I can provide you with the snippet of working initialization in OpenWRT
and from the vendor for now. I recall it was complaining about not
enough space in the BAR when not altering the range in the device tree.
AVM:
[ 0.333513] qcom-pcie 40000000.pci: link up
[ 0.333779] qcom-pcie 40000000.pci: PCI host bridge to bus 0000:00
[ 0.333807] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 0.333833] pci_bus 0000:00: root bus resource [io 0x0000-0xfffff]
(bus address [0x40200000-0x402fffff])
[ 0.333854] pci_bus 0000:00: root bus resource [mem
0x48000000-0x57ffffff]
[ 0.333904] pci 0000:00:00.0: [1bef:0030] type 01 class 0x060400
[ 0.333952] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x00000fff]
[ 0.334035] pci 0000:00:00.0: PME# supported from D0 D3hot D3cold
[ 0.334411] PCI: bus0: Fast back to back transfers disabled
[ 0.334664] pci 0000:01:00.0: [8086:09a9] type 00 class 0x028000
[ 0.334823] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x007fffff]
[ 0.335209] pci 0000:01:00.0: supports D1 D2
[ 0.335229] pci 0000:01:00.0: PME# supported from D0 D1 D3hot D3cold
[ 0.335593] PCI: bus1: Fast back to back transfers disabled
[ 0.335746] pci 0000:00:00.0: BAR 8: assigned [mem 0x48000000-0x487fffff]
[ 0.335774] pci 0000:00:00.0: BAR 0: assigned [mem 0x48800000-0x48800fff]
[ 0.335805] pci 0000:01:00.0: BAR 0: assigned [mem 0x48000000-0x487fffff]
[ 0.335840] pci 0000:00:00.0: PCI bridge to [bus 01]
[ 0.335863] pci 0000:00:00.0: bridge window [mem 0x48000000-0x487fffff]
OpenWRT working:
[ 0.339504] qcom-pcie 40000000.pci: link up
[ 0.339656] qcom-pcie 40000000.pci: PCI host bridge to bus 0000:00
[ 0.339677] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 0.339693] pci_bus 0000:00: root bus resource [io 0x0000-0xfffff]
(bus address [0x40200000-0x402fffff])
[ 0.339706] pci_bus 0000:00: root bus resource [mem
0x48000000-0x57ffffff]
[ 0.340029] PCI: bus0: Fast back to back transfers disabled
[ 0.341058] PCI: bus1: Fast back to back transfers disabled
[ 0.341108] pci 0000:00:00.0: BAR 8: assigned [mem 0x48000000-0x487fffff]
[ 0.341126] pci 0000:00:00.0: BAR 0: assigned [mem
0x48800000-0x48800fff 64bit]
[ 0.341150] pci 0000:01:00.0: BAR 0: assigned [mem 0x48000000-0x487fffff]
[ 0.341179] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
[ 0.341194] pci 0000:00:00.0: bridge window [mem 0x48000000-0x487fffff]
> Because the fix (bigger area) should definitely be sent upstream.
>
> As for adding the pcie node: please do. I think it's fine to have
> it, even if the driver for the VDSL chip isn't working.
Okay, will do so.
If anyone is interested: there are some resources for the modem chip
here, but they originate from a GRX350 UGW, so it's most likely platform
specific:
https://github.com/blocktrron/vrx518-pcie
https://github.com/blocktrron/vrx518-mei
https://github.com/blocktrron/vrx518-dsl-cpe-api
>>>> 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.
> Oh ok. "Good to know". I guess this would then also require I2S support...
> which is non-existent at the moment.
>
>>>> 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.
> K. Keep it as is then (just move it)
>
>>>> 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>
>>>> +
>>>> +/ {
>
> I just remembered that the rng-node was missing in the soc-subnode.
> Robert Marko discovered this while porting the 4.19. We didn't add
> it for the 4.14 because the qcom rng driver only registers with a
> crypto_rng device. While this is still useful (stdrng), it is not
> a true random number generator.
>
> But nevertheless: can you please add:
>
> rng at 22000 {
> status = "okay";
> };
>
> to 4.19's dts?
Will do.
>>>> 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
>
> Oh, boy. Well, this is a bit of a pickle. But for other reasons than you might
> think...
Could you explain why it is? :)
Best wishes
David
> Thanks,
> Christian
>
> [0] <https://www.openfirmware.info/data/docs/bus.pci.pdf>
>
>
>
_______________________________________________
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