60-2230C Series Bluetooth and WiFi Module

These two pins are 3.3V level signal and need to be within range below,

VIH= 2.5V to 3.6V

VIL=-0.3V to +0.5V

VOH=2.9V (min)

VOI=0.4V (max)

Yes, If you decide to use NetworkManager, then systemd-networkd should be removed from the system. We would recommend changing Yocto systemd PACKAGECONFIG to not build it into image.

• Conformal coatings is not recommend for ST60 and no special mitigation is needed for tin wisker. The PCB process we have on the ST60-SIPT is ENIG that can mitigation for tin wisker. 

Yes, 60 series is able to support ACS in AP mode.

To enable ACS mode, with summit supplicant, need to set "acs= 1" under network setting segment and it will scan first then choose the best channel to run as AP mode.

Here is an example of wpa_supplicant.conf with ACS enable,

# cat /etc/wpa_supplicant_ap.conf

ctrl_interface=/var/run/wpa_supplicant_1

network={

    ssid="miles-hotspot"

    mode=2

    frequency=2412

    acs=1

    psk="miles123"

    proto=RSN

    key_mgmt=WPA-PSK

}

PCIE Active State Power Management (ASPM) is enabled by default in powersave mode in the stock nVidia kernel image. This causes correctable errors.

ASPM support needs to be disabled either by changing the kernel config by removing ASPM or by a run time change via

/sys/module/pcie_aspm/parameters/policy, set to [performance]. 

The latter however has to be done upon every boot.

No, there are no plans to add support for LTE coexistence in 60 series firmware.

Need to add libgpiod, libgpiod-dev and libgpiod-tools.

libgpiod containing libgpiod.so* files

libgpiod-dev containing /usr/include for the header files and /usr/lib for the shared lib's solink file and corresponding pkgconfig metadata.

libgpiod-tools containing gpiodetect, gpioget, …

ST60 doesn't support  [HT40]  11n mode in 2.4G.

In OpenWRT, the PHY is set by adding (Logic OR) the two settings of Band-1(2.4G) and Band-2(5G).

So, [HT20] and [HT40] two modes are always set.

Need to modify the OpenWRT source so that only [HT20] is set in case of 2.4G operation of the ST60 modem.

Yes, it supports HCSL, and the mode it supports is Common Clock mode.

After building a default image for the NXP i.MX8 LPDDR4 DVK device tree is such that M2 slot provides PCIe connectivity.

However, SDIO device tree is generated and available in the image.

The parameter "fdtfile=" in U-Boot needs to be changed.

Change "fdtfile=imx8mp-evk-revb4.dtb" to "fdtfile=imx8mp-evk-usdhc1-m2.dtb" by:

u-boot=> setenv fdtfile imx8mp-evk-revb4-usdhc1-m2.dtb
u-boot=> saveenv

Reference:

root@imx8mp-lpddr4-evk:~# ls /dev/mmc*
/dev/mmcblk2       /dev/mmcblk2boot0  /dev/mmcblk2boot1  /dev/mmcblk2p1     /dev/mmcblk2p2     /dev/mmcblk2rpmb
root@imx8mp-lpddr4-evk:~# mount /dev/mmcblk2p1 /media/
root@imx8mp-lpddr4-evk:~# ls /media | grep usdhc
imx8mp-evk-revb4-usdhc1-m2.dtb
imx8mp-evk-usdhc1-m2.dtb

To check if your SDIO Wi-Fi module is recognized and available in a Linux system, you can use several command-line tools to probe the system and examine its output. Here are some commands that are commonly used for this purpose:

1) lsusb and lspci:

• If your SDIO Wi-Fi module is externally connected via USB or internally via PCI, use these commands to list the USB and PCI devices, respectively.

  lsusb
  lspci
  

• Look for your Wi-Fi module in the output. External SDIO over USB adapters will appear in lsusb, while internal ones connected to the PCI bus will show up in lspci.

2) dmesg:

• This command displays kernel messages, which can be helpful to see if the module was detected during boot or when plugged in.

  dmesg | grep -i sdio
  

• Replace sdio with a more specific keyword of your Wi-Fi module if needed.

3) ip link or ifconfig:

• These commands show network interfaces recognized by the system.

  ip link
  

• or for older systems:

  ifconfig -a
  

• Check if there's a new network interface that corresponds to the Wi-Fi module.

4) iwconfig or iw:

• These tools are specifically for wireless network interfaces.

  iwconfig
  

• or using iw:

  iw dev
  

• These commands list wireless interfaces and can be used to identify if your SDIO Wi-Fi module is active as a network interface.

5) lshw:

• This command provides detailed hardware information.

  sudo lshw -C network
  

• It shows all network devices and their statuses, including any Wi-Fi modules.

6) lsmod:

• Use this command to check if the driver modules required by the Wi-Fi card are loaded.

  lsmod | grep -i wifi
  

• Replace wifi with the specific driver name if known.

7) Check System Logs:

• System logs can also provide information about hardware detection and driver loading.

  cat /var/log/syslog | grep -i wifi
  

• Replace wifi with a more specific keyword of your WiFi module such as lrd for some Laird specific drivers and firmware.

8) rfkill list:

• This tool lists all wireless devices and shows if they are blocked or unblocked (enabled or disabled).

  rfkill list
  

According to SDIO Simplified Specification V3.0, we would recommend to have pull-up resistors in SDIO bus while design with ST60-2230C. Should be able to apply to other module which has SDIO 3.0 bus as well.

There was a change in kernel 5.19 and higher, lrd-11 is built against the kernel 6.1 kernel backports), where there is a requirement to add cfg80211 to your image as a module (m) in the base platform kernel configuration. It must not be left out and must not be included as built-in (y). Networking support->Wireless->cfg80211 - wireless configuration API

The setting would be similar as TLS setup except these two configurations. 

802-11-wireless-security.proto wpa3

 802-11-wireless-security.key-mgmt wpa-eap-eap-suite-b-192

For example:

nmcli c add type wifi ifname wlo61s0 con-name 'My Wifi Network' \
  802-11-wireless.ssid 'My Wifi' \
      802-11-wireless-security.key-mgmt wpa-eap-eap-suite-b-192 \

      802-11-wireless-security.proto wpa3 \

      802-1x.eap tls \
      802-1x.identity identity@example.com \
      802-1x.ca-cert /etc/cert/ca.pem \
      802-1x.client-cert /etc/cert/user.pem \
      802-1x.private-key /etc/cert/user.prv \
      802-1x.private-key-password the_password

If you configure Wi-Fi setting by wpa_supplicant, you will need to setup a configuration file such as "/etc/wpa_supplicant.conf", and then execute wpa_supplicant as below command.

wpa_supplicant -Dnl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B -ddd

Here is the example of wpa_supplicant.conf to setup "WPA3 Enterprise Suite b 192" network.

ctrl_interface=/var/run/wpa_supplicant

#update_config=1

network={

        ssid="Cisco_2802_WPA3_Enterprise"

        proto=WPA3

        key_mgmt=WPA-EAP-SUITE-B-192

        ieee80211w=2

        pairwise=GCMP-256

        group=GCMP-256

        group_mgmt= BIP-GMAC-256

        eap=TLS

identity=xxxx

ca_cert="/etc/cert/ca.pem"

client_cert="/etc/cert/user.pem"

private_key="/etc/cert/user.prv"

private_key_passwd="password"

phase1=”tls_suiteb=1”

}

If you use native wpa-supplicant, you will need to enable CONFIG_WNM in wpa-supplicant config. No extra configuration settings in client mode but not currently supported in AP mode. If you use the supplicant Laird provided, already enable this setting by default.

