WL18xx Adding WoWLAN

AM335x EVM requires HW ECO to make this feature functional.

Introduction

Wake on Wireless is a feature to allow the system to go into a low-power state while the wireless NIC remains active and does varying things for the host, e.g. staying connected to an AP or searching for networks for more information refer to kernel.org

This page will discuss how to enable "Suspend Resume" WoW Mode with a WL18xx device and an AM335x host processor. With some extra work, the HW and SW modifications outlined below can also be performed on other host processors to enable WoW,

Mode of Operation

On Suspend state, the WL18XX chip will stay connected to WiFI network and will wait for specific "magic" frame on the WiFi media. Only upon receiving that frame, it will wake up the Host.

Two mode of operation are supported:

1. Suspend state: The chip will be held in shutdown mode, were the host disable the WLAN portion by keeping the WLAN_Enable signal OFF, in that mode the WL18XX consumes minimal current consumption.
2. WOWLAN state: The host is shutting down but the WLAN chip is being kept active (WLAN enable pin remains active). This allows the WL18XX firmware to remain active during suspend and if the system is configured to allow the WLAN interrupt to wake-up the host, it can trigger a system resume when a specific packet is received by the WL18XX firmware.

Adding "Suspend Resume" WOW mode to AM335x EVM

In order to enable suspend resume in the PSP you will need to add the following:

1. IRQ line - select GPIO that is capable waking up the host from suspend, i.e. from GPIO0 bank.
2. WLAN Enable - For SR1.0 silicon, AM335x Advisory 1.0.14 "GMII_SEL and CPSW Related Pad Control Registers: Context of These Registers is Lost During Transitions of PD_PER" is applicable. Normally a pin is chosen that defaults to being pulled down during AM335x reset, e.g. GPIO1_16 (GPMC_A0) was used on the EVM. It needs to be pulled down during power-up in order to meet power sequencing requirements. However, for the purpose of WoWLAN, the WL_EN pin must be pulled high. GPIO1_16 suffered from this errata for AM335x SR1.0 which caused the register to always revert back to its default value during a suspend sequence. For that reason, SR 1.0 silicon must use another pin that isn't impacted such as GPIO3_16.
3. SDIO MMC keep power – enable the SDIO to avoid re enumeration after resuming from suspend mode, since the assumption is that the SDIO continue to be in Active mode during Hosts Suspend mode. In Linux, this can be achieved by using the "keep-power-in-suspend" designator as part of the MMC configuration in the device tree.

Patch Description

The following hardware modifications were done on the am335x-evm for supporting WOW mode by the following patch

• WLAN_IRQ: moved from GPIO3_17 to GPIO0_19 (for waking up SA from suspend on WOWLAN event)
• WLAN_EN: moved from GPIO1_16 to GPIO3_16 as GPIO1_16 is losing context during suspend (AM335x SR1.0 Advisotry 1.0.14).
• Enable MMC_PM_KEEP_POWER for mmc2
• Activate padmux external pull-up for keeping WLAN_EN pin high when the host is suspending

Suspend/Resume - WOWLAN (Wake on WLAN) mode

Before we enter suspend mode we need to declare which event triggers the wake up. In this example we will set the trigger to any which means any event (console activity, magic frame, etc) will wake up the board:

There are 2 option to resume from Suspend:

1. Serial console activity or other configured wakeup sources (keypad, touchscreen) will trigger resume
2. Send Magic frame from other Station to the Station that is in suspend mode

The Procedure will be as follows:

1. Connect station (EVM) to the AP
2. Enter the EVM to suspend in WOWLAN mode ( [any] or other pattern, examples below)
   <syntaxhighlight lang="bash">iw phy0 wowlan enable any</syntaxhighlight>
3. Enter suspend mode
   <syntaxhighlight lang="bash">echo mem > /sys/power/state</syntaxhighlight>
4. Send ping to the device --> That ping will cause the first EVM to wake from suspend

Commands and expected output:

iw WoW commands:

iw <phyname> wowlan enable [any] [disconnect] [magic-packet] [gtk-rekey-failure] [eap-identity-request] [4way-handshake] [rfkill-release] [patterns <pattern>*]
iw <iwname> wowlan disable
iw <phyname> wowlan show

Enter to WoW Suspend mode, by calling the following command: <syntaxhighlight lang="bash"> echo mem > /sys/power/state </syntaxhighlight>

Following is the screen shot shows how the Host is entering suspend mode, also the wl1271 is suspended

[16277.797393] PM: Syncing filesystems ... done.
[16277.929870] PM: Preparing system for mem sleep
[16277.934509] Freezing user space processes ... (elapsed 0.02 seconds) done.
[16277.963470] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
[16277.994689] PM: Entering mem sleep
[16277.998565] Suspending console(s) (use no_console_suspend to debug)
[16278.242462] PM: suspend of devices complete after 236.060 msecs
[16278.243408] PM: late suspend of devices complete after 0.945 msecs
[16279.748199] Successfully put all powerdomains to target state

Resume from Suspend by sending ping to it.
Following is the screen shot shows how the Host is resuming from suspend mode, also the wl1271 is reconnecting to the WiFi network (by the WPA supplicant) and traffic resumes.

[16279.748840] PM: early resume of devices complete after 0.518 msecs
[16279.749237] platform iva.0: omap_voltage_scale: Already at the requestedrate 800000000
[16279.749237] platform mpu.0: omap_voltage_scale: Already at the requestedrate 1000000000
[16280.107391] PM: resume of devices complete after 358.428 msecs
[16280.157989] PM: Finishing wakeup.
[16280.161499] Restarting tasks ... done.

Rx Filter Configuration

Once enabled, WoWLAN patterns are searched by the chip firmware in every incoming data packet. Once a pattern is detected the chip wakes up the host. To configure wowlan patterns you should use the iw utility. The patterns begin with an 802.3 (Ethernet) header with the correct src/dest MACs (i.e. it's NOT the actual 802.11 header which is transmitted in the air).

Rx filters can be enabled in suspend and in awake states.

The Pattern - 802.3 Mac Header:

Destination MAC Address   6 Bytes
Source MAC Address          6 Bytes

• EtherType                              2 Bytes
• PayLoad                                 46-1500 Bytes
• CRC                                        4 Bytes

Payload could be any upper layer protocol, for filter purposes we will only show IP header as when filtering other protocols there is no need to go in the MAC payload. i.e. when configuring a filter for ARP or EAPOL there is no need to configure pattern in the ARP/EAPOL header as you want to pass all of them.

IP filter This pattern if for a frame containing a ip packet:

---

AA:AA:AA:AA:AA:AA:BB:BB:BB:BB:BB:BB:CC:CC:DD:-:-:-:-:-:-:-:-:EE:-:-:FF:FF:FF:FF:GG:GG:GG:GG:HH:HH:II:II

---

A: Ethernet destination address
B: Ethernet source address
C: Ethernet protocol type
D: IP header VER+Hlen, use: 0x45 ( 4 – is for ver 4, 5 is for len 20)
E: IP protocol
F: IP source address ( 192.168.0.4: C0:A8:00:2C )
G: IP destination address ( 192.168.0.4: C0:A8:00:2C )
H: Source port (1024: 04:00)
I: Destination port (1024: 04:00)

Restrictions:

Only 7 patterns can be active at any time

• Max size is 81 bytes
• No more then 7 segments for each pattern, if pattern crosses layer header it counts as two segments (each segment has an overhead of 4 bytes)

Ethernet protocol type

Ethertype      Protocol
0x05DC         : IEEE 802.3 length
0x0600          : XEROX NS IDP
0x0661          : DLOG
0x0800          : IP, Internet Protocol
0x0801          : X.75 Internet
0x0806          : ARP, Address Resolution Protocol
0x0807          : XNS compatability
0x0808          : Frame Relay ARP
0x8035          : DRARP, Dynamic RARP.RARP, Reverse Address Resolution Protocol
0x80F3          : AARP, AppleTalk Address Resolution Protocol
0x888E          : EAPOL, EAP over LAN
0x8100          : EAPS, Ethernet Automatic Protection Switching
0x8137          : IPX, Internet Packet Exchange
0x814C         : SNMP, Simple Network Management Protocol
0x86DD        : IPv6, Internet Protocol version 6

IP protocols

Decimal	Hex	Keyword
0	0x04	IPv4
6	0x06	TCP
2	0x02	IGMP
17	0x11	UDP
41	0x29	IPv6

Examples

• Wake up on any packet sent to MAC 00:44:44:44:44:44

    iw phy0 wowlan enable patterns 00:44:44:44:44:44

• Wake up on any TCP packet sent to MAC 00:44:44:44:44:44 IP 192.168.1.4 from TCP port 5001

   iw phy0 wowlan enable patterns 00:44:44:44:44:44:-:-:-:-:-:-:08:00:45:-:-:-:-:-:-:-:-:06:-:-:-:-:-:-:c0:a8:01:04:13:89

• Wake up on any EAPOL traffic directed at MAC 00:44:44:44:44:44

   iw phy0 wowlan enable patterns 00:44:44:44:44:44:-:-:-:-:-:-:88:8e

• Wakeup on any unicast, broadcast and multicast

   iw phy0 wowlan enable patterns 00:44:44:44:44:44 ff:ff:ff:ff:ff:ff 01:00:5e

• To set up several patterns

    iw phy0 wowlan enable patterns PATTERN1 PATTERN2 PATTERN3

• To view the configured patterns:

    iw phy0 wowlan show

Couple of things about iw:

• The ”:-:” indicate a wildcard byte which isn't matched
• phy0 identifies the physical device. Best would be to verify what it is by using “iw list | grep Wiphy”

Note: If you don't configure at all unicast pattern (which you probably should as you'd like to receive traffic intended for you) but more specific patterns it's important to include a pattern to capture EAPOLs as these are used for AP Group Rekey which occurs periodically. If these are missed then after a rekey event the station won't be able to receive multicast and broadcast traffic as it wouldn't have the right key to decrypt it (all of this is relevant only to WPA2 where there's rekey).

