WL1837MOD: 'iw wlan0 scan' does not work on Xilinx zynqmp build

Brandon Dudley

Part Number: WL1837MOD
Other Parts Discussed in Thread: WL1837,

I am integrating the wl1837mod on a board with a Xilinx ZynqMP (UltraSCALE+). Initially, I had problems with the zynq device tree configuration, which prevented enumeration of the device at boot. Now, I believe I have corrected the DT configuration because the device is detected at boot and a wlan0 interface is shown available in the interface listing. Additionally, I have observed there is some communication on the sdio bus with a logic analyzer. Setting the wlan interface 'UP' appears to work as there are no error/warning messages in dmesg or printed to the console. My next step was to scan for APs, which does not work. The attempted scan causes a crash dump, included below, and the removal of the wlcore_sdio module. I included the latest wl1837 firmware in my build using the recipe from the meta-ti yocto layer in my petalinux build environment. I have modified it to pull in the latest firmware build, but it gives the same result as below. Is this a known issue that has already been solved? If not, what is the next recommended step to debug this problem?

iw wlan0 scan
[ 1838.634662] wl1271_sdio mmc1:0001:2: sdio write 52 addr 0x1fffc, byte 0x01
[ 1838.641594] ------------[ cut here ]------------
[ 1838.646205] WARNING: CPU: 2 PID: 771 at drivers/net/wireless/ti/wlcore/sdio.c:131 wl12xx_sdio_raw_write+0xf0/0x1b8 [wlcore_sdio]
[ 1838.657750] Modules linked in: wlcore_sdio dmaproxy(O) wl18xx wlcore mac80211 cfg80211 zynqmp_r5_remoteproc mali(O) uio_pdrv_genirq [last unloaded: wlcore_sdio]
[ 1838.672095] CPU: 2 PID: 771 Comm: iw Tainted: G        W  O      5.4.0-xilinx-v2020.1 #1
[ 1838.680173] Hardware name: xlnx,zynqmp (DT)
[ 1838.684342] pstate: 00000005 (nzcv daif -PAN -UAO)
[ 1838.689117] pc : wl12xx_sdio_raw_write+0xf0/0x1b8 [wlcore_sdio]
[ 1838.695019] lr : wl12xx_sdio_raw_write+0xa4/0x1b8 [wlcore_sdio]
[ 1838.700920] sp : ffffffc0112835f0
[ 1838.704218] x29: ffffffc0112835f0 x28: ffffff887936dc10 
[ 1838.709514] x27: ffffffc0112837e8 x26: ffffffc008d01000 
[ 1838.714809] x25: ffffff88792f9580 x24: 000000000001fffc 
[ 1838.720104] x23: 0000000000000000 x22: 0000000000000004 
[ 1838.725400] x21: ffffff887936dc10 x20: ffffff887a03adc0 
[ 1838.730695] x19: ffffff8879194400 x18: 0000000000000010 
[ 1838.735990] x17: 0000000000000000 x16: ffffffc0112837f8 
[ 1838.741286] x15: ffffff887a03b1e8 x14: ffffffffffffffff 
[ 1838.746581] x13: ffffffc091283217 x12: ffffffc01128321f 
[ 1838.751876] x11: ffffffc010fdc000 x10: 0000000000000000 
[ 1838.757172] x9 : ffffffc011095000 x8 : 00000000000011bd 
[ 1838.762467] x7 : 0000000000000006 x6 : 0000002d44c9f175 
[ 1838.767762] x5 : 00ffffffffffffff x4 : 0000000000000000 
[ 1838.773057] x3 : 0000000000000001 x2 : ffffff887ab3a4e4 
[ 1838.778353] x1 : 0000000000000000 x0 : 00000000ffffff92 
[ 1838.783649] Call trace:
[ 1838.786083]  wl12xx_sdio_raw_write+0xf0/0x1b8 [wlcore_sdio]
[ 1838.791657]  wlcore_runtime_resume+0xf0/0x2c8 [wlcore]
[ 1838.796788]  pm_generic_runtime_resume+0x28/0x40
[ 1838.801395]  __rpm_callback+0xf0/0x170
[ 1838.805127]  rpm_callback+0x54/0x80
[ 1838.808599]  rpm_resume+0x494/0x690
[ 1838.812071]  __pm_runtime_resume+0x74/0xb0
[ 1838.816158]  wl1271_op_hw_scan+0x68/0x180 [wlcore]
[ 1838.820963]  __ieee80211_start_scan+0x138/0x508 [mac80211]
[ 1838.826455]  ieee80211_request_scan+0x34/0x58 [mac80211]
[ 1838.831769]  ieee80211_scan+0x6c/0xc0 [mac80211]
[ 1838.836385]  nl80211_trigger_scan+0x50c/0x5d0 [cfg80211]
[ 1838.841683]  genl_family_rcv_msg+0x198/0x3c8
[ 1838.845944]  genl_rcv_msg+0x58/0xd0
[ 1838.849416]  netlink_rcv_skb+0x54/0x110
[ 1838.853236]  genl_rcv+0x34/0x48
[ 1838.856361]  netlink_unicast+0x174/0x200
[ 1838.860267]  netlink_sendmsg+0x178/0x318
[ 1838.864175]  ___sys_sendmsg+0x280/0x2c0
[ 1838.867994]  __sys_sendmsg+0x64/0xb8
[ 1838.871553]  __arm64_sys_sendmsg+0x20/0x28
[ 1838.875635]  el0_svc_common.constprop.0+0x68/0x160
[ 1838.880416]  el0_svc_handler+0x6c/0x88
[ 1838.884149]  el0_svc+0x8/0xc
[ 1838.887012] ---[ end trace 748c1280140ee90a ]---
[ 1838.891649] wl1271_sdio mmc1:0001:2: sdio write failed (-110)
[ 1838.897408] wlcore: WARNING Enable for recovery failed
command failed: Connection timed out (-110)[ 1838.902551] wlcore: down

[ 1838.908921] ieee80211 phy7: Hardware restart was requested

[ 1841.915651] wlcore: PHY firmware version: Rev 8.2.0.0.240
[ 1841.921044] wlcore: unmasking event_mask 0x3ffef01
[ 1842.895881] wlcore: ERROR reg domain conf error
[ 1843.441691] wl1271_sdio mmc1:0001:2: sdio write 52 addr 0x1fffc, byte 0x01
[ 1845.903504] wlcore: PHY firmware version: Rev 8.2.0.0.240
[ 1845.908895] wlcore: unmasking event_mask 0x3ffef01
[ 1846.883715] wlcore: ERROR reg domain conf error
[ 1847.429681] wl1271_sdio mmc1:0001:2: sdio write 52 addr 0x1fffc, byte 0x01
[ 1849.891407] wlcore: PHY firmware version: Rev 8.2.0.0.240
[ 1849.896799] wlcore: unmasking event_mask 0x3ffef01
[ 1850.865055] wlcore: ERROR reg domain conf error
[ 1850.869622] wlcore: ERROR firmware boot failed despite 3 retries
[ 1850.875668] ------------[ cut here ]------------
[ 1850.880308] WARNING: CPU: 0 PID: 665 at net/mac80211/util.c:2235 ieee80211_reconfig+0xa24/0xca8 [mac80211]
[ 1850.889944] Modules linked in: wlcore_sdio dmaproxy(O) wl18xx wlcore mac80211 cfg80211 zynqmp_r5_remoteproc mali(O) uio_pdrv_genirq [last unloaded: wlcore_sdio]
[ 1850.904288] CPU: 0 PID: 665 Comm: kworker/0:0 Tainted: G        W  O      5.4.0-xilinx-v2020.1 #1
[ 1850.913147] Hardware name: xlnx,zynqmp (DT)
[ 1850.917335] Workqueue: events_freezable ieee80211_restart_work [mac80211]
[ 1850.924113] pstate: 60000005 (nZCv daif -PAN -UAO)
[ 1850.928905] pc : ieee80211_reconfig+0xa24/0xca8 [mac80211]
[ 1850.934391] lr : ieee80211_reconfig+0x288/0xca8 [mac80211]
[ 1850.939858] sp : ffffffc0112f3cd0
[ 1850.943157] x29: ffffffc0112f3cd0 x28: ffffff8878218200 
[ 1850.948452] x27: 00000000ffffffea x26: 0000000000000000 
[ 1850.953747] x25: 0000000000000000 x24: 0000000000000000 
[ 1850.959042] x23: ffffff887f784a00 x22: ffffff88772e7180 
[ 1850.964338] x21: ffffff88793787c0 x20: ffffff8879391888 
[ 1850.969633] x19: ffffff88793907c0 x18: 0000000000000010 
[ 1850.974929] x17: ffffff887a801108 x16: ffffff887a801128 
[ 1850.980224] x15: ffffff88772e75a8 x14: ffffffffffffffff 
[ 1850.985519] x13: ffffffc0912f3967 x12: ffffffc0112f396f 
[ 1850.990814] x11: ffffffc010fdc000 x10: 0000000000000000 
[ 1850.996110] x9 : ffffffc011095000 x8 : 00000000000017f3 
[ 1851.001405] x7 : 0000000000000006 x6 : 0000002d8daa864d 
[ 1851.006700] x5 : 00ffffffffffffff x4 : 0000000000000000 
[ 1851.011996] x3 : ffffff88772e7180 x2 : 0000000000000000 
[ 1851.017291] x1 : 244ef920b7793600 x0 : 00000000ffffffea 
[ 1851.022587] Call trace:
[ 1851.025037]  ieee80211_reconfig+0xa24/0xca8 [mac80211]
[ 1851.030175]  ieee80211_restart_work+0xc0/0xf8 [mac80211]
[ 1851.035474]  process_one_work+0x1c4/0x338
[ 1851.039472]  worker_thread+0x4c/0x488
[ 1851.043120]  kthread+0x120/0x128
[ 1851.046331]  ret_from_fork+0x10/0x18
[ 1851.049888] ---[ end trace 748c1280140ee90b ]---
[ 1851.054662] ------------[ cut here ]------------
[ 1851.059273] wlan0:  Failed check-sdata-in-driver check, flags: 0x0
[ 1851.065507] WARNING: CPU: 0 PID: 665 at net/mac80211/driver-ops.h:17 drv_remove_interface+0x5c/0x70 [mac80211]
[ 1851.075487] Modules linked in: wlcore_sdio dmaproxy(O) wl18xx wlcore mac80211 cfg80211 zynqmp_r5_remoteproc mali(O) uio_pdrv_genirq [last unloaded: wlcore_sdio]
[ 1851.089823] CPU: 0 PID: 665 Comm: kworker/0:0 Tainted: G        W  O      5.4.0-xilinx-v2020.1 #1
[ 1851.098683] Hardware name: xlnx,zynqmp (DT)
[ 1851.102870] Workqueue: events_freezable ieee80211_restart_work [mac80211]
[ 1851.109649] pstate: 60000005 (nZCv daif -PAN -UAO)
[ 1851.114441] pc : drv_remove_interface+0x5c/0x70 [mac80211]
[ 1851.119927] lr : drv_remove_interface+0x5c/0x70 [mac80211]
[ 1851.125394] sp : ffffffc0112f3ab0
[ 1851.128693] x29: ffffffc0112f3ab0 x28: 0000000000000690 
[ 1851.133988] x27: ffffff88793907c0 x26: ffffff8879390fb8 
[ 1851.139283] x25: ffffff8879379330 x24: 0000000000000018 
[ 1851.144579] x23: 0000000000000000 x22: 0000000000000000 
[ 1851.149874] x21: ffffff88793918e8 x20: ffffff88772e7180 
[ 1851.155169] x19: ffffff8879378c58 x18: 0000000000000010 
[ 1851.160465] x17: ffffff887a801108 x16: ffffff887a801128 
[ 1851.165760] x15: ffffff88772e75a8 x14: ffffffffffffffff 
[ 1851.171055] x13: ffffffc0912f37f7 x12: ffffffc0112f3800 
[ 1851.176351] x11: ffffffc010fdc000 x10: 0000000000000000 
[ 1851.181646] x9 : ffffffc011095000 x8 : 0000000000001816 
[ 1851.186941] x7 : 0000000000000006 x6 : ffffffc01109509d 
[ 1851.192236] x5 : 000000000000000f x4 : 0000000000000000 
[ 1851.197532] x3 : 0000000000000000 x2 : 00000000ffffffff 
[ 1851.202827] x1 : 244ef920b7793600 x0 : 0000000000000000 
[ 1851.208122] Call trace:
[ 1851.210573]  drv_remove_interface+0x5c/0x70 [mac80211]
[ 1851.215712]  ieee80211_do_stop+0x628/0x8f8 [mac80211]
[ 1851.220764]  ieee80211_stop+0x14/0x20 [mac80211]
[ 1851.225368]  __dev_close_many+0xac/0x128
[ 1851.229280]  dev_close_many+0x84/0x120
[ 1851.233013]  dev_close.part.0+0x3c/0x68
[ 1851.236832]  dev_close+0x18/0x20
[ 1851.240061]  cfg80211_shutdown_all_interfaces+0x78/0xe8 [cfg80211]
[ 1851.246242]  ieee80211_handle_reconfig_failure+0xe0/0xf0 [mac80211]
[ 1851.252510]  ieee80211_reconfig+0x310/0xca8 [mac80211]
[ 1851.257648]  ieee80211_restart_work+0xc0/0xf8 [mac80211]
[ 1851.262944]  process_one_work+0x1c4/0x338
[ 1851.266937]  worker_thread+0x4c/0x488
[ 1851.270584]  kthread+0x120/0x128
[ 1851.273795]  ret_from_fork+0x10/0x18
[ 1851.277353] ---[ end trace 748c1280140ee90c ]---

over 4 years ago

0 S over 4 years ago

TI__Mastermind 35795 points

Hi,

Can you pls confirm WLAN_EN remains asserted after you bring up the interface ?

Thanks

Saurabh

0 Brandon Dudley over 4 years ago in reply to S

Prodigy 130 points

The situation has changed somewhat since I started this post. Initially, we had problems with the petalinux config, device tree spec, and some PL issues on the zynqmp. I resolved these issues to get to the point that I could config the wlan interface up. In the process I had been using a build of our PL that inverted the clock signals because we suspected some clock-data timing issues. This morning I reverted to a PL build that has no inverters on the clock, and the result is that the scan works sometimes, but fails other times. I have some logic analyzer traces of a failure and a successful scan. In the case of a failure, the trace shows a couple transactions on the command signal followed by ~11 ms of no activity, then the WLAN_EN is de-asserted ~24.3 ms. This is followed by more command signal transactions and WLAN_EN de-assertion - reassertion cycles. The trace ends with an IRQ assertion for 173 ms until WLAN_EN is de-asserted, which corresponded to the driver crash dump.

0 S over 4 years ago in reply to Brandon Dudley

TI__Mastermind 35795 points

Hi,

WLAN_EN should remain asserted after wireless interface is brought up .

Can you pls consult this device tree file to ascertain mmc , wlan_en etc. are configured ok : https://git.ti.com/cgit/wilink8-wlan/build-utilites/tree/patches/kernel_patches/beaglebone-wilink8-capes/Enable-TI-WiFi-Bluetooth-am335x-boneblack-WL1837.patch?h=r8.8

Best,

Saurabh

0 Brandon Dudley over 4 years ago in reply to S

Prodigy 130 points

Saurabh,

Thanks for the assistance. I based my device tree on a combination of the one you linked to and another example on Avnet's forum for one of their boards that includes a zynqmp and the wl1837. I have included the shdci parts below - they are in multiple blocks because petalinux tools generates part of the tree and I added part of the tree in the system-user.dtsi file Xilinx provides for manual dt entries in their environment. I pulled this out of the final dt spec that is built by the tools before compiling the dtb. I have the enable signal defined, and it works most of the time. However, it will eventually fail with a driver crash. Most of the time I can recover by reloading the wlcore_sdio module, but there are instances in which I have to reboot the target.

Edit: I should also note that this part is being accessed through the EMIO block of the zynqmp, which is the gpio block that route through the PL fabric of the part.

sdhci0: mmc@ff160000 {
   u-boot,dm-pre-reloc;
   compatible = "xlnx,zynqmp-8.9a", "arasan,sdhci-8.9a";
   status = "disabled";
   interrupt-parent = <&gic>;
   interrupts = <0 48 4>;
   reg = <0x0 0xff160000 0x0 0x1000>;
   clock-names = "clk_xin", "clk_ahb";
   xlnx,device_id = <0>;
   #stream-id-cells = <1>;
   iommus = <&smmu 0x870>;
   power-domains = <&zynqmp_firmware 39>;
   nvmem-cells = <&soc_revision>;
   nvmem-cell-names = "soc_revision";
   #clock-cells = <1>;
   clock-output-names = "clk_out_sd0", "clk_in_sd0";
  };

