[参考译文] TUSB9261：发送数据失败

您好、Ryan、

很抱歉跳进、但从我在日志中看到的内容来看、-i选项似乎设置不正确（选项看起来没有问题）-s。
用于的连字符似乎-i与用于的连字符不同-s。
您能否确保它们匹配并重试？

此致、
Yuya

尊敬的 Yuya：

“好的,我知道你喜欢我。“ 我做了这个改变,我至少得到了一些不同的结果,虽然仍然不是正确的: e2e.ti.com/.../Updated-log-capture.txt

我注意到的一件事是尝试发送这些命令之外,我注意到我无法从 SSD 发送文件,它给了我一个权限被拒绝的错误。 将驱动器重新格式化为 EXT4 是个好主意、看看是否可以解决该问题？ 如果您、我可以继续尝试一下。

谢谢、

Ryan

您好、Ryan、

似乎没有根据日志发送正确的命令。 您可以使用以下命令吗？

sg_raw -r 512 "Destination Directory (SSD directory)" a1 2a 25 52 00 00 00 00 00 81 00 00

另外、您是否可以在发送文件时尝试以下命令？

sg_raw -r 512 -i auth_device.bin "Destination Directory (SSD directory)" a1 2a 25 51 00 00 00 00 00 81 00 00

作为预防性检查、目标目录也可以指定绝对路径、那么您也可以尝试该选项吗？

此致、

Yuya

尊敬的 Yuya：

我也尝试了这些命令,我仍然看到“是一个目录“返回。 它似乎只是 ping 查看它是否存在、或者像您所说的那样返回错误：

e2e.ti.com/.../6_2D00_19-Test-Commands-Log.txt

您认为导致这些错误的原因是什么？ 与 SCSI 有关、或者可能是权限？

谢谢、

Ryan

您好、Ryan、

由于未正确指定设备文件、您似乎遇到了错误。 您当前指定的可能是设备挂载的目录。 我相信您应该指定原始器件文件。

请尝试使用'lsblk'命令查找它

lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0   120G  0 disk 
|-sda1        8:1    0 119.1G  0 part /media/XXXX

如果设备是这样装入的、请指定 “sda" 目录“目录并发送命令。
例如、当您发送 Identify device 命令时、成功会是这样的。
e2e.ti.com/.../COM8_5F00_202506_5F00_20_5F00_124833.log

此致、

Yuya

尊敬的 Yuya：

  Ryan 今天到场、将继续收看下一个星期一。

好极了

Brian

尊敬的 Yuya：

对不起,迟来的答复,我是出去星期五和星期一发热。

我像你说的一样寻找/sda 目录,并找到了作为/dev/sda1 列出的驱动器. 我尝试用它进行测试,我相信它似乎更符合命令的期望。 但是、我收到以下错误消息：“/dev/sda1：权限被拒绝“。 如果我不得不猜测、这意味着最初格式化的所有者/PC 是唯一可以发送此命令的 PC。

关于接下来要测试什么的任何建议？

谢谢、

Ryan

您好、Ryan、

我很高兴听到你感觉更好。 请继续好好照顾自己。

关于错误消息：
/dev/sda1: Permission denied
—这很好地表明了问题。 使用的命令似乎需要 root 权限、但在没有 root 权限的情况下执行、这很可能是系统拒绝访问的原因。

作为解决方案、请尝试sudo在您使用的命令的开头添加。

例如：

sudo sg_raw -r 512 /dev/sda a1 28 2d 00 00 00 00 00 00 ec 00 00

你能尝试一下,让我知道它是否有效吗?

此致、

Yuya

尊敬的 Yuya：

好电话、看起来像修复了它。 我能够成功发送命令、以下是测试环境中列出的三个命令的结果： e2e.ti.com/.../Sudo-Results.txt

从我所能说的与测试文件环境相比、我们看到“failure command“（失败命令）超时并返回一个错误的问题。 同时、一个成功的命令“sudo sg_raw -r 512 -i auth_device.bin /dev/sda1 A1 28 2d 51 00 00 00 00 00 81 00 00“返回正确的结果、而另一个命令看起来可能有不正确的响应。

请看一下、让我知道您的想法、我相信接下来的步骤将是获得协议分析器、并找出其他命令超时的原因。

谢谢、

Ryan

您好、Ryan、

