为什么某些硬件无法检测到某些 USB 大容量存储设备?

发布于 2024-09-16 19:51:54 字数 310 浏览 8 评论 0原文

我正在尝试使用复合 USB 框架修改大容量存储驱动程序,以允许嵌入式大容量存储设备在我的 Xbox 360 上可见。我已确认这不是一个简单的 VendorID/ProductID 块。

我想了解具体是什么阻止某些设备(例如 Xbox 360)查看某些大容量存储设备。尽管我的问题是针对 Xbox 的,但解释为什么设备无法识别某些类型的大容量存储的通用答案也是可以接受的。

我观察到,在我拥有的闪存设备中,无法工作的是那些仅定义了 2 个端点(批量输入、批量输出)的设备。而包含 3 个端点(批量输入、批量输出、中断输入)的所有大容量存储设备都可以工作。这是相关观察还是巧合?

I am trying to modify a mass storage driver using the composite usb framework to allow an embedded mass storage device to be visible on my Xbox 360. I have confirmed that this is not a simple VendorID/ProductID block.

I would like to understand what specifically prevents some devices, say the Xbox 360, from seeing certain mass storage devices. Although my question is specific to the Xbox, a generic answer that explains why a device cannot see certain types of mass storage, would also be acceptable.

I made the observation that out of the flash devices I own, the ones that do not work are those with only 2 Endpoints defined (Bulk IN, Bulk OUT). Whereas all mass storage devices containing 3 Endpoints (Bulk IN, Bulk OUT, Interrupt IN) have worked. Is this a relevant observation or coincidence?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

你如我软肋 2024-09-23 19:51:54

大容量存储设备无法在给定主机上工作的原因有两个。

最简单的原因是供应商和产品 ID 块。某些软件(例如 iTunes)会根据提供的供应商和产品 ID 阻止设备同步。这是一种非常基本的预防措施,很容易通过欺骗供应商/产品 ID 来绕过。

特别是对于 Xbox 360,原因是 Xbox 360 SCSI 实现和 USB 设备驱动程序实现的组合。 USB海量存储的规范包含一个称为命令块包装器的结构,该结构包含一个成员bCBWCBLength,它声明要执行的命令块的长度。根据规范,这可以合法地包含从 1 到 16 的值。

虽然命令块的长度可以合法地从 1 到 16,但 CDB 的传统长度是 6、10、12 或 16 字节 - 长度根据不同的情况而变化。命令。例如,TEST UNIT READY 命令为 6 字节,而 MODE SENSE 有 6 字节和 10 字节版本。

Xbox 360 碰巧发送某些命令,例如 TEST UNIT READY 作为 10 个字节而不是 6 个字节。对于具有较旧驱动程序(如 Palm Pre 和 Android)的 USB 设备,这可能会导致问题,因为驱动程序不知道如何处理这些大小奇怪的 CDB。

最终的问题是设备端驱动程序处理不当和主机端奇怪的 SCSI 实现的混合。除非您是 Microsoft,否则解决方法是修改您的大容量存储驱动程序以处理奇怪大小的 CBW 长度字段。

关于仅批量与批量中断端点的观察结果只是巧合,与问题、解决方案或中间的任何内容无关。

There are 2 reasons why a mass storage device might not work on a given host.

The simplest reason is the Vendor and Product ID block. Some software, like iTunes will prevent devices from syncing based on the Vendor and Product ID that is presented. This is a very rudimentary prevention and is easily bypassed by spoofing Vendor/Product ID.

For the Xbox 360 specifically, the reason is a combination of Xbox 360 SCSI implementation and USB device driver implementation. The specification for USB Mass Storage contains a structure called the Command Block Wrapper, this structure contains a member bCBWCBLength that declares the length of the command block to be executed. According to the spec, this can legally contain values from 1 to 16.

While the length of command blocks can legally be from 1 to 16, the traditional length of CDBs are 6, 10, 12, or 16 bytes - the length varies depending on the command. For instance the TEST UNIT READY command is 6 bytes while MODE SENSE has a 6 byte and a 10 byte version.

The Xbox 360 happens to send certain commands such as TEST UNIT READY as 10 bytes rather than 6. For USB Devices with older drivers (like the Palm Pre and Android), this can cause a problem because the driver does not know what to do with these oddly sized CDBs.

Ultimately the problem is a mixture of poor driver handling on the device side and odd SCSI implementation on the host side. Unless you are Microsoft, the fix is to modify your mass storage driver to handle the oddly sized CBW length field.

The observation regarding bulk-only vs bulk interrupt endpoints was only a coincidence and had nothing to do with the problem, solution or anything in-between.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文