ST60/SU60 SDIO mode need clock to send the card interrupt to the host. By default it's NOT enabled. Please check the following setting and enable it in sdhci.c

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c

index 9c1a099afbbec..63bc33a54d0dd 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1830,6 +1830,9 @@ static void sdhci_enable_sdio_irq(struct mmc_host *mmc, int enable)
struct sdhci_host *host = mmc_priv(mmc);
unsigned long flags;
+ if (enable)
+ pm_runtime_get_noresume(host->mmc->parent);
+
spin_lock_irqsave(&host->lock, flags);
if (enable)
host->flags |= SDHCI_SDIO_IRQ_ENABLED;
@@ -1838,6 +1841,9 @@ static void sdhci_enable_sdio_irq(struct mmc_host *mmc, int enable)
sdhci_enable_sdio_irq_nolock(host, enable);
spin_unlock_irqrestore(&host->lock, flags);
+
+ if (!enable)
+ pm_runtime_put_noidle(host->mmc->parent);
}

To be able to configure the backport package issue the command

bitbake -c menuconfig kernel-module-st60-backports-summit

in the top folder of your Yocto build environment set up to build for Laird 60-series modules.

Yes, Laird Wifi modules with USB interface can be used instead of or in addition to the SU60 Wifi module that is inegrated on the SOM8MPlus system on module. 

That requires integration of the driver of the corresponding USB based module into the Yocto build environment for the SOM8MPlus. Please see the Lairds "Guides"section for details: https://lairdcp.github.io/guides/

Laird modules with USB interface are the Sterling-60, Summit-60 and the Sterling-LWB5+.

PCIE Active State Power Management (ASPM) is enabled in powersave mode by default in stock nVidia kernel image.  This causes correctable errors because the 60-series radios advertise support for ASPM but doesn't handle it well enough.

Disabling of ASPM is needed by one of the below methods:

1. change in kernel config (permanent)
2. Change at run time via /sys/module/pcie_aspm/parameters/policy, set to [performance] (has to be done upon every boot)

The countries listed in the Radio Release Notes (RRN) are those the module can be set to for regulatory testing and operation.

This enables users and their test houses to do regulatory testing for a very large number of countries by just setting the correct country for the correct channel and power settings.

However test reports have only been created for the countries that can be found in the documents under the "Certification" tab of the web landing page for the module.

For the 60-series those are:
USA (FCC), EU, UK (UKCA), Canada (ISED), Japan (MIC), Korea (KC), Australia, New Zealand

Yes, Laird´s 60-radios support 4-addr mode and layer-2 bridging with Lairds specialized SUMMIT Wifi stack.

This functionality requires the use of software version 10.4.0.10 (Gihub) or newer and Lairds Summit Software stack for the 60-series modules: /wireless-modules/wifi-modules-bluetooth/summit-software-stack-60-series

This is supported on all 60-radios including SU60-SIPT, SU60-2230-C, SOM60 and SOM8M+.

You can also reference this tutorial: https://lairdcp.github.io/guides/Sterling-60-Tutorials/1.0/4addr-mode.html

Yes they can. There is also a tutorial material available for reference:

USING THE 60-RADIO WITH RASPBERRY PI ON THE SDIO_UART INTERFACE FOR WIFI AND BLUETOOTH

Yes the software package availabe around Lairds 60-series radio is suitable for being integrated with Xilinx´ Peta Linux tool. There is a guide that can be followed:

/documentation/application-note-petalinux-software-integration-60-series-and-lwb-series

When you issue the following command on an embedded Linux system with mounted debugfs and correctly integrated 60-series radio, you, for example get the below information:

# cat /sys/class/ieee80211/phyX/device/lrd/info

Driver name : lrdmwl
Chip type   : 88W8997-SDIO
HW  version : 7
FW  version : 5.5.46.5
DRV version : 9.32.0.13
OTP version : 1
OTP num mac : 3
Radio Type  : SU
MAC address : c0:ee:40:50:2a:70
Region code : 0x10 (0x10)
Country code: 'US' ('US')
TX antenna  : 2
RX antenna  : 2

The country/region code on the left is the current code that is used by the system at that moment, whereas the one in parentheses is what is currently in OTP.

The only time they might not match is when using Advanced World Mode (AWM).

The used region codes are:

0x00: WW (World Wide)
0x10: FCC
0x20: IC
0x30: ETSI
0x31: KCC
0x32: AU
0x40: JP
0x50: CN

"phyX" in above command will have to be replaced with the actual phy your module is known to your system. e.g. phy0, phy1, phy2, phy3,...

The Jetson TX2 NX does not act the same as the Jetson Nano when providing power to the m.2 slot. The Jetson Nano will automatically toggle PMU_EN, while the TX2 NX will require a manual toggle of the pin in software.

This applies to USB variants, as PCIe variants have a reset built into the PCIe standard.

On a linux system if the dmesg is reporting an unknown symbol this is usually due to one of the following:

1. The backports drivers didn't get compiled against the correct kernel.
2. WLAN, CONFIG_BT, and WIRELESS were not removed from the kernel menuconfig.
3. backports was compiled with different flags than how the kernel was compiled.

When you have an agreement with Laird to send in your device for testing of anything around your radio you need to make sure your radio can be set to all necessary test modes.

In order to do that please contact the Laird FAE already known to you or write to Laird at "support@lairdconnect.com" to get in contact with us.

Your FAE will be able to help you determine if your device is fit for testing.

When setting the 60 module to WorldWide mode all 5GHz channels are set to "no IR" - no Initiate Radio by default.
However when there are APs present that beacon on the 60s WW channles the "no IR" flag will be removed and does not show anymore when probing the module with "iw phy<X> info".

For example:
                       * 5260 MHz [52] (20.0 dBm) (no IR, radar detection)
versus
                       * 5260 MHz [52] (20.0 dBm) (radar detection)

Calculations show that the OTP in the 60-series can be written to well more than 100 times.

That is in contradiction with some apps notes that still state a value of 10 times. That luckily is not true. You can savely consider a number 100 times during your development work.

However, as the term OTP (One-Time-Programmable) memory suggests it will fill up one by one with every change of the regualtory domain and will eventually be full. It will then be stuck with the last regualtory doamin that it has been changed to.
So, it is advised to not change the regulatory as part of your design as the OTP will top up eventually.

The LMU tool offers the possibilty to set the regualtory domain the 60 module is going to be used in at the command line in an OTP memory.

This can be done by selecting the respective regualtory domain (e.g. ETSI, FCC, etc.) as well as by selecting the country code of the desired country (e.g. US, NZ, DK, FR, DE)

A comprehnsive list of available options is shown when exectung the LMU tool by simply typing "lmu" <enter>.

While loading 7.1.0.9 release in ST60/SU60, driver indicates "/lib/firmware/lrdmwl/regpwr.db not found." What does it mean and how to handle it?

It’s the adaptive world mode component (awm) which implements 802.11d/WorldMode “roaming” for SU60, not for ST60.
Among other things it includes a daemon which runs and checks the geo-location of the radio and sets the regulatory domain accordingly.  
The message is just informational. It is not an error and will not cause any problems.

To integrate this part, if you build by yocto, you can add adaptive_ww in your recipe.

The specification of Bluetooth includes an encryption key negotiation protocol that allows for the negotiate encryption keys with 1 Byte of entropy without protecting the integrity of the negotiation process.

