RNDIS Question - USBConnect4.TXT [0/1]

Hi everyone,

I'm in the process of porting across the netchip 2890 usb RNDIS driver
to my Hitachi 64404 hardware. I'm at the point where the endpoint 0
setup appears to be working. I've installed the rndis driver and a
SEND_ENCAPSULATED_COMMAND message is sent to the device, at which point
nothing else happens. No further packets are received and nothing else
seems to happen. I've got no other hardware to test this on, so I'm not
sure what else is supposed to happen. Does anyone know what I should be
sending in response or what ishould be waiting for at this point? I've
attached some debug output from my serial port to indicate what's going
on. Any suggestions on where to go from here are appreciated.

Thanks,

Glenn.

brianp
Wed Sep 03 03:23:54 CDT 2003

Hi Glenn,

I have just completed the RNDIS port for PXA255 processor and have
some logs about the USB data transfer. As you can see in the excerpt
of the log below which includes the first SEND_ENCAPSULATED_COMMAND of
the transaction, the
RNDISMINI layer gets called to process the message. The next thing
that comes down the wire is another setup packet requesting
GET_ENCAPSULATED_RESPONSE.

I hope this helps.
Brian Price
Applied Controls

4294792783: ProcessEP0Setup: UDCCS0=C1
4294792784: bmRequest: 80 bRequest: 06 wValue: 0100 wIndex: 0000
wLength: 0012
4294792785: USBD:: EP0: Get Descriptor for: [DEVICE]
4294792785: USBD:: EP0: Preparing to send [18] bytes.
4294792786: USBD:: EP0: EP0Send() [18] bytes pending.
4294792788: EP0_ISR: State=ECPS_DataTransmit UDCCS0 = 0
4294792789: USBD:: EP0: EP0Send() [2] bytes pending.
4294792789: USBD:: EP0: Short packet..
4294792791: EP0_ISR: State=ECPS_WaitForOutStatus UDCCS0 = 0
4294792791: IN Data sent out : UDDC0=0
4294792792: EP0_ISR: State=ECPS_WaitForOutStatus UDCCS0 = 1
4294792794: EP0_ISR: State=ECPS_WaitForSetup UDCCS0 = C1
4294792795: ProcessEP0Setup: UDCCS0=C1
4294792795: bmRequest: 80 bRequest: 06 wValue: 0200 wIndex: 0000
wLength: 0009
4294792796: USBD:: EP0: Get Descriptor for: [CONFIGURATION]
4294792796: USBD:: EP0: Preparing to send [9] bytes.
4294792797: USBD:: EP0: EP0Send() [9] bytes pending.
4294792798: USBD:: EP0: Short packet..
4294792800: EP0_ISR: State=ECPS_WaitForOutStatus UDCCS0 = 0
4294792803: EP0_ISR: State=ECPS_WaitForSetup UDCCS0 = C1
4294792804: ProcessEP0Setup: UDCCS0=C1
4294792804: bmRequest: 80 bRequest: 06 wValue: 0200 wIndex: 0000
wLength: 003e
4294792805: USBD:: EP0: Get Descriptor for: [CONFIGURATION]
4294792805: USBD:: EP0: Preparing to send [62] bytes.
4294792806: USBD:: EP0: EP0Send() [62] bytes pending.
4294792807: EP0_ISR: State=ECPS_DataTransmit UDCCS0 = 0
4294792808: USBD:: EP0: EP0Send() [46] bytes pending.
4294792810: EP0_ISR: State=ECPS_DataTransmit UDCCS0 = 0
4294792811: USBD:: EP0: EP0Send() [30] bytes pending.
4294792812: EP0_ISR: State=ECPS_DataTransmit UDCCS0 = 0
4294792812: USBD:: EP0: EP0Send() [14] bytes pending.
4294792813: USBD:: EP0: Short packet..
4294792815: EP0_ISR: State=ECPS_WaitForOutStatus UDCCS0 = 0
4294792819: EP0_ISR: State=ECPS_WaitForSetup UDCCS0 = C1
4294792819: ProcessEP0Setup: UDCCS0=C1
4294792820: bmRequest: 00 bRequest: 09 wValue: 0001 wIndex: 0000
wLength: 0000
4294792821: USBD:: EP0: Set configuration: [1]
4294792883: EP0_ISR: State=ECPS_WaitForInStatus UDCCS0 = C1
4294792884: ProcessEP0Setup: UDCCS0=C1
4294792884: bmRequest: 21 bRequest: 00 wValue: 0000 wIndex: 0000
wLength: 0018
4294792885: USBD:: EP0: SEND_ENCAPSULATED_COMMAND.
4294792885: EP0_ISR: State=ECPS_DataReceive UDCCS0 = 41
4294792886: EP0_ISR: State=ECPS_DataReceive UDCCS0 = 0
4294792887: USBD:: Completely received one RNDIS message.
4294792887: RNDISMINI:: Host Max Rx = [16384] bytes.
4294792889: USBD:: PDD_Get():: RequestID = [0x80000003]
4294792893: RNDISMINI:: PDD's Max Rx = [8192] bytes.
4294792896: USBD:: EP0: Send RNDIS message [0x45d00]
4294792897: EP0_ISR: State=ECPS_WaitForInStatus UDCCS0 = 0
4294792900: EP0_ISR: State=ECPS_WaitForSetup UDCCS0 = C1
4294792900: ProcessEP0Setup: UDCCS0=C1
4294792901: bmRequest: a1 bRequest: 01 wValue: 0000 wIndex: 0000
wLength: 0401
4294792902: USBD:: EP0: GET_ENCAPSULATED_RESPONSE.
4294792903: USBD:: EP0: Preparing to send [52] bytes.
4294792905: USBD:: EP0: EP0Send() [52] bytes pending.
4294792906: EP0_ISR: State=ECPS_DataTransmit UDCCS0 = 0
4294792908: USBD:: EP0: EP0Send() [36] bytes pending.
4294792909: EP0_ISR: State=ECPS_DataTransmit UDCCS0 = 0
4294792913: USBD:: EP0: EP0Send() [20] bytes pending.
4294792915: EP0_ISR: State=ECPS_DataTransmit UDCCS0 = 0
4294792917: USBD:: EP0: EP0Send() [4] bytes pending.
4294792918: USBD:: EP0: Short packet..
4294792920: EP0_ISR: State=ECPS_WaitForOutStatus UDCCS0 = 0
4294792921: IN Data sent out : UDDC0=0
4294792923: EP0_ISR: State=ECPS_WaitForOutStatus UDCCS0 = 1
4294792924: !!! STATUS = 81
4294792926: ProcessEP0Setup: UDCCS0=81
4294792927: bmRequest: 21 bRequest: 00 wValue: 0000 wIndex: 0000
wLength: 001c
4294792928: USBD:: EP0: SEND_ENCAPSULATED_COMMAND.
4294792930: EP0_ISR: State=ECPS_DataReceive UDCCS0 = 41
4294792931: EP0_ISR: State=ECPS_DataReceive UDCCS0 = 0
4294792933: USBD:: Completely received one RNDIS message.
4294792935: USBD:: EP0: Send RNDIS message [0x45d00]
4294792936: EP0_ISR: State=ECPS_WaitForInStatus UDCCS0 = 0
4294792939: EP0_ISR: State=ECPS_WaitForSetup UDCCS0 = C1
4294792940: ProcessEP0Setup: UDCCS0=C1
4294792940: bmRequest: a1 bRequest: 01 wValue: 0000 wIndex: 0000
wLength: 0401
4294792941: USBD:: EP0: GET_ENCAPSULATED_RESPONSE.
4294792942: USBD:: EP0: Preparing to send [188] bytes.
4294792942: USBD:: EP0: EP0Send() [188] bytes pending.
4294792943: EP0_ISR: State=ECPS_DataTransmit UDCCS0 = 0
4294792944: USBD:: EP0: EP0Send() [172] bytes pending.
4294792947: EP0_ISR: State=ECPS_DataTransmit UDCCS0 = 0
4294792948: USBD:: EP0: EP0Send() [156] bytes pending.
4294792949: EP0_ISR: State=ECPS_DataTransmit UDCCS0 = 0
4294792950: USBD:: EP0: EP0Send() [140] bytes pending.
4294792952: EP0_ISR: State=ECPS_DataTransmit UDCCS0 = 0
4294792953: USBD:: EP0: EP0Send() [124] bytes pending.
4294792954: EP0_ISR: State=ECPS_DataTransmit UDCCS0 = 0
4294792955: USBD:: EP0: EP0Send() [108] bytes pending.
4294792956: EP0_ISR: State=ECPS_DataTransmit UDCCS0 = 0
4294792957: USBD:: EP0: EP0Send() [92] bytes pending.
4294792958: EP0_ISR: State=ECPS_DataTransmit UDCCS0 = 0
4294792959: USBD:: EP0: EP0Send() [76] bytes pending.
4294792960: EP0_ISR: State=ECPS_DataTransmit UDCCS0 = 0
4294792961: USBD:: EP0: EP0Send() [60] bytes pending.
4294792962: EP0_ISR: State=ECPS_DataTransmit UDCCS0 = 0
4294792963: USBD:: EP0: EP0Send() [44] bytes pending.
4294792964: EP0_ISR: State=ECPS_DataTransmit UDCCS0 = 0
4294792965: USBD:: EP0: EP0Send() [28] bytes pending.
4294792966: EP0_ISR: State=ECPS_DataTransmit UDCCS0 = 0
4294792967: USBD:: EP0: EP0Send() [12] bytes pending.
4294792968: USBD:: EP0: Short packet..
4294792969: EP0_ISR: State=ECPS_WaitForOutStatus UDCCS0 = 0
4294792970: IN Data sent out : UDDC0=0
4294792971: EP0_ISR: State=ECPS_WaitForOutStatus UDCCS0 = 1
4294792973: EP0_ISR: State=ECPS_WaitForSetup UDCCS0 = C1