&sdhci0 {
 clocks = <&zynqmp_clk 54>, <&zynqmp_clk 31>;
};

&sdhci0 {
 clock-frequency = <199980026>;
 status = "okay";
 xlnx,mio_bank = <0x0>;
};

/ {
 wlan_en_reg: fixedregulator-mmcsdio {
  compatible = "regulator-fixed";
  regulator-name = "wlan_en_reg";
  regulator-min-microvolt = <3300000>;
  regulator-max-microvolt = <3300000>;
  startup-delay-us = <70000>;


     gpio = <&axi_gpio_0 0 0 0>;
     enable-active-high;
 };
};

&sdhci0 {
    bus-width = <0x4>;
 non-removable;
 disable-wp;
 cap-power-off-card;
 keep-power-in-suspend;
 vmmc-supply = <&wlan_en_reg>;

 max-frequency = <25000000>;
 sdhci-caps-mask = <0x0 0x00200000>;

 #address-cells = <1>;
 #size-cells = <0>;
 wlcore: wlcore@0 {
  compatible = "ti,wl1837";
  reg = <2>;
  interrupt-parent = <&gic>;
  interrupts = <0 89 1>;
 };
};

0 Sudharshan KN over 4 years ago in reply to Brandon Dudley

TI__Genius 10550 points

Hi,

There are some differences w.r.t to the voltage level settings as shown below. Also can you please let us know the kernel version that you are using?

Regards,

Sudharshan K N

