Adding support for VRX518 (and maybe VRX320)

Sorry for repeating myself, but I'm afraid I'm not being clear in the previous post.

But, what is the safe method to maintain this build updated?

I ask this because I'm really noob in custom builds.

I think that because of the particular implementation of the vr11 branch I cannot safely update packages using opkg, especially the kernel... right?

Or I could safely update my router packages at the last version without worries?

Best way is to pull in the latest changes and run the build again (recompile). Updating packages probably won't end well

Thank you @ListerWRT .

So does this mean that to update we have to wait for a new commit on the vr11 branch and to use the official package manager we have to wait for a merge on the official openwrt master branch?

I read that there is currently a licensing issue.
If this will not resolved will I have an outdated router forever?

Or maybe recompiling every so often I will get an updated version?

I'm just asking this to learn. I am really inexperienced in this subject. I really appreciate the work you are doing.

Thank you.

DSL support only exists in the vr11 branch. If you want it, the only way is to build it. Updating = rebuilding, which is trivial once you know what you're doing.

Support is entirely reliant on dhewg for the time being. It may never be merged into openwrt master (the licencing issues you mentioned).

Opkg is only really useful in stable branches where not much/nothing changes (21.02, 22.03, etc). If you're not using a stable release just forget about it.

If you need more, start a new thread or DM. This is off topic here.

Hope that's helpful.


The patches which are also useful to currently supported DSL routers, and some common ones we depend on, are all merged by now.

What's left are VR11 specific ones, and getting all of those merged depends on the licensing issue, without that OpenWrt cannot ship router images which contain the required DSL firmware.

Because the remaining patches mostly introduce new VR11 specific packages, the chances for conflicts between the vr11 and the evolving master branches are pretty low. So you can just rebase the vr11 branch on OpenWrt master and build that. While I rebase and push myself every now and then, that doesn't mean you have to wait for me to do so :slight_smile:

1 Like

Not shipping xDSL firmware and requiring the user to obtain it somehow and write it to the device has been a common occurrence in the past -- before Lantiq publish the redistributable VDSL firmware for VR9 and for users of VR9 connected to a DSLAM with mandatory vectoring it even still holds true up to today. This situation is not great, but still better than not supporting xDSL interfaces at all.

What I'm trying to say is: the lack of decently licensed firmware should not prevent us from merging patches and drivers which are licensed under GPLv2.

Hence, please lets go ahead and merge what we have by now, and then maybe also come up with helper scripts which allow users to easily download, extract and install non-redistributable xDSL firmware once when installing OpenWrt on VR11-based devices.


Okay, I just threw everything as-is in
Along with some options on how to handle the fw situation.
Let's see...


On the firmware situation, would it make sense to build USB mass storage support into the image (if it isn’t already)? Then it wouldn’t take much to install firmware from a USB stick: eg if a particular layout exists it’s automatically installed via a helper script, or can be done via a command. Then it just needs some instructions in what to copy to the USB stick.

The alternative is that the router would be operational for LAN purposes but not WAN, but that would be enough to scp the file over after having downloaded it from a machine that has internet.

1 Like

The PR now doesn't contain the fw packages anymore, since those won't get merged due to the license situation, see

Which affects the same vr11 branch posted and used here.

The last commit of that branch now contains instruction how to get these.

So you either pick one of the two options per the instructions or use the new vr11fw branch, which does have the firmware packages just as the old vr11 had.

That's described in the last commit of the PR.

That's a possibility, per default the images won't come with the required modules though.
But similar to the ltq-vdsl-fw package, you could add a new package which does all that while depending on the required modules. Once the PR is merged, users could then use imagebuilder to add that to their image so it's usable without inet connectivity. I won't pursue that option, but don't let me stop you from doing so :slight_smile:

just cloned openwrt master and cherrypicked this EXCELENT pull request. will replace my bt homehub 5a since this fb 7530 has much more perfomance. thank you @moeller0 for pointing me to this thread! i'm totally happy and turris omnia + unstable allnet sfp module will go back to its sender. fritzbox 7530 just cost me 75€.

on bt homehub 5a i got only 33mbit download. (50/10 plan)


Just saw there is another version "FRITZ!Box 7530 AX" of this box. Is it covered by this PR too?

Currently DT's DLM system is intervening on your link and limiting the maximal allowed sync rates to 90/37 Mbps. The way this system is supposed to work is to adjust the maximal syncrates (as well as a few other less visible parameters) in proportion to the perceived 'instability' of a link (lower stability -> lower sync rates), but this adjustment is supposed to be dynamic. So in your case, with the likely cause for the intervention being an only partially suited modem that often resynct, I exxpect that in the next few weeks DLM will open up the allowed sync again. Could you please post the go-dsl output/screenshot in say a month, please?

Tripple no, that one has different soc, wifi and dsl hardware, broadcom at that, see!Box_7530_AX

But it covers the 7520 model, and the artificial limitations of the vendor fw don't apply to OpenWrt, so from that perspective they're identical. You can get that one used for ~40€

1 Like

One thing to be aware of though is that there is a variant of the 7520 called "Typ B". That one still uses an IPQ40xx SoC, and OpenWrt should probably run on it (the device tree is nearly identical). However, it has a Realtek modem (actually an entire second SoC) instead of the VRX518.

(Unfortunately, an open source archive for that model is not yet available. It would be interesting to see what's actually in there, because all the drivers on the Realtek side seem to be built into the kernel image. Although the host side drivers to get the Realtek SoC to boot at all would be more important for getting the modem running.)

Since i'm not a GIT expert and the official release seems to have some delay:
How can i keep the official OpenWRT snapshot AND this PR up to date?
Can someone give me the command lines? Thx.

Guess thats why ChatGPT was invented. I hope he is right:

git checkout master
git pull
git checkout PR-11728
git pull --rebase origin master

Interesting, was v2 mentioned in this thread before? I found some basic info about it here

And I see that is already available to get on popular used markets. So yeah, pay attention if you wanna get one, you want the older version with "wings".

I looked at this again, and in the end the code in qcom_pcie_prog_magic is actually not all that magic. The last line changes the vendor/device ID of the PCIe host, as already expected.

The code before that writes the Lantiq manufacturer ID 0x839 to a buffer, and configures the PCIe address translation unit so that it is visible at a memory range that contains chip identification on Lantiq SoCs.

The exact location of the value within the buffer is a bit strange though. On xrx200 the offset 0x340 from the MPS base address (which is actually referenced in some Lantiq bootloader sources as containing manufacturer ID) contains the value 0x1820. The manufacturer ID is actually at 0x344 and only shifted 1 bit to the left. But that might be different on GRX500.

In any case, I put together a patch:

It doesn't have any effect on functionality here (except that the PCIe ID changes of course). But maybe it helps on devices with the dc_ep_clk_on failed error.

@mm933, @varda, @jaghatei: You reported about that issue here earlier, so it might be worth trying this patch.

Hi @janh,

nice work!
I gave it a try and it seems to fix the dc_ep_clk_on failed:

@jekkos Could you briefly explain how to set this up?
Documentation of G997_LineInventorySet is nonexistent, and cannot find how to do this anywhere :slight_smile:

I used Belgian AVM fw V7.29 firmware files, expecting to stay whitelisted, but have been kicked onto fallback profile after a few hours.