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
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
After some further testing by @mm933, it turned out that the issue is actually reproducible on vendor firmware with the magic disabled in the device tree. The dc_ep_clk_on failed error was just no longer present in the dmesg output in the support data, because there were too many other kernel messages.
I also found out why my adaptation of the magic hack for OpenWrt didn't work. The upstream DesignWare PCIe driver code includes auto detection of the number of ATU regions. This involves overwriting some ATU registers, and happens after the host_init function of the Qualcomm PCIe driver is called. As a result, the programmed ATU entry wasn't actually active.
I fixed that, and it seems to work now. I also did some additional cleanup and sent the patch to the mailing list.
Github: https://github.com/janh/openwrt/commit/1625aa9ce27ed848c851bf739eb29936749bf6f2
Mailing list: https://lists.openwrt.org/pipermail/openwrt-devel/2023-January/040401.html
Patchwork: https://patchwork.ozlabs.org/project/openwrt/patch/20230130224020.473703-1-jan@3e8.eu/
@varda, @jaghatei, or anyone else who encountered the dc_ep_clk_on failed error: This patch should really fix the issue. If you tested it successfully, consider sending your Tested-by to the mailing list.
5 Likes
Hi, i managed to upload the first builds and firmware to my Fritzbox 7530 MA and got a DSL link.
But when I updated to the official build 7530 openwrt-22.03.3-ipq40xx-generic-avm_fritzbox-7530-squashfs-sysupgrade.bin and adding the firmware files as stated in the wiki, I don't have any VDSL menu items nor device in the Lucy webfrontend.
Is there anything I can check what the problem is? Syslog and Kernel log don't reveal anything missed 
22.03.3 does not contain the patches yet. You'll have to stick to SNAPSHOT for now.
I wrote "The integrated VRX518 DSL modem is only supported in releases later than 22.03 and snapshot [...]".
Do you think I should add "(i.e. 23.x)"? Since 22.03.03 might be considered later than 22.03. Or should I phrase "22.03.x" to make it clear?
1 Like
for myself, i also thought the latest release 22.03.3 should work, i would write ie. 23.x.
Also i would thank you all for your efforts to bring a cheap all-in-one device for vdsl back into openwrt. I used vr200v for some time and was never happy. DSL was also good but wifi only worked on 5ghz and it didn't go well. There are so many issues in mt76 firmware with this device: you have to guess eeprom values for better wifi range and even with patches wifi was very bad in multi-user situations.
I enjoyed to just copy my old router config. Since both targets use dsa now this worked quite well.
Now a 30€ Fritzbox 5720 is running openwrt latest master and wifi is great (as expected from qualcomm). DSL sync is much faster (not the data rate, just the time to dsl init sync) than with old lantiq and seems to be stable in 24h.
Big thumbs up!
4 Likes
Yeah sorry it was my misunderstanding, but maybe the clarification will also help others 
Device seems to be stable and very smooth, Thank you all for this great job! 
1 Like
@dhewg, can you please reupload the old vr11 branch that you recently deleted on github so I can make my own build based on older stuff from like end of Dec. 22. That's when everything worked perfectly for me. Nothing new seems to work anymore as the "Unidentified network" always shows up on fresh installs, even on 22.03 stable builds. Only 19.x stable builds work now.
Maybe you can label it as "vr11 old" in github or provide it elsewhere so people don't mix it up. Thanks!
As far as I can tell it works for everybody else.
The vr11fw branch is still there, the pre-merged stuff is gone for good, but you can rebase the relevant commits onto whatever you want. But I don't see that fixing anything.
I'm pretty sure that I have a local copy, but I can't check before the weekend.
What do you mean with "Unidentified network"?
one question about building for the ipq40xx target
it seems the patch I linked to earlier in this thread that boosted cpu clock speeds has been scrubbed off other people's trees
is there a particular reason why the higher clocking of 896000 got removed from those trees ? I've left the patch in my builds because i've never seen the device crash yet but I figure there must be a reason why it seems to have gone bye bye
I wonder how wise it is to overclock cpus without making sure that the heat removal system is up to the task. As far as I understand running at increased temperature does not necessarily lead to crashes but might lead to a shortened device life time, but my understanding is quite superficial....
1 Like
Does the 7520 flashed with OpenWrt master with included firmware files support vdsl up to super vectoring now? profile 35b (250/40 speeds)
I couldn't find any clear answer, yet. ^^
No, because there are no included firmware files. All firmware files need to be installed separately, after installing OpenWrt. The instructions are on the Wiki page.
I know, I want to know, if vdsl supervectoring works with those firmwarefiles or only adsl or vdsl 50/10.
I can not answer for profile 35b (aka "supervectoring in Germany), but the linked files allow 100/40 (syncing currently at 116.7/37 Mbps) with bi-directional vectoring and G.INP. That does not answer your original question, but shows that VDSL2 >> 50/10 does work "out of he box" (I put the firmware files into the "files" folder and built my own snapshot so the firmware files are part of my installation image).
1 Like