[BPI-R2] internal Wifi/BT (MT6625L) - Kernel

Banana Pi BPI-R4/BPI-R3 Mini/BPI-R3/BPI-R64/BPI-R2
115

As far as I understand it, the driver modules get compiled into the kernel, they get probed during boot and then will look into the dts how to initialize the hardware etc.

Interesting logs. This line should most likely also happen in 4.16 for the wifi module to find it, unless in 4.16 they altered this behavior. I expect it to be somewhere (indirectly) in the mtk-wdt driver.

Just for fun I tried those printk’s also on 4.17-rc1, which also doesn’t call reset_controller_register for watchdog, same as your 4.16.

116

maybe this is related: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e6127c1240ed569cdda2a67c8f03836f9f28c05

there is a patch for 7621 (not bpi-chip, but maybe interesting) which changes watchdog_register_device to devm_watchdog_register_device

117

Good find, but I don’t think these changes have any impact.

Could you please add some printk’s to: mtk_infrasys_init, at least at the top and before mtk_register_reset_controller. If reset controller is called, then continue in there. At the end of that function, the reset controller is registered. This method should be called. If you see no prints at all, check if the drivers/clk/mediatek/clk-mt2701.o file exists and has recent changes.

118

i try to include some printk’s:

printk(KERN_WARNING "%s: (%s:%i) regmap=%s", __FUNCTION__, __FILE__, __LINE__, regmap ? regmap->name : "<NULL>");

got this error:

drivers/clk/mediatek/reset.c:75:97: error: dereferencing pointer to incomplete type 'struct regmap'
  printk(KERN_WARNING "%s: (%s:%i) regmap=%s", __FUNCTION__, __FILE__, __LINE__, regmap ? regmap->name : "<NULL>");

and i wonder how this can work:

struct regmap *regmap;

because variable-name is same as type…without the var-content log is here:

4.16-infrasys.txt (24,4 KB)

patch-file: infrasys.patch (2,6 KB)

119

Incomplete type in this case probably means the type was forward declared and only used as pointer (not as regmap type).

The logs are sufficient, thanks. On a quick look it seems that sadly were not on the right path as everything is called as it’s supposed to. I didn’t have any time yet to dive into further, busy weekend :sweat:, but we need to find out how kernel 4.14 mtk_wdt_probe finally causes calling reset_controller_register. This what your earlier log was showing:

Note that the Watchdog enabled is the last line of mtk_wdt_probe, while the register_controller_register is called after, according to the log. I now suspect this is because the watchdog is scheduled somewhere, and registered upon start. I was hoping the infrasys logs would give some more insight…

120

In your wifi-debug.log (4.16-wlan) I don’t see the line MTK_WDT_NONRST_REG(0) that is in wifi-debug-4.14.log. I think you forgot to merge drivers/watchdog/mtk_wdt.c :wink:

1 Like
121

Hah! you’re probably right… 4.14 from your 4.14-main branch has DRIVER_VERSION 2.0 and 4.16 has 1.0. Also for 4.14 the file is 621 lines vs 280 in 4.16… pff I was comparing with 4.14 mainline

122

Seems this is the missing part:

Forum-software stripped the #diff-a7c2e83ff71c648e58025d54ffb50e02

I will add this later…

123 
[12:00] root@bpi-r2:~# uname -r                                                 
4.16.7-bpi-r2-wlan                                                              
[12:00] root@bpi-r2:~# uname -a                                                 
Linux bpi-r2 4.16.7-bpi-r2-wlan #211 SMP Mon May 21 11:54:59 CEST 2018 armv7l Gx
[12:00] root@bpi-r2:~# ifconfig ap0                                             
ap0       Link encap:Ethernet  HWaddr 02:08:22:52:61:fc                         
          inet addr:192.168.10.1  Bcast:0.0.0.0  Mask:255.255.255.0             
          inet6 addr: fe80::8:22ff:fe52:61fc/64 Scope:Link                      
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1                    
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0                    
          TX packets:7 errors:0 dropped:0 overruns:0 carrier:0                  
          collisions:0 txqueuelen:1000                                          
          RX bytes:0 (0.0 B)  TX bytes:746 (746.0 B)                            
                                                                                
[12:00] root@bpi-r2:~# dmesg |grep MTK                                          
[    1.510238] MTK-BTIF[E]hal_btif_clk_get_and_prepare(286):[CCF]clk_btif=3ac2d9
[    1.517534] MTK-BTIF[E]hal_btif_clk_get_and_prepare(292):[CCF]clk_btif_apdma0
[    1.711568] MTK_WDT_NONRST_REG(0)                                            
[   54.664170] [MTK-BT] BT_init: mtk_stp_BT_chrdev driver(major 192) installed  
[   54.664636] [GPS-MOD-INIT][I]do_gps_drv_init:CONFIG_MTK_COMBO_GPS is not defd
[   54.664917] [MTK-WIFI] WIFI_init: mtk_wmt_WIFI_chrdev driver(major 155) inst.
[   61.686268] [MTK-WIFI] WIFI_open: WIFI_open: major 155 minor 0 (pid 1000)    
[   61.686360] [MTK-WIFI] WIFI_write: WIFI_write A                              
[   62.916939] [MTK-WIFI] register_set_p2p_mode_handler: (pid 1026) register se7
[   62.917058] [MTK-WIFI] WIFI_write: WMT turn on WIFI success!                 
[   62.918513] [MTK-WIFI] WIFI_write: Set wlan mode 0 --> 1                     
[   62.918578] [MTK-WIFI] WIFI_close: WIFI_close: major 155 minor 0 (pid 1000)

looks well :wink: thank you @BitMaster & @dfiloni very much

i can also connect to the AP :slight_smile:

124

Wow, great! Good job! You still did most of the work :slight_smile:

Do you know why this awful wmt whatever tool and stp blabla loader is required? Maybe we can combine some efforts to ban them as well, if it’s not too much work.

125

Wmt-tools are required because this driver is from android…i also want to kickoff these tools,but don’t know where these hook into the driver…i’m still no kernel-developer…i only copy files,compile them and try to fix the errors the compiler reports me :slight_smile:

Stp_art_launcher throw firmware-file to the driver, wmt_loader makes the init

126

I’m really happy to know it works! :sunny:

I’m not sure, maybe I’ll buy a board (I quit my old job so I don’t have any R2 anymore which I can use) to try to mainline only the WIFI driver (with all his dependencies such as watchdog 2.0, pwrap, etc.), is anyone working on this or interested in helping? Does anyone know if MTK guys already planned to do that? I think we could proceed as step, by porting all drivers one by one.

I still have to check if the WIFI firmware is proprietary but other core drivers (watchdog, pwrap…) can be already ported to mainline.

127

The wifi-driver is imho to large for mainline…and with the wmt-tools-depency we have imho no chance for mainline-integration. Afaik we can not hope for mtk-support…i have asked gary multiple times for porting this driver and some others for other drivers (hdmi,dual gmac,hnat)…there was not the best response

Also bt is not working…no help so far…

128

Thanks Frank! Sounds awesome! I’m also interested in getting the wifi driver in a better shape, have already a project with yocto on banana pi with 4.16, right now I’m just using external wifi card, soon will try to apply changes from your branch to a vanilla 4.16.x.

It will be good to get the smallest possible patch for latest upstream kernel to enable the wifi driver, last time I’ve checked that on 4.14 it was a huge ~7MB diff.

129

The patch was bigger when i got it…i have removed a folder that was not used and had redundancy files…but sure it’s to big for mainline

Maybe you can wait to the moment i merge the code to 4.16-main…so you can generate a single patch

130

Of course we should mainline the watchdog driver first, then the pwrap one, then the mt6625 core one, then… (this is an example, IDK all mini-drivers involved), you think it is too large because you’re seeing it as a single big driver :wink:

I think it can be integrated in mainline (at least some simple drivers such as the watchdog). Also maybe…maybe… MTK guys (and others) will help us to remove that wmt-tools-thing if everything else is already in mainline

About BT: I think we can merge the Wifi driver without BT (it’s another config so it is quite easy to remove it)

131

Can you post these parts for mainline…still try to figure out how to post a simple patch (leds)

132

The code requires a huge cleanup before you can submit it to patchwork :sweat_smile:

133

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?

134

Any idea to bypass linaro-bug?