A few observations that I made earlier when I was looking at this firmware image earlier today (I probably won't end up getting one though, for those reading)
Wowee Mediatek, is that a 5.4 kernel in the vendor sdk? That's probably the newest kernel version I've seen in a shipping product... (They still use swconfig though. Probably don't have the time or desire to port their acceleration modules to DSA)
Oooooh, they're building the Arm Trusted Firmware (ATF) in their build system too...
I have no idea if this uses secure boot. The secboot upgrade script has return 0 hardcoded as usual, so there might not be any. On the other hand, I see an efuse node in the dtb.
Uses the new mediatek bad block management thing nmbm. OpenWrt master already has support.
There's no support for this in the current testing kernel we have at the moment. You would have to have to backport a few things.
Hooray a MTK platform with AX on both bands without having to stick in a MT7915D...
Xiaomi casually leaking the existence of a MT7981 in their kernel config. (Although there are references on the internet to the demo board + MT7976C anyway)
RB04 I think was the AX5400 gaming edition, RB08 is an unannounced (I think) one called HomeWiFi (I'm guessing a mesh by the name), soooo I guess that leaves... RB05 and RB07? They have too many 11ax models, it makes my head hurt.
FIP is u-boot I believe. The image header seems to suggest it's forked from 2022.01-rc1 from December.
The lack of 2.5G port(s) is a bit of a letdown, all things considered. Just one would have been nice. Not sure if this chipset had the dual HSGMII that would have made it viable.
According to a speculation in the review of the disassembly site, it is very likely to sell products that are "still available", and if the 2.5G network port is added, those products may lag.
According to my guess, this is actually a counterpart to the XDR6020, which debuted at 499RMB.
But if added, the competitor is not yet on sale XDR6088, then the price may also have to be much more.
Then I am more concerned that mt7986 was not added until 5.17 kernel, I wonder if it can be added as a bunch of patches and then added to openwrt for 5.10/5.15 kernel?
You can use ubireader to decompress the image.
After that you can use extract-dtb to get dtb, and then use dtc to convert dtb to dts and/or decompressing rootfs with unsquashfs.
FWIW, I've ordered one of these. Should be here in ~1 month. Never ported OpenWrt to a new device but am willing to learn and help if anyone is interested. I've got sufficient knowledge that it won't be too difficult.
For best experience FPS gaming should use wired (and not wireless) connection.
With that said, and using a wired connection, any modern router (dual core CPU or better) will (should) not impact your internet latency. Your route between your ISP and the game server will likely to have a bigger impact in latency than your router.
On the other hand you may be experiencing increased latency due to buffer bloat. If this is the case, research buffer bloat and configure SQM in your router to minimize this issue.
I don't think any vendor does any offload for cake, so that kind of applies to basically... everything. (Minus the platforms where you can just throw CPU at the problem like X86 and many of the SBC platforms with Cortex A72 or better)
This will probably top out at around 600mbit like the MT7622, which is a respectable amount. You may squeeze a little more out of fq_codel. Some on gigabit connections won't even bother with the downstream shaper at all.
The manner in which they're delivered matters not, since we have source for both. For any critical ethernet/wifi bug you'd just end up flashing a new image and kernel anyway. (Both mt76 and the mt753x switch driver are open source. While the wireless chipsets do use firmware blobs loaded by the driver, fixes to those would come from mediatek anyway, since they're not terrible people and send things upstream regularly)
Probably just stay on wired where humanly possible, while AQL should smooth things over in wireless, it remains shared medium.
You can’t yet and reading above, support likely won’t even be available until the master branch moves up to kernel 5.20. Glad to see it’s gaining traction though.
My device should be in in a couple days. Wondering where/how you found the link for this firmware. I'd like to be able to grab them in the future. I don't speak Chinese to find it easily.
The firmware goes up on the update servers a little while before showing up on the miwifi site.
It's a release channel image anyway, so usual restrictions apply.
You can still get uart access without beta images, so not too big a deal.
I'm not entirely sure what exactly causes a bungled recovery flash to get U-Boot menu working, probably a combination of them saving boot_wait=on before flash, in addition to bootdelay=3 in inbuilt defaults without specifying boot_wait=off as well. I just wonder if the same bug is present in this U-Boot version. (I don't have a dump of that since it wasn't in the image, and I've only remember seeing it included in AX9000 developer images.)
And no, I don't believe they build with CONFIG_IP_DEFRAG on either, for those who read the writeup of CVE-2022-30790 As fun as it would have been to use to patch instructions directly.