Netgear WAC124 (MediaTek MT7621AT) support

Hi,

what does it take to get openwrt support for WAC124?

There are already some supported MT7621 devices https://archive.openwrt.org/snapshots/trunk/ramips/mt7621/

https://wikidevi.com/wiki/Netgear_WAC124

MT7621AT, MT7603E + MT7615
128MB RAM, 128MB Flash

source available on https://kb.netgear.com/2649/NETGEAR-Open-Source-Code-for-Programmers-GPL

FCC ID: PY318100410
internal photos https://apps.fcc.gov/eas/GetApplicationAttachment.html?id=3838631

Someone (you?) with the device on their desk will have to port OpenWrt to this device, the SOC (mt7621) itself is already supported and you can find previous commits adding support for other mt7621 devices in OpenWrt's git history. mt7615, the 5 GHz wlan card, is not supported in OpenWrt yet, but a driver has been merged for mainline linux v5.2~ and will likely become available to OpenWrt's mt76 package in due time; be aware that this driver is still very new and might not meet your expectations in terms of performance or stability yet.

3 Likes

WAC124 should be supported under R6350 image. Same as mine new R6260 . I have Trunk compilation with mtk-openwrt-feeds mt7615 module (for 5Ghz support). Just need some time to test it .I have high hopes for it :slight_smile:

Why that? Can you please explain?

1 Like

R6350 firmware and flash method is compatible with routers R6260 R6850 WAC124 .They even share the same OEM firmware R6260 R6850 R6350 .WAC124 is using different one but they share same hardware minus antena output .

@tmomas do u try openwrt on the WAC124, what was the result ?

I was able to flash the sysupgrade image for R6850/R6350, but only after modifying the Sercomm header

unzip openwrt-ramips-mt7621-netgear_r6850-squashfs-factory.img
cp R6850.bin WAC124.bin
rm -f WAC124.img ; zip WAC124.img WAC124.bin
mksercommfw -b CTL -r A003 -i WAC124.img

I flashed the file using nmrpflash, but it should also work via the Web UI.

5 GHz Wifi is still slow due to incomplete open-source driver support for MT7615E.

2 Likes

Thanks for the instruction, I was able to use the r6850 image to flash my router. Everything seems to be working fine, apart for the wifi. I am now at the stage where the factory mtd is wrong in the dts file.
I am wondering where the original layout is taken from ? the oem image?

I can see in the factory mtd where the mac address start for the different interfaces, i think it should adjusted.

Is there a way to mount the oem img in a nandsim to see what is inside ?

I fixed it, my 5Ghz has good tx power now. however i am not getting the 2.4 band on the mt7615

What changes did you perform?

I adjusted the dts, the eeprom wasn't read properly. I want to make a pr for it, but i am not sure how to make a dts file for just that change. Also, in regards to my previous comment, i think there is no 2.4Ghz on the mt7615 for this configuration. The patch is below, if you want to try it.

diff --git a/target/linux/ramips/dts/mt7621_netgear_sercomm_chj.dtsi b/target/linux/ramips/dts/mt7621_netgear_sercomm_chj.dtsi
index b781edf6be..6e7faac396 100644
--- a/target/linux/ramips/dts/mt7621_netgear_sercomm_chj.dtsi
+++ b/target/linux/ramips/dts/mt7621_netgear_sercomm_chj.dtsi
@@ -173,9 +173,9 @@
                        read-only;
                };
 
