No subject

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 at 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 at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel