Adding support for VRX518 (and maybe VRX320)

dhewg · May 4, 2022, 8:34am

They are, there was just an alternative and simpler way, see

dhewg · May 4, 2022, 2:59pm

I updated the branch for kernel 5.15, so it works with CONFIG_TESTING_KERNEL=y now.
Only minor testing done so far, but DSL is up and running.

Lebedev · May 4, 2022, 3:59pm

ok, i will try it this weekend with a 7520.
Is there some info or even quick step guide how to use the latest development/code from this thread?

dhewg · May 5, 2022, 8:17am

I just pushed another update so the 7520 variant for u-boot is built.

With that the 7530 install steps still apply, just use the 7520 u-boot binary instead (but it'll work with the 7530 build too, but you'll get a random MAC):
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=95b0c07a618fe5fd93a26931152ced483bba143b

bin-bash · May 5, 2022, 6:59pm

Hello also down

Reiver · May 8, 2022, 2:42pm

Does the driver here for vrx518 (vr11) also potentially include support for vrx320 (vr10)?

As noted in the first post, a previous thread Netgear D7800 build stalled on dsl support but would be curious if changes for vr11 could otherwise be ported to vr10 drivers?

Interested in VDSL support for Netgear D7800 so I can to retire my HH5.

janh · May 8, 2022, 5:43pm