richmogd@hotmail.com (Glenn) wrote in message news:<MPG.19bed91f9a971dd7989685@news.microsoft.com>...
> Hi everyone,
>
> I'm in the process of porting across the netchip 2890 usb RNDIS driver
> to my Hitachi 64404 hardware. I'm at the point where the endpoint 0
> setup appears to be working. I've installed the rndis driver and a
> SEND_ENCAPSULATED_COMMAND message is sent to the device, at which point
> nothing else happens. No further packets are received and nothing else
> seems to happen. I've got no other hardware to test this on, so I'm not
> sure what else is supposed to happen. Does anyone know what I should be
> sending in response or what ishould be waiting for at this point? I've
> attached some debug output from my serial port to indicate what's going
> on. Any suggestions on where to go from here are appreciated.
>
> Thanks,
>
> Glenn.

brianp
Sun Sep 07 19:09:38 CDT 2003

Hi Glenn,

One other thing you need to verify is that the descriptors that your
CE box is reporting to the host has the correct Endpoint configuration
in it. If your hardware is different to the net2890 in its endpoint
configuration then the host will be trying to communicate with the
wrong ones.

Regards
Brian Price
Applied Controls

richmogd
Mon Sep 08 16:47:09 CDT 2003

Hi Brian,

My controller appears to be very similar to the 2890, to the extent that
all of the endpoints perform the same function. EP0 is control (8 byte
buffer), EP1 is receiving data packets (handling OUT tokens), EP2 is
sending data packets (handling IN tokens) and EP3 is sending interrupt
packets (IN tokens). At this point, i think that i'm almost there. I've
gotten past all of the rndis configuration. There are a range of RNDIS
packets received and processed at the beginning and the occasional RNDIS
packet is still send/received continually (i assume as some sort of
polling thing). The RNDIS packets begin to be received on EP1 after
initial configuration... is this the same for you? I've also hard-coded
my IP address as 192.168.10.10 on my adapter, as the net2890 appears to
pull this off an eeprom. Hopefully this is correct. At this point, it
appears that EP2 is constantly polled for data.

