Good place to start digging, i’ve switched to new driver with 5.8 support, so it’s untested on R2.
this should not be r2-related as it is a usb-dongle which can be used also on x86. but maybe your channel-config / 5ghz regulatory db is set wrong
I’m not a good reader, and didn’t find the instructions for bringing up the BPi-R2 WLAN on boot, so I wrote my own systemd service files.
These are essentially @frank-w’s wifi.sh script in systemd service unit file form.
Save to /etc/systemd/system/stp_uart_launcher.service:
# Run the MT76 WiFi adapter stp_uart_launcher daemon
#
# This must be run before the mt76_wlan service
[Unit]
Description=MediaTek MT76 stp_uart_launcher daemon
Before=mt76_wlan.service
[Service]
User=root
Environment=PATH=/bin:/sbin:/usr/bin:/usr/sbin
Type=simple
ExecStartPre=/bin/bash -c "test -c /dev/wmtWifi || { /usr/bin/wmt_loader; /bin/sleep 3; }"
ExecStart=/usr/bin/stp_uart_launcher -p /etc/firmware
ExecStartPost=/bin/sleep 5
KillMode=process
KillSignal=SIGINT
Restart=on-failure
RestartSec=5
[Install]
WantedBy=mt76_wlan.service
Save to /etc/systemd/system/mt76_wlan.service:
# Run utilities to initialize the MT76 WiFi adapter
#
# This must be run before networking is started
[Unit]
Description=MediaTek MT76 WiFi adapter
Before=network-pre.target
Wants=stp_uart_launcher.service
[Install]
WantedBy=network-pre.target
[Service]
User=root
Environment=PATH=/bin:/sbin:/usr/bin:/usr/sbin
Type=oneshot
ExecStart=/bin/bash -c '/bin/echo 1 > /dev/wmtWifi'
ExecReload=/bin/bash -c '/bin/echo 0 > /dev/wmtWifi; /bin/sleep 5; /bin/echo 1 > /dev/wmtWifi'
ExecStop=/bin/bash -c '/bin/echo 0 > /dev/wmtWifi'
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
Enable and start as usual:
sudo systemctl daemon-reload
sudo systemctl enable stp_uart_launcher.service
sudo systemctl enable mt76_wlan.service
sudo systemctl start stp_uart_launcher.service
sudo systemctl start mt76_wlan.service
THANK YOU to the folks here for everything you’ve done to build a kernel that supports the R2 so well. I’ve been using mine for a year now without issues.
I’m still missing something after starting up the wlan0 interface.
The interface exists:
$ ip link show dev wlan0
10: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
link/ether 00:08:22:40:c4:fb brd ff:ff:ff:ff:ff:ff
But doesn’t seem configurable as a WiFi interface:
$ iwconfig wlan0
wlan0 no wireless extensions.
I only found one other such report, where @troumad had this problem, it either resolved itself or the fix wasn’t posted.
Hi
i bring up wifi on boot by calling wifi.sh in rc.local (needs to be activated in systemd first)
You want internal wifi in client-mode (not ap-mode)? Had not tested it yet…my wifi.sh is for ap-mode and device created is ap0
Troumad had problem with ethernet…wlan0 is only listed in output.
Which kernel do you use? Does it it work in earlier version (4.14,4.19)? Which image do you use (i experienced strange behaviour when using official images)? Can you post full dmesg? Any firewall active?
Is this the best place to do it? In the other post, you wrote:
These systemd units don’t have that problem, since they’re brought up before network-pre.target.
Correct. (This is used to provision wired hosts over PXE in a lab with no Ethernet.) You could bring up ap0 by adding a mt76_ap.service unit file, copied from mt76_wlan.service but instead using /bin/echo A > /dev/wmtWifi.
He actually had problems with both, although the Ethernet problems were the main focus of that thread. I’m referring to these bits, which appear to be the same problem I’m having:
4.14.189-bpi-r2-main, built yesterday from your repo, 4.14-main branch (rev. aa521b9a2417)
I can try. Which versions do you recommend?
I built this Stretch image myself with multistrap.
No, but isn’t this problem at a lower level? The interface can’t be brought up, so firewall settings can’t be applied yet.
Sure:
Thank you!
It’s a good point 
full ack.
Then you should try prior version 4.9-main/4.4-main (including patches from bpi)…i cannot add more functionality, but maybe i had broken driver while porting. As i do not know how to connect via commandline without wpa-supplicant (which is known to break ap-mode if installed) and i do not use client mode, i had not tested it
Dmesg looks good so far…fm/gps not available (first errors) and config-options not needed (only file itself).
The 4.4-main branch mysteriously wouldn’t even start booting the kernel, just a boot loop. I didn’t try hard to fix it.
The 4.9-main branch booted (but needed updates to uEnv.txt and fstab because the order of the SD card and internal MMC devices are reversed).
The wlan0 device now shows wireless extensions:
$ iwconfig wlan0
wlan0 Disconnected ESSID:""
Mode:Managed Access Point: Not-Associated Tx-Power=off
RTS thr=0 B Fragment thr:off
Power Management:off
Link Quality=0/100 Signal level=-65 dBm Noise level=0 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
But setting an ESSID fails with iwconfig wlan0 essid my-essid:
[ 19.547866] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 21.716460] ------------[ cut here ]------------
[ 21.721141] WARNING: CPU: 0 PID: 97 at net/wireless/sme.c:733 __cfg80211_connect_result+0x240/0x2dc
[ 21.730146] Modules linked in: mtk_thermal spi_mt65xx thermal_sys mt6577_auxadc pwm_mediatek ip_tables x_tables ipv6
[ 21.740754] CPU: 0 PID: 97 Comm: kworker/u8:1 Not tainted 4.9.212-bpi-r2-4.9-main #1
[ 21.748457] Hardware name: Mediatek Cortex-A7 (Device Tree)
[ 21.754004] Workqueue: cfg80211 cfg80211_event_work
[ 21.758875] [<c0112a5c>] (unwind_backtrace) from [<c010d054>] (show_stack+0x20/0x24)
[ 21.766584] [<c010d054>] (show_stack) from [<c03bafec>] (dump_stack+0xc4/0xd8)
[ 21.773777] [<c03bafec>] (dump_stack) from [<c012e768>] (__warn+0xf8/0x110)
[ 21.780702] [<c012e768>] (__warn) from [<c012e850>] (warn_slowpath_null+0x30/0x38)
[ 21.788238] [<c012e850>] (warn_slowpath_null) from [<c085df7c>] (__cfg80211_connect_result+0x240/0x2dc)
[ 21.797586] [<c085df7c>] (__cfg80211_connect_result) from [<c0834718>] (cfg80211_process_wdev_events+0x154/0x194)
[ 21.807794] [<c0834718>] (cfg80211_process_wdev_events) from [<c0834794>] (cfg80211_process_rdev_events+0x3c/0x70)
[ 21.818087] [<c0834794>] (cfg80211_process_rdev_events) from [<c082ea80>] (cfg80211_event_work+0x24/0x2c)
[ 21.827603] [<c082ea80>] (cfg80211_event_work) from [<c0149a04>] (process_one_work+0x190/0x498)
[ 21.836258] [<c0149a04>] (process_one_work) from [<c014a814>] (worker_thread+0x60/0x578)
[ 21.844308] [<c014a814>] (worker_thread) from [<c014fef8>] (kthread+0x108/0x120)
[ 21.851671] [<c014fef8>] (kthread) from [<c0108cd0>] (ret_from_fork+0x14/0x24)
[ 21.858915] ---[ end trace 31af6edb32f3e655 ]---
After this traceback, running sudo bash -c 'echo 0 > /dev/wmtWifi successfully removes the wlan0 interface, but then sudo bash -c 'echo 1 > /dev/wmtWifi usually triggers another traceback, and if not, iwconfig wlan0 essid my-essid does.
Tried 4.4 long time no more…only did some updates (only compiling).
Ok,intersting first step in 4.9 works. These are vendor patches i ported to 4.14. Seems like i made a mistake here. The traceback is only a warning (warn_on) at net/wireless/sme.c:733 __cfg80211_connect_result
We need to find differences in both versions…afair i did only porting,no much cleanup. The patches in 4.9 were from vendors openwrt/lede i only applied to 4.9 and only updating the tree some time.you can easily swap mmc in dtsi (put mmc1 before mmc0)
For 4.4 you could try my fork from official which should be bootable:
But build.sh is a bit different
edit: made a quick diff between 4.9-main and 4.14-main
config MTK_WAPI_SUPPORT
bool "MTK_WAPI_SUPPORT"
depends on MTK_COMBO_WIFI
- default y
+ #default y
help
if it is set to TRUE: Support WAPI (WLAN Authentication and
Privacy Infrastructure)
maybe this is needed for client-support?
i see i did some cleanup too…but that does not affect client-mode because it was not compiled in…afair there were some redundant (header) files
maybe you can trace the functions called for client-mode in 4.9 and then add same debug to 4.14?
this may break client-mode:
drivers/misc/mediatek/connectivity/wlan/gen2/os/linux/gl_kal.c
@@ -1601,7 +1602,7 @@ WLAN_STATUS kalRxIndicatePkts(IN P_GLUE_INFO_T prGlueInfo, IN PVOID apvPkts[], I
STATS_RX_PKT_INFO_DISPLAY(prSkb->data);
- prNetDev->last_rx = jiffies;
+ //prNetDev->last_rx = jiffies;
prSkb->protocol = eth_type_trans(prSkb, prNetDev);
prSkb->dev = prNetDev;
/* DBGLOG_MEM32(RX, TRACE, (PUINT_32)prSkb->data, prSkb->len); */
@@ -1751,11 +1752,22 @@ kalIndicateStatusAndComplete(IN P_GLUE_INFO_T prGlueInfo, IN WLAN_STATUS eStatus
/* CFG80211 Indication */
if (eStatus == WLAN_STATUS_ROAM_OUT_FIND_BEST) {
- cfg80211_roamed_bss(prGlueInfo->prDevHandler,
+ /*cfg80211_roamed_bss(prGlueInfo->prDevHandler,
bss,
prGlueInfo->aucReqIe,
prGlueInfo->u4ReqIeLength,
prGlueInfo->aucRspIe, prGlueInfo->u4RspIeLength, GFP_KERNEL);
+ */
+ struct cfg80211_roam_info roam_info = {
+ .bss = bss,
+ .req_ie = prGlueInfo->aucReqIe,
+ .req_ie_len = prGlueInfo->u4ReqIeLength,
+ .resp_ie = prGlueInfo->aucRspIe,
+ .resp_ie_len = prGlueInfo->u4RspIeLength
+ };
+ cfg80211_roamed(prGlueInfo->prDevHandler,
+ &roam_info,
+ GFP_KERNEL);
} else {
/* to support user space roaming, cfg80211 will change the sme_state to connecting
before reassociate */
also this looks like ssid-related
--- a/drivers/misc/mediatek/connectivity/wlan/gen2/mgmt/p2p_fsm.c
+++ b/drivers/misc/mediatek/connectivity/wlan/gen2/mgmt/p2p_fsm.c
@@ -1489,17 +1489,20 @@ VOID p2pFsmRunEventScanRequest(IN P_ADAPTER_T prAdapter, IN P_MSG_HDR_T prMsgHdr
}
u4ChnlListSize = sizeof(RF_CHANNEL_INFO_T) * prScanReqInfo->ucNumChannelList;
+
kalMemCopy(prScanReqInfo->arScanChannelList, prP2pScanReqMsg->arChannelListInfo, u4ChnlListSize);
/* TODO: I only take the first SSID. Multiple SSID may be needed in the future. */
/* SSID */
- if (prP2pScanReqMsg->i4SsidNum >= 1)
- kalMemCopy(&(prScanReqInfo->rSsidStruct), prP2pScanReqMsg->prSSID, sizeof(P2P_SSID_STRUCT_T));
+ if (prP2pScanReqMsg->i4SsidNum >= 1 && prP2pScanReqMsg->prSSID)
+ kalMemCopy(&(prScanReqInfo->rSsidStruct), prP2pScanReqMsg->prSSID, sizeof(prScanReqInfo->rSsidStruct));
else
prScanReqInfo->rSsidStruct.ucSsidLen = 0;
/* IE Buffer */
- kalMemCopy(prScanReqInfo->aucIEBuf, prP2pScanReqMsg->pucIEBuf, prP2pScanReqMsg->u4IELen);
+ kalMemCopy(prScanReqInfo->aucIEBuf,
+ prP2pScanReqMsg->pucIEBuf,
+ prP2pScanReqMsg->u4IELen > CFG_IE_BUFFER_SIZE? CFG_IE_BUFFER_SIZE : prP2pScanReqMsg->u4IELen);
prScanReqInfo->u4BufLength = prP2pScanReqMsg->u4IELen;
btw. tested current 4.4-main…have no bootloop…only a warning for mfd-driver
root@bpi-r2:~# uname -a Linux bpi-r2 4.4.177-BPI-R2-Kernel-00029-g4ad8f399c829 #122 SMP Sat Aug 1 09:39:05 CEST 2020 armv7l GNU/Linux
[ 4.904431] WARNING: CPU: 0 PID: 1 at drivers/mfd/mfd-core.c:214 mfd_add_device+0x364/0x38c()
...
[ 4.970889] [<c076ba6c>] (mfd_add_device) from [<c076bb74>] (mfd_add_devices+0xa0/0x10c)
[ 4.978957] [<c076bb74>] (mfd_add_devices) from [<c076bc74>] (devm_mfd_add_devices+0x78/0xb8)
[ 4.987459] [<c076bc74>] (devm_mfd_add_devices) from [<c076c89c>] (mt6397_probe+0x1b4/0x1d4)
[ 4.995875] [<c076c89c>] (mt6397_probe) from [<c0699018>] (platform_drv_probe+0x60/0xbc)
[ 5.003945] [<c0699018>] (platform_drv_probe) from [<c0697184>] (driver_probe_device+0x1e0/0x2ec)
[ 5.012789] [<c0697184>] (driver_probe_device) from [<c0697324>] (__driver_attach+0x94/0x98)
[ 5.021201] [<c0697324>] (__driver_attach) from [<c06952a0>] (bus_for_each_dev+0x88/0xac)
[ 5.029355] [<c06952a0>] (bus_for_each_dev) from [<c0696a30>] (driver_attach+0x2c/0x30)
[ 5.037336] [<c0696a30>] (driver_attach) from [<c0696670>] (bus_add_driver+0x1d0/0x214)
[ 5.045318] [<c0696670>] (bus_add_driver) from [<c0697d78>] (driver_register+0x88/0x104)
[ 5.053386] [<c0697d78>] (driver_register) from [<c0698f24>] (__platform_driver_register+0x50/0x58)
[ 5.062406] [<c0698f24>] (__platform_driver_register) from [<c10903bc>] (mt6397_driver_init+0x1c/0x20)
[ 5.071684] [<c10903bc>] (mt6397_driver_init) from [<c0009708>] (do_one_initcall+0xa0/0x1f8)
Maybe it’s caused by modifications by poweroff-patch (https://github.com/frank-w/BPI-R2-4.4/commit/b8da54ae8e458cbff31e8e25fe56ac9db45279c8#diff-f6e9ae435447a08e357a3335e06dbabd original: #1 #2) and an update…afair there was a conflict,maybe i had not solved it completely
looking on https://github.com/frank-w/BPI-R2-4.4/commit/b8da54ae8e458cbff31e8e25fe56ac9db45279c8#diff-633d2d2a958e322669dbabaa80faaefc i guess pmic->irq_domain is not allocated
it’s definitely the last param (irq-domain)
https://github.com/frank-w/BPI-R2-4.14/blob/4.4-main/drivers/mfd/mfd-core.c#L213
but this warn_on also exists in old 4.4, so it seems that pmic->irq_domain is wrong
poweroff is not working in 4.4-main, if setting irq_daomain-param to NULL fixes warning, but not the poweroff itself. irq_domain is set in drivers/mfd/mt6397-core.c mt6397_irq_init()
mt6397->irq_domain = irq_domain_add_linear(mt6397->dev->of_node,
MT6397_IRQ_NR, &mt6397_irq_domain_ops, mt6397);
and should result in error “could not create irq domain” if it fails (return -ENOMEM)
4.4.160 (commit where i copied source from other repo in) does not have this warning (.169 have it…so i try to bisect further), but also poweroff does not work, official kernel is not buildable with current gcc, so i cannot verify poweroff is working there
for ssid-issue you could try adding some debugs around this point (4.9-main)
and compare with 4.14, maybe try to list bss first instead of try to connect to a specific one? maybe no bssid is found…and so you can’t connect to any. you have attached an antenna to r2??
Wow, thanks for all this effort!
I’m prepared to help look at this a little, but stepping back, I’m not quite sure what the strategy is.
You tested the 4.4-main branch and successfully booted; great! (I probably didn’t install it correctly.) I can’t tell if you got WiFi client mode working though; did you?
If so, the 4.4-main branch makes a great base case to start from while debugging 4.9 or 4.14 drivers. Is that what you’re thinking? I can try to get 4.4-main working and trace the functions in 4.9 and/or 4.14 branches.
If not, I have almost no familiarity with WiFi driver code, and I’m not sure what I can do to help. If you feel like hand-holding me through some specific tests, I can do that if you think we can get it done in less than, say, ten iterations.
Best is if we can start from a known-working base case and compare with other branches.
i want 4.4 booting without errors (to verify client mode is working there) to have a base for comparing whats not working in 4.9…
but please try to find difference between 4.9 and 4.14 which was my main porting work…if we get 4.14 to same point as 4.9, i can patch all further versions.
comparing 4.4 to 4.9 may show us problem persists in 4.9. we cannot compare wifi-driver between 4.4 and 4.9 directly because much more has changed…we need to find problem in 4.9 (which is patch-base for 4.14+)
i cannot test wifi client-mode because it needs installing wpa-supplicant which breaks ap-mode
OK, as a first step I’m going to go back to 4.4 in hopes that client mode works, even though 4.9 is difficult to compare.
4.9 still doesn’t work, though; even though iwconfig wlan0 shows wireless extensions, the basic functionality of setting an ESSID doesn’t work. Getting 4.14 to that same state won’t help my case. (Sorry to be selfish when you’re so generous!)
You might be able to, actually: just set up an open AP; then you can test with iwconfig wlan0 essid myopenap. No wpa-supplicant required.
i know, that 4.9 does not work completely, but wifi-driver is very large codebase and i first need to know where i need to start…so we have a difference between the 4.9-code (that was my base for 4.14) and 4.14…anything in these (relatively small amount of) changes breaks first step of client-mode…if we have 4.14 at same state as 4.9 we can start at location we know to fix the rest of client-mode
currently i’m at same 4.4.160, but still warning
It turns out that the 4.4-main branch has the same issues as 4.9-main: sudo iwconfig wlan0 essid myopenap prints the same kernel backtrace. Same as 4.9-main, the sudo iwlist wlan0 scan command successfully lists APs.
So that means we don’t have a working base case to start from. Even if we get 4.14 to the same state as 4.9, on-board WiFi in client mode still won’t work.
If you have any suggestion for how to fix this more fundamental problem, I’m interested. If so, I’d prefer to start with the 4.9 branch, since it appears a little closer to working than the 4.14 branch, and the 4.4 branch doesn’t seem to have support for the switch (based on my 5-minute trial just now).
ok, thanks for the test. so we start at 4.9 and need to know why connection fails.
as i wrote above the warning happens here:
so first we need to check if the bss-param of __cfg80211_connect_result is NULL/invalid. if it’s invalid we need to check where this function is called and where the wrong bss comes from
btw. 4.4 has support for switch, but no dsa-driver for separting all ports (eth0 are lan-ports, eth1 is wan-port).
booted up 4.9, initialized wifi and make scan
/usr/bin/wmt_loader
/usr/bin/stp_uart_launcher -p /etc/firmware &
echo 1 >/dev/wmtWifi
iwlist wlan0 scan
and see my (encrypted) AP
tried connecting it
iwconfig wlan0 essid r2_AP0
no output…
I’ll try.
Interesting. Does iwconfig wlan0 show you’re associated to r2_AP0 after that?
I don’t think so…have not checked (already off),but it have not asked for pwd…so i guess it does not work. But also not the warning and not my debug-info
i guess it’s rejected before it…need to setup ap with my r64 first 
Only running iwconfig wlan0 essid r2_AP0 won’t ask for a password; it will simply associate to the base station. Then it’s up to wpa-supplicant to take care of authentication. Next time you turn it on, give it a try; could be that wlan0 associated!
In any case, I wonder why you’re getting different results.
This call to cfg80211_get_bss() is returning NULL:
Which means cfg80211_get_bss() is failing to find a matching base station:
I wonder if you’re seeing success because your AP uses 802.11 privacy whereas mine does not? That could explain different results.
not connected…had put wlan0 up before
9: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN grou0
link/ether 00:08:22:34:84:fc brd ff:ff:ff:ff:ff:ff
root@bpi-r2:~# iwconfig wlan0 essid r2_AP0
root@bpi-r2:~# iwconfig wlan0
wlan0 Disconnected ESSID:""
Mode:Managed Access Point: Not-Associated Tx-Power=off
RTS thr=0 B Fragment thr:off
Encryption key:off
Power Management:off
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
but strange anyway that i did not get the error you got…ok, with unencrypted ap, i got the warning…
root@bpi-r2:~# iwconfig wlan0 essid r64_APi
root@bpi-r2:~# iwlist wlan0 scan[ 397.946902] DEBUG: Passed __cfg80211_connect0
[ 397.953460] ------------[ cut here ]------------
[ 397.958078] WARNING: CPU: 1 PID: 595 at net/wireless/sme.c:734 __cfg80211_coc
maybe encrypted waits in background for wpa-supplicant?
my debug says that bss given on that function is also 0x0
DEBUG: Passed __cfg80211_connect_result 667 bss:0x00000000OK, so maybe this only affects open APs. I could totally be wrong about iwconfig wlan0 essid encrypted_ap; iwconfig wlan0 showing an associated base station. I don’t have a way to test right now, though.
Anyway, I tried to track down exactly where things were going wrong yesterday, but didn’t get a final answer. Here is the dmesg after running iwconfig wlan0 essid 'Los Abuelitos' with debugging enabled (and my own debug statements, including diffs):
Starting at line 139 in the dmesg log, you can see where cfg80211_get_bss() (in net/wireless/scan.c) is checking for base stations matching the requested ESSID. In the first two calls, the ssid string contained the ESSID (plus junk), but apparently there were no base stations listed in the rdev->bss_list. In the third call, the ssid string contained only junk in the ssid string, and while there was a base station in the rdev->bss_list, obviously it couldn’t be matched.
That’s all the tracing I can do on my own, since I don’t know which call to cfg80211_get_bss() should have succeeded, or how the interfaces all work. Let me know if you have any good ideas about where to go from here. I’ll install a miniPCIe card if we can’t figure this out, not a problem.