[参考译文] AM3352：USB2412集线器和 Bluegiga BT 软件狗出现问题

朋友、

我忘记添加：

还有一点、USB 协议分析器(总相位)抱怨错误：
I - PID 序列无效

但是、在多次分析帧时、无法找到原因。

Ty、
是的

Chris、

我们不支持 Debian。 您是否看到 AM335x 处理器 SDK 的相同问题？

您好 Biser、

我意识 到我们的偏好是客户使用我们的 TI 处理器 SDK、但我还记得 Beaglebone.org 同时支持 Ubuntu (和 Debian)及其 AM335x 平台；因此、尽管我将进行仔细检查、但我不确定这一点。

欢迎更多评论！

谢谢、
Chris

Beagleboard.org 可能支持 AM335x 上的 Debian 和 Ubuntu、但 TI 仅支持 AM335x 处理器 SDK。

团队、

客户更清楚：
----
仅为了说明我们面临的问题：

AM335x HS USB 主机->USB2412 2端口集线器->BLED112 FS 器件

此问题似乎是特定于数据包分离的问题；当主机将数据包分离发送到 FullSpeed 器件的集线器时。
最简单的复制方法是向 BLED112软件狗发送软件复位(echo -en '\x00\x01\x09\x00\x00'>/dev/ttyACM0)
然后、BLED112软件狗会自行复位、恢复使用寿命(检测到连接事件)。 来自主机的(获取设备描述符)请求将失败(集线器返回 NAK)，主机状态机似乎不会从该请求中恢复。

我已从以下位置安装了最新 SDK (v4.01)的预编译映像：
www.ti.com/.../PROCESSOR-SDK-AM335X

由于操作系统是如何将软件重置数据包发送到软件狗的，因此我无法重现问题。 我们目前通过 shell 脚本执行此操作，该脚本将数据直接写入 ttyACM 端口，但这在 Arago 编译上不起作用(现在看不出原因)。 该软件狗不接受软件重置数据包(与集线器的错误无关)。 这就是 TTY 通信通过虚拟端口的方式)。

由于我可能无法向您发送 Microchip 借给我的 EVB-USB2422电路板、我想再进行一次设置…
我在查看 AM335x 原理图，我还记得 USB2412集线器也在该板上，但(它只是在保留方向与我们的应用程序之间进行有线连接)。
USB2412在下游端连接到 AM335x 的 USB0端口。
我相信您可以通过将 Starterkit (我们称之为 A)的 USB0端口设置为全速设备(而不是高速设备)来重现此问题。
在 USB2412 (micro-AB 连接器)的上游端，您可以连接另一个 AM335x (入门套件；我们称之为 B)作为高速主机。

在入门套件 A 上、您可以强制端口 USB0向下并向上移动。
下面是建议的测试设置图：

AM335x 入门套件 A
AM335x FS USB 设备--> USB2412 2端口集线器--> AM335x 入门套件 B FS USB 主机
----
评论确实受到欢迎。

此致、
Chris

Chris、

内核日志和总线跟踪都显示在复位后将全速集线器枚举为高速集线器、这可能是 BT 枚举软件狗失败的原因。

请同时尝试以下两项更改、以查看问题是否仍然发生。

－在 u-boot bootargs 中添加"usbcore.autosuspend=-1"；

-对内核应用以下补丁以强制 USB 控制器进入全速模式。

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 7abcfa8a1a64.8fed77067486--
a/arch/arm/boot/dts/am33xx.dtsi
++ b/transc/diss=<16
、7+16






、tds/tranm =/tran>


；<16、6_demor =/tran/trans/rm =7、6+16、tr =@@@@@@@@；"trus/transc/tran/最大值=7、"trus"；<16、6_dementor =7、"trans/trans/r=7、"trus"；<16、temors=7、"trus"；<16、temors/trus"；<16、tementor =/trans/trans"=7、"trus"；<16、"trus
中断名称="MC"；
+最大速度="全速"；
DR_MODE ="OTG"；
Mentor、多点=<1>；
Mentor、num-eps =<16>；

箱、

