Hi,
I have been trying to get a working u-boot console over usb for the
DM365. I successfully ported the latest versions of drivers/usb and
drivers/serial/usbtty from the usb branch to the slightly older
version of u-boot supplied with my board and I have been able to get
stdout=usbtty to work properly. However I cannot seem to get stdin to
work at all. Much googling suggested others have seen the same problem
in the past but didn't turn up any fixes.
My setup has my Ubuntu desktop host linked by a standard usb to
miniusb cable to the board. When I power up the board it appears to
enumerate correctly as a device on my host. If I run two minicom
sessions on my host, one using serial and the other using usb, I can
type on the serial minicom and see the u-boot console on the usb
minicom. However setenv stdin usbtty causes u-boot to stop responding
to characters entered via either minicom session.
I have used wireshark to trace the usb traffic and I have established
that this command
echo "Hello" > /dev/ttyACM0
Produces this traffic on the USB bus:
No. Time Source Destination
Protocol Length Info
141 426.991749 host 2.1 USB
64 URB_INTERRUPT in
142 426.991759 host 2.0 USB
64 URB_CONTROL out
143 426.993716 2.0 host USB
64 URB_CONTROL out
144 426.993750 host 2.2
Ethernet 70 URB_BULK out[Malformed Packet]
145 426.993761 host 2.0 USB
64 URB_CONTROL out
146 426.994714 2.0 host USB
64 URB_CONTROL out
147 426.995713 2.1 host USB
64 URB_INTERRUPT in
URB status: No such file or directory (-ENOENT) (-2)
148 426.996713 2.2 host USB
64 URB_BULK out
URB status: No such file or directory (-ENOENT) (-2)
Obviously if you know the problem and can tell me a fix that would be
fantastic, if not I have two specific questions which would help me
debug this.
1) Where in the u-boot source is the code which is generating the
responses with the error codes above? I can't find any point in the
code which is capable of setting urb->status=ERROR. Is it possible
that the hardware itself can generate these responses automatically?
2) What is supposed to happen when the host sends the BULK packet
containing the "Hello" string? It's possible that the error codes in
the USB traffic are a red herring. As far as I can tell, the device
should raise an interrupt to tell usbtty to read the fifo and pull out
the "Hello" string. Since U-boot runs with interrupts turned off, the
function udc_irq() in drivers/musb/musb_udc.c polls the interrupt
registers to see if it should do anything. However the call to intrrx
= readw(&musbr->intrrx); always returns 0 and the call to intrusb =
readb(&musbr->intrusb); always returns "Start of Frame" (never seems
to get cleared). Usually reading an interrupt register clears it, but
this doesn't seem to happen in this case. I confess to being a bit
confused about interrupt polling anyway. It seems to rely on the idea
that the hardware will set the interrupt registers even though
interrupts are disabled so that they can be polled. However the
hardware documentation is a bit light on details about what happens
with interrupts masked off since that isn't it's intended mode of
operation.
I've been working on this for several weeks now and would be really
grateful for a pointer from an expert.
Many thanks,
Alex
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
