[U-Boot] usb cdc mode flow

[Marcel]

Hi,

Is there someone on the list who has a USB trace of a working CDC 
implementation ?
What I want to know is what happens after all descriptors are received by the 
host. 
The last descriptor I receive is a string descriptor saying "Ethernet data".

I'm busy implementing the USB device controller for the SAM9G45 and got quite 
far I think. It is recognised by the host as a cdc device but it doesn't work 
yet. I also see no errors so far, so according to the host it should be a 
working device I guess. I know that doesn't mean all that much , but it should 
mean that after it switched the IN and OUT endpoints that ep0 and ep3 are 
working well. I just guess ep1 and ep2 are not working correctly somehow.

I do notice when I call lsusb that it responds very slow and I do see on my 
USB analyzer that my device responds with NYET after it receives some OUT 
data.

What happens is that the host sends 90 bytes OUT data. The next thing is that 
my device sends is NYET. This first packet from the host contains the eth_addr 
(0a:fa:63:8b:e8:0a) if that means anything.
Than my device sends 8 byte IN data over the status end point (ep3) :
A1 00 01 00 01 00 00 00
Than the device sends 16 bytes over the status end point :
A1 2A 00 00 01 00 08 00 00 00 64 19 00 00 64 19
Than the host send another 78 bytes of OUT data which also get responded by 
NYET (it also contains the eth_addr).

After this, I see the u-boot prompt.

The device sees that OUT data arrived, but nothing seems to happen with it. 
This is basically what I'm currently trying to find out. 

I wonder where things get stuck in my communication. Since I see no real error 
appear and I even wonder if the driver on my host PC may be the issue. I tried 
a machine with an older kernel and the response is a little bit different but 
also doesn't work (and stops at the same point) so I guess that's not the 
issue.

I think I can clearly state that endpoint 0 and 3 are working correctly. 

I have taken the atmel_usba_udc driver from linux, but I changed  it to 
disable DMA. I'm not sure if that's a smart thing to do but I figured if DMA is 
disabled, the driver gets a whole lot simpler to implement and thus smaller. 
Regarding speed I think there's hardly any real need for high speed as well in 
u-boot but I may be wrong here.
As far as I analyzed the Linux driver (I ported back from kernel 2.6.33) it 
seems to have been programmed with both DMA and non-DMA transfers in mind but 
I think non-DMA actually doesn't work at all because it contains no code to 
switch of DMA I think.

I can post analyzer results and some outputs from u-boot itself if anyone 
thinks it is helpful. I do however think that I' already helped with a working 
trace so that I know what should happen. 

Anyway, if someone has a tip how to figure out this issue, please let me know.

Best regards,
Marcel