Hi Remy,
I also have some fixes for ether.c. How should I send them for review? Through this mailing list or make 'git push' into private branch to u-boot-usb.git repo?
On 08/11/2010 02:40 PM, Stefano Babic wrote:
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.
- 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.
- 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);
- 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