Adding support for VRX518 (and maybe VRX320)

I think you need to install luci-mod-dsl. In the past the status->overview contained a verbose list just as the one you linked to, but some time ago this DSL information in the overview page was slimmed down considerably, but luci-mod-dsl now offers more detailed information under Status->DSL Status, with one tab with textual information and one tab with SNR, bitloading, Hlog, and QLN spectra. That is pretty sweet!

2 Likes

Thanks, I installed the luci-mod-dsl package. I can see detailed information.


1 Like

And even better, have a look at
http://192.168.1.1/cgi-bin/luci/admin/status/dsl/spectrum
for a visual display of the per frequency bin information. :wink:

1 Like

Greetings esteemed colleagues.

I'm not sure if this is significant however, I have just "attended-sysupgrade" to most recent snapshot. Kernel is now 6.1.55 (IIRC it was 5.15.132 on previous snapshot from about 2 weeks ago that I was running before). I get the following kernel stack trace/dump, though the router appears to work fine.

Model AVM FRITZ!Box 7530
Architecture ARMv7 Processor rev 5 (v7l)
Target Platform ipq40xx/generic
Firmware Version OpenWrt SNAPSHOT r24072-a181b9f0f9 / LuCI Master git-23.266.27574-7744ad0
Kernel Version 6.1.55

DSL stats

Connection State

Line State Showtime with TC-Layer sync
Line Mode G.993.2 (VDSL2, Profile 17a)
Line Uptime 2h 23m 46s
Annex B
Power Management Mode L0 - Synchronized

Inventory

