msm8916 + wcn3620 mainline support?

Wed Dec 31 01:02:20 PST 2014

Do you have a prima driver working with wcn3620? If so you can check
what does prima send through SMD and then do the same in wcn36xx.

2014-12-31 2:46 GMT+00:00 Andy Green <andy.green at linaro.org>:
> 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

-- 
Best regards,
Eugene