msm8916 + wcn3620 mainline support?

[Andy Green]

Hi -

I am working on an msm8916-qrd platform

http://store.thundersoft.com/index.php?main_page=product_info&cPath=55&products_id=197

with the goal of a mainline-tracking kernel with things like WLAN
(wcn3620) working.  I think the current mainline driver does not
support this variant but I'll describe my situation and would welcome
any advice or opinions on the chances of adapting wcn36xx to also work
on wcn3620.

I chopped down the 3.10.28-based kernel that came with the QRD to a
rough minimum to make it boot, including the gcc locks and rpm pieces,
rebased and got that working on mainline (3.19-rc2) and added eMMC
using mainline, serial using mainline and simple-framebuffer

https://git.linaro.org/people/andy.green/msm8916-qrd.git/shortlog/refs/heads/mainline-basis

(the reset of the partially ported pieces there don't work yet).

After getting a rough self-taught education in Qualcomm-specific Three
Letter Abbreviations, I ported the PIL and PIL/tz specific pieces to
get the necessary smd channels to appear.

The stock 3.10.28 kernel shipped with a kind of stub driver called
"wcnss", he is mainly there to integrate with the rest of the qualcomm
pm + smd stack.  I ported that as well.

So in this setup there are two distinct kinds of firmware, first what
seems to be TZ (?) firmware that we talk to over smd

-rwxr-xr-x 1 root root     436 Jan  1 00:07 wcnss.b00
-rwxr-xr-x 1 root root    6824 Jan  1 00:07 wcnss.b01
-rwxr-xr-x 1 root root   12844 Jan  1 00:07 wcnss.b02
-rwxr-xr-x 1 root root   61440 Jan  1 00:07 wcnss.b04
-rwxr-xr-x 1 root root 3097028 Jan  1 00:07 wcnss.b06
-rwxr-xr-x 1 root root      52 Jan  1 00:07 wcnss.b09
-rwxr-xr-x 1 root root  655360 Jan  1 00:07 wcnss.b10
-rwxr-xr-x 1 root root   39048 Jan  1 00:07 wcnss.b11
-rwxr-xr-x 1 root root    7260 Jan  1 00:07 wcnss.mdt

the PIL / PIL/tz stuff successfully loads this firmware

[    1.625972] subsys-pil-tz a21b000.qcom,pronto: wcnss: loading from
0x8b600000 to 0x8bbff000
[    1.629269] pil_mem_setup_trusted: MEM_SETUP_CMD id 6, PA
0x8b600000, len 6287360
[    1.629514] scm returned 0
[    1.650582] pil_load_seg: memcpy to offset 0x0
[    1.657948] pil_load_seg: memcpy to offset 0xc000
[    1.709494] pil_load_seg: memcpy to offset 0x29000
[    1.715522] pil_load_seg: memcpy to offset 0x550000
[    1.724946] pil_load_seg: memcpy to offset 0x551000
[    1.727513] pil_load_seg: memcpy to offset 0x5f1000
[    1.869140] subsys-pil-tz a21b000.qcom,pronto: wcnss: Brought out of reset

When that is accepted on the TZ side, the necessary smd channels for WLAN appear

[    2.131770] smd_alloc_channel() 'IPCRTR' cid=1
[    2.176510] smd_alloc_channel() 'sys_mon' cid=2
[    2.188739] smd_alloc_channel() 'APPS_RIVA_CTRL' cid=3
[    2.188932] smd_alloc_channel() 'APPS_RIVA_DATA' cid=4
[    2.267513] subsys-pil-tz a21b000.qcom,pronto: Subsystem error
monitoring/handling services are up
[    2.267778] wcn36xx-msm a000000.qcom,wcn36xx: wcn36xx_msm_probe initialized
[    2.273076] wcn36xx: mac address: 00:0a:f5:c4:31:e9
[    2.284519] wcn36xx wcn36xx wlan2: renamed from wlan0
[    2.354807] systemd-udevd[243]: renamed network interface wlan0 to wlan2
[    2.700556] smd_alloc_channel() 'APPS_RIVA_BT_CMD' cid=5
[    2.724639] smd_alloc_channel() 'APPS_RIVA_BT_ACL' cid=6
[    2.724819] smd_alloc_channel() 'APPS_RIVA_ANT_CMD' cid=7
[    2.724975] smd_alloc_channel() 'APPS_RIVA_ANT_DATA' cid=8
[    2.725146] smd_alloc_channel() 'APPS_FM' cid=9
[    2.725919] smd_alloc_channel() 'WCNSS_CTRL' cid=10
[    2.726091] smd_alloc_channel() 'WLAN_CTRL' cid=11

Now we start to get nasty, both wcn36xx from mainline and wcnss from
qualcomm's 2.10.28 stock kernel know how to load the second kind of
firmware, from /lib/firmware/wlan/prima/

-rwxr-xr-x 1 root root 29816 Jan  1 00:00 WCNSS_qcom_wlan_nv.bin

but they use very different smd commands to load the same firmware.

If I let wcn36xx load the firmware, he does load it via WLAN_CTRL smd
channel, the blocks are accepted but at the final block the smd reply
gives an error 233, which is not defined in what wcn36xx understands
about that protocol.  After that he blows an smd result 5 and we could
not start.  So I think that is the point we can say "wcn36xx doesn't
support wcn3620 chipset".

On the other hand, wcnss can successfully load the same firmware, he
does a very similar process using WCNSS_CTRL and different smd command
indexes.  But then he just sits there (because he expects an OOT wlan
driver to deal with it, see later).

I attempted to cross-breed the two drivers, allowing wcnss to bring up
the chipset and set the firmware and then let wcn36xx start up, that
gets me

root at linaro-developer:~# wpa_supplicant -B -i wlan2 -c
/etc/wpa_supplicant/test.conf
Successfully initialized wpa_supplicant
[  156.515916] smd_wcnss_irq_handler: #############
[  156.516219] smd_wcnss_irq_handler: #############
[  156.785180] Fatal error on wcnss!
[  156.785209] wcnss subsystem failure reason:
boot_exception_c_handlers.c:108:Data Abort Exception at 0xa2887b4.
[  156.787522] Kernel panic - not syncing: subsys-restart: Resetting
the SoC - wcnss crashed.

(The assertion is reported from TZ it's not in the kernel).


so I think wcn36xx probably needs to be taught more about wcn3620
firmware protocol changes before it would do anything.


Trying to follow up wcnss in 3.10.28 is a bit ugly, in addition to
"wcnss" in-tree I ported, which presents 2 x /dev nodes, there is a
whole monster OOT kernel driver

https://www.codeaurora.org/cgit/external/hisense/platform/vendor/qcom-opensource/wlan/prima/log/?h=8130_CS

the stock 3.10 kernel loads that as a module, which is unfortunate
because that repo has not been touched in 18 months and does not
support msm8916, so I do not have matching sources for that I think.

So I would very much prefer to use wcn36xx mainline driver with this
wcn3620 chipset rather than the OOT driver.

Does anyone have any advice how to best proceed?

-Andy