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.
Is there any way to get the ROM code for the USB booting option to run with Windows 10 current version (1909)? It seems like the ROM code is waiting for Windows to recognize it as an RNDIS device, but the ROM code is not announcing itself in a Windows-recognized way.
I've tried several approaches using a Beaglebone Black. The board is working correctly (tested with a SD Card) and the ROM always sends its USB descriptor.
With the current version of Uniflash (6.1.0), the command line detect-devices command does not detect the AM3358. Is Uniflash supposed to work with USB?
I've tried modifying the BBBlfs project (https://github.com/ungureanuvladvictor/BBBlfs) which works correctly with a Linux host. With Windows 10 I can see it sending a bulk transfer, but the AM3358 never acknowledges the transfer.
Is there documentation about the ROM steps required to initiate RNDIS, that might allow a manual workaround with a series of USB commands?
Hi Greg,
The AM3358 ROM USB peripheral boot mode was originally validated with Linux, Windows XP and Windows 7, we didn't officially test it with Windows 10. But we received a few reports that the ROM USB peripheral boot mode has issues with different versions of Windows 10, which seems to be related to multiple changes in the USB RNDIS host driver on Windows 10, which we have no control over it unfortunately.
Does any documentation exist about the sequence of events the ROM code requires before accepting USB data transfers. What has to happen before the SPL can be loaded?
Hi Greg,
There are many details related to USB, which is just the nature of the USB interface.
But if you are able to do ROM USB peripheral boot with Linux host, but boot failed only when swapped the host to Windows 10, I don't think you have setup issue on AM335x. Very likely it is due to USB RNDIS host driver on Windows 10.
Have you tried to use a USB protocol analyzer to capture the USB bus traffic to see where the communication failed?
Yes, I have captured the traffic. But without documentation of the ROM handshaking steps, I do not know what to do next. I understand that there are many details, and I want documentation so that I can review the traffic and understand where the problem is. If TI has failed to document the ROM code and has nothing available for customers, then Is there a version of the RNDIS specification that the AM335x confirms to?
Hi Greg,
We don't have a public document for ROM RNDIS boot handshake. The function on AM335x was validated with Windows 7, so it is compliant with whatever the RNDIS Spec implemented in Windows 7 RNDIS host driver.
In the USB traffic trace you captured, is that the USB standard enumeration passed but failed in the RNDIS protocol enumeration? If that is the case, I am not sure what you can do to solve this, you cannot modify either the AM335x ROM or the Windows 10 RNDIS driver, so the RNDIS handshake cannot be changed. Did you have a plan to solve the issue if you had the detail of the RNDIS handshake in this setup?
Yes, I do have a plan. The Libusb library and WinUSB driver that I'm using can issue commands directly over the USB bus. If I knew the detail, I would issue the commands necessary for the ROM to begin transfers, without needing Windows RNDIS protocol.
Is this a general problem with the entire Sitara family, that the USB boot option was developed with obsolete versions of Windows and no support documentation is available?
Hi Greg,
This does sound like a plan if you want to develop a host driver to replace the host RNDIS driver. Unfortunately we don't have such AM335x ROM document to support this development.
Have you concidered to use Linux host instead if your environment allows? I would think deploying a Linux host takes less effort than implementing a Windows USB driver.
In Sitara family, only AM335x and AM437x devices have such issue with Windows 10. All other Sitara devices use DFU instead for USB peripheral boot mode.
Hi Greg,
I found the following link while searching on internet. I am wondering if the issue has anything to do with c:/Windows/inf/rndiscmp.inf on Windows 10. Is it possible to compare this file between Windows 7 and Windows 10 to see if it has any difference? I don't have access to any Windows 7 PC unfortunately.
Hi Bin,
What I need is an explanation of the AM3358 ROM behavior, not speculation about Windows. I don't know why you misdirecting my attention to Windows when what I am asking for is information about the AM3358 product.
I need to know what commands are required, after USB communication is established, before the AM3358 accepts RNDIS transfers.
Hi Greg,
It is not my intention to misdirect you, rather than trying to help you find a solution. This AM335x ROM function was validated with Windows 7 many years ago, and appears Windows 10 changed the way how it handles RNDIS devices which breaks the function.
As I mentioned we don't have a public documentation explaining ROM behaviors. To summaries my comments above, here is what I would recommend to do -
- determine if using a Linux host is a solution. If not, then
- find a Windows 7 PC which is known to work with AM335x ROM, compare its rndiscmp.inf with that in Windows 10 to see if this solves the issue which Windows 10 doesn't assign the RNDIS driver to AM335x ROM RNDIS device. If not, then
- attach AM335x ROM to Windows 7 PC and capture the USB bus traffic to understand how Windows 7 handles RNDIS devices, then implement a driver for Windows 10 to replicate the same RNDIS enumeration flow as with Windows 7.