How to wake 43455

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
joe
Level 1
Level 1
10 sign-ins 5 sign-ins First reply posted

Please correct me or give me some advise about how to test and use the wake on wireless lan function.

I suppose the released driver is capable of assert WL_HOST_WAKE when receive magic packet and do the following steps.

  • I setup a embedded linux environment with iw, wpa-supplicant, and the 43455 fmac driver
  • Establish connection to WIFI AP router with help of wpa-supplicant and got a valid IP address.
  • Run command:
     iw phy0 wowlan enable disconnect magic-packet 
  • Run command:
    echo "standby" > /sys/power/stat
  • Issue magic-packet by another computer within the same lan
  • No change on WL_HOST_WAKE

 

Best Regards,

Joe.

0 Likes
1 Solution
GauravS_31
Moderator
Moderator
Moderator
10 questions asked 250 solutions authored 250 sign-ins

WL_HOST_WAKE is used for Out of band(OOB) wakeup of host. To enable it the following is required:

1. The OOB interrupt should be enabled in device tree. Example dts files with and without OOB is shown in \cypress-fmac-v5.10.9-2021_1020\cypress-devicetree\iMX6SX\4.9.88.

2. The nvram parameter "muxenab" has to be set to 0x10 for hardware OOB and sd_oobonly=1 /* Send to OOB only */

View solution in original post

12 Replies
GauravS_31
Moderator
Moderator
Moderator
10 questions asked 250 solutions authored 250 sign-ins

WL_HOST_WAKE is used for Out of band(OOB) wakeup of host. To enable it the following is required:

1. The OOB interrupt should be enabled in device tree. Example dts files with and without OOB is shown in \cypress-fmac-v5.10.9-2021_1020\cypress-devicetree\iMX6SX\4.9.88.

2. The nvram parameter "muxenab" has to be set to 0x10 for hardware OOB and sd_oobonly=1 /* Send to OOB only */

joe
Level 1
Level 1
10 sign-ins 5 sign-ins First reply posted

Still no change on WL_HOST_WAKE (In my case voltage is keeping 0v)

Had append the  lines to nvram

# enable wowl
muxenab=0x10
sd_oobonly=1

I trying to trace the driver, seems not parse the device tree. Maybe something wrong when I compile the driver.

The variable nb is NULL at

Source line to inspect 

 

0 Likes
lock attach
Attachments are accessible only for community members.
GauravS_31
Moderator
Moderator
Moderator
10 questions asked 250 solutions authored 250 sign-ins

Yes, if nb is NULL, that could be a problem. It is defined as *np = dev->of_node; in brcmf_of_probe() definition, where of_node is associated device tree node. If of_node is NULL, there might be an issue in the device tree configuration. Can you please check your device tree once? For reference, I have attached a sample device tree file for OOB, valid for imx6sx.

0 Likes
GauravS_31
Moderator
Moderator
Moderator
10 questions asked 250 solutions authored 250 sign-ins

Also, I have presumed that you have used GPIO_0 as WL_HOST_WAKE on CYW43455

0 Likes
lock attach
Attachments are accessible only for community members.
joshuacv
Level 1
Level 1
5 sign-ins First reply posted Welcome!

Was this problem resolved?

Which driver are you using?

I am trying to do the same on a broadcom chip - 4356 using the brcmfmac driver on a linux 5.4 kernel.  So far I have tried the following:

1. make sure the following files are in the /lib/firmware folder   

  • brcmfmac4356.bin
  • brcmfmac4356.clm_blob
  • brcmfmac4356_pcie.txt

2. iw phy0 wowlan enable magic-packet

3. Added the following lines in the  "brcmfmac4356_pcie.txt" file:

muxenab = 0x10

sd_oobonly= 1

wowl_gpio = 0

wowl_pol = 1

Still no sign of wake up when I send a magic packet with the MAC-address of the adaptor from another computer which is on the same network. 

Any ideas? Does anyone have any official NVRAMs file for the 4356 adaptor? I suspect mine is contaminted because it was copied from elsewhere. I have attached my NVRAMs (pcie.txt) file here.  



0 Likes
GauravS_31
Moderator
Moderator
Moderator
10 questions asked 250 solutions authored 250 sign-ins

@joshuacv Official NVRAM file can be obtained from your module vendor. In addition to nvram, did you modify the device tree to allow OOB interrupts?

0 Likes
lock attach
Attachments are accessible only for community members.

