Adding support for VRX518 (and maybe VRX320)

varda · November 26, 2021, 10:22am

openwrt pppoe avm 7520 with error .. I used debug values in the function dc_ep_clk_on function (misc.c).

type or past10.487095] urandom-seed: Seeding with /etc/urandom.seed
[   10.585818] procd: - early -
[   10.586298] procd: - watchdog -
[   11.176387] procd: - watchdog -
[   11.421473] procd: - ubus -
[   11.481481] procd: - init -
[   12.031362] kmodloader: loading kernel modules from /etc/modules.d/*
[   12.065028] IFXOS, Version 1.6.9 (c) Copyright 2009, Lantiq Deutschland GmbH
[   12.066646] vrx518: Intel(R) SmartPHY DSL(VRX518) PCIe EP/ACA Driver - version 2.1.0-k
[   12.071195] vrx518: Copyright (c) 2016 Intel Corporation.
[   12.079041] vrx518 0000:01:00.0: enabling device (0140 -> 0142)
[   12.087412] NET: Registered protocol family 8
[   12.090174] NET: Registered protocol family 20
[   12.100517] vrx518_tc:pcie_ep_probe: Total 1 VRX518 EP detected
[   12.119502] urngd: v1.0.2 started.
[   13.316268] vrx518 0000:01:00.0: 0 guenter retry 
[   13.316299] vrx518 0000:01:00.0: 400000 guenter bits 
[   13.319964] vrx518 0000:01:00.0: c00004 guenter rd32 
[   13.324983] vrx518 0000:01:00.0: 11c guenter PMU_PWDCR 
[   13.330029] vrx518 0000:01:00.0: 120 guenter PMU_SR 
[   13.335051] vrx518 0000:01:00.0: dc_ep_clk_on failed
[   13.387915] MD5 checksum pass!!!
[   13.387962] Firmware pointer id(0):size(10608), fw addr(25ce3054), off(100)
[   13.390260] Firmware pointer id(1):size(19376), fw addr(a0153d0b), off(10708)
[   13.396904] Firmware pointer id(2):size(11368), fw addr(fe56eded), off(30084)
[   13.404282] Firmware pointer id(3):size(21244), fw addr(5476770a), off(41452)
[   13.411355] VRX518 PPE Firmware header info
[   13.418440] 	PTM Version: 3.5.72
[   13.422459] 	PTM Feature: A0000000
[   13.425903] 	ATM Version: 3.5.36
[   13.429111] 	ATM Feature: B0000000
[   13.432511] 	Compability ID: 00000004
[   13.435696] 	Size: 00000010
[   13.439428] 	FW built Date: 9-25-2018
[   13.442049] 	Number of firmware: 4
[   13.445857] 		Firmware[0]: ID[0] size[2652] at[0x25ce3054]
[   13.449156] 		Firmware[1]: ID[1] size[4844] at[0xa0153d0b]
[   13.454640] 		Firmware[2]: ID[2] size[2842] at[0xfe56eded]
[   13.460107] 		Firmware[3]: ID[3] size[5311] at[0x5476770a]
[   13.465653] vrx518_tc:tc_drv_init: Intel(R) SmartPHY DSL(VRX518) PCIe TC Driver - version 1.5.12
[   13.471056] vrx518_tc:tc_drv_init: Copyright (c) 2018 Intel Corporation.
[   13.484025] NET: Registered protocol family 15
[   13.488852] Initializing XFRM netlink socket
[   13.493017] tun: Universal TUN/TAP device driver, 1.6
[   13.519692] Lantiq (VRX) DSL CPE MEI driver, version 1.9.3, (c) 2007-2016 Lantiq Deutschland GmbH
[   13.520052] Found 1 PCI VRX devices, 
[   13.532520] 
[   13.532520] 
[   13.532520] Lantiq CPE API Driver version: DSL CPE API V4.21.3
[   13.532560] 
[   13.532560] e code here

openwrt pppoe avm 7530 ok

t9.314724] random: ubusd: uninitialized urandom read (4 bytes read)
[    9.324690] procd: - init -
[    9.676971] kmodloader: loading kernel modules from /etc/modules.d/*
[    9.692484] IFXOS, Version 1.6.9 (c) Copyright 2009, Lantiq Deutschland GmbH
[    9.693958] vrx518: Intel(R) SmartPHY DSL(VRX518) PCIe EP/ACA Driver - version 2.1.0-k
[    9.698605] vrx518: Copyright (c) 2016 Intel Corporation.
[    9.706553] vrx518 0000:01:00.0: enabling device (0140 -> 0142)
[    9.714694] NET: Registered protocol family 8
[    9.717526] NET: Registered protocol family 20
[    9.724728] urngd: v1.0.2 started.
[    9.725921] vrx518_tc:pcie_ep_probe: Total 1 VRX518 EP detected
[    9.729830] vrx518 0000:01:00.0: 999999 guen retry 
[    9.735583] vrx518 0000:01:00.0: 400000 guenter bits 
[    9.740903] vrx518 0000:01:00.0: 800004 guenter rd32 
[    9.745912] vrx518 0000:01:00.0: 11c guenter PMU_PWDCR 
[    9.750975] vrx518 0000:01:00.0: 120 guenter PMU_SR 
[    9.760652] MD5 checksum pass!!!
[    9.761197] Firmware pointer id(0):size(10608), fw addr((ptrval)), off(100)
[    9.764403] Firmware pointer id(1):size(19376), fw addr((ptrval)), off(10708)
[    9.771138] Firmware pointer id(2):size(11368), fw addr((ptrval)), off(30084)
[    9.778379] Firmware pointer id(3):size(21244), fw addr((ptrval)), off(41452)
[    9.785541] VRX518 PPE Firmware header info
[    9.792659] 	PTM Version: 3.5.72
[    9.796611] 	PTM Feature: A0000000
[    9.800133] 	ATM Version: 3.5.36
[    9.803295] 	ATM Feature: B0000000
[    9.806680] 	Compability ID: 00000004
[    9.809895] 	Size: 00000010
[    9.813614] 	FW built Date: 9-25-2018
[    9.816217] 	Number of firmware: 4
[    9.820059] 		Firmware[0]: ID[0] size[2652] at[0x(ptrval)]
[

dmesg with orginal Firma avm + freetz dmesg 7520 Box .. pppoe possible !!

20.707486] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
[   20.707567] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 1
[   20.712195] xhci-hcd xhci-hcd.0.auto: hcc params 0x0228f665 hci version 0x100 quirks 0x00010010
[   20.719566] xhci-hcd xhci-hcd.0.auto: irq 242, io mem 0x08a00000
[   20.728382] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[   20.734401] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   20.741090] usb usb1: Product: xHCI Host Controller
[   20.748196] usb usb1: Manufacturer: Linux 4.4.60 xhci-hcd
[   20.752956] usb usb1: SerialNumber: xhci-hcd.0.auto
[   20.759532] hub 1-0:1.0: USB hub found
[   20.763272] hub 1-0:1.0: 1 port detected
[   20.767613] avm_net_trace: New net trace device 'usb1' registered with minor 161.
[   20.771319] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
[   20.778575] avm_net_trace: udev device avm_net_trace161 created
[   20.778681] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 2
[   20.785075] xHCI: delay VBUS POWER on for 50 ms
[   20.791559] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
[   20.796183] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
[   20.804284] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   20.811065] usb usb2: Product: xHCI Host Controller
[   20.818102] usb usb2: Manufacturer: Linux 4.4.60 xhci-hcd
[   20.822947] usb usb2: SerialNumber: xhci-hcd.0.auto
[   20.830741] hub 2-0:1.0: USB hub found
[   20.833164] hub 2-0:1.0: 1 port detected
[   20.837229] AVM: disable USB3 bus#2 port#0 config=0
[   20.843442] xHCI: delayed VBUS POWER on
[   20.844121] avm_net_trace: New net trace device 'usb2' registered with minor 162.
[   20.844638] avm_net_trace: udev device avm_net_trace162 created
[   21.951003] vrx518: Intel(R) SmartPHY DSL(VRX518) PCIe EP/ACA Driver - version 2.1.0-k
[   21.951053] vrx518: Copyright (c) 2016 Intel Corporation.
[   21.958645] vrx518 0000:01:00.0: enabling device (0140 -> 0142)
[   22.016988] vrx518_tc: Total 1 VRX518 EP detected
[   22.017021] Function platform_init called
[   22.017059] tx.virt = d0826000 tx.phys = 8fa10000
[   22.020651] rxout.virt = d082e000 rxout.phys = 8fa18000
[   22.024742] Function plat_tc_ops_setup called
[   22.029749] Function ppa_callback_set called
[   22.034285] Function ppa_callback_set called
[   22.038610] Function ppa_callback_set called
[   22.042862] Function ppa_callback_set called
[   22.065974] Firmware pointer id(0):size(10476), fw addr(d22b3064), off(100)
[   22.066007] Firmware pointer id(1):size(18176), fw addr(d22b5950), off(10576)
[   22.066027] Firmware pointer id(2):size(11296), fw addr(d22ba050), off(28752)
[   22.066046] Firmware pointer id(3):size(21220), fw addr(d22bcc70), off(40048)
[   22.066063] VRX518 PPE Firmware header info
[   22.066080] 	PTM Version: 3.5.66
[   22.066097] 	PTM Feature: A0000000
[   22.066114] 	ATM Version: 3.5.33
[   22.066130] 	ATM Feature: B0000000
[   22.066147] 	Compability ID: 00000004
[   22.066162] 	Size: 00000010
[   22.066180] 	FW built Date: 8-2-2017
[   22.066196] 	Number of firmware: 4
[   22.066215] 		Firmware[0]: ID[0] size[2619] at[0xd22b3064]
[   22.066234] 		Firmware[1]: ID[1] size[4544] at[0xd22b5950]
[   22.066252] 		Firmware[2]: ID[2] size[2824] at[0xd22ba050]
[   22.066271] 		Firmware[3]: ID[3] size[5305] at[0xd22bcc70]
[   22.066394] vrx518_tc: Intel(R) SmartPHY DSL(VRX518) PCIe TC Driver - version 1.5.0
[   22.066432] vrx518_tc: Copyright (c) 2016 Intel Corporation.
[   22.081995] Function simu_tc_request called
[   22.082767] Function plat_tc_request called
[   22.086872] Function plat_tc_req_workqueue called
[   22.092545] vrx518_tc: [setup_avm_pa_ptm_dev] dev ptm0
[   22.121395] Loading PTM FW ver: 3.5.66
[   22.124059] PP32(0): fw mem data: 0x80000900 != original 0x90080 @0x304000
[   22.127283] PP32(1): fw mem data: 0x80000920 != original 0x20090080 @0x344000
[   22.132982] PP32(2): fw mem data: 0x80001000 != original 0x100080 @0x384000
[   22.138405] vrx518_tc: ptm_tc_hw_fw_init: Try to set PPE TC mode
[   22.144961] vrx518_tc: PTM TC init successfully
[   22.151172] Function plat_umt_init called
[   22.155405] plat_umt_init:479 umt mapping at d1ad00c8(480500c8)
[   22.159602] Function plat_soc_cfg_get called
[   22.169262] Lantiq (VRX) DSL CPE MEI driver, version 1.6.13.2-pd2, (c) 2007-2016 Lantiq Deutschland GmbH
[   22.170800] Found 1 PCI VRX devices,

janh · November 26, 2021, 11:46pm

So that looks like the drivers in the AVM firmware do something differently which makes it work. Unfortunately, I have no idea what exactly the issue could be. The failing call to dc_ep_clk_on happens very early in the initialization of the TC driver, and before that it only does a few other calls into the EP driver, so maybe the issue is somewhere in that one, but that is just a rough guess.

francisuk1989 · November 27, 2021, 9:08am

If your on a TalkTalk or there wholesale backhaul then 6db is normal however if you see anything like 9/12db then you have issues, However im on Zen what uses the BT wholesale backhal what uses 3db profile for SNR howecver they take an % of the attainable data rate (ATTNDR) cant remember what % is it but at a guess is 80% depending on profile.

Would advise your get a cat5 or cat6e twisted pair as the 7530 take a rj45 for the xDSL port and then you need the rj11 for the telephone socket for VDSL2 line.however it may not increase your connection speed but it will be more reliable than a cheap flat modem cable with less noise!

francisuk1989 · November 27, 2021, 12:30pm

Link down, can you reupload a sysupgrade.bin ? Thanks @mm933 mm933
https://transfer.sh this might be a better host?

mm933 · November 27, 2021, 1:02pm

https://transfer.sh/kX8YFy/openwrt-ipq40xx-generic-avm_fritzbox-7530-squashfs-sysupgrade.bin

francisuk1989 · November 27, 2021, 5:59pm

Thanks very much @mm933

If you or anyone experiencing high pings then normal, This also happens on 21.02.1 stable version also.so there nothing worng with the DSL FW

but fixed it by ...

Login into SSH @ 192.168.1.1 and then copy and paste this

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor

now ping 192.168.1.1 and you should see 0.03ms or something like so, <1ms if on Windows.

root@FB750:~# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: seq=0 ttl=128 time=0.589 ms
64 bytes from 192.168.1.1: seq=1 ttl=128 time=0.513 ms

Compared to

root@FB750:~# ping 192.168.1.1
PING 192.168.1.1 (92.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: seq=1 ttl=128 time=2.152 ms
64 bytes from 192.168.1.1: seq=2 ttl=128 time=2.193 ms

And for permanent solution without resetting you DSL line, Go to OpenWrt GUI @ 192.168.1.1
system > startup > Local Startup

paste in the commands above and the save & apply, so next time yo restart the router, the changes are there.

@mm933 might be an idea when your next compiling openwrt with FRITZBox 7530, edit /etc/rc.local file with this.

Last .... Keep in mind there is a FB 7530 AX what runs on broadcom BCM6303 DSL chipset so BEWARE!!!

francisuk1989 · December 3, 2021, 3:06pm

@janh
I installed this on my FB7530 however is it normal for the "Forward Error Correction Seconds (FECS)" to keep going up every second? If i remember correctly it was something like 3XX / 777751 when the uptime is 15 minutes.
Chipset is a broadcam 12.3.16 on DSLAM

However my line re-synced today at early hours in the morning and have noticed that my attainable throughput upstream/upload speed has been synced to 21502kbit/s from about 17xxxkbit/s odd via DSL version 1.180.131.76 on the FB 7530 itself. So with the FECS that kept going up, I don't know if is a good thing or bad thing, whats your thoughts? it is normal?

janh · December 3, 2021, 10:21pm

FECS should increase by 1 for every second that has at least one error corrected by forward error correction. This kind of errors doesn't have any noticeable impact, as they are transparently corrected. DLM may take these into consideration, though. Any actual errors that lead to packet loss would be counted as CRC or as RTX-UC (rx_uncorrected_protected) if G.INP is enabled.

Unfortunately, the data available via ubus/LuCI is missing some error counters. To get FEC (nFEC) and CRC (nCodeViolations) counters you can use the following commands:

# dsl_cpe_pipe.sh pmlscsg 0 0 # near end (downstream)
# dsl_cpe_pipe.sh pmlscsg 1 0 # far end (upstream)

These commands are for showtime counters, i.e. only errors since the last synchronization should be included (ubus/LuCI reports total values).

Is it the attainable rate or the actual rate which increased? Such an increase in the attainable rate would seem a bit strange, but if it is the actual rate, this could be due to DLM.

francisuk1989 · December 4, 2021, 4:44pm

Both attainable and actual have gone up from about 17 odd kbits to now 21502 however i was unsure about the Forward Error Correction Seconds (FECS) as this kept going up every second so wasn't sure if to keep the openwrt fritzbox on or take it off because of the FECS errors.

Looking at @gsum post status

@gsum is lower then mine, same profile 17a etc however In 15 minutes mine had gone 304 but @gsum only has 321 over 2 hours of uptime.

Will have to switch it back but abit worried about the Errors has my local DSLAM likes to add interleaving (adding more latency) and lowering back the speeds.

janh · December 4, 2021, 7:13pm

Maybe some parameters were changed, like increased transmit power (ACTATP), changed interleaving parameters (which could reduce the overhead), or a lower minimum SNR margin. All of these could be changed by DLM (and this should also be visible in the stats from the modem, if not via ubus/LuCI then through dsl_cpe_pipe.sh). Of course, it's also possible that the SNR just changed for some reason, but in that case one would expect that it doesn't take a resync for the attainable rate to increase.

Keep in mind that the counters that are reported via ubus and in LuCI are total counters, and those are not related to the line uptime. For downstream, these counters include all errors since the device was last started, and for upstream they contain all errors since the last reboot of the DSLAM.

I have now idea about the DLM behaviour in the UK, so you have to make your own decision here.

I don't know which DSL firmware you are currently using, but if it isn't the one extracted from the AVM device firmware, you could try that one.

francisuk1989 · December 10, 2021, 12:54pm

Your right, the 7530-07.29.image given me hardly no FECS errors compared to the default one, and just renamed and replaced with vdsl.bin into /lib/firmware

Thanks for that

OpenWrt SNAPSHOT r17784
Kernel Version 5.4.152


root@7530:~# /etc/init.d/dsl_control dslstat
	"api_version": "4.21.3",
	"firmware_version": "8.13.1.10.1.7",
	"chipset": "Lantiq-VRX500",
	"driver_version": "1.9.3",

dhewg · December 15, 2021, 9:26am

Nice work, I'm currently running this on a 7520, and so far it looks good!

Is there a reason avoid renaming the devices as seen on lantiq (ptm0 -> dsl0, dsl_cpe_api/0 -> dsl_cpe_api0)?

With that we could add stuff like:
ucidef_set_interface_wan "dsl0" "pppoe"
wan_mac=$(/usr/bin/fritz_tffs_nand -d $(find_mtd_part "nand-tffs") -n macdsl -b)

See also:
b02b7004 "lantiq: xway: rename nas0/ptm0 to dsl0"
d3fd3863 "lantiq: create ATM/PTM interfaces with dsl as netdev name"
23c3aa99 "add vdsl userland app" (unfortunately without reason for the dev rename)

Btw, don't we need to add the mac for vectoring error reports here too?

janh · December 15, 2021, 3:23pm

I don't know of any reason against that. My own work has been focused on getting this to work at all so far. Obviously, there is still lots of cleanup needed (which includes consistent device names, and setting up the WAN interface including MAC address).

Yes, the MAC address needs to be set according to the vectoring specification. It probably doesn't really matter in practice though (at least during my early tests on VR9 the missing MAC address didn't seem to matter at all). So I think this can wait until the cleanup is done at some point.

Ansuel · December 15, 2021, 3:36pm

It could... Wonder what happen if for example on the same dslam we have 2 modem that provide the same mac address. If the stats are handled based on the mac address, that can results in vectoring done wrong.

janh · December 15, 2021, 4:01pm

The ERBs also contain a Line ID field, so I would hope that the DSLAM uses that to identify the modem.

But I'm not saying this shouldn't be fixed, I just don't want to do any extra work before the cleanup that is needed anyway. And I would also like to get the VR9 vectoring fix merged before this, and that includes the code to set the MAC address (as long as it is configured properly).

wilsonyan · December 16, 2021, 1:47am

Login into SSH @ 192.168.1.1 and then copy and paste this

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor

Another option is to increase the minimum scaling frequency.

cat /sys/bus/cpu/devices/cpu0/cpufreq/scaling_available_frequencies

then go up in frequencies until you get the desired result eg

echo 500000 > /sys/bus/cpu/devices/cpu0/cpufreq/scaling_min_freq

That way you can still run ondemand and not just @ maxed out all the time

I can confirm that the vrx518 branch is stable, DSL connectiion is staying up as long as I leave it and i've left it for at least 4 weeks in the past. I'm no expert so i'm not sure if anything is geting lost of those spurious interrupt messages to the kernel log but other than that and being unable to reload the DSL process it's pretty great.

Other off topic stuff i'm noticing with opwrt lately:

can't seem to compile with glibc because procd doesn't generate the proper syscall file on ARM platform, seems to be ok on mips but not ARM
seems like some ncurses aps like iptraf-ng can segfault but it might be because of some terminal setting on my client

dhewg · December 16, 2021, 5:14pm

I fixed some minor issues, fixup patches for your tree:
http://sprunge.us/1FXu0V
http://sprunge.us/bdUiKo
http://sprunge.us/eCc79J
http://sprunge.us/CfO3uO
http://sprunge.us/cST4rv

That includes the ptm0 -> dsl0 rename with the mentioned additions. And your patch "ltq-vdsl-app: set MAC address for vectoring error reports" works as-is

Maybe the different ltq-vdsl-mei and ltq-vdsl-app versions should get their own directory, currently there's the same version in tmp/.packageinfo.
And I can't build a xrx200 target with this tree, it's trying to build package/kernel/intel/vrx518_tc?

dhewg · December 16, 2021, 5:18pm

About the dsl_cpe_api/0 -> dsl_cpe_api0 rename... I guess the other way around would be cleaner: Go with that default for vr9 instead.

Can someone on lantiq confirm this still works? ping @jekkos or @moeller0
http://sprunge.us/yKdxFu

dhewg · December 17, 2021, 5:51pm

Both points are intertwined. Dunno if there's a way, but I didn't find any to make the tree buildable for both archs without splitting the package. With vr9/vr11 living as their own dir/package it works just fine.

And as already mentioned, I've added support for the fritzbox 7520. That is, an unmodified one, so without changing EVA bootloaders vars to force flash a 7530 vendor firmware.
That seems to be rather stable so far! As far as OpenWrt is concerned, the 7520 1&1 branding is completely irrelevant. The box works exactly the same, the artificial limitations are not present or lifted [0] [1].

Probably the most attractive point is the price. Compared to the 7530 that box is available rather cheap - I got a used one for €40. It's not exactly new hardware, but way newer than those ancient lantiq boxes

[0] https://github.com/chunkeey/FritzBox-4040-UBOOT/pull/6#issuecomment-993494537
[1] https://github.com/openwrt/openwrt/pull/4721#issuecomment-996709101

janh · December 17, 2021, 8:54pm

Yes, I think creating separate packages for VR11 based on the latest driver versions (i.e. the ones I experimented with here, just without the VR9 hacks) is probably the best solution. I don't like that this would also duplicate the ubus code, but it doesn't look like there's a way around that.