Still getting "bad magic" by cat'ing mtd1{1,2,3}.bin .. the log is here:
https://drive.google.com/file/d/1Sou5Fqz97_6uGqxqxCaLk_eELi3QcgOZ/view?usp=sharing
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 192.0.0.1/8 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..
https://drive.google.com/drive/folders/169YUl7cI2t6LijVTJGsajqvgVACe2UDJ?usp=sharing
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 eko.one.pl 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 
.
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: https://github.com/qca/qca-swiss-army-knife/blob/master/tools/scripts/ath10k/ath10k-bdencoder
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.
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 
Just opened a PR with modem support: https://github.com/openwrt/openwrt/pull/9670
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.
I find that everything is working quite peachy otherwise, but, for me, enabling signal statistics sometimes causes the modem to stop working. I forget what the exact error message was, but something about a command not being cancelable. Perhaps a 30 seconds refresh-rate for signal statistics is too often, I don't know -- I haven't used any LTE-stuff with OpenWRT before.
This is great news, thank you! I haven't had a chance to give it a try yet, I'm sorry about that..
Works fine in last snapshot except(or i messed around official firmware layout) we need two options set
" Either way, if there is a partition named rootfs and MTD_ROOTFS_ROOT_DEV kernel config option is set to yes, this partition is automatically used for the root filesystem.
After that, if MTD_ROOTFS_SPLIT is enabled, the kernel adjusts the rootfs partition size to the minimum required by the particular SquashFS image and automatically adds rootfs_data to the list of the available mtd partitions setting its beginning to the first appropriate address after the SquashFS end and size to the remainder of the original rootfs partition. The resulting list is stored in RAM only, so no partition table of any kind gets actually modified."
Could you explain why do you think all that is needed? I haven't had any issue with the layout as-is, I haven't had to enable any extra kernel settings.
@sunnydrake, this should not be needed. UBI is used for rootfs_data on this family of devices, and is stored on the ubiconcat thing, with label "ubi" causing userspace to mount overlay there automatically.
i wiped my factory layout accidently and sysupgrade does not create squashfs or ubi filesystem correctly
so at boot time i get
[ 0.544346] spi-nand spi0.1: Winbond SPI NAND was found.
[ 0.549848] spi-nand spi0.1: 128 MiB, block size: 128 KiB, page size: 2048, OOB size: 64
[ 0.560702] 4 fixed-partitions partitions found on MTD device spi0.1
[ 0.567310] Creating 4 MTD partitions on "spi0.1":
[ 0.572268] 0x000000000000-0x000000080000 : "art"
[ 0.578465] 0x000000080000-0x000000100000 : "mac"
[ 0.585456] 0x000002000000-0x000008000000 : "rootfs"
[ 0.672227] mtd: device 2 (rootfs) set to be root filesystem
[ 0.679886] mtdsplit: no squashfs found in "rootfs"
[ 0.685031] 0x000001800000-0x000002000000 : "nand_kernel"
[ 0.703411] spi-nor spi0.0: mx25l1606e (2048 Kbytes)
[ 0.708632] 2 fixed-partitions partitions found on MTD device spi0.0
[ 0.715214] Creating 2 MTD partitions on "spi0.0":
[ 0.720169] 0x000000000000-0x0000000a0000 : "u-boot"
[ 0.726925] 0x0000000a0000-0x0000000c0000 : "u-boot-env"
so when i enter firstboot -y i usually get no rootfs_data device and that's it .. im stuck with tmpfs
check... looks like MTD_ROOTFS_SPLIT and MTD_ROOTFS_ROOT_DEV kicked out of kernel config somehow... So i found another cultprit it is missing uvol mounter and not mounting at all .. investigating
@Leo-PL thanks for suggestion