Red MT7697 WiFi


It looks like official support for the built-in WiFi on Red is waiting for a kernel that supports the mac/cfg80211 modules.

Eager to get this working ahead of time, I built a custom Yocto image that enables the WEXT Wireless Extensions (see 2-mt7697wifi_core.mdef), and removed the ti-compat-wireless related elements for the IoT WiFi module I should no longer need.

I followed the mtwifi script to setup and install the wifi module on the uart interface as wlan1, but it appears the uart bus is not receiving anything from the mt7697 module: particularly the GET CONFIG response. What am I missing?

Here is the relevant section of dmesg, with dynamic debugging enabled on all the mt7697 kernel modules:

[ 19.357271] mt7697core init
[ 19.377353] mt7697core mt7697core: mt7697_probe(): probe
[ 19.405859] mt7697core mt7697core: mt7697_probe(): hw_itf(‘uart’)
[ 19.405920] mt7697core mt7697core: mt7697_cfg80211_init(): init mt7697 cfg80211
[ 19.424019] mt7697core mt7697core: mt7697_cfg80211_init(): wiphy registered
[ 19.424355] mt7697core mt7697core: mt7697_init_hw_start(): open mt7697 uart
[ 19.424385] mt7697_uart_open(): find UART device(‘mt7697serial’)
[ 19.474408] mt7697serial mt7697serial: mt7697_uart_open(): open serial device ‘/dev/ttyHS0’
[ 19.589806] mt7697serial mt7697serial: mt7697_uart_open(): fd_hndl(cdfe5c00)
[ 19.589897] mt7697core mt7697core: mt7697_wr_set_radio_state_req(): <-- SET RADIO STATE(0) len(8)
[ 19.589897] mt7697serial mt7697serial: mt7697_uart_write(): len(2)
[ 19.590019] mt7697serial mt7697serial: mt7697_uart_write(): written(8)
[ 19.590050] mt7697serial mt7697serial: mt7697_uart_write(): return(2)
[ 19.590080] mt7697core mt7697core: mt7697_wr_cfg_req(): <-- GET CONFIG len(4)
[ 19.590111] mt7697serial mt7697serial: mt7697_uart_write(): len(1)
[ 19.590172] mt7697serial mt7697serial: mt7697_uart_write(): written(4)
[ 19.590172] mt7697serial mt7697serial: mt7697_uart_write(): return(1)

At this point I would expect to see “–> GET CONFIG RSP”, but the mt7697 module is not responding on ttyHS0 / UART0. I followed the David’s wiki instructions to build and install the mt7697 firmware, and verified messages were printed to the console with switches 1, 3, 6, and 8 set.

Wifi on MangOH_RED not works

Two things to check here:

First was the MT7697 built for serial transport. To check goto the GCC/ and check the SWI_SPI_ENABLE (should be = n) and the SWI_UART_ENABLE (should be = y).

Second insure AT port settings are correct by doing following:

  • on the device run microcom -E /dev/ttyAT
  • execute at!entercnd=“A710”
  • execute at!mapuart=17,1


Thank you for the suggestions, but I verified both things (being the defaults) were already set on my device.

The LinkIt MT7697 image was already set to UART not SPI:

swi wifi transport


The UART1 service was already set to the default 17=Customer Linux application:

!MAPUART: 17,16

I tried setting it again and restarting for good measure, but found it had no effect as expected.

Looking over the documentation further, could this be related to MTK_TO_WP_UART_EN GPIO expander signal? I am using a WP7504 as my CF3 and the documentation says this signal “connects CF3 UART1 to Wi-Fi/BT chipset UART0”. I will look into it next.

Any other suggestions would be greatly appreciated. I chose the Red specifically for the built-in WiFi and am very eager to get my prototype running.