A remote attacker can manipulate the entropy negotiation to let any standard compliant Bluetooth device negotiate encryption keys with 1 byte of entropy and then brute force the low entropy keys in real time.

With the 7.1.0.9 release for the ST60/SU60, all options including USB-USB have addressed and resolved the KNOB attack vulnerability.

SDIO reset would rely on SDIO card detection function, which can be done by broken-cd setting in device tree.

1. Modify the dts file:

For example if you use NXP IMX6UL board, the dts file is located at “~/projects/fsl-release-bsp/build-imx6ul-fb/tmp/work-shared/imx6ulevk/kernel-source/arch/arm/boot/dts/imx6ul-14x14-evk.dts”. If you use mmc0, the setting will be in usdhc1.

Add broken-cd function in the setting of usdhc1 as below and also need to make sure there is no setting of “non-removable”.

&usdhc1 {

pinctrl-names = "default", "state_100mhz", "state_200mhz";

pinctrl-0 = <&pinctrl_usdhc1>;

pinctrl-1 = <&pinctrl_usdhc1_100mhz>;

pinctrl-2 = <&pinctrl_usdhc1_200mhz>;

cd-gpios = <&gpio1 19 GPIO_ACTIVE_LOW>;

keep-power-in-suspend;

broken-cd;

enable-sdio-wakeup;

vmmc-supply = <®_sd1_vmmc>;

status = "okay";

};

2. Rebuild kernel and then it will set MMC_CAP_NEEDS_POLL during mmc driver initialization.

int mmc_of_parse(struct mmc_host *host)

{

…

if (of_property_read_bool(np, "non-removable")) {

dev_warn(host->parent,"Parse Card Detection: non-removable\n");

host->caps |= MMC_CAP_NONREMOVABLE;

if (of_property_read_bool(np, "cd-post"))

host->caps2 |= MMC_CAP2_CD_POST;

} else {

cd_cap_invert = of_property_read_bool(np, "cd-inverted");

if (of_property_read_bool(np, "broken-cd"))

{

dev_info(host->parent,"Parse Card Detection: broken-cd\n");

host->caps |= MMC_CAP_NEEDS_POLL;

}

…

}

…

}

Then SDHC will check the SDIO bus per second and once there is any PMU_EN or PDN assert event, SDHC will detect the bus no longer available and will unload/reload the SDIO again automatically.

While loading the lrdmwl.ko kernel object you will need to add the option SISO_mode. The value would depend on which antenna port is to be used.

        SISO_mode:
        0: WiFi --> ANT Wi-Fi & ANT Wi-Fi+BT ports
        1: WiFi--> ANT Wi-Fi  port
        2: WiFi --> ANT Wi-Fi+BT port

You will need to terminate the unused antenna port with a 50 ohm terminator, otherwise, it could damage the PA of the unattached antenna port, due to energy rebounding during driver/firmware Initialization and you run the risk of not being able to leverage our certifications. 

In BlueZ, some commands such as l2test or l2ping are able to generate traffic on L2CAP layer. To test performance and reliability, you can use the l2test command:

On the server, run the command:

l2test -I 2000 -r

On the client side, run the command:

l2test -O 2000 -s XX:XX:XX:XX:XX:XX

The 60 series radio itself is not FIPS certified and cannot be certified, since FIPS must be tied to an entire platform (host, OS, encryption mechanisms, etc..) and have a defined boundary within the platform (data at rest, data at motion, Ethernet, USB, Wi-Fi, etc..).

From a Wi-Fi radio perspective, the on-board encryption hardware accelerators on the Marvell silicon are not FIPS compliant. Therefore, a customer would need to disable the radio encryption accelerator on the 60 series radio and use a FIPS validated crypto-engine. This is similar to what Ezurio did on our 60 Series SOM to achieve FIPS certification – from a high-level perspective we bypassed the silicon's encryption HW accelerators and forwarded all of the encryption functions to a FIPS validated crypto-module on the SOM60. Disabling the radio’s encryption functions can be done from the host.  The rest of the FIPS architecture will need to be determined by customer as FIPS is tied to more than just the radio.

Each implementation of FIPS is different and the radio is just one piece of a larger FIPS strategy. Ezurio's implementation of FIPS was specifically designed for the SOM60 platform.

Only the SU60 version supports monitor mode.

1. Load backports driver, such as below for SDIO option.

insmod compat/compat.ko
insmod net/wireless/cfg80211.ko
insmod net/mac80211/mac80211.ko
insmod drivers/net/wireless/laird/lrdmwl/lrdmwl.ko
insmod drivers/net/wireless/laird/lrdmwl/lrdmwl_sdio.ko

2. Setup interface type as monitor mode and bring it up.

iw dev wlaninterface add wlan1 type monitor
ifconfig wlan1 up

3. Use tcpdump to capture the packet as the command below.

tcpdump -i wlan1  -n -w wireless.cap

CONFIG_ARCH_BERLIN  need to be disabled

Platform Selection  -->

[ ] Marvell Berlin SoC Family

Networking support --> Wireless

[ ] cfg80211

Device Driver -->

[*] LED support

<*> LED Class Support

<*> LED Support for GPIO connected LED

[*] LED support for LEDs on system controller

 -*-  LED Trigger support

<*> LED Heartbeat Trigger

[*] LED CPU trigger

Cryptographic API -->

<*> CCM support

<*> GCM/GMAC support

<*> CMAC support

<*> CRC32 CRC algorithm

<*> AES cipher algorithms

<*> ARC4 cipher algorithm

Kernel hacking

<*> Kernel debugging

 

If WiFi interface is PCIE, then need to check the following configuration as well.

Bus support -->

[*] PCI Support

[*] Message signaled Interrupt

[*] Root port Advance error reporting support

[*] PCI express ASPM control

 

For BT, need to have few more extra configuration.

Cryptographic API -->

<*> ECDH algorithm

Networking support -->

< > Bluetooth

1. Load backports driver. (Here is an example for the SDIO option.)

insmod compat/compat.ko
insmod net/wireless/cfg80211.ko
insmod net/mac80211/mac80211.ko
 insmod drivers/net/wireless/laird/lrdmwl/lrdmwl.ko
insmod drivers/net/wireless/laird/lrdmwl/lrdmwl_sdio.ko
Ifconfig wlan0 up

2. Set interface as AP mode

iw dev wlan0 interface add wlan1 type __ap

3. Use hostapd utility to load hostapd.conf to enable AP.

hostapd /etc/hostapd/hostapd.conf -B (Set interface=wlan1 in hostapd.conf)

1. Add two modules in the list of blacklist.conf:

vi /etc/modprobe.d/blacklist.conf
blacklist cfg80211
blacklist mac80211

2. Export the kernel settings and build driver:

export KLIB_BUILD=/lib/modules/4.4.0-31-generic/build
export KLIB=/lib/modules/4.4.0-31-generic/kernel

tar xf backports-laird-7.0.0.242.tar.bz2  -C projects/
cd ~/projects/laird-backport-7.0.0.242/
make defconfig-sterling60
make

3. Copy firmware to host and add link file  (here is an example of the PCIE option):

sudo mkdir /lib/firmware/lrdmwl
sudo cp 88W8997_ST_pcie_uart_v5.4.24.1.bin /lib/firmware/lrdmwl/
sudo cp regulatory_sterling60.db /lib/firmware/
cd /lib/firmware/lrdmwl
sudo ln -s 88W8997_ST_pcie_uart_v5.4.24.1.bin 88W8997_pcie.bin
sudo ln -s  /lib/firmware/regulatory_sterling60.db /lib/firmware/regulatory.db

4. Load the drivers:

cd ~/projects/laird-backport-7.0.0.242/
sudo insmod compat/compat.ko
sudo insmod net/wireless/cfg80211.ko
sudo insmod net/mac80211/mac80211.ko
sudo insmod drivers/net/wireless/laird/lrdmwl/lrdmwl.ko
sudo insmod drivers/net/wireless/laird/lrdmwl/lrdmwl_pcie.ko

The ST60/SU60 modules supports either the open-none or WEP methods in ad hoc mode.

To enable ad hoc mode:

1. Set the interface type as ibss mode and bring it up.

# iw wlan0 set type ibss
# ip link set wlan0 up

2. run wpa_supplicant on all devices connected to the network with the following command:

# wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant_adhoc.conf -D nl80211

To configure open-none:

/etc/wpa_supplicant_adhoc.conf
ctrl_interface=/run/wpa_supplicant GROUP=wheel
ap_scan=2
network={
    ssid="Laird_adhoc"
    mode=1
    frequency=2432
    key_mgmt=NONE
}

To configure WEP:

/etc/wpa_supplicant_adhoc.conf
ctrl_interface=/run/wpa_supplicant GROUP=wheel
ap_scan=2
network={
    ssid="Laird_adhoc"
    mode=1
    frequency=2432
    key_mgmt=NONE
    wep_key0="11111"
   wep_key1="22222"
   wep_key2="33333"
   wep_key3="44444"
    wep_tx_keyidx=0
}

No, LE coded is not supported in ST60.

No. Even though this line wire to PCIE_W_DISABLEn in ST60-SIPT module, but there is no feature implementation in this pin to handle the reset of module.

Follow IEEE spec as below:

The transmitter center frequency tolerance shall be ± 20 ppm maximum for the 5 GHz band and ± 25 ppm maximum for the 2.4 GHz band. The different transmit chain center frequencies (LO) and each transmit chain symbol clock frequency shall all be derived from the same reference oscillator.

Wifi adapters by default often come up in a power save mode. That is a mode in which the adapter shuts off the network connection in a state of inactivity.

While this is a good way to achieve additional power savings it of course introduces a delay for re-connecting.

To set the mode on or off:

iw wlan0 set power_save on
iw wlan0 set power_save off

To query the current setting issue:

iw wlan0 get power_save

Some systems might require "sudo" in front of the commands to be exectuted.

bluetoothctl 

[bluetooth]#Power on

[bluetooth]#menu advertise

[bluetooth]# manufacturer 0x0077 0x12 0x34

[bluetooth]# name myDevice

[bluetooth]# back

[bluetooth]# advertise on

[bluetooth]# menu gatt 
[bluetooth]# register-service e2d36f99-8909-4136-9a49-d825508b297b

[bluetooth]# yes

[bluetooth]# register-characteristic 0x1234 read

[bluetooth]# 0x12

[bluetooth]# register-characteristic 0x4567 read,write

[bluetooth]# 0x34

[bluetooth]# register-application

bluetoothctl 

[bluetooth]#Power on

[bluetooth]#menu advertise

[bluetooth]# manufacturer 0x0077 0x12 0x34

[bluetooth]# name myDevice

[bluetooth]# back

[bluetooth]# advertise on

[bluetooth]# menu gatt 
[bluetooth]# register-service e2d36f99-8909-4136-9a49-d825508b297b

[bluetooth]# yes

[bluetooth]# register-characteristic 0x1234 read

[bluetooth]# 0x12

[bluetooth]# register-characteristic 0x4567 read,write

[bluetooth]# 0x34

[bluetooth]# register-application

[802-1x]

ca-cert=/root/certs/_ca.pem

eap=peap;

identity=xxxx

phase2-auth=tls;

phase2-ca-cert=/root/certs/_ca.pem

phase2-client-cert=/root/certs/_user.pem

phase2-private-key=/root/certs/_user.pem

phase2-private-key-password=cert-password

Yes, ST60/SU60 firmware support 2MPHY and no need to have extra setting and able to support it.

Yes, actually up to three APs with different SSIDs are possible to be created on the very same 60-radio.
The 60-radio is required because it supports up to three MAC addresses.

Each AP will have to be created on the very same channel as there is only one singel radio in the 60 module.

Of course since this must all be on the same channel in the same band heavy constraints with throughput and bandwidth have to be taken in account.

Only two 80MHz channels, and setting as below. No DFS band support in AP mode.

Band 1:

network={
        mode=2
        ssid="vht-80"
        scan_ssid=1
        key_mgmt=NONE
        frequency=5180
        vht=1
        ht40=1
        max_oper_chwidth=1
        vht_center_freq1=5210
}

Band3:

network={
        mode=2
        ssid="vht-80"
        scan_ssid=1
        key_mgmt=NONE
        frequency=5745
        vht=1
        ht40=1
        max_oper_chwidth=1
        vht_center_freq1=5775
}

Please refer this blog as below. Laird are currently investigating these issues internally and investigating with the chipset vendors and our internal QA team to establish test scenarios to evaluate the impacted devices.

/resources/blog/frag-attack-wi-fi-putting-pieces-back-together

No, all the power control has been handled by ST60-2230C-U/ST60-2230C-UU.

The 8997 has a different USB architecture than the LWB5+.  

The 8997 in USB/USB mode is a composite device – it has multiple interfaces on one device.  

The LWB5+ in USB/USB mode is two separate devices behind an internal hub.  Each of the LWB5+ devices has an interface.  

In Linux, the client drivers are interface drivers, not device drivers.  So in both cases, the driver loads against an interface, it just happens that the interfaces are on the same device for 8997, and different devices for LWB5+

Prior to firmware loading, the 8997 device reports as 1286:2052.  After the firmware is download, the 8997 resets, and reattaches to USB.  At that point, the downloaded firmware is running and it reports as 1286:204e.

(1) While setup the environment, make sure the environment is under control, better not to use 2.4GHz channel for the testing. Antenna attach well or not is not related to frequency, so better to test in 5GHz channel.

(2) If you want to setup several devices at the same time, you may setup AP with different channels  (recommend to use 5GHz DFS channel which softAP device won’t be in these channels, less interference)

(3) You may set SISO_mode=1 to test if the device is able to connect to AP. Then change setting to SISO_mode=2 and reboot device, check again if able to connect to AP as well.

Remember to set it back to the setting at the end of the test.

(4) Recommend to lower the AP’s power, either the AP support power adjustment feature or add attenuator in AP antenna, so that it can tell only when attach antenna well, then it’s able to connect AP.

P.S.: the signal difference with antenna and without is around 30~40dB. And the sensitivity of the module is around 90~94dBm.

With the latest release 8.x.x.x release, it's able to run up to 5.4 kernel so that able to run in Ubuntu 18.04 as well.

CONFIG_ARCH_BERLIN  need to be disabled

Platform Selection  -->

[ ] Marvell Berlin SoC Family

Networking support --> Wireless

[ ] cfg80211

Device Driver -->

[*] LED support

<*> LED Class Support

<*> LED Support for GPIO connected LED

[*] LED support for LEDs on system controller

 -*-  LED Trigger support

<*> LED Heartbeat Trigger

[*] LED CPU trigger

Cryptographic API -->

<*> CCM support

<*> GCM/GMAC support 

<*> CMAC support 

<*> CRC32 CRC algorithm 

<*> AES cipher algorithms 

<*> ARC4 cipher algorithm

Kernel hacking

<*> Kernel debugging

If WiFi interface is PCIE, then need to check the following configuration as well.

Bus support -->

[*] PCI Support 

