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