我最终在完全相同的情况下. 我很高兴问题已得到解决。
我也同意下一步。 如果您可以使用协议分析器来找出原因、那会很好。

此致、

Yuya

尊敬的 Yuya：

我正在努力获得我需要的设置,即,分析仪本身和软件到我可以使用的计算机上,我会让你知道,一旦我有了它的设置,我看到什么.

谢谢、

Ryan

您好、Ryan、

几天过去了、你们到底进展如何？

此致、

Yuya

尊敬的 Yuya：

很抱歉等待。 在发送这些命令时、我在使用协议分析器来记录协议时、在获得所需的软件方面遇到了一些问题。 下载软件后、我应该能够获得一个录制文件与您共享。

谢谢、

Ryan

您好、Ryan、

我懂了。 我将等待您的更新。

此致、

Yuya

您好、Ryan、

您能分享一下这个状态吗？

此致、

Yuya

尊敬的 Yuya：

我很抱歉等待。 我的软件已获得批准、因此我安装了该软件、但是我们目前需要多个项目的分析仪。 我应该能够得到一个机会明天我相信捕获一个跟踪,这样我可以发送给你审查,我们可以看到是否有任何迹象表明这一超时正在发生。

谢谢、

Ryan

您好、Ryan、

我懂了。 我将等待您的报告。

此致、

Yuya

尊敬的 Yuya：

我得到了通过 TUSB9261 从 Linux PC 向 SSD 发送失败命令的迹线。 但是、观察跟踪似乎根本没有发出命令。 没有任何 USB3 SS 活动的迹象、只有在命令超时后 SSD 断开并重新连接、看起来像：

此命令是否可与其他 SSD 一起使用、但没有任何问题？ 或者、您在任何 SATA 到 M.2 连接中看到的问题是否存在？

谢谢、

Ryan

您好、Ryan、

抱歉、我不完全明白、所以我有一个问题。
该命令是不是从 SSD 发送的、还是从 TUSB9261 发送的？
我相信它大致如下图所示、但在查看 USB 分析仪时、您是否看到了信息 from① 或 ②？

>>此命令是否可以与其他 SSD 一起使用、但没有问题？  
我没有使用其他 SSD 测试它、因为我只有一个启用了命令的 SSD、我发送给您。

>>或者您在任何 SATA 到 M.2 连接中看到的问题是否存在？
我不确定这意味着什么。 您能解释一下吗？

此致、

Yuya

尊敬的 Yuya：

抱歉、我不完全理解、所以我有一个问题。
该命令是不是从 SSD 发送的、还是从 TUSB9261 发送的？
我相信它大致如下图所示、但在查看 USB 分析仪时、您看到的信息是 from① 还是 ②？

例如、当我在主机 PC 的命令提示符中键入命令时、Linux OS 会通过 TUSB9261 将命令发送到 SSD。 此命令是否旨在使 SSD 向 PC 发送命令？ 我认为该命令旨在由 PC 发送以读取数据或配置 SSD。

USB 分析仪位于 Linux PC 和 TUSB9261EVM 之间。 信号从 PC 发送、通过 USB 分析仪路由、以便在信号通过时读取信号、并记录数据以准确查看发送的内容、然后再返回 TUSB9261EVM。 在 TUSB9261 和 SSD 之间、我们没有任何能够监听的分析仪。

我不确定这是什么意思。 您能解释一下吗？

为了使用此 SSD 进行测试、因为它是一款 M.2 NVMe SSD、我们使用 SATA 转 M.2 SSD 机柜来将 TUSB9261 连接到 SDD、因为我们无法将 TUSB9261EVM 直接连接到 SSD。  

谢谢、

Ryan

您好、Ryan、

应该是、当我在主机 PC 的命令提示符中键入命令时、Linux OS 通过 TUSB9261 将命令发送到 SSD。 此命令是否旨在使 SSD 向 PC 发送命令？ 我认为该命令应该由 PC 发送以读取数据或配置 SSD。

如您所述、从 PC 发送命令以从 SSD 读取数据或更改 SSD 的设置。

我们将 USB 分析仪置于 Linux PC 和 TUSB9261EVM 之间。 信号从 PC 发送、通过 USB 分析仪路由、以便在信号通过时读取信号、并记录数据以准确查看发送的内容、然后再返回 TUSB9261EVM。 我们没有任何能够监听 TUSB9261 和 SSD 的分析仪。

