mt76 can't read eeprom now, so it can't get the correct wireless calibration information. If the mt76 can read the eeprom, the wireless performance will be much improved.
From my previous experience, reading the eeprom correctly has a big impact on wireless performance.
3 Likes
Good point. I'll head out for now and see if you come back with anything about reading eeprom. Goodnight and I (we) appreciate your contributions!
1 Like
I went ahead and installed this, everything but the LED bar seems to be working perfectly! Speeds are fantastic! I don't have a fast enough internet link to see how well SQM+Cake is on here, but at 100mbit it doesn't even break a sweat. I suspect this might get very close to gigabit, especially since my RT3200 with 2 cores @1.35Ghz could do ~4-500 and this is 4 cores@2GHz.
How about wifi speed after the eeprom was reading correctly? Could you please compare it with AC3200 AC mode again?I hope the performance of MT7986 open source driver can reach the level of proprietary driver.
Yes here's my findings. I'll compare them to my RT3200 again.
AX6000 5GHz, 80MHz channels: Performance on Apple devices is horrible (6-12mbps at -68 RSSI, one wall between device and AP). Other devices speeds are great, mostly 600-700mbps, even had a RT3200 hit over 1gbps.
AX6000 5GHz, 160MHz channels: Performance on Apple devices appears normal, 200-300mbps iperf3 tests. 160MHz does appear to nerf my other E8450 in Client WDS mode (stuck at ~144mbps, almost like it locks to 802.11n).
This also doesn't make sense because Apple devices don't support 160MHz so I don't really understand how the channel bandwidth "fixes" that part. I tested both channel 36 and 161 in 80MHz channel width, both tests showed 6-12mbps on Apple devices so channel is likely ruled out. I'll reiterate this part as I mentioned in the other thread, seems like Apple devices get stuck in low power mode when their RSSI goes past RSSI somewhere past -60 ish.
Thanks for your test. What is the speed and mcs information displayed in the openwrt wireless overview when the apple device is at an abnormally low speed?
Idle (80MHz):
6.0 Mbit/s, 20 MHz
432.3 Mbit/s, 80 MHz, HE-MCS 4, HE-NSS 2
Active (running iperf3, 80MHz):
36.0 Mbit/s, 80 MHz, HE-MCS 0, HE-NSS 1
864.8 Mbit/s, 80 MHz, HE-MCS 8, HE-NSS 2
When in 160MHz mode and the Apple device is idle, tx rate drops to 6.0mbit/s. When device is active, speeds pick up to several hundred mbps. In 80MHz mode, idle has tx at 6mbit/s as well. When active, tx stays between 6.0mbit/s or up to 36mbit/s.
It looks like the problem may be caused by hibernation. Have you ever tried closing TWT?
This is the relevant commit. https://github.com/openwrt/mt76/commit/2f9555a2f18f5d6775e08cd739631a5096a8a472
I don't see anything related to TWT in my hostapd run file, so it shouldn't even be enabled, no?
Sorry I don't understand the configuration options of the mac80211 wireless driver. But I saw mtk's patch for TWT in mtk sdk.
Looks like my board fried itself. had it running all day, went to reboot, didn't come back up. stuck in u-boot and the console is all garbage, can't tftpboot, networking is broken. Uh oh.
So here's what happened (its fixed now). Original Xiaomi image has 2 ubi partitions as a failsafe. Something triggered it to fail over to the second one which prevented me from booting (boot loop). I did
setenv flag_try_sys1_failed 0
setenv flag_try_sys2_failed 0
which seem to be reset counters, then erased ubi partition and refreshed for good measure. I'm back up now.
TL;DR: 2 things need to be figured out/adjusted
- u-boot should remove option to boot second partition (might mean u-boot replacement like E8450/RT3200?)
- need to figure out what caused it to failover in the first place
3 Likes
fw_setenv boot_fw1 "run boot_rd_img;bootm" or nvram set boot_fw1="run boot_rd_img;bootm" ; nvram commit
It was necessary to save all the logs from the UART.
It is the system itself (and the kernel too) that decides when a terrible event occurs.
/etc/fw_env.config doesn't exist so fw_setenv isn't working. That's new.
echo "/dev/mtdX 0x0 0x10000 0x10000" > /etc/fw_env.config
Bootlooped again. Here's what I see once out of ATF:
Init_DRAM:2480: init PCDDR4 dram End
EMI: complex real chip dram calibration
Verify pattern 1 (0x00~0xff)...
EMI: mem8_base[0] = pattern8 = 0x0
Verify pattern 2 (0x00~0xffff)...
EMI: mem16_base[0] = pattern16 = 0x0
Verify pattern 3 (0x00~0xffffffff)...
detect button reset released!
Reading from 0x0 to 0x5f7fdd8c, size 0x4 ... OK
Boot failure detected on both systems
Reading from 0x0 to 0x5f7fdd8c, size 0x4 ... OK
Saving Environment to MTD... Erasing on MTD device 'nmbm0'... OK
Writing to MTD device 'nmbm0'... OK
OK
Booting System 1
resetting ...
Lemme reset a few more things
setenv boot_fw1 run boot_rd_img\;bootm
and
setenv boot_rd_img2 nand read \$\{loadaddr\} 0x2C0000 2000\;image_blks 2048\;nand read \$\{loadaddr\} 0x2C0000 \$\{img_align_size\}
reset counters:
setenv flag_try_sys1_failed 0
setenv flag_try_sys2_failed 0
Dunno if this will hold though, because setting boot_fw1 and boot_rd_img2 as above didn't kick it out of boot loop. U-boot replacement might be a better option.
1 Like
This vulnerability is very useful, it can be exploited and ssh is enabled, thanks for this constructive discovery
1 Like