谢谢！ 实际上、集线器是高速集线器、客户希望它是高速集线器、因为他们显然也在集线器…的另一个端口上插入了一个 WiFi 加密狗

但 BT 软件狗是全速器件、因此集线器必须进行速度转换…

他们非常确信，导致 get 设备描述符请求失败的是这种特定情况，但他们只是不知道原因(因为它是相当标准的，大部分时间都能正常工作)。

Microchip 认为其协议分析器在线路上发生了一些无法看到的情况(但它们没有证明)。

他们会尝试您的建议、因为正如您所指出的、USB 电源管理功能可能会涉及到这里。

Ty、
是的

Chris、

啊、您的第一篇文章说集线器是全速的、我没有查看其数据表...

您好、Bin、

是的、这是我的错、抱歉。 他们将尝试您的建议、但您的任何其他意见都将受到欢迎！

再次感谢、
Chris

Chris、

不用担心；)
如果我的建议有所不同、请尝试仅应用 uboot bootargs 参数、但不应用 DTS 更改来查看其运行情况、因为我们知道集线器必须在高速模式下工作。
同时，我会研究历史，看看过去数年，我们是否有类似的问题。

您好 Bin、

为了便于说明，当您说“uboot bootargs parameter”时，我们假定您是指传递给内核“bootargs=……”的参数。
如果是、他们只是尝试了、但我仍然很遗憾地遇到了问题。 …仍在尝试 Δ t、我们意识到这并不一定是一个"全部修复"...

如果不是、我们的理解不正确、请告知我其他情况。

感谢您提供的任何其他历史记录或指导。

此致、
Chris

是的、就是这样。
客户是否也尝试将 USB 控制器强制为全速？
我正在尝试查看是否可以重现 SMSC2514和 BT 加密狗的问题...

Chris、

从您在第一个帖子中提供的日志中、我知道情况是、当重置 BT 软件狗时、USB BABBLE 条件发生在重新枚举 USB 集线器和 BT 软件狗期间、然后以下 BT 软件狗枚举失败。

我将2个 BT 加密狗连接到 SMSC2514集线器、然后连接到 AM335x GP EVM 上的 USB1端口。 由于我的 BT 软件狗不会在/dev/dev 下创建任何设备节点、我不确定如何从命令行重置软件狗。 但我们可以强制 USB 控制器生成虚假的 BABBLE 事件、以触发驱动程序执行相同的处理例程。

因此、我在 UART 控制台中运行'devmem2 0x4740182c w 4'以触发 BABBLE 条件并重新枚举、但无法重现故障。 请尝试是否可以在设置中使用'evmem2 0x4740182c w 4'来触发故障？

Chris、

