[U-Boot] USB-CDC with musb controller

[Stefano Babic <sbabic@denx.de>]

Remy Bohmer wrote:
> Hi Stefano,
> 

Hi Remy,

> Indeed, this seems to be some debug logging that can be removed...

Ok, understood.

> We have tested it with the Atmel at91sam9261 core, and I have never
> used it with any other hardware.
> It is possible that you run into problems here that where not visible
> on the Atmel core...

yes, this is what I have seen...

> 
>> I report the whole log, enabling debug output on both musb driver and
>> ether.c. Do you have some hints to give me to go further ?
> 
> This is my log when I do a (successful) ping to the host when I run on
> a Atmel eval-kit.
> Maybe you can use it as reference? Maybe it helps...

Thanks a lot, it really helped me ;-).

At least, I can now identify what a real problem is and what is not..

I can now complete the setup phase and the interface is working.
I have found a couple of problems in ether.c that I will report to you.
Of course, if you agree with my analyses, I will send patches to fix them.

1. The status_req buffer is static allocated as u8. However, in
eth_status_complete is referenced with a 32 bit pointer:

 __le32  *data = req->buf

In most case the buffer is not 32-bit aligned and causes an exception.

2. In eth_bind a wrong ep is allocated.
#if defined(DEV_CONFIG_CDC)
        if (dev->status_ep) {
                dev->stat_req = usb_ep_alloc_request(gadget->ep0,
GFP_KERNEL);

This should be:

dev->stat_req = usb_ep_alloc_request(dev->status_ep, GFP_KERNEL);

3. Not sure about the handling in usb_eth_send. I do not know if the fix
I propone works only for the musb driver or could be general and it was
to me not clear as the packet_sent variable is managed:

1834         while(!packet_sent)
1835         {
1836                 packet_sent=0;
1837         }

It seems there is no possibility to change packet_sent if we run in the
loop....

I managed to call handle_interrupts() inside the loop to get it working.
I can only assume that on your Atmel Core, tx_complete is called
directly after running into usb_ep_queue, and then you have not this issue.
But for most drivers, it should be required to call the interrupt
routine (or something like that, but we have already
handle_interrupts()) to manage all events.

Best regards,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================