• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 645 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

OMAP35xx, OMAP36xx, DM37xx ROM Bootloader (RBL) don't fully comply to USB specification

Raul Benet
Prodigy 205 points
Other Parts Discussed in Thread: DM3730, OMAP3530

All, - to whom it may concern-

the USB stack in the ROM Bootloader of the OMAP35xx, OMAP36xx and DM37xx is not fully compliant to the USB specification.

The ROMBootloader, in its device descriptor reports "bcdUSB = 0x0210", as described in their respectives TRM  (for the DM3730 TRM, this would be in section 26.4.5.3.1 USB Driver Descriptors, Table 26-15); and as measured on a real DM3730 device.

According to the USB specification, USB 2.0 LPM ECN, section 3:

The value of the bcdUSB field in the standard USB 2.0 Device Descriptor is used to indicate that the device
supports the request to read the BOS Descriptor (i.e. GetDescriptor(BOS)). Devices that support the BOS
descriptor must have a bcdUSB value of 0201H or larger.

Also in USB specification, USB 3.0, section 9.2.6.6:

Devices with a value of at least 0210H in the bcdUSB field of their device descriptor shall support GetDescriptor (BOS Descriptor) requests.

So, the RBL, announcing itself as bcdUSB=0x210 shall support GetDescriptor(BOS Descriptor). But it doesn't and it just "returns" a STALL (which is the correct way of saying it doesnt support it).

Until recently, this went probably unnoticed. But, since Windows 8 (on USB3.0 ports, even if operating as USB2.0 speeds) and Windows 8.1 (all ports), the standard Windows USB controller stack will request the BOS. Because the RBL doesn't support, Windows fails to enumerate it with a code 43.

For more details on the topic, also covering other devices affected by this, see following blog entry by the Windows USB Core development team:

http://blogs.msdn.com/b/usbcoreblog/archive/2013/11/26/why-does-my-usb-device-work-on-windows-8-0-but-fail-on-windows-8-1-with-code-43.aspx

Ideally, Texas Instruments does fix their devices to either return the BOS or report bcdUSB=0x200 (as it is done by the OMAP5 devices). 

And at least, this gets documented in the errata document for all those devices.

Any acknowledgement of the issue from TI and information on the steps that wiill be taken are highly appreciated.

Best regards,

Raul Benet

  • 0
    TI__Guru 65405 points

    Hi Raul,

    Thanks for reporting this issue. The ROM Bootloader could not be changed but this issue probably will be added in the next version of omap3530 errata document. After booting the Kernel this issue is solved as hardcoded setting the bcdUSB to 0x200 in the USB gadget driver.

    BR

    Tsvetolin Shulev