Adding support for VRX518 (and maybe VRX320)

FRITZBox 7530-07.50 version wil give you firmware 8.13.1.5.0.7

Sorry, I didnt mean i swapped from a openwrt bt homehub 5 as i mean i swapped a bt homehub 6 that was on BT's Firmware

Same, UK Huawei cabinets are on Broadcom only diffrent between is that you have

Line Mode	G.993.2 (VDSL2, Profile 17a, with down- and upstream vectoring)

It looks like we dont have vectoring here?

    "annex": "B",
    "standard": "G.993.2",
    "profile": "17a",
    "mode": "G.993.2 (VDSL2, Profile 17a)",
    "upstream": {
            "vector": false,
            "trellis": true,
            "bitswap": true,
            "retx": false,
            "virtual_noise": false,
            "ra_mode": "At initialization",
            "ra_mode_num": 1,
            "interleave_delay": 0,
            "inp": 0.000000,
            "data_rate": 19715000,
            "latn": 22.700000,
            "satn": 22.700000,
            "snr": 5.700000,
            "actatp": 7.400000,
            "attndr": 19715000
    },
    "downstream": {
            "vector": false,
            "trellis": true,
            "bitswap": true,
            "retx": true,
            "virtual_noise": false,
            "ra_mode": "At initialization",
            "ra_mode_num": 1,
            "interleave_delay": 220,
            "inp": 39.000000,
            "data_rate": 69408000,
            "latn": 19.500000,
            "satn": 19.500000,
            "snr": 2.900000,
            "actatp": 12.500000,
            "attndr": 69350240,
            "mineftr": 66007000

Ah, I did not get that... in my case I am close to full sync anyway (the upstream is limited a bit but that is likely because the transmit power is minimized).

Likely, I seem to recall that BT started the VDSL2 deployment a bit earlier than Telekom and used the then available (and affordable) technology, Telekom started the mass roll-out a bit later when vectoring was a real option, it also allowed to offer plans with the magic 100 Mbps download figure to not loose out too badly against docsis-cabe ISPs that offered tripple digit download rates... so I guess different timing and competitive environments are responsible for that difference*.

Side-note: G.fast is a heavy user of vectoring technology, but G.fast so far has seen little delpoyment in Germany (partly because the incumbent had already started to deploy vectoring on vdsl2 and probably wanted to amortize that investment before increasing the speed, but by now they are busy deploying FTTH/GPON instead, and G.fast is just treated as a way of in-house distribution for FTTH if the house owner does/can not exchange the old POTs wiring with something FTTH compatible, but I digress).

*) Vectoring is also incompatible with physical local line unbundling and allowed the incumbent to re-gain control over most last mile links again (they have to offer bitstream access to competitors, but there is essentially no competitor that could offer better technology over the same lines**).

**) That is not 100% correct, but effectively nobody can offer economically sane alternative technology over the same lines...

1 Like

been messing around with my stuff, it seems the fritz 7530 is pretty sensitive to the power input you use
if you feed it less power, it will actually boot up and work but sync lower and constantly experience fec (latest dsl blob firmware 8.13) errors or dtu retransmit (old dsl blob firmware 8.11) errors
i'm not sure if it matters if you stick to the original power brick but it seems like with some power delivery it may help the sync/error rate if you sandwich the power cord going into the modem between two shungite tiles, I seem to have gotten a few more megabits in my sync rate