Can you confirm also that the MT7697 is not in programming mode - if u switch pin 6 up to switch the console to the MT7697 do u see a series of ‘C’`s or do u u see the MT7697 app starting up ok - u should also see in msgs that it is using UART


This is ALL I ever see on the console when I flip on switch 6 and reset:

loader enable 30s timeout
loader init
fota: TMP is empty, skip upgrade
jump to (0x10079000)

Does this make any sense? From what you mention, it sounds like I should expect something else. I’ll try rebuilding + reflashing.


It turns out there was an error building the MT7697 firmware:

Makefile:395: recipe for target ‘/home/mangoh/LinkIt_SDK/out/linkit7697_hdk/MT7697_WiFi_BT_fw/MT7697_WiFi_BT_fw.elf’ failed
make: Leaving directory '/home/mangoh/LinkIt_SDK/project/linkit7697_hdk/apps/MT7697_WiFi_BT_fw/GCC’
Build CM4 Firmware…Done
./ linkit7697_hdk MT7697_WiFi_BT_fw bl
Start Build: Tue Nov 21 23:20:39 EST 2017
End Build: Tue Nov 21 23:21:43 EST 2017

From the error log:

arm-none-eabi-gcc: error: …/…/…/…/…/out/linkit7697_hdk/MT7697_WiFi_BT_fw/obj/kernel/rtos/FreeRTOS/Source/portable/GCC/ARM_CM4F/port.o: No such file or directory
make: *** [/home/mangoh/LinkIt_SDK/out/linkit7697_hdk/MT7697_WiFi_BT_fw/MT7697_WiFi_BT_fw.elf] Error 1

I’ll see if I can get a successful build. NOTE: I am trying to build on the Ubuntu 16.04 Legato VM from


john can u share command line u are using to build MT7697 application if you are still having problems - dave


I am bulding the MT7697 application with the command specified in the wiki:

./ linkit7697_hdk MT7697_WiFi_BT_fw bl

It looks like the latest commit of the application does not compile with the latest “SDK for GCC/IAR” from the MediaTek website. I had to #define HAL_DWT_MODULE_ENABLED in inc/hal_feature_config.h to compile kernel/rtos/FreeRTOS/Source/portable/GCC/ARM_CM4F/port.c, and make a few other small changes to get the firmware to compile.

My MT7697 is now receiving UART commands when I insmod the wifi module (mtwifi shell script), as shown from the console (dipswitch 6 on):

[T: 971941 M: common C: info F: swi_wifi_proc_set_radio_state_req L: 1126]: --> SET RADIO STATE(8)
[T: 971946 M: common C: info F: swi_wifi_proc_set_radio_state_req L: 1145]: opmode(1)
[T: 971947 M: common C: info F: swi_wifi_proc_set_radio_state_req L: 1153]: set radio(0)
[T: 971970 M: common C: info F: swi_wifi_proc_set_radio_state_req L: 1163]: <-- SET RADIO STATE rsp len(8) result(0)
[T: 971970 M: common C: info F: swi_wifi_proc_get_cfg_req L: 879]: --> GET CONFIG(4)
[T: 971979 M: common C: info F: swi_wifi_proc_get_cfg_req L: 891]: opmode(1)
[T: 971980 M: common C: info F: swi_wifi_proc_get_cfg_req L: 899]: STA SSID(11/‘MTK_SOFT_AP’)
[T: 971990 M: common C: warning F: swi_wifi_proc_get_cfg_req L: 903]: wifi_config_get_bssid() failed(-1)
[T: 971991 M: common C: info F: swi_wifi_proc_get_cfg_req L: 915]: STA password(8/‘12345678’)
[T: 971991 M: coon C: info F: swi_wifi_proc_get_cfg_req L: 964]: <-- GET CONFIG rsp len(220) result(0)
[T: 971995 M: common C: info F: swi_wifi_proc_get_listen_interval_req L: 1193]: --> GET LISTEN INTERVAL(4)
[T: 972012 M: common C: info F: swi_wifi_proc_get_listen_interval_req L: 1207]: listen interval(1)
[T: 972012 M: common C: info F: swi_wifi_proc_get_lsten_interval_req L: 1212]: <-- GET LISTEN INTERVAL rsp len(12) result(0)
[T: 972012 M: common C: info F: swi_wifi_proc_get_radio_state_req L: 1066]: --> GET RADIO STATE(4)
[T: 972019 M: common C: info F: swi_wifi_proc_get_radio_state_req L: 1078]: opmode(1)
[T: 972033 M: common C: info F: swi_wifi_proc_get_radio_state_req L: 1089]: radio stae(0)
[T: 972033 M: common C: info F: swi_wifi_proc_get_radio_state_req L: 1095]: <-- GET RADIO STATE rsp len(12) result(0)
[T: 972033 M: common C: info F: swi_wifi_proc_get_wireless_mode_req L: 749]: --> GET WIRELESS MODE(8)
[T: 972033 M: common C: info F: swi_wifi_proc_get_wireless_mode_req L: 769]: wireless mode port(0)
[T: 972047 M: commn C: info F: swi_wifi_proc_get_wireless_mode_req L: 777]: wireless mode(9)
[T: 972070 M: common C: info F: swi_wifi_proc_get_wireless_mode_req L: 782]: <-- GET WIRELESS MODE rsp len(12) result(0)
[T: 972070 M: common C: info F: swi_wifi_proc_mac_addr_req L: 685]: --> GET MAC ADDRESS(8)
[T: 972070 M: common C: info F: swi_wifi_proc_mac_addr_re L: 705]: MAC address port(0)
[T: 972110 M: common C: info F: swi_wifi_proc_mac_addr_req L: 713]: MAC
00 0C 43 76 87 22
[T: 972110 M: common C: info F: swi_wifi_proc_mac_addr_req L: 718]: <-- GET MAC ADDRESS rsp len(16) result(0)

For some reason there was already one byte in the UART buffer, so I had to send three more to clear it before adding the wifi module:

echo -en ‘\x00\x00\x00’ > /dev/ttyHS0

Switching back to the WP7504 console, I can also verify that it is receiving responses from the MT7697. However, now something is causing a “kernel oops” and automatic restart every time I load the wifi module:

[ 165.018098] mt7697core mt7697core: mt7697_wr_set_radio_state_req(): <-- SET RADIO STATE(0) len(8)
[ 165.018159] mt7697serial mt7697serial: mt7697_uart_write(): len(2)
[ 165.018281] mt7697serial mt7697serial: mt7697_uart_write(): written(8)
[ 165.018281] mt7697serial mt7697serial: mt7697_uart_write(): return(2)
[ 165.018312] mt7697core mt7697core: mt7697_wr_cfg_req(): <-- GET CONFIG len(4)
[ 165.018373] mt7697serial mt7697serial: mt7697_uart_write(): len(1)
[ 165.018434] mt7697serial mt7697serial: mt7697_uart_write(): written(4)
[ 165.018434] mt7697serial mt7697serial: mt7697_uart_write(): return(1)
[ 165.060125] mt7697serial mt7697serial: mt7697_uart_rx_poll(): Rx data
[ 165.060186] mt7697serial mt7697serial: mt7697_uart_read(): len(8)
[ 165.060247] mt7697serial mt7697seria[ 165.188768] Internal error: Oops - bad syscall: 9b10f0 [#1] PREEMPT ARM
[ 165.197802] Modules linked in: 2_mt7697wifi_core(O) spisvc(O) 9_mangoh_red_dv5(O) 4_bmi160_i2c(O) 3_bmp280_i2c(O) 3_bmi160(O) 2_iio_triggered_buffer(O) 2_bmp280(O) 1_mt7697serial(O) 1_mt7697q(O) 1_mcp251x(O) 1_iio_kfifo_buf(O) 0_ltc294x(O) 0_iot_slot(O) 0_iio(O) 0_cp2130(O) 0_can_dev(O) 0_bq24296(O) xt_hl nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_tcpudp ipv6 xt_conntrack nf_conntrack iptable_filter ip_tables x_tables mac80211 cfg80211 msm_sdcc usb_storage sd_mod scsi_mod unix
[ 165.244590] CPU: 0 PID: 59 Comm: kworker/0:2 Tainted: G O 3.14.29ltsi-961ca71325_ab5094eade #12
[ 165.254143] Workqueue: events mt7697_uart_rx_work [1_mt7697serial]
[ 165.260277] task: cf2ef900 ti: cea9c000 task.ti: cea9c000
[ 165.265710] PC is at mt7697_exit+0xd1c/0x34 [2_mt7697wifi_core]
[ 165.271570] LR is at 0x41ca8
[ 165.274439] pc : [] lr : [<00041ca8>] psr: a00f0013
[ 165.274439] sp : be937c64 ip : cc67a004 fp : cea9de1c
[ 165.285884] r10: 00000000 r9 : cc67a000 r8 : c0aa4580
[ 165.291103] r7 : 00000002 r6 : bf2c7c58 r5 : 00000000 r4 : cc67a000
[ 165.297604] r3 : bf2c3708 r2 : cf154800 r1 : 00000005 r0 : cc67a000
[ 165.304135] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
[ 165.311429] Control: 10c5387d Table: 4e64c059 DAC: 00000015
[ 165.317137] Process kworker/0:2 (pid: 59, stack limit = 0xcea9c230)
[ 165.323393] Stack: (0xbe937c64 to 0xcea9e000)
[ 165.327758] 7c60: 0009fbec 46348668 0009dba0 46348668 00000002 000001b4 00000048
[ 165.335907] 7c80: 0009d974 be937e24 000928d4 00010aec be937f10 00000000 00000000 00000000

Do you have any suggestions as to how I might go about diagnosing this? Running arm-poky-linux-gnueabi-objdump on my wifi_core.ko module file hasn’t revealed much to me yet, but I’m not that familiar with what I am looking at.

I am planning to purchase several dozen of these Red boards as soon as I can get wifi working. Thanks.



I see you are using a wp76? is that correct - I ask because I only got this working last week. I will look at your MT7697 application issues as this should compile without any modifications other than applying the MT updates to the original MT7697 framework.

If you are using the wp76 then there were 2 modifications required:

  1. I had to do some API updates that are #ifdef’ed in the WiFi driver as the kernel for the wp76 is newer
    than the wp85. These updates are checked in and should be available
  2. The second change was in the MSM high speed serial driver used by (/dev/ttyHS0) - I found that the driver
    was configured to insert 0xFD characters when the Rx was woken up when there was nothing to read. This change would require a new kernel.

I just took a look at my hal_feature_config.h and did not have to add then HAL_DWT_MODULE_ENABLED - what type of machine are you building on? I am building on a Ubuntu desktop.

Thanks Dave


Thanks Dave, I appreciate you continuing to work with me on this.

I am building for the WP7504 (not 76) on the Ubuntu 16.04 Legato VM from Sierra Wireless. When I run the build command listed in my previous post, line 283 of kernel/rtos/FreeRTOS/Source/portable/GCC/ARM_CM4F/port.c is preventing a successful build unless I #define HAL_DWT_MODULE_ENABLED:

#error please enable HAL_DWT_MODULE_ENABLED in project inc/hal_feature_config.h for task stack overflow check.

I don’t see how this can be avoided unless that option is defined elsewhere. Are you sure you are working with the latest “SDK for GCC/IAR” from the mediatek site? I just ran through the build steps on the wiki from scratch and got the same result.



Thanks I am going to double check that the kernel is the same for the wp85 and wp75 as this could be cause of your kernel issue. Are you building the WiFi driver ko files yourself or are you pulling those from the MangOH web site (sorry right now not sure what is posted).

For the MT7697 application I am building the application from a framework MTPulbic3.0 which we received around May 2017. Note also there are a couple of patches required to this framework. Have you applied the two patches - I am guessing yes or else you would compile errors in my MT7697 wifi code which it does not look like you are getting.



I am building the ko module files for the Red from the primary mangOH repo, but had to build a custom kernel with yocto to enable the wireless extensions in order to load the wifi module (see my original post). I need to double-check if my toolchain is pointing at the custom yocto kernel or not - that could explain the particular kernel oops message I’m getting in the WP75 when UART bytes are received back from the MT7697.

Regarding the MT7607: yours is from around 5/17? That explains it. The wiki I read did not specify a version - so I downloaded the latest off the mediatek website. I’ll switch to version 4.3.0 released 2017.05.15 and I don’t expect I’ll have any issues compiling.

I noticed that there is a patch file “mt7697wifi_patch.txt” in the root of the MT7697_WiFi_BT_fw repo. It patches two files, so I assume that is what you are referring to. I did have apply the patch to compile. The first file patch (wifi_api.h) applied successfully with the patch utility, but I had to apply the second file (ethernetif.c) patch by hand - realizing now that my ethernetif.c was newer than yours.

Thanks for your help. I think I have enough direction for now about where I need to go next.


John just confirmed that kernel on the Wp75 is the same as the Wp85. I am pretty sure I know what your problem is kernel wise. The board you have has a version of the kernel with 2 different versions of the cfg/mac80211 modules and by default the wrong ones (wrong in that I mean not compatible for the MT7697 WiFi - but correct for the TI WiFi) are loaded. Note this has been resolved but a new release for the the WP75/85 kernel wont come out till next year. To get around this you will need to add the following to the /etc/init.d/mtwifi script.

This is the reason for the MT wifi driver issue as its loading an incorrect version of the cfg80211 kernel module. First do a ‘find / -name cfg80211.ko’ on the MangOH Red linux console to get location of the cfg/mac80211 ko module files. Then note path of the non-TI versions and use those in the mtwifi script updates below:

Here is what u need to add before the mt7697wifi_core is insmod’ed in this file:

lsmod | grep cfg80211 >/dev/null
if [ $? -eq 1 ]; then
insmod //cfg80211 || exit 127

lsmod | grep mac80211 >/dev/null
if [ $? -eq 1 ]; then
insmod //mac80211 || exit 127

The above lines go before the mt7697wifi_core is insmod’ed and below goes in the same file after the mt7697wifi_core is rmmod’ed.

lsmod | grep mac80211 >/dev/null
if [ $? -eq 0 ]; then
rmmod mac80211 || exit 127

lsmod | grep cfg80211 >/dev/null
if [ $? -eq 0 ]; then
rmmod cfg80211 || exit 127

This should resolve your mt7697 wifi linux driver issue although I am still interested in your mt7697 application compiles issues



I noticed early on that there were two versions of the cfg80211 module under /lib/modules/, and that the kernel was defaulting to the “updated” one for the ti wifi on boot. I simply removed all ti compat wireless tools from my custom yocto image to end up with one cfg80211 module in my custom image. I still needed to set the wireless extension (WEXT) settings listed in the wifi_core .mdef file to get a kernel + cfg80211 module that would accept the wifi_core module as written. That means your suggestion would not work with the default legato image. I would still get symbol undefined issues when loading the wifi_core module against the non-ti cfg80211 module. I suspect my issue is toolchain related at this point.

Regarding the MT7697 - I downloaded the 4.3.0 version from here. The patch worked for both files - but unfortunately I saw even more compilation errors that I did with the 4.6.0 version I had been previously working on. It would be helpful if you could update the MT7697_WiFi_BT_fw repo (and the wiki) to specify the exact version of the SDK it should be compiled against.


John the TI versions of the cfg80211 and mac80211 kernel modules will not have wext built in but the non-TI versions should have cfg80211 and mac80211 kernel modules compiled with wext enabled.


John for the MT7697 4.3 compile errors could you please attach or copy the err.log here. I can take a look and see why the errors are happening - thanks dve


Dave, I appreciate you continuing to follow up on this. My kernel oops issue was toolchain related, as I suspected. I built a new toolchain with yocto to go along with my custom kernel image, rebuilt the mangOH project with the new toolchain, and my kernel no longer reboots when it receives traffic back from the MT7697. I of course have a new blocking issue, but I am working through it and will report back here if I get stuck.

Regarding WEXT, you must be working with the next Legato release (15?), because the current Release 14 does not define all the kernel options defined in 2-mt7697wifi_core.mdef:


Some of these apply to the kernel itself and NOT the CFG80211 module, so it doesn’t matter if the non-TI version is used or not. This is why I needed to build a custom image with yocto.

Regarding the MT7697, it looks like the patch adds the line:

typedef int32_t (* wifi_net_rx_handler_t)(struct pbuf *p, struct netif *netif);

to ./middleware/third_party/lwip/ports/ethernetif.c when it should be ./middleware/MTK/wifi_service/combo/inc/wifi_api.h. I moved it and was able to compile 4.3.0 without any other modifications.