-               factory: partition@4600000 {
+               factory: partition@4640000 {
                        label = "factory";
-                       reg = <0x4600000 0x200000>;
+                       reg = <0x4640000 0x200000>;
                        read-only;
                };

On my WAC124, the factory partition is at 0x4600000. This also matches the partition layout of the factory firmware:

# cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 00100000 00020000 "Bootloader"
mtd1: 00100000 00020000 "SC_PART_MAP"
mtd2: 00400000 00020000 "Kernel"
mtd3: 02800000 00020000 "Rootfs"
mtd4: 00200000 00020000 "English UI"
mtd5: 00200000 00020000 "ML1"
mtd6: 00200000 00020000 "ML2"
mtd7: 00200000 00020000 "ML3"
mtd8: 00200000 00020000 "ML4"
mtd9: 00200000 00020000 "ML5"
mtd10: 00200000 00020000 "ML6"
mtd11: 00200000 00020000 "ML7"
mtd12: 00200000 00020000 "ML8"
mtd13: 00200000 00020000 "ML9"
mtd14: 00200000 00020000 "ML10"
mtd15: 00200000 00020000 "ML11"
mtd16: 00200000 00020000 "Factory"
mtd17: 00200000 00020000 "SC Private Data"
mtd18: 00200000 00020000 "POT"
mtd19: 00200000 00020000 "Traffic Meter"
mtd20: 00200000 00020000 "SC PID"
mtd21: 00200000 00020000 "SC Nvram"
mtd22: 00200000 00020000 "Ralink Nvram"
mtd23: 00200000 00020000 "Reserved Block1"
mtd24: 00200000 00020000 "Reserved Block2"
mtd25: 00200000 00020000 "Reserved Block3"
mtd26: 00200000 00020000 "Reserved Block4"
mtd27: 00200000 00020000 "Reserved Block5"
mtd28: 02180000 00020000 "Reserved Block6"

There has been a similar issue on other mt7621 NAND devices before, related to the handling of bad eraseblocks (#1926). Does the flash in your device have any bad blocks?

Edit: It looks like this also issue also affects R6260/R6350/R6850: 0cf889db00f81575568b19cb470e97aad7765f32

Edit2: There is a previous discussion of the issue on the mailing list and on GitHub.

Yes, I have 2 bad blocks , hence the offset start. I wasn't aware of those issues, if this can be detected and adjusted at runtime it would good, and a single dts for those devices.

There is a partition map (in the second partition SC_PART_MAP). When support for the R6350 was originally added in 2018, the author of the pull request also created a parser for that partition map. But the result seemed to be wrong, so it was rejected in favor of fixed partition offsets (see this comment).

Looking again at the bad block issue, the original mt7621 NAND driver handled bad blocks by transparently shifting pages. That broken behavior was only fixed in 2019 with commit 527832e54bf3bc4d699a145ae66f34230246f0a9.

So, I think that the partition map just seemed to be wrong because of the broken NAND driver behavior, but it is actually correct. Then the proper fix would be to replace the fixed partition offsets by the partition map parser.

I agree with you, seems like the partition map parser should be included, especially if this is something we will see more in the future. However, I do not know enough about NANDs to know what exactly is going with those bad eraseblock, how many does yours have?

I have sent a patch with the partition table parser to the mailing list: http://lists.infradead.org/pipermail/openwrt-devel/2020-June/029857.html
It would be great if you could test it to verify that it actually works.

The flash in my WAC124 doesn't have any bad blocks at all. But a few bad blocks are normal for NAND flash, even on a new chip (there is some information on the wiki page about flash memory). If you look at the datasheet of the MX30LF1G18AC flash chip, you can see that up to 20 bad blocks (out of 1024) are allowed for this 128M chip (table 18).

Thanks, I'll try to compile this and test it over the weekend.

I tried your patch, and also used the new wac124 device tree, It worked. The factory partition has been correctly detected and adjusted.

[ 1.241080] Bad eraseblock 204 at 0x000001980000
[ 1.362690] Bad eraseblock 293 at 0x0000024a0000
[ 2.345095] scpart: valid 'SC PART MAP' found (29 partitions)
[ 2.356712] 29 scpart partitions found on MTD device mt7621-nand
[ 2.368681] Creating 29 MTD partitions on "mt7621-nand":
[ 2.379280] 0x000000000000-0x000000100000 : "u-boot"
[ 2.390518] 0x000000100000-0x000000200000 : "SC PART_MAP"
[ 2.402359] 0x000000200000-0x000000600000 : "kernel"
[ 2.413358] 0x000000600000-0x000002e40000 : "ubi"
[ 2.424033] 0x000002e40000-0x000003040000 : "English UI"
[ 2.435712] 0x000003040000-0x000003240000 : "ML1"
[ 2.446184] 0x000003240000-0x000003440000 : "ML2"
[ 2.456672] 0x000003440000-0x000003640000 : "ML3"
[ 2.467208] 0x000003640000-0x000003840000 : "ML4"
[ 2.477717] 0x000003840000-0x000003a40000 : "ML5"
[ 2.488389] 0x000003a40000-0x000003c40000 : "ML6"
[ 2.499124] 0x000003c40000-0x000003e40000 : "ML7"
[ 2.509821] 0x000003e40000-0x000004040000 : "ML8"
[ 2.520488] 0x000004040000-0x000004240000 : "ML9"
[ 2.531102] 0x000004240000-0x000004440000 : "ML10"
[ 2.541781] 0x000004440000-0x000004640000 : "ML11"
[ 2.552493] 0x000004640000-0x000004840000 : "factory"
[ 2.563669] 0x000004840000-0x000004a40000 : "SC Private Data"
[ 2.576218] 0x000004a40000-0x000004c40000 : "POT"
[ 2.586828] 0x000004c40000-0x000004e40000 : "Traffic Meter"
[ 2.599120] 0x000004e40000-0x000005040000 : "SC PID"
[ 2.610129] 0x000005040000-0x000005240000 : "SC Nvram"
[ 2.621458] 0x000005240000-0x000005440000 : "Ralink Nvram"
[ 2.633572] 0x000005440000-0x000005640000 : "reserved0"
[ 2.645119] 0x000005640000-0x000005840000 : "reserved1"
[ 2.656672] 0x000005840000-0x000005a40000 : "reserved2"
[ 2.668247] 0x000005a40000-0x000005c40000 : "reserved3"
[ 2.679810] 0x000005c40000-0x000005e40000 : "reserved4"
[ 2.691388] 0x000005e40000-0x000007f80000 : "reserved5"

I have one side question, do you have issue with the mt7603e where it does not apply the country channels correctly ? , I found mine to use channel13 a lot, and it is not seen by clients until it uses another channel.

If you are in the US, there has been change in wireless-regdb recently which enables channels 12 and 13.

Personally, I use fixed channels (and channels 12/13 are allowed here anyway). But when using automatic channel selection it is also possible to limit the available channels via the channels option.