Hi All,
Has anyone tried kernel v4.1? I'm currently on 3.12 but having issues
with hot-plug via HUB (as discussed at
https://github.com/beagleboard/kernel/issues/64). People say USB
doesn't work well on v3.14 and under.
I've tried USBProxy on v4.1 kernel stable release but don't seem to
get it to work. Are there any patches (e.g. inode.c) applicable to
4.1? The one for v3.16 plus looks incompatible with v4.1.
Thanks,
Gordon
On Fri, Jul 3, 2015 at 10:12 AM, Dominic Spill <dominicgs@xxxxxxxxx> wrote:
On 2 July 2015 at 20:19, Y. Zhang <ygz999@xxxxxxxxx> wrote:
- about usbmon: it seems to be able to monitor peripheral traffics only. In
the BBB case, only 2u. The gadgetFS is on bus 1 but nothing shows up on 1u.
The usbmon sniffs traffics to hdrc controller only, as such one can only
monitor usb traffics from/to device, not from/to host connected with
gadgetFS.
Yes, I was interested in checking which packets were transferred
between USBProxy and the hub.
The pcap shows that the host sends GET_STATUS requests, which I wanted
to know if the hub was seeing and responding to. Of course, that
wouldn't have told us anything about the GET_DESCRIPTOR response /
status messages.
- the issue with unresponded requests is due to a bug in USBProxy, where
ctl.request==0 is used to imply no control request on
host->control_request(); however, 0 is actually valid (namely get_status).
Since it's dropped, gadgetfs sets POLLHUP (instead of POLLIN) causing any
following requests not being retrieved by USBProxy (by testing POLLIN).
- after fixing the bug with USBProxy mentioned above, I was able to proceed
a bit further.
That's great. do you have a patch or pull request so that we can fix
it in the main repository?
When I insert a device (say USB stick) into the HUB, the host
starts to perform actions on the port (like set/clear features etc which
seem fine) but eventually gives up due to unresponsive get_descriptor and/or
set_address via address=0. This is one of the major issues. I'd like your
comments on the following:
+ How to retrieve host requests to address 0 (before the host enumerates
the device address)? Apparently address 0 is not the ep0 of the gadgetFS and
I have no idea where to intercept such traffics.
Here is part of the problem. GadgetFS isn't a pipe through which we
can just send USB packets. It represents a single USB device, with
VID/PID and receives an address from the host. We forward the
requests to the device attached to the BBB, but we aren't actually
forwarding the packets, with their addresses to anything.
It's been a while since I looked at the code, so I need to have a
think about how we can represent this.
+ If the traffics to address 0 can be handled properly, the next major issue
will be how to intercept traffics to all endpoints (ep0, ...) of the
enumerated device within the gadgetFS (which are in addition to ep0... of
the hub) .
This seems to be an extension of the above problem - having gadgetfs
handle packets which it doesn't think are for it. I', unsure if you
can force gadgetfs to act as multiple devices or as a soft hub to
allow us to handle arbitrary devices.