[*] Message signaled Interrupt

[*] Root port Advance error reporting support

[*] PCI express ASPM control

For BT, need to have few more extra configuration.

Cryptographic API -->

<*> ECDH algorithm 

Networking support --> 

< > Bluetooth

The Jetson nano is giving out 64-bit DMA addresses but the ST60-2230-P/-PU as well as the ST60-SIPT operating on the PCIe interface only support 32-bit DMA addresses.

You can follow the instructions behind this link to make the Jetson-nano issuing 32-bit addresses: https://forums.developer.nvidia.com/t/jetson-nano-custom-motherboard-wifi-doesnt-work/109485
 

The Yocto layer includes a mechanism to configure the regulatory domain using the module parameter
mechanism.

LWB_REGDOMAIN variable needs to be set iny out local.conf file:
LWB_REGDOMAIN = "US"

This will create a brcmfmac.conf file in /etc/modprobe.d containing the specified
country code in the regdomain module parameter.
 

Once you have created the soft AP on your Linux system and have successfully connected clients to the soft AP you can issue the command:

# iw wlan0 station dump

This will get a list of connected clients. 

Note: the interface name (here: wlan0) might be different in your system.

While the high speed UART of the 88W8997 chip on the 60-series supports up to 4 Mbaud the speed is actually fixed to 3 Mbaud in the firmware. It cannot be changed.

So, a typical download command looks like this:

hciattach /dev/ttyS1 any -s 3000000 3000000 flow dtron

While "ttyS1" of course has to be repalced by your actual Bluetooth UART.
 

No. The firmware for the Wifi module needs to be placed in the root file system of your Linux device and will be loaded to module during every boot.

There is no firmware flashed to non-volatile memory of the module.

Of course it is a good idea to look out for new relases of software for your Wifi module.
 

You can use the Network Manager command line interface to create an open hotspot using this command:

MIMO stands for Multiple Input, Multiple Output and uses multiple transmit and receive antennas to improve quality and capacity of the wireless connection.

The AP and STA are on the same channel potentially causing disconnections if the STA roams to a different AP. The Sterling-70 has the advantage of dual independent radios that can run on different Wi-Fi channels.

MCS stands for Modulation Coding Scheme and is an industry metric index based on Wi-Fi connection parameters between a client and wireless access point. These parameters include modulation type, coding rate, spatial streams, channel width, and guard interval.

The m.2 used on our Wi-Fi modules is an E-key. Review the PCI Express M.2 Specification from the PCI-SIG website for more information.

• Here is an Application note on E-Key from NXP
• When using an m.2 Wi-Fi module ensure your platform supports the interface by the selected m.2 Wi-Fi module. An example is an external sleep clock which is needed by some Ezurio modules.

This can be found by reviewing the release notes for the specific product on GitHub.

• LWB, LWB5, LWB5+ - Sterling-LWB-and-LWB5-Release-Packages
• Sterling 60 - Sterling-60-Release-Packages

Yes as new kernels are updated in Ubuntu automatically it will break backports and will need to be reinstalled.

Laird modules can be used on a Ubuntu system with a kernel version that is supported by Laird backports.

To check, find the kernel version of the Ubuntu system and then check the release notes of the products to see if the latest backports supports that kernel.

Sterling-60 Release Notes

Sterling-LWB Release Notes

Inside the LE Menu, the PHY rate can be specified with the

-t [1,2]

option. Use 1 for 1MPHY and 2 for 2MPHY.

Yes, for Classic Bluetooth the BTLRU can put the module in Device Test Mode by sending the

tm

No, it's not possible to do an unmodulated carrier with BTLRU.

During the loading of the Sterling-60 kernel module if you see the following error in dmesg:
Lockdown: systemd-udevd: unsigned module loading is restricted; see man kernel_lockdown.7

This is due to Secure Boot being enabled in the BIOS and CONFIG_SECURITY_LOCKDOWN_LSM being enabled in the kernel.

The easiest way around this is to disable Secure Boot in the BIOS. Additionally the module can be signed if Secure Boot and CONFIG_SECURITY_LOCKDOWN_LSM is needed.

Configuring the ST60 for hostapd to take advantage of it's max data rate requires a bit of setup. For hostapd to take advantage it has to know all the capabilities of the radio which can be pull from 'iw list'. One will need to convert the capabilities from 'iw list' to ht_capab and vht_capab. To help do this conversion reference the hostapd full config documentation.

Note: hostapd is not officially supported at this time, but wpa_supplicant setup as an AP is support via the sterling-supplicant which can be obtained here: Sterling-60.

Below is a sample working configuration for the ST60.

# hostapd configuration
ctrl_interface=/var/run/hostapd
ctrl_interface_group=0
interface=wlan0
driver=nl80211

# IEEE 802.11
ssid=hostAPD

hw_mode=a
channel=149
max_num_sta=12
auth_algs=1

# DFS
country_code=US
ieee80211d=1
ieee80211h=1

# IEEE 802.11n
ieee80211n=1
ht_capab=[HT40+][LDPC][SHORT-GI-20][SHORT-GI-40][RX-STBC1][DSSS_CCK-40][MAC-AMSDU-3839]

# IEEE 802.11ac
ieee80211ac=1
vht_oper_chwidth=1
vht_capab=[MAX-MPDU-3895][RXLDPC][SHORT-GI-80][RX-STBC-1][TX-ANTENNA-PATTERN][RX-ANTENNA-PATTERN]
vht_oper_centr_freq_seg0_idx=155

# IEEE 802.11i
wpa=2
wpa_key_mgmt=WPA-PSK
wpa_passphrase=password1
rsn_pairwise=CCMP

M.2 Version:

• The M.2 version of the module already has DC blocking cap on the Tx side; so it's not required.
• On the Rx side of the module, it's assumed the host will have DC blocking caps on the Tx side.

SIP Version:

• You must add DC blocking cap on the Tx side of the module.
• On the Rx side of the module, it's assumed the host will have DC blocking cap on the Tx side.

The unused antenna port must be terminated with a 50 ohm load. A 1/4 Watt resistor is recommended. For the u.fl version of the module, it might be more cost-effective to just use one of the certified antennas. It's not easy to find an affordable 50 ohm resistor that plugs into the u.fl connector.

The shelf life statements are essentially to prevent mishandling of the product and not storing it properly. If the modules are still sealed in the package, stored at the proper temperature and have not been exposed to moisture they should be fine. However, when working with modules beyond their shelf life you MUST bake the modules before populating the them to your board. Failure to bake the modules could result in the yield rate dropping down lower than expectation due to popcorn or de-lamination on the modules. It is recommended that you follow IPC/JEDEC J-STD-033 which is the general standard for the handling, packing, shipping and use of moisture/reflow sensitive surface mount devices.

Our main concern is around the castellation/pads which solder the module to the board. It is imperative those pads do not get tarnished, as this would cause soldering issues. Humidity can affect solderability as well, as if there is any excess moisture in the solder on the module, during reflow of the module to the board, steam balls can essentially explode the solder and sometimes result in an open circuit (or possibly a short circuit).

As long as all of the moisture handling and temperature guidelines are being followed you will likely have no issues. It is further recommended that when you do the build with modules that have exceeded their shelf life that you start with a handful to perform a test run and do a final test to make sure all is working as expected. As long as there are no issues with the initial test run we would expect that you will not experience any problems.

To activate BT, list controller information and scan for BT/BLE devices:

# bluetoothctl
Agent registered
[bluetooth]# power on
Changing power on succeeded
[bluetooth]# list
Controller C0:EE:40:50:00:00 summit [default]
[bluetooth]# scan on