After all of this, the KITL is initialised and packets are sent over EP2
that are 136 bytes in length to the desktop (i assume this means it's
trying to establish the kitl connection with PB). Can you verify that
your device does roughly the same? It's a very general description, but
hopefully gives you an idea of what's going on. I'm just about to start
analysing these packets to work out what's happening.

Regards,

Glenn.

In article <83ae2378.0309071609.30b8dd7b@posting.google.com>,
brianp@appliedcs.com.au says...
> Hi Glenn,
>
> One other thing you need to verify is that the descriptors that your
> CE box is reporting to the host has the correct Endpoint configuration
> in it. If your hardware is different to the net2890 in its endpoint
> configuration then the host will be trying to communicate with the
> wrong ones.
>
> Regards
> Brian Price
> Applied Controls
>

brianp
Tue Sep 09 19:21:32 CDT 2003

Hi Glenn,

I can't help you with KITL, I have not tried it over USB.
But everything else I tried works fine - Remote Registry Editor,
Telnet, HTTP, FTP, anything that uses IP.

As for setting the IP address, the registry is probably better under
[HKEY_LOCAL_MACHINE\Comm\RndisMini1\Parms\TcpIp]
"EnableDHCP"=dword:0
"IpAddress"=multi_sz:"192.168.10.10"
"Subnetmask"=multi_sz:"255.255.255.0"
"UseZeroBroadcast"=dword:0
This way you can easily change it or even use DHCP (which will default
eventually to APIPA 169.255.x.x).

When sending data from the device ensure you clear the interrupt in
the device before loading the next packet. I had a problem with this
that caused only one packet to be sent because the next interrupt was
being generated before I got to clear it.

If KITL isn't responding then maybe it's in the Remote Connection
settings that the problem lies.

Sorry I can't be of any more help.

Regards
Brian Price
Applied Controls


richmogd@hotmail.com (Glenn) wrote in message news:<MPG.19c7c00923b24c0898968b@news.microsoft.com>...
> Hi Brian,
>
> My controller appears to be very similar to the 2890, to the extent that
> all of the endpoints perform the same function. EP0 is control (8 byte
> buffer), EP1 is receiving data packets (handling OUT tokens), EP2 is
> sending data packets (handling IN tokens) and EP3 is sending interrupt
> packets (IN tokens). At this point, i think that i'm almost there. I've
> gotten past all of the rndis configuration. There are a range of RNDIS
> packets received and processed at the beginning and the occasional RNDIS
> packet is still send/received continually (i assume as some sort of
> polling thing). The RNDIS packets begin to be received on EP1 after
> initial configuration... is this the same for you? I've also hard-coded
> my IP address as 192.168.10.10 on my adapter, as the net2890 appears to
> pull this off an eeprom. Hopefully this is correct. At this point, it
> appears that EP2 is constantly polled for data.
>
> After all of this, the KITL is initialised and packets are sent over EP2
> that are 136 bytes in length to the desktop (i assume this means it's
> trying to establish the kitl connection with PB). Can you verify that
> your device does roughly the same? It's a very general description, but
> hopefully gives you an idea of what's going on. I'm just about to start
> analysing these packets to work out what's happening.
>
> Regards,
>
> Glenn.
>
> In article <83ae2378.0309071609.30b8dd7b@posting.google.com>,
> brianp@appliedcs.com.au says...
> > Hi Glenn,
> >
> > One other thing you need to verify is that the descriptors that your
> > CE box is reporting to the host has the correct Endpoint configuration
> > in it. If your hardware is different to the net2890 in its endpoint
> > configuration then the host will be trying to communicate with the
> > wrong ones.
> >
> > Regards
> > Brian Price
> > Applied Controls
> >