[参考译文] AM6442：USB 器件配置导致 Linux 系统挂起(2)

尊敬的 Ralph：

以下内核补丁应该可以解决此问题。

https://lore.kernel.org/all/20250206125943.786949-1-s-vadapalli@ti.com/

尊敬的 Bin：

谢谢、这看起来确实很有希望。 它干净地应用于6.12.y 的顶部,但不幸的是,它仍然以同样的方式挂起。

我看不到 正在打印 dev_err(priv_dev->dev、"启用快速访问失败\n")、但要绝对确定、我在此位置之后添加了自己的 printk()、确认启用了快速访问。 奇怪的是,有了这个额外的打印,似乎没有挂起。 那么、也许在实现快速访问后需要延时时间呢？ 这可能是另一个 SR1.0 gremlin 吗？

diff --git a/drivers/usb/cdns3/cdns3-gadget.c b/drivers/usb/cdns3/cdns3-gadget.c
index 93d95946fd58..b152303781f1 100644
--- a/drivers/usb/cdns3/cdns3-gadget.c
+++ b/drivers/usb/cdns3/cdns3-gadget.c
@@ -3018,10 +3018,11 @@ static int cdns3_gadget_udc_start(struct usb_gadget *gadget,
                if (ret) {
                        dev_err(priv_dev->dev, "Failed to enable fast access\n");
                        spin_unlock_irqrestore(&priv_dev->lock, flags);
                        return ret;
                }
+               printk("RFS: fast access ok\n");
        }

        switch (max_speed) {
        case USB_SPEED_FULL:
                writel(USB_CONF_SFORCE_FS, &priv_dev->regs->usb_conf);

编辑:当我键入此回复时,它挂起,经过1000多次迭代。

第二次运行在120次迭代后挂起。

因此、似乎还有其他事情正在发生...

尊敬的 Ralph：

您能否使用下面随附的其他补丁版本进行测试？

e2e.ti.com/.../0001_2D00_usb_2D00_cdns3_2D00_cdns3_2D00_gadget_2D00_Workaround_2D00_for_2D00_successive_2D00_USB.diff

尊敬的 Bin：

非常感谢-但它似乎这个"不同的版本"似乎仍然挂起. 本例中是经过44次迭代后的测试。 以下是在为 cdns3和 UDC 事件启用跟踪时看到的结果。 它并不总是在相同的地方停止、但这种模式(3个分配通道、对于单个 ACM 小工具)和 USB_gadget_connect 相当常见。

44
        test2.sh-148     [000] ...1.    80.229859: cdns3_alloc_request: ep0: req: 000000007ddf24fb, req buff 0000000000000000, length: 0/0 zsi, status: 0, trb: [start:0, end:0], flags:0 SID: 0
        test2.sh-148     [000] ...1.    80.229920: usb_ep_alloc_request: ep0: req 000000007ddf24fb length 0/0 sgs 0/0 stream 0 zsI status 0 --> 0
        test2.sh-148     [000] ...1.    80.229963: usb_gadget_set_selfpowered: speed 0/3 state 0 0mA [sg:bus-powered:activated:disconnected] --> 0
        test2.sh-148     [000] ...1.    80.230032: cdns3_alloc_request: ep2in: req: 000000005304643c, req buff 0000000000000000, length: 0/0 zsi, status: 0, trb: [start:0, end:0], flags:0 SID: 0
        test2.sh-148     [000] ...1.    80.230034: usb_ep_alloc_request: ep2in: req 000000005304643c length 0/0 sgs 0/0 stream 0 zsI status 0 --> 0
        test2.sh-148     [000] ...1.    80.230060: cdns3_alloc_request: ep0: req: 00000000ca66c16d, req buff 0000000000000000, length: 0/0 zsi, status: 0, trb: [start:0, end:0], flags:0 SID: 0
        test2.sh-148     [000] ...1.    80.230062: usb_ep_alloc_request: ep0: req 00000000ca66c16d length 0/0 sgs 0/0 stream 0 zsI status 0 --> 0
        test2.sh-148     [000] ...1.    80.230136: usb_gadget_connect: speed 0/3 state 0 0mA [sg:bus-powered:activated:connected] --> 0

尊敬的 Ralph：

第二个修补程序适用于有相同问题的几个客户。 但是、如果它无法为您解决问题、除了使用看门狗进行复位之外、我们没有任何其他软件解决方案。

尊敬的 Bin：

Ralph 的条目确实会让系统关注配置为 USB 小工具的 AM64x 设备在受到攻击(即"挂起")之前可以运行多长时间。 对于 Linux SDK v12版本(采用较新的内核 Linux 版本)、可以研究一下这一点吗？ 我目前依赖 在与 Windows 11 PC 连接的工业环境中将 AM6442配置为 USB 2.0 ACM 串行小工具@ 480MB/秒

谢谢

Jim

您好、Jim、

到目前为止、我们在 USB 小工具控制器驱动程序调用其 start ()和 stop ()函数期间没有发现该问题、这基本上意味着插入和拔下 USB 电缆、或者 AM64x 上的 Linux 在上面的初始帖子中专门启用和禁用 UDC 作为 Rahph 的测试脚本。

我们仍在内部调查该问题、但尚不知道根本原因。 此时、权变措施是使用看门狗检测问题并对 AM64x 器件和系统进行热复位。

尊敬的 Bin：

对于报告第二个修补程序成功的客户、我们是否了解有关其系统的更多详细信息？ 它是 EVM 板还是定制板？ 它们运行的是6.12内核还是其他版本？ 只是想看看有什么不同。

在我看来、由于我的 EVM 具有 SR1.0、我们正在尝试在另一个具有 SR2.0的电路板上运行一些测试、看看这是否有所不同(当然应用了补丁)。

Ralph

尊敬的 Ralph：

我检查了内部记录、两位客户报告了问题。

一位客户在使用 SDK v8.6.0.42时发现了定制电路板和 EVM 上的问题。 客户使用看门狗复位作为解决方案。

另一个客户的定制电路板和 EVM 也遇到了问题、即 SDK v9.0和 v9.2。 客户报告说、第二个补丁程序解决了其项目的此问题。

因为问题似乎在处理器中,所以我认为内核版本不是很重要(如果有的话)。 但您可能需要使用 AM64x SR2.0进行测试、看看是否仍会遇到此类问题。 任何人都不应使用 SR1.0。

您好、Ralph、

由于您有一个 EVM、并且发现了问题、您能否应用以下从 USB 2.0 PHY 切换到 USB 3.0 PHY (SERDES)的差异？

diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
index f6a76073ec11..cb042c232bd5 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
@@ -615,15 +615,16 @@ &sdhci1 {
 &usbss0 {
 	bootph-all;
 	ti,vbus-divider;
-	ti,usb2-only;
 };
 
 &usb0 {
 	bootph-all;
-	dr_mode = "otg";
-	maximum-speed = "high-speed";
+	dr_mode = "peripheral";
+	maximum-speed = "super-speed";
 	pinctrl-names = "default";
 	pinctrl-0 = <&main_usb0_pins_default>;
+	phys = <&serdes0_usb_link>;
+	phy-names = "cdns3,usb3-phy";
 };
 
 &cpsw3g {
@@ -813,23 +814,22 @@ &main_timer11 {
 };
 
 &serdes_ln_ctrl {
-	idle-states = <AM64_SERDES0_LANE0_PCIE0>;
+	idle-states = <AM64_SERDES0_LANE0_USB>;
 };
 
 &serdes0 {
-	serdes0_pcie_link: phy@0 {
+	serdes0_usb_link: phy@0 {
 		reg = <0>;
 		cdns,num-lanes = <1>;
 		#phy-cells = <0>;
-		cdns,phy-type = <PHY_TYPE_PCIE>;
+		cdns,phy-type = <PHY_TYPE_USB3>;
 		resets = <&serdes_wiz0 1>;
 	};
 };
 
 &pcie0_rc {
-	status = "okay";
+	status = "disabled";
 	reset-gpios = <&exp1 5 GPIO_ACTIVE_HIGH>;
-	phys = <&serdes0_pcie_link>;
 	phy-names = "pcie-phy";
 	num-lanes = <1>;
 };

随着上述变化,我不再看到一个挂起,即使在大约20分钟后. 请检查并告诉我。 虽然以上内容不能修复、但我们可以帮助我们确认观察到的问题是否与 USB 2.0 PHY 的使用有关。

此致、
Siddharth。

尊敬的 Siddharth：

我已经在我的 EVM 上使用 SR1.0测试了您的补丁(USB 2.0 PHY 转 USB 3.0 SERDES)、这似乎很有帮助：到目前为止 、我有超过3000次迭代(连接/断开)、没有任何挂起、测试仍在运行。

同时、我的客户在其定制电路板上安装了 SR2.0、他们报告说无法使用此补丁、因为他们的硬件仅限于 USB 2.0。 但是、他们在 SR2.0硬件上成功安装了以前的修补程序(Bin 中的 v2)。

尊敬的 Ralph：

很高兴听到积极的消息。 期待最终测试结果。

我相信在您的客户端电路板上、只要不使用 PCIe 接口而需要 SERDES、这个新补丁仍然可以进行测试、即使电路板设计限制为 USB 2.0也是如此。

尊敬的 Bin：

客户端板(与 SR 2.0)显然具有 USB 隔离,当他们尝试了 USB 3.0补丁, USB 是不起作用的。 但他们正在成功使用您的早期补丁(上面的"不同版本")。

同时、在我采用 SR1.0的 EVM 上、USB 3.0补丁似乎有点麻烦。 它已经运行了75,000次迭代、运行了近24小时。 我还注意到主机侧仍报告检测到高速器件、而不是超高速器件。

Unknown 说：

我还注意到主机端仍报告检测到高速设备、而不是超高速设备。

串行器/解串器超高速数据线是否连接至电路板上的 USB 连接器？ 是否使用超高速 USB 电缆？

哦、我没有意识到您使用了 EVM (尽管您在上面的第一篇文章中提到过它)。

是的、EVM USB 端口仅用于 USB2.0。 有道理的是、主机只能以高速方式检测 EVM。