{
+	model = "TI AM335x BeagleBone Black";
+	compatible = "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx";
+
+	wlan_en_reg: fixedregulator@1 {
+		compatible = "regulator-fixed";
+		regulator-name = "wlan-en-regulator";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		gpio = <&gpio0 2 0>;
+		enable-active-high;
+	};

0 Brandon Dudley over 4 years ago in reply to Sudharshan KN

Prodigy 130 points

Yeah, the voltage difference is something that came from an avnet forum post. I had been using 1.8V, but the device was never enumerated using 1.8V. There are other posts on e2e about using the dt node you posted with a zynqmp in which the device would not enumerate or timeout. I found an avnet post that uses the 3.3V value with a comment that states the signal is 1.8V, but the 3.3V value in the dt keeps the driver "happy". So, I tried it and I am at the point I have posted about - the device enumerates, scans, and can connect to access points, but the driver crashes in a fashion that appears random.

We are using petalinux 2020.1, which is based on kernel version 5.4 -

Linux zynq_zcu106 5.4.0-xilinx-v2020.1 #1 SMP Tue Mar 2 22:23:16 UTC 2021 aarch64 GNU/Linux

0 Sudharshan KN over 4 years ago in reply to Brandon Dudley

TI__Genius 10550 points

Thanks for the update! Are the drivers updated to R8.8 release https://www.ti.com/tool/download/WILINK8-WIFI-NLCP ? Please let me know. This is the latest driver that has several fixes.

Regards,

Sudharshan K N

0 Brandon Dudley over 4 years ago in reply to Sudharshan KN

Prodigy 130 points

How can I determine this from my kernel tree?

0 Sudharshan KN over 4 years ago in reply to Brandon Dudley

TI__Genius 10550 points

Hi,

The driver releases are made separately and some of the patches may not be unstreamed. The cleanest approach would be to try to integrate the R8.8 release with the kernel tree as per the procedure mentioned in the user guide.

Regards,

Sudharshan K N

0 Brandon Dudley over 4 years ago in reply to Sudharshan KN

Prodigy 130 points

The release guide details building this manually out-of-tree. Is there any guide or recommendations for building the release in a Yocto environment?

0 Sudharshan KN over 4 years ago in reply to Brandon Dudley

TI__Genius 10550 points

Hi,

No we do not have a guide with yacto reference. The same instructions should apply.

Regards,

Sudharshan K N

0 Brandon Dudley over 4 years ago in reply to Sudharshan KN

Prodigy 130 points

How do I get the source to build this driver? I tried this document, but some of the URLs display a page indicating R8.8 is an invalid branch.

software-dl.ti.com/.../WiLink8_R8.8_manifest.html

0 Sudharshan KN over 4 years ago in reply to Brandon Dudley

TI__Genius 10550 points

Hi,

Please refer to https://www.ti.com/lit/ug/swru561a/swru561a.pdf for details on integration.

0 Brandon Dudley over 4 years ago in reply to Sudharshan KN

Prodigy 130 points

I have read that guide. I am trying to pull this build into a yocto image, so I need URLs to the source for the packages listed in the Build User's Guide. The manifest page lists several repos, half of which do not work. I am not building this on the target, I am building it in a yocto cross-compiled environment, which means I need to add recipes and/or patches to build this driver for my project.

0 Sudharshan KN over 4 years ago in reply to Brandon Dudley

TI__Genius 10550 points

Hi,

Can you please let us know which of the links are not working? You can refer to configuration.sh within the build_utilities for the paths to the required components.

Regards,

Sudharshan K N

tar_filesystem=(
fs_skeleton.tbz2
)

toolchain=(
releases.linaro.org/.../gcc-linaro-4.9-2015.05-x86_64_arm-linux-gnueabihf.tar.xz
)


kernel
git://git.ti.com/wilink8-wlan/wilink8-wlan-ti-linux-kernel.git
processor-sdk-linux-02.00.01

openssl
git://github.com/openssl/openssl
OpenSSL_1_0_2d

libnl
git://github.com/tgraf/libnl.git
libnl3_2_25

crda
git://git.ti.com/wilink8-wlan/crda.git
master

wireless_regdb
git://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git
master-2017-03-07

driver
git://git.ti.com/wilink8-wlan/wl18xx.git
upstream_44

hostap
git://git.ti.com/wilink8-wlan/hostap.git
upstream_25_rebase

ti_utils
git://git.ti.com/wilink8-wlan/18xx-ti-utils.git
master

fw_download
git://git.ti.com/wilink8-wlan/wl18xx_fw.git
master

scripts_download
git://git.ti.com/wilink8-wlan/wl18xx-target-scripts.git
sitara-scripts

backports
git://git.ti.com/wilink8-wlan/backports.git
upstream_44

iw
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/iw.git
v4.1

uim
git://git.ti.com/ti-bt/uim.git
master

bt-firmware
git://git.ti.com/ti-bt/service-packs.git
master

)

0 Brandon Dudley over 4 years ago in reply to Sudharshan KN

Prodigy 130 points

Thanks. I presume I should be using branch 'r8.8' of the build utilities repo. Is that a correct assumption?

Broken URLs

WL18xx driver: https://git.ti.com/wilink8-wlan/wl18xx/trees/R8.8

Backports: git.ti.com/.../R8.8

WL18xx_fw: git.ti.com/.../R8.8

0 Sudharshan KN over 4 years ago in reply to Brandon Dudley

TI__Genius 10550 points

Hi,

Yes. The R8.8 configuration.sh is a better place to look into.

Brandon Dudley said:
WL18xx driver: https://git.ti.com/wilink8-wlan/wl18xx/trees/R8.8

we will check and see why the R8.8 label is missing

Brandon Dudley said:
Backports: git.ti.com/.../R8.8

R8.8 doesnt support backports.

