Interesting, was v2 mentioned in this thread before? I found some basic info about it here https://boxmatrix.info/wiki/Property:RTL86
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: https://github.com/janh/openwrt/commit/1906c5585bd88ed8aaedcbd4351406aff8a7ef32
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.
@jekkos Could you briefly explain how to set this up?
Documentation of dsl_cpe_pipe.sh G997_LineInventorySet is nonexistent, and cannot find how to do this anywhere 
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 
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 https://github.com/openwrt/openwrt/commit/539b52068a079801fe0955f7cf5f39e536a08803
My vr11 branch is gone with that, and the vr11fw one is now rebased on master.
Nice work everybody!
First builds are now available: https://downloads.openwrt.org/snapshots/targets/ipq40xx/generic/
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
Got a 7520 in the mail to replace my trusty 7412 workhorse. 
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.
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);
+ */
+#else
+ /* 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);
+ */
+#endif
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:
--- 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;
err_clks:
@@ -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 https://downloads.openwrt.org/snapshots/targets/ipq40xx/generic/ 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 192.168.1.10). 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: https://github.com/openwrt/openwrt/pull/4721
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: https://firmware-selector.openwrt.org/
Hit "customize installed packages" and replace everything wolfssl with openssl and add openvpn-openssl
When using SNAPSHOT in https://firmware-selector.openwrt.org/ 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 ). 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 
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.
Modifying the kernel:
make toolspath/to/freetz-ng/tools/unpack_kernel -u kernel.image to unpack the kernel imageavm,host_magic.path/to/freetz-ng/tools/lzma e kernel.image.unpacked kernel.image.packed to compress the modified image againpath/to/freetz-ng/tools/lzma2eva 0x80208000 0x80208000 kernel.image.packed kernel.image.new to convert the compressed image to the format expected by the bootloaderInstallation:
(The same firmware version that was used for modification already needs to be installed.)
mtd write kernel.image.new "uboot$(fritz_tffs_nand -b -d /dev/mtd7 -n linux_fs_start)" to write the modified kernel to the active kernel partitionThe 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).
…
[ 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
…
…
[ 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?