To connect to a device acting as a peripheral:

[bluetooth]# scan on
Discovery started
[CHG] Controller C0:EE:40:50:00:00 Discovering: yes
[NEW] Device 4C:90:DE:92:00:00 Pixel XL
[CHG] Device 4C:90:DE:92:00:00 RSSI: -68
[CHG] Device 4C:90:DE:92:00:00 RSSI: -58
...
[NEW] Device 4C:90:DE:92:00:00 Pixel XL
[bluetooth]# scan off
Discovery stopped
[CHG] Controller C0:EE:40:50:00:00 Discovering: no
[CHG] Device 4C:90:DE:92:00:00 TxPower is nil
[CHG] Device 4C:90:DE:92:00:00 RSSI is nil
[bluetooth]# pair 4C:90:DE:92:00:00
Attempting to pair with 4C:90:DE:92:00:00
[CHG] Device 4C:90:DE:92:00:00 Connected: yes
[NEW] Primary Service
        /org/bluez/hci0/dev_4C_90_DE_92_00_00/service0001
        00001801-0000-1000-8000-00805f9b34fb
        Generic Attribute Profile
[NEW] Characteristic
        /org/bluez/hci0/dev_4C_90_DE_92_00_00/service0001/char0002
        00002a05-0000-1000-8000-00805f9b34fb
...
[NEW] Characteristic
        /org/bluez/hci0/dev_4C_90_DE_92_00_00/service003a/char003b
        00002a8a-0000-1000-8000-00805f9b34fb
        First Name
[NEW] Characteristic
        /org/bluez/hci0/dev_4C_90_DE_92_00_00/service003a/char003d
        00002a90-0000-1000-8000-00805f9b34fb
        Last Name
[NEW] Characteristic
        /org/bluez/hci0/dev_4C_90_DE_92_00_00/service003a/char003f
        00002a8c-0000-1000-8000-00805f9b34fb
        Gender
...
[CHG] Device 4C:90:DE:92:00:00 UUIDs: 0000181c-0000-1000-8000-00805f9b34fb
[CHG] Device 4C:90:DE:92:00:00 UUIDs: 0000aaa0-0000-1000-8000-aabbccddeeff
[CHG] Device 4C:90:DE:92:00:00 ServicesResolved: yes
Request confirmation
[agent] Confirm passkey 210165 (yes/no): yes
[Pixel XL]# trust 4C:90:DE:92:00:00
[CHG] Device 4C:90:DE:92:00:00 Trusted: yes
Changing 4C:90:DE:92:00:00 trust succeeded

The peripheral device is a Google Pixel XL running Android 10 using Nordic’s nRF app with an advertising profile setup with dummy information. If you pair with a device that does not have some kind of service running, it will disconnect, as BT/BLE has nothing to do.

For international use, we recommend leaving the 60 configured in the default static worldwide mode as this mode will not violate any of our modular certifications.

The 60 series in static WW mode:

• 2.4GHz band
  • Limited to channels 1-11 for both client and AP mode
• 5GHz band
  • Flagged for no-IR (no initiating radiation)
    • Initial passive scanning in client mode
    • Standalone AP mode will not be available
  • Restrictions are due to the lack of a radar detection engine used for master devices complying to DFS regulations and different DFS requirements per region
• Assumes you are going for EN 300 440 which allows the 60 to operate as an SRD on UNII-3 in the ETSI region
• Is limited to the lowest common denominator of transmit power levels per channel and channel set available of the currently supported modular certifications
  • This mode may only become more restricted; for instance we may add a new modular cert that introduces further restrictions

Using the test scripts provided with BlueZ to setup a GATT server:

cd /lib/bluez/test/
./example-gatt-server &

Power on Bluetooth, start advertising and set to pairable:

# bluetoothctl
Agent registered
[bluetooth]# power on
Changing power on succeeded
[bluetooth]# advertise on
[bluetooth]# pairable on

Connect with Nordic's nRF smartphone app and read the fake battery level.

The Sterling supplicant is based on the open-source wpa_supplicant and is also provided as an open-source package.

We update the source and patch as needed to make sure we are up to date on the latest CVEs.

It also goes through our QA validation process with each production release of backports and firmware. For more information, see the release notes on GitHub:

The iw tool can be used to read the status of the device:

# iw dev

phy#0
        Unnamed/non-netdev interface
                wdev 0x2
                addr 7e:4a:78:cc:85:77
                type P2P-device
                txpower 31.00 dBm
        Interface wlan0
                ifindex 7
                wdev 0x1
                addr aa:bb:cc:07:0c:b1
                ssid testAP
                type AP
                channel 11 (2462 MHz), width: 20 MHz, center1: 2462 MHz
                txpower 31.00 dBm

Managed/client mode link information:

# iw wlan0 link

Connected to aa:bb:cc:12:34:56 (on wlan0)
        SSID: testAP
        freq: 2462
        RX: 364 bytes (2 packets)
        TX: 3782 bytes (22 packets)
        signal: -31 dBm
        tx bitrate: 2.0 MBit/s
        bss flags:      short-slot-time
        dtim period:    2
        beacon int:     200

AP mode to read connected client information:

# iw wlan0 station dump

Station aa:bb:cc:8b:6c:fe (on wlan0)
        inactive time:  3000 ms
        rx bytes:       6479
        rx packets:     37
        tx bytes:       9706
        tx packets:     66
        tx failed:      0
        signal:         -44 [-44] dBm
        tx bitrate:     1.0 MBit/s
        rx bitrate:     65.0 MBit/s
        authorized:     yes
        authenticated:  yes
        associated:     yes
        WMM/WME:        yes
        TDLS peer:      no
        DTIM period:    2
        beacon interval:100
        short slot time:yes
        connected time: 20 seconds

We provide a sysfs entry for this purpose:

cat /sys/class/net/wlan0/device/lrd/info
Driver name : lrdmwl
Chip type   : 88W8997-PCIE
HW  version : 7
FW  version : 5.4.29.5
DRV version : 8.1.0.11
OTP version : 1
OTP num mac : 2
Radio Type  : ST
MAC address : c0:ee:40:50:00:00
Region code : 0xff (0xff)
Country code: '00' ('00')
TX antenna  : 2
RX antenna  : 2

You must load Summit firmware for multi-BSSID support. After loading the driver and firmware, perform the following: Stop all software that may be managing the Wi-Fi interface including the supplicant, NetworkManager, connman, hostapd, etc.

List out the current virtual interfaces on the physical interface (phy):

# iw dev
phy#0
        Interface wlan0
                ifindex 7
                wdev 0x1
                addr c0:ee:40:50:00:00
                type managed
                txpower 20.00 dBm

Delete the virtual interface:

# iw wlan0 del

Add up to 3 virtual interfaces onto the phy using unique names per dev (note there are two underscores in __ap):

# iw phy0 interface add ap0 type __ap
# iw phy0 interface add ap1 type __ap
# iw phy0 interface add ap2 type __ap

Confirm the virtual interfaces exist:

# iw dev
phy#0
        Interface ap2
                ifindex 10
                wdev 0x4
                addr c0:ee:40:50:00:02
                type AP
                txpower 20.00 dBm
        Interface ap1
                ifindex 9
                wdev 0x3
                addr c0:ee:40:50:00:01
                type AP
                txpower 20.00 dBm
        Interface ap0
                ifindex 8
                wdev 0x2
                addr c0:ee:40:50:00:00
                type AP
                txpower 20.00 dBm