DSL stats
Connection State
Line State	Showtime with TC-Layer sync
Line Mode	G.993.2 (VDSL2, Profile 17a, with down- and upstream vectoring)
Line Uptime	23h 29m 38s
Annex	B
Power Management Mode	L0 - Synchronized
Inventory
Modem Chipset	Lantiq-VRX500
Modem Firmware	8.13.1.12.1.7
xTU-C Vendor ID	Broadcom 178.33
Line Details
Data Rates
Actual Data Rate	114.747 Mb/s	40.505 Mb/s
Attainable Data Rate (ATTNDR)	121.320 Mb/s	41.861 Mb/s
Minimum Error-Free Throughput (MINEFTR)	113.137 Mb/s	40.342 Mb/s
On-line Reconfiguration
Bitswap	on	on
Rate Adaptation Mode	Dynamic with SOS	Dynamic with SOS
Noise Protection
Latency	0.14 ms	0.00 ms
Impulse Noise Protection (INP)	40.0 symbols	37.0 symbols
Retransmission (G.INP)	on	on
Line Parameters
Line Attenuation (LATN)	12.4 dB	13.8 dB
Signal Attenuation (SATN)	12.4 dB	14.1 dB
Noise Margin (SNRM)	7.7 dB	7.7 dB
Aggregate Transmit Power (ACTATP)	13.3 dB	1.6 dB
Error Counters
Error Seconds
Forward Error Correction Seconds (FECS)	2343	50367
Errored Seconds (ES)	0	122
Severely Errored Seconds (SES)	0	19
Loss of Signal Seconds (LOSS)	0	0
Unavailable Seconds (UAS)	224	224
Seconds with Low Error-Free Throughput (LEFTRS)	0	650
Channel Counters
CRC Errors (CV-C)	0	342
Corrected by FEC (FEC-C)	4052	2157506
Data Path Counters
ATM Header Error Code Errors (HEC-P)	0	0
PTM Non Pre-emptive CRC Errors (CRC-P)	10	0
PTM Pre-emptive CRC Errors (CRCP-P)	0	0
Retransmission Counters
Retransmitted DTUs (rtx-tx)	398065	539
Corrected DTUs (rtx-c)	308	94829
Uncorrected DTUs (rtx-uc)	0	3452154

DSL modem typically are sensitive to the cleanliness of their DC power input. When I fed my old BT HomeHub5A fro a POA injector and (cheap) POE-power-splitter I saw massive noise artifacts in the spectra and a massively lower sync rate... so bad in fact the modem started loosing the sync quite often so I ended that specific experiment rather quickly.
With "underpower" what I would expect is that the modem (assuming it actually boots up fully) would work under low load conditions, butmight start to flake out (loose sync or randomly reboot) if stressed a bit more.

updated my build, added dashboard , kernel 5.15.111 (stable-rc queue as of today), gcc 13, lto turned on, latest glibc, fw4 masq random, janhs pcie magic patch, xhci ring expansion etc

Dear @janh - do you know if the PCIe magic patch or an alternative has been upstreamed already? If not, is there anything a mere user can do to help? I'd like to move to official images at some point :slight_smile:

No, the status of that patch is unchanged.

Guys, I'm having trouble compiling the latest firmware for the 7530 with the modem drivers and the LUCI interface.
Could someone share their compiled firmware?
Thank you.

You can download a snapshot image and install LuCI immediately, is that no viable option? The firmware for the modem needs to be manually uploaded anyway.

my build
here: openwrt-ipq40xx-generic-avm_fritzbox-7530-squashfs-sysupgrade.bin

whole bin/ folder for what it's worth
fritz7530

I wasn't sure but I made a few changes as well as updating this time, I switched the crc32 algo to 4 bytes as it seems to be a bit faster in the little benchmark at the start

I'm also not quite sure about which wireless driver to use, this one is using the ath10k-ct driver with ct firmware, you lose mesh support (which is an easy way to bridge networks wirelessly) but I personally experienced some kind of regression in speed using the normal driver and firmware, not confirmed on this device though, but on an ipq806x/qca99x0, so i'm not sure, I know the 4019 is different than other chipsets and it has proper reported tx speeds even if you use the default driver and firmware unlike the ipq806x/qca99x0

If you are wondering why DSL doesn't work straight away with this build see here you can also use other blobs if you want checkout the vrx500 section from here

One other thing, you're probably going to want to delete the default watchcat entry in the web interface so it doesnt send pings out, I should probably just remove watchcat altogether since I never get around to doing anything with it anyway

updated again, added SQM QoS

the following is a patch for the modem driver to compile with glibc
it's no big deal I pretty much just copied the patch for the vr9 driver to vr11

