I will do as soon as i have some kind of state which i would recommend someone to flash. Currently it is pretty barebone in terms of what is working and the required U-Boot is currently in a sorcery state. It is completely WIP currently.
1 Like
Ok, thank you very much! 
Just tell me an I‘ll test.
I was just wondering if you already found the GPL sources for the fritzbox itself?
if not, here they are:
https://osp.avm.de/fritzbox/
and my mirror:
I havn't looked for the DSL driver yet, so maybe its not even in there.
There are great news.
blocktrron ported openwrt to the device
There is no dsl driver yet!
THE FOLLOWING IS AT YOUR OWN RISK:
-
Clone from here: https://github.com/blocktrron/openwrt/tree/pr-fritz7530-nodsl
-
Download modfied ramboot script from here:
https://paste.linuxlounge.net/#/rJFaI1ukX16hETwTuoNtPKHHvrY!hAx204NFzzIjbBx8dmoTgW2c7TtwbteeSdL43A6lL0c -
Compile the above branch from blocktrron
-
Upload the uboot-fritz7530.bin with the modified ramboot script.
-
TFTP to 192.168.1.1 in binary mode and upload the initrams image you just compiled
-
Scp the uboot-fritz7530.bin and the squashfs image to 192.168.1.1:/tmp/
-
SSH to 192.168.1.1
-
Write uboot to boot0 partition:
mtd write /tmp/uboot-fritz7530.bin /dev/uboot0 -
Write uboot to boot1 parition:
mtd write /tmp/uboot-fritz7530.bin /dev/uboot1 -
Remove avm partitions to get space for owrt:
ubirmvol ubi0 --name=avm_filesys_0
ubirmvol ubi0 --name=avm_filesys_1 -
Sysupgrade the squashfs you've uploaded to the device:
sysupgrade /tmp/squashfs_image.bin -
OpenWRT should boot.
THANKS TO @blocktrron !!!
3 Likes
A little confusing as this device seems to be in the compatibility list now showing as "snapshot" but I can't actually find any image.
Are there any pre-compiled images now or do you still have to compile it yourself? I understand you would still have to do the procedure above to flash as AVM locked out flashing on these devices thus you have to boot a custom image from RAM first.
Has anyone tested how the WiFi performs on OpenWRT? I was kinda hoping this would be a nice replacement for my Archer C7 which seems to be CPU bound for large WiFi transfers.
https://downloads.openwrt.org/snapshots/targets/ipq40xx/generic/openwrt-ipq40xx-avm_fritzbox-7530-initramfs-fit-uImage.itb
https://downloads.openwrt.org/snapshots/targets/ipq40xx/generic/openwrt-ipq40xx-avm_fritzbox-7530-squashfs-sysupgrade.bin
Keep in mind that this doesn't imply that the VDSL modem, DECT or the FXS ports were supported.
1 Like
Thanks, I understand DECT is likely never to be supported and VDSL is not guaranteed either.
I'm really just interested in more consistent 802.11ac performance than the Archer C7 while waiting for OpenWRT supported 802.11ax devices to come out (I bet that will be a while coming).
I think I will hold off trying until someone can confirm if performance is acceptable or not as I don't fancy trying to get stock firmware back on it if its not, if you even can.
I can only speak for a single Client 2SS <-> AP scenario, but i managed to get ~500Mbit/s to the LAN side. However, I can't speak for if it's worth the upgrade from a C7. From the raw WiFi speeds when directly near the device i had with neither of those devices any problems.
However, in case you consider buying one, i would go for the 4040. It has the downside of having less flash, but it sports an additional WAN port, additional USB 2.0 port but has the same core chipset. Way back to stock is relatively easy in case you have access to a Windows computer (on this device I've tested it personally, but i could try the same with the 7530 and report back if you wish).
The recovery tool can be obtained from AVM's FTP server: http://ftp.avm.de/
1 Like
That's very promising.
I got the router free with my ISP for signing a new 12 month contract, which also was cheaper for the same package, so quite a steal.
My Archer C7 is not performing great. Here's a comparison of the Archer C7 OpenWRT vs the Fritzbox stock firmware:
Reverse mode, remote host lcars is sending
[ 4] local 192.168.1.2 port 49810 connected to 192.168.1.253 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 31.5 MBytes 265 Mbits/sec
[ 4] 1.00-2.00 sec 31.8 MBytes 265 Mbits/sec
[ 4] 2.00-3.01 sec 32.1 MBytes 268 Mbits/sec
[ 4] 3.01-4.00 sec 36.8 MBytes 311 Mbits/sec
[ 4] 4.00-5.00 sec 35.0 MBytes 293 Mbits/sec
[ 4] 5.00-6.00 sec 35.0 MBytes 294 Mbits/sec
[ 4] 6.00-7.00 sec 40.0 MBytes 335 Mbits/sec
[ 4] 7.00-8.00 sec 41.9 MBytes 352 Mbits/sec
[ 4] 8.00-9.00 sec 41.1 MBytes 345 Mbits/sec
[ 4] 9.00-10.00 sec 42.2 MBytes 354 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 370 MBytes 310 Mbits/sec 5 sender
[ 4] 0.00-10.00 sec 368 MBytes 308 Mbits/sec receiver
Reverse mode, remote host lcars is sending
[ 4] local 192.168.1.2 port 49935 connected to 192.168.1.253 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 50.2 MBytes 421 Mbits/sec
[ 4] 1.00-2.00 sec 51.6 MBytes 433 Mbits/sec
[ 4] 2.00-3.00 sec 51.5 MBytes 432 Mbits/sec
[ 4] 3.00-4.00 sec 52.8 MBytes 443 Mbits/sec
[ 4] 4.00-5.00 sec 51.9 MBytes 436 Mbits/sec
[ 4] 5.00-6.00 sec 51.1 MBytes 429 Mbits/sec
[ 4] 6.00-7.00 sec 52.5 MBytes 441 Mbits/sec
[ 4] 7.00-8.00 sec 52.0 MBytes 436 Mbits/sec
[ 4] 8.00-9.00 sec 49.8 MBytes 418 Mbits/sec
[ 4] 9.00-10.00 sec 49.8 MBytes 418 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 516 MBytes 433 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 513 MBytes 431 Mbits/sec receiver
iperf Done.
Even 2.4Ghz is dramatically different on the same channel and width:
Reverse mode, remote host lcars is sending
[ 4] local 192.168.1.2 port 50623 connected to 192.168.1.253 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 3.92 MBytes 32.9 Mbits/sec
[ 4] 1.00-2.00 sec 3.32 MBytes 27.8 Mbits/sec
[ 4] 2.00-3.01 sec 3.73 MBytes 31.0 Mbits/sec
[ 4] 3.01-4.00 sec 3.67 MBytes 31.1 Mbits/sec
[ 4] 4.00-5.00 sec 3.42 MBytes 28.7 Mbits/sec
[ 4] 5.00-6.00 sec 2.68 MBytes 22.5 Mbits/sec
[ 4] 6.00-7.00 sec 3.61 MBytes 30.3 Mbits/sec
[ 4] 7.00-8.00 sec 3.72 MBytes 31.2 Mbits/sec
[ 4] 8.00-9.00 sec 3.89 MBytes 32.6 Mbits/sec
[ 4] 9.00-10.00 sec 3.91 MBytes 32.8 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 37.1 MBytes 31.1 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 36.0 MBytes 30.2 Mbits/sec receiver
Reverse mode, remote host lcars is sending
[ 4] local 192.168.1.2 port 50835 connected to 192.168.1.253 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 8.21 MBytes 68.8 Mbits/sec
[ 4] 1.00-2.00 sec 8.31 MBytes 69.8 Mbits/sec
[ 4] 2.00-3.00 sec 9.41 MBytes 78.8 Mbits/sec
[ 4] 3.00-4.00 sec 9.72 MBytes 81.7 Mbits/sec
[ 4] 4.00-5.00 sec 10.1 MBytes 84.5 Mbits/sec
[ 4] 5.00-6.00 sec 9.46 MBytes 79.3 Mbits/sec
[ 4] 6.00-7.00 sec 8.73 MBytes 73.2 Mbits/sec
[ 4] 7.00-8.00 sec 9.15 MBytes 76.8 Mbits/sec
[ 4] 8.00-9.00 sec 9.26 MBytes 77.5 Mbits/sec
[ 4] 9.00-10.00 sec 9.25 MBytes 77.6 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 93.0 MBytes 78.0 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 91.7 MBytes 76.9 Mbits/sec receiver
I use custom scripts to aggregate a list of all connected clients, for security and to monitor range/connection issues, which is why if I can get that performance on OpenWRT then that would be great. I can repurpose the C7 on my friends cable line which is using an older WDR3600 that can't quite handle his full speed with QoS enabled.
You forgot the u-boot: https://downloads.openwrt.org/snapshots/targets/ipq40xx/generic/u-boot-fritz7530/uboot-fritz7530.bin
Also that folder has the uploader for the 4040 instead of the eva_ramboot.py so I took the latter from github.
Everything seems to have gone fine, just need to configure it now.
UPDATE:
Everything works fine from boot but if you try to restart WiFi you get the following error and 5Ghz never comes back up, you have to power cycle.
[ 1154.642701] ath10k_ahb a800000.wifi: peer-unmap-event: unknown peer id 0
Apart from that speed seems much more stable than the Archer C7 (Channel 52 80Mhz Reg: GB):
Out of curiosity - How distant is now the scenario to get DSL support for 7530, given that drivers for vrx518 have now been obtained?
Don't hold your breath.
--
Keep in mind that the Fritz!Box 7530 not only employs this new Intel/ lantiq VRX518 modem chipset, it also operates it outside of its natural habitat, connected via PCIe on a little endian QCA4019 ARMv7 system SoC.
It's a pity
For comparison, keep in mind that the Netgear D7800 is in a similar situation. Available since 2015, QCA IPQ8064 combined with a lantiq VRX320 modem, while the router itself is supported, the modem functionality isn't available. While this (for both devices) shouldn't be impossible to get working, it would require significant work on these specific combinations.
Very interesting what you say. When you say "significant work" could this be a matter of months/years or maybe just of couple of weeks of focused work for an experienced person?
I would be really interested doing this work for all of us if I knew how to do it, even if it took months, but unfortunately my professional expertise lies outside the technology sector. I guess this is not a realistic target for a novice in that field like me, isn't it?
It means diving into the unknown, because it's a previously "unseen[1]" combination.
--
[1] within the scope of OpenWrt supported devices.
@blocktrron Did you get the serial console of the fb 7530 fully working. I am able to get data from the fritzbox, but cannot send anything to it. I've already tried an 10k pull-up on the rx line without success. Is there anything else to equip apart from the 4-pin-header?
The Serial console works for me without further modifications in both directions.
Are you connecting with the mapping described in the patch?
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=95b0c07a618fe5fd93a26931152ced483bba143b
Yes, I'm using this mapping and I also can the data on the rx-pin with my oscilloscope. My thought was now that perhaps still somewhere something must be equipped.
@blocktrron Can you please have a look at your pcb if the marked pads are also open on yours?
The route from "my" Rx-Pin seems to end there.