@GauravS_31 - Thanks for your reply. I did not change the device tree yet. I saw what needs to be done from this  post: https://community.infineon.com/t5/AIROC-Wi-Fi-and-Wi-Fi-Bluetooth/How-to-use-out-of-band-OOB-interru...

I am not using the WICED tool chain to do all this. I am trying to get this BCM4356 wifi module on a PCIE slot to run with linux kernel 5.4. Does this means that I will have to compile the kernel with the altered device tree flags for OOB interrupts? Do you happen to have any guide to do this? I found this README file from Cypress's guide to compile the brcmfac driver for older kernels . Could you confirm if this is what is to be done?

Thanks a tonne!


0 Likes
GauravS_31
Moderator
Moderator
Moderator
10 questions asked 250 solutions authored 250 sign-ins

No, you don't have to compile the kernel, but you would need to compile the DTS file to DTB using DTC. It is explained in this blog post https://community.infineon.com/t5/Resource-Library/Linux-Device-Tree-FMAC/ta-p/246025.

0 Likes

@GauravS_31 Is there anyway to get the dts file for the standard BCM4356 module? 

I might be asking the wrong questions - sorry. Not an expert here. 

0 Likes
GauravS_31
Moderator
Moderator
Moderator
10 questions asked 250 solutions authored 250 sign-ins

There is no DTS file for each WLAN radio, it is prepared for the linux host and it describes the hardware connections from the host. You can check this link https://github.com/torvalds/linux/tree/master/arch/arm/boot/dts for the DTS files of different vendors. I had already shared a sample DTS file
imx6sx-sdb-btwifi-fmac-oob.zip in my response 3 above, which specifies the Wi-Fi specific additions. From the CYW4356 radio perspective, the WLAN_HOST_WAKE which is WLAN GPIO_0 serves as OOB pin. But it should be connected to a GPIO pin on the host device. And in the device tree, that host GPIO pin should be an interrupt pin. In the sample DTS file imx6sx-sdb-btwifi-fmac-oob.dts, it is declared as:

interrupt-parent = <&gpio6>;
interrupts = <9 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "host-wake";

The above interrupt parameters have been explained in https://elinux.org/Device_Tree_Usage. You would need to refer to your host documentation to understand how the interrupts is encoded in device tree.

0 Likes
joshuacv
Level 1
Level 1
5 sign-ins First reply posted Welcome!

@GauravS_31 Sorry to bother you again! I might be close to a solution but the device tree is still elusive. My linux host has a x84_64 architecture. My bootloader is grub. So I guess I will have to recompile the kernel so that it looks for a dtb file? Isnt the default device tree specific to ARM? I might be gravely mistaken.

I tested an Atheros QCA6174 chip for the same computer and it worked. I am just wondering how it worked without the OOB interrupt enable in the device tree. Just technical curiosity - do you know how the other chip might have worked without the device tree? 

In either case, I am trying to find out the gpios on my motherboard. Hopefully, I get hold of some documentation

0 Likes
GauravS_31
Moderator
Moderator
Moderator
10 questions asked 250 solutions authored 250 sign-ins

Yes, even though there is some level of device tree support for x86 https://www.kernel.org/doc/html/latest/devicetree/usage-model.html, the default device tree is specific to ARM, which is used for embedded linux. If your x86 kernel has a provision for device tree, you can consider recompiling it. As far as I understand, x86 devices largely use ACPI.

To understand why the OOB worked without device tree, you can check this function *brcmf_get_module_param() definition. You will find that it initially looks for device specific platform data under this condition if (brcmfmac_pdata). If it fails, after that it checks for device tree, otherwise it doesn't. My best guess is that QCA6174 chip would be having linux platform data hardcoded, and the if (brcmfmac_pdata) would have passed, that is why device tree was not required.

In your case, there are two options, since you are using grub bootloader, you can try loading the .dtb file using devicetree command https://www.gnu.org/software/grub/manual/grub/html_node/devicetree.html. Alternately, you can check for the platform device configuration for your x86 device. This struct brcmfmac_pd_device *device_pd contains the SDIO Device specific platform data as defined in the struct below and in brcmfmac.h:

struct brcmfmac_sdio_pd {
int txglomsz;
unsigned int drive_strength;
bool oob_irq_supported;
unsigned int oob_irq_nr;
unsigned long oob_irq_flags;
bool broken_sg_support;
unsigned short sd_head_align;
unsigned short sd_sgentry_align;
void (*reset)(void);
};

The platform data brcmfmac_pdata shown above is initialized in brcmf_common_pd_probe() as shown below:

brcmfmac_pdata = dev_get_platdata(&pdev->dev);

0 Likes