请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
器件型号： AM623
To Texas Instruments Technical Support Team,
## 1. Basic Environment Information
| Item | Details |
|------|---------|
| SoC | TI AM62x Series Sitara Processor |
| Ethernet Subsystem | CPSW3G |
| ALE Version | 1.5 |
| Linux Kernel Version | 5.10.168-rt83 |
| Affected Interfaces | eth0, eth1 (on-chip CPSW3G MAC ports) |
| Unaffected Debug Interface | usbnet3 (USB Ethernet, for out-of-band access) |
## 2. Issue Overview
We have encountered two independent hardware/driver-related bugs in the CPSW3G Ethernet subsystem on the AM62x platform, which result in complete connectivity failure of the eth0 and eth1 ports (ICMP ping unreachable, TCP SSH connection failed). Only the out-of-band USB Ethernet interface is accessible for debugging. We have completed full issue reproduction, root cause localization, and temporary workaround validation. This request is submitted to seek official root cause confirmation and permanent solutions from TI.
## 3. Detailed Bug Description, Root Cause Analysis & Validation
### Bug 1: ALE VLAN_AWARE Mode Persistence Causes Ingress Priority-Tagged Frame Drop
#### 3.1.1 Issue Phenomenon
- When the `VLAN_AWARE` bit (bit[2]) of the ALE Control Register (`ALE_CTRL`, physical address `0x0803E008`) is set to 1, all ingress 802.1Q Priority-Tagged Ethernet frames (VID=0) are continuously dropped by the ALE hardware.
- The `ale_vid_ingress_drop` and `p0_ale_vid_ingress_drop` counters in `ethtool -S` increase continuously at a rate of ~400 packets per second on the faulty device, while remaining stable on normal devices of the same hardware/software version.
- ARP resolution works normally (L2 reachability), but all IP packets are discarded, confirming the issue is at the L2/ALE layer.
#### 3.1.2 Root Cause & Trigger Condition
1. **Trigger Source**: When eth0/eth1 is added to a Linux bridge, the driver internally triggers `switch_mode` switching, which sets the `VLAN_AWARE` bit in `ALE_CTRL` to 1. Even after the bridge is deleted, the `VLAN_AWARE` configuration persists in the hardware register through warm reboots.
2. **Driver Behavior**: The `am65-cpsw-nuss` driver forcibly re-sets the `VLAN_AWARE` bit to 1 in the `ndo_open()` callback (executed when the network interface is brought up). This makes software-level configuration changes unable to permanently clear the abnormal state.
3. **Forwarding Failure Root Cause**: On normal devices with `VLAN_AWARE=1`, the ALE VLAN table has a valid entry for VID=0, so ingress Priority-Tagged frames are forwarded normally. On the faulty device, the ALE VLAN table is corrupted by the historical bridge operation, and the valid VID=0 entry is missing, resulting in all tagged ingress frames being dropped by the ALE hardware.
#### 3.1.3 Validation & Temporary Fix
- Directly writing `0x80000001` to the `ALE_CTRL` register via `devmem` (clearing the `VLAN_AWARE` bit to 0) immediately resolves the ingress frame drop issue.
- However, after any `ip link set eth0/eth1 down/up` operation, the driver's `ndo_open()` callback resets the `VLAN_AWARE` bit to 1, and the fix becomes invalid.
- Additional note: The driver maintains an internal `usage_count` (number of currently UP CPSW interfaces). Only when all CPSW interfaces are brought down at the same time (usage_count returns to 0) and then brought up again, the driver triggers a full re-initialization. Sequential down/up of individual interfaces does not reset the abnormal ALE state.
---
### Bug 2: TX Checksum Offload Causes TCP Header Corruption When Inserting 802.1Q VLAN Tag
#### 3.2.1 Issue Phenomenon
- After bypassing ALE VLAN filtering by enabling promiscuous mode (sets `ALE_BYPASS`), ICMP ping works normally, but TCP connections (e.g., SSH) still fail to establish.
- Packet capture analysis shows that the TCP SYN-ACK packets sent from the faulty device have an invalid TCP header: `[bad hdr length 0 - too short, < 20]`. The Data Offset field of the TCP header is incorrectly modified to 0.
#### 3.2.2 Root Cause
When TX checksum offload is enabled on the CPSW3G, the hardware corrupts the Data Offset field of the TCP header while inserting an 802.1Q Priority-Tagged (VID=0) VLAN tag into the egress frame. This results in an invalid TCP header length, and the TCP three-way handshake cannot be completed.
#### 3.2.3 Validation & Temporary Fix
- Disabling TX checksum offload via `ethtool -K eth0/eth1 tx-checksumming off` immediately resolves the TCP header corruption issue, and SSH connections are restored normally.
## 4. Verified Temporary Workaround
The following commands can immediately restore the connectivity of eth0/eth1 when the issue occurs (executed via the out-of-band USB Ethernet interface), but the fix is not persistent and needs to be re-applied after interface reboot or system warm restart:
```bash
# Clear VLAN_AWARE bit in ALE_CTRL register to fix ingress frame drop
/sbin/devmem 0x0803E008 32 0x80000001
# Disable TX checksum offload to fix TCP header corruption
ethtool -K eth0 tx-checksumming off
ethtool -K eth1 tx-checksumming off
# Enable promiscuous mode to bypass ALE VLAN filtering as an auxiliary measure
ip link set eth0 promisc on
ip link set eth1 promisc on
```
## 5. Official Support & Technical Questions
We hereby request TI official technical support to answer the following questions and provide official solutions:
### 5.1 Questions about ALE VLAN_AWARE Mode Issue
1. What is the design logic of the `am65-cpsw-nuss` driver forcibly setting the `VLAN_AWARE` bit of `ALE_CTRL` to 1 in the `ndo_open()` callback? Is this behavior expected by design?
2. When the interface is removed from the Linux bridge, the driver does not clean up the abnormal configuration in the ALE VLAN table or restore the default state of the `VLAN_AWARE` bit, and the hardware state persists after warm reboot. Is this a known driver bug? Is there an official fix patch available?
3. For ingress Priority-Tagged frames with VID=0, what is the correct processing logic of the CPSW3G ALE when `VLAN_AWARE=1`? How should the driver correctly initialize the ALE VLAN table entry for VID=0 to avoid ingress frame drops?
4. Is there an official recommended, persistent configuration method that can completely resolve this ingress frame drop issue without invalidation after interface reboot or system warm restart?
### 5.2 Questions about TX Checksum Offload TCP Header Corruption Issue
1. Is the issue that the CPSW3G hardware corrupts the TCP Data Offset field when inserting an 802.1Q VLAN tag with TX checksum offload enabled a known hardware errata or driver bug?
2. Does TI have an official fix patch for this issue that can resolve the TCP header corruption while retaining the TX checksum offload hardware acceleration capability?
3. If this issue is a hardware limitation, what is the official recommended workaround? Is there a better way that does not lose hardware performance, other than completely disabling TX checksum offload?
### 5.3 General Questions & Long-Term Solutions
1. For the above two issues, does TI have a fully released official fix (including driver patches, device tree configuration modifications, hardware configuration recommendations, etc.) compatible with the Linux 5.10-rt series kernel?
2. For the switching of Linux bridge scenarios on the AM62x CPSW3G, are there official recommended best practices to avoid triggering the above ALE state abnormality?
3. Can you provide the official detailed programming guide for the CPSW3G ALE control registers and VLAN table configuration, to support our further debugging and persistent fix development?
## 6. Additional Supplementary Information
We can provide complete debug information upon request, including but not limited to: full kernel dmesg logs, complete `ethtool -S` statistics, packet capture files (pcap), full ALE register dump, driver configuration parameters, and device tree source files.
We look forward to your professional reply and official solutions.