diff --git a/package/kernel/lantiq/ltq-vdsl-vr11-mei/patches/030-no-static-linking.patch b/package/kernel/lantiq/ltq-vdsl-vr11-mei/patches/030-no-static-linking.patch
new file mode 100644
index 0000000000..462f806621
--- /dev/null
+++ b/package/kernel/lantiq/ltq-vdsl-vr11-mei/patches/030-no-static-linking.patch
@@ -0,0 +1,44 @@
+diff --git a/src/Makefile.am b/src/Makefile.am
+index 141973f..0b12d43 100644
+--- a/src/Makefile.am
++++ b/src/Makefile.am
+@@ -198,10 +198,10 @@ AM_CFLAGS = -Wall -Wimplicit -Wunused -Wswitch -Wcomment \
+ 
+ if IFXOS_ENABLE
+ AM_LDFLAGS= \
+-      -Bstatic -dn -static @IFXOS_LIBRARY_PATH@
++      -Bstatic -dn @IFXOS_LIBRARY_PATH@
+ else
+ AM_LDFLAGS= \
+-      -Bstatic -dn -static
++      -Bstatic -dn
+ endif
+ 
+ #
+@@ -303,7 +303,7 @@ mei_cpe_appl_ldflags= $(ADD_APPL_LDFLAGS)
+ else
+ if TARGET_ADM5120_MIPSEL
+ mei_cpe_appl_cflags =  -O1 -g
+-mei_cpe_appl_ldflags = -static
++mei_cpe_appl_ldflags =
+ else
+ mei_cpe_appl_cflags =  -DPPC
+ endif
+@@ -336,7 +336,7 @@ endif
+ mei_cpe_drv_test_CFLAGS = $(mei_cpe_app_common_cflags) \
+                               $(mei_cpe_appl_cflags) $(MEI_DRV_TARGET_OPTIONS)
+ 
+-mei_cpe_drv_test_LDFLAGS = $(mei_cpe_appl_ldflags) -Bstatic -dn -static @IFXOS_LIBRARY_PATH@ \
++mei_cpe_drv_test_LDFLAGS = $(mei_cpe_appl_ldflags) -Bstatic -dn @IFXOS_LIBRARY_PATH@ \
+                                                       $(dsl_cpe_mei_LDFLAGS)
+ 
+ mei_cpe_drv_test_LDADD = -lifxos $(dsl_cpe_mei_LDADD)
+@@ -357,7 +357,7 @@ endif
+ 
+ mei_cpe_drv_dbg_strm_dmp_CFLAGS = $(mei_cpe_app_common_cflags) \
+                               $(mei_cpe_appl_cflags) $(MEI_DRV_TARGET_OPTIONS)
+-mei_cpe_drv_dbg_strm_dmp_LDFLAGS = $(mei_cpe_appl_ldflags) -Bstatic -dn -static @IFXOS_LIBRARY_PATH@ \
++mei_cpe_drv_dbg_strm_dmp_LDFLAGS = $(mei_cpe_appl_ldflags) -Bstatic -dn @IFXOS_LIBRARY_PATH@ \
+                                                                       $(dsl_cpe_mei_LDFLAGS)
+ mei_cpe_drv_dbg_strm_dmp_LDADD = -lifxos $(dsl_cpe_mei_LDADD)
+ 

Got the permissions on the irq affinity wrong. I've fixed the image now or you can ssh onto the modem and run "chmod +x /etc/init.d/set-irq-affinity" and then run "/etc/init.d/set-irq-affinity start" or reboot

Your patch works great. I spent a lot of time realizing that this is the problem, finally I found your patch. Why isn't this patch merged with the Openwrt master branch?

updated build again, trying out the normal ath10k driver and added dns over https support

Thank you so much for your patch! I was pulling my hair trying to figure out why the pppoe on one of my 7530 boxes failed. This fixes the issue, and the kernel error does no longer appear. Really hoping this fix can be merged. Great work!

Still ask myself why the patch won't get merged...

Did you got more info here?

No, nothing for vrx310 (vr10) as far as I'm aware. Just relegated my HH5 to a modem only (which prepares for FTTP in the future) in combination with a more powerful router instead.

well there is this thread

which is a bit of an interesting read, i'm not sure how you should feel after reading it
how you should feel about buying computer hardware, what it means etc

I realise to some degree it's bait
However, you don't see support for the hardware materialize either /shrug

Hello, dsl status does not show such detailed information for me. What should I do to see detailed information like in this screenshot? I am using Openwrt snaphshot version.