Adding OpenWrt support for ZTE MF286 3g/4g wifi router

Great to hear that!

There is actually one more thing you can help with - test the Wi-Fi performance, for example using iperf3 - on stock firmware versus OpenWrt, specifically on 5GHz band, because this is Wave2 radio and it's vendor calibration data may need upstreaming as well, if performance on OpenWrt is worse.

iperf3 results from OpenWrt are here..

Am having trouble to get stock back to the device, took backup using stock firmware. When I follow the receipt in your PR, concatenating "web", "kernel", "rootfs" images, I do get a "bad magic" on bootm. When I concat just "kernel" and "rootfs" images, it at least start to boot, doing some sort of repartion and flashing but end up in a kernel panic.

I have uploaded a log, inlcuding a printenv and a boot which end up with a panic here..

You may have an idea what am I doing wrong or whether I could try something different to get my device back on stock firmware. It's not an issue for me, I'm fine with that, just in case the iperf3 result on stock firmware is that important to further try to get the device back on stock firmware.

Did you use the "U-boot TFTP factory" method for restoring when using "web+kernel+rootfs" combo? You can upload the MTDs somewhere, maybe I can produce working image from them.

Yes, I tried that "U-boot TFTP factory" method..

The MTDs are available here:

Thank you!

cat'ing mtd1{1,2,3}.bin should work. Do you have a log from U-boot attempting to perform this recovery?

cat'ing mtd1{1,2,3}.bin is what I tried 1st which resulted in the "bad magic" sympthom. I then left out "web" and that produced the log from U-boot I posted earlier, this one..

I will try it anyway again..

Still getting "bad magic" by cat'ing mtd1{1,2,3}.bin .. the log is here:

No. You have confused the recovery methods. You manually loaded the kernel as initramfs, that's why omitting the web part worked. You're supposed to erase beginning of "kernel" partition, then reboot and let U-boot do it's job to load image from and write it to flash.
Follow the "Method 3: using built-in TFTP recovery (LAST RESORT)" method, just using the reconstructed factory image instead of prepended OpenWrt initramfs"

Thank you to enlighten me! The device is now back on stock firmware. I will get you the iperf3 results w/stock firmware later today..

Here it is..

Overall, wifi perf on stock seems a lot better

For 5GHz (only that matters in terms of extracting ath10k board data) I don't see much difference here, both firmwares reach around 179Mbps total, usually, with occasional hiccups in the OpenWrt measurements. So could you describe how the performance suffers?

Also, I confirmed that stock board data for QCA9888 in MF286A and MF286R are exactly the same, and extracted the right one. However, I'm not sure if it's worth to upstream them if performance isn't affected. I'll do some more measurements today as well with a help of a friend - I don't have the device myself.

In the meantime, folks at forum go the modem to work with some patches.

I'm sorry, just my gut feeling. The difference w/2.4GHz is much more than w/5GHz. When just looking at the 5GHz values, as you said, it is not that much.. my chosen test parameters probably were not so good, instead of fixed time based, I should have chosen based on size, using different sizes. How do you test? If you want me to repeat testing, just let me know your preferred way of doing.

Great, the modem thing sounds promising.

The modem is quite unstable, though. See the other topic: Problem with modem in ZTE MF286R

Regarding 2.4GHz, there is not much to do for ath9k than load calibration from flash data - that's what what drivers both in stock (QSDK) and OpenWrt do anyway.
For testing ensure that both firmwares use the same, and mostly empty channel if possible, and with the same channel width. On 2.4GHz, OpenWrt defaults to 20MHz channels, this might explain the difference, although I haven't really looked into 2.4GHz results.

@chunkeey, I found other device (Asus RT-AC57U) using the same boardData.bin file as this unit in its stock firmware - is it good enough premise to conclude, that custom board data is not needed? The test results also look very similar. OTOH I decoded and compared internal board data from OpenWrt versus stock, and there are substantial differences in binary. Are there any tools to parse them for wave2 chips?

"the test results also look very similar".
This is fine :slight_smile: .

If you compare the "pre-calibration" (in ART) with "boarddata.bin" then this would be expected for wave-2. If you compare "boarddata.bin" with other device's "boarddata.bin" (not board-2.bin as a whole)... Then well, the boarddata includes a length, checksum and a placeholder for the MAC-Address, some space for a "random comment" at the beginning. If only these differ then that would be fine, but not so much for the other fields.

Here are the official board-2.bin tools:

As for the binary-data within the individual board.bin: No, there aren't available. If you browse github you can sometimes find that a vendor provided a matching boarddata.txt file right next to the boarddata.bin. These boarddata.txt are consisting of rows and rows of STRING=VALUE lines... Now, the values are ending up in the boarddata.bin... And some of the "STRINGS" do provide an insight into what the byte/word/array is used for by the firmware.

Acknowledged. What I compared was the specific board.bin file ext
racted from stock firmware (not the pre-calibration itself) and the matching part extracted from board-2.bin by ath10k-bdencoder for bus=pci,bmi-chip-id=0,bmi-board-id=16 ID, which gets selected by ath10k on OpenWrt. I have the GPL code for this device, so I'll dig into that - maybe it's in the textual version there.
Edit: found it - it differs from what I found on the internet elsewhere, and from actual binary from the device. So I think it may be worthwhile to upstream it.

you would have seen those by now. If you can't measure any difference in range/performance, then it's likely fine as is... and if not, it can be added later.

@faloyeh you might want to take a look here: Problem with modem in ZTE MF286R - #34 by Leo-PL

Marvelous, thank you!

I was informed that the patch doesn't work yet, but we're really close.
I'll have some chance at testing tomorrow.

In the meantime, a friend gave me two modem-less MF286A's, with three modems to potentially unbrick, so I can measure the radio performance, at last :wink:

Just opened a PR with modem support:
Testing/reviewing very much appreciated.

@faloyeh and it got merged, to 22.03 release as well. This means we have complete support for the series, save for the obscure MF286C, I have yet to see in the wild. Hope it works well for you - I won't be surprised if another modem variant gets discovered.