感谢您的解释。 我现在了解了设置。

为了使用此 SSD 进行测试、因为它是 M.2 NVMe SSD、我们使用 SATA 转 M.2 SSD 机柜来将 TUSB9261 连接到 SDD、因为我们没有任何方法将 TUSB9261EVM 直接连接到 SSD。  [/报价]

我们还使用适配器将 SSD 转换为 SATA、以便将其连接到 TUSB9261、因此条件应该相同。

此致、

Yuya

尊敬的 Yuya：

好的、明白。 如果可能、我将继续尝试查看是否可以获得正确的布线、以查看主机 PC 是否正常通信。 我应该能够尝试已知良好的命令并查看这些命令也返回了什么。 理想情况下、我们将在 USB 线路上看到一些活动、这表明至少正确发送了命令、这样我们就可以在两者之间进行比较。

谢谢、

Ryan

您好、Ryan、

我认为这是一个好主意。 我期待着你们的努力。

此致、

Yuya

我们目前正在收集数据、我们将于 7 月 22 日准备好更新

您好、Ryan、

我被告知、将在第 22 次会议上有最新情况。 怎么回事？ 您能否提供状态更新？

此致、

Yuya

尊敬的 Yuya：

我的鸡巴在裤裆里跳动,不停地跳动。

我尝试通过比较好的命令与失败的命令来收集一些数据、下面是我迄今为止发现的：

使用已知良好的命令 sg_raw -r 512 /dev/sdX A1 28 2D 52 00 00 00 00 00 81 00 进行测试时、这是 分析仪看到的结果。 看起来、从我可以看出、命令以传输 0 在这里发送、传输 1 返回从 SSD 发送回的数据。 分析器中提供的数据与 Linux 操作系统中返回的数据相匹配、因此我认为这些数据是一致的。 看起来命令按预期工作。

使用失败的命令进行测试时： sg_raw -s 512–i set_auth.bin /dev/sdX A1 0A 25 00 00 00 00 00 00 81 00 00、这是分析仪看到的。 从这里,它看起来像传输 0 和 1 看起来很好,传输 1 从 set_auth.bin 文件发送数据到 SSD。 但是、在传输二时、似乎发生了超时、因为您可以注意到、该传输与下一个传输之间存在 20 秒的间隔、这在已知良好的命令上不存在。 之后、看起来 SSD 可能会暂时断开连接、这会提示 Linux 系统向 SSD 请求描述符和其他信息。 所以在我看来、这种命令可能会导致某种类型的中断。

我将进一步比较这两种情况、看看我是否可以注意到任何其他差异、或者是否有任何其他可能导致这种情况的迹象。

谢谢、

Ryan

您好、Ryan、

我懂了。 感谢您的持续调查、我期待您的调查结果。

从这里,它看起来像传输 0 和 1 看起来很好,传输 1 从 set_auth.bin 文件发送数据到 SSD。 [/报价]

假设 TUSB9261 正在正确转换 SG_RAW 命令并将其发送到 SSD、无论它是成功还是失败、这是正确的吗？

此致、

Yuya

尊敬的 Yuya：

假设 TUSB9261 正确转换了 SG_RAW 命令并将其发送到 SSD、无论该命令是否成功？

我认为情况很可能是这样。 信息似乎通过 TUSB9261 正确发送到 SSD。 在这 20 秒内、SSD 似乎正在冻结或尝试配置自己、因为我认为这是命令尝试执行的操作、在超时和重置之前。 根据我能说的、其他命令都可以正常工作、因此可能是这个特定的命令导致了问题。

我将尝试查看在这 20 秒的时间范围内是否有任何其他信息、可能是在 USB2 侧还是在 FS / LS。 现在、我看到的唯一主要区别是失败命令的超时时间。

谢谢、

Ryan

您好、Ryan、

信息似乎是通过 TUSB9261 正确发送到 SSD。

您是否对此假设有任何依据？ 例如、使用调试工具确认从 TUSB9261 发送到 SSD 的命令。

如果命令真正正确转换并到达 SSD、则表明 TUSB9261 没有问题。 但是、如果存在任何导致 SSD 故障的转换错误、则可能表明存在问题。 很抱歉详细、但我想找出问题。

