Adding support for VRX518 (and maybe VRX320)

For Developers
1

I am trying to add support for VRX518, and maybe VRX320 devices. I own an AVM 7530 (VRX518).
As I can see, a lot of thread were created in these years, but none of them reached the goal:

Currently I am focusing on VRX518.
Looking around, I found many repositories containing (probably) all the needed files.
After some work I managed to build and load the modules on my AVM7530.

  • drv_dsl_cpe_api
  • drv_mei_cpe
  • drv_ifxos
  • vrx518
  • vrx518_tc
[    8.856227] IFXOS, Version 1.6.9 (c) Copyright 2009, Lantiq Deutschland GmbH
[    8.861134] vrx518: Intel(R) SmartPHY DSL(VRX518) PCIe EP/ACA Driver - version 2.1.0-k
[    8.867137] vrx518: Copyright (c) 2016 Intel Corporation.
[    8.874976] vrx518 0000:01:00.0: enabling device (0140 -> 0142)
[    8.885853] vrx518_tc:pcie_ep_probe: Total 1 VRX518 EP detected
[    8.886005] vaddr: 0xce90d800, phyaddr: 0x8e90d800
[    8.890686] urngd: v1.0.2 started.
[    8.891903] ring: membase: 0xce90d800, phybase: 0x8e90d800, dnum: 128
[    8.900149] vaddr: 0xc1164200, phyaddr: 0x81164200
[    8.906709] ring: cumulative cnt addr: 0xc1164200, phy address: 0x81164200
[    8.911347] vaddr: 0xce90e000, phyaddr: 0x8e90e000
[    8.918214] ring: membase: 0xce90e000, phybase: 0x8e90e000, dnum: 128
[    8.922988] vaddr: 0xc1164240, phyaddr: 0x81164240
[    8.929481] ring: cumulative cnt addr: 0xc1164240, phy address: 0x81164240
[    8.934194] vaddr: 0xc1118000, phyaddr: 0x81118000
[    8.941027] ring: membase: 0xc1118000, phybase: 0x81118000, dnum: 1024
[    8.945822] vaddr: 0xc1164280, phyaddr: 0x81164280
[    8.952310] ring: cumulative cnt addr: 0xc1164280, phy address: 0x81164280
[    8.957108] vaddr: 0xc116c000, phyaddr: 0x8116c000
[    8.962176] random: crng init done
[    8.963964] ring: membase: 0xc116c000, phybase: 0x8116c000, dnum: 1024
[    8.963973] vaddr: 0xc11642c0, phyaddr: 0x811642c0
[    8.978628] ring: cumulative cnt addr: 0xc11642c0, phy address: 0x811642c0
[    9.001012] alloc shash md5 fail. Handle: -2
[    9.001050] Firmware pointer id(0):size(10608), fw addr(52ba6c30), off(100)
[    9.004399] Firmware pointer id(1):size(19376), fw addr(704b3b8c), off(10708)
[    9.011038] Firmware pointer id(2):size(11368), fw addr(575b0291), off(30084)
[    9.018347] Firmware pointer id(3):size(21244), fw addr(6c754040), off(41452)
[    9.025459] VRX518 PPE Firmware header info
[    9.032559] 	PTM Version: 3.5.72
[    9.036566] 	PTM Feature: A0000000
[    9.040023] 	ATM Version: 3.5.36
[    9.043250] 	ATM Feature: B0000000
[    9.046618] 	Compability ID: 00000004
[    9.049831] 	Size: 00000010
[    9.053575] 	FW built Date: 9-25-2018
[    9.056168] 	Number of firmware: 4
[    9.059990] 		Firmware[0]: ID[0] size[2652] at[0x52ba6c30]
[    9.063304] 		Firmware[1]: ID[1] size[4844] at[0x704b3b8c]
[    9.068760] 		Firmware[2]: ID[2] size[2842] at[0x575b0291]
[    9.074241] 		Firmware[3]: ID[3] size[5311] at[0x6c754040]
[    9.079790] vrx518_tc:tc_drv_init: Intel(R) SmartPHY DSL(VRX518) PCIe TC Driver - version 1.5.12
[    9.085190] vrx518_tc:tc_drv_init: Copyright (c) 2018 Intel Corporation.
[    9.107386] Lantiq (VRX) DSL CPE MEI driver, version 1.7.2, (c) 2007-2016 Lantiq Deutschland GmbH
[    9.107576] Found 1 PCI VRX devices, 
[    9.120021] 
[    9.120021] 
[    9.120021] Lantiq CPE API Driver version: DSL CPE API V4.19.3
[    9.120065] 
[    9.120065] 
[    9.120065] Lantiq CPE API Device layout: 1 devices, 1 lines, 1 channels
[    9.127932] 
[    9.127932] Predefined debug level: 3
[    9.137374] 
[    9.137374] ++++++++++++++++++ MEI_InternalDevOpen ++++++++++++++++++
[    9.137374] 
[    9.142492] hwVers=0x00000240
[    9.152024] 
[    9.152024] ++++++++++++++++++ MEI_InternalDevOpen ++++++++++++++++++
[    9.152024] 