[引用 user="Chris Yorkey"[381.600196] musb-hdrc musb-hddrc.1：babble[/quot]

日志中的这一行表示发生了 BABBLE 情况。

您能否与客户核实、如果每次枚举失败、此 BABBLE 条件始终会发生？ 或者、有时日志中没有此类 BABBLE 条件、但枚举仍然失败？ 我想查看 BABBLE 条件是否与枚举故障相关。

由于测试中生成了大量内核日志、因此在检查 BABBLE 消息时必须多加注意。

箱、

来自客户：
----
我们相信(根据我们与 Microchip 的对话和我自己的经验)，我们无法在 USB2514上重现此错误，因为它是一个多 TT 设备。 USB2412/2422是单个 TT 器件、我们认为它们的问题来自此特定案例。 驾驶员可能无法很好地处理某些单个 TT 集线器…

我个人多次测试 USB2514 (超过100次)，无法重新创建错误。 因此、我建议使用入门套件进行测试(USB2422的评估板即将停产)

昨天我能够测试的另一件事是，我可以在没有针对 Gluegiga 软件狗的“特殊”软件复位调用的情况下重现错误...我只需在 USB 集线器上连接一个 BT 软件狗， 然后、我使用终端 SW 打开 ttyACM 端口(如果我调用正确、则为 minicom.py)。 然后我断开(物理)转换器并重新将其插入。
我重复这些步骤8-10次、使其崩溃。
----
谢谢、
Chris

箱、

此外：
----
为了让您知道、我有时会在重置 BT 器件时看到 BABBLE 中断、但不一定在发生错误时看到。
在我提供的内核日志中、当 BT 软件狗具有地址4时、会发生 BABBLE 中断、但在该 BABBLE 中断后、我确实复位了5次了软件狗、并成功枚举了 BT 设备、直至器件#9
基本上，每次发送软件复位时，您都会看到“USB 2-1.1：USB 断开连接，设备号 x”，因为它是测试期间唯一连接到集线器的设备。
只有在我用设备编号9重置 BT 软件狗后，才会发生错误。
----
再次感谢您、
Chris

Chris、

感谢您提供信息。 此问题似乎与 BABBLE 条件无关。

您之前的帖子中的"入门套件"是什么？ 不是 AM335x 入门套件 EVM、对吧？ 我是否仍然需要 SMSC2412集线器来重现此问题？

老实说、如果问题仅与单个 TT 中心有关、这不是一个微不足道的调查、还需要 USB 硬件专家参与进来、根本原因不会很快被发现。 请为您的客户设定适当的期望。

箱、

首先、非常感谢您迄今提供的帮助。  如果没有你的指导、就不能让这变得更远了。  

其次是 AM335x 入门套件。  这是上面的一个图形。

最后、我完全同意您的意见。  我相信他们已经在客户现场工作了一段时间、因此这并不重要。

让我设定适当的期望并了解更多信息。

再次感谢您、
Chris

箱、

更进一步...

在查看 AM335x 原理图后，USB2412集线器也位于此主板上，但(与应用程序相比，它只是在保留方向上布线。)

USB2412在下游端连接到 AM335x 的 USB0端口。  我相信您可以通过将 Starterkit ( 我们称之为 A)的 USB0端口设置为全速设备(而不是高速设备)来重现此问题。  在 USB2412 (micro-AB 连接器)的上游端，您可以连接另一个 AM335x (入门套件； 我们称之为 B)作为高速主机。

在入门套件 A 上、您可以强制端口 USB0向下并向上移动。  下面是建议的测试设置图：

再次感谢、

Chris

Chris、

这听起来像是一个很好的计划。 我知道入门套件的 usb0端口上有一个集线器、但从未检查过它的原理图、它是 USB2412。
我将尝试找到一个入门套件、并告诉您我的测试是如何进行的。

箱、

太棒了。 谢谢你。

此外、还有一些进一步的输入：
----

您可能知道、我们的 SMSC/Microchip 人员也会对此问题进行调查。 他们正在查看问题的一面(集线器)。 我向他们发送一个包含内核构建和脚本的 BBB、以便他们可以进行调查。
我们在…星期五与他们进行了后续电话联系

在 TI 方面、我们希望确保主机状态机(和/或 USB 驱动程序堆栈)不是问题所在。 我使用不同的集线器和 AM335x 进行了许多测试、无法重现问题；但我也使用其他主机简要测试了 USB2422、无法重现问题。 因此、它似乎是2的组合(AM335x 和 usb2422+全速器件)。
我认为问题与 BT 软件狗仿真 ttyACM 端口无关。 我认为任何类型的全速器件与主机进行某些数据交换都可能会触发该问题。

如果您愿意、我有一个定制板几乎可以随时发货给您。 它具有从 eMMC 运行的 Debian /内核发行版、其中包含一些特定于硬件的功能。
如果您想在同一硬件上使用另一个内核/操作系统、我相信我也可以向您发送我们的 DTS 文件。 请告诉我您是否感兴趣，或者您是否更喜欢使用2个入门套件进行测试。

说到入门套件、我刚刚使用它和 USB2422开发板+ TI SDK 操作系统运行了一个测试。
我得到的误差是：
[1422.067286] USB 2-1.1：新的全速 USB 器件、编号17、使用 musb-hdrc
[1422.234494] CDC_ACM 2-1.1：1.0：ttyACM0：USB ACM 设备
[1425.039912] USB 2-1.1：USB 断开连接、器件编号17
[1425.797155] USB 2-1.1：使用 musb-hdrc 的新型全速 USB 器件编号18
[1425.942433] CDC_ACM 2-1.1：1.0：ttyACM0：USB ACM 设备
[1480.737784] USB 2-1.1：USB 断开连接、器件编号18
[1481.257145] USB 2-1.1：全新的全速 USB 器件、编号19、使用 musb-hdrc
[1481.403105] CDC_ACM 2-1.1：1.0：ttyACM0：USB ACM 设备
[1506.593871] USB 2-1.1：USB 断开连接、器件编号19
[1511.317268] USB USB2-port1：无法启用。 可能是 USB 电缆损坏了？
[1515.637234] USB USB2-port1：无法启用。 可能是 USB 电缆损坏了？
[1519.957234] USB USB2-port1：无法启用。 可能是 USB 电缆损坏了？
[1524.277233] USB USB2-port1：无法启用。 可能是 USB 电缆损坏了？
[1524.291675] USB 2-1：USB 断开连接、器件编号2
[1528.647315] USB USB2-port1：无法启用。 可能是 USB 电缆损坏了？
[1532.967234] USB USB2-port1：无法启用。 可能是 USB 电缆损坏了？
[1537.287358] USB USB2-port1：无法启用。 可能是 USB 电缆损坏了？
[1541.607233] USB USB2-port1：无法启用。 可能是 USB 电缆损坏了？
[1541.614053] USB USB2-port1：无法枚举 USB 设备

即使我拔下或重置集线器，我也无法将其变为现实… 电缆来自 Microchip 开发套件、因此我假设他们提供的电缆质量良好…
(我现在没有将 USB 分析器连接到我的设置，因为我必须与处理此问题的另一位开发人员共享该分析器…) 我明天会再试一次。

这不是使用“usbcore.autosuspend=-1””的，因为 SDK 映像中的内核具有自己的 bootargs，我无法从 uboot 覆盖它们(除非您可以提供一种简单的方法来实现它)。
fat 分区上没有 uEnv.txt 文件，因此我相信 u-boot 不会搜索它。
----

此致、
Chris

您好 Bin、

更新：

我刚刚意识到为什么内核构建上没有任何 USB 连接。  

USB 驱动程序是作为模块构建的，“内核发行版”名称随着我的自定义编译而改变。

现在我已经修复了这个问题、我得到了以下错误：  

[失败]无法启动启动 USB 小工具。

有关详细信息、请参阅'stemctl status gadget-init.service'。

[18.046703] random: crng init done．(随机：完成 crng 初始化。

[19.675040] 47401300.usb-phy 未找到使用虚拟稳压器的电源 VCC

[19.732171] usbcore：`-1；'对于参数`autosuspend'无效

[19.878638] 47401b00.usb-phy 电源 VCC 未找到、使用虚拟稳压器

[19.898900] usbcore：`-1；'对于参数`autosuspend'无效

[20.035938] usbcore：`-1；'对于参数`autosuspend'无效

[20.228335] usbcore：`-1；'对于参数`autosuspend'无效

[20.374201] ti-pruss 4a300000.pruss：创建 PRU 内核和其他子平台器件

[20.564216] IRQ：找不到/ocp/pruss_soc_bus@4a326000/prusss@4a300000/INTC@4a320000的 IRQ 域！

[20.704730] IRQ：找不到/ocp/pruss_soc_bus@4a326000/prusss@4a300000/INTC@4a320000的 IRQ 域！

[21.303128] remoteproc remoteproc1：4a334000.pru0可用

[21.348050] PRU-rproc 4a334000.pru0：PRU rproc 节点/ocp/pruss_soc_bus@4a326000/prusss@4a300000/PRU@4a334000已成功探测

[21.438958] remoteproc remoteproc 2：4a338000.pru1现已推出

[21.469973] PRU-rproc 4a33890.pru1：PRU rproc 节点/ocp/pruss_soc_bus@4a326000/prusss@4a300000/PRU@4a338000探测成功

今天稍后我将尝试对此进行故障排除。

现在有趣的部分是我们从 Microchip/SMSC 得到的回复；请参阅附件。

e2e.ti.com/.../USB_5F00_TT_5F00_SPLIT_5F00_Issue.docx

让我们知道您对此有何看法、您或您的团队可以找到一种良好的方法来实施该提议1)

最后、我们将实现一个临时挂钩来测试 clear_TT_buffer 命令。

此致

----

谢谢、

Chris

Chris、

[引用 user="Chris Yorkey"[19.732171] usbcore：`-1；'对于参数`autosuspend'无效

在'-1'之后似乎有分号(;)，则驱动程序无法识别该值。

[引用 user="Chris Yorkey"]让我们知道您对此有何看法，您或您的团队可以找到一种实施方案的好方法1)

MUSB 驱动程序中的集线器处理来自社区驱动程序、多年来从未接触过。 我可以看一下问题是否存在、我们可以在 MUSB 驱动程序中解决它。 但我到今年年底才有时间。

箱、

我们客户的最新动态：
----
我发现我可以在运行时向该文件写入-1：
“/sys/module/usbcore/parameters/autosuspend”，所以我稍后会尝试并报告...

关于 Microchip 对 Linux 驱动程序的评论、我们的问题与您完全相同： “MUSB 驱动程序中的集线器处理来自社区驱动程序，多年来从未被触及过”，但他们回答说，具有单个 TT 的集线器已不再很常见，并且可能该错误在 Linux 内核中从未修复过。 他们认为 Windows 驱动程序在这方面更加坚固…
我个人对该驱动程序的评论并不了解；只需转发他们的评论即可。

最后、如果您的团队能够快速查看 MUSB 实施情况以确认 SSplIT/Ccsplit 是否得到了正确处理、我们将不胜感激、因为这对我们(以及一个非常大的客户)来说是一个非常重要的问题。 …修补内核/时间范围、我们必须评估我们的选项、因为我们的客户无法接受年底的版本

正如我提到的，在我们的最后，我们将再次测试“自动暂停”，我们还将手动测试“CLEAR_TT_buffer”的发送。
----
如果您有任何短期意见、请告诉我、我知道其中一些意见需要时间。

谢谢、
Chris

Chris、

SSplIT/Ccsplit 传输由 MUSB 控制器本身处理、在 SW 中控制的每个 USB 传输的唯一内容是集线器地址、设备连接的集线器端口以及设备地址。 集线器地址占用寄存器中的7个位、寄存器的位8 (MSB)是单个 TT 或多 TT 的标志。 所有这些信息都从 Linux 内核中的 USB 内核驱动程序(通过模板数据结构)传递到 MUSB 驱动程序。 因此、在我看来、如果驱动程序在 USB 内核驱动程序中有一个缺陷来区分单个或多个 TT、它应该会影响其他 USB 控制器、而不仅仅是 MUSB 控制器。

我可能想到的一个潜在的软件错误是、当与连接的多个设备通信时、如果 MUSB 驱动程序无法在硬件端点重新编程正确的集线器信息。 我不记得您之前提到过，客户是否曾尝试在集线器上仅使用*one * BT 软件狗重现此问题？

目前、我正在执行一项高优先级任务、直到今年12月初、我才能够重现/调试此问题。

Chris、

在连接/断开50次以上之后、我无法重现 AM335x 入门套件的问题。
由于无法从物理上断开板载 USB2412集线器下行端口上的 USB 器件、因此我在测试中使用了以下序列。

在入门套件上、modprobe g_serial
2.在 AM335x GP EVM 上作为 USB 主机、cat /dev/ttyACM0
3.在入门套件上，modprobe -r g_serial

客户是否尝试在集线器上仅使用*一个* BT 软件狗复制此问题？

您好、Bin、

要在重现错误时跟进“多个设备已连接”的问题，它们在集线器上只连接了一个设备；BT 软件狗。

您在上面描述的过程也是他们的想法。  但是、由于您无法重现此设置的问题、他们希望确保：

•您是否以全速配置 AM335x GP EVM 上的 USB 接口？  由于 TT 交易中存在错误、因此需要执行此操作。

•此外、我看到您对 ttyACM 端口进行了 cat 操作、但没有数据交换。  我们认为、只有在事务(数据)中断时才会发生错误。

o 可能需要在“删除”g_serial 模块的同时从一端发送数据。  ？？？

在“驾驶员方面”，他们根据 Microchip 评论进行了许多测试/调查。  他们发现 MUSB 驱动程序没有完全实现对分离事务的支持；更具体地说是 clear_tt_buffer 请求。  

最近、他们开发了一个软件补丁、似乎解决了他们可以在工作台上创建的问题。  现在、他们将将此补丁部署到其客户站点、以查看它是否能解决他们所面临的全部问题。  他们还开始讨论 Linux－USB 邮件列表，以供评论/审查。

感谢您的支持。  当然，任何进一步的评论都受到欢迎。

此致、

Chris

Chris、

[引用 user="Chris Yorkey"]•您是否以全速配置 AM335x GP EVM 上的 USB 接口？

是的、我是这样做的。 我使用我先前在该主题中发布的补丁。

[引用 user="Chris Yorkey"]•此外，我看到您使用的是 ttyACM 端口，但没有数据交换。  我们认为只有在事务(数据)中断时才会发生错误。

我在客户测试中的理解只是打开端口、无论如何都会触发 USB RX 请求。 但是、当我有机会再次调试问题时、我将在测试中添加数据传输。

[引用 user="Chris Yorkey"]他们发现 MUSB 驱动程序没有完全实现对拆分事务的支持；更具体地说是 clear_t_buffer 请求。[/quot]

我理解这一要求、但我想查看测试中的故障、以便我能够了解软件可以获得的错误条件、以便我们可以实施修复。

Chris Yorkey 说：

他们还开始讨论了 Linux-USB 邮件列表，以供评论/审阅。

我在 Linux-USB 邮件列表中看到了此修补程序、我已经在讨论中了。

要评论并接受此补丁、理想情况下、我希望看到测试失败。

客户是否能够在任何 TI AM335x EVM 上重现此问题？ 或者他们只是在他们的电路板上进行了测试？

您好、Bin、

回答：

1-正常(USB 全速)

2-(port/clear_tt_Buffer)使用与 BlueGiga 软件狗、USB2412集线器和 AM335x 不同的设置、他们没有尝试很难重现此错误。 他们知道、通过手动将 clear_tt_buffer 请求发送到端点4 (Bulb_IN)、他们可以肯定地从该错误中恢复；这就是他们建议使用从器件到主机的数据的原因。
不过、该错误可能是上述硬件组合的唯一错误、而且似乎还取决于某些时序或累积。 但是、如前所述、他们可以使用 USB24121集线器评估板和2种不同的内核实现(Gitorious 的原始3.2)和 BeagleBone Repo、在特定的硬件平台以及 BeagleBone Black 上轻松重现此错误。
此外、Arago 编译必须在 TTY 端口的处理方式上具有不同的内容。 在测试的2个系统(Android 或 Debian)上，执行此“echo -en '\x00\x01\x09\x00\x00'>/dev/ttyACM0”将系统地重置 BT 软件狗。 但是，在 Arago 编译上，这不能很好地工作(他们看到使用 USB 监听器以不同的方式发送数据包)。 他们发现、他们的原生者必须改用这种方法：
echo -en '\x00\x01\x09\x00\x00'> reset_bled112.bin；dd if=reset_bled112.bin of=/dev/ttyACM0 bs=1
他们比较了内核树(BeagleBone repo 与 TI repo)、在 USB 驱动程序方面看起来几乎相同。
还有一个注释(不知道它是否发生任何变化)，它们在内核中内置了 CDC-ACM 驱动程序(而不是模块)。

3 -(重现错误)如上所述、他们最初认为这是其内核或硬件版本所独有的、但他们可以使用 BeagleBone Black、EVB-USB2422和 Bled112软件狗轻松复制这一版本、并使用 BeagleBone 社区提供的最新图像和内核。 我很确定如果他们使用处理器 SDK 中的内核、也会执行同样的操作；尽管我认为他们必须添加特定于 Debian 的配置。 在 TTY 通信(或字节的分段方式)方面，处理器 SDK 中的 Arago 版本存在一些不同，因此使用此操作系统很难重现问题。

也许他们可以要求 Microchip 为我们提供 USB2422开发板-因为我们都在这一步中？ ;-)
(半开玩笑/半严肃)

谢谢、
Chris