Adding OpenWrt support for AVM FRITZ!WLAN Mesh Repeater 2400

I saw a PR for the current AVM Repeater 3000 flagship and want to ask, if there is any chance that the AVM FRITZ!WLAN Mesh Repeater 2400 could get OpenWrt support, too?
I already have two 1750E with OpenWrt and maybe the 2400 is not that different.
Can anybody help me?

Thanks in advance!

1 Like

According to boxmatrix, the FRITZ!Repeater 2400 uses the QCN5502 SoC.

Because the TP-Link Archer A9 v6.x has the same SoC, its chances of OpenWrt support will be similar. I suggest to refer to this post to get an idea what needs to be done. Are you planning to work on OpenWrt support for the FRITZ!Repeater 2400?

In case you just want to use a device without development, also consider the FRITZ!Repeater 1200 and 3000.
They both use the IPQ4019 SoC and are already supported by OpenWrt. Note that I do not own either of them, my recommendation is based on their specs and discussions in this forum.

1 Like

Hello everyone, Archer A9 V6 support has been added to OpenWrt (https://github.com/openwrt/openwrt/commit/9c335accfe57f3049850b8fdb684c9e7e5feea82). It is therefore possible to obtain a firmware for Fritz 2400 too ?

It won't magically materialize by itself, but that certainly helps (keep in mind that QCN5502 support is still very basic and rough, e.g. no 2.4 GHz wireless support yet).

Ok. Obviously no claims on your part (which you already do a lot) but I hope it can be developed. The original software is not that great. I reported some requests to the help desk and they didn't even bother to answer. Thank you.

I started adding the the device:

I had to disable PCIe. Further, the mtd layout looks odd:

# cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 01d2d200 00010000 "rootfs"
mtd1: 00242e00 00010000 "kernel"
mtd2: 00020000 00010000 "urlader"
mtd3: 00070000 00010000 "tffs (1)"
mtd4: 00070000 00010000 "tffs (2)"
mtd5: 01f70000 00010000 "reserved-kernel"

It is only 2315.5 KiB for the kernel partition. Further it is not aligned? Resulting in error messages like:

[    0.382113] Creating 6 MTD partitions on "spi0.0":
[    0.387073] 0x000000000000-0x000001d2d200 : "rootfs"
[    0.392234] mtd: partition "rootfs" doesn't end on an erase/write block -- force read-only
[    0.404568] mtd: device 0 (rootfs) set to be root filesystem
[    0.410555] mtdsplit: no squashfs found in "rootfs"
[    0.415633] 0x000001d2d200-0x000001f70000 : "kernel"
[    0.420795] mtd: partition "kernel" doesn't start on an erase/write block boundary -- force read-only
[    0.432111] 0x000001f70000-0x000001f90000 : "urlader"
[    0.438336] 0x000001f90000-0x000002000000 : "tffs (1)"
[    0.446004] 0x000002000000-0x000002070000 : "tffs (2)"
[    0.452330] 0x000002070000-0x000003fe0000 : "reserved-kernel"
...
Flash size not aligned to erasesize, reducing to 29824KiB

Complete-Bootlog.

Can someone help me especially with the flash?

Sorry i can't help in this sense but thank you for developing!

Hello, any news about the development for Repeater 2400? Is there any way to help?
Thanks!

Hi @PolynomialDivision

it would be interesting if the bootloader is booting this device via device-tree or legacy boot. device-tree can contain runtime configurations like cmdline but also other information e.g. which serial can be used.
Further it is possible for bootloaders to change the partition table depending which partition to boot.

OEM Bootlog

[    0.000000] Kernel command line:  gocommand console=ttyS0,115200n8r nor_size=0 sflash_size=64MB nand_size=0MB ethaddr=3C:A6:2F:1F:CF:95 slub_debug=-

Suspicious. What for is

nor_size=0 sflash_size=64MB nand_size=0MB

Who parse and use it? The kernel or userspoace?
Let's check the partition table

OEM Bootlog
[    1.065446] Creating 6 MTD partitions on “ath-nor”:
[    1.070473] 0x0000022d2e00-0x000004000000 : “rootfs”
[    1.076717] [rootfs] use mtd0 (rootfs) as root
[    1.081298] mtdsplit: no squashfs found in “rootfs”
[    1.086267] 0x000002090000-0x0000022d2e00 : “kernel”
[    1.092402] 0x000000000000-0x000000020000 : “urlader”
[    1.098615] 0x000000020000-0x000000090000 : “tffs (1)”
[    1.104976] 0x000002020000-0x000002090000 : “tffs (2)”
[    1.111381] 0x000000090000-0x000002000000 : “reserved-kernel”

What in tffs (1) or tffs (2)?
Do you have a full dump of the flash (e.g. by booting an OpenWrt via tftp)?

mtdsplit is splitting up mtd partitions. This allows us to skip updating the kernel partition everytime it increase. Also it saves some flash memory.
This is also the reason why the kernel doesn't end up on an erase block (usually 64kbyte, depending on your flash).

Let's sort the partition table:

0x000000000000-0x000000020000 : “urlader”
0x000000020000-0x000000090000 : “tffs (1)”
0x000000090000-0x000002000000 : “reserved-kernel”
0x000002020000-0x000002090000 : “tffs (2)”
0x000002090000-0x0000022d2e00 : “kernel”
0x0000022d2e00-0x000004000000 : “rootfs”

This flash is huge. 64Mbyte. But is it really SPI-NOR? I would guess it's SPI-NAND. Can you check it?
Also I would guess AVM implement either A/B firmware scheme or a recovery/production scheme to make it harder to brick it.

So merging now the kernel + rootfs part
0x000002090000 - 0x000004000000.
This looks like the reserved-kernel partition with an offset.
So as start I would call this merged partition "firmware". OpenWrt treats mtd parts with name "firmware" special and is doing everything what it needs to be done.

If this is a SPI-NAND we have to use UBI and also have to check if the old bootloader even supports UBI. Or if it's possible to add a second stage u-boot.
Also we need to know how the A/B or recovery/production image works. How is the booted system reports it's running correct?

I'm also wondering where the calibration data are? From where does it take the mac address?