root@OpenWrt:~# lsmod | grep dsl
drv_dsl_cpe_api       184320  0 
drv_ifxos              24576  2 drv_dsl_cpe_api,drv_mei_cpe
drv_mei_cpe           163840  1 drv_dsl_cpe_api
root@OpenWrt:~# lsmod | grep vrx
vrx518                 24576  2 drv_mei_cpe,vrx518_tc
vrx518_tc             159744  1 drv_mei_cpe

But I don't see any new interface. I still trying to understand what's missing or if I deleted some necessary code... maybe some expert developer in xrx platform could help...

This is my development branch just for the AVM7530. Be sure to select all the needed packages in the menuconfig.

Side notes and closing thoughts:

  1. This is just a development branch that I update in my little spare time.. so expect silly mistakes and stupid bugs...
  2. Currently all the packages are from the official openwrt repository (except the vrx518-ep that's from blocktrron). I am wondering why this is still not supported... Lack of interest or unresolvable problems? :roll_eyes:
  3. I don't know why, but in order to compile everything I had to delete the original ltq-vdsl and ltq-vdsl-mei packages. Otherwise they get compiled automatically even if I don't select them
3 Likes
2

I'm glad I found your post just in time: I received a FRITZ!Box 7530 today and I wanted to look into the very same thing.
Thanks for posting your work, I'll try to at least reproduce your work!

Btw, you've got an error logged regarding md5 - I don't know if that's the problem?

3

The more, the merrier! :slight_smile:

I know that problem but I don't know why it happens. Seems that the kernel it's not able to load the module to calculate the md5... however I just skipped the md5 part because it shouldn't do anything except calculate the checksum of the firmware (PATCH)

4

So, everything compiled, modules transferred and loaded - so far so good. I do not get any new interfaces, either, so some debugging is going to be necessary.

You can omit the patch if you select the "md5" module at the kernel module configuration. For me, the message is:

[  958.102657] ring: cumulative cnt addr: 0xce5787c0, phy address: 0x8e5787c0
[  958.108993] MD5 checksum pass!!!
[  958.114416] Firmware pointer id(0):size(10608), fw addr(2e2eb3e6), off(100)
[  958.117679] Firmware pointer id(1):size(19376), fw addr(a12e355a), off(10708)
[  958.124425] Firmware pointer id(2):size(11368), fw addr(ddea1259), off(30084)
[  958.131746] Firmware pointer id(3):size(21244), fw addr(06709ed4), off(41452)
[  958.138886] VRX518 PPE Firmware header info
1 Like
5

I don't want to be too optimistic, but I might be on to something.
Going through the vrx518_tc driver, it seems that atm or ptm interfaces are only created if requested by the control application. I haven't built the control application, so this is the next step.

I discovered two devices under /dev: /dev/dsl_cpe_api/0 and /dev/mei_cpe/0. While researching this, I found a different (newer?) control application dsl-cpe-fapi at a repository here. This application directly talks to the two devices under /dev.

6

Good work! :wink:

You can be right :slight_smile: I don't know if openwrt in the past replaced dsl-cpe-fapi with his own implementation... According to the files in the docs folder seems necessary:

The DSL FAPI is designed as a c-based interface bridge between
DSL SL (Service Layer) towards the higher, and the DSL CPE API towards the
lower layers.

The figure below shows the DSL CPE PHY Subsystem and visualizes (highlights)
the parts which are directly related to the DSL FAPI.\n

https://git.prpl.dev/intel/dsl-cpe-fapi/blob/master/doc/fapi_sw_structure_overview-noref.jpg

We should investigate this :wink:

Just to understand better how it works with vrx200, seems that the dsl0 interface is created by ltq-ptm package here: https://github.com/openwrt/openwrt/blob/master/package/kernel/lantiq/ltq-ptm/src/ifxmips_ptm_vdsl.c#L1014
But from what I understand, the ptm module should not be necessary anymore because it's integrated in the vrx518 one...

7

As far as I've understood how it works on the vrx200 devices, there is a ltq-vdsl-app which invokes /sbin/vdsl_cpe_control. It includes dsl_cpe_control as source and installs it as vdsl_cpe_control. I did not yet investigate whether it works with the VRX518 as well or if the -fapi version is required.

Unfortunately, I won't have much time to work on this for the next few days, let's see.

8

And suddenly this: http://lists.infradead.org/pipermail/openwrt-devel/2020-February/021758.html.
He managed to make it mostly work... I still didn't have time to look into it, but it looks promising. :slight_smile:

2 Likes
9

Wow, sounds interesting! I'm not subscribed to the list, so thanks for sharing.

I just had a brief look at the dsl-cpe-fapi I posted above: It needs a proprietary system_fapi library which is Intel binary only. It seems to be required for hardware acceleration support only.

I also had a quick try with the ltq-vdsl-app and came to the conclusion that it's too old for the VRX518. In the repo you posted, it was updated to a newer version.

10

I tried the repository linked in my previous message and I can confirm that the dsl part is half working. The VRX518 gets the signal, but no data is received. I digged into the vrx518_tc_drv but not enough to find the culprit. I think that the problem is caused by some interrupts not firing when the dsl chip receives packets. Probably somewhere in the the sw_plat.c file connected to the rx section... @sch-m Do you have any idea about it?

P.s. Just for clarification, i think that ltq-vdsl-app creates the "pipes" in /tmp/pipe so that is possible to get information from the dsl chip. Although my version was not working correclty, it wasn't too old to support the vrx518. I tried an even newer version and it does't work either. However Martin's repository is cleaner and better organized than mine so I advice to start again from his repo.

11

@numero53
This corresponds exactly to my observations.
I have already tried to enable the interrupts explicitly (https://github.com/3headeddevs/openwrt/commit/b0be6e9c0cfe3b93226a0c78b14c8a9d24c2ea37#diff-54302b2609977e3102efd2c0facfbde4R412) but this leads to the fact that after a short time the DSL synchronization breaks off.

12

Some observations in the Supportdata of the original FB7530 Firmware 164.07.03:

  • vrx518_tc driver uses essedma driver (output of lsmod)
  • vrx518_tc irq_base is 203
  • mei_cpe driver uses irq 204
  • In the process list you can find irq/206-aca_rxo which looks like there is a threaded interrupt handler used.
13

Hi Martin,
are there any news so far?

Thanks!

Best Regards

14

Hi Mike!

I'm currently not working on this problem anymore.
My hope was to find someone (or maybe many) who can help to get this finally working.
But I've got no feedback from anyone.

Regards,
Martin

15

Hi Martin,
thanks for answering!

Which DSLAM did you use for testing?

Best Regards

16

I used a Zyxel VES1724-56B2

1 Like
17

The lantiq devices seem to be of very low interest. For the very same reason, I'm abandoning my work on the Fritz 3390 and Fritz 3490 devices as well.
I do have a 7530 as well, but hacking on the Lantiq code is a bit over my head, unfortunately.

18

First of all, I'm sorry that i didn't came back to your E-Mail (which apparently was directed towards me).

When I was working with the 7530, there was substantially fewer sources for the VRX518 available which were also incomplete and/or massively outdated, which let down my interest in getting this thing to work.

What further complicates the process (at least from my perspective) is the fact that VDSL concentrator hardware is either expensive and/or creates a noticeable nosie environment. Testing with your own VDSL line (if you still have one) is not very fun.

The 7530 is still very interesting Hardware, but the prerequisites for someone to experiment with the hardware are rather high. Combined with the fact that xDSL wireline access is disappearing this makes is rather hard to find someone who can and is willing to invest time in it.

19

After short conversation with @blogic today he mentioned that the lack of interrupts firing is possibly due to lacking support for MSI in the pcie-qcom driver. This should not be hard to add, however, testing is difficult without PCIe hardware actually making use of MSI (wifi cards all use old-school PCI INT ABCD approach).

20

Are there any news?

1 Like