此致、

Yuya

尊敬的 Yuya：

不用担心,最好是详细和准确的这一点,而不是只是猜测。 我不是最熟悉对这些协议跟踪进行解码和分析的人、但我认为、确保正确接收这些命令的最佳方法是查看跟踪并查找确认或 ACK 数据包、这基本上会告诉主机 PC 器件已成功接收到发送的信息。

如果我可以查看命令发送时间附近并找到此信息、那么这将告诉我们命令正在通过器件发送和接收。 我将在内部仔细检查、确认是否已发送命令、或者是否有更好的方法来确定 TUSB9261 是否阻止了该命令。

谢谢、

Ryan

您好、Ryan、

谢谢你。 我希望我们能取得良好的成果。 如果有任何更新或进展、敬请分享。

此致、

Yuya

您好、Ryan、

我有一个建议。 是否可以通过从控制台进行调试来检查命令详细信息和其他信息？ 你怎么看？

此致、

Yuya

尊敬的 Yuya：

我 认为它可以提供更多结果/证据、但我不完全熟悉如何使用控制台来调试此问题。 您对此有何想法？ 尝试不同的命令来查看某些命令是否导致了该问题？ 或者、除了“已完成“或“错误“之外、是否有办法返回更详细的信息？

谢谢、

Ryan

您好、Ryan、
这与 TUSB9261PvP 相关、我相信可以从引脚 5 和 6 获得调试信息。

信息应如下所示。

e2e.ti.com/.../2046.Debug.log

您能否在内部查看？

此致、

Yuya

尊敬的 Yuya：

我明白您现在的意思、我们确实有这种能力、是的。 我可以研究这是否会有所帮助、我知道我需要修改 EVM、以便组装此跳线并监控 UART TX/RX、因此我需要在后台执行该操作来监控这种情况、还需要尽可能从我们这边调整固件以启用这些调试消息。

尽管如此、这为我们提供的信息主要是关于正在建立的连接和所连接的 SATA/M.2 驱动器的规格。 我不确定它会提供更多有关命令本身的数据、但以后获取作为证据还是不错的。

谢谢、

Ryan

您好、Ryan、

我明白,明白。 如果可以捕获数据、最好这样做。

我认为、隔离问题最简单的方法是使用 SATA 分析仪。 您的公司是否有可用的产品？ 如果您对隔离问题有任何其他建议、如果您也可以尝试一下、我将不胜感激。

此致、

Yuya

尊敬的 Yuya：

好了、我会继续尝试将其添加到我们的 EVM 进行监测。 也许它会告诉我们当这些重置似乎发生时发生了什么情况。

我相信、找出问题的最简单方法是使用 SATA 分析仪。 您的公司是否有可用的产品？ 如果您对隔离问题有任何其他建议、如果您也可以尝试这些建议、我将不胜感激。

不幸的是,我们的团队没有 SATA 分析仪,我也不 相信我们会找到一个. 我会看看我们是否有任何其他方法来隔离问题。

谢谢、

Ryan

您好、Ryan、

了解一下、我将继续、尝试将该内容添加到我们的 EVM 上进行监控。 也许它会告诉我们当这些重置似乎发生时发生了什么情况。

我懂了。 首先、请继续执行上述步骤、感谢您的努力。 此外、如果您有任何好的建议、请予以实施。

此致、

Yuya

尊敬的 Yuya：

现在等待 EVM 从焊接作业恢复、我将在重新安装并测试 UART 功能后告诉您。

谢谢、

Ryan

您好、Ryan、

我们公司将于 8 月 9 日至 17 日关闭,因此在此期间我将无法回复。 如果您可以执行任何操作（包括获取调试信息）、能否在这段时间内试用一下？

此致、

Yuya

尊敬的 Yuya：

是的、我将努力完成此测试、并反馈当时我找到的结果。 很抱歉等待。

谢谢、

Ryan

尊敬的 Yuya：

我将 EVM 与 UART 调试引脚焊接在一起、并且一直在与我们的其他某个 EVM 配合使用、以便可以看到调试输出。

但是、在配置串行端口时、我遇到了一些问题、因此我尝试找出问题。 我看到 TUSB9261 提供了数据、因此毫无疑问、这只是一个配置问题。 我将继续处理此问题、并尝试在 2018 年 8 月的星期一上获得更新。

谢谢、

Ryan

您好、Ryan、

由于我们已于 2018 年 8 月 8 日通过、您能否提供最新进展情况？

此致、

Yuya

尊敬的 Yuya：

我在按预期运行设置时仍遇到问题、我已尝试刷写我正在使用的两个器件的软件来尝试完成这些设置、但我仍然看到问题。 我将研究 TUSB9261 的软件方面、看看是否有波特率设置错误、以及尝试不同的 COM 端口板。

我这边有个问题、只是为了确保我没有遗漏任何内容、您所在的组还使用了 115200 的波特率从电路板的调试中读取数据、对吗？

谢谢、

Ryan

您好、Ryan、

理解了、我们期待您的更新。

我有一个问题,只是为了确保我没有遗漏任何东西,你的团队还使用了 115200 的波特率从你的板调试,正确吗?

是的、我们使用的波特率为 115200。

此致、

Yuya

尊敬的 Yuya：

明白了、感谢确认。 我将尝试让这个工作,以便我们可以尽快获得更多的信息。

谢谢、

Ryan

您好、Ryan、

获得了、感谢您的确认。 我将尝试使此功能生效、以便我们尽快获得更多信息。

已经差不多一个星期了；我想知道在解决这个问题方面是否有任何进展。

我们有机会在我们这边使用一个总线分析仪、我想分享一下结果。

检查 SATA 协议后、发现如下：

• 第一个图像对应于成功执行的命令。

• 第二个图像对应于失败的命令。

从第一个图像来看、似乎已正确发送命令以及 512 字节数据。 相比之下、在第二个图像中、命令加 512 字节数据似乎没有正确传输。

根据这些观察结果、TUSB9261 可能未正确转换命令。 你对此有何看法？

此致、

Yuya

您好、

Ryan 将于明天下班。 他会有一个回应。 很抱歉耽误你的时间。

尊敬的 Yuya：

我真的很抱歉等待。 我一直在努力得到一个工作的设置, 并已经离开办公室的最后几天,因为健康的原因。

我不熟悉 SATA 协议跟踪、因此我不能说根据您提供的屏幕截图、我确切知道这里发生了什么。 但是、我确实看到使用失败的命令似乎没有传输数据。 失败命令可能会导致 TUSB9261 的固件停止、但我不确定。  

对于正在发送的命令、是否可以帮助我了解命令末尾的这些值用于通信/设置：“A1 0A 25 00 00 00 00 00 00 00 81 00 00 “。

“sg_raw -s 512–i auth_device.bin /dev/sdX A1 28 2d 51 00 00 00 00 81 00 00“

“sg_raw -s 512–i set_auth.bin /dev/sdX A1 0A 25 00 00 00 00 00 81 00 00 “

例如、对于上面的两条命令、主要区别在于要发送的文件以及相关的命令参数。 我的理解是、上述两条命令都发送了 512 位的.bin 文件、其中操作码 A1 用作直通操作码。 但是、这两条命令之间的 CDP 有哪些差异可能导致此问题？ 是否可以将第一个命令与 set_auth.bin 文件一起使用？

如果您有有关正在发送的命令的更多详细信息、或者我可以 研究这些 SG_RAW 命令使用的格式以及所使用的命令参数的含义、我将不胜感激。 我将继续努力使 TX/RX 设置也正常工作、我不确定为什么会令人头疼。

谢谢、

Ryan

您好、Ryan、

sg_raw -s 512 –i set_auth.bin /dev/sdX a1 0a 25 00 00 00 00 00 00 81 00 00

旨在启用 SSD 上的一项功能。 set_auth.bin 文件指定了启用此函数的详细信息。 因此、即使您使用此命令发送 auth_device.bin、也不太可能正常工作。 即使是、详细信息也会有所不同、因此必须使用 set_auth.bin。

另一方面、该命令：

sg_raw -s 512 –i auth_device.bin /dev/sdX a1 28 2d 51 00 00 00 00 00 81 00 00

将在该功能启用后发送。 该函数返回 512 字节的数据、反映了该函数的当前状态、如 auth_device.bin 中指定。 如果尚未启用该功能、它将返回 512 字节的看似随机数据。

有关这些命令的更多详细信息、搜索 SG3_utils 应提供各种有用的参考。

此致、

Yuya