The MAC on the first interface will not change and each subsequent interface added will add 1 to the first MAC.

For Sterling supplicant it is limited to only 1, for the Summit supplicant it is a total of 3.

More information comparing the Summit vs Sterling stack can be found in the Summit stack product brief:

Open/unsecured Network:

network={
        ssid="myAP"
        key_mgmt=NONE
        scan_ssid=1
}

WPA2-PSK:

network={
        ssid="myAP"
        key_mgmt=WPA-PSK
        psk="password"
        pairwise=CCMP
        group=CCMP
        proto=RSN
        scan_ssid=1
}

WPA2-AES with EAP-TLS

network={
    scan_ssid=1
    ssid="myAP"
    pairwise=CCMP
    group=CCMP
    key_mgmt=WPA-EAP
    proto=RSN
    eap=TLS
    identity="user1"
    private_key="/etc/certs/user1.pem"
    private_key_passwd="user1"
    client_cert="/etc/certs/user1.pem"
}

WPA-TKIP with PEAP MSCHAPv2:

network={
    scan_ssid=1
    ssid="myAP"
    key_mgmt=WPA-EAP
    eap=PEAP
    identity="user1"
    phase1="peaplabel=auto peapver=0 "
    phase2="auth=MSCHAPV2"
    password="user1"
}

For the full documentation provided by the wpa_supplicant maintainers, please visit: https://w1.fi/cgit/hostap/plain/wpa_supplicant/wpa_supplicant.conf

In order to leverage our modular certifications, you must follow the RF design of the module associated with the chip/SIPT. Design files will be provided upon request so you can reproduce our design on your custom board. We highly suggest you to take advantage of our free design review to prevent any issues when going for certification testing.

Please submit a ticket using our support portal when you are ready to begin the process.

The country code is stored in one time programmable memory (OTP) on the 60 Series module. The default is worldwide mode. You can permanently change this in manufacturing using the LMU (Laird Manufacturing Utility). For access to this tool, please submit a ticket using our support portal and we can send you a link to the pre-compiled binaries. More information about using the tool, please download the laird-sterling-60-docs-<ver>.tar.bz2 archive and read the vendor tools application note available here.

The LRU (Laird Regulatory Utility) and manufacturing firmware are used to exercise the 60 Series radios during certification testing. We do not publicly provide the LRU, however you can submit a ticket using our support portal and we will provide the pre-compiled binaries via a secure link. For more information regarding the use of the tool, please download the laird-sterling-60-docs-<ver>.tar.bz2 archive and read the vendor tools application note.

We provide custom "thinmac" firmware that not only includes optimizations and power tables but is designed to run on the 60 Series modules. Using firmware that is not provided by us will violate the modular certifications and may not work with our module.

We provide driver support via our fork of the backports package. Backports replaces the kernel-side Bluetooth stack and Wi-Fi stack including cfg80211, mac80211 and custom "lrdmwl" driver. We regularly perform a kernel rebase to keep up with LTS releases which provides the benefit of running a modern stack on a range of kernels. We perform build verification regression testing including popular silicon vendor kernels such as Xilinx, nVidia, ST Micro, TI and NXP. All releases are QA validated in our automated testing system.

We support our customers integrating backports in different Linux build environments including Yocto, Buildroot and PetaLinux. Please contact support if integration assistance is needed.

CVEs that have been addressed are referenced in our release notes. If there is a new CVE or one that is not listed in our release notes, please submit a ticket using our support portal and we will provide the status.

Radio-specific release notes can be found in the corresponding GitHub repo: https://github.com/LairdCP/Release-Packages

Yes, the unused antenna port needs to be terminated with 50 Ohms.
Please also refer to the application note "app_note_60_siso" that can be found in the documentation archive on Github where you downloaded the Laird software for the module.

On Github where all software releases for the 60-series modules can be found 60 Releases amongst every release there is an archive called for example: "laird-sterling-60-docs-8.3.0.16.tar.bz2 In the archive there are technical documents like:

• app_note_60_antenna_adjust
• app_note_60_reset
• app_note_60_siso
• app_note_60_summit_awm
• app_note_60_summit_supplicant
• app_note_60_vendor
• app_note_60_wow
• sig_60_series_radio
• user_guide_60_dvk_su60_sipt
• user_guide_60_networkmanager

Most of them are very relevant for your development with the 60-series Wifi module.

If the binary returns "not found" or does not work after confirming the executable bit is set with chmod +x <filename>, then you will need to create a symlink pointing to the system's interpreter. The file tool will show the expected interpreter and architecture of a binary, readelf is a lot more verbose and is used to discover the expected "sonames" of shared libraries. These utilities do not have to be used on the target system and is convenient to use on a common x86 Linux machine. These utilities can be installed on Ubuntu with sudo apt install binutils.

Example output from the file command:
sterling_supplicant-arm-7.0.0.139/usr/sbin$ file wpa_supplicant
wpa_supplicant: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 3.0.0, stripped

Example output from the readelf command:
sterling_supplicant-arm-7.0.0.139/usr/sbin$ readelf -ld wpa_supplicant Elf file type is EXEC (Executable file)
Entry point 0xba28
There are 10 program headers, starting at offset 52 Program Headers:
...
<edited>
...
      [Requesting program interpreter: /lib/ld-linux.so.3]
...
<edited>
...
Dynamic section at offset 0x176ee8 contains 30 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [librt.so.1]
 0x00000001 (NEEDED)                     Shared library: [libnl-3.so.200]
 0x00000001 (NEEDED)                     Shared library: [libnl-genl-3.so.200]
 0x00000001 (NEEDED)                     Shared library: [libdl.so.2]
 0x00000001 (NEEDED)                     Shared library: [libdbus-1.so.3]
 0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
...
<edited>
...

To use this binary, we will have to confirm this symlink exists or create a new symlink pointing to the interpreter on the target filesystem:
cd /lib/
ls -l ld-*
-rwxr-xr-x    1 root     root        158772 Dec  2  2019 /lib/ld-2.26.so
ln -sf ld-2.26.so ld-linux.so.3
ls -l ld-*
-rwxr-xr-x    1 root     root        158772 Dec  2  2019 /lib/ld-2.26.so
lrwxrwxrwx    1 root     root            10 Dec 21 18:55 /lib/ld-linux.so.3 -> ld-2.26.so

If the binary now reports that a library is not found when executed, repeat the steps shown above for creating a library symlink/soname pointing to it's real name. This may require you to use the find command to discover the location of the library. Example for libnl-genl-3:
find / -name 'libnl-genl-3*' -exec ls -l {} 2>/dev/null \;
-rwxr-xr-x    1 root     root         18524 Feb 14 23:42 /usr/lib/libnl-genl-3.so.200.26.0
cd /usr/lib/
ln -sf libnl-genl-3.so.200.26.0 libnl-genl-3.so.200
ls -l libnl-genl-3*
-rwxr-xr-x    1 root     root         18524 Feb 14 23:42 /usr/lib/libnl-genl-3.so.200.26.0
lrwxrwxrwx    1 root     root            24 Feb 14 23:37 /usr/lib/libnl-genl-3.so.200 -> libnl-genl-3.so.200.26.0

If the library does not exist, you will have to include that package in your build. For instance if the above example libnl was missing, include the libnl package when building your filesystem.

To use an antenna that is not listed on your wireless modules datasheet, it must be of the same topology (e.g. dipole, PIFA, etc.), equal or lesser gain, and have the same in-band and out of band characteristics.

Note: Japan (MIC) lists applicable antennas on its certificates. If your antenna is not on the approved list, regardless of whether it is comparative, it must be added to the certificate before it can be used in Japan.

