Gadget mode advice sought
Greetings, I'm trying to find the simplest way to develop a bulk mode gadget that exposes a standard userland IO interface. I've not been able to find anything suitable but if such a beast does exist please do point me in the right direction. Failing that please read on. The appliance collects data via video and other sensors. There is an intermediate userland processing application that sources from video (V4L2), SPI, etc. and would write its output to the host via USB. V4L2 on the target H3 SoC is only (currently) supported with a 3.4.X kernel. Thus newer gadget FS options marked as experimental. This may be a significant constraint, I am not yet sure. This is an embedded appliance and g_zero does work. Thus I am minded to extend g_zero, adding fileops etc. so it appears as a standard character mode driver in /dev. Read() and write() would simply be hooked in to the source_sink_complete() handler. Does this sense? Any comments/thought much appreciated. TAIA Jerry. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Gadget mode advice sought
Hi and thanks > 3.4??? sorry, you're on your own. You need to ask for support from whoever forces you to stay on this kernel. Absolutely but sadly it is the all-important camera interface which is completely missing from mainline. That said I have GadgetFS working to the extent it is showing up as a nearly functional bulk-mode device. BR. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Gadget mode advice sought
Hello and thanks, > You should use the serial (tty) interface for this (see f_serial.c / serial.c) Not keen on that for binary data. > No. g_zero is meant only for testing purposes. Indeed. Problem is looking solved using GadgetFS working on the target board. Promise my next set of USB questions will be with for a contemporary kernel! Thanks again. Jerry. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Question: GadgetFS and EP0 'IN' traffic?
I'm obviously missing something here but am not quite sure what. My usermode code* is set up to emulate an existing FX3 device. Bulk reads and writes are all fine as are vendor-specific commands that are host to device. However anything that is device to host never appears on the wire. The generic handler for IN vendor requests is simply writes 'length' bytes back on the file descriptor that represents EP0. USB packet sniffers show that data never gets out. Does it need to ACK or clear anything first? Incidentally is there any reason why EP0 itself does not appear in the /dev/gadget tree? TAIA Jerry * based on the example here: http://www.linux-usb.org/gadget/usb.c -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Question: GadgetFS and EP0 'IN' traffic?
Hello and thanks > Do you mean: Any control-IN data (device to host) never appears on the wire? After all, you said that bulk reads and writes > are fine. Correct. Data sent via the bulk endpoint is visible. Data sent device to host on EP0 in response to my vendor commands is not. Now this is very weird as the host is obviously getting enough traffic on EP0 to acquire descriptors and strings. I am mystified. Is there anything internally that might affect EP0 writes once setup/configuration is complete? Can you suggest any obvious places further down the stack where I can put some trace/debug code? This board is a PITA to run under a debugger. > Yes, that is how it should work. The data is supposed to appear on the bus. Yes, as expected. > ep0 is represented by the original gadget file (/dev/gadget/"UDC name"): Ah, of course. I appreciate your exceptionally prompt response. Many thanks. Jerry. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Question: GadgetFS and EP0 'IN' traffic?
Hello Alan. > Plenty of things could affect it. Without knowing more about your system, I > can't be more specific. For example, what UDC > driver are you using? Ah 😊. It's an ancient (3.4.x*) sunxi_usb_hdc running on an AllWinner H3. > And have you tried testing your program with the dummy-hcd driver? Good point. Not yet. > Do you get the correct values for the GADGETFS_SETUP event? You mean post enumeration from host to device? Yes, I send some majik packets for proof of life. All good in that direction. > What is the return value from the write() call where you send the vendor data? As expected, the number of bytes written back to the endpoint. In this case 4. > If you want to add some debugging output to the kernel's gadgetfs driver, the > appropriate place would be inside epo_write() in > drivers/usb/gadget/legacy/inode.c. The part following: Ideal and once again extremely helpful. Thank you. BR, Jerry. * We will move to mainline ASAP but this is a quick proof of concept and there is zero support in mainline for the essential AllWinner camera interface. That'll be the next task. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