Modem Chipset Lantiq-VRX500
Modem Firmware 8.13.1.5.0.7
xTU-C Vendor ID Infineon 178.6
[   71.520638] br-lan: port 6(phy1-ap0) entered forwarding state
[  100.500043] ath10k_ahb a800000.wifi: mac flush vdev 0 drop 0 queues 0x1 ar->paused: 0x0  arvif->paused: 0x0
[  101.568830] ath10k_ahb a800000.wifi: mac flush vdev 0 drop 0 queues 0x1 ar->paused: 0x0  arvif->paused: 0x0
[  115.738925] ath10k_ahb a800000.wifi: mac flush vdev 0 drop 0 queues 0x1 ar->paused: 0x0  arvif->paused: 0x0
[  118.255098] ------------[ cut here ]------------
[  118.255148] WARNING: CPU: 3 PID: 6125 at target-arm_cortex-a7+neon-vfpv4_musl_eabi/linux-ipq40xx_generic/dsl_cpe_mei-ugw_8.5.2.10/src/drv_mei_cpe_msg_process.c:3570 MEI_IoctlCmdMsgWrite+0x290/0x2c8 [drv_mei_cpe]
[  118.258874] memcpy: detected field-spanning write (size 4) of single field "pDestPtr" at target-arm_cortex-a7+neon-vfpv4_musl_eabi/linux-ipq40xx_generic/dsl_cpe_mei-ugw_8.5.2.10/src/drv_mei_cpe_msg_process.c:3570 (size 2)
[  118.277423] Modules linked in: pppoe ppp_async nft_fib_inet nf_flow_table_inet ath10k_pci ath10k_core ath wireguard pppox ppp_generic nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_objref nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack_netlink nf_conntrack mac80211 libchacha20poly1305 curve25519_neon cfg80211 slhc poly1305_arm nfnetlink_log nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_syslog nf_defrag_ipv6 nf_defrag_ipv4 libcurve25519_generic libcrc32c hwmon crc_ccitt compat clip chacha_neon drv_dsl_cpe_api drv_mei_cpe ip6_udp_tunnel udp_tunnel br2684 vrx518_tc atm vrx518 drv_ifxos sha512_arm md5 kpp ghash_arm_ce cmac usb_storage leds_gpio xhci_plat_hcd xhci_pci xhci_hcd dwc3 dwc3_qcom sd_mod scsi_mod scsi_common gpio_button_hotplug exfat crc32c_generic
[  118.355649] CPU: 3 PID: 6125 Comm: evnthnd Not tainted 6.1.55 #0
[  118.377823] Hardware name: Generic DT based system
[  118.383817]  unwind_backtrace from show_stack+0x10/0x14
[  118.388414]  show_stack from dump_stack_lvl+0x40/0x4c
[  118.393537]  dump_stack_lvl from __warn+0x84/0xc4
[  118.398749]  __warn from warn_slowpath_fmt+0xf8/0x15c
[  118.403434]  warn_slowpath_fmt from MEI_IoctlCmdMsgWrite+0x290/0x2c8 [drv_mei_cpe]
[  118.408482]  MEI_IoctlCmdMsgWrite [drv_mei_cpe] from MEI_IoctlMsgSend+0x68/0x2b8 [drv_mei_cpe]
[  118.415943]  MEI_IoctlMsgSend [drv_mei_cpe] from MEI_InternalMsgSend+0x48/0x50 [drv_mei_cpe]
[  118.424534]  MEI_InternalMsgSend [drv_mei_cpe] from MEI_InternalSendMessage+0x58/0x84 [drv_mei_cpe]
[  118.433128]  MEI_InternalSendMessage [drv_mei_cpe] from MEI_VRX_DSM_StatsGet+0x60/0x9c [drv_mei_cpe]
[  118.441895]  MEI_VRX_DSM_StatsGet [drv_mei_cpe] from MEI_VRX_DSM_FwStatsCheck+0x58/0xc0 [drv_mei_cpe]
[  118.451275]  MEI_VRX_DSM_FwStatsCheck [drv_mei_cpe] from MEI_DEV_IoctlFirmwareDownload+0xc24/0x1c28 [drv_mei_cpe]
[  118.460387]  MEI_DEV_IoctlFirmwareDownload [drv_mei_cpe] from MEI_InternalFirmwareDownload+0x2c/0x34 [drv_mei_cpe]
[  118.470631]  MEI_InternalFirmwareDownload [drv_mei_cpe] from DSL_DRV_DEV_FwDownload+0x2a0/0x80c [drv_dsl_cpe_api]
[  118.480881]  DSL_DRV_DEV_FwDownload [drv_dsl_cpe_api] from DSL_DRV_AutobootLoadFirmware+0x248/0x66c [drv_dsl_cpe_api]
[  118.491208]  DSL_DRV_AutobootLoadFirmware [drv_dsl_cpe_api] from DSL_DRV_IoctlHandleHelperCall+0x8c/0x14c [drv_dsl_cpe_api]
[  118.501796]  DSL_DRV_IoctlHandleHelperCall [drv_dsl_cpe_api] from DSL_DRV_IoctlHandle+0x6a8/0xb74 [drv_dsl_cpe_api]
[  118.512733]  DSL_DRV_IoctlHandle [drv_dsl_cpe_api] from DSL_DRV_Ioctls+0x8c/0xb4 [drv_dsl_cpe_api]
[  118.523147]  DSL_DRV_Ioctls [drv_dsl_cpe_api] from sys_ioctl+0x438/0xb98
[  118.532167]  sys_ioctl from ret_fast_syscall+0x0/0x54
[  118.539008] Exception stack(0xc6f59fa8 to 0xc6f59ff0)
[  118.543964] 9fa0:                   0003fe00 00000001 00000008 c0447201 b6e5f9bc b6e5f990
[  118.549004] 9fc0: 0003fe00 00000001 0003a004 00000036 b6e5f9bc 00000008 0003fe00 ffffffff
[  118.557159] 9fe0: 00039e54 b6e5f860 00013ad4 b6ee873c
[  118.565378] ---[ end trace 0000000000000000 ]---
[  125.238840] ath10k_ahb a800000.wifi: mac flush vdev 0 drop 0 queues 0x1 ar->paused: 0x0  arvif->paused: 0x0
[  133.538830] ath10k_ahb a800000.wifi: mac flush vdev 0 drop 0 queues 0x1 ar->paused: 0x0  arvif->paused: 0x0
[  133.602359] plat_tc_request: dsl id: 0, mode: 1, tc_mode: 3, tc_idx: -1
[  133.603826] vrx518_tc:ptm_tc_hw_fw_init: id(Line)		= 0
[  133.606291] vrx518_tc:ptm_set_mac_address: ptm mac address update!
[  133.607808] vrx518_tc:ptm_tc_hw_fw_init: irq			= 64
[  133.613442] vrx518_tc:ptm_open: ptm open
[  133.619222] vrx518_tc:ptm_tc_hw_fw_init: membase		= 0xd1680000
[  133.629990] vrx518_tc:ptm_tc_hw_fw_init: phy_membase		= 0x40800000
[  133.633772] vrx518_tc:ptm_tc_hw_fw_init: peer_num		= 0
[  133.640017] vrx518_tc:ptm_tc_hw_fw_init: tc_mode		= PTM Single Line
[  133.665838] vrx518_tc:is_ptm_sl: is_ptm_sl: SINGLE
[  133.665902] vrx518_tc:is_ptm_sl: is_ptm_sl: SINGLE
[  133.670359] vrx518_tc:is_ptm_sl: is_ptm_sl: SINGLE
[  133.674330] ppe_aca_cfg_cnt: priv->ep_id[0] bond[0]
[  133.679181] ppe_aca_cfg_cnt: 0 0 0 0
[  133.683874] ppe_aca_cfg_cnt: cfg->txin.soc_cnt_phyaddr[0]
[  133.687699] ppe_aca_cfg_cnt: cfg->txout.soc_cnt_phyaddr[0]
[  133.693060] ppe_aca_cfg_cnt: cfg->rxout.soc_cnt_phyaddr[0]
[  133.698375] ppe_aca_cfg_cnt: cfg->rxin.soc_cnt_phyaddr[0]
[  133.703893] Loading PTM FW ver: 3.5.75
[  133.730859] vrx518_tc:ptm_tc_hw_fw_init: PTM TC init successfully

