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.
You can be right 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
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.
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.
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.
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.
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.
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.
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).
The problem for me is lack of HW and DSL line to test against.
adding the MSI stubs should be a 10 line patch, problem is how to debug it if it does not work and no DSL line is easily accessable.
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:
