[U-Boot] USB-CDC with musb controller

Hi Remy,
I would like to add CDC support to a davinci (DM365 Soc) board using the musb controller. As the actual driver (musb_udc) does have gadget support, I decided (even if I get some advises that it is a harder way) to port the actual linux driver, changing what I need to provide setup under u-boot.
I made changes to compile the musb as peripheral (as hcd must still be done), and I can compare the debug output with Linux, where everything is fine running on the same HW.
The usb_eth_init does not complete, and a ping request ends with "The remote end did not respond in time". However, a CDC gadget is recognized on both sides (target and PC). On the PC, I get the usb0 interface, and the cdc driver is loaded:
usb 3-2: New USB device found, idVendor=0525, idProduct=a4a1 usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 3-2: Product: Ethernet Gadget usb 3-2: Manufacturer: Linked-IP DVR365 usb 3-2: configuration #1 chosen from 1 choice usb0: register 'cdc_ether' at usb-0000:01:00.1-2, CDC Ethernet Device, 0a:fa:63:8b:e8:0a
There are some printf I do not understand, and that are not comparable with Linux.
I get a lot of "respond with data transfer before status phase", but as I see in code, it seems to be quite a normal case, and the setup is sent again (is this true ?).
In musb_gadget_queue() entry point (usb_ep_queue from ethernet gadget) there is a check for the parameters, and the ep should be the same as the ep in the request. This is not a case, and an error is reported (see later in error log).
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 ?
Thanks, Stefano
U-Boot 2010.06-00090-g3969a10-dirty (Aug 05 2010 - 12:11:22)
I2C: ready DRAM: 128 MiB Flash: 32 MiB In: serial Out: serial Err: serial Net: Read from EEPROM @ 0x50 failed Ethernet PHY: GENERIC @ 0x00 musb: DaVinci OTG revision 00140901 phy 21f0 control 00 musb: musb_hdrc: ConfigData=0x06 (UTMI-8, dyn FIFOs, SoftConn) musb: musb_hdrc: MHDRC RTL version 1.500 musb: musb_hdrc: setup fifo_mode 2 musb: musb_hdrc: 7/9 max ep, 2624/4096 memory musb: musb_hdrc: hw_ep 0shared, max 64 musb: musb_hdrc: hw_ep 1tx, max 512 musb: musb_hdrc: hw_ep 1rx, max 512 musb: musb_hdrc: hw_ep 2tx, max 512 musb: musb_hdrc: hw_ep 2rx, max 512 musb: musb_hdrc: hw_ep 3shared, max 256 musb: musb_hdrc: hw_ep 4shared, max 256 musb: PERIPHERAL mode, status 0, dev98 musb: USB Peripheral mode controller at 01c64000 using PIO, IRQ 0 using musb_hdrc, OUT ep1out IN ep1in STATUS ep2in MAC 8e:28:0f:fa:3c:39 HOST MAC 0a:fa:63:8b:e8:0a musb: <== devctl 98 musb: musb_start: peripheral active -> 1 EMAC, usb0 Hit any key to stop autoboot: 0
Note: setup seems ok, it is the same under Linux.
DVR365 # sete ethact usb0 DVR365 # ping 192.168.90.7 musb: IRQ 00050001 musb: ** IRQ peripheral usb0005 tx0001 rx0000 musb: <== Power=e0, DevCtl=99, int_usb=0x5 musb: BUS RESET as b_idle musb: csr 0011, count 8, myaddr 0, ep0stage idle musb: SetupEnd came in a wrong ep0stage idle musb: RX ep0 fifo 01c64420 count 8 buf 80f7fd5e musb: SETUP req80.06 v0100 i0000 l64 musb: musb_hdrc: peripheral reset irq lost! musb: handled 0, csr 0001, ep0stage in eth_setup:... respond with data transfer before status phase musb: queue to ep0 (OUT/RX), length=18 musb: TX ep0 fifo 01c64420 count 18 buf 810b51a3 musb: ep0 done request 80f82d98, 18/18 musb: IRQ 00000000 musb: IRQ 00000001 musb: ** IRQ peripheral usb0000 tx0001 rx0000 musb: csr 0000, count 0, myaddr 0, ep0stage out/status musb: IRQ 00040000 musb: ** IRQ peripheral usb0004 tx0000 rx0000 musb: <== Power=e0, DevCtl=99, int_usb=0x4 musb: BUS RESET as b_peripheral musb: IRQ 00040000 musb: ** IRQ peripheral usb0004 tx0000 rx0000 musb: <== Power=e0, DevCtl=99, int_usb=0x4 musb: BUS RESET as b_peripheral musb: IRQ 00040000 musb: ** IRQ peripheral usb0004 tx0000 rx0000 musb: <== Power=e0, DevCtl=99, int_usb=0x4 musb: BUS RESET as b_peripheral musb: IRQ 00040000 musb: ** IRQ peripheral usb0004 tx0000 rx0000 musb: <== Power=e0, DevCtl=99, int_usb=0x4 musb: BUS RESET as b_peripheral musb: IRQ 00000000 musb: IRQ 00000000
[snip]
musb: IRQ 00000000 musb: IRQ 00000000 musb: IRQ 00000000 musb: IRQ 00000000 musb: IRQ 00000001 musb: ** IRQ peripheral usb0000 tx0001 rx0000 musb: csr 0001, count 8, myaddr 0, ep0stage idle musb: RX ep0 fifo 01c64420 count 8 buf 80f7fd5e musb: SETUP req00.05 v002b i0000 l0 musb: handled 1, csr 0001, ep0stage in/status musb: IRQ 00000000 musb: IRQ 00000001 musb: ** IRQ peripheral usb0000 tx0001 rx0000 musb: csr 0000, count 0, myaddr 0, ep0stage in/status musb: IRQ 00000000 musb: IRQ 00000001 musb: ** IRQ peripheral usb0000 tx0001 rx0000 musb: csr 0001, count 8, myaddr 43, ep0stage idle musb: RX ep0 fifo 01c64420 count 8 buf 80f7fd5e musb: SETUP req80.06 v0100 i0000 l18 musb: handled 0, csr 0001, ep0stage in eth_setup:... respond with data transfer before status phase musb: queue to ep0 (OUT/RX), length=18 musb: TX ep0 fifo 01c64420 count 18 buf 810b51a3 musb: ep0 done request 80f82d98, 18/18 musb: IRQ 00000000 musb: IRQ 00000001 musb: ** IRQ peripheral usb0000 tx0001 rx0000 musb: csr 0001, count 8, myaddr 43, ep0stage out/status musb: RX ep0 fifo 01c64420 count 8 buf 80f7fd5e musb: SETUP req80.06 v0600 i0000 l10 musb: handled 0, csr 0001, ep0stage in eth_setup:... musb: stall (-95) musb: IRQ 00000001 musb: ** IRQ peripheral usb0000 tx0001 rx0000 musb: csr 0005, count 8, myaddr 43, ep0stage idle musb: RX ep0 fifo 01c64420 count 8 buf 80f7fd5e musb: SETUP req80.06 v0600 i0000 l10 musb: handled 0, csr 0001, ep0stage in eth_setup:... musb: stall (-95) musb: IRQ 00000001 musb: ** IRQ peripheral usb0000 tx0001 rx0000 musb: csr 0005, count 8, myaddr 43, ep0stage idle musb: RX ep0 fifo 01c64420 count 8 buf 80f7fd5e musb: SETUP req80.06 v0600 i0000 l10 musb: handled 0, csr 0001, ep0stage in eth_setup:... musb: stall (-95) musb: IRQ 00000001 musb: ** IRQ peripheral usb0000 tx0001 rx0000 musb: csr 0005, count 8, myaddr 43, ep0stage idle musb: RX ep0 fifo 01c64420 count 8 buf 80f7fd5e musb: SETUP req80.06 v0200 i0000 l9 musb: handled 0, csr 0001, ep0stage in eth_setup:... respond with data transfer before status phase musb: queue to ep0 (OUT/RX), length=9 musb: TX ep0 fifo 01c64420 count 9 buf 810b51a3 musb: ep0 done request 80f82d98, 9/9 musb: IRQ 00000001 musb: ** IRQ peripheral usb0000 tx0001 rx0000 musb: csr 0001, count 8, myaddr 43, ep0stage out/status musb: RX ep0 fifo 01c64420 count 8 buf 80f7fd5e musb: SETUP req80.06 v0200 i0000 l80 musb: handled 0, csr 0001, ep0stage in eth_setup:... respond with data transfer before status phase musb: queue to ep0 (OUT/RX), length=80 musb: TX ep0 fifo 01c64420 count 64 buf 810b51a3 musb: IRQ 00000001 musb: ** IRQ peripheral usb0000 tx0001 rx0000 musb: csr 0000, count 0, myaddr 43, ep0stage in musb: TX ep0 fifo 01c64420 count 16 buf 810b51e3 musb: ep0 done request 80f82d98, 80/80 musb: IRQ 00000001 musb: ** IRQ peripheral usb0000 tx0001 rx0000 musb: csr 0001, count 8, myaddr 43, ep0stage out/status musb: RX ep0 fifo 01c64420 count 8 buf 80f7fd5e musb: SETUP req80.06 v0300 i0000 l255 musb: handled 0, csr 0001, ep0stage in eth_setup:... respond with data transfer before status phase musb: queue to ep0 (OUT/RX), length=4 musb: TX ep0 fifo 01c64420 count 4 buf 810b51a3 musb: ep0 done request 80f82d98, 4/4 musb: IRQ 00000001 musb: ** IRQ peripheral usb0000 tx0001 rx0000 musb: csr 0001, count 8, myaddr 43, ep0stage out/status musb: RX ep0 fifo 01c64420 count 8 buf 80f7fd5e musb: SETUP req80.06 v0302 i0409 l255 musb: handled 0, csr 0001, ep0stage in eth_setup:... respond with data transfer before status phase musb: queue to ep0 (OUT/RX), length=32 musb: TX ep0 fifo 01c64420 count 32 buf 810b51a3 musb: ep0 done request 80f82d98, 32/32 musb: IRQ 00000001 musb: ** IRQ peripheral usb0000 tx0001 rx0000 musb: csr 0001, count 8, myaddr 43, ep0stage out/status musb: RX ep0 fifo 01c64420 count 8 buf 80f7fd5e musb: SETUP req80.06 v0301 i0409 l255 musb: handled 0, csr 0001, ep0stage in eth_setup:... respond with data transfer before status phase musb: queue to ep0 (OUT/RX), length=34 musb: TX ep0 fifo 01c64420 count 34 buf 810b51a3 musb: ep0 done request 80f82d98, 34/34 musb: IRQ 00000001 musb: ** IRQ peripheral usb0000 tx0001 rx0000 musb: csr 0001, count 8, myaddr 43, ep0stage out/status musb: RX ep0 fifo 01c64420 count 8 buf 80f7fd5e musb: SETUP req00.09 v0001 i0000 l0 musb: handled 0, csr 0001, ep0stage wait eth_setup:... musb: musb_hdrc periph: enabled ep2in for int IN, maxpacket 16 full speed config #1: 2 mA, Ethernet Gadget, using CDC Ethernet respond with data transfer before status phase musb: queue to ep0 (OUT/RX), length=0 musb: ep0 done request 80f82d98, 0/0 musb: IRQ 00000001 musb: ** IRQ peripheral usb0000 tx0001 rx0000 musb: csr 0001, count 8, myaddr 43, ep0stage in/status musb: RX ep0 fifo 01c64420 count 8 buf 80f7fd5e musb: SETUP req80.06 v0307 i0409 l255 musb: handled 0, csr 0001, ep0stage in eth_setup:... respond with data transfer before status phase musb: queue to ep0 (OUT/RX), length=26 musb: TX ep0 fifo 01c64420 count 26 buf 810b51a3 musb: ep0 done request 80f82d98, 26/26 musb: IRQ 00000000 musb: IRQ 00000001 musb: ** IRQ peripheral usb0000 tx0001 rx0000 musb: csr 0001, count 8, myaddr 43, ep0stage out/status musb: RX ep0 fifo 01c64420 count 8 buf 80f7fd5e musb: SETUP req80.06 v0305 i0409 l255 musb: handled 0, csr 0001, ep0stage in eth_setup:... respond with data transfer before status phase musb: queue to ep0 (OUT/RX), length=54 musb: TX ep0 fifo 01c64420 count 54 buf 810b51a3 musb: ep0 done request 80f82d98, 54/54 musb: IRQ 00000001 musb: ** IRQ peripheral usb0000 tx0001 rx0000 musb: csr 0001, count 8, myaddr 43, ep0stage out/status musb: RX ep0 fifo 01c64420 count 8 buf 80f7fd5e musb: SETUP req01.0b v0001 i0001 l0 musb: handled 0, csr 0001, ep0stage wait eth_setup:... musb: ep1in musb: ep1out musb: musb_hdrc periph: enabled ep1in for bulk IN, maxpacket 64 musb: musb_hdrc periph: enabled ep1out for bulk OUT, maxpacket 64 musb: ep2in musb: musb_hdrc periph: enabled ep2in for int IN, maxpacket 16 musb: Wrong ep in queue: 0 2 status buf queue --> -22
It seems that the parameters passed by eth_setup do not match. ep is always ep0, I missed where is coming the req->ep, as it is saved in the dev structure. Should they always be the same as checked by the musb driver ?
respond with data transfer before status phase musb: queue to ep0 (OUT/RX), length=0 musb: ep0 done request 80f82d98, 0/0 musb: IRQ 00000001 musb: ** IRQ peripheral usb0000 tx0001 rx0000 musb: csr 0001, count 8, myaddr 43, ep0stage in/status musb: RX ep0 fifo 01c64420 count 8 buf 80f7fd5e musb: SETUP req80.06 v0303 i0409 l255 musb: handled 0, csr 0001, ep0stage in eth_setup:... respond with data transfer before status phase musb: queue to ep0 (OUT/RX), length=26 musb: TX ep0 fifo 01c64420 count 26 buf 810b51a3 musb: ep0 done request 80f82d98, 26/26 musb: IRQ 00000000 musb: IRQ 00000001 musb: ** IRQ peripheral usb0000 tx0001 rx0000 musb: csr 0001, count 8, myaddr 43, ep0stage out/status musb: RX ep0 fifo 01c64420 count 8 buf 80f7fd5e musb: SETUP req80.06 v0304 i0409 l255 musb: handled 0, csr 0001, ep0stage in eth_setup:... respond with data transfer before status phase musb: queue to ep0 (OUT/RX), length=28 musb: TX ep0 fifo 01c64420 count 28 buf 810b51a3 musb: ep0 done request 80f82d98, 28/28 musb: IRQ 00000001 musb: ** IRQ peripheral usb0000 tx0001 rx0000 musb: csr 0000, count 0, myaddr 43, ep0stage out/status musb: IRQ 00000001 musb: ** IRQ peripheral usb0000 tx0001 rx0000 musb: csr 0000, count 0, myaddr 43, ep0stage idle musb: IRQ 00000000

