Adding support for VRX518 (and maybe VRX320)

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.

Thank you for testing! I guess this confirms that some VRX518 fail to initialize when not connected to (what they believe is) a Lantiq SoC.

If you have a bit of time, could you also try with all the dw_pcie_writel calls between #if and #else (i.e. this part) commented out? I'd like to make sure this is really correct and necessary (although of course the fact that AVM included this code strongly suggests so).

Then I'll update the patch and submit it.

The PR has been merged :tada:

So with the next round of built snapshots you can just download an image which then already has the DSL drivers included.
One simply has to take care of the firmware files, as per

My vr11 branch is gone with that, and the vr11fw one is now rebased on master.

Nice work everybody!


First builds are now available:

Please give that a try, with the firmware instructions mentioned above it should just work.

And if anyone with a wiki account could update it that'd be appreciated as well :slight_smile:


Got a 7520 in the mail to replace my trusty 7412 workhorse. :slightly_smiling_face:
I'll join the testing club as soon as it arrives.

Installed yesterday on a brand new 7520, but I can only confirm that the drivers are there and load just fine if the firmware files are provided as mentioned. I'll have access to a line to test on Sunday.

I updated the Wiki page, feedback and tests are welcome!

NB: scp doesn't preserve symlinks, it copies the entire file. If we transfer vdsl.bin as per your instructions, we end up with two copies of the firmware.

Nice, thanks for the confirmation!

Right, the symlinks are preserved for files/lib/firmware when building the image though. I tried to keep the instructions as simple as possible, and while that's not optimal it shouldn't be a problem since there's plenty of space.

I see you fixed that for the wiki, thanks!

What's not yet solved is keeping the fw files for a sysupgrade. If they're part of the image that's not a problem, but if you scp them to the downloaded image, they're gone afterwards. Maybe throw the filenames in /etc/sysupgrade.conf for now, but I didn't test if there's a size issue.

Another idea is to create a firmware partition, so they're persistent and then overlay mount that.

I think if they fit in overlay, they will survive a sysupgrade if in /etc/sysupgrade.conf. It would really be great if maxlinear would be open and friendly and release these files with an OpenWrt compatible license, after all all users of these blobs will need a device with maxlinear chips/IP inside so are indirect customers.

1 Like

Hi, sure! Unfortunately I have absolute no experience in c.
I've tried to comment out like this:

+#if 1
+       /*
+       * dw_pcie_writel_dbi(pci, PCIE_ATU_VIEWPORT,
+       *                  PCIE_ATU_REGION_INBOUND | index);
+       * dw_pcie_writel_dbi(pci, PCIE_ATU_CR1, PCIE_ATU_TYPE_MEM);
+       * dw_pcie_writel_dbi(pci, PCIE_ATU_CR2, PCIE_ATU_ENABLE);
+       * dw_pcie_writel_dbi(pci, PCIE_ATU_LOWER_BASE, 0x1f100000);
+       * dw_pcie_writel_dbi(pci, PCIE_ATU_UPPER_BASE, 0);
+       * dw_pcie_writel_dbi(pci, PCIE_ATU_LIMIT, 0x1f10ffff);
+       * dw_pcie_writel_dbi(pci, PCIE_ATU_LOWER_TARGET, phys);
+       * dw_pcie_writel_dbi(pci, PCIE_ATU_UPPER_TARGET, 0);
+       */
+       /* for Linux 6.0 */
+       /*
+       * dw_pcie_writel_atu_ib(pci, index, PCIE_ATU_REGION_CTRL1,
+       *                     PCIE_ATU_TYPE_MEM);
+       * dw_pcie_writel_atu_ib(pci, index, PCIE_ATU_REGION_CTRL2,
+       *                     PCIE_ATU_ENABLE);
+       * dw_pcie_writel_atu_ib(pci, index, PCIE_ATU_LOWER_BASE, 0x1f100000);
+       * dw_pcie_writel_atu_ib(pci, index, PCIE_ATU_UPPER_BASE, 0);
+       * dw_pcie_writel_atu_ib(pci, index, PCIE_ATU_LIMIT, 0x1f10ffff);
+       * dw_pcie_writel_atu_ib(pci, index, PCIE_ATU_LOWER_TARGET, phys);
+       * dw_pcie_writel_atu_ib(pci, index, PCIE_ATU_UPPER_TARGET, 0);
+       */

But then the patch fails:

patch: **** malformed patch at line 102: +

Patch failed!  Please fix /home/ubuntu/Documents/openwrt/target/linux/ipq40xx/patches-5.15/997-avm-pcie-host-magic.patch!

The patch format doesn't allow changing the number of lines without adjusting the range information. Here is a simplified patch with the code removed entirely:

Modified patch for testing
--- a/drivers/pci/controller/dwc/pcie-qcom.c
+++ b/drivers/pci/controller/dwc/pcie-qcom.c
@@ -197,6 +197,7 @@ struct qcom_pcie {
 	struct phy *phy;
 	struct gpio_desc *reset;
 	const struct qcom_pcie_ops *ops;
+	bool host_magic;
 #define to_qcom_pcie(x)		dev_get_drvdata((x)->dev)
@@ -236,6 +237,21 @@ static void qcom_pcie_2_1_0_ltssm_enable
 	writel(val, pcie->elbi + PCIE20_ELBI_SYS_CTRL);
+static void qcom_pcie_init_magic(struct qcom_pcie *pcie)
+	struct dw_pcie *pci = pcie->pci;
+	struct device *dev = pci->dev;
+	if (!pcie->host_magic)
+		return;
+	/* Set vendor/device ID of GRX500 PCIe host */
+	dw_pcie_dbi_ro_wr_en(pci);
+	dw_pcie_writew_dbi(pci, PCI_VENDOR_ID, 0x1bef);
+	dw_pcie_writew_dbi(pci, PCI_DEVICE_ID, 0x0030);
+	dw_pcie_dbi_ro_wr_dis(pci);
 static int qcom_pcie_get_resources_2_1_0(struct qcom_pcie *pcie)
 	struct qcom_pcie_resources_2_1_0 *res = &pcie->res.v2_1_0;
@@ -946,6 +962,8 @@ static int qcom_pcie_init_2_4_0(struct q
 	val |= BIT(31);
 	writel(val, pcie->parf + PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT_V2);
+	qcom_pcie_init_magic(pcie);
 	return 0;
@@ -1490,6 +1508,8 @@ static int qcom_pcie_probe(struct platfo
 	pcie->ops = of_device_get_match_data(dev);
+	pcie->host_magic = of_property_read_bool(dev->of_node, "avm,host_magic");
 	pcie->reset = devm_gpiod_get_optional(dev, "perst", GPIOD_OUT_HIGH);
 	if (IS_ERR(pcie->reset)) {
 		ret = PTR_ERR(pcie->reset);

(The expectation would be that this patch is not enough, so initialization now fails again.)

It seems that builds from work on my 7520. Though when building my own image from vr11fw, as well as when downloading the stable build 22.03.3, on first boot of the router after the fresh install I can't access the router. The network says "Unidentified network" with no access to SSH or ping at all (ping works only when changing PC address to I built the vr11fw image prob like 5 times. Builds before the vr11fw branch worked from the vr11 branch. The stable build 22.03.1 works as well. Any ideas?

I need to build my own image as openvpn-openssl doesn't seem to work when installing via opkg afterwards.

The master branch switched to DSA:
Hence the network config isn't compatible with any other branch.
The master branch also is the only one with dsl drivers.

You can try imagebuilder to customize the package for a master snapshot:
Hit "customize installed packages" and replace everything wolfssl with openssl and add openvpn-openssl


When using SNAPSHOT in for the 7520 and adding to customize installed packages "openvpn-openssl" and "luci-app-openvpn" then installing luci via opkg, the router and access work like a charm. But OpenVpn is not working (or I don't know how to make it work :slight_smile: ). When using Snapshot and adding both from above + "luci" to the image, the router is not accessible via SSH again and PC says "Unidentified network".

There're shouldn't be a conflict between the ssl libraries, but you can try luci-ssl-openssl instead of just luci.
If that doesn't work it may be a bug, but then you better open an issue or create a new thread about it

Hi Jan,

I guess I mixed the two devices and used the wrong Fritzbox.
Today I've tried with the other devices and the "magic patch" you've linked in post 357.
Unfortunately the kernel error still appears :confused:

If the full patch from the original post doesn't work, that could mean that my adaptation to OpenWrt is broken, or that the magic may be there for another reason.

One way to rule out the latter would be to try running the vendor firmware without the magic and check if anything breaks (if it causes the dc_ep_clk_on failed error, that should be easily visible in kernel messages from support data).

Since this just requires changing the device tree of the kernel, it is actually not that hard too do.

Instructions to modify vendor firmware kernel to disable magic

Modifying the kernel:

  • Download
  • Run make tools
  • Download and unpack Fritzbox firmware image (it is just a tar archive), find "kernel.image" in "var/tmp"
  • Run path/to/freetz-ng/tools/unpack_kernel -u kernel.image to unpack the kernel image
  • Open kernel.image.unpacked in hex editor and find avm,host_magic.
    Replace all occurences except the first (i.e. just the ones in DTB) by another string (changing one character is enough)
  • Run path/to/freetz-ng/tools/lzma e kernel.image.unpacked kernel.image.packed to compress the modified image again
  • Run path/to/freetz-ng/tools/lzma2eva 0x80208000 0x80208000 kernel.image.packed to convert the compressed image to the format expected by the bootloader

(The same firmware version that was used for modification already needs to be installed.)

  • Boot OpenWrt initramfs image
  • Copy the modified image to the device (e.g. using scp)
  • Run mtd write "uboot$(fritz_tffs_nand -b -d /dev/mtd7 -n linux_fs_start)" to write the modified kernel to the active kernel partition
  • Reboot to run the vendor firmware with modified kernel

The latest vendor firmware helpfully includes kernel messages that show whether the magic is enabled or not, so it is easy to see if the modification worked (see the updated pcie-qcom.c from the latest source code release).

Kernel log from unmodified vendor firmware
[    0.294461][2] PCI change magic executed
[    0.499963][2] pci 0000:00:00.0: [1bef:0030] type 01 class 0x060400
[   26.668227] vrx518_tc: Total 1 VRX518 EP detected
[   26.668274] Function platform_init called
Kernel log from vendor firmware with modified kernel image (without magic)
[    0.294202][0] PCI change magic disabled. No host_magic set
[    0.499963][0] pci 0000:00:00.0: [17cb:1001] type 01 class 0x060400
[   26.725834] vrx518_tc: Total 1 VRX518 EP detected
[   26.725986] Function platform_init called

So, in my test, the modification worked, as shown by the kernel messages. It doesn't look like anything broke here. There's also no dc_ep_clk_on failed message in the place where it would occur (but as I tested on a device which doesn't show that error on OpenWrt, this is the expected result).

By the way, the recent open source archive contains some other interesting information. There are DTS files for a 7530 Typ B. I have no idea if it is out in the wild (maybe not, since there is no public firmware), but it may still be good to keep in mind for anyone looking to find a supported device. (There's also a 7530 AX Typ B, based on IPQ50xx+VRX518 like the 7510, but of course that is not that interesting until OpenWrt supports that SoC.)

Not many changes in the -2 DTS. Maybe they did something similar to the 7520 Typ B and replaced the VDSL frontend by a RTL86?