Adding support for VRX518 (and maybe VRX320)

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 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!

12 Likes

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 :slight_smile:

4 Likes

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);
+       */
+#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:

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;
 
 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

2 Likes

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 :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 https://github.com/Freetz-NG/freetz-ng
  • 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 kernel.image.new to convert the compressed image to the format expected by the bootloader

Installation:
(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 kernel.image.new "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.)

1 Like

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?

Yes, I forgot to mention that.

The DTS files for 7520-B and 7530-B are identical except for the device model, some formatting, and the switch port limitation. Both define GPIO pins for NFBI, which appears to be the inter-SoC interface used to boot the Realtek SoC ("Non-Flash Boot Interface").

That all looks like 7530 Typ B is identical to 7520 Typ B and has a Realtek modem. So, if it actually exists as a released product, it would be better to avoid for anyone who wants an OpenWrt device with working modem.

1 Like

Hi *

Long time OpenWrt user, first time forum poster - I'd just like to express my gratitude to all involved and to report my experience.

Thanks to all the great effort by the devs, I too have been able to upgrade from a BT Home Hub 5A to a FRITZ!Box 7530. My ISP is TalkTalk in UK which uses DHCP via VDSL for a 80/20 Mbps connection. My local cabinet is an Infineon one.

I bought a second hand but still sealed "Edition Zen Internet" ISP branded 7530, upgraded the FritzOS to the latest 7.50 before attempting the OpenWrt snapshot install. The only issue I had with the install was a weirdly behaving tftp server on my macbook which refused to send the initfamfs image properly. I resolved this by running a Devuan Linux VM under UTM on the mac, passing through the USB-Ethernet dongle and using tftpd-hpa. Initial IP address for uboot was the 192.168.178.x one.

I run a Wireguard VPN connected to an OpenBSD VM hosted at my favourite provider along with Policy Based Routing, by installing these extra packages on the router: curl, htop, dnsmasq-full, luci-ssl, luci-app-wireguard, luci-app-pbr.

I also set echo 500000 > /sys/bus/cpu/devices/cpu0/cpufreq/scaling_min_freq as mentioned earlier in the thread which greatly improves the high and variable local ping latency.

I have 'software flow offloading' and 'packet steering' enabled, though I'm currently unsure whether they have much impact.I have also installed irqbalance which works as expected to spread the IRQs across the four CPUs.

Anyway, I'm super happy because it is all working perfectly and a great step up from the venerable BT Home Hub.

:~#ubus call dsl metrics
{
	"api_version": "4.23.1",
	"firmware_version": "8.13.1.5.0.7",
	"chipset": "Lantiq-VRX500",
	"driver_version": "1.11.1",
	"state": "Showtime with TC-Layer sync",
	"state_num": 7,
	"up": true,
	"uptime": 78194,
	"atu_c": {
		"vendor_id": [
			181,
			0,
			73,
			70,
			84,
			78,
			178,
			6
		],
		"vendor": "Infineon 178.6",
		"system_vendor_id": [
			69,
			67,
.......
	],
	"annex": "B",
	"standard": "G.993.2",
	"profile": "17a",
	"mode": "G.993.2 (VDSL2, Profile 17a)",
	"upstream": {
		"vector": false,
		"trellis": true,
		"bitswap": true,
		"retx": false,
		"virtual_noise": false,
		"interleave_delay": 0,
		"data_rate": 20000000,
		"latn": 12.200000,
		"satn": 12.100000,
		"snr": 12.600000,
		"actatp": 2.800000,
		"attndr": 29821518
	},
	"downstream": {
		"vector": false,
		"trellis": true,
		"bitswap": true,
		"retx": false,
		"virtual_noise": false,
		"interleave_delay": 0,
		"data_rate": 79995000,
		"latn": 13.500000,
		"satn": 13.600000,
		"snr": 6.800000,
		"actatp": 2.300000,
		"attndr": 83181112
	},
	"errors": {
		"near": {
			"es": 15,
			"ses": 0,
			"loss": 0,
			"uas": 31,
			"lofs": 0,
			"fecs": 126,
			"hec": 0,
			"ibe": 0,
			"crc_p": 43,
			"crcp_p": 0,
			"cv_p": 275,
			"cvp_p": 0
		},
		"far": {
			"es": 64,
			"ses": 0,
			"loss": 88,
			"uas": 31,
			"lofs": 0,
			"fecs": 313,
			"hec": 0,
			"ibe": 0,
			"crc_p": 0,
			"crcp_p": 0,
			"cv_p": 0,
			"cvp_p": 0
		}
6 Likes

My results after a month:

updated my build, link to download above somewhere (contains no dsl blobs as per discussion here)
merged in the extra dsl stats stuff from janh

just one thing to bring up, the vr11 driver still needs a patch like was made here:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=71bdff9139a469380f1b0a42425fa091dbb16f88
to compile with glibc