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> >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). 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. > >> 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@22000 { status = "okay"; }; to 4.19's dts? > >> 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... Thanks, Christian [0] <https://www.openfirmware.info/data/docs/bus.pci.pdf> _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