I have just tried flashing snapshot r24096-9536446965, built using the web build-bot rather than relying on attended-sysupgrade (I think only base-files is changed since last snapshot 5 days ago). I get the same error from the kernel, except different CPU core and PID:

[  118.104768] ------------[ cut here ]------------
[  118.104818] WARNING: CPU: 1 PID: 5638 at target-arm_cortex-a7+neon-vfpv4_musl_eabi/linux-ipq40xx_generic/dsl_cpe_mei-ugw_8.5.2.10/src/drv_mei_cpe_msg_process.c:3570 MEI_IoctlCmdMsgWrite+0x290/0x2c8 [drv_mei_cpe]
[  118.108491] memcpy: detected field-spanning write (size 4) of single field "pDestPtr" at target-arm_cortex-a7+neon-vfpv4_musl_eabi/linux-ipq40xx_generic/dsl_cpe_mei-ugw_8.5.2.10/src/drv_mei_cpe_msg_process.c:3570 (size 2)

The router appears to work fine though.
I'm wondering whether I should log an issue on github?

So, 23.05 has been released and the patchwork link is unchanged. Does that mean my box will be broken when I upgrade? Do you know if this has been fixed in a different way?

Hello, I have a fritzbox 7530 device with openwrt 23.05.01 version.
I want to try different DSL firmware. After installing the new DSL firmware, I restart the DSL with the /etc/init.d/dsl_control restart command. The DSL line is disconnected and reconnected, but the DSL version does not change. When I restart the modem, the newly installed DSL version appears. Is there an easier method than constantly rebooting?

Reloading the kernel modules should work:

/etc/init.d/dsl_control stop
sleep 3
rmmod drv_dsl_cpe_api
rmmod drv_mei_cpe
rmmod vrx518_tc
rmmod vrx518
modprobe vrx518
modprobe vrx518_tc
modprobe drv_mei_cpe
modprobe drv_dsl_cpe_api
/etc/init.d/dsl_control start

You could also try the command dsl_cpe_pipe.sh AutobootLoadFirmware, which takes an absolute path to the firmware as parameter. But I haven't tested if that command actually works.

1 Like

it didn't work

For those who might be interested, I've found a couple more xDSL firmware files:

  • 8.D.1.F.1.7_8.D.1.0.1.1
  • 8.D.1.F.1.7_8.D.1.0.1.2

Details

3 Likes

I have come to post in THE THREAD
Some thoughts... I still revert the kernel version to 5.15 for my builds for this platform.

Reasons:

  1. The "magic" branch only works with 5.15 kernel, it has not been ported to work with 6.1
  2. Things just seem a bit iffy with warnings that are appearing and just kinda being left there as warnings, this goes for the xrx200 target as well I guess. It's not a big deal to me to revert the few patches to go back to 5.15 for me so this isn't some kind of demand or insult or anything, I'm very appreciative already of the considerable work and spirit of kindness that went into these devices being supported in this way. I would just maybe say that I personally don't think 6.1 looks quite ready for 5.15 to have been disabled.

Hello, is there any progress at all in porting the patch to newer kernels and more importantly to apply it for the official OpenWrt builds?

I don't mean to stress or annoy anyone but it would be awesome if it could be applied to the official build as i don't currently have the means to build myself (even though id love to) and it is important to me to have newer software on my router which is one of the beauties of OpenWrt.

Without the patch there is currently no way of getting DSL to work for me.
With the patch it works flawlessly.

Regards
Combatsatellite

i got around to making a new 5.15 build today
as far as I can tell it works, at least on my 7530

I deleted the .itb file because it's too big and doesn't work anyway
i'm going to make a cut down build tomorrow and see if I can recover a device with bad blocks

kernel: 5.15.158 magic patched

whole bin directory (minus .itb)
sysupgrade firmware file

As per usual to use DSL with this firmware you have to follow instructions from here

1 Like

The best thing you (and anyone else with affected devices that the patch helps) could do would be to add a comment to this effect to the PR - the more positive comments there are, the more weight might be brought to bear to accept it.

1 Like

Sorry, where?

Hmmm... My apologies, I thought I'd come across a pull request from someone other than JanH (but created from his patch) but I can't find anything now so must have misremembered :confounded:

Brand new (in response to a post on the mailing list here): https://github.com/openwrt/openwrt/pull/15421

2 Likes

Any Fritzbox 7530 users who can verify this patch works on the DSL?

Do you mean if the patch works in general or in 23.X?

OK, I've asked @ansuel at the github link above whether he can make a firmware including the patch so users could trivially test it.

1 Like