build/tools/amebasmart: Refine wifi wake-up logic to fix rare crash issue

[jwei5]

• Modify wififw logic to resolve rare KM4 crash after wakeup

[sunghan-chang]

@jwei5 You just changed the day in the release note. Does it mean you made a change for the same issue again?

[sunghan-chang]

@hk-gwak Please check this PR.

[sunghan-chang]

@jwei5 Please leave the issue and how to fix in detail. Current description does not help us in history.

[sunghan-chang]

Not allowed to merge. No meaningful description.

[jwei5]

Hi @sunghan-chang , as this PR currently includes some debug information used for verification, the detailed changes have not been included in the release note yet.
Once the verification is complete, we will update this PR to remove the debug information and include the detailed description. Apologies for any confusion this might have caused.

[sunghan-chang]

Hi @sunghan-chang , as this PR currently includes some debug information used for verification, the detailed changes have not been included in the release note yet. Once the verification is complete, we will update this PR to remove the debug information and include the detailed description. Apologies for any confusion this might have caused.

@jwei5 Could you let me know status of this?
@hk-gwak Any plan for this?

[hk-gwak]

Hi @sunghan-chang,
Plan is : This PR needs to be merged by this week. This change needs to be included for a project on March.
We got technical report from realtek last Friday, and reviewing this document. Will merge this PR as soon as reviewing this document is finished.

[hk-gwak]

Hi @jwei5 , Reviewing the ER, I have some questions.

1. "Detected buffer corruption; packet length and other information were invalid" -> What kind of buffer is this?
2. "Instead of writing to a buffer, WiFiFWnow simply checks the thepacket’s destination address" -> What kind of address is this? mac address?
3. "Instead of writing to a buffer, WiFiFWnow simply checks the thepacket’s destination address" -> So from now on, WiFI FW does not distinguish packet type, but only check dest addr for wakeup?
4. According to my understanding, wakeup processing was not done normally by buffer corruption. Then, Do you guess any cause of buffer corruption?

[jwei5]

Hi @hk-gwak , please refer to the replies below:

1. "Detected buffer corruption; packet length and other information were invalid" -> What kind of buffer is this?

This buffer is used for storing some details of the received packet, such as the packet length, data rate of the received packet etc.

2. "Instead of writing to a buffer, WiFiFWnow simply checks the thepacket’s destination address" -> What kind of address is this? mac address?

Yes, this refers to the MAC address.

3. "Instead of writing to a buffer, WiFiFWnow simply checks the thepacket’s destination address" -> So from now on, WiFI FW does not distinguish packet type, but only check dest addr for wakeup?

The general condition for wakeup is to check the destination address, but WiFiFW will also still distinguish packet type to filter it further. There are a few checks for the wake up flow:

1. First, check if the destination address matches.
2. Second, WiFiFW will filter further based on the packet type.
   For example, if the received packet type is Null Data, it will not wake the system even if the destination address matches.

4. According to my understanding, wakeup processing was not done normally by buffer corruption. Then, Do you guess any cause of buffer corruption?

In our tests, the buffer corruption is caused by a very specific timing mismatch during the WiFi wake-up process, which explains its low occurrence rate.
With the refined WiFiFW wake-up logic, we've eliminated the mechanism of checking the shared buffer for evaluating the wake-up condition. Instead, we directly check the destination address of the packet to ensure the correct packet content is processed, thereby preventing the issue.

[jwei5]

Rebased PR to resolve merge conflict for KM4

[hk-gwak]

Hi @jwei5 , thank you for your response. I want to ask more questions.

2. For example, if the received packet type is Null Data, it will not wake the system even if the destination address matches.

If Null Data will not wake the system, which layer is sending the ACK response for the null data packet? And is this behavior changed before/after this PR?

• First, check if the destination address matches.
• Second, WiFiFW will filter further based on the packet type.

Sounds like 1. dest addr 2. packet type. Then how about broadcast packet like ARP? There is no dest addr, then it will be filtered as no-wakeup at 1.

[jwei5]

Hi @hk-gwak,

If Null Data will not wake the system, which layer is sending the ACK response for the null data packet? And is this behavior changed before/after this PR?

Regardless whether the system is awake or sleeping, the hardware layer handles the sending of ACK response for unicast packets. This behavior remains unchanged after this PR.

Sounds like 1. dest addr 2. packet type. Then how about broadcast packet like ARP? There is no dest addr, then it will be filtered as no-wakeup at 1.

In the context of 'wake-up,' it refers to the waking up of the driver/application layer. Packets that are marked as no-wakeup (eg. Broadcast), will still be processed by WiFiFW but do not wake the driver/application.

[hk-gwak]

Regardless whether the system is awake or sleeping, the hardware layer handles the sending of ACK response for unicast packets. This behavior remains unchanged after this PR.

hardware layer -> Is this WiFiFW also?

[jwei5]

hardware layer -> Is this WiFiFW also?

No, the hardware layer refers to the physical components of the system, such as the receiver. When a packet is received, the hardware layer will reply with an ACK packet as it can handle this operation efficiently.

[sunghan-chang]

Hi @sunghan-chang , as this PR currently includes some debug information used for verification, the detailed changes have not been included in the release note yet. Once the verification is complete, we will update this PR to remove the debug information and include the detailed description. Apologies for any confusion this might have caused.

Hello @jwei5 . Please include the detailed description. This does not help maintenance in history.

[jwei5]

Hi @sunghan-chang , I have just updated the commit with more details. Could you help to check if it is ok?
Thank you.