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

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.

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

@sunnydrake this is 286, not R nor A version, right?
For me, it looks like this:

[    0.387340] spi-nand spi0.1: GigaDevice SPI NAND was found.
[    0.393112] spi-nand spi0.1: 128 MiB, block size: 128 KiB, page size: 2048, OOB size: 128
[    0.403941] 6 fixed-partitions partitions found on MTD device (null)
[    0.410558] Creating 6 MTD partitions on "(null)":
[    0.415522] 0x000000000000-0x000000140000 : "fota-flag"
[    0.423651] 0x000000140000-0x000000280000 : "caldata"
[    0.432375] 0x000000280000-0x0000003c0000 : "mac"
[    0.440788] 0x0000003c0000-0x000001300000 : "ubiconcat0"
[    0.468951] 0x000001300000-0x000001700000 : "kernel"
[    0.481348] 0x000001700000-0x000008000000 : "ubiconcat1"
[    0.638013] spi-nor spi0.0: mx25l1606e (2048 Kbytes)
[    0.643193] 2 fixed-partitions partitions found on MTD device spi0.0
[    0.649811] Creating 2 MTD partitions on "spi0.0":
[    0.654761] 0x000000000000-0x000000080000 : "u-boot"
[    0.661810] 0x000000080000-0x0000000a0000 : "u-boot-env"
[    0.669211] Concatenating MTD devices:
[    0.673098] (0): "ubiconcat0"
[    0.676159] (1): "ubiconcat1"
[    0.679285] into device "ubi-concat"
[    0.683011] 1 fixed-partitions partitions found on MTD device ubi-concat
[    0.689945] Creating 1 MTD partitions on "ubi-concat":
[    0.695252] 0x000000000000-0x000007840000 : "ubi"

I see that your flash layout is totally different from upstream one.

In upstream, rootfs partition is in UBI as well, as typical for NAND devices. Maybe you're missing the right Kconfig for mtd-concat or UBI, or the right label?

An idea struck me, that it would indeed be possible to use uImage split, to combine kernel and rootfs dynamically on single MTD, but then there is no equivalent of "squashfs-split" parser used on NOR devices, for UBI, so we would probably lose more space than just allocating 4MB for kernel itself statically.

as i see layout was changed from my version to different in qca9563_zte_mf286.dts

&system_flash {
        partitions {
                partition@0 {
                        label = "fota-flag";
                        reg = <0x000000 0x140000>;

                partition@140000 {
                        label = "caldata";
                        reg = <0x140000 0x140000>;

                        compatible = "nvmem-cells";
                        #address-cells = <1>;
                        #size-cells = <1>;

                        cal_caldata_1000: cal@1000 {
                                reg = <0x1000 0x440>;

                        cal_caldata_5000: cal@5000 {
                                reg = <0x5000 0x844>;

                partition@280000 {
                        label = "mac";
                        reg = <0x280000 0x140000>;

                        compatible = "nvmem-cells";
                        #address-cells = <1>;
                        #size-cells = <1>;

                        macaddr_mac_0: macaddr@0 {
                                reg = <0x0 0x6>;

                /* This encompasses stock cfg-param, oops, web partitions,
                 * which can be overwritten safely
                ubiconcat0: partition@3c0000 {
                        label = "ubiconcat0";
                        reg = <0x3c0000 0xf40000>;

                /* Kernel MTD size is increased to 4MB from stock 3MB */
                partition@1300000 {
                        label = "kernel";
                        reg = <0x1300000 0x400000>;

                /* This encompasses stock rootfs, data, fota partitions,
                 * which can be overwritten safely
                ubiconcat1: partition@1600000 {
                        label = "ubiconcat1";
                        reg = <0x1700000 0x6900000>;

problem is openwrt sysupdate does not create new partitions :frowning:

OMG used erase command from uboot now flash is empty device is brick... need to reprogramm flash somehow

Erased NOR flash as well? If that's only NAND, U-boot will attempt TFTP recovery by itself, as detailed in the commit message:
If not, you can find it here: - in the CPE_boot_file subdirectory.
BTW, I don't see the reason for fiddling with flash layout and not using upstream one, it makes the most space available to the user already.