More on iw commands at wireless.kernel.org/en/users/Documentation/iw

WoWLAN - magic packet:

The magic packet is a broadcast frame containing anywhere within its payload 6 bytes of all 255 (FF FF FF FF FF FF in hexadecimal), followed by sixteen repetitions of the target computer's 48-bit MAC address, for a total of 102 bytes.

Since the magic packet is only scanned for the string above, and not actually parsed by a full protocol stack, it may be sent as any network- and transport-layer protocol, although it is typically sent as a UDP datagram to port 7 or 9, or directly over Ethernet as EtherType 0x0842.

The wl18xx firmware does not support scanning of the entire Ethernet frame for the magic packet. Besides, as mentioned before, the max size of a pattern is 81 bytes.

However, it is possible to define patterns that can dissect an actual implementation of the magic packet by comparing a subset of the actual magic packet.

Wakeup on magic packet with EtherType = 0x0842 or UDP port no: 9

iw phy0 wowlan enable patterns 01:02:03:04:05:06:-:-:-:-:-:-:08:00:45:-:-:-:-:-:-:-:-:11:-:-:-:-:-:-:C0:A8:01:04:-:-:00:09:-:-:-:-:ff:ff:ff:ff:ff:ff:01:02:03:04:05:06:01:02:03:04:05:06 
01:02:03:04:05:06:-:-:-:-:-:-:08:42:ff:ff:ff:ff:ff:ff:01:02:03:04:05:06:01:02:03:04:05:06 

where:
01:02:03:04:05:06 -> Destination MAC ID
C0:A8:01:04 -> Destination IP address (192.168.1.4)

The utilities "etherwake" or "wakeonlan" (on Linux) or "Wol Wake on Lan Wan" (Android) can be used to wake up the wl18xx host after setting the above pattern.

Command to run on the remote (Ubuntu) machine:

# etherwake -iwlan2 -D 01:02:03:04:05:06 
OR
# wakeonlan -i 192.168.1.4 01:02:03:04:05:06 

BA Filter setting

By default, the wl18xx firmware is enabled to send any BA action frames to the host even while the host is suspended and the data filter will not block it.
To remove the BA requests from being sent, the BA Filter in the WLCONF (that will remove the reception of BA Action Frames while suspend) can be configured.

core.conn.suspend_rx_ba_activity = 0x01

More on wlconf at: http://processors.wiki.ti.com/index.php/.INI/wlconf_Overview

HW modification for AM335x EVM

Engineering Change Order Request
Board Name: AM335x 15x15 Base Board Revision: B1 Project Name: Sitara

WOW support on Sitara platform (AM335x 15x15 Base Board)

Value Changes

1. Component             Old Value                 New Value
   R221,
   R349,                      0R 0402                   N.C
   R328,                      RES-100004R
   Description: Remove Resistors (For WLAN_IRQ modification)

     2   R350,                      0R 0402                   N.C
          R347                       RES-100004R
          Description: Remove Resistors (For WLAN_EN modification)

Wire-ups/Cuts

1.  Components Involved: TP31, R328 - Solder wire between TP31 and R328 (WLAN_IRQ)

      2.  Components Involved:  R350, R347 - Solder wire between R350 and R347 (WLAN_EN)