The code requires a huge cleanup before you can submit it to patchwork 
thats why i guess, we cannot do it…i have not much time for cleaning up this hugh folder…tried to do it a bit, but there is also much garbage in it (references to LTE,GPS-Driver in makefiles/code that is not existent)…there are many compiler-switches in the code currently not used.
maybe we can push code outside the driver/misc/mediatek-folder like watchdog and genetlink to avoid porting that every time…as a first step
@garywang / @Ryder.Lee: i made a pull-request for merging wlan-branch into 4.16-main…there i see some changes in cpu-section in dtsi:
cpu2: cpu@2 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x2>;
+ clocks = <&infracfg CLK_INFRA_CPUSEL>,
+ <&apmixedsys CLK_APMIXED_MAINPLL>;
+ clock-names = "cpu", "intermediate";
operating-points-v2 = <&cpu_opp_table>;
clock-frequency = <1300000000>;
};
should i remove that before merging or are they meaningful?
Any idea to bypass linaro-bug?
I doubt it is a linaro bug, I also spent some time on it with gcc 7, although not this one specific as far as I can remember. Couldn’t find it at the time either… but I suspect some shady coding, perhaps even compiler flags.
strange tried building 4.14-main (also with this wifi-driver) and no error occour…and this error/warning is not the only one in kernel 4.16…
e.g. this is outside the wifi-driver and also not compilable with gcc7-cross
drivers/usb/core/hcd.c:460:34: warning: '%s' directive output may be truncated writing up to 64 bytes into a region of size between 35 and 99 [-Wformat-truncation=]
snprintf (buf, sizeof buf, "%s %s %s", init_utsname()->sysname,
^~
init_utsname()->release, hcd->driver->description);
~~~~~~~~~~~~
drivers/usb/core/hcd.c:460:3: note: 'snprintf' output 3 or more bytes (assuming 131) into a destination of size 100
snprintf (buf, sizeof buf, "%s %s %s", init_utsname()->sysname,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
init_utsname()->release, hcd->driver->description);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make: *** [drivers] Error 2
for wifi-driver i can disable the following -Werror…but this is imho not the right way and does not solve compile-issues outside wifi-driver:
drivers/misc/mediatek/connectivity/common/Makefile:1:subdir-ccflags-y += -Werror -I$(srctree)/drivers/misc/mediatek/include/mt-plat/$(MTK_PLATFORM)/include
drivers/misc/mediatek/connectivity/common/Makefile:2:subdir-ccflags-y += -Werror -I$(srctree)/drivers/misc/mediatek/include/mt-plat
drivers/misc/mediatek/Makefile:15:subdir-ccflags-y += -WerrorTried to port driver to 4.18: Searching testing people for hdmi + wifi in Kernel 4.16
Sadly it crashes on loading firmware in hal_btif_hw_init
got wifi-driver working…i’m able to run hostapd on ap0 and can connect to it with 4.18-rc1 
see here for details: Searching testing people for hdmi + wifi in Kernel 4.16
tried porting driver back to 4.17 because 4.16 is EOL
- echo A
/usr/local/sbin/wifi.sh: line 64: echo: write error: Input/output error
https://github.com/frank-w/BPI-R2-4.14/tree/4.17-wlan
dmesg_4.17-wlan_wmt.txt (31,6 KB) dmesg_4.17-wlan_full.txt (118,4 KB)
fixed…the btif-enable-node in dts was missing
Hi Frank,
is there an image which contains 4.18rc1 with working WLAN for test? Try to have some headles ubuntu router for AP, Router and iobroker.
Kind regards
Daniel
there is no image because 4.18 is only rc
but you can download my debian/ubuntu-image and unpack a 4.18-wlan-kernel to it… had merged wlan yesterday to main-branch…
you can (maybe upgrade to 4.18-rc3 first,) compile it by yourself and install it to sd-card
i have uploaded last version here: https://drive.google.com/open?id=17MoFc3vIuGHDEV5SsCmGegJDr009IXls
bpi-r2_4.18.0-rc1_rc.tar.gz
just backup your existing uImage-File in BPI-BOOT/bananapi/bpi-r2/linux/ and look if kernel-var in uEnv.txt is set to uImage
Thanks Frank.
Where should I copy the WMT_SOC.cfg file to? There is no folder named “system” on my SD card (it is Your ubuntu-18.04-bpi-r2-preview.img … thank You for that too).
The file bpi-r2_4.18.0-rc1_rc.tar.gz does not yet contain the last commit from main-branch?
I compiled this yesterday and this is the last version.
You have to create that folder and imho one in etc. For wmt-files i have a tar-file containing all files and my script (simply unpack to rootfs) on my gdrive: https://drive.google.com/open?id=1MJxfHCpR-ph5YJu-_yMTCH5YG9rL6HHY
create a /etc/hostapd/hostapd_ap0.conf and run wifi.sh
for automatic creation this is simply done: wmt_loader.c:18++
#define WCN_COMBO_LOADER_DEV "/dev/wmtdetect"
gLoaderFd = open(WCN_COMBO_LOADER_DEV, O_RDWR | O_NOCTTY);
// Get Device ID
chipId = ioctl(gLoaderFd, COMBO_IOCTL_GET_SOC_CHIP_ID, NULL);
// Set Device ID
iRet = ioctl(gLoaderFd, COMBO_IOCTL_SET_CHIP_ID, chipId);
// do module init
iRet = ioctl(gLoaderFd, COMBO_IOCTL_DO_MODULE_INIT, chipId);
these values are handled here:
drivers/misc/mediatek/connectivity/common/common_detect/wmt_detect.c:83 static long wmt_detect_unlocked_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
so we need to place the wmtloader-code in wmt_detect.c instead of waiting for a file-operation
I’m trying to get things working on OpenWrt with 3.14 kernel and those drivers on top and having some problems with that. Either a device cannot connect claiming WPA handshake failed or, sometimes, it can connect but then works only for a couple of minutes, gets disassociated and continues to fail WPA handshakes then. I have custom patches that rename interfaces (to get OpenWrt play better with them) but apart from that it’s effectively @frank-w 's drivers port[1]. Any idea what is going wrong? Errors on hostapd side are pretty vague:
root@abbradarrouter:~# hostapd hostapd-mtkp2p0.conf
Configuration file: hostapd-mtkp2p0.conf
mtkap0: interface state UNINITIALIZED->COUNTRY_UPDATE
mtkap0: interface state COUNTRY_UPDATE->HT_SCAN
Using interface mtkap0 with hwaddr 02:08:22:00:0b:c6 and ssid "foo"
mtkap0: interface state HT_SCAN->ENABLED
mtkap0: AP-ENABLED
mtkap0: STA c4:0b:cb:85:b9:3b IEEE 802.11: associated
mtkap0: AP-STA-CONNECTED c4:0b:cb:85:b9:3b
mtkap0: STA c4:0b:cb:85:b9:3b WPA: pairwise key handshake completed (RSN)
mtkap0: STA c4:0b:cb:85:b9:3b IEEE 802.11: disassociated
mtkap0: AP-STA-DISCONNECTED c4:0b:cb:85:b9:3b
mtkap0: STA c4:0b:cb:85:b9:3b IEEE 802.11: associated
mtkap0: STA c4:0b:cb:85:b9:3b IEEE 802.11: disassociated
mtkap0: STA c4:0b:cb:85:b9:3b IEEE 802.11: associated
mtkap0: STA c4:0b:cb:85:b9:3b IEEE 802.11: disassociated
mtkap0: STA c4:0b:cb:85:b9:3b IEEE 802.11: associated
mtkap0: STA c4:0b:cb:85:b9:3b IEEE 802.11: disassociated
My hostapd configuration is pretty much barebones:
driver=nl80211
logger_syslog=127
logger_syslog_level=2
logger_stdout=127
logger_stdout_level=2
country_code=CN
hw_mode=g
channel=8
interface=mtkap0
wpa_passphrase=12345678
auth_algs=1
wpa=2
rsn_pairwise=CCMP
ssid=foo
bridge=br-lan
wpa_key_mgmt=WPA-PSK
1: https://github.com/frank-w/BPI-R2-4.14/commit/e6b369a5ade19206db433b46d0102ae000b87e99
Have you tried a higher debug-level? Some users experiencing problems with missing entropy from random-number-generator. Try install haveng
I’ve built a full-featured hostapd which has a debug log[1]. It’s as if at some point the chip stops sending and receiving messages. Notice that the first (successful) connection when during key exchange there are EAPOL_RX events and the next ones when there are no such events at all and key exchange timeouts.
I’ve tried installing haveged and also looked at diff between my and yours dts-es – there were some changes which I ported but it made no difference. If you have the radio working, can you show me your dmesg from the moment when you run wmt_loader till you have connection for some time?
1: https://gist.github.com/abbradar/b876c4358ae419940c37b9e8281a4edd
It will take a week because i’m away from home. But after that i can send you the log if you send me changed settings (loglevel,changes in binary)
Nah, that’s not going to help after all – I thought the problem is in Cannot find pinctrl defaulterror but I managed to solve it and nothing has changed.
Does anyone have a stable connection (by that I mean that fast.com running some time doesn’t kill the AP)? If so, on what kernel and did you make any tweaks to hostapd.conf or something else? I’m trying to get results with the official LEDE image now to see what’s different.
I’ve tested more and it turns out it works normally on official LEDE image. It’s also broken without my custom changes to connectivity driver meaning that possible reasons are:
- I’ve forgot to take some change from @frank-w’s tree;
- It doesn’t work on 4.14 at all.
Unfortunately I can’t just test @frank-w’s kernel because it’s not trivial to make OpenWrt run on it.
@frank-w @garywang how is combo chip connected to the CPU? I think which .dts changes may be relevant; I didn’t yet port fixes for SDIO for example. Could that be relevant?
In my mutiple tries to port (4.14, 4.16, 4.17, 4.18) i got no ap0 device if i forgot anything in dts(i).
Wifi-chip (mt6626l) is connected via btif (similar to uart). If this node is wrong (different compatible or clock) kernel crashes. If main-node is disabled you get timeout on echo A.
the problem looks more like wpasupplicant or similar is running (or just installed). Try to remove that if you found it
@abbradar how do you solve “Cannot find pinctrl default”-Error? I looked in hostapd-log on my router and found no eapol timeouts
Index: linux-4.14.53/drivers/misc/mediatek/connectivity/common/conn_soc/mt7623/mtk_wcn_consys_hw.c
===================================================================
--- linux-4.14.53.orig/drivers/misc/mediatek/connectivity/common/conn_soc/mt7623/mtk_wcn_consys_hw.c
+++ linux-4.14.53/drivers/misc/mediatek/connectivity/common/conn_soc/mt7623/mtk_wcn_consys_hw.c
@@ -116,7 +116,7 @@ static INT32 mtk_wmt_probe(struct platfo
WMT_PLAT_ERR_FUNC("Wmt cannot find pinctrl!\n");
goto set_pin_exit;
}
- mt6625_spi_default = pinctrl_lookup_state(mt6625_spi_pinctrl, "consys_pins_default");
+ mt6625_spi_default = pinctrl_lookup_state(mt6625_spi_pinctrl, PINCTRL STATE DEFAULT);
if (IS_ERR(mt6625_spi_default)) {
ret = PTR_ERR(mt6625_spi_default);
WMT_PLAT_ERR_FUNC("Wmt Cannot find pinctrl default!\n");
From my very limited understanding on newer kernels when there’s only one pinctrl state entry it’s placed under PINCTRL STATE DEFAULT. Anyway this doesn’t change anything, and I’m not even sure that’s needed – I think it’s done automatically by the kernel when there’s only one entry. Notice that this is all half-assumptions! Just to be sure earlier I listed all state entries in that place – only default is there.
1 Like