It is best practice to include the source in your build system. If using Yocto, our external layer will do this for you.
Here is an example manually compiling using our SOM60 as a target in a Buildroot environment:

1. Download and extract the Sterling supplicant source.
2. Navigate to the "laird" directory.
3. Edit the config_laird file:
4. Find the following line, uncomment and change the path to your "openssl/include" directory:
   original line:
   #CFLAGS += -I/usr/local/openssl/include
   modified line:
   CFLAGS += -I/wb/buildroot/output/som60sd/build/host-libopenssl-1.1.1d/include
5. Run make with the following flags
   set:
CC="" for your cross-compile binary
PKG_CONFIG="" for your pkg-config binary
PKG_CONFIG_PATH="" for your pkgconfig directory
OBJCOPY="" for your objcopy binary

Note the following example is a single line command:
make CC="/wb/buildroot/output/som60sd/host/bin/arm-buildroot-linux-gnueabihf-gcc" PKG_CONFIG="/wb/buildroot/output/som60sd/host/bin/pkg-config" OBJCOPY="/wb/buildroot/output/som60sd/host/arm-buildroot-linux-gnueabihf/bin/objcopy" PKG_CONFIG_PATH="/wb/buildroot/output/som60sd/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/pkgconfig"

There are certain patch ranges within kernels 4.4 and 4.9 that need a modification so backports can build, the reason why we cannot fix it in backports is that we cannot track and differentiate between patch versions of the same 'major.minor' version of kernel. To fix this issue, move the function kobject_has_children from linux/kobject.h to drivers/base/core.c in your kernel source, rebuild the kernel and then rebuild backports.

No, the ST60 SIPT module on the 2230C carrier board is strapped for 1.8 VIO operation only. Design for an embedded SDIO operation and does not allow 3.3 VIO even during card enumeration.

Additional documentation can be located in the Sterling 60 GitHub repository

In order to be able to leverage the Modular Approval of a wireless module the following requirements have to be met:

• The RF circuitry must be shielded
• The module must have buffered modulation/data inputs. Module must inherently ensure compliance under host fault (watch dog) conditions
• The module must have a regulated power supply
• An antenna needs to be attached permanently or a unique antenna connector must be mounted on the module
• The module must be compliant with the regulations in a stand-alone configuration
• The module must be labeled with its permanently affixed FCC ID label or use an electronic display
• A user manual needs to provide comprehensive instructions to explain compliance requirements.
• The module must comply with RF exposure requirements

Our only officially supported option for RTOS is the Sterling-LWB with Cypress? WICED stack. However, if you are interested in using our module with an RTOS please contact Laird support for more information and assistance.

The 60 series supports a limited SoftAP mode. It is not certified or capable of being a full AP.

When using the 60 series raido you should leverage our latest backports package and documentation. If you do this, as a result, you should have bluetooth.ko and hci_uart.ko. These are the required kernel modules for Bluetooth.

When using the 60 series radio you should leverage our latest backports package and documentation. If you do this, as a result, you should have the following kernel modules: compat.ko, cfg80211.ko, mac80211.ko, lrdmwl.ko, and lrdmwl_sdio.ko.

You may not have enough space for the firmware. Verify the size of the specific firmware you are using and compare that to your available space. It is also possible that your firmware is not in the correct directory. Verify the location of the firmware file. If neither of these seem to be the issue, please contact Laird support and have the MAC address of your module handy.

It supports Linux kernel versions ranging from 3.18 to 4.9 using our backports package.

The 60 series radio supports every BT 5 feature with the exception of LE Long Range.

All of them.

Generally speaking the difference is that a Thick MAC firmware will have most of the radios features and options built into the firmware. With a Thin MAC firmware many features are pulled out of the firmware and put into the driver and supplicant.

There are several differences. Wave 2 has or supports Multi User MIMO, higher PHY rates, larger channel width, an additional spatial stream, and higher MAC throughput.

The interfaces for WiFi are USB, SDIO, and PCIE. The interfaces for Bluetooth are UART, SDIO, and USB.

Yes and no. The Sterling-60 module does not support CCX. The Summit-60 module does indeed support CCX.

Yes, WoW is supported on  WLAN. Please see our Wake on Wireless application note for more information. In future releases we will support WoBT.

The 60 series radio as well as the 50 support the the M.2 ?E? key.

Yes. The 60 has coexistence arbitration for WLAN, Bluetooth, and LTE operation.

Yes, the Sterling-60 can be upgraded to a Summit-60 with a software upgrade. There is a license agreement that needs to be in place before this can be done. Please contact us for information.

Yes, but it?s capabilities and features will be limited to those of 802.11ac Wave 1.

There are no hardware differences between the two modules. However there are vast software differences. The Sterling-60 provides professional grade connectivity while the Summit-60 has more security and roaming features intended for Enterprise use.

Yes, in our 2nd software release we will provide the capability to switch between a 1x1 and a 2x2 configuration.

Yes, the 60 radio supports SDIO 3.0.

Only the Summit-60 will support 802.11d. The Sterling-60 does not support 802.11d.

No, the 60 series radio only supports 20, 40, and 80 MHz wide channels. It does not support 120 MHz channels.

We test our Sterling supplicant for all of the following EAP types: EAP-FAST LEAP PEAP-MSCHAP PEAP-GTC PEAP-TLS EAP-TLS EAP-TTLS

No, actually this message is only a warning and should only come up when the highest linux printk debug is set. Laird does not use this file within its software. Hende the warning as well as the file an be neglected.

There is no way to upgrade the settings on the module to run SUMMIT software. However in order to make use of the DVKs mainboard the WiFi module ST60-2230x can be replaced with a SU60-2230x to make the DVK compatible with SUMMIT software.  

If you don't want simultaneous ap/sta, you can run the commands:

nmcli conn add type wifi ifname wlan0 con-name softAP autoconnect no ssid softAP

nmcli conn modify softAP 802-11-wireless.mode ap 802-11-wireless.band bg 802-11d

nmcli conn up softAP

You can also do it via wpa_supplicant .conf files if you do not have nmcli.

GPIO Pin on the 88w8997 Pins on SIP WOW Use GPIO 0 23 88W8997.WLAN->Host wake up GPIO 3 67   88W8997.BT->Host wake up PMU_EN 51 Host->88W8897 wake up  

Attached power point file.  

Attached power point file.  

The Sterling 60 has connectors for two antennas. What is the performance difference for 802.11AC with only one antenna? That is, a single antenna firmware version was mentioned for the Sterling 60 at a later date. How would that performance compare to the two antenna 60?  - Regarding performance difference between 1x1 and 2x2 MIMO:  We haven?t tested it yet.  Theoretically, 1x1 has half the throughput of 2x2, but you will also lose out on some TX and RX performance.  Typically, with 2x2 MIMO, the TX power is amplified thanks to 2x2 MIMO phase shifting.  Using single antenna you can expect 3dB loss in TX power which equates to half the TX performance vs using two antennas.  For 1x1 RX; the radio will only have one chance to receive a packet, whereas 2x2 gives the radio 2 chances to receive a packet.  With that said, to achieve max performance we recommend two antennas.  However single antenna does offer benefits such as lower power consumption and allow for a smaller form factor product.      

Simply log into GitHub, go to the corresponding release packages page and click the "Watch" button (eye icon) in the top right of the page. Some radios (such as the LWB Series) requires you to download firmware separately from the product page; this firmware is updated on the product page in conjunction with GitHub releases.

Release Packages