Brandon Dudley said:
WL18xx_fw: git.ti.com/.../R8.8

we will check why the R8.8 is not applied. The latest version of FW is 8.9.0.0.86.

Regards,

Sudharshan K N

0 Brandon Dudley over 4 years ago in reply to Sudharshan KN

Prodigy 130 points

Thanks for the information. I am attempting to build this driver in a yocto environment, so I am pulling the build-utilities repo in via a linux kernel recipe, and applying the patches in TI's build-utilities using the yocto patching function. The patcher cannot apply some of these patches, which is not a surprise because these patches are for a 4.19 linux kernel while my project is using Xilinx's 5.4 kernel tree. Does TI have a patch set that apply to a newer kernel version? If not, what is your recommendation?

Brandon

0 Sudharshan KN over 4 years ago in reply to Brandon Dudley

TI__Genius 10550 points

Hi,

Yes. This may be the reason why the patches are not getting applied. There are no release available with latest kernel.

BTW Does the issue stated above always happen? are you able to get the wlan0 interface up on your board? Please let us know.

Regards,

Sudharshan K N

0 Brandon Dudley over 4 years ago in reply to Sudharshan KN

Prodigy 130 points

ifconfig wlan0 up works (I don't recall any failures since I set the wlan_en regulator to 3.3V, though, I could have forgotten.)

After that, 'iw wlan0 scan' works sometimes and fails others. I have been able to connect to an AP once; however, most of the time the driver crashes when I try to start wpa_supplicant. I am using the version of wpa_supplicant packaged in the petalinux 2020.1 release, so that could be an issue. I am trying to apply TI patches to the driver, then I am going to move on to hostapd/wpa_supplicant and wireless_regdb.

Regarding wireless-regdb, do you know if TI's r8.8 patches for that package have been upstreamed?

Brandon

0 Sudharshan KN over 4 years ago in reply to Brandon Dudley

TI__Genius 10550 points

Thanks for the details!!

0 Brandon Dudley over 4 years ago in reply to Brandon Dudley

Prodigy 130 points

I edited this into the previous post: Regarding wireless-regdb, do you know if TI's r8.8 patches for that package have been upstreamed?

Brandon

0 Sudharshan KN over 4 years ago in reply to Brandon Dudley

TI__Genius 10550 points

Hi,

All patches that are not up streamed are included as part of the release. If the patch exists for a component then it needs to be applied

Regards,

Sudharshan K N

+1 Brandon Dudley over 4 years ago in reply to Sudharshan KN

Prodigy 130 points

Thanks for the information. I started down the path of applying R8.8 patches to our kernel. Unfortunately, 4 of the patches would not apply because of significant changes to the ieee80211 layer in the linux kernel, and I think some of the patches that did apply successfully will not build because of references to functions/variables that no longer exist in ieee80211, though I am not certain of this because I did not build them. Concurrently, I was working on patching some sdio changes from Xilinx's release 2020.2 into our 2020.1 environment. The result of applying their changes to our kernel is a wl1837 that connects to an AP using R8.7 of the NLCP driver. So, I cannot say the suggestion either, resolved ,or did not resolve my problem. We are planning to go with this setup unless we find other problems or we find that we lack functionality that was added in R8.8. In that case, I will attempt to incorporate R8.8 into our kernel, which will require quite an effort because I will, first, have to dig through R8.8 applied to a 4.19 kernel to learn what is going on, then apply that to a 5.4 kernel with its ieee80211 changes.

0 Sudharshan KN over 4 years ago in reply to Brandon Dudley

TI__Genius 10550 points

Hi Brandon,

Thanks for the update!!

Brandon Dudley said:
Concurrently, I was working on patching some sdio changes from Xilinx's release 2020.2 into our 2020.1 environment. The result of applying their changes to our kernel is a wl1837 that connects to an AP using R8.7 of the NLCP driver.

Yes. This might help as the earlier problem is related to the SDIO. Please close the thread if there are no further issues

Regards,

Sudharshan K N

Wi-Fi

Wi-Fi forum

WL1837MOD: 'iw wlan0 scan' does not work on Xilinx zynqmp build