* [U-Boot] USB-CDC with musb controller
@ 2010-08-05 11:44 Stefano Babic
2010-08-09 17:12 ` Remy Bohmer
0 siblings, 1 reply; 8+ messages in thread
From: Stefano Babic @ 2010-08-05 11:44 UTC (permalink / raw)
To: u-boot
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
--
=====================================================================
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
=====================================================================
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] USB-CDC with musb controller
2010-08-05 11:44 [U-Boot] USB-CDC with musb controller Stefano Babic
@ 2010-08-09 17:12 ` Remy Bohmer
2010-08-11 10:40 ` Stefano Babic
0 siblings, 1 reply; 8+ messages in thread
From: Remy Bohmer @ 2010-08-09 17:12 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] USB-CDC with musb controller
2010-08-09 17:12 ` Remy Bohmer
@ 2010-08-11 10:40 ` Stefano Babic
2010-08-11 12:48 ` Vitaly Kuzmichev
2010-08-11 18:51 ` Remy Bohmer
0 siblings, 2 replies; 8+ messages in thread
From: Stefano Babic @ 2010-08-11 10:40 UTC (permalink / raw)
To: u-boot
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
=====================================================================
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] USB-CDC with musb controller
2010-08-11 10:40 ` Stefano Babic
@ 2010-08-11 12:48 ` Vitaly Kuzmichev
2010-08-11 15:17 ` Stefano Babic
2010-08-11 20:06 ` Wolfgang Denk
2010-08-11 18:51 ` Remy Bohmer
1 sibling, 2 replies; 8+ messages in thread
From: Vitaly Kuzmichev @ 2010-08-11 12:48 UTC (permalink / raw)
To: u-boot
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.
>
> 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
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] USB-CDC with musb controller
2010-08-11 12:48 ` Vitaly Kuzmichev
@ 2010-08-11 15:17 ` Stefano Babic
2010-08-11 18:53 ` Remy Bohmer
2010-08-11 20:06 ` Wolfgang Denk
1 sibling, 1 reply; 8+ messages in thread
From: Stefano Babic @ 2010-08-11 15:17 UTC (permalink / raw)
To: u-boot
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
--
=====================================================================
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
=====================================================================
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] USB-CDC with musb controller
2010-08-11 10:40 ` Stefano Babic
2010-08-11 12:48 ` Vitaly Kuzmichev
@ 2010-08-11 18:51 ` Remy Bohmer
1 sibling, 0 replies; 8+ messages in thread
From: Remy Bohmer @ 2010-08-11 18:51 UTC (permalink / raw)
To: u-boot
Hi,
> Of course, if you agree with my analyses, I will send patches to fix them.
Great!
> 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.
nice catch.
> 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);
OK.
> 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.
Sounds okay. Indeed the Atmel core calls tx_complete().
Calling handle_interrupts() here might indeed do the job...
Kind regards,
Remy
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] USB-CDC with musb controller
2010-08-11 15:17 ` Stefano Babic
@ 2010-08-11 18:53 ` Remy Bohmer
0 siblings, 0 replies; 8+ messages in thread
From: Remy Bohmer @ 2010-08-11 18:53 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] USB-CDC with musb controller
2010-08-11 12:48 ` Vitaly Kuzmichev
2010-08-11 15:17 ` Stefano Babic
@ 2010-08-11 20:06 ` Wolfgang Denk
1 sibling, 0 replies; 8+ messages in thread
From: Wolfgang Denk @ 2010-08-11 20:06 UTC (permalink / raw)
To: u-boot
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
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Time is an illusion perpetrated by the manufacturers of space.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2010-08-11 20:06 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-08-05 11:44 [U-Boot] USB-CDC with musb controller Stefano Babic
2010-08-09 17:12 ` Remy Bohmer
2010-08-11 10:40 ` Stefano Babic
2010-08-11 12:48 ` Vitaly Kuzmichev
2010-08-11 15:17 ` Stefano Babic
2010-08-11 18:53 ` Remy Bohmer
2010-08-11 20:06 ` Wolfgang Denk
2010-08-11 18:51 ` Remy Bohmer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox