config device
option type '8021q'
option ifname 'wan'
option vid '100'
option name 'wan.100'
config device
option type '8021q'
option ifname 'br-lan'
option vid '100'
option name 'br-lan.100'
config device
option type 'bridge'
option name 'bridge-tv'
list ports 'br-lan.100'
list ports 'wan.100'
config interface 'tv'
option proto 'none'
option device 'bridge-tv'
A bunch of Lorenzo patches dropped yesterday on his repo for mt76. Lots of interesting references to mt7996 and npu, so maybe someone can figure out a way to get some wireless offloading love out of this.
I forked it and it does appear to compile cleanly.
After taking a break from it, I tore it all down and started fresh.
Somewhere along the way I must have fubar'd the pins or they weren't well seated.
Odd that it displayed on boot as you'd expect and did not exhibit normal serial port type issues like stair stepping, garbled data, etc. Just no keyboard.
I am back into the device, thanks to everyone for talking me off the ledge.
Glad to hear it. Working with it really isn’t too bad. I do cut off the left and right snaps leaving the front and the back to make it easier to get into.
One of the problems with the wifi in the Banana Pi BPI-R4 is incorrect eeprom power settings, leading to unsatisfactory wireless performance.
The original W1700k enabling patch by @andrewjlamarche did not load the eeprom correctly. This was subsequently fixed by @namidairo (who incidentally also cracked the vexing inoperative Realtek 10G bug.)
Nonethless, wireless works fine even without proper eeprom loading. Why?
Investigation
I used xxd /sys/kernel/debug/ieee80211/phy0/mt76/eeprom >> /tmp/eeprom.txt to get the eeprom from four devices. I then reverted @namidairo's patch so I can pull the default eeprom file that is used when the eeprom cannot be loaded.
Results
0x1300 (MT_EE_TX0_POWER_2G)
W1700k: 0x2C
default: 0x30
0x1301 (MT_EE_TX0_POWER_5G): a 5-byte table
W1700k: 0x2A 0x2A 0x2A 0x2A 0x27
default: 0x2B 0x2B 0x2B 0x2B 0x28
0x1310 (MT_EE_TX0_POWER_6G): a 8-byte table
W1700k: 0x28 0x2B 0x2B 0x2B 0x2B 0x2B 0x2B 0x2B
default: same
Interpretation
Loading the eeprom results in TX powers of 28dBm, 28dBm and 30dBm for 2G, 5G and 6G. If the eeprom load fails, the default file provides very similar but slightly higher TX powers of 30dBm, 29dBm and 30dBm.
Hello, why are all the offload statistics values 0 after installing airoha-npu? Also, the CPU usage is still very high when testing LAN<->WAN. Are there any switches that need to be configured? I'm using https://github.com/OpenWRT-fanboy/openw1700k to compile.
Hey great work. However I ran into a little hickup. I upgraded to the latest version (32220-openwrt-airoha-an7581-gemtek_w1700k-squashfs-sysupgrade.bin) and every thing works fine but radio0 only goes to 25dbm now. Radio1 now won't go higher then 24dbm. Radio2 won't go higher then 25dbm. Is this to be expected? Thanks for the work you are doing in the mean time. I can't wait for this router to one day be officially supported. It's such a great deal for what it is.
I can confirm the 320Mhz issue, I have a AX210 card was never able to connect via 6Ghz, switched to 160Mhz and it connect to 6Ghz right away. I have other router has the Qualcomm BE wifi7 chip and it connects fine under 320Mhz, so it might be the driver issue?
I checked on it now and all 3 radios are set to 28 to 29dbm and now are claimed to be running at those power levels too. I could have SWORN they were much lower. In fact I am sure of it. But it's working now. No idea why it did that. Using US CC too.
I don't know LoL. But it's working fine now so that's what matters.
I have now tested all the new mt76-npu-devel patches in Lorenzo's repo.
The good news is that they all compile cleanly and all but one do not seem to negatively affect stability or performance.
The bad news is that the patch named "Enable npu support for mt7996 devices" completely wrecks wireless function. And by the name of it, this seems like the critical one.
I've re-ordered the patch sequence so that this is the last patch. If you build from my repo, it will now pull in all but this patch.
Hopefully someone with more expertise than I can get us further in enabling wireless offload.
That seems to be the case from what others have reported. Looks like intel has developed a better linux driver than a windows one, at least as it pertains to 320Mhz.
It's certainly possible to test as you suggested, but not a lot of practical consequence in any case.
Regarding the GPS comma, if we could get the LED for the GPS module, we could get the PPS signal. It would be really awesome if we could get the PPS signal and use it for NTP.