Here is another update including fixes and cleanup. (I already started working on this some time ago, so the latest changes by @dhewg are not included. But I think the only missing thing is the 7520 u-boot image, which shouldn't matter much as that only needs to be built once anyway.)

So, here is the list of changes:

Support for kernel 5.15
Info LED is now used for DSL status
MAC address for vectoring error reports is actually set (commands in the autoboot script require a nLine parameter with current drivers)
DSL connection can be started and stopped via /etc/init.d/dsl_control (Previously, there was no way to get the connection running again after the service was stopped unless kernel modules are reloaded. This is because the drv_dsl_cpe_api driver is broken and fails to restart the autoboot thread once it has been stopped. This thread is needed to start the DSL connection. The daemon now avoids stopping the autoboot thread when it exits.)
Reported connection uptime is now accurate (this is a long-standing bug in the driver which also affected older modem generations, caused by cumulative rounding error)
Cleaned up data path code (includes removing debug code and a few other changes)
Fixed buffer management in transmit path (The previous code in sw_plat.c didn't consider that both the buffers allocated for internal transmit descriptors in ptm_tc.c/atm_tc.c and those allocated in sw_plat.c for sending move between the respective descriptors during operation. This resulted in a segmentation fault when unloading the vrx518_tc module, as sw_plat.c freed all buffers which it had previously allocated itself, but at this point some of these would be in the internal descriptors and already freed by ptm_tc.c/atm_tc.c.)
Moved all datapath patches from the WIP commit into the respective driver commits
Experimental NAPI support for data path (Seems to work so far, but hasn't seen much testing. Optionally it is possible to switch to threaded NAPI via /sys/class/net/dsl0/threaded. If you want to try a version without NAPI support, you can remove the two uppermost patches 202-napi.patch and 203-dbg.patch from the vrx518_tc driver.)

The updated code is in my vrx518 branch.

Some of the remaining issues in functionality that I know of:

ADSL/ATM support. Not sure if anyone has already tested this, I don't have any way to do that myself.
Reports of broken transmit path on some devices (message dc_ep_clk_on failed in kernel log)
Switching between different firmware requires driver reload, unlike VR9 where /etc/init.d/dsl_control restart works (but this is a relatively minor issue)

And if this is ever going to be upstreamed in the future, there is also the issue of firmware licensing. For the DSL firmware, there is at least a license file (it looks like a standard license for device manufacturers, which may not be sufficient for OpenWrt). For the ACA and PPE firmware the situation is even worse, as there doesn't seem to be any license information at all. Of course, one could add a firmware downloader package similar to the vectoring firmware installer for VR9, but for VR11 that would mean an additional download is required even for basic operation of the modem.

dhewg · May 9, 2022, 7:41am

Sounds like nice progress, I'll test drive it!

On first glance our 5.15 patches differ a little too. The only small thing worth mentioning is about ltq-vdsl-vr11-mei: There's another MODULE_SUPPORTED_DEVICE in src/test_internal/drv_test_mei_cpe_linux.c. I assume that get's compiled with the additional test package, but I didn't even try that.

janh · May 9, 2022, 3:25pm

I have to admit I only fixed whatever errors came up when building, so I didn't notice that. But I just did a build of the ltq-vdsl-vr11-mei-test package and it worked. It looks like that only builds a test application (src/mei_cpe_drv_test.c), and the kernel module within test_internal isn't built at all.

dhewg · May 12, 2022, 8:24am

Ah okay, so that doesn't matter after all I also just looked at the errors and grep'ed around a little.

As for your latest update:
There wasn't any noticeable regression with non-threaded NAPI, I tested this for +2 days. No issues, no dmesg entries afaict.
I enabled threaded NAPI yesterday, seems to work just fine too, no regressions either

janh · May 13, 2022, 7:23pm

I just pushed another small update to my branch. This includes just 2 changes:

Moved locking for interrupt mask changes to EP driver (cleans up the code a bit).
Fixed reported upstream MINEFTR value (Removed multiplication by 1000 in the driver which caused an overflow, as the EFTR_min value from the device seems to alredy be in bits/second. The same issue exists for VR9, so a separate patch for these devices is also needed. I'm not entirely sure if this is actually an issue in the Lantiq modem. In theory, this could also be caused by the other end sending data in the wrong format. But the only G.INP line I have for testing is my own DTAG line (Broadcom 194.26). So, if anyone tests this on a line with different vendor ID, please report back with results. The MINEFTR value is reported by dsl_cpe_pipe.sh pmrtctg 1.)

andyboeh · May 15, 2022, 2:44pm

@dhewg It would be great if you could rebase your branch on the current master the next time you work on it: Support for the Fritz!7530 with the new NAND chip was just merged.

Thanks for all the hard work!

dhewg · May 16, 2022, 6:13am

Done, including @janh's latest patches

dhewg · May 16, 2022, 6:55am

I'm using a local provider, but it's all DTAG lines anyway afaik, Broadcom 178.31.
Uptime is less than one hour, because of a new image with your latest patches.
nReturn=0 nDirection=1 nElapsedTime=2763 bValid=1 nEftrMin=42140000 nErrorFreeBits=2788235998 nLeftr=43

janh · May 16, 2022, 6:14pm

Thank you for testing! This is a reasonable value, so it looks like the patch also works on your line.

Now, the interesting question is if it also works for non-Broadcom VTU-C.
@numero53: If you still have the Planet VC-231G, it would be great if you could test this! This of course also applies to anyone else who has a way to test on a non-Broadcom G.INP-enabled line.

akron · July 4, 2022, 6:03pm

@dhewg @janh what a blast the fastest VDSL2 device by a mile, nice work guys. Retiring BT Home Hub 5a soon!

dhewg · July 8, 2022, 10:42am

Same here, already retired my BTHH for a 7520 last year
But the hard work to get DSL going was all done by @janh, I only got it a bit into shape to get a step closer to upstream it.

About that, maybe we should just try that? I guess the license on a few firmware files are unclear, leave them out for now?

andyboeh · July 9, 2022, 10:07am

@dhewg I'm also on a 7520 with your tree, but two LAN ports seem to be stuck at 100M. Am I missing a patch in your tree?

idfxken · July 9, 2022, 12:30pm

I'm guessing this won't be off much use in Belgium? (Only whitelisted firmwares can use vectoring, Else you get a 30/5 fallback profile)

Or are the loaded firmware blobs fixing this?

janh · July 9, 2022, 8:29pm

There is a potential issue with the ATM patch that is worth looking at before trying to upstream the code. @akron reported a build failure due to the function ppp_device not being defined (It went away though with a fresh config). I haven't verified this myself, but it seems like the function is indeed missing.

Other than yet, I agree that it may be time to look into upstreaming. I have finally switched to a 7520 for my actual DSL a few weeks ago, and it also works fine here.

I think that restriction is only lifted with the DSA patch. @dhewg commented about this on Github: https://github.com/openwrt/openwrt/pull/4721#issuecomment-996504471 https://github.com/chunkeey/FritzBox-4040-UBOOT/pull/6#issuecomment-996732085

Depending on how that whitelist is actually implemented I think it could still work. In addition to using a supported DSL firmware version, it is possible to adjust the reported inventory data to match the values from the vendor firmware (using dsl_cpe_pipe.sh G997_LineInventorySet for temporary configuration, but making that permanent should be possible using a modification of the DSL init script). If the whitelist includes any further checks, then this could be more difficult.