https://e2e.ti.com/support/processors-group/processors/<p style="display:none;">blank</p>en-USTelligent Community 13https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1633648/am623-technical-support-request-am62x-cpsw3g-ethernet-ale-vlan_aware-persistence-tx-checksum-offload-corruption-issuesTue, 07 Apr 2026 03:17:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c8237095-012d-4273-a8f3-b2fe32c565a7li weiyuPart Number: 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 &amp; 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 &amp; 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 &amp; 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&#39;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, &lt; 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 &amp; 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 &amp; 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 &amp; 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.AM623https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1629566/am3354-am3354-custom-som-schematic-check-before-pcb-design/6297670Tue, 07 Apr 2026 02:43:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:7b2d1456-2c3b-46a9-9a8b-336d25b52460Kallikuppa SreenivasaHello Marius, Refer below inputs from our power expert and let me know your thoughts. Do you know if this SOM requires supporting RTC-only low power mode? and when is the customer planning to release the SOM to production? I asked because, depending on their answer we might want to recommend them to use the same power solution that was used in the latest beagle board ( https://www.ti.com/tool/BEAGL-BONE-GRN-ECO ). Regards, Sreenivasahttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1631126/tda4ven-q1-tidlrt_invoke-hangs-after-ownnodekernelschedule-tidlrt_create-succeeds/6297660Tue, 07 Apr 2026 02:29:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:3bc7ea69-dd57-4495-a9bf-c685df8e7bc5Yong ZhangDear Miao. per discussion, you can reproduce this issue w/ your model on TI J722S EVM. Right? would you please provide the model and steps to us in this ticket? thanks a lot! yonghttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1629636/am62p-am62p-spi-inter-frame-interval-problem/6297656Tue, 07 Apr 2026 02:24:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:7ae6328f-9324-49aa-aa04-420a37a864abZhou XinqiangHi To improve communication stability in high-reliability scenarios, and ensure the signal level can be pulled up quickly, pull up resistors have been added to the MOSI. Therefore the default level is high.https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1633629/am5728-connection-to-cfastTue, 07 Apr 2026 01:52:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:52f9ca91-6ec4-4a54-bb78-50ec059c66f9Shuhei GotoPart Number: AM5728 Hi team, Could you please support following inquiry? The SATA1 TX/RX pins of AM5728BABCXA are coupled through decoupling capacitors(0.1uF) to a CFAST connector. The CFAST (SATA) specifications are as follows: DC Vdiff_TX: 275 mV – 750 mV DC Vdiff_RX: 400 mV – 700 mV [Q1] What are the DC‑characteristic specifications for the SATA_Rx pins of the AM5728BABCXA? [Q2] We can only observe it on the CFAST side. We have occasionally measured RX differential voltages that are slightly higher than the maximum specified value (700 mV). From the AM5728BABCXA standpoint, is there any concern? [Q3] Very rarely (extremely low reproducibility), CFAST data cannot be read during power‑on. This occurs roughly once in tens of thousands of power‑on cycles. What can be the cause of this behavior? Best regards, GotoAM5728https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1615657/am62a1-q1-am62a-sigmoid-issue-in-psdk11-1/6297636Tue, 07 Apr 2026 01:48:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c140a128-6baf-4a89-a4b3-78e3aeef62c1Youngheon RoHi Jay, Could you give us an update on the progress of the AM62A Sigmoid? It would also be very helpful if you could share the expected timeline for the next update. Best regards, Youngheonhttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1633076/j784s4xevm-uses-the-nfm18hc106d0g-filter-at-the-power-input-stage-of-the/6297634Tue, 07 Apr 2026 01:47:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:816c2110-5c51-4706-a5d9-11bdd9da2bbdSeung rae KimThank you for your reply. I am the person who made the inquiry. I understand that it is used as a decoupling capacitor. However, as I mentioned in the main text, I do not understand why the wires are connected as shown in the red box. In the attached photo, shouldn&#39;t the part in the red box on the left be omitted and connected as shown in the circuit on the right? Additionally, would it be okay to replace the 3-terminal capacitor with a 2-terminal capacitor? I would appreciate it if you could let me know if there are any precautions to take when making the substitution. Thank you.https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1633234/am62d-q1-read-eye-mask-specification/6297629Tue, 07 Apr 2026 01:43:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:b93560bf-5ca4-497e-a823-48d1711634e6O.HHi experts, Q2 clarification: Q2-1: Is it possible for the controller to perform deskew for each bit? Q2-2: Or is it possible for the controller to perform deskew for each Byte Lane? If it is case 2-1, it is sufficient to adjust the wire length within the Byte Lane according to &quot;SPRAD66B&quot;. However, in case 2-2, it is necessary to make the wiring within the Byte Lane almost equal length (equal delay) for it to work. Best regards, O.Hhttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1632905/am625-about-am625-rpmsg/6297628Tue, 07 Apr 2026 01:42:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:92b83109-2628-4459-8bbc-932c9601949fhao tengHi Harshith I am grateful for your reply, but I still have some questions： 1、I have disabled these two drivers（rpmsg_client_sample，virtio_rpmsg_bus）. I do not have the M-core program and have not conducted remote core testing. Why did this driver testing occur? Is it because the system immediately shut down? 2、In the following, I will use the M core, rpmsgchar_init,rpmsg_char_open, read and write to communicate with the M core. Will directly using the two drivers in rmmod have any impact? Regards Haohttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1630750/am62p-am62px-soc-hw-accelerator-of-chinese-crypto-algorithm---sm2-sm3-sm4/6297625Tue, 07 Apr 2026 01:34:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:597b0be8-7a4a-4d72-bbc0-ced3224be004Tim WangThanks Hong, Is there any progress about this topic? Thanks!https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1583417/am625-am625-watchdog-enable/6297615Tue, 07 Apr 2026 01:22:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:0a964b61-ab64-45ec-a6d3-9c13901d2e78tom zhangHi Hong: Can the rti-watchdog patch applied on hs-fs device？ we want to apply the patch both on hs-fs and hs-se device. You can read the code from line 96 to line 100, and line 107, it says 50% is the larget window size. But in TRM, the register can be set as 100% window size. Which value is the larget window size?https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1632626/re-am2754-q1-is-the-ipc-the-one-and-the-only-one-method-for-communication-between-each-of-the-soc-cores/6297564Tue, 07 Apr 2026 00:24:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:4a5e1ae6-3c70-4407-a409-64588f2b3709luo luoyongchuangThank you. I understand.https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1633292/am6442-nand-memory-through-gpmc---bad-blocks-management/6297552Tue, 07 Apr 2026 00:06:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:a583f6a1-69fc-4cfa-a85f-9655c5ad0142Anastas YordanovHello Geoffrey, Thank you for your query ! The topic owner will be able to respond tomorrow. Thanks Best Regards Anastas Yordanovhttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1633277/am623-unable-to-see-usb-device-in-u-boot/6297547Tue, 07 Apr 2026 00:01:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:5496cbc3-141e-435b-b74c-cc40ee181b8cAnastas YordanovHello Daniel, Thank you for your query ! The USB topic owner will be able to respond tomorrow. Thanks Best Regards Anastas Yordanovhttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1632626/re-am2754-q1-is-the-ipc-the-one-and-the-only-one-method-for-communication-between-each-of-the-soc-cores/6297521Mon, 06 Apr 2026 23:17:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:1c7ebc55-aac0-4495-9f59-90ad8acadbd0Anastas YordanovHello Luo, Freddy, It was confirmed to me that the only method for communication between the Main R5F core and the DM R5f core and the TIFS M4 is the Secure Proxy (for the TISCI service requests) . If there are no TISCI requests from the Main R5F core, then the DM R5F and the TIFS M4 will stay in Wait For Interrupt (WFI). The Inter Processor Communication (IPC) HW for AM275x includes: Mailbox, Spinlock and Secure-Proxy. I hope this helps answer your questions ! Thanks Best Regards Anastas Yordanovhttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1633601/tms320f28335-thermal-profile-and-continuity-issuesMon, 06 Apr 2026 22:53:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:8e15b4f1-cce1-4fe4-a1e5-5cc61e84a83eJeff SteelPart Number: TMS320F28335 We are using TMS320F28335ZJZS (RoHS) Level-3-260C-168 HR with 60/40 tin lead solder. We are using the thermal profile from Application Report: SPRABY1A(MSL Ratings and Reflow Profiles (Rev. A)). We were having continuity issues with the BGA, so we machined the top of the BGA off (See clip below). When we decapped the BGA, we noticed that solder balls and solder paste did not completely mix on the BGA substrate side (See Pictures). It appears BGA&#39;s solder ball failed to merge with the paste and adhere to the BGA substrate during reflow. We would like to know if the solder balls and solder paste is not completely mixing because the temperature profile is not getting hot enough. Thanks for your support.TMS320F28335Aerospace &amp; Defensehttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1633595/am625sip-1gbyte-ddr-ram-versionMon, 06 Apr 2026 22:45:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:54186f95-6fc2-4644-92e8-9ee38dd2a1aaSachith KasthuriPart Number: AM625SIP Hello, My name is Sachith. I would like to understand the part number of AM625SIP version with 1GByte DDR RAM . Best, SachithAM625SIPhttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1631358/am623-am62x-ospi-cadence-qspi-undocumented-quirks-and-issues-with-custom-spi-slave-non-nor-flash/6297486Mon, 06 Apr 2026 22:17:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:5bc17b9e-fbe9-4220-a7c2-7aab07279c61Hong Guan64Hi Mehmet, To interface an external FPGA over OSPI. one option is using spi_mem_op structure as defined in https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/include/linux/spi/spi-mem.h The spi-cadence-quadspi.c driver implements the spi_controller_mem_ops interface. When you call spi_mem_exec_op(), it eventually triggers the controller&#39;s internal exec_op implementation. Have we tried the approach using spi_mem_op() to interact with spi-cadence-quadspi.c to communicate with an external FPGA? Best, -Honghttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1633347/dra829v-facing-issue-with-devnp-cpsw9g-in-qnx/6297475Mon, 06 Apr 2026 22:05:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:6861add2-a525-4bbc-a584-865bba8247b9Praveen RaoOk, missed reading that you are using &quot;ethernet firmware on r5f&quot;, so I assume you are using both PSDK QNX and PSDK RTOS.. Are the SDK versions of both the same? Is the issue reported in the thread PROCESSOR-SDK-J721E: CPSW9G integration with QNX 7.1 the same? If yes, can you tell how you are including the devnp driver? Is it part of QNX-IFS, or is it on the mounted file system? Can you share the complete list of file content of QNX_IFS or the file system (whichever is being used)? Thanks.https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1631825/tda4vh-q1-dp-can-not-work-without-mhdp-hpd/6297463Mon, 06 Apr 2026 21:58:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:fa3a2552-956a-48ea-88b4-155650dfa924Takuma FujiwaraHi BoWen, I have read through the patch. I see it is commented well, and a lot of descriptive logs integrated within - if the patch was written by hand, quite impressive. In any case, my suspicion was that the interrupt from HPD is needed to trigger an event within the MHDP IP block. As a troubleshooting method, if you can manually change the HPD pin state, that would be the best to simulate a system that has HPD pin physically connected... but if not possible, how about adding a delay before the read occurs? In normal case where HPD is through a physical pin, there are some registers that have some delay values for waiting until HPD stable. But disclaimer that this current usecase where none of the HPD pin is available for HPD is a first. There is no known working case as of now that does not use HPD (although, there are cases where HPD pin exists, but not hooked up correctly like the J721S2 EVM). Regards, Takuma