Hi Stefano,
2010/8/5 Stefano Babic sbabic@denx.de:
Hi Remy,
I would like to add CDC support to a davinci (DM365 Soc) board using the musb controller. As the actual driver (musb_udc) does have gadget support, I decided (even if I get some advises that it is a harder way)
The USB gadget layer used for CDC is derived from Linux 2.6.27. It was ported such that the gadget drivers from Linux could be used with little modifications.
The usb_eth_init does not complete, and a ping request ends with "The remote end did not respond in time". However, a CDC gadget is recognized on both sides (target and PC). On the PC, I get the usb0 interface, and the cdc driver is loaded:
I get a lot of "respond with data transfer before status phase", but as I see in code, it seems to be quite a normal case, and the setup is sent again (is this true ?).
Indeed, this seems to be some debug logging that can be removed...
In musb_gadget_queue() entry point (usb_ep_queue from ethernet gadget) there is a check for the parameters, and the ep should be the same as the ep in the request. This is not a case, and an error is reported (see later in error log).
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...
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...
at91sam9261-ek> ping 10.0.0.1 Holding VBUS down: 4...3...2...1...Go! end bus reset end bus reset SETUP 80.06 v0100 i0000 l0040 eth_setup:... respond with data transfer before status phase ep0 20aa35e8 in/8 ep0 20aa35e8 in/8 end bus reset nuke ep0 setup complete --> -108, 16/18 SETUP 00.05 v0025 i0000 l0000 address 37 SETUP 80.06 v0100 i0000 l0012 eth_setup:... respond with data transfer before status phase ep0 20aa35e8 in/8 ep0 20aa35e8 in/8 ep0 20aa35e8 in/2 (done) ep0 out/status ACK SETUP 80.06 v0600 i0000 l000a eth_setup:... req 80.06 protocol STALL; stat -95 ep0 stalled SETUP 80.06 v0600 i0000 l000a eth_setup:... req 80.06 protocol STALL; stat -95 ep0 stalled SETUP 80.06 v0600 i0000 l000a eth_setup:... req 80.06 protocol STALL; stat -95 ep0 stalled SETUP 80.06 v0200 i0000 l0009 eth_setup:... respond with data transfer before status phase ep0 20aa35e8 in/8 ep0 20aa35e8 in/1 (done) ep0 out/status ACK SETUP 80.06 v0200 i0000 l0050 eth_setup:... respond with data transfer before status phase ep0 20aa35e8 in/8 ep0 20aa35e8 in/8 ep0 20aa35e8 in/8 ep0 20aa35e8 in/8 ep0 20aa35e8 in/8 ep0 20aa35e8 in/8 ep0 20aa35e8 in/8 ep0 20aa35e8 in/8 ep0 20aa35e8 in/8 ep0 20aa35e8 in/8 (done) ep0 out/status ACK SETUP 80.06 v0300 i0000 l00ff eth_setup:... respond with data transfer before status phase ep0 20aa35e8 in/4 (done) ep0 out/status ACK SETUP 80.06 v0302 i0409 l00ff eth_setup:... respond with data transfer before status phase ep0 20aa35e8 in/8 ep0 20aa35e8 in/8 ep0 20aa35e8 in/8 ep0 20aa35e8 in/8 ep0 20aa35e8 in/0 (done) ep0 out/status ACK SETUP 80.06 v0301 i0409 l00ff eth_setup:... respond with data transfer before status phase ep0 20aa35e8 in/8 ep0 20aa35e8 in/8 ep0 20aa35e8 in/8 ep0 20aa35e8 in/8 ep0 20aa35e8 in/8 ep0 20aa35e8 in/2 (done) ep0 out/status ACK SETUP 00.09 v0001 i0000 l0000 wait for config eth_setup:... udc: alloc_req: request[2] udc: alloc_req: request[3] full speed config #1: 2 mA, Ethernet Gadget, using CDC Ethernet respond with data transfer before status phase toggle config ep0 in/status SETUP 80.06 v0307 i0409 l00ff eth_setup:... respond with data transfer before status phase ep0 20aa35e8 in/8 ep0 20aa35e8 in/8 ep0 20aa35e8 in/8 ep0 20aa35e8 in/2 (done) ep0 out/status ACK SETUP 80.06 v0305 i0409 l00ff eth_setup:... respond with data transfer before status phase ep0 20aa35e8 in/8 ep0 20aa35e8 in/8 ep0 20aa35e8 in/8 ep0 20aa35e8 in/8 ep0 20aa35e8 in/8 ep0 20aa35e8 in/8 ep0 20aa35e8 in/6 (done) ep0 out/status ACK SETUP 01.0b v0001 i0001 l0000 eth_setup:... ep4 20aa361c in/8 (done) send SPEED_CHANGE --> 0 respond with data transfer before status phase ep0 in/status SETUP 80.06 v0303 i0409 l00ff eth_setup:... respond with data transfer before status phase ep0 20aa35e8 in/8 ep0 20aa35e8 in/8 ep0 20aa35e8 in/8 ep0 20aa35e8 in/2 (done) ep0 out/status ACK SETUP 80.06 v0304 i0409 l00ff eth_setup:... respond with data transfer before status phase ep0 20aa35e8 in/8 ep0 20aa35e8 in/8 ep0 20aa35e8 in/8 ep0 20aa35e8 in/4 (done) ep0 out/status ACK ep4 20aa361c in/16 (done) event 2a --> 0 USB network up! rx_submit Using usb0 device usb_eth_send:... ep1 20aa3650 in/42 (done) tx_complete, status: ok usb_eth_send: packet queued ep2 20aa3684 out/42 (done) rx_complete rx status 0 usb_eth_recv: packet received usb_eth_send:... ep1 20aa3650 in/42 (done) tx_complete, status: ok usb_eth_send: packet queued rx_submit ep2 20aa3684 out/54 (done) rx_complete rx status 0 usb_eth_recv: packet received rx_submit ep2 20aa3684 out/42 (done) rx_complete rx status 0 usb_eth_recv: packet received rx_submit nuke ep2 rx_complete rx status -108 host 10.0.0.1 is alive

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

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

Vitaly Kuzmichev wrote:
Hi Vitaly,
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?
My two cents. I would prefer to send patches always to the ML, even if they are not planned to go soon in the mainline. We can get a better visibility and a lot of people could review them. Personally, I do not traverse all branches and I would probably miss changes if they go into a private branch. Remy could then decide himself if he will pick-up the patches or not.
Stefano

Hi,
2010/8/11 Stefano Babic sbabic@denx.de:
Vitaly Kuzmichev wrote:
Hi Vitaly,
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?
My two cents. I would prefer to send patches always to the ML, even if they are not planned to go soon in the mainline. We can get a better visibility and a lot of people could review them. Personally, I do not traverse all branches and I would probably miss changes if they go into a private branch. Remy could then decide himself if he will pick-up the patches or not.
I agree, I would also prefer sending those patches to ML as regular patches. I will pick them up from there. Thanks!
Kind regards,
Remy

Dear Vitaly Kuzmichev,
In message 4C629C28.40300@mvista.com you wrote:
I also have some fixes for ether.c. How should I send them for review?
Please start by reading the docs, especially http://www.denx.de/wiki/U-Boot/Patches
Through this mailing list or make 'git push' into private branch to u-boot-usb.git repo?
Posting on the ML is mandatory. Patches that have not been posted for review on the ML are rejected without further checking.
Also, you should have hard tiems trying to push into the u-boot-usb.git repository. You are not the appointed custodian.
On 08/11/2010 02:40 PM, Stefano Babic wrote:
<<Full quote deleted>>
Finally: please stop top posting / full quoting. Make sure to read http://www.netmeister.org/news/learn2quote.html
Best regards,
Wolfgang Denk

Hi,
Of course, if you agree with my analyses, I will send patches to fix them.
Great!
- 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.
nice catch.
- 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);
OK.
- 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.
Sounds okay. Indeed the Atmel core calls tx_complete(). Calling handle_interrupts() here might indeed do the job...
Kind regards,
Remy
participants (4)
-
Remy Bohmer
-
Stefano Babic
-
Vitaly Kuzmichev
-
Wolfgang Denk