It seems sometimes reading the readme could save from heavy debugging and writing an email. But nevertheless, I filed a PR: https://github.com/apache/incubator-nuttx/pull/1456 RNDIS is working now, I have TCP/IP Telnet access through USB on Kinetis K28.
Regards, Johannes > -----Original Message----- > From: Gregory Nutt [mailto:spudan...@gmail.com] > Sent: Tuesday, July 21, 2020 3:53 PM > To: dev@nuttx.apache.org > Subject: [!!Mass Mail]Re: RNDIS Kinetis > > > > Now I'm facing a problem with the RNDIS driver under Kinetis USB device > (K28-Freedom), it is not working. > > If I'm not wrong I think I tracked it down: The Kinetis USB device driver > doesn't support accompanying data in an nonstandard OUT setup packet. > > Has someone already fixed this and can file a PR? If not I will try to fix > > it. > > That is a problem with several USB device drivers. There is more > description in the top-level TODO list: > > 1693 Title: EP0 OUT CLASS DATA > 1694 Description: There is no mechanism in place to handle EP0 OUT > data transfers. > 1695 There are two aspects to this problem, neither are > easy to fix > 1696 (only because of the number of drivers that would be > impacted): > 1697 > 1698 1. The class drivers only send EP0 write requests > and these are > 1699 only queued on EP0 IN by this drivers. There is > never a read > 1700 request queued on EP0 OUT. > 1701 2. But EP0 OUT data could be buffered in a buffer in > the driver > 1702 data structure. However, there is no method > currently > 1703 defined in the USB device interface to obtain the > EP0 data. > 1704 > 1705 Updates: (1) The USB device-to-class interface as > been extended so > 1706 that EP0 OUT data can accompany the SETUP request > sent to the > 1707 class drivers. (2) The logic in the STM32 F4 OTG FS > device driver > 1708 has been extended to provide this data. Updates are > still needed > 1709 to other drivers. > 1710 > 1711 Here is an overview of the required changes: > 1712 New two buffers in driver structure: > 1713 > 1714 1. The existing EP0 setup request buffer (ctrlreq, 8 > bytes) > 1715 2. A new EP0 data buffer to driver state structure > (ep0data, > 1716 max packetsize) > 1717 > 1718 Add a new state: > 1719 > 1720 3. Waiting for EP0 setup OUT data (EP0STATE_SETUP_OUT) > 1721 > 1722 General logic flow: > 1723 > 1724 1. When an EP0 SETUP packet is received: > 1725 - Read the request into EP0 setup request buffer > (ctrlreq, > 1726 8 bytes) > 1727 - If this is an OUT request with data length, set > the EP0 > 1728 state to EP0STATE_SETUP_OUT and wait to receive > data on > 1729 EP0. > 1730 - Otherwise, the SETUP request may be processed > now (or, > 1731 in the case of the F4 driver, at the conclusion > of the > 1732 SETUP phase). > 1733 2. When EP0 the EP0 OUT DATA packet is received: > 1734 - Verify state is EP0STATE_SETUP_OUT > 1735 - Read the request into the EP0 data buffer > (ep0data, max > 1736 packet size) > 1737 - Now process the previously buffered SETUP > request along > 1738 with the OUT data. > 1739 3. When the setup packet is dispatched to the class > driver, > 1740 the OUT data must be passed as the final > parameter in the > 1741 call. > 1742 > 1743 Update 2013-9-2: The new USB device-side driver for > the SAMA5D3 > 1744 correctly supports OUT SETUP data following the same > design as > 1745 per above. > 1746 > 1747 Update 2013-11-7: David Sidrane has fixed with issue > with the > 1748 STM32 F1 USB device driver. Still a few more to go > before this > 1749 can be closed out. > 1750 > 1751 Status: Open > 1752 Priority: High for class drivers that need EP0 data. For > example, the > 1753 CDC/ACM serial driver might need the line coding > data (that > 1754 data is not used currently, but it might be).
