Re: Linux USB file storage gadget with new UDC
Hi, >> > > >> > > The udc_start() function is being called now. Before this, it was not >> > > called because of driver->max_speed checking in udc_start(). After >> > > udc_start(), which function is to be called when the gadget device is >> > > connected to the host PC? >> > > >> > > Thanks. I will look at the "controller 'kagen2_usb' not recognized" >> message. >> > > The development is being done on arm9 architecture. I am afraid it is >> > > not possible to move to a newer kernel now. >> > >> > fair enough. Just to help you out, I believe that message will be under >> > drivers/usb/gadget/gadget_chips.h: >> > >> > >> http://git.kernel.org/?p=linux/kernel/git/balbi/usb.git;a=blob;f=drivers/usb >> /gad >> > get/gadget_chips.h;h=a8855d0b7f3bdf19fbdc76eab8a25992f07884b0;hb=76e1 >> > 0d158efb6d4516018846f60c2ab5501900bc >> > >> > note that you must add your gadget_is_kagen2() and check for it on >> > usb_gadget_controller_number(). Also keep in mind that this doesn't exist >> > anymore for recent kernels. >> > >> >> Thanks, I got it done. I can insmod the g_file_storage.ko without the >> "controller 'kagen2_usb' not recognized" message. After that, can I simply >> connect the usb cable to the host PC? Because the PC says "USB device not >> recognised" when I do so. I have registered the irq routine in >> kagen2_udc.ko, and it is not called when usb cable is plugged in. What can >> go wrong? > > from this point on, you need to read your HW documentation. Maybe you're > using wrong IRQ number ? Who knows. I have no clue how kagen2 works and > can't help anymore. > I find out the IRQ number for usb, and unmask that IRQ number in interrupt controller. So usb cable is plugged into host PC, the gadget (which runs on linux) freezes immediately, no error message is printed out, no device reset. now i don't know whether linux hang or the hardware hang. Thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> 1) host PC sends a GET_DESCRIPTOR request, the gadget replies with device >> descriptor. >> 2) host PC sends a SET_ADDRESS request >> 3) host PC sends a GET_DESCRIPTOR request, the gadget replies with the same >> device descriptor. >> 4) host PC sends a GET_DESCRIPTOR request, the gadget replies with >> configuration descriptor. >> 5) host PC sends a GET_DESCRIPTOR request, the gadget replies with string >> descriptor. >> 6) host PC sends a GET_DESCRIPTOR request, the gadget replies with string >> descriptor. >> 7) host PC sends a GET_DESCRIPTOR request, the gadget replies with device >> qualifier descriptor. >> 8) host PC sends a GET_DESCRIPTOR request, the gadget replies with the same >> device descriptor. >> 9) host PC sends a GET_DESCRIPTOR request, the gadget replies with >> configuration descriptor. >> 10) host PC sends SET_CONFIGURATION >> 11) host PC sends 0xfe bRequest > > What does the gadget send in response to this request? In response to this request, class_setup_req() in file_storage.c is called, then the case US_BULK_GET_MAX_LUN is entered, the fsg->nluns is 1. The gadget then sends 1 byte of 0x00. >> How to fix the bulk out endpoint >> to 1? > > Fix your UDC driver. If it uses the right names for the endpoints then > usb_ep_autoconfig() will automatically do the right thing. The bulk out descriptor is defined in storage_common.c, as "fsg_fs_bulk_out_desc". How to set the names of endpoints so that usb_ep_autoconfig() can do the right thing? I use the USBlyzer software on host PC, i can see that SCSI inquiry is sent out by the host PC, but the gadget device does not receive it, due to the mis-match bulk out endpoint. Bulk out endpoint is auto-configured to 2, whereas gadget device bulk out endpoint is 1. thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, > > I use the USBlyzer software on host PC, i can see that SCSI inquiry is > sent out by the host PC, but the gadget device does not receive it, > due to the mis-match bulk out endpoint. Bulk out endpoint is > auto-configured to 2, whereas gadget device bulk out endpoint is 1. > Replying my email, i set the ep,name to ep1 for bulk out and bulk in endpoints. The ep_matches() in epautoconf.c is able to auto-configure the bulk out to endpoint 1. however, i only see one SCSI_INQUIRY command being sent out, and it is not received by the gadget device. thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> Replying my email, i set the ep,name to ep1 for bulk out and bulk in >> endpoints. The ep_matches() in epautoconf.c is able to auto-configure >> the bulk out to endpoint 1. > > Are you sure the name string is set to "ep1" for both endpoints? (Or > "ep1in" and "ep1out"?) If the string was instead set to "ep" or > "ep-bulk" or something like that, then it would make sense for the > auto-configured bulk-out endpoint address to be 2. > > You should add some printk statements to the ep_matches() routine in > epautoconf.c so you can see exactly what it is doing. Yes, i change the name string to "ep1" for both endpoints [ Before that, it is ep-a, ep-b, and bulk-out endpoint auto-configured to 2 ]. In ep_matches(), the isdigit(ep->name[2]) if-condition is fulfilled. In fsg_bind(), after the usb_ep_autoconfig() for bulk-out returns, the fsg_fs_bulk_out_desc.bEndpointAddress is 1. >> however, i only see one SCSI_INQUIRY command being sent out, and it is >> not received by the gadget device. > > There could be other reasons for this, like an incorrect data toggle > value. Are you certain the endpoint address is wrong? Can you post > the usbmon trace and the output from "lsusb -v" for the gadget? > Now the endpoint address is ok, i guess. After i do insmod usbmon, g_file_storage, and my UDC driver, the "lsusb -v" shows nothing. Should my UDC driver provide the info in /sys/bus/usb folder? # ls /sys/bus/usb/ devicesdrivers_autoprobe uevent driversdrivers_probe # lsusb -v # Thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> Now the endpoint address is ok, i guess. >> After i do insmod usbmon, g_file_storage, and my UDC driver, the >> "lsusb -v" shows nothing. > > usbmon doesn't do anything on the gadget side; it is meant to be used > on the host. The same is true for lsusb. > >> Should my UDC driver provide the info in >> /sys/bus/usb folder? > > No. > Yes, usbmon requires usb host side support (i enable them both to use usbmon). So i disable the usbmon and usb host side support in menuconfig. Then i rebuild linux again. Subsequently, the /sys/bus does not contain usb folder. # ls /sys/bus/ clocksource cpu mmc platform sdio spi > Did you enable the two debugging options in file_storage.c? And did > you remember to enable CONFIG_USB_GADGET_DEBUG in the kernel > configuration? What shows up in the dmesg log? Yes, i enable the CONFIG_USB_GADGET_DEBUG and the VERBOSE_DEBUG and DUMP_MSGS in file_storage.c. In dmesg log, there are lot of entries recorded during usb gadget enumeration with host PC. After gadget receives "get MAX LUN", the enumeration process gets repeated. Is this the problem?? Please see the dmesg log below. g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 40 00 g_file_storage gadget: get device descriptor g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 12 00 g_file_storage gadget: get device descriptor g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 ff 00 g_file_storage gadget: get configuration descriptor g_file_storage gadget: ep0-setup, length 8: : 80 06 00 03 00 00 ff 00 g_file_storage gadget: get string descriptor g_file_storage gadget: ep0-setup, length 8: : 80 06 02 03 09 04 ff 00 g_file_storage gadget: get string descriptor g_file_storage gadget: ep0-setup, length 8: : 80 06 00 06 00 00 0a 00 g_file_storage gadget: get device qualifier g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 12 00 g_file_storage gadget: get device descriptor g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 09 00 g_file_storage gadget: get configuration descriptor g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 20 00 g_file_storage gadget: get configuration descriptor g_file_storage gadget: ep0-setup, length 8: : 00 09 01 00 00 00 00 00 g_file_storage gadget: set configuration g_file_storage gadget: set interface 0 g_file_storage gadget: high-speed config #1 g_file_storage gadget: ep0-setup, length 8: : a1 fe 00 00 00 00 01 00 g_file_storage gadget: get max LUN g_file_storage gadget: ep0-setup, length 8: : 80 06 01 03 09 04 ff 00 g_file_storage gadget: get string descriptor g_file_storage gadget: ep0-setup, length 8: : 80 06 04 03 09 04 ff 00 g_file_storage gadget: get string descriptor g_file_storage gadget: ep0-setup, length 8: : 80 06 05 03 09 04 ff 00 g_file_storage gadget: get string descriptor g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 40 00 g_file_storage gadget: get device descriptor . Thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, > For testing purposes, you probably should use a Linux host. Then you > could use usbmon on the host to see what's happening, and there would > be more debugging options available. Got it, i will get a PC to install Linux. >> > Did you enable the two debugging options in file_storage.c? And did >> > you remember to enable CONFIG_USB_GADGET_DEBUG in the kernel >> > configuration? What shows up in the dmesg log? >> >> Yes, i enable the CONFIG_USB_GADGET_DEBUG and the VERBOSE_DEBUG and >> DUMP_MSGS in file_storage.c. In dmesg log, there are lot of entries >> recorded during usb gadget enumeration with host PC. After gadget >> receives "get MAX LUN", the enumeration process gets repeated. Is this >> the problem?? Please see the dmesg log below. > > This log looks oddly incomplete. A lot of debugging messages are > missing. > >> g_file_storage gadget: ep0-setup, length 8: >> : 80 06 00 01 00 00 40 00 >> g_file_storage gadget: get device descriptor > > For example, right here we should see the device descriptor data that > was sent back to the host. I checked the log again, the dmesg log did not contain that info. May i know which part of the gadget code will print out the device descriptor data that was sent back to the host? >> . > > Where does the enumeration repeat? I don't see any repeats here, aside > from the fact that Windows asks for the same device and config > descriptors a few times. Why is the Windows asking for the same device and config descriptors several times? Thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, For bulk transfer, the new UDC driver has one problem. When SCSI Inquiry command is received, the UDC driver interrupt routine will receive it first. However, the queue function is not yet called, and queue buffer is not yet added. Thus, interrupt routine is not able to store the SCSI Inquiry command to the queue buffer. This is a serious problem, what is the way to synchronise UDC driver and file storage gadget driver for SCSI command bulk transfer? Regards, Victor -- 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: Linux USB file storage gadget with new UDC
Hi, > On Fri, Mar 15, 2013 at 01:59:30PM +0800, victor yeo wrote: >> For bulk transfer, the new UDC driver has one problem. When SCSI >> Inquiry command is received, the UDC driver interrupt routine will >> receive it first. However, the queue function is not yet called, and >> queue buffer is not yet added. Thus, interrupt routine is not able to >> store the SCSI Inquiry command to the queue buffer. >> >> This is a serious problem, what is the way to synchronise UDC driver >> and file storage gadget driver for SCSI command bulk transfer? > > don't process the interrupt until you receive a queue. Data will be > pending in controller's FIFO until then. > change to do exactly that, bulk transfer interrupt come in, don't process, then queue function is called to add queue buffer. After that, no more bulk transfer interrupt come in. regards, victor -- 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: Linux USB file storage gadget with new UDC
Hi, On Sat, Mar 16, 2013 at 1:49 AM, Felipe Balbi wrote: > On Fri, Mar 15, 2013 at 11:00:45AM -0400, Alan Stern wrote: >> On Fri, 15 Mar 2013, Felipe Balbi wrote: >> >> > On Fri, Mar 15, 2013 at 04:26:10PM +0800, victor yeo wrote: >> > > Hi, >> > > >> > > > On Fri, Mar 15, 2013 at 01:59:30PM +0800, victor yeo wrote: >> > > >> For bulk transfer, the new UDC driver has one problem. When SCSI >> > > >> Inquiry command is received, the UDC driver interrupt routine will >> > > >> receive it first. However, the queue function is not yet called, and >> > > >> queue buffer is not yet added. Thus, interrupt routine is not able to >> > > >> store the SCSI Inquiry command to the queue buffer. >> > > >> >> > > >> This is a serious problem, what is the way to synchronise UDC driver >> > > >> and file storage gadget driver for SCSI command bulk transfer? >> > > > >> > > > don't process the interrupt until you receive a queue. Data will be >> > > > pending in controller's FIFO until then. >> > > > >> > > >> > > change to do exactly that, bulk transfer interrupt come in, don't >> > > process, then queue function is called to add queue buffer. After >> > > that, no more bulk transfer interrupt come in. >> > >> > did you process the pending data from FIFO after queue was called ? >> >> I'm not sure about the details of how the controller hardware works. >> But what should happen is this: When the controller receives the bulk >> packet containing the INQUIRY command, it should send back NAK until it >> has a buffer ready to store the packet. > > right, with all controllers I have seen so far, this means just not > processing the interrupt, AKA not starting a transfer. > Thanks, i add processing the pending data from FIFO after queue was called. The UDC driver can process the SCSI INQUIRY command and SCSI READ FORMAT CAPACITIES command now. In the processing of SCSI READ FORMAT CAPACITIES command, there is attention condition. Then the bulk transfer stops completely and control transfer is repeated. How can i solve it? Regards, victor -- 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: Linux USB file storage gadget with new UDC
Hi,
On Wed, Mar 20, 2013 at 10:22 PM, Alan Stern wrote:
> On Wed, 20 Mar 2013, victor yeo wrote:
>
>> Thanks, i add processing the pending data from FIFO after queue was
>> called. The UDC driver can process the SCSI INQUIRY command and SCSI
>> READ FORMAT CAPACITIES command now.
>>
>> In the processing of SCSI READ FORMAT CAPACITIES command, there is
>> attention condition. Then the bulk transfer stops completely and
>> control transfer is repeated.
>
> What control transfer?
those get descriptor requests.
>> How can i solve it?
>
> First you have to figure out why it isn't working. What does the
> debugging information show?
Here is some debugging information:
receive GET_DESCRIPTOR, 80, 6 index 0 value 200 len 20
receive SET_CONFIGURATION, 0, 9 index 0 value 1 len 0
set curlun->unit_attention_data to SS_NO_SENSE
do_set_config() is called because of FSG_STATE_CONFIG_CHANGE
do_set_interface() is called
set curlun->unit_attention_data to SS_RESET_OCCURRED
receive *UNKNOWN*, a1, fe index 0 value 0 len 1
receive SCSI Inquiry
receive SCSI read format capacities, get attention condition,
curlun->unit_attention_data is 062900 (SS_RESET_OCCURRED)
The gadget code is able to process SCSI Inquiry because it does not
fulfill the if-condition:
if (curlun && curlun->unit_attention_data != SS_NO_SENSE &&
fsg->cmnd[0] != INQUIRY &&
fsg->cmnd[0] != REQUEST_SENSE) {
Why is curlun->unit_attention_data set to SS_RESET_OCCURRED?
Regards,
Victor
--
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: Linux USB file storage gadget with new UDC
Hi, >> > First you have to figure out why it isn't working. What does the >> > debugging information show? >> >> Here is some debugging information: >> >> receive GET_DESCRIPTOR, 80, 6 index 0 value 200 len 20 >> receive SET_CONFIGURATION, 0, 9 index 0 value 1 len 0 >> set curlun->unit_attention_data to SS_NO_SENSE >> do_set_config() is called because of FSG_STATE_CONFIG_CHANGE >> do_set_interface() is called >> set curlun->unit_attention_data to SS_RESET_OCCURRED >> receive *UNKNOWN*, a1, fe index 0 value 0 len 1 >> receive SCSI Inquiry >> receive SCSI read format capacities, get attention condition, >> curlun->unit_attention_data is 062900 (SS_RESET_OCCURRED) > > Up to this point, everything is normal. We need to see what happens > next. > After the SS_RESET_OCCURRED attention condition, the debug information is: start_transfer is called the driver queue function is called start_transfer is called the driver queue function is called to send out CSW of 13 bytes driver receive EP1 IN interrupt bulk_in_complete is called get_next_command is called driver receive setup data valid interrupt receive GET_DESCRIPTOR, 80, 6 index 0 value 200 len 20 .many control transfers.. May i know if everything is normal here? Thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> I have a serial console to access the platform. Today i use Linux as >> USB host. The log of the usb gadget is attached (gadget-log.txt). >> >> The Linux usbmon log file is also attached (usbmon-log.txt). Hopefully >> the log data will be useful. > > It looks like you cut out a lot of information from the gadget log. > Please don't do that. > > The logs show that your driver still has several bugs. For example, > the start of the gadget log shows that the driver thinks it received a > bunch of packets on the bulk-out endpoint, but the usbmon log shows > that the host never sent these packets. > > Your driver does not set the Halt feature for the bulk-in endpoint when > it is supposed to. It doesn't even respond with NAK when it receives > an invalid request on endpoint 0. > > When asked to transmit 4096 bytes of data, your driver sent a packet > containing more than 512 bytes. > I do not know when to set the Halt feature for the bulk-in endpoint. I see gadget code have this line printed out: g_file_storage gadget: bulk-in set halt In the log file, is there any invalid request received on endpoint 0? Regards, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> I do not know when to set the Halt feature for the bulk-in endpoint. I >> see gadget code have this line printed out: >> g_file_storage gadget: bulk-in set halt > > The UDC driver is supposed to set the Halt feature when the set_halt() > routine in the usb_ep_ops table is called with a nonzero second > argument. Also when the set_wedge() routine is called -- the > difference is that with set_wedge(), the driver should ignore > Clear-Halt requests from the host. > > All of this material is documented in include/linus/usb/gadget.h. Why > don't you read that file? > I thought Halt feature is optional. I will add code to instruct hardware to set the halt feature. I suppose the driver needs to handle usb_ep_clear_halt() too. Thanks. g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=4096; Hc=10, Hi=4096 g_file_storage gadget-lun0: file read 4096 @ 0 -> 4096 About the SCSI_READ_10 command, why is it reading 4096 bytes, as the MBR(master boot record) is only 512 bytes? >> In the log file, is there any invalid request received on endpoint 0? > > In the usbmon file there is. It is this line: > >> f4ae6f40 1217192721 S Co:2:018:0 s 21 ff 0 ok, i will add code to UDC to instruct hardware to send NAK upon receiving invalid request on endpoint 0. Does it mean that UDC driver has to check for invalid request on endpoint 0? Thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> >> In the log file, is there any invalid request received on endpoint 0? >> > >> > In the usbmon file there is. It is this line: >> > >> >> f4ae6f40 1217192721 S Co:2:018:0 s 21 ff 0 >> >> ok, i will add code to UDC to instruct hardware to send NAK upon >> receiving invalid request on endpoint 0. Does it mean that UDC driver >> has to check for invalid request on endpoint 0? > > No. The UDC driver has no way to know whether a request is valid or > not. Read the description of the "setup" member of the > usb_gadget_driver structure in the header file. > I read that. The "setup" member of the usb_gadget_driver structure is pointing to fsg_setup, in file_storage.c. The fsg_setup() function handles the request on endpoint 0. So how could UDC driver know when to send NAK? Thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> >> ok, i will add code to UDC to instruct hardware to send NAK upon >> >> receiving invalid request on endpoint 0. Does it mean that UDC driver >> >> has to check for invalid request on endpoint 0? >> > >> > No. The UDC driver has no way to know whether a request is valid or >> > not. Read the description of the "setup" member of the >> > usb_gadget_driver structure in the header file. >> > >> >> I read that. The "setup" member of the usb_gadget_driver structure is >> pointing to fsg_setup, in file_storage.c. The fsg_setup() function >> handles the request on endpoint 0. So how could UDC driver know when >> to send NAK? > > When an invalid request is received, the gadget is supposed to send > STALL, not NAK. See the last two lines of the "setup" description: > > * USB byte order. Called in_interrupt; this may not sleep. Driver > * queues a response to ep0, or returns negative to stall. > > "Driver ... returns negative to stall." That's how the UDC driver > knows whether to send a STALL packet -- if the setup callback returns a > negative value. > > Also, it looks like you didn't read this paragraph in the description > of usb_ep_queue(): > > * Control endpoints ... after getting a setup() callback, the driver queues > * one response (even if it would be zero length). That enables the > * status ack, after transferring data as specified in the response. Setup > * functions may return negative error codes to generate protocol stalls. > * (Note that some USB device controllers disallow protocol stall responses > * in some cases.) When control responses are deferred (the response is > * written after the setup callback returns), then usb_ep_set_halt() may be > * used on ep0 to trigger protocol stalls. Depending on the controller, > * it may not be possible to trigger a status-stage protocol stall when the > * data stage is over, that is, from within the response's completion > * routine. > > Notice especially the fourth line. > > Alan Stern > Understand, UDC driver will call driver->setup(), and if the return value is negative, UDC driver has to set dev->protocol_stall = 1 and maybe call usb_ep_set_halt(). However, the hardware won't be able to send out zero length response. I think the purpose of zero length response is to get an ACK from the host. Thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> Understand, UDC driver will call driver->setup(), and if the return >> value is negative, UDC driver has to set dev->protocol_stall = 1 and >> maybe call usb_ep_set_halt(). However, the hardware won't be able to >> send out zero length response. > > Don't be silly; of course it can. Nobody would be foolish enough to > design a piece of USB hardware that couldn't send a zero-length DATA > packet. > >> I think the purpose of zero length >> response is to get an ACK from the host. > > The purpose of the zero-length response is to complete the Status stage > of a control-OUT transfer. Thanks, the halt feature is ok now. The SCSI_READ_10 command has a problem. The reply value from do_read is -5, which means -EIO. The for(;;) loop in do_read() was probably broken at "if (amount_left == 0)". Is this if-statement valid? Here is the gadget log when receiving SCSI_READ_10 from Linux host. g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 0f 00 00 00 00 10 00 00 80 00 0a 28 0010: 00 00 00 00 00 00 00 08 00 00 00 00 e0 f8 02 SCSI CDB: 28 00 00 00 00 00 00 00 08 00 g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=4096; Hc=10, Hi=4096 < driver read from SD card .> g_file_storage gadget-lun0: file read 4096 @ 0 -> 4096 READ_10 reply -5 *** printk added by me*** g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 0f 00 00 00 00 00 00 00 00 Thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> Here is the gadget log when receiving SCSI_READ_10 from Linux host. >> >> g_file_storage gadget: bulk-out, length 31: >> : 55 53 42 43 0f 00 00 00 00 10 00 00 80 00 0a 28 >> 0010: 00 00 00 00 00 00 00 08 00 00 00 00 e0 f8 02 >> SCSI CDB: 28 00 00 00 00 00 00 00 08 00 >> g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=4096; Hc=10, >> Hi=4096 >> < driver read from SD card .> >> g_file_storage gadget-lun0: file read 4096 @ 0 -> 4096 >> READ_10 reply -5 *** printk added by me*** >> g_file_storage gadget: bulk-in, length 13: >> : 55 53 42 53 0f 00 00 00 00 00 00 00 00 > > This all looks right. There is a problem with SCSI_READ_10 command if looking at usbmon. I pasted the usbmon log that starts from SCSI_READ_10. Basically, the SCSI_READ_10 was received by gadget, processed, sent CSW, followed by control packets. Then another SCSI_READ_10, sent CSW, followed by control packets. Then another SCSI_READ_10, but CSW is not received by host. There must be problems in the UDC driver. CSW is sent by the UDC driver but it is not received by the Linux host. Thanks, victor f59e13c0 3246885432 S Bo:2:046:1 -115 31 = 55534243 0c00 0010 8a28 0008 00 f59e13c0 3246885582 C Bo:2:046:1 0 31 > f59e15c0 3246885594 S Bi:2:046:1 -115 4096 < f59e15c0 3247150217 C Bi:2:046:1 -75 0 f59e13c0 3247150291 S Bi:2:046:1 -115 13 < f59e13c0 3247150450 C Bi:2:046:1 -75 0 f412a840 3247310347 S Ci:2:046:0 s 80 06 0100 0012 18 < f412a840 3247313216 C Ci:2:046:0 0 18 = 12010002 0040 2505a5a4 33030102 0001 f412a840 3247313226 S Ci:2:046:0 s 80 06 0200 0020 32 < f412a840 3247326452 C Ci:2:046:0 0 32 = 09022000 010104c0 01090400 00020806 50050705 81020002 00070501 02000201 f412a840 3247326511 S Co:2:046:0 s 00 09 0001 0 f412a840 3247339340 C Co:2:046:0 0 0 f59e13c0 3247345346 S Bo:2:046:1 -115 31 = 55534243 0d00 0010 8a28 0008 00 f59e13c0 3247345450 C Bo:2:046:1 0 31 > f59e15c0 3247345461 S Bi:2:046:1 -115 4096 < f59e15c0 3247352463 C Bi:2:046:1 -75 0 f59e13c0 3247352476 S Bi:2:046:1 -115 13 < f59e13c0 3247352712 C Bi:2:046:1 0 0 f59e13c0 3247352720 S Bi:2:046:1 -115 13 < f59e13c0 3247359080 C Bi:2:046:1 0 13 = 55534253 0c00 00 f412a840 3247529347 S Ci:2:046:0 s 80 06 0100 0012 18 < f412a840 3247530463 C Ci:2:046:0 0 18 = 12010002 0040 2505a5a4 33030102 0001 f412a840 3247530476 S Ci:2:046:0 s 80 06 0200 0020 32 < f412a840 3247543866 C Ci:2:046:0 0 32 = 09022000 010104c0 01090400 00020806 50050705 81020002 00070501 02000201 f412a840 3247543906 S Co:2:046:0 s 00 09 0001 0 f412a840 3247556713 C Co:2:046:0 0 0 f59e13c0 3247562349 S Bo:2:046:1 -115 31 = 55534243 0e00 0010 8a28 0008 00 f59e13c0 3247562449 C Bo:2:046:1 0 31 > f59e15c0 3247562460 S Bi:2:046:1 -115 4096 < f59e15c0 3278472491 C Bi:2:046:1 -104 0 -- 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: Linux USB file storage gadget with new UDC
Hi, >> f59e13c0 3246885432 S Bo:2:046:1 -115 31 = 55534243 0c00 0010 >> 8a28 0008 00 >> f59e13c0 3246885582 C Bo:2:046:1 0 31 > >> f59e15c0 3246885594 S Bi:2:046:1 -115 4096 < >> f59e15c0 3247150217 C Bi:2:046:1 -75 0 > > This is the problem. -75 is -EOVERFLOW; it means the host received a > packet that was larger than expected. Since the maxpacket value for a > bulk-in endpoint is 512, your UDC must be sending bulk DATA packets > with more than 512 bytes. > > Alan Stern Thanks. Working on this problem now. Another problem observed for SCSI_READ_10 command, when reading from the SD card, the gadget driver never sends the MBR address, the FAT boot record address, the start of FAT address, and the start of FAT cluster address to the SD card driver. The address sent by gadget driver is wrong. So is the gadget driver designed to work with SCSI/SATA/ATA drive only? Thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> Thanks. Working on this problem now. Another problem observed for >> SCSI_READ_10 command, when reading from the SD card, the gadget driver >> never sends the MBR address, the FAT boot record address, the start of FAT >> address, and the start of FAT cluster address to the SD card driver. > > The gadget doesn't make up addresses by itself. It always sends the > address the host tells it to send. > >> The >> address sent by gadget driver is wrong. > > Then the address sent by the host is wrong. > > However, I suspect you are mistaken. In your usbmon trace earlier, the > very first READ(10) command had a logical block address of 0. That is > the address of the MBR. If the driver hadn't failed at that point, the > host would have gone on to ask for the address of the boot sector and > other things. Yes, the very first READ(10) command has a logical block address of 0 (as shown below). I will generate the fresh usbmon trace the next day, i do not have access to the platform now. f59e13c0 3246885432 S Bo:2:046:1 -115 31 = 55534243 0c00 0010 8a28 0008 00 Thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi,
>>> Thanks. Working on this problem now. Another problem observed for
>>> SCSI_READ_10 command, when reading from the SD card, the gadget driver
>>> never sends the MBR address, the FAT boot record address, the start of FAT
>>> address, and the start of FAT cluster address to the SD card driver.
>>
>> The gadget doesn't make up addresses by itself. It always sends the
>> address the host tells it to send.
>>
>>> The
>>> address sent by gadget driver is wrong.
>>
>> Then the address sent by the host is wrong.
>>
>> However, I suspect you are mistaken. In your usbmon trace earlier, the
>> very first READ(10) command had a logical block address of 0. That is
>> the address of the MBR. If the driver hadn't failed at that point, the
>> host would have gone on to ask for the address of the boot sector and
>> other things.
>
> Yes, the very first READ(10) command has a logical block address of 0
> (as shown below). I will generate the fresh usbmon trace the next
> day, i do not have access to the platform now.
>
> f59e13c0 3246885432 S Bo:2:046:1 -115 31 = 55534243 0c00 0010
> 8a28 0008 00
>
Here is the fresh usbmon trace. Four SCSI commands are shown. The
first SCSI_READ_10 command has LBA of 0. The second SCSI_READ_10
command has LBA of 0x00ed2900, which is wrong. Somehow, the first
SCSI_READ_10 command got the wrong data, i think. Isn't it?
f31a9740 4037054141 S Bo:2:071:1 -115 31 = 55534243 0c00 0010
8a28 0008 00
f31a9740 4037054176 C Bo:2:071:1 0 31 >
f4a555c0 4037054184 S Bi:2:071:1 -115 4096 <
f4a555c0 4037108430 C Bi:2:071:1 0 4096 = eb58904d 53444f53 352e3000
02402e11 0200 00f8 3f00ff00 0020
f31a9740 4037108476 S Bi:2:071:1 -115 13 <
f31a9740 4037114564 C Bi:2:071:1 0 13 = 55534253 0c00 00
f31a9740 4037114722 S Bo:2:071:1 -115 31 = 55534243 0d00
0600 00
f31a9740 4037114801 C Bo:2:071:1 0 31 >
f31a9740 4037114805 S Bi:2:071:1 -115 13 <
f31a9740 4037121303 C Bi:2:071:1 0 13 = 55534253 0d00 00
f31a9740 4037121388 S Bo:2:071:1 -115 31 = 55534243 0e00 0800
8a25 00
f31a9740 4037121550 C Bo:2:071:1 0 31 >
f4a552c0 4037121559 S Bi:2:071:1 -115 8 <
f4a552c0 4037127426 C Bi:2:071:1 0 8 = 00ed29c7 0200
f31a9740 4037127435 S Bi:2:071:1 -115 13 <
f31a9740 4037133064 C Bi:2:071:1 0 13 = 55534253 0e00 00
f31a9740 4037133100 S Bo:2:071:1 -115 31 = 55534243 0f00 0010
8a28 ed29 0008 00
f31a9740 4037133176 C Bo:2:071:1 0 31 >
f4a552c0 4037133184 S Bi:2:071:1 -115 4096 <
f4a552c0 4037184441 C Bi:2:071:1 0 4096 =
f31a9740 4037184453 S Bi:2:071:1 -115 13 <
f31a9740 4037190564 C Bi:2:071:1 0 13 = 55534253 0f00 00
Thanks,
victor
--
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: Linux USB file storage gadget with new UDC
Hi, >> Here is the fresh usbmon trace. Four SCSI commands are shown. The >> first SCSI_READ_10 command has LBA of 0. The second SCSI_READ_10 >> command has LBA of 0x00ed2900, which is wrong. Somehow, the first >> SCSI_READ_10 command got the wrong data, i think. Isn't it? > > It looks like the data is wrong, but I have no way of knowing what the > data actually should be. Only you know that. > >> f31a9740 4037054141 S Bo:2:071:1 -115 31 = 55534243 0c00 0010 >> 8a28 0008 00 >> f31a9740 4037054176 C Bo:2:071:1 0 31 > >> f4a555c0 4037054184 S Bi:2:071:1 -115 4096 < >> f4a555c0 4037108430 C Bi:2:071:1 0 4096 = eb58904d 53444f53 352e3000 >> 02402e11 0200 00f8 3f00ff00 0020 > > Is this different from what you have in the first 32 bytes of your > backing file? If it is then your UDC driver is not sending the correct > buffer data to the host. The first 32 bytes data is correct. It is the first 32 bytes content of the FAT boot record. I observed further, when first SCSI_READ_10 command is sent with LBA of zero, and the file_offset_tmp of vfs_read() in do_read() is passed in as 0. It reaches SD driver with argument of 0x2002, . Somehow, the address got passed wrongly in the processing of it. In this case, 0x2000 is the FAT boot sector. Shouldn't gadget driver read from MBR (master boot record) as LBA of zero corresponds to MBR? Thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> > It looks like the data is wrong, but I have no way of knowing what the >> > data actually should be. Only you know that. >> > >> >> f31a9740 4037054141 S Bo:2:071:1 -115 31 = 55534243 0c00 0010 >> >> 8a28 0008 00 >> >> f31a9740 4037054176 C Bo:2:071:1 0 31 > >> >> f4a555c0 4037054184 S Bi:2:071:1 -115 4096 < >> >> f4a555c0 4037108430 C Bi:2:071:1 0 4096 = eb58904d 53444f53 352e3000 >> >> 02402e11 0200 00f8 3f00ff00 0020 >> > >> > Is this different from what you have in the first 32 bytes of your >> > backing file? If it is then your UDC driver is not sending the correct >> > buffer data to the host. >> >> The first 32 bytes data is correct. It is the first 32 bytes content >> of the FAT boot record. I observed further, when first SCSI_READ_10 >> command is sent with LBA of zero, and the file_offset_tmp of >> vfs_read() in do_read() is passed in as 0. It reaches SD driver with >> argument of 0x2002, . Somehow, the address got passed wrongly in the >> processing of it. In this case, 0x2000 is the FAT boot sector. >> Shouldn't gadget driver read from MBR (master boot record) as LBA of >> zero corresponds to MBR? > > The gadget driver reads from whatever you tell it to read. When you > load g-file-storage, what parameters do you put in the modprobe > command? > > Alan Stern > the parameter is file=/dev/mmcblk0p1 Thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi,
>>> > It looks like the data is wrong, but I have no way of knowing what the
>>> > data actually should be. Only you know that.
>>> >
>>> >> f31a9740 4037054141 S Bo:2:071:1 -115 31 = 55534243 0c00 0010
>>> >> 8a28 0008 00
>>> >> f31a9740 4037054176 C Bo:2:071:1 0 31 >
>>> >> f4a555c0 4037054184 S Bi:2:071:1 -115 4096 <
>>> >> f4a555c0 4037108430 C Bi:2:071:1 0 4096 = eb58904d 53444f53 352e3000
>>> >> 02402e11 0200 00f8 3f00ff00 0020
>>> >
>>> > Is this different from what you have in the first 32 bytes of your
>>> > backing file? If it is then your UDC driver is not sending the correct
>>> > buffer data to the host.
>>>
>>> The first 32 bytes data is correct. It is the first 32 bytes content
>>> of the FAT boot record. I observed further, when first SCSI_READ_10
>>> command is sent with LBA of zero, and the file_offset_tmp of
>>> vfs_read() in do_read() is passed in as 0. It reaches SD driver with
>>> argument of 0x2002, . Somehow, the address got passed wrongly in the
>>> processing of it. In this case, 0x2000 is the FAT boot sector.
>>> Shouldn't gadget driver read from MBR (master boot record) as LBA of
>>> zero corresponds to MBR?
>>
>> The gadget driver reads from whatever you tell it to read. When you
>> load g-file-storage, what parameters do you put in the modprobe
>> command?
>>
>> Alan Stern
>>
>
> the parameter is file=/dev/mmcblk0p1
I see a problem here. The first 32 bytes of the boot sector is
correct. The rest of the bytes are , which is wrong. See the
usbmon trace below.
f59e13c0 2704842730 S Bo:2:007:1 -115 31 = 55534243 2100 0080
8a28 0020 0040 00
f59e13c0 2704842836 C Bo:2:007:1 0 31 >
f319db40 2704842846 S Bi:2:007:1 -115 4096 <
f59e16c0 2704842848 S Bi:2:007:1 -115 4096 <
f59e14c0 2704842850 S Bi:2:007:1 -115 4096 <
f59e1240 2704842851 S Bi:2:007:1 -115 4096 <
f59e15c0 2704842852 S Bi:2:007:1 -115 4096 <
f59e1340 2704842853 S Bi:2:007:1 -115 4096 <
f59e12c0 2704842854 S Bi:2:007:1 -115 4096 <
f59e1540 2704842855 S Bi:2:007:1 -115 4096 <
f319db40 2705432226 C Bi:2:007:1 0 4096 = e52d424f 4f542020 42494e20
1886fc80 7c417c41 838a 7b410300 94b80200
f59e16c0 2705432230 C Bi:2:007:1 0 4096 =
f59e14c0 2705432231 C Bi:2:007:1 0 4096 =
f59e1240 2705432231 C Bi:2:007:1 0 4096 =
f59e15c0 2705432232 C Bi:2:007:1 0 4096 =
f59e1340 2705432233 C Bi:2:007:1 0 4096 =
f59e12c0 2705432234 C Bi:2:007:1 0 4096 =
f59e1540 2705432234 C Bi:2:007:1 0 4096 =
f59e13c0 2705432244 S Bi:2:007:1 -115 13 <
f59e13c0 2705438346 C Bi:2:007:1 0 13 = 55534253 2100 00
Thanks,
victor
--
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: Linux USB file storage gadget with new UDC
Hi, >> > the parameter is file=/dev/mmcblk0p1 > > Perhaps you have already realized this... mmcblk0p1 is the first > partition of the mmcblk0 device. Block 0 of the partition is the boot > sector, not the MBR. The MBR is block 0 of the mmcblk0 device. So > perhaps you really meant to use: > > file=/dev/mmcblk0 > >> I see a problem here. The first 32 bytes of the boot sector is >> correct. The rest of the bytes are , which is wrong. See the >> usbmon trace below. >> > > Are you certain this is wrong? All those 0's could be unoccupied > entries in a FAT. For testing purpose, i would like to create a backing file, and then use it with g_file_storage, such as below: # modprobe g_file_storage file=/tmp/backing_file Can i use an ordinary text file as the backing file? Thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >>> > the parameter is file=/dev/mmcblk0p1 >> >> Perhaps you have already realized this... mmcblk0p1 is the first >> partition of the mmcblk0 device. Block 0 of the partition is the boot >> sector, not the MBR. The MBR is block 0 of the mmcblk0 device. So >> perhaps you really meant to use: >> >> file=/dev/mmcblk0 >> >>> I see a problem here. The first 32 bytes of the boot sector is >>> correct. The rest of the bytes are , which is wrong. See the >>> usbmon trace below. >>> >> >> Are you certain this is wrong? All those 0's could be unoccupied >> entries in a FAT. > > For testing purpose, i would like to create a backing file, and then > use it with g_file_storage, such as below: > > # modprobe g_file_storage file=/tmp/backing_file > > Can i use an ordinary text file as the backing file? I find a link which contains answers to my question above. http://www.linux-usb.org/gadget/file_storage.html Thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, > the parameter is file=/dev/mmcblk0p1 >>> >>> Perhaps you have already realized this... mmcblk0p1 is the first >>> partition of the mmcblk0 device. Block 0 of the partition is the boot >>> sector, not the MBR. The MBR is block 0 of the mmcblk0 device. So >>> perhaps you really meant to use: >>> >>> file=/dev/mmcblk0 >>> I see a problem here. The first 32 bytes of the boot sector is correct. The rest of the bytes are , which is wrong. See the usbmon trace below. >>> >>> Are you certain this is wrong? All those 0's could be unoccupied >>> entries in a FAT. >> >> For testing purpose, i would like to create a backing file, and then >> use it with g_file_storage, such as below: >> >> # modprobe g_file_storage file=/tmp/backing_file >> >> Can i use an ordinary text file as the backing file? > > I find a link which contains answers to my question above. > > http://www.linux-usb.org/gadget/file_storage.html > Now i insmod g_file_storage gadget with file=/mnt/sd/backing_file, the SCSI_READ_10 command is still not working properly. See the gadget log below. The g_file_storage gadget receives "SCSI command: Unknown xa1" from the Linux host near the end of the log. Something is wrong. Thanks, victor g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 12 00 g_file_storage gadget: get device descriptor g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 20 00 g_file_storage gadget: get configuration descriptor g_file_storage gadget: ep0-in, length 32: : 09 02 20 00 01 01 04 c0 01 09 04 00 00 02 08 06 0010: 50 05 07 05 81 02 00 02 00 07 05 01 02 00 02 01 g_file_storage gadget: ep0-setup, length 8: : 00 09 01 00 00 00 00 00 g_file_storage gadget: set configuration 0010: 00 00 00 24 00 00 00 00 00 00 00 00 07 00 00 g_file_storage gadget: reset config g_file_storage gadget: reset interface g_file_storage gadget: set interface 0 g_file_storage gadget: high-speed config #1 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 02 00 00 00 00 00 00 00 00 00 06 00 0010: 00 00 00 00 00 00 00 00 00 00 00 00 07 00 00 g_file_storage gadget: SCSI command: TEST UNIT READY; Dc=6, Dn=0; Hc=6, Hn=0 attention condition g_file_storage gadget: sending command-failure status g_file_storage gadget: sense data: SK x06, ASC x29, ASCQ x00; info x0 g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 02 00 00 00 00 00 00 00 01 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 03 00 00 00 12 00 00 00 80 00 06 03 0010: 00 00 00 12 00 00 00 00 00 00 00 00 74 f9 02 g_file_storage gadget: SCSI command: REQUEST SENSE; Dc=6, Di=18; Hc=6, Hi=18 g_file_storage gadget: bulk-in, length 18: : 70 00 06 00 00 00 00 0a 00 00 00 00 29 00 00 00 0010: 00 00 g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 03 00 00 00 00 00 00 00 00 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 04 00 00 00 00 00 00 00 00 00 06 00 0010: 00 00 00 00 00 00 00 00 00 00 00 00 74 f9 02 g_file_storage gadget: SCSI command: TEST UNIT READY; Dc=6, Dn=0; Hc=6, Hn=0 g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 04 00 00 00 00 00 00 00 00 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 05 00 00 00 24 00 00 00 80 00 06 12 0010: 00 00 00 24 00 00 00 00 00 00 00 00 74 f9 02 g_file_storage gadget: SCSI command: INQUIRY; Dc=6, Di=36; Hc=6, Hi=36 g_file_storage gadget: bulk-in, length 36: : 00 00 02 02 1f 00 00 00 4c 69 6e 75 78 20 20 20 0010: 46 69 6c 65 2d 53 74 6f 72 20 47 61 64 67 65 74 0020: 30 33 33 33 g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 05 00 00 00 00 00 00 00 00 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 06 00 00 00 00 00 00 00 00 00 06 00 0010: 00 00 00 00 00 00 00 00 00 00 00 00 74 f9 02 g_file_storage gadget: SCSI command: TEST UNIT READY; Dc=6, Dn=0; Hc=6, Hn=0 g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 06 00 00 00 00 00 00 00 00 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 07 00 00 00 08 00 00 00 80 00 0a 25 0010: 00 00 00 00 00 00 00 00 00 00 00 00 74 f9 02 g_file_storage gadget: SCSI command: READ CAPACITY; Dc=10, Di=8; Hc=10, Hi=8 g_file_storage gadget: bulk-in, length 8: : 00 00 07 ff 00 00 02 00 g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 07 00 00 00 00 00 00 00 00 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 08 00 00 00 c0 00 00 00 80 00 06 1a 0010: 00 3f 00 c0 00 00 00 00 00 00 00 00 74 f9 02 g_file_storage gadget: SCSI command: MODE SENSE(6); Dc=6, Di=192; Hc=6, Hi=192 g_file_storage gadget: bulk-in, length 16: : 0f 00 00 00 08 0a 04 00 ff ff 00 00 ff ff ff ff g_file_storage gadget: bulk-in set halt g_file_storage
Re: Linux USB file storage gadget with new UDC
Hi, >> Now i insmod g_file_storage gadget with file=/mnt/sd/backing_file, the >> SCSI_READ_10 command is still not working properly. > > What makes you think that? Because the SCSI_READ_10 is able to read the MBR from the backing file, and after that, SCSI_READ_10 reads all zeroes (fails to read boot sector). >> g_file_storage gadget: ep0-setup, length 8: >> : 80 06 00 01 00 00 40 00 >> g_file_storage gadget: get device descriptor > > But something is definitely wrong here. Before sending this > Get-Device-Descriptor request, the host should have done a USB port > reset. Either the host isn't performing the reset correctly or else > your UDC driver didn't inform g_file_storage when the reset occurred. Yes, the UDC driver didn't inform g_file_storage when the reset occurred. What is to be done to inform g_file_storage when the reset occurs? Thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi,
>> Earlier, i used file=/dev/mmcblk0p1. Now i use
>> file=/mnt/sd/backing_file. This backing_file is a dummy file system
>> that i created. I attached two jpeg files. One show the MBR and Boot
>> Sector of the backing_file. Another shows the usbmon of the Linux Host
>
> Why did you send jpeg files? Plain text files are a lot easier to work
> with. Now I can't copy and paste the lines from your files into this
> email message. :-(
>
>> PC. I also attached the udc log which shows the MBR and Boot Sector
>> content which are read from the backing_file.
>
> The UDC log indicates that the MBR and boot sectors were read
> correctly.
>
>> From the usbmon jpeg,
>> that first SCSI_READ_10 command got a overflow error, the second
>> SCSI_READ_10 command got a connection reset error. Is the overflow
>> error occurred because the host PC cannot handle the data returned
>> from the gadget device?
>
> The usbmon log shows that the host sent the gadget a READ(10) command
> for 8 sectors, which 4096 bytes. It then requested a 4096-byte
> transfer on the bulk-in endpoint, expecting the gadget to reply with
> eight packets, each containing 512 bytes (because the bulk-in
> wMaxPacketSize is 512).
>
> But the gadget did not reply correctly. The UDC sent a data packet
> containing only 256 bytes, instead of 512 bytes. The overflow occurred
> when it sent a second data packet, again containing the wrong number of
> bytes.
>
>> > Call the gadget driver's ->reset handler. If the ->reset pointer is
>> > NULL, call the ->disconnect handler instead. See the code in
>> > net2280.c's handle_stat1_irqs() as an example.
>> >
>> > Alan Stern
>> >
>>
>> i read the net2280.c code. Is it the usb_reset() function, called by
>> stop_activity()? I am sorry if i understand incorrectly.
>
> No, it is the handle_stat1_irqs() function, as I wrote above. In
> particular, this part of the code, which handles both disconnects and
> resets:
>
> if (disconnect || reset) {
> stop_activity(dev, dev->driver);
> ep0_start(dev);
> spin_unlock(&dev->lock);
> if (reset && dev->driver->reset)
> (dev->driver->reset)(&dev->gadget);
> else
> (dev->driver->disconnect)(&dev->gadget);
> spin_lock(&dev->lock);
> return;
> }
>
I use kernel 3.4.4, the code in handle_stat1_irqs() is as below. There
is no reset or disconnect member function in "struct
usb_gadget_driver" in kernel 3.4.4.
if (stat & (1 << SUSPEND_REQUEST_INTERRUPT)) {
if (dev->driver->suspend)
dev->driver->suspend (&dev->gadget);
if (!enable_suspend)
stat &= ~(1 << SUSPEND_REQUEST_INTERRUPT);
} else {
if (dev->driver->resume)
dev->driver->resume (&dev->gadget);
/* at high speed, note erratum 0133 */
}
>> Another usbmon trace showing 3 SCSI_READ_10 command.
>
>This trace shows that the READ(10) commands worked correctly. Good.
>But it also shows that the gadget did not respond correctly to the 0xA1
>command near the end. The UDC was supposed to set the Halt feature
>for the bulk-in endpoint and send a STALL packet, but it didn't.
In gadget driver, when do_scsi_command() receives an unknown command,
the return value is -EINVAL. Will this value be returned to UDC
driver, so that UDC driver can set the Halt feature for the bulk-in
endpoint and send a STALL packet? For now, UDC driver does not set
Halt when unknown SCSI command is received.
Thanks,
victor
--
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: Linux USB file storage gadget with new UDC
Hi,
>> I use kernel 3.4.4, the code in handle_stat1_irqs() is as below. There
>> is no reset or disconnect member function in "struct
>> usb_gadget_driver" in kernel 3.4.4.
>>
>> if (stat & (1 << SUSPEND_REQUEST_INTERRUPT)) {
>> if (dev->driver->suspend)
>> dev->driver->suspend (&dev->gadget);
>> if (!enable_suspend)
>> stat &= ~(1 << SUSPEND_REQUEST_INTERRUPT);
>> } else {
>> if (dev->driver->resume)
>> dev->driver->resume (&dev->gadget);
>> /* at high speed, note erratum 0133 */
>> }
>
> Okay. I have a hard enough time remembering how the kernel works now;
> I can't afford to remember how it worked five releases ago. :-)
>
> In the 3.4 kernel, when either a reset or a disconnect occurs, the UDC
> driver should call the gadget driver's ->disconnect handler.
>
>> >> Another usbmon trace showing 3 SCSI_READ_10 command.
>> >
>> >This trace shows that the READ(10) commands worked correctly. Good.
>> >But it also shows that the gadget did not respond correctly to the 0xA1
>> >command near the end. The UDC was supposed to set the Halt feature
>> >for the bulk-in endpoint and send a STALL packet, but it didn't.
>>
>> In gadget driver, when do_scsi_command() receives an unknown command,
>> the return value is -EINVAL.
>
> No, the return value is 0. Read the last line of do_scsi_command():
>
> return 0;
>
>> Will this value be returned to UDC
>> driver, so that UDC driver can set the Halt feature for the bulk-in
>> endpoint and send a STALL packet? For now, UDC driver does not set
>> Halt when unknown SCSI command is received.
>
> Look at finish_reply(), near the end of the DATA_DIR_TO_HOST case:
>
> /*
> * For Bulk-only, mark the end of the data with a short
> * packet. If we are allowed to stall, halt the bulk-in
> * endpoint. (Note: This violates the Bulk-Only Transport
> * specification, which requires us to pad the data if we
> * don't halt the endpoint. Presumably nobody will mind.)
> */
> else {
> bh->inreq->zero = 1;
> start_transfer(fsg, fsg->bulk_in, bh->inreq,
> &bh->inreq_busy, &bh->state);
> fsg->next_buffhd_to_fill = bh->next;
> if (mod_data.can_stall)
> rc = halt_bulk_in_endpoint(fsg);
> }
>
> And read the fist line in halt_bulk_in_endpoint():
>
> rc = fsg_set_halt(fsg, fsg->bulk_in);
>
> And finally, read the last line of fsg_set_halt():
>
> return usb_ep_set_halt(ep);
>
> That's when your UDC is supposed to set the Halt feature -- when its
> usb_ep_set_halt() function is called. If the controller is busy at
> this time because the bulk-in buffer is full, and it is unable to set
> the Halt feature, then usb_ep_set_halt() should return -EAGAIN -- see
> the documentation for usb_ep_set_halt in include/linux/usb/gadget.h.
>
> Alan Stern
>
Thanks for the detailed write-up. I have checked the UDC driver
set_halt(), it is called by the gadget driver. The full ascii text of
usbmon trace for one usb session is also attached. This usbmon trace
shows a few EOVERFLOW(-75) error. I don't know why EOVERFLOW error
happened.
victor
scsi_read_10_again10.log
Description: Binary data
Re: Linux USB file storage gadget with new UDC
Hi,
>> Thanks for the detailed write-up. I have checked the UDC driver
>> set_halt(), it is called by the gadget driver. The full ascii text of
>> usbmon trace for one usb session is also attached. This usbmon trace
>> shows a few EOVERFLOW(-75) error. I don't know why EOVERFLOW error
>> happened.
>
> Because your UDC driver sent a packet that was too big. Here's the
> first example from the trace:
>
> f3a2b6c0 3633034189 S Bo:2:036:1 -115 31 = 55534243 0600
> 0600 00
> f3a2b6c0 3633034326 C Bo:2:036:1 0 31 >
> f3a2b6c0 3633034518 S Bi:2:036:1 -115 13 <
> f3a2b6c0 3633040328 C Bi:2:036:1 -75 0
>
> The first two lines show the host sending a TEST UNIT READY command.
> The third line shows the host waiting for a 13-byte CSW data packet.
> The -75 error means that the UDC sent back a data packet containing
> more than 13 bytes.
>
> Alan Stern
>
Thanks, i do not know why UDC sent back a data packet containing more
than 13 bytes in response to TEST UNIT READY command.
Here is another usbmon trace attached in this email. There are two
issues in this usbmon trace. Firstly, the CSW that is sent back in
response to SCSI_READ_10 is wrong (wrong tag).
f2c92340 2379075608 S Bo:2:047:1 -115 31 = 55534243 1100 0010
8a28 0008 00
f2c92340 2379075737 C Bo:2:047:1 0 31 >
f2c92ac0 2379075746 S Bi:2:047:1 -115 4096 <
f2c92ac0 2382204478 C Bi:2:047:1 0 4096 =
f2c92340 2382204489 S Bi:2:047:1 -115 13 <
f2c92340 2382210596 C Bi:2:047:1 0 13 = 55534253 1000 00
Secondly, this CSW shows remote I/O error (-121).
f2c92340 2382422538 S Bo:2:047:1 -115 31 = 55534243 1200 0010
8a28 0008 00
f2c92340 2382422588 C Bo:2:047:1 0 31 >
f3a2b5c0 2382422596 S Bi:2:047:1 -115 4096 <
f3a2b5c0 2382448965 C Bi:2:047:1 -121 13 = 55534253 1200 0010 01
f2c92340 2382448977 S Bi:2:047:1 -115 13 <
I am lost. Every time i connect Linux host to the USB gadget,
different error scenario is shown in usbmon.
victor
scsi_read_10_again11.log
Description: Binary data
Re: Linux USB file storage gadget with new UDC
Hi, >> Thanks, i print out additional information in gadget driver and UDC >> driver. Here are another problem. In usbmon trace, the time difference >> between first SCSI_INQUIRY command and the second TEST_UNIT_READY >> command is large. So i check the driver log file. When SCSI_INQUIRY is >> received, start_transfer() is called, then UDC ep_queue function is >> called, then bulk_out_complete() is called. This sequence is repeated >> many times. > > In fact, this problem starts even _before_ the INQUIRY command is > received. The log shows that the UDC driver calls the > bulk_out_complete routine over and over, even though no packet was > received and ka2000_ack_irq didn't run. The same thing happens after > the INQUIRY is received. > > The UDC driver is not supposed to call bulk_out_complete until a > transfer has completed. > > After the gadget was reset, the problem didn't occur any more. > >> What is the reason that SCSI_INQUIRY is not processed by >> gadget driver? Is it due to some problem in UDC driver? > > The INQUIRY _was_ processed by the gadget driver. Yes, the UDC driver > has a problem; see above. > >> After that, i can see when the unknown command 0xa1 is received, the >> UDC driver sets the Halt feature. > > Look at line 1339 of the UDC log file: > >> g_file_storage gadget: SCSI command: MODE SENSE(6); Dc=6, Di=192; Hc=6, >> Hi=192 >> g_file_storage gadget: bulk-in, length 16: >> : 0f 00 00 00 08 0a 04 00 ff ff 00 00 ff ff ff ff >> [start_transfer] f 40a08 >> ept1 in queue len 0x10, buffer 0xc12ac000 >> 0: 0xf >> 4: 0x40a08 >> 8: 0x >> c: 0x >> ka2000_ack_irq(32) >> bulk_in_complete --> 0, 16/16 > > At this point the gadget driver tries to do a set-halt: > >> g_file_storage gadget: bulk-in set halt >> kagen2_set_halt 1 1 > > When the Halt feature is set, the UDC is supposed to send a STALL > packet to the host -- but it did not. Instead it sent this 13-byte > bulk-IN packet. > >> g_file_storage gadget: bulk-in, length 13: >> : 55 53 42 53 08 00 00 00 b0 00 00 00 00 >> [start_transfer] 53425355 8 >> ept1 in queue len 0xd, buffer 0xc133c000 >> 0: 0x53425355 >> 4: 0x8 >> 8: 0xb0 >> bulk_in_complete --> 0, 13/13 > > The same thing happened when the 0xA1 command was received: > >> g_file_storage gadget: SCSI command: Unknown xa1; Dc=12, Du=0; Hc=12, >> Hi=512 >> g_file_storage gadget: bulk-in, length 0: >> [start_transfer] 43425355 12 >> ept1 in queue len 0x0, buffer 0xc12ac000 >> g_file_storage gadget: bulk-in set halt >> kagen2_set_halt 1 1 > > Right here, a STALL packet should have been sent. It wasn't. > >> g_file_storage gadget: sending command-failure status >> g_file_storage gadget: sense data: SK x05, ASC x20, ASCQ x00; info x0 >> g_file_storage gadget: bulk-in, length 13: >> : 55 53 42 53 12 00 00 00 00 02 00 00 01 >> [start_transfer] 53425355 12 >> ept1 in queue len 0xd, buffer 0xc133c000 >> 0: 0x53425355 >> 4: 0x12 >> 8: 0x200 >> bulk_in_complete --> 0, 13/13 > > Instead this packet was sent. > > Alan Stern Thanks! This packet is the CSW to the unknown SCSI command 0xa1. So it should not be sent at all, and the UDC driver should send the STALL packet instead of this CSW? Just curious, after this 0xa1 is received and bulk-in endpoint is halted. The Linux host tries to send TEST_UNIT_READY command, and UDC driver could not receive it because endpoint is halted and in reset condition. Seems like the set Halt feature is working (but STALL packet is not sent). victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> Here are another problem. In usbmon trace, the time difference >> between first SCSI_INQUIRY command and the second TEST_UNIT_READY >> command is large. So i check the driver log file. When SCSI_INQUIRY is >> received, start_transfer() is called, then UDC ep_queue function is >> called, then bulk_out_complete() is called. This sequence is repeated >> many times. >In fact, this problem starts even _before_ the INQUIRY command is >received. The log shows that the UDC driver calls the >bulk_out_complete routine over and over, even though no packet was >received and ka2000_ack_irq didn't run. The same thing happens after >the INQUIRY is received. >The UDC driver is not supposed to call bulk_out_complete until a >transfer has completed. >After the gadget was reset, the problem didn't occur any more. Looking at the log, the UDC driver queue function is called repeatedly by start_transfer() before SCSI_INQUIRY is received. Is this ok? [start_transfer] ebfe e5943010 ept1 out queue len 0x200, buffer 0xc133c000 bulk_out_complete --> 0, 0/31 >> Thanks! This packet is the CSW to the unknown SCSI command 0xa1. So it >> should not be sent at all, and the UDC driver should send the STALL >> packet instead of this CSW? > > No. As long as the Halt feature is set for the bulk-in endpoint, the > UDC should send STALL packets. When the host clears the Halt feature, > then the UDC should send the CSW packet. > >> Just curious, after this 0xa1 is received and bulk-in endpoint is >> halted. The Linux host tries to send TEST_UNIT_READY command, and UDC >> driver could not receive it because endpoint is halted and in reset >> condition. > > That sounds very wrong. The bulk-IN endpoint was halted, but the TEST > UNIT READY command is sent to the bulk-OUT endpoint. There should be > no problem receiving it. When debugging the UDC driver halt problem, i disable setting the halt feature for bulk-in endpoint and does not call fsg_disconnect() when reset interrupt occurs. Now when unknown SCSI command 0xa1 is received, the usbmon trace still shows the same error, and subsequent TEST_UNIT_READY is not received by UDC driver, and (-104) is connection reset error. It seems that UDC and gadget driver somehow still reset the USB connection? Driver has to reset the USB connection when unknown SCSI command is received? f3a2b7c0 486132750 S Bo:2:060:1 -115 31 = 55534243 1200 0002 8ca1 082e0001 ec00 00 f3a2b7c0 486132805 C Bo:2:060:1 0 31 > f2c92340 486132814 S Bi:2:060:1 -115 512 < f2c92340 486236946 C Bi:2:060:1 -121 13 = 55534253 1200 0002 01 f3a2b7c0 486237000 S Bi:2:060:1 -115 13 < f3a2b7c0 493408020 C Bi:2:060:1 -104 0 . f3a2b7c0 493652682 S Bo:2:060:1 -115 31 = 55534243 1300 0600 00 f3a2b7c0 493652755 C Bo:2:060:1 0 31 > f3a2b7c0 493652761 S Bi:2:060:1 -115 13 < f3a2b7c0 503652077 C Bi:2:060:1 -104 0 Thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> >In fact, this problem starts even _before_ the INQUIRY command is >> >received. The log shows that the UDC driver calls the >> >bulk_out_complete routine over and over, even though no packet was >> >received and ka2000_ack_irq didn't run. The same thing happens after >> >the INQUIRY is received. >> >The UDC driver is not supposed to call bulk_out_complete until a >> >transfer has completed. >> >After the gadget was reset, the problem didn't occur any more. >> >> Looking at the log, the UDC driver queue function is called repeatedly >> by start_transfer() before SCSI_INQUIRY is received. Is this ok? >> >> [start_transfer] ebfe e5943010 >> ept1 out queue len 0x200, buffer 0xc133c000 >> bulk_out_complete --> 0, 0/31 > > This is not a good question. You don't have to worry about > start_transfer; it is part of file_storage.c and it works correctly. > > The problem is: Why does bulk_out_complete get called so many times? > The UDC driver should not call bulk_out_complete if no bulk-out packets > have been received. > >> When debugging the UDC driver halt problem, i disable setting the halt >> feature for bulk-in endpoint and does not call fsg_disconnect() when >> reset interrupt occurs. > > Why are you disabling this? You should fix it, not disable it. > >> Now when unknown SCSI command 0xa1 is >> received, the usbmon trace still shows the same error, and subsequent >> TEST_UNIT_READY is not received by UDC driver, and (-104) is >> connection reset error. It seems that UDC and gadget driver somehow >> still reset the USB connection? Driver has to reset the USB connection >> when unknown SCSI command is received? > > The reset is done by the host, not by the UDC or the gadget driver. > > I don't know why the subsequent TEST UNIT READY was not received. I > can't tell what is happening inside the gadget and UDC just by reading > the usbmon log (which was recorded on the host). >From the usbmon trace and driver log, i can only see that TEST UNIT READY command is sent out but UDC driver does not receive it. May i ask, under what circumstances, is gadget driver calling start_transfer() to schedule reading from bulk-out endpoint ? Thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> From the usbmon trace and driver log, i can only see that TEST UNIT >> READY command is sent out but UDC driver does not receive it. May i >> ask, under what circumstances, is gadget driver calling >> start_transfer() to schedule reading from bulk-out endpoint ? > > file_storage.c calls start_transfer() whenever it expects the host to > send a bulk-out packet. These times include: > > When the gadget is waiting for the host to send a CBW packet > containing a SCSI command; I think the get_next_command() calls start_transfer() to read the next CBW. After unknown command 0xa1 is received, and if UDC driver doesn't halt the endpoint, why the get_next_command() does not call start_transfer() to read the next CBW? Somehow, i don't understand. Thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> I think the get_next_command() calls start_transfer() to read the next >> CBW. After unknown command 0xa1 is received, and if UDC driver doesn't >> halt the endpoint, why the get_next_command() does not call >> start_transfer() to read the next CBW? Somehow, i don't understand. > > I think that the previous call to start_transfer() never returned. > Probably because the usb_ep_queue() routine got hung up. Therefore > get_next_command() wasn't executed. > > Here's an extract from the log you posted, showing the 0xa1 command: > >> [start_transfer] f 40a08 >> ept1 out queue len 0x200, buffer 0xc12ac000 >> g_file_storage gadget: bulk-out, length 31: >> : 55 53 42 43 12 00 00 00 00 02 00 00 80 00 0c a1 >> 0010: 08 2e 00 01 00 00 00 00 ec 00 00 00 f8 9e 34 >> bulk_out_complete --> 0, 31/31 >> g_file_storage gadget: SCSI command: Unknown xa1; Dc=12, Du=0; Hc=12, >> Hi=512 >> g_file_storage gadget: bulk-in, length 0: >> [start_transfer] 43425355 12 >> ept1 in queue len 0x0, buffer 0xc12ac000 >> g_file_storage gadget: bulk-in set halt I think here is the problem: the bulk-in of length 0. This zero length packet is never sent out nor received by the host. What is this zero length packet? >> kagen2_set_halt 1 1 >> g_file_storage gadget: sending command-failure status >> g_file_storage gadget: sense data: SK x05, ASC x20, ASCQ x00; info x0 >> g_file_storage gadget: bulk-in, length 13: >> : 55 53 42 53 12 00 00 00 00 02 00 00 01 >> [start_transfer] 53425355 12 >> ept1 in queue len 0xd, buffer 0xc133c000 >> 0: 0x53425355 >> 4: 0x12 >> 8: 0x200 In comparison, the CSW is sent out and received by the host. > It looks like the UDC driver get hung up right here, somewhere inside > the usb_ep_queue() routine. I think the usb_ep_queue() routine is re-entrant. If one instance of it hangs, the next instance will not be affected. > At this point, the host got tired of waiting for the gadget to accept > the next CBW, so it issued a port reset. Yes, i fully agree! Thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> >> g_file_storage gadget: SCSI command: Unknown xa1; Dc=12, Du=0; Hc=12, >> >> Hi=512 >> >> g_file_storage gadget: bulk-in, length 0: >> >> [start_transfer] 43425355 12 >> >> ept1 in queue len 0x0, buffer 0xc12ac000 >> >> g_file_storage gadget: bulk-in set halt >> >> I think here is the problem: the bulk-in of length 0. This zero >> length packet is never sent out nor received by the host. What is this >> zero length packet? > > A data packet has three parts: > > a Packet ID (PID) byte, which is either DATA0 or DATA1 for > bulk transfers; > > some variable number N of data bytes; > > two Cyclic Redundancy Check (CRC) bytes. > > A zero-length data packet is one in which N = 0. Such packets contain > exactly three bytes: a PID and two CRC bytes. See Sections 8.3 and > 8.4.4 of the USB-2.0 specification. I modified the UDC driver to send out zero length data packet. Now the linux host is able to see the USB gadget as a mass storage device and read from USB gadget. However, writing to USB gadget fails. The SCSI_WRITE_10 command often receives (-104). The usbmon trace showing this failure is attached. Is the bulk-out endpoint unable to receive command and data continuously, due to error in UDC driver? Also, as in UDC driver log, sometimes the same SCSI_READ_10 command is received repeatedly. It is strange behavior. Thanks, victor g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 0a 01 00 00 00 02 00 00 80 00 0a 28 0010: 00 00 00 20 00 00 00 01 00 00 00 00 f8 9e 33 g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=512; Hc=10, Hi=512 g_file_storage gadget-lun0: file read 512 @ 4194304 -> 512 g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 0a 01 00 00 00 00 00 00 00 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 0a 01 00 00 00 02 00 00 80 00 0a 28 0010: 00 00 00 20 00 00 00 01 00 00 00 00 f8 9e 33 g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=512; Hc=10, Hi=512 g_file_storage gadget-lun0: file read 512 @ 4194304 -> 512 g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 0a 01 00 00 00 00 00 00 00 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 0a 01 00 00 00 02 00 00 80 00 0a 28 0010: 00 00 00 20 00 00 00 01 00 00 00 00 f8 9e 330: 0x53425355 g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=512; Hc=10, Hi=512 g_file_storage gadget-lun0: file read 512 @ 4194304 -> 5124: 0x2020544f g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 0a 01 00 00 00 00 00 00 00 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 0a 01 00 00 00 02 00 00 80 00 0a 28 0010: 00 00 00 20 00 00 00 01 00 00 00 00 f8 9e 33 g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=512; Hc=10, Hi=512 g_file_storage gadget-lun0: file read 512 @ 4194304 -> 512 g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 0a 01 00 00 00 00 00 00 00 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 0a 01 00 00 00 02 00 00 80 00 0a 28 0010: 00 00 00 20 00 00 00 01 00 00 00 00 f8 9e 33 g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=512; Hc=10, Hi=512 g_file_storage gadget-lun0: file read 512 @ 4194304 -> 512 g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 0a 01 00 00 00 00 00 00 00 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 0a 01 00 00 00 02 00 00 80 00 0a 28 0010: 00 00 00 20 00 00 00 01 00 00 00 00 f8 9e 33 g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=512; Hc=10, Hi=512 g_file_storage gadget-lun0: file read 512 @ 4194304 -> 5120: 0x53425355 g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 0a 01 00 00 00 00 00 00 00 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 0a 01 00 00 00 02 00 00 80 00 0a 28 0010: 00 00 00 20 00 00 00 01 00 00 00 00 f8 9e 33 g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=512; Hc=10, Hi=512 g_file_storage gadget-lun0: file read 512 @ 4194304 -> 512 g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 0a 01 00 00 00 00 00 00 00 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 0a 01 00 00 00 02 00 00 80 00 0a 28 0010: 00 00 00 20 00 00 00 01 00 00 00 00 f8 9e 33 g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=512; Hc=10, Hi=512 g_file_storage gadget-lun0: file read 512 @ 4194304 -> 512 g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 0a 01 00 00 00 00 00 00 00 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 0a 01 00 00 00 02 00 00 80 00 0a 28 0010: 00 00 00 20 00 00 00 01 00 00 00 00 f8 9e 33 g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=512; Hc=10, Hi=512 g_file_storage gadget-lun0: file read 512 @ 4194304 -> 512 g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 0a 01 00 00 00 00 00 00 00 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 0a 01 00 00 00 02 00
Re: Linux USB file storage gadget with new UDC
Hi, >> I modified the UDC driver to send out zero length data packet. Now the >> linux host is able to see the USB gadget as a mass storage device and >> read from USB gadget. However, writing to USB gadget fails. The >> SCSI_WRITE_10 command often receives (-104). The usbmon trace showing >> this failure is attached. Is the bulk-out endpoint unable to receive >> command and data continuously, due to error in UDC driver? > > It looks like the data gets received okay. I can't tell what's going > wrong because you did not post the gadget log showing the WRITE > commands. When writing to USB gadget from Linux host, the SCSI_WRITE_10 command is sent out from the Linux host, but the USB gadget receives zero length packet. And after a long wait of 30 seconds, the Linux host resets the connection (-104). The usbmon trace and the UDC driver log are attached. g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 I think UDC driver receives the zero length packet on bulk out endpoint. Thanks, victor # dmesg [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000<7>g_file_storage gadget: bulk_out_complete --> 0, 0/31 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: usbmon_write_gadget2.log Description: Binary data
Re: Linux USB file storage gadget with new UDC
Hi,
>> Here is a full log from the beginning which shows another problem.
>> When the SCSI_READ_10 command below is received, there is a disconnect
>> or port reset which causes the (-32) broken pipe problem.
>
> You really need to fix the old problems before worrying about new
> problems. The set_halt still isn't working, and the UDC continues to
> continues to call bulk_out_complete multiple times without receiving
> any packets.
I change that in UDC driver queue function, adding in a length check:
if (len > 0)
{
ka_req->req.complete(&ka_ep->ep, &ka_req->req);
list_del_init(&ka_req->queue);
}
However, i still observe the SCSI command being received by UDC and
gadget driver, but not processed by gadget driver.
For the UDC and gadget driver log, it looks like the flow cannot get
past get_next_command() of fsg_main_thread(). The log is attached.
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
The same SCSI command as seen on usbmon log:
f2f4fe40 3842078083 S Bo:2:050:1 -115 31 = 55534243 0900
0600 00
f2f4fe40 3842078159 C Bo:2:050:1 0 31 >
f2f4fe40 3842078182 S Bi:2:050:1 -115 13 <
f2f4fe40 3872633965 C Bi:2:050:1 -104 0
> It would be easier to maintain a stable link if the UDC connected at
> high speed in the first place. The usbmon log shows that the
> connection was at full speed (12 Mb/s), not high speed (480 Mb/s) --
> which means that this line:
>
>> g_file_storage gadget: high-speed config #1
>
> in the gadget log indicates another bug in the UDC driver. It told the
> gadget driver that the connection was high speed, but the connection
> really was full speed.
How to read from usbmon log that the connection was at full speed?
Thanks,
victor
# dmesg
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 0
Re: Linux USB file storage gadget with new UDC
Hi,
>> I change that in UDC driver queue function, adding in a length check:
>>
>> if (len > 0)
>> {
>> ka_req->req.complete(&ka_ep->ep,
>> &ka_req->req);
>> list_del_init(&ka_req->queue);
>> }
>
> What is "len"? Is it the packet size? If it is then this check is
> wrong, because the UDC driver must accept zero-length packets.
Yes, it is packet size. So UDC driver must accept zero-length packets
sent from USB host?
> Just before the line that calls ka_req->req.complete, add:
>
> WARN_ON(!victor_test);
> victor_test = 0;
>
> Then you'll get a stack dump every time the completion routine is
> called without an interrupt occurring first. The stack dump will help
> you to figure out why this is going wrong and where the problem is.
This is the stack dump when the completion routine is called without
an interrupt occurring first, is it useful?
Backtrace:
[] (dump_backtrace+0x0/0x110) from [] (dump_stack+0x18/0x1c)
r6:bf030da8 r5:c12aec00 r4:c12b4c00 r3:00f8
[] (dump_stack+0x0/0x1c) from []
(kagen2_ep_queue+0x520/0x598 [kagen2_udc])
[] (kagen2_ep_queue+0x0/0x598 [kagen2_udc]) from
[] (fsg_lun_open+0x578/0x1278 [g_file_storage])
[] (fsg_lun_open+0x430/0x1278 [g_file_storage]) from
[] (fsg_main_thread+0x10c/0x155c [g_file_storage])
r8: r7:0001 r6:c12896c0 r5:c12896bc r4:c1289600
[] (fsg_main_thread+0x0/0x155c [g_file_storage]) from
[] (kthread+0x94/0xa0)
[] (kthread+0x0/0xa0) from [] (do_exit+0x0/0x6f0)
r6:c02191c8 r5:c022f860 r4:c1327e00
> Here's an example. This shows the port status immediately after the
> first port reset in the April 22 usbmon trace:
>
> f2f4f740 1985276053 S Ci:2:002:0 s a3 00 0004 0004 4 <
> f2f4f740 1985276154 C Ci:2:002:0 0 4 = 03011000
>
> The 01 in the second byte of the response indicates full speed. If
> the connection were high speed, the second byte would be 05. See
> Section 11.24.2.7 in the USB-2.0 specification, and especially the
> description of bit 10 in Table 11-21 and 11.24.2.7.1.8.
Thanks, i found the bit 10 in Table 11-21 Port Status Field.
0 = Full-speed device attached to this port.
1 = High-speed device attached to this port.
victor
--
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: Linux USB file storage gadget with new UDC
Hi, >> This is the stack dump when the completion routine is called without >> an interrupt occurring first, is it useful? >> >> Backtrace: >> [] (dump_backtrace+0x0/0x110) from [] >> (dump_stack+0x18/0x1c) >> r6:bf030da8 r5:c12aec00 r4:c12b4c00 r3:00f8 >> [] (dump_stack+0x0/0x1c) from [] >> (kagen2_ep_queue+0x520/0x598 [kagen2_udc]) >> [] (kagen2_ep_queue+0x0/0x598 [kagen2_udc]) from >> [] (fsg_lun_open+0x578/0x1278 [g_file_storage]) >> [] (fsg_lun_open+0x430/0x1278 [g_file_storage]) from >> [] (fsg_main_thread+0x10c/0x155c [g_file_storage]) >> r8: r7:0001 r6:c12896c0 r5:c12896bc r4:c1289600 >> [] (fsg_main_thread+0x0/0x155c [g_file_storage]) from >> [] (kthread+0x94/0xa0) >> [] (kthread+0x0/0xa0) from [] (do_exit+0x0/0x6f0) >> r6:c02191c8 r5:c022f860 r4:c1327e00 > > This shows that kagen2_ep_queue() calls kareq->req.complete. Perhaps > indirectly, through another function. If this is true then it's > probably a bug. You should check it out. Yes, the kagen2_ep_queue() calls req->req.complete directly. I thought this is necessary to pass the packets to gadget driver for processing? req->req.complete is mapped to bulk_out_complete() or bulk_in_complete(). thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> Yes, the kagen2_ep_queue() calls req->req.complete directly. I thought >> this is necessary to pass the packets to gadget driver for processing? > > It is necessary to call req.complete when the request has _completed_! > That's why the callback is named "complete"! > >> req->req.complete is mapped to bulk_out_complete() or >> bulk_in_complete(). > > A bulk-out request isn't complete until the data has been received from > the host. A bulk-in request isn't complete until the data has been > sent to the host (or at least copied into a hardware buffer). > > kagen2_ep_queue() gets called when the bulk-out request is submitted, > right? So the request is not complete at that time. It isn't complete > until the host has sent the data. After all, if you haven't received > the packets from the host yet, how can you pass the packets to the > gadget driver for processing? > > Alan Stern > For bulk out endpoint, I code the kagen2_ep_queue() to read the packets from the USB hardware, then call bulk_out_complete() via req->req.complete. Is this the correct way? Or i should only read the bulk out endpoint when bulk-out endpoint interrupt is received? thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi,
> While kagen2_ep_queue() is running, there shouldn't be any packets in
> the USB hardware. The hardware should refuse to accept any packets,
> sending NAKs back to the host, until a request has been submitted and
> queued.
>
> When the request is queued, that's when you should tell the hardware to
> accept data from the host. After that, each time a packet arrives from
> the host, either the hardware or the UDC driver should store the packet
> data in the request's buffer. When the buffer is full or a short
> packet is received (the UDC driver's interrupt handler will know when
> this happens) then the UDC driver should call req.complete.
Please see the attached kagen2_ep_queue(). As long as it is called, it
will queue the request and read packets from hardware, in the same
if-else branch for bulk out endpoint. The interrupt handler will NOT
accept packet if request is NOT queued. If request is queued,
interrupt handler will accept the packet.
Somehow, there is still timing problem in UDC driver and it is hard to
pin down the root cause. It could be due to interaction of UDC driver
queue() and gadget driver fsg_main_thread() main loop.
1) When writing to gen2 gadget, SCSI_READ_10 or or SCSI_REQUEST_SENSE
commands are received by UDC driver, but gadget did not process the
commands. (cannot get past get_next_command() in fsg_main_thread)
2) Repeatedly (many many times), the same SCSI_READ_10 command is
received by UDC driver, processed by gadget driver, and UDC driver
sends out data and CSW to host. On usbmon trace, only one instance of
the SCSI_READ_10 is observed.
3) More severe case, if removing one printk statement in
bulk_in_complete(), USB gadget device cannot be recognised by host.
Thanks,
victor
static int kagen2_ep_queue(struct usb_ep *ep,
struct usb_request *req, gfp_t gfp_flags)
{
struct kagen2_ep *ka_ep;
struct kagen2_request *ka_req;
struct kagen2 * dev;
unsigned phys;
int num, len, in;
ka_req = container_of(req, struct kagen2_request, req);
if (!req || !req->complete || !req->buf
|| !list_empty(&ka_req->queue))
{
printk("exit A\n");
return -EINVAL;
}
ka_ep = container_of(ep, struct kagen2_ep, ep);
if (!ep || (!ka_ep->desc && ka_ep->num != 0))
{
printk("exit B\n");
return -EINVAL;
}
dev = ka_ep->dev;
if (!dev || !dev->driver || dev->gadget.speed == USB_SPEED_UNKNOWN)
{
printk("exit C\n");
return -ESHUTDOWN;
}
num = ka_ep->desc->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK;
in = (ka_ep->desc->bEndpointAddress & USB_DIR_IN) != 0;
phys = (unsigned)req->buf;
len = req->length;
printk(KERN_DEBUG "ept%d %s queue len 0x%x, buffer 0x%x\n",
num, in ? "in" : "out", len, phys);
/* ep0 IN endpoint */
if ((len > 0) && (num == 0) && (in != 0))
{
req->actual = 0;
ep0_in(phys, len, dev);
req->actual += len;
req->complete(ep, req);
list_del_init(&ka_req->queue);
return 0;
}
/* ep1 IN endpoint */
else if ((len >= 0) && (num == 1) && (in != 0))
{
req->actual = 0;
ep1_in(phys, len, dev);
req->actual += len;
req->complete(ep, req);
list_del_init(&ka_req->queue);
return 0;
}
/* ep1 OUT endpoint */
else if (in == 0)
{
// read from EP1 OUT buffer
if (num == 1)
{
unsigned int val;
unsigned int val_arr[8];
int i;
// get byte count from hardware
val = readl(dev->base_addr + 0x008);
len = val & 0xFF;
// read from hardware fifo1 data
for (i = 0; i < len/4; i++)
{
val_arr[i] = readl(dev->base_addr + 0x084);
}
list_add_tail(&ka_req->queue, &ka_ep->queue);
ka_req->req.actual = len;
memcpy(ka_req->req.buf, &val_arr[0], len);
ka_req->req.complete(&ka_ep->ep, &ka_req->req);
list_del_init(&ka_req->queue);
// clear hardware OUT1CS register
val = readl(dev->base_addr + 0x008);
val &= 0x00ff;
writel(val, dev->base_addr + 0x008);
}
}
return 0;
}
Re: Linux USB file storage gadget with new UDC
Hi,
>> Please see the attached kagen2_ep_queue(). As long as it is called, it
>> will queue the request and read packets from hardware, in the same
>> if-else branch for bulk out endpoint. The interrupt handler will NOT
>> accept packet if request is NOT queued. If request is queued,
>> interrupt handler will accept the packet.
>
> This code is wrong. See what happens when a request for ep1-out is
> submitted:
>
>> /* ep1 OUT endpoint */
>> else if (in == 0)
>> {
>> // read from EP1 OUT buffer
>> if (num == 1)
>> {
>> unsigned int val;
>> unsigned int val_arr[8];
>> int i;
>>
>> // get byte count from hardware
>> val = readl(dev->base_addr + 0x008);
>> len = val & 0xFF;
>
> Why do you expect there to be any data in the hardware FIFO at this
> point? You said that the hardware will not accept any data if a
> request is not queued. Well, before this point the request wasn't
> queued, so there shouldn't be any data.
I am sorry for unclear writing. What i mean is: If a request is not
queued, the hardware will still accept data, but interrupt controller
will not read the data from the hardware FIFO.
>>
>> // read from hardware fifo1 data
>> for (i = 0; i < len/4; i++)
>> {
>> val_arr[i] = readl(dev->base_addr + 0x084);
>> }
>
> val_arr is declared as an array of 8 unsigned ints. That means its
> total size is 32 bytes. What happens if len > 32? You will end up
> overwriting part of the stack.
Yes! This is a bug. I only thought about the 31 byte CBW for bulk out
endpoint. I forgot about the SCSI_WRITE_10 command. Thanks!!
>> list_add_tail(&ka_req->queue, &ka_ep->queue);
>>
>> ka_req->req.actual = len;
>> memcpy(ka_req->req.buf, &val_arr[0], len);
>>
>> ka_req->req.complete(&ka_ep->ep, &ka_req->req);
>
> You should not call req.complete until the request really is complete.
> For example, what happens here if the host hasn't sent any packets yet?
> Or what happens if req is waiting to receive 1024 bytes but the host
> has sent only 512 bytes so far?
How the UDC driver know when the request is really complete?
> Also, all the data gets copied _twice_: once from the hardware FIFO
> into val_arr, and then again from val_arr into req.buf. That's a waste
> of time; the data should be copied directly from the FIFO into req.buf.
Agree.
>> 2) Repeatedly (many many times), the same SCSI_READ_10 command is
>> received by UDC driver, processed by gadget driver, and UDC driver
>> sends out data and CSW to host. On usbmon trace, only one instance of
>> the SCSI_READ_10 is observed.
>
> This is probably because you are copying the same data from the FIFO to
> req.buffer many times.
I am curious about it. After data is read from FIFO, the FIFO will
become empty. Still cannot figure out how the same data is read from
the FIFO many times.
Thanks,
victor
--
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: Linux USB file storage gadget with new UDC
Hi, >> How the UDC driver know when the request is really complete? > > An OUT request is really complete when either: > > The total number of bytes copied into req.buffer (i.e., > req.actual) is equal to req.length, or > > The number of bytes received in the last packet is smaller > than ep.maxpacket. I made some changes regarding req.actual. Now the UDC driver still cannot process SCSI_WRITE_10 command. Please see the attached UDC driver log when i try to write to a text file. There should be three SCSI commands in the log: SCSI_REQUEST_SENSE, SCSI_TEST_UNIT_READY and SCSI_WRITE_10. SCSI_WRITE_10 is not received properly. Thanks, victor g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 0d 01 00 00 12 00 00 00 80 00 06 03 0010: 00 00 00 12 00 00 00 00 00 00 00 00 c3 63 4a g_file_storage gadget: SCSI command: REQUEST SENSE; Dc=6, Di=18; Hc=6, Hi=18 g_file_storage gadget: bulk-in, length 18: : 70 00 06 00 00 00 00 0a 00 00 00 00 29 00 00 00 0010: 00 00 [start_transfer] 60070 a00 ept1 in queue len 0x12, buffer 0xc1344000 0: 0x60070 4: 0xa00 8: 0x0 c: 0x29 bulk_in_complete --> 0, 18/18 g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 0d 01 00 00 00 00 00 00 00 [start_transfer] 53425355 10d ept1 in queue len 0xd, buffer 0xc1304000 0: 0x53425355 4: 0x10d 8: 0x0 bulk_in_complete --> 0, 13/13 EP1 OUT IRQ 0x28 ep1_out: RX DMA done : NULL REQ on OUT EP-1 [start_transfer] 60070 a00 ept1 out queue len 0x200, buffer 0xc1344000 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 0e 01 00 00 00 00 00 00 00 00 06 00 0010: 00 00 00 00 00 00 00 00 00 00 00 00 c3 63 4a g_file_storage gadget: SCSI command: TEST UNIT READY; Dc=6, Dn=0; Hc=6, Hn=0 g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 0e 01 00 00 00 00 00 00 00 [start_transfer] 53425355 10e ept1 in queue len 0xd, buffer 0xc1344000 0: 0x53425355 4: 0x10e 8: 0x0 bulk_in_complete --> 0, 13/13 EP1 OUT IRQ 0x28 ep1_out: RX DMA done : NULL REQ on OUT EP-1 [start_transfer] 53425355 10d ept1 out queue len 0x200, buffer 0xc1304000 g_file_storage gadget: bulk-out, length 31: EP1 OUT IRQ 0x28 epnum 1 in 0 len 0 512 0 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 g_file_storage gadget: bulk_out_complete --> 0, 0/31 g_file_storage gadget: invalid CBW: len 0 sig 0x43425355 g_file_storage gadget: bulk-in set wedge g_file_storage gadget: get_next_command [start_transfer] 43425355 10f ept1 out queue len 0x200, buffer 0xc1304000
Re: Linux USB file storage gadget with new UDC
Hi, >> I made some changes regarding req.actual. Now the UDC driver still >> cannot process SCSI_WRITE_10 command. Please see the attached UDC >> driver log when i try to write to a text file. There should be three >> SCSI commands in the log: SCSI_REQUEST_SENSE, SCSI_TEST_UNIT_READY and >> SCSI_WRITE_10. SCSI_WRITE_10 is not received properly. > > No, it isn't. Here's what the log says: > >> EP1 OUT IRQ 0x28 >> ep1_out: RX DMA done : NULL REQ on OUT EP-1 >> [start_transfer] 53425355 10d >> ept1 out queue len 0x200, buffer 0xc1304000 >> g_file_storage gadget: bulk-out, length 31: > > This is from bulk_out_complete, when the WRITE(10) was received. > >> EP1 OUT IRQ 0x28 >> epnum 1 in 0 len 0 512 0 >> g_file_storage gadget: bulk-out, length 0: > > This line indicates a bug. It means the UDC driver called > bulk_out_complete again, even though the previous request was no longer > queued and no new requests had been submitted yet. > > It is likely that this bug occurs because you don't use a spinlock in > kagen2_ep_queue. Does the interrupt handler routine use a spinlock? Spinlock is Not used in interrupt handler routine. >[start_transfer] 53425355 10d >ept1 out queue len 0x200, buffer 0xc1304000 >g_file_storage gadget: bulk-out, length 31: Is the kagen2_ep_queue function gotten interrupted here? So the kagen2_ep_queue and interrupt routine need spinlock for synchronisation? >EP1 OUT IRQ 0x28 >epnum 1 in 0 len 0 512 0 >g_file_storage gadget: bulk-out, length 0: > Maybe you haven't noticed this, but the REQUEST SENSE and TEST UNIT > READY commands weren't received correctly either. The last three bytes > in each command should be 0, but they aren't. They are: c3 63 4a. > Where did those values come from? Yes, i haven't noticed the c3 63 4a. Clearly the last three bytes should be zero. Maybe the UDC driver has a bug (Do the last 3 bytes matter for file gadget? ). Here is the usbmon trace that corresponds to the UDC log. It is the proof that the last three bytes are zero. Thanks, victor scsi_write_10_again02.log Description: Binary data
Re: Linux USB file storage gadget with new UDC
Hi, >> > It is likely that this bug occurs because you don't use a spinlock in >> > kagen2_ep_queue. Does the interrupt handler routine use a spinlock? >> >> Spinlock is Not used in interrupt handler routine. > > Then that's the reason for this bug. > >> >[start_transfer] 53425355 10d >> >ept1 out queue len 0x200, buffer 0xc1304000 >> >g_file_storage gadget: bulk-out, length 31: >> >> Is the kagen2_ep_queue function gotten interrupted here? So the >> kagen2_ep_queue and interrupt routine need spinlock for >> synchronisation? > > That's right. Interrupts can occur at almost any time (on > multiprocessor systems they can occur even when interrupts are disabled > on some of the CPUs). I am confused. I add the spinlock functions to kagen2_ep_queue function. spin_lock_irqsave(&dev->lock, flags); .. spin_unlock_irqrestore(&dev->lock, flags); When kagen2_ep_queue function is called, the error "BUG: scheduling while atomic: swapper/0/0x0002" occurs. I test the same spinlock functions in other device module. It is ok in other device module. thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi,
>> > That's right. Interrupts can occur at almost any time (on
>> > multiprocessor systems they can occur even when interrupts are disabled
>> > on some of the CPUs).
>>
>> I am confused. I add the spinlock functions to kagen2_ep_queue function.
>>
>> spin_lock_irqsave(&dev->lock, flags);
>> ..
>> spin_unlock_irqrestore(&dev->lock, flags);
>>
>> When kagen2_ep_queue function is called, the error "BUG: scheduling
>> while atomic: swapper/0/0x0002" occurs. I test the same spinlock
>> functions in other device module. It is ok in other device module.
>
> While the function holds a spinlock, it is not allowed to sleep.
>
> The BUG occurs because kagen2_ep_queue must call some function that can
> sleep. But since you did not provide the rest of the BUG message
> (including the stack trace), I can't tell what function it calls.
The "BUG: scheduling while atomic" is solved. Need to add extra
spinlock functions for req->complete() as below:
spin_unlock(&dev->lock);
req->complete(ep, req);
spin_lock(&dev->lock);
Now, the SCSI_WRITE_10 command is received but the data is not
received. There is disconnect or port reset after SCSI_WRITE_10
command. Please see below:
[start_transfer] 613e2d71 61757463
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 f6 00 00 00 00 02 00 00 00 00 0a 2a
0010: 00 00 00 00 01 00 00 01 00 00 00 00 80 b7 21
EP1 OUT IRQ 0x28
g_file_storage gadget: disconnect or port reset
g_file_storage gadget: SCSI command: WRITE(10); Dc=10, Do=512; Hc=10, Ho=512
[start_transfer] 43425355 f6
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: do_scsi_command
unlink (ep1) pio
kagen2_set_halt 1 0
g_file_storage gadget: bulk-out, length 0:
g_file_storage gadget: bulk_out_complete --> 0, 0/512
g_file_storage gadget: reset config
g_file_storage gadget: reset interface
g_file_storage gadget: handle_exception
"g_file_storage gadget: do_scsi_command" is from extra DBG statement
that i added in file_storage.c.
if (do_scsi_command(fsg) || finish_reply(fsg))
{
DBG(fsg, "do_scsi_command\n");
continue;
}
thanks,
victor
--
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: Linux USB file storage gadget with new UDC
Hi, > Obviously this "disconnect or port reset" message is related to the > "EP1 OUT IRQ 0x28" line above. But why? It looks like another bug. > > I see you still haven't fixed the last three bytes in the bulk-out > transfer. Ok, i just fixed the last three bytes in the bulk-out transfer problem. Please see below for the log. Now the last three bytes are read correctly. After SCSI_WRITE_10 is received, the gadget driver prints "g_file_storage gadget: disconnect or port reset", it means USB reset interrupt is received by the UDC driver. I don't know why USB reset interrupt is triggered. [start_transfer] ept1 out queue len 0x200, buffer 0xc1298000 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 f5 00 00 00 00 02 00 00 00 00 0a 2a 0010: 00 00 00 00 01 00 00 01 00 00 00 00 00 00 00 g_file_storage gadget: SCSI command: WRITE(10); Dc=10, Do=512; Hc=10, Ho=512 [start_transfer] 43425355 f5 ept1 out queue len 0x200, buffer 0xc1298000 g_file_storage gadget: disconnect or port reset g_file_storage gadget: do_scsi_command unlink (ep1) pio kagen2_set_halt 1 0 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/512 g_file_storage gadget: reset config g_file_storage gadget: reset interface g_file_storage gadget: handle_exception g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 40 00 . Thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> Ok, i just fixed the last three bytes in the bulk-out transfer >> problem. Please see below for the log. Now the last three bytes are >> read correctly. After SCSI_WRITE_10 is received, the gadget driver >> prints "g_file_storage gadget: disconnect or port reset", it means USB >> reset interrupt is received by the UDC driver. I don't know why USB >> reset interrupt is triggered. > > Then you need to figure out why. Have you checked the dmesg log and > usbmon trace on the host? > > Incidentally, for debugging it will help if you enable > CONFIG_PRINTK_TIME in the gadget's kernel. Thanks, i will enable the CONFIG_PRINTK_TIME. Nonetheless, now the gadget driver and UDC driver are able to process some SCSI_WRITE_10 commands (i ignore the USB reset interrupt in UDC driver). Please see the attached usbmon log. Will the log help? Thanks, victor scsi_write_10_again04.log Description: Binary data
Re: Linux USB file storage gadget with new UDC
Hi, > All I can tell is that the gadget got hung after receiving the second > WRITE command. Can you figure out where it got hung and why? > > Victor, you don't seem to get the big pattern that keeps repeating > here. Every time something does wrong, you tell me about it. Then I > point out that you didn't include any debugging information, so you > send part of a log. Then I point out that you didn't send the entire > log, or you didn't send logs for both the gadget and the host. You end > up losing a day or two each time this happens. > > There's a very simple lesson: When you're asking for help in debugging > a problem, _always_ include _all_ the data that might be relevant. > > Here's another lesson, which I have pointed out a few times before but > you still don't seem to have understood: When you want to know where > your driver is hanging up, put a bunch of printk statements in it, at > all the important spots. Then you'll be able to see, in the log, the > last printk that was executed before the hang. That will tell you > where the problem is. Thanks. I will add more printk statements gradually. Now i discover if i write to a large text file (> 48k) on USB gadget, linux will crash. The full log of UDC and gadget driver when linux crashes, and corresponding usbmon trace are attached. If these logs are not helpful, i shall add more printk. thanks, victor bulk_in_complete --> 0, 13/13 bulk_in_complete --> 0, 13/13 EP1 OUT IRQ 0x28 ep1_out: RX DMA done : NULL REQ on OUT EP-1 Unable to handle kernel paging request at virtual address 4000 pgd = c0204000 [4000] *pgd= Internal error: Oops - BUG: 817 [#1] PREEMPT ARM Modules linked in: g_file_storage kagen2_udc ath6kl_sdio ath6kl_core ka2000_sdio ka2000_sdhc CPU: 0Not tainted (3.4.4+ #41) PC is at th, wValue, wIndex; unsigned int rdata, rdata1; // setup data valid val = readl(dev->base_addr + 0+0xfb0/0x199c [kagen2_udc] LR is at console_unlock+0x208/0x218 pc : []lr : []psr: 2093 sp : c1347c68 ip : c1347b98 fp : c1347eb4 r10: c1328000 r9 : c12b4db4 r8 : 0001 r7 : c12fedd0 r6 : 0200 r5 : c1346000 r4 : c12b4d80 r3 : r2 : 0001 r1 : 015bb795 r0 : 4000 Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 0005717f Table: 01314000 DAC: 0017 Process file-storage-ga (pid: 122, stack limit = 0xc1346270) Stack: (0xc1347c68 to 0xc1348000) 7c60: 0200 c1347c78 000a 6013 7c80: c1328000 c12b4db4 4f203150 50205455 0a474e49 61760909 203d206c 64616572 7ca0: 6564286c 623e2d76 5f657361 72646461 30202b20 63383178 090a3b29 6c617609 7cc0: 203d2620 7830 3030 0a3b 61760909 3d7c206c 30783020 30323030 7ce0: 3b303030 090a0909 69727709 286c6574 2c6c6176 76656420 61623e2d 615f6573 7d00: 20726464 7830202b 29633831 7d090a3b 6c65090a 69206573 76282066 3d206c61 7d20: 7830203d 0a293832 700a7b09 746e6972 4522286b 4f203150 49205455 30205152 7d40: 5c782578 202c226e 296c6176 09090a3b 70652f2f 756f5f31 65642874 0a3b2976 7d60: 73740909 74654c6b 4253555f 7461642e 203d2061 736e7528 656e6769 6f6c2064 7d80: 6429676e 0a3b7665 61740909 656c6b73 63735f74 75646568 2628656c 4c6b7374 7da0: 555f7465 3b294253 09090a0a 206c6176 6572203d 286c6461 2d766564 7361623e 7dc0: 64615f65 2b207264 31783020 3b293061 7d090a09 6c65090a 69206573 76282066 7de0: 3d206c61 7830203d 0a293432 090a7b09 452f2f09 69203150 5249206e 09090a51 7e00: 206c6176 6572203d 286c6461 2d766564 7361623e 64615f65 2b207264 31783020 7e20: 3b293838 7609090a 26206c61 7830203d 3030 09090a3b 206c6176 7e40: 30203d7c 30303078 30303030 09093b32 7709090a 65746972 6176286c 64202c6c 7e60: 3e2d7665 65736162 6464615f 202b2072 38317830 0a3b2938 090a0909 65090a7d 7e80: 2065736c 28206669 c03ef7b0 c12b4d80 c12fedd0 c1289600 c12896f8 c12896e0 7ea0: 7e00 c1346018 c1347eec c1347eb8 bf035f9c bf02fa88 c12896dc 7ec0: c1289700 c1289600 00c8c000 c12896dc c1289700 c1289600 00c8c000 7ee0: c1347f54 c1347ef0 bf036b14 bf035e64 c12896e0 000a c1347f04 c0209bd4 7f00: c1347fbc be00 7e00 0001 00c8c000 00c88000 7f20: 0001 005f c12896dc c1289600 0001 005f c12896dc 7f40: c1346018 c1347fbc c1347f58 bf038ce8 bf0368d8 bf03a316 bf03a29f 7f60: 0015 c127ea80 c1347f8c c1347f78 c02349c8 c1289604 c13207e0 c1320540 7f80: c1347fac c1347f90 c03f2fc0 c02365d0 c1337e00 c1337e00 c1289600 bf037bc0 7fa0: 0013 c1347ff4 c1347fc0 c022f8f4 bf037bd0 7fc0: c1337e00 c1289600 c1347fd0 c1347fd0 c1337e00 7fe0: c022f860 c02191c8 c1347ff8 c02191c8 c022f870 Backtrace: [] (th, wValue, wIndex; unsigned int rdata, rdata1; // setup data valid val = readl(dev->base_addr + 0+0xa1c/0x199c [kagen2_udc]) from [] (bulk_in_complete+0x24c/0x1010 [g_file_storage
Re: Linux USB file storage gadget with new UDC
Hi, >> Thanks. I will add more printk statements gradually. Now i discover if >> i write to a large text file (> 48k) on USB gadget, linux will crash. >> The full log of UDC and gadget driver when linux crashes, and >> corresponding usbmon trace are attached. If these logs are not >> helpful, i shall add more printk. > > Unfortunately, I can't get anything useful out of the UDC driver crash > log. > > It looks like the crash occurred somewhere inside the do_write() > routine. Perhaps within the call to start_transfer(), or perhaps > within the vfs_write() call. > > Alan Stern > Just curious. The crash log shows the following UDC driver code which is responsible to receive endpoint 0 setup data. However, the host PC is sending SCSI_WRITE_10 command at the time of the crash. These two does not correlate, right? unsigned int rdata, rdata1; // setup data valid val = readl(dev->base_addr + 0+0xfb0/0x199c [kagen2_udc] thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> Just curious. The crash log shows the following UDC driver code which >> is responsible to receive endpoint 0 setup data. However, the host PC >> is sending SCSI_WRITE_10 command at the time of the crash. These two >> does not correlate, right? >> >> unsigned int rdata, rdata1; >> >> // setup data valid >> val = readl(dev->base_addr + 0+0xfb0/0x199c [kagen2_udc] > > The crash log should not include any driver code. > > What data were you writing to the gadget when the crash occurred? > Were you sending the source code for the UDC driver? If you were, > maybe that data got written to a wrong area in memory. Yes, you are right! I was sending the source code of the UDC driver when the crash occurred. Another question from the bulk_out_complete() printout which is shown below. The req->actual is 512 byte. The bh->bulk_out_intended_length is 31. Is this a bug? g_file_storage gadget: get_next_command [start_transfer] 6f007442 7000 ept1 out queue len 0x200, buffer 0xc133 kagen2_ep_queue 512 512 512 g_file_storage gadget: bulk_out_complete --> 0, 512/31 . thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> Another question from the bulk_out_complete() printout which is shown >> below. The req->actual is 512 byte. The bh->bulk_out_intended_length >> is 31. Is this a bug? >> >> g_file_storage gadget: get_next_command >> [start_transfer] 6f007442 7000 >> ept1 out queue len 0x200, buffer 0xc133 >> kagen2_ep_queue 512 512 512 >> g_file_storage gadget: bulk_out_complete --> 0, 512/31 >> . > > Well, it's a mistake. It might be a bug. > > If the host really did send a 13-byte packet then it's definitely a > bug. But if the host sent a 512-byte packet then something else is > wrong; it would mean the gadget was expecting a CBW packet but the host > sent something else. > > Alan Stern When copying a file to the USB gadget, sometimes the USB gadget will hang, sometimes the USB gadget will crash, sometimes the copy is ok. >From the UDC driver log, when the USB gadget crashes, the host is sending 16384 bytes of data. It seems that bulk_out_complete() is not able to handle it. [] (dev_printk+0x0/0x3c) from [] (bulk_out_complete+0xc4/0x1a8 [g_file_storage]) r3:152a0e00 r2:a020d0e5 [] (kagen2_ep_queue+0x0/0x680 [kagen2_udc]) from [] (bulk_in_complete+0x24c/0x1010 [g_file_storage]) The meaning of printk of "kagen2_ep_queue 512 16384 512" in UDC driver log: ka_req->req.actual is 512 ka_req->req.length is 16384 length from hardware FIFO is 512 Please see the attached UDC driver log and corresponding usbmon trace. Thanks, victor bulk_in_complete --> 0, 512/512 bulk_in_complete --> 0, 13/13 kagen2_ep_queue 31 512 31 bulk_in_complete --> 0, 512/512 bulk_in_complete --> 0, 13/13 kagen2_ep_queue 31 512 31 EP1 OUT IRQ 0x28 ep1_out: RX DMA done : NULL REQ on OUT EP-1 bulk_in_complete --> 0, 512/512 bulk_in_complete --> 0, 13/13 kagen2_ep_queue 31 512 31 EP1 OUT IRQ 0x28 ep1_out: RX DMA done : NULL REQ on OUT EP-1 kagen2_ep_queue 512 16384 512 kagen2_ep_queue 1024 16384 512 kagen2_ep_queue 1536 16384 512 kagen2_ep_queue 2048 16384 512 kagen2_ep_queue 2560 16384 512 kagen2_ep_queue 3072 16384 512 kagen2_ep_queue 3584 16384 512 kagen2_ep_queue 4096 16384 512 kagen2_ep_queue 4608 16384 512 kagen2_ep_queue 5120 16384 512 kagen2_ep_queue 5632 16384 512 kagen2_ep_queue 6144 16384 512 kagen2_ep_queue 6656 16384 512 kagen2_ep_queue 7168 16384 512 kagen2_ep_queue 7680 16384 512 kagen2_ep_queue 8192 16384 512 kagen2_ep_queue 8704 16384 512 kagen2_ep_queue 9216 16384 512 kagen2_ep_queue 9728 16384 512 kagen2_ep_queue 10240 16384 512 kagen2_ep_queue 10752 16384 512 kagen2_ep_queue 11264 16384 512 kagen2_ep_queue 11776 16384 512 kagen2_ep_queue 12288 16384 512 kagen2_ep_queue 12800 16384 512 kagen2_ep_queue 13312 16384 512 kagen2_ep_queue 13824 16384 512 kagen2_ep_queue 14336 16384 512 kagen2_ep_queue 14848 16384 512 kagen2_ep_queue 15360 16384 512 kagen2_ep_queue 15872 16384 512 kagen2_ep_queue 16384 16384 512 Unable to handle kernel NULL pointer dereference at virtual address 0004 pgd = c0204000 [0004] *pgd= Internal error: Oops - BUG: 17 [#1] PREEMPT ARM Modules linked in: g_file_storage kagen2_udc ath6kl_sdio ath6kl_core ka2000_sdio ka2000_sdhc CPU: 0Not tainted (3.4.4+ #43) PC is at dev_driver_string+0x30/0x44 LR is at __dev_printk+0x38/0x68 pc : []lr : []psr: 2093 sp : c1333c08 ip : c1333c18 fp : c1333c14 r10: c0c38000 r9 : c12a0e34 r8 : 0001 r7 : c1289600 r6 : c129ec00 r5 : c1333c44 r4 : c129edd0 r3 : 0004 r2 : c1333c44 r1 : c129ec00 r0 : c129ec00 Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 0005717f Table: 01308000 DAC: 0017 Process file-storage-ga (pid: 123, stack limit = 0xc1332270) Stack: (0xc1333c08 to 0xc1334000) 3c00: c1333c3c c1333c18 c03280c4 c0327ed8 c0208eb8 c0208564 3c20: c129edd0 c12a0e00 c12896bc 0200 c1333c5c c1333c40 c0328320 c032809c 3c40: 0001 a020d0e5 c1333c4c c1333c64 c1333eb4 c1333c68 bf035924 c0328300 3c60: a020d0e5 152a0e00 152a0e00 c1333c78 000a 6013 3c80: c0c38000 c12a0e34 20313320 34660a3e 32613231 32203034 32323434 31363639 3ca0: 20532033 323a6942 3435303a 2d20313a 20353131 36393034 660a3c20 61323134 3cc0: 20303432 32343432 37313435 43203534 3a694220 35303a32 20313a34 30342030 3ce0: 3d203639 30303020 30303030 30302030 30303030 30203030 30303030 20303030 3d00: 30303030 30303030 30303020 30303030 30302030 30303030 30203030 30303030 3d20: 20303030 30303030 30303030 6166640a 34313936 34322030 34353234 34323831 3d40: 42205320 3a323a69 3a343530 312d2031 31203531 0a3c2033 36616664 30343139 3d60: 34343220 38343532 20323934 69422043 303a323a 313a3435 31203020 203d2033 3d80: 33353535 33353234 30613520 30303030 30302030 30303030 30203030 66640a30 3da0: 31393661 32203034 35323434 38353834 20532037 323a6f42 3435303a 2d20313a 3dc0: 20353131 3d203133 35353520 34323433 62352033 30303030 30203030 30303130 3de0: 20303030 30303038 38326130 30303020 30303030 30382033 30303030 30203830 3e00: 30303030 20303030 30303030 640a3030 39366166 20303431 32343432 37383435 3e20: 4
Re: Linux USB file storage gadget with new UDC
Hi, >> When copying a file to the USB gadget, sometimes the USB gadget will >> hang, sometimes the USB gadget will crash, sometimes the copy is ok. >> >> From the UDC driver log, when the USB gadget crashes, the host is >> sending 16384 bytes of data. It seems that bulk_out_complete() is not >> able to handle it. >> >> [] (dev_printk+0x0/0x3c) from [] >> (bulk_out_complete+0xc4/0x1a8 [g_file_storage]) >> r3:152a0e00 r2:a020d0e5 >> [] (kagen2_ep_queue+0x0/0x680 [kagen2_udc]) from >> [] (bulk_in_complete+0x24c/0x1010 [g_file_storage]) >> >> The meaning of printk of "kagen2_ep_queue 512 16384 512" in UDC driver log: >> ka_req->req.actual is 512 >> ka_req->req.length is 16384 >> length from hardware FIFO is 512 >> >> Please see the attached UDC driver log and corresponding usbmon trace. > > I think the log says that bulk_out_complete() crashed when trying to > dereference a NULL pointer. Maybe req->buf, maybe req->context, maybe > something else. > > But you already know that bulk_out_complete() crashed; you don't need > me to tell you that. > > What you _do_ need is to find out why the crash occurred. This means > finding out which pointer is NULL. Thanks! Indeed, the req->buf pointer was the one causing the crash problem. It happened when combining multiple 512 bytes data. I have fixed this bug. Now my UDC driver is almost ready. That is probably one more SCSI command timeout problem remaining, i am adding more printk to UDC driver and studying it. Thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi,
> Thanks! Indeed, the req->buf pointer was the one causing the crash
> problem. It happened when combining multiple 512 bytes data. I have
> fixed this bug.
>
> Now my UDC driver is almost ready. That is probably one more SCSI
> command timeout problem remaining, i am adding more printk to UDC
> driver and studying it.
I am able to solve the SCSI command timeout problem by adding a code
to check the hardware register busy bit continuously, in
kagen2_ep_queue():
do {
read_hardware_register_busy_bit
} while (hardware_is_busy)
however, it causes the linux prompt to be non-responsive because the
checking hardware register code is run continuously. If i add a
schedule() to the do-while loop, the kagen2_ep_queue() will not be
continued. How to go about fixing this dilemma?
thanks,
victor
--
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: Linux USB file storage gadget with new UDC
Hi, > The text capture is incomplete. It is missing lots of packets. In > particular, it is missing all the packets between 202489 and 202502. The missing packets are NAK, I added the NAK after Set-Config setup stage. I hide the NAK when i export the packet capture to text format. > Also, I don't understand the "Dir H(S)" part of the capture lines. > What do they mean? They are present on every packet. Dir stands for direction, H is high speed, S is super speed. > This was never the issue. I'm sure the DATA1 packet of the Set-Config > was sent before the Get-Config request. The real question is whether > the DATA1 packet was sent before the Set-Config request had been fully > processed. > > To get more information, try adding > > msleep(100); > > just before the final "return rc;" line in do_set_config(). We should > be able to see in the analyzer log if this 100-ms delay is present. After i added msleep(100) just before final line in do_set_config(), the USB enumeration fails to complete normally. > Here's a second test you can try. In handle_exception(), the > FSG_STATE_CONFIG_CHANGE case, comment out the > > ep0_queue(fsg); > > line. Without that line the Set-Config request should time out, > because the gadget will never complete the status stage. If the > request does complete normally, it will prove that the UDC driver isn't > working right. After i comment out the ep0_queue(fsg) in FSG_STATE_CONFIG_CHANGE case of handle_exception(), the request does complete, but takes more time to complete. And UDC driver queue function is still being called after the Set-Config request. Thanks, Victor -- 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: Linux USB file storage gadget with new UDC
Hi, > It looks like you didn't add the dump_stack() call to the UDC driver's > queue function. You need to add it. The attached is the log of dump_stack() call in the UDC driver queue function, for the last few USB request in the USBCV "device descriptor test – addressed state". From the log, after Set-Config request is received, the UDC driver queue function is not called. That function is called after Get-Config request is received. >> I also share the pseudo code of the setup data valid processing, i >> suspect it may be related to the problem: >> >> receive setup data valid interrupt >> find out the usb request field (bmRequestType, bRequest, wValue, >> wIndex, wLength) >> if (USB_CLEAR_FEATURE_REQUEST) >> call usb_ep_queue() > > Don't you need to handle this in the hardware, just like > USB_SET_FEATURE_REQUEST? USB_SET_FEATURE_REQUEST is handled in software. Thanks, victor [ 83.61] : 80 06 00 02 00 00 09 00 [ 83.61] fsg_setup call ep0_queue Backtrace: [ 83.61] [] (dump_backtrace+0x0/0x110) from [] (dump_stack+0x18/0x1c) [ 83.61] r6:0002 r5:c0d6f600 r4:c0da69c0 r3:bf02fa10 [ 83.61] [] (dump_stack+0x0/0x1c) from [] (kagen2_ep_queue+0x1c/0x7b4 [kagen2_udc]) [ 83.61] [] (kagen2_ep_queue+0x0/0x7b4 [kagen2_udc]) from [] (ep0_queue+0x28/0x60 [g_file_storage]) [ 83.61] [] (ep0_queue+0x0/0x60 [g_file_storage]) from [] (fsg_setup+0x3a0/0x3d8 [g_file_storage]) [ 83.61] r5:c0e23e98 r4:c0d6f600 [ 83.61] [] (fsg_setup+0x0/0x3d8 [g_file_storage]) from [] (kagen2_irq+0x388/0x4d8 [kagen2_udc]) [ 83.61] [] (kagen2_irq+0x0/0x4d8 [kagen2_udc]) from [] (handle_irq_event_percpu+0x30/0x178) [ 83.61] r7:0020 r6: r5:c049af70 r4:c0da6840 [ 83.61] [] (handle_irq_event_percpu+0x0/0x178) from [] (handle_irq_event+0x60/0x7c) [ 83.61] [] (handle_irq_event+0x0/0x7c) from [] (handle_edge_irq+0x114/0x16c) [ 83.61] r6:f5006000 r5: r4:c049af70 r3:f5006000 [ 83.61] [] (handle_edge_irq+0x0/0x16c) from [] (generic_handle_irq+0x28/0x38) [ 83.61] r4:0020 r3:c024bb98 [ 83.61] [] (generic_handle_irq+0x0/0x38) from [] (handle_IRQ+0x68/0x8c) [ 83.61] r4:0020 r3:0040 [ 83.61] [] (handle_IRQ+0x0/0x8c) from [] (asm_do_IRQ+0x10/0x14) [ 83.61] r5:0013 r4:bf02f500 [ 83.61] [] (asm_do_IRQ+0x0/0x14) from [] (__irq_svc+0x34/0xbc) [ 83.61] Exception stack(0xc0e23f60 to 0xc0e23fa8) [ 83.61] 3f60: 4000 0288001f c2886000 c0df2c00 c0df2c00 bf02f4d8 0013 [ 83.61] 3f80: c0e23fbc c0e22000 c0e23fa8 4001 bf02f500 [ 83.61] 3fa0: 0013 [ 83.61] [] (chkbusy_thread+0x0/0x60 [kagen2_udc]) from [] (kthread+0x94/0xa0) [ 83.61] r4:c0d75d58 r3: [ 83.61] [] (kthread+0x0/0xa0) from [] (do_exit+0x0/0x6f0) [ 83.61] r6:c021913c r5:c022f7d4 r4:c0d75d58 [ 83.61] ept0 in queue len 0x9, buffer 0xc0d6f800 [ 83.61] : 09 02 20 00 01 01 04 c0 01 [ 83.62] : 80 08 00 00 00 00 01 00 [ 83.62] g_file_storage gadget: get configuration 1 1 [ 83.62] fsg_setup call ep0_queue Backtrace: [ 83.62] [] (dump_backtrace+0x0/0x110) from [] (dump_stack+0x18/0x1c) [ 83.62] r6:c0da69c0 r5:c0d6f600 r4:c0da69c0 r3:bf02fa10 [ 83.62] [] (dump_stack+0x0/0x1c) from [] (kagen2_ep_queue+0x1c/0x7b4 [kagen2_udc]) [ 83.62] [] (kagen2_ep_queue+0x0/0x7b4 [kagen2_udc]) from [] (ep0_queue+0x28/0x60 [g_file_storage]) [ 83.62] [] (ep0_queue+0x0/0x60 [g_file_storage]) from [] (fsg_setup+0x3a0/0x3d8 [g_file_storage]) [ 83.62] r5:c0e23e98 r4:c0d6f600 [ 83.62] [] (fsg_setup+0x0/0x3d8 [g_file_storage]) from [] (kagen2_irq+0x388/0x4d8 [kagen2_udc]) [ 83.62] [] (kagen2_irq+0x0/0x4d8 [kagen2_udc]) from [] (handle_irq_event_percpu+0x30/0x178) [ 83.62] r7:0020 r6: r5:c049af70 r4:c0da6840 [ 83.62] [] (handle_irq_event_percpu+0x0/0x178) from [] (handle_irq_event+0x60/0x7c) [ 83.62] [] (handle_irq_event+0x0/0x7c) from [] (handle_edge_irq+0x114/0x16c) [ 83.62] r6:f5006000 r5: r4:c049af70 r3:f5006000 [ 83.62] [] (handle_edge_irq+0x0/0x16c) from [] (generic_handle_irq+0x28/0x38) [ 83.62] r4:0020 r3:c024bb98 [ 83.62] [] (generic_handle_irq+0x0/0x38) from [] (handle_IRQ+0x68/0x8c) [ 83.62] r4:0020 r3:0040 [ 83.62] [] (handle_IRQ+0x0/0x8c) from [] (asm_do_IRQ+0x10/0x14) [ 83.62] r5:0013 r4:bf02f500 [ 83.62] [] (asm_do_IRQ+0x0/0x14) from [] (__irq_svc+0x34/0xbc) [ 83.62] Exception stack(0xc0e23f60 to 0xc0e23fa8) [ 83.62] 3f60: 4000 0288001f c2886000 c0df2c00 c0df2c00 bf02f4d8 0013 [ 83.62] 3f80: c0e23fbc c0e22000 c0e23fa8 4001 bf02f500 [ 83.62] 3fa0: 0013 [ 83.62] [] (chkbusy_thread+0x0/0x60 [kagen2_udc]) from [] (kthre
Re: Linux USB file storage gadget with new UDC
Hi, >> > This log looks oddly incomplete. A lot of debugging messages are >> > missing. >> > >> >> g_file_storage gadget: ep0-setup, length 8: >> >> : 80 06 00 01 00 00 40 00 >> >> g_file_storage gadget: get device descriptor >> > >> > For example, right here we should see the device descriptor data that >> > was sent back to the host. >> >> I checked the log again, the dmesg log did not contain that info. May >> i know which part of the gadget code will print out the device >> descriptor data that was sent back to the host? > > ep0_complete(), where it calls dump_msg(). My Usb gadget hardware was broken for 2 weeks, i am sorry for the late reply. Today i check the ep0_complete() function, it is not called during Usb mass storage gadget enumeration with host PC. I am not sure which part of file_storage.c called ep0_complete(). Please kindly point out to me. Thanks. Regards, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> >> >> g_file_storage gadget: ep0-setup, length 8: >> >> >> : 80 06 00 01 00 00 40 00 >> >> >> g_file_storage gadget: get device descriptor >> >> > >> >> > For example, right here we should see the device descriptor data that >> >> > was sent back to the host. >> >> >> >> I checked the log again, the dmesg log did not contain that info. May >> >> i know which part of the gadget code will print out the device >> >> descriptor data that was sent back to the host? >> > >> > ep0_complete(), where it calls dump_msg(). >> >> My Usb gadget hardware was broken for 2 weeks, i am sorry for the late >> reply. Today i check the ep0_complete() function, it is not called >> during Usb mass storage gadget enumeration with host PC. I am not sure >> which part of file_storage.c called ep0_complete(). Please kindly >> point out to me. Thanks. > > ep0_complete() should be called by your UDC driver. Seriously dude, read > the documentation and read other drivers to figure out how things should > be called. A quick look in the storage drivers would have shown you that > ep0_complete() is passed in as req->complete() through the usb_request > structure. That structure (well, a pointer to it) is passed to the UDC > driver through usb_ep_queue(). All you had to figure out is "when it > req->complete called". ANY UDC driver would have given you the answer. > > Likely your UDC driver is still buggy, if you don't call ->complete(), > you're starving your usb_request queue. > Yes, ep0_complete() is called in UDC driver queue function, i just added it in and ep0_complete() is called now. The dmesg output is below. handle setup GET_DESCRIPTOR, 80, 6 index 0 value 100 len 40 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 40 00 g_file_storage gadget: get device descriptor g_file_storage gadget: ep0_complete --> 0, 0/18 the req->actual is 0, so dump_msg() in ep0_complete() is not called. My UDC driver is still buggy. thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> > ep0_complete() should be called by your UDC driver. Seriously dude, read >> > the documentation and read other drivers to figure out how things should >> > be called. A quick look in the storage drivers would have shown you that >> > ep0_complete() is passed in as req->complete() through the usb_request >> > structure. That structure (well, a pointer to it) is passed to the UDC >> > driver through usb_ep_queue(). All you had to figure out is "when it >> > req->complete called". ANY UDC driver would have given you the answer. >> > >> > Likely your UDC driver is still buggy, if you don't call ->complete(), >> > you're starving your usb_request queue. >> > >> >> Yes, ep0_complete() is called in UDC driver queue function, i just >> added it in and ep0_complete() is called now. The dmesg output is >> below. > > not in queue function, you should call it when completing. > Is there any mistake in my understanding of ep0 setup data processing? 1. usb gadget HW IRQ is triggered if ep0 receives data 2. fsg_setup() is called 3. ep0_queue() is called 4. UDC driver queue function is called 5. UDC driver sends data to ep0 HW buffer 6. UDC driver increments req->actual by the amount of transferred bytes 7. UDC driver call ep0_complete() thanks. victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> >> Yes, ep0_complete() is called in UDC driver queue function, i just >> >> added it in and ep0_complete() is called now. The dmesg output is >> >> below. >> > >> > not in queue function, you should call it when completing. >> > >> >> Is there any mistake in my understanding of ep0 setup data processing? >> >> 1. usb gadget HW IRQ is triggered if ep0 receives data >> 2. fsg_setup() is called >> 3. ep0_queue() is called >> 4. UDC driver queue function is called >> 5. UDC driver sends data to ep0 HW buffer >> 6. UDC driver increments req->actual by the amount of transferred bytes >> 7. UDC driver call ep0_complete() > > looks correct > Some progress, now i am able to see the dump_msg from ep0_complete(). It looks like the enumeration is ok, but the SCSI Inquiry command is not received by the UDC driver. The do_scsi_command() in fsg_main_thread() is not called. Is this another bug in my UDC driver? below is the debug message from file storage gadget g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 40 00 g_file_storage gadget: get device descriptor g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 12 00 g_file_storage gadget: get device descriptor g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 ff 00 g_file_storage gadget: get configuration descriptor g_file_storage gadget: ep0-in, length 32: : 09 02 20 00 01 01 04 c0 01 09 04 00 00 02 08 06 0010: 50 05 07 05 81 02 00 02 00 07 05 01 02 00 02 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 03 00 00 ff 00 g_file_storage gadget: ep0-in, length 4: : 04 03 09 04 g_file_storage gadget: ep0-setup, length 8: : 80 06 02 03 09 04 ff 00 g_file_storage gadget: get string descriptor g_file_storage gadget: ep0-in, length 54: : 36 03 46 00 69 00 6c 00 65 00 2d 00 62 00 61 00 0010: 63 00 6b 00 65 00 64 00 20 00 53 00 74 00 6f 00 0020: 72 00 61 00 67 00 65 00 20 00 47 00 61 00 64 00 0030: 67 00 65 00 74 00 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 12 00 g_file_storage gadget: get device descriptor g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 09 00 g_file_storage gadget: get configuration descriptor g_file_storage gadget: ep0-in, length 9: : 09 02 20 00 01 01 04 c0 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 20 00 g_file_storage gadget: get configuration descriptor g_file_storage gadget: ep0-in, length 32: : 09 02 20 00 01 01 04 c0 01 09 04 00 00 02 08 06 0010: 50 05 07 05 81 02 00 02 00 07 05 01 02 00 02 01 g_file_storage gadget: ep0-setup, length 8: : 00 09 01 00 00 00 00 00 g_file_storage gadget: set configuration g_file_storage gadget: set interface 0 g_file_storage gadget: high-speed config #1 g_file_storage gadget: ep0-setup, length 8: : a1 fe 00 00 00 00 01 00 g_file_storage gadget: ep0-in, length 1: : 00 g_file_storage gadget: ep0-setup, length 8: : 80 06 01 03 09 04 ff 00 g_file_storage gadget: get string descriptor g_file_storage gadget: ep0-in, length 58: : 3a 03 4c 00 69 00 6e 00 75 00 78 00 20 00 33 00 0010: 2e 00 34 00 2e 00 34 00 2b 00 20 00 77 00 69 00 0020: 74 00 68 00 20 00 6b 00 61 00 67 00 65 00 6e 00 0030: 32 00 5f 00 75 00 73 00 62 00 g_file_storage gadget: ep0-setup, length 8: : 80 06 04 03 09 04 ff 00 g_file_storage gadget: get string descriptor g_file_storage gadget: ep0-in, length 26: : 1a 03 53 00 65 00 6c 00 66 00 2d 00 70 00 6f 00 0010: 77 00 65 00 72 00 65 00 64 00 g_file_storage gadget: ep0-setup, length 8: : 80 06 05 03 09 04 ff 00 g_file_storage gadget: get string descriptor g_file_storage gadget: ep0-in, length 26: : 1a 03 4d 00 61 00 73 00 73 00 20 00 53 00 74 00 0010: 6f 00 72 00 61 00 67 00 65 00 thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> >> >> Yes, ep0_complete() is called in UDC driver queue function, i just >> >> >> added it in and ep0_complete() is called now. The dmesg output is >> >> >> below. >> >> > >> >> > not in queue function, you should call it when completing. >> >> > >> >> >> >> Is there any mistake in my understanding of ep0 setup data processing? >> >> >> >> 1. usb gadget HW IRQ is triggered if ep0 receives data >> >> 2. fsg_setup() is called >> >> 3. ep0_queue() is called >> >> 4. UDC driver queue function is called >> >> 5. UDC driver sends data to ep0 HW buffer >> >> 6. UDC driver increments req->actual by the amount of transferred bytes >> >> 7. UDC driver call ep0_complete() >> > >> > looks correct >> > >> >> Some progress, now i am able to see the dump_msg from ep0_complete(). >> It looks like the enumeration is ok, but the SCSI Inquiry command is >> not received by the UDC driver. The do_scsi_command() in >> fsg_main_thread() is not called. Is this another bug in my UDC driver? > > I would believe so since so many other controllers work just fine. Is there any way to to further debug into why do_scsi_command() is not called? thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> > >> >> Is there any mistake in my understanding of ep0 setup data >> > >> >> processing? >> > >> >> >> > >> >> 1. usb gadget HW IRQ is triggered if ep0 receives data >> > >> >> 2. fsg_setup() is called >> > >> >> 3. ep0_queue() is called >> > >> >> 4. UDC driver queue function is called >> > >> >> 5. UDC driver sends data to ep0 HW buffer >> > >> >> 6. UDC driver increments req->actual by the amount of transferred >> > >> >> bytes >> > >> >> 7. UDC driver call ep0_complete() >> > >> > >> > >> > looks correct >> > >> > >> > >> >> > >> Some progress, now i am able to see the dump_msg from ep0_complete(). >> > >> It looks like the enumeration is ok, but the SCSI Inquiry command is >> > >> not received by the UDC driver. The do_scsi_command() in >> > >> fsg_main_thread() is not called. Is this another bug in my UDC driver? >> > > >> > > I would believe so since so many other controllers work just fine. >> > >> > Is there any way to to further debug into why do_scsi_command() is not >> > called? >> >> usbmon, printk(), trace_printk(), kernel function tracer, there are many >> ways choose one and spend some time debugging, I'm sure you'll find the >> bug. > > It sounds like the UDC driver now works okay for control transfers but > not for bulk transfers. > Some code in file_storage.c that i cannot understand. In ep0_complete(), the code snippet: if (req->status == 0 && req->context) ((fsg_routine_t) (req->context))(fsg); Does the UDC driver provide the context pointer to file_storage.c? Another gadget question: get_next_command() is receiving command from host PC, UDC HW isr routine is also receiving data from host PC. What is the difference between these two? thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi,
>> >> > Is there any way to to further debug into why do_scsi_command() is not
>> >> > called?
>> >>
>> >> usbmon, printk(), trace_printk(), kernel function tracer, there are many
>> >> ways choose one and spend some time debugging, I'm sure you'll find the
>> >> bug.
>> >
>> > It sounds like the UDC driver now works okay for control transfers but
>> > not for bulk transfers.
>> >
>>
>> Some code in file_storage.c that i cannot understand. In
>> ep0_complete(), the code snippet:
>>
>> if (req->status == 0 && req->context)
>> ((fsg_routine_t) (req->context))(fsg);
>>
>> Does the UDC driver provide the context pointer to file_storage.c?
>
> That belongs to the gadget driver. file_storage.c maintains that
> req->context.
>
>> Another gadget question: get_next_command() is receiving command from
>> host PC, UDC HW isr routine is also receiving data from host PC. What
>> is the difference between these two?
>
> hmm... ISR receives data and bounces it back to gadget driver. What do
> you mean ?
Ok, rephrase the question, is this the flow for bulk transfer?
1) data is received by Usb mass storage HW, the UDC driver ISR is
called to read the data to usb_request buffer
2) bulk_out_complete() in gadget driver, is called to set buffer state to full
3) get_next_command() in gadget driver, is called to read the CBW.
4) do_scsi_command() to process SCSI command encoded in CBW
5) send_status() sends the CSW to host
i see this code snippet in fsg_main_thread(), i cannot understand it,
please tell me what the purpose of this code is. is handle_exception()
tries to process error condition?
if (exception_in_progress(fsg) || signal_pending(current)) {
handle_exception(fsg);
}
thanks,
victor
--
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: Linux USB file storage gadget with new UDC
Hi, >> >> > It sounds like the UDC driver now works okay for control transfers but >> >> > not for bulk transfers. >> >> > >> >> >> >> Some code in file_storage.c that i cannot understand. In >> >> ep0_complete(), the code snippet: >> >> >> >> if (req->status == 0 && req->context) >> >> ((fsg_routine_t) (req->context))(fsg); >> >> >> >> Does the UDC driver provide the context pointer to file_storage.c? >> > >> > That belongs to the gadget driver. file_storage.c maintains that >> > req->context. >> > >> >> Another gadget question: get_next_command() is receiving command from >> >> host PC, UDC HW isr routine is also receiving data from host PC. What >> >> is the difference between these two? >> > >> > hmm... ISR receives data and bounces it back to gadget driver. What do >> > you mean ? >> >> Ok, rephrase the question, is this the flow for bulk transfer? >> >> 1) data is received by Usb mass storage HW, the UDC driver ISR is >> called to read the data to usb_request buffer >> 2) bulk_out_complete() in gadget driver, is called to set buffer state to >> full >> 3) get_next_command() in gadget driver, is called to read the CBW. >> 4) do_scsi_command() to process SCSI command encoded in CBW >> 5) send_status() sends the CSW to host > > Something like below: > > OUT Token -> ISR -> giveback() -> bulk_out_complete() -> > get_next_command() -> do_scsi_command() -> usb_ep_queue() -> OUT/IN > Token -> ISR -> bulk_out_complete() -> send_status() For the IN Token, i will just write the data to the HW buffer, and the flow will go to send_status(). I use a different USB cable, now the USB gadget is able to receive bulk transfer data from host PC. I am working on the bulk transfer code. Thank you for the very useful answers. victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> >> Ok, rephrase the question, is this the flow for bulk transfer? >> >> >> >> 1) data is received by Usb mass storage HW, the UDC driver ISR is >> >> called to read the data to usb_request buffer >> >> 2) bulk_out_complete() in gadget driver, is called to set buffer state to >> >> full >> >> 3) get_next_command() in gadget driver, is called to read the CBW. >> >> 4) do_scsi_command() to process SCSI command encoded in CBW >> >> 5) send_status() sends the CSW to host >> > >> > Something like below: >> > >> > OUT Token -> ISR -> giveback() -> bulk_out_complete() -> >> > get_next_command() -> do_scsi_command() -> usb_ep_queue() -> OUT/IN >> > Token -> ISR -> bulk_out_complete() -> send_status() >> >> For the IN Token, i will just write the data to the HW buffer, and the >> flow will go to send_status(). >> >> I use a different USB cable, now the USB gadget is able to receive >> bulk transfer data from host PC. I am working on the bulk transfer >> code. Thank you for the very useful answers. > > np In fsg_dev structure, there are 3 usb_ep: bulk_in, bulk_out, and intr_in. Why is the intr_out endpoint not defined? thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> >> >> Ok, rephrase the question, is this the flow for bulk transfer? >> >> >> >> >> >> 1) data is received by Usb mass storage HW, the UDC driver ISR is >> >> >> called to read the data to usb_request buffer >> >> >> 2) bulk_out_complete() in gadget driver, is called to set buffer state >> >> >> to full >> >> >> 3) get_next_command() in gadget driver, is called to read the CBW. >> >> >> 4) do_scsi_command() to process SCSI command encoded in CBW >> >> >> 5) send_status() sends the CSW to host >> >> > >> >> > Something like below: >> >> > >> >> > OUT Token -> ISR -> giveback() -> bulk_out_complete() -> >> >> > get_next_command() -> do_scsi_command() -> usb_ep_queue() -> OUT/IN >> >> > Token -> ISR -> bulk_out_complete() -> send_status() >> >> >> >> For the IN Token, i will just write the data to the HW buffer, and the >> >> flow will go to send_status(). >> >> >> >> I use a different USB cable, now the USB gadget is able to receive >> >> bulk transfer data from host PC. I am working on the bulk transfer >> >> code. Thank you for the very useful answers. >> > >> > np >> >> In fsg_dev structure, there are 3 usb_ep: bulk_in, bulk_out, and >> intr_in. Why is the intr_out endpoint not defined? > > because it's not needed. Read the USB Mass Storage Class specification > from usb.org Ok. In the gadget driver, it keeps on receiving the same bulk_out data, maybe because the data is not processed. The get_next_command is not called. g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 38 b5 ea 86 24 00 00 00 80 00 06 12 0010: 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00^C g_file_storage gadget: bulk_out_complete --> 0, 31/0 Is it because the bh->bulk_out_intended_length is 0? thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> >> In fsg_dev structure, there are 3 usb_ep: bulk_in, bulk_out, and >> >> intr_in. Why is the intr_out endpoint not defined? >> > >> > because it's not needed. Read the USB Mass Storage Class specification >> > from usb.org >> >> Ok. In the gadget driver, it keeps on receiving the same bulk_out >> data, maybe because the data is not processed. The get_next_command is >> not called. >> >> g_file_storage gadget: bulk-out, length 31: >> : 55 53 42 43 38 b5 ea 86 24 00 00 00 80 00 06 12 >> 0010: 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00^C >> g_file_storage gadget: bulk_out_complete --> 0, 31/0 >> >> Is it because the bh->bulk_out_intended_length is 0? > > that data is a CBW. But aparently gadget driver queued 0-bytes, why did > you unload data if req->length was zero ? > > another bug in your udc driver In my udc driver, i set the req->length to the number of bytes i received from HW, which is 31 bytes. Is it necessary to do that? How to know the gadget driver queued 0-bytes? By bh->bulk_out_intended_length ? thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> >> Ok. In the gadget driver, it keeps on receiving the same bulk_out >> >> data, maybe because the data is not processed. The get_next_command is >> >> not called. >> >> >> >> g_file_storage gadget: bulk-out, length 31: >> >> : 55 53 42 43 38 b5 ea 86 24 00 00 00 80 00 06 12 >> >> 0010: 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00^C >> >> g_file_storage gadget: bulk_out_complete --> 0, 31/0 >> >> >> >> Is it because the bh->bulk_out_intended_length is 0? >> > >> > that data is a CBW. But aparently gadget driver queued 0-bytes, why did >> > you unload data if req->length was zero ? >> > >> > another bug in your udc driver >> >> In my udc driver, i set the req->length to the number of bytes i >> received from HW, which is 31 bytes. Is it necessary to do that? How > > you shouldn't touch req->lenght, you should only update req->actual. > req->length is readonly for the UDC. > >> to know the gadget driver queued 0-bytes? By >> bh->bulk_out_intended_length ? > > read req->length > i removed setting the req->length in udc driver. Now in the bulk_out_complete(), the value of req->length is 512. who set it to 512? thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> >> In my udc driver, i set the req->length to the number of bytes i >> >> received from HW, which is 31 bytes. Is it necessary to do that? How >> > >> > you shouldn't touch req->lenght, you should only update req->actual. >> > req->length is readonly for the UDC. >> > >> >> to know the gadget driver queued 0-bytes? By >> >> bh->bulk_out_intended_length ? >> > >> > read req->length >> > >> >> i removed setting the req->length in udc driver. Now in the >> bulk_out_complete(), the value of req->length is 512. who set it to >> 512? > > Read the code and you will figure it out. Here are the last two setup data and CBW data received. the get_next_command() is not called when CBW data is received. the bulk_out_complete() wakes up the thread, however, get_next_command() still sleeps. i do not see where req->length is checked in gadget driver. g_file_storage gadget: ep0-setup, length 8: : 00 09 01 00 00 00 00 00 g_file_storage gadget: set configuration g_file_storage gadget: ep0-setup, length 8: : a1 fe 00 00 00 00 01 00 g_file_storage gadget: get max LUN g_file_storage gadget: ep0-in, length 1: : 00 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 a8 48 ed 86 24 00 00 00 80 00 06 12 0010: 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 g_file_storage gadget: bulk_out_complete --> 0, 31/0 victor -- 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: Linux USB file storage gadget with new UDC
Hi,
>> Here are the last two setup data and CBW data received. the
>> get_next_command() is not called when CBW data is received. the
>> bulk_out_complete() wakes up the thread, however, get_next_command()
>> still sleeps. i do not see where req->length is checked in gadget
>> driver.
>>
>> g_file_storage gadget: ep0-setup, length 8:
>> : 00 09 01 00 00 00 00 00
>> g_file_storage gadget: set configuration
>> g_file_storage gadget: ep0-setup, length 8:
>> : a1 fe 00 00 00 00 01 00
>> g_file_storage gadget: get max LUN
>> g_file_storage gadget: ep0-in, length 1:
>> : 00
>> g_file_storage gadget: bulk-out, length 31:
>> : 55 53 42 43 a8 48 ed 86 24 00 00 00 80 00 06 12
>> 0010: 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00
>> g_file_storage gadget: bulk_out_complete --> 0, 31/0
>
> file_storage uses bulk_out_intended_length.
>
> You're on your own, to be fair, using a really old kernel, you never
> posted your UDC driver for review, so you need to fix it all up by
> yourself.
>
> Read the code, add prints, look at other UDC drivers. g_file_storage is
> next to perfect and proven to work with many, many different setups.
Here is my UDC driver code. I use a kthread to poll the hardware
register EP0 and EP1 interrupt. I removed the HW register access code.
If it is required, i can send the full code. Something could be wrong
in my UDC driver. Thanks.
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define NUM_ENDPOINTS 3
#define EP_MAX_PACKET_SIZE 0x200
#define EP0_MAX_PACKET_SIZE 64
#define QH_MAXNUM 32
/*-*/
#define IO_OFFSET 0x5500
#define __IO_ADDRESS(x) ((x) + IO_OFFSET)
#define IO_ADDRESS(pa) IOMEM(__IO_ADDRESS(pa))
#ifdef IOMEM // Override asm/io.h
#undef IOMEM
#endif // IOMEM
#ifdef __ASSEMBLER__
#define IOMEM(x)x
#else
#define IOMEM(x)((void __force __iomem *)(x))
#endif
#define ka2000_readb(a) __raw_readb(IO_ADDRESS(a))
#define ka2000_readw(a) __raw_readw(IO_ADDRESS(a))
#define ka2000_readl(a) __raw_readl(IO_ADDRESS(a))
#define ka2000_writeb(v, a) __raw_writeb(v, IO_ADDRESS(a))
#define ka2000_writew(v, a) __raw_writew(v, IO_ADDRESS(a))
#define ka2000_writel(v, a) __raw_writel(v, IO_ADDRESS(a))
/*-*/
static const char *reqname(unsigned r)
{
switch (r) {
case USB_REQ_GET_STATUS: return "GET_STATUS";
case USB_REQ_CLEAR_FEATURE: return "CLEAR_FEATURE";
case USB_REQ_SET_FEATURE: return "SET_FEATURE";
case USB_REQ_SET_ADDRESS: return "SET_ADDRESS";
case USB_REQ_GET_DESCRIPTOR: return "GET_DESCRIPTOR";
case USB_REQ_SET_DESCRIPTOR: return "SET_DESCRIPTOR";
case USB_REQ_GET_CONFIGURATION: return "GET_CONFIGURATION";
case USB_REQ_SET_CONFIGURATION: return "SET_CONFIGURATION";
case USB_REQ_GET_INTERFACE: return "GET_INTERFACE";
case USB_REQ_SET_INTERFACE: return "SET_INTERFACE";
default: return "*UNKNOWN*";
}
}
static struct usb_endpoint_descriptor ep0_out_desc = {
.bLength = sizeof(struct usb_endpoint_descriptor),
.bDescriptorType = USB_DT_ENDPOINT,
.bEndpointAddress = 0,
.bmAttributes = USB_ENDPOINT_XFER_CONTROL,
};
static struct usb_endpoint_descriptor ep0_in_desc = {
.bLength = sizeof(struct usb_endpoint_descriptor),
.bDescriptorType = USB_DT_ENDPOINT,
.bEndpointAddress = USB_DIR_IN,
.bmAttributes = USB_ENDPOINT_XFER_CONTROL,
};
struct kagen2;
struct kagen2_request {
struct usb_request req;
struct list_head queue;
unsigned mapped:1,
valid:1;
};
struct ka_ep {
struct usb_ep ep;
struct kagen2 * dev;
unsigned long irqs;
struct usb_request req;
struct list_head queue;
const struct usb_endpoint_descriptor *desc;
unsigned num:8,
fifo_size:12,
stopped:1,
wedged:1,
is_in:1,
is_iso:1,
dma:1,
not_empty:1;
};
struct ka_udc {
struct usb_gadget gadget;
struct usb_gadget_driver*driver;
};
#define CONFIG_MAX_PKT(n) ((n) << 16)
#define TERMINATE 1
#define INFO_BYTES(n) ((n) << 16)
#define INFO_IOC (1 << 15)
#define INFO_ACTIVE (1 << 7)
#define INFO_HALTED (1 << 6)
#define INFO_BUFFER_ERROR (1 << 5)
#define INFO_TX_ERROR (1 << 3)
static struct ka_ep ka_ep_g[NUM_ENDPOINTS];
enum SPEED {
LOWSPEED = 0,
FULLSPEED = 1,
HIGHSPEED = 2,
};
enum STATE {
DEFAULT = 0,
SUSPENDED
};
int system_level = 0;
unsigned char device_state = 0;
unsigned char device_speed = FULLSPEED;
Re: Linux USB file storage gadget with new UDC
Hi, >> >> Here are the last two setup data and CBW data received. the >> >> get_next_command() is not called when CBW data is received. the >> >> bulk_out_complete() wakes up the thread, however, get_next_command() >> >> still sleeps. i do not see where req->length is checked in gadget >> >> driver. >> >> >> >> g_file_storage gadget: ep0-setup, length 8: >> >> : 00 09 01 00 00 00 00 00 >> >> g_file_storage gadget: set configuration >> >> g_file_storage gadget: ep0-setup, length 8: >> >> : a1 fe 00 00 00 00 01 00 >> >> g_file_storage gadget: get max LUN >> >> g_file_storage gadget: ep0-in, length 1: >> >> : 00 >> >> g_file_storage gadget: bulk-out, length 31: >> >> : 55 53 42 43 a8 48 ed 86 24 00 00 00 80 00 06 12 >> >> 0010: 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 >> >> g_file_storage gadget: bulk_out_complete --> 0, 31/0 >> > >> > file_storage uses bulk_out_intended_length. >> > >> > You're on your own, to be fair, using a really old kernel, you never >> > posted your UDC driver for review, so you need to fix it all up by >> > yourself. >> > >> > Read the code, add prints, look at other UDC drivers. g_file_storage is >> > next to perfect and proven to work with many, many different setups. >> >> Here is my UDC driver code. I use a kthread to poll the hardware >> register EP0 and EP1 interrupt. I removed the HW register access code. > > you should an interrupt handler to handle interrupts from your device. > Also, there are way too many mistakes on your driver, run checkpatch.pl, > compile it with sparse, don't hardcode addresses, don't reimplement a > bunch of infrastructure the kernel already gives you and check your > list_head usage! I have run checkpatch.pl and read the linux/usb/gadget.h. The Soc interrupt controller has problem, so i use a kernel thread to read from USB controller directly. > don't reimplement a bunch of infrastructure the kernel already gives you i don't understand this. please kindly show an example. > Also, you shouldn't requeue the request yourself, gadget driver owns the > request. which request do i requeue? please kindly point that out. Thanks! victor -- 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: Linux USB file storage gadget with new UDC
Hi,
>> > you should an interrupt handler to handle interrupts from your device.
>> > Also, there are way too many mistakes on your driver, run checkpatch.pl,
>> > compile it with sparse, don't hardcode addresses, don't reimplement a
>> > bunch of infrastructure the kernel already gives you and check your
>> > list_head usage!
>>
>> I have run checkpatch.pl and read the linux/usb/gadget.h. The Soc
>> interrupt controller has problem, so i use a kernel thread to read
>> from USB controller directly.
>>
>> > don't reimplement a bunch of infrastructure the kernel already gives you
>> i don't understand this. please kindly show an example.
>
> #define IO_OFFSET 0x5500
> #define __IO_ADDRESS(x) ((x) + IO_OFFSET)
>
> #define IO_ADDRESS(pa) IOMEM(__IO_ADDRESS(pa))
>
> #ifdef IOMEM // Override asm/io.h
> #undef IOMEM
> #endif // IOMEM
> #ifdef __ASSEMBLER__
> #define IOMEM(x)x
> #else
> #define IOMEM(x)((void __force __iomem *)(x))
> #endif
>
> none of this should be in the driver.
this can be removed.
>> > Also, you shouldn't requeue the request yourself, gadget driver owns the
>> > request.
>> which request do i requeue? please kindly point that out. Thanks!
>
> look at your code. Look what you do after you call complete.
is it this code? i will remove the redundant code after complete.
ka_ep_p->req.complete(&ka_ep_p->ep, &req->req);
if (num == 0) {
ka_ep_p->req.length = 0;
usb_ep_queue(&ka_ep_p->ep, &req->req, 0);
ka_ep_p->desc = &ep0_in_desc;
}
i read the net2272.c, the net2272_enable() is called by gadget driver
enable_endpoint(). When i run the gadget driver, enable_endpoint() is
called for fsg->bulk_in and fsg->bulk_out. The enable_endpoint() of
fsg->intr_in is not called because transport_is_cbi() is false. So
how can the endpoint 0 be enabled?
thanks,
victor
--
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: Linux USB file storage gadget with new UDC
Hi,
>> >> > Also, you shouldn't requeue the request yourself, gadget driver owns the
>> >> > request.
>> >> which request do i requeue? please kindly point that out. Thanks!
>> >
>> > look at your code. Look what you do after you call complete.
>>
>> is it this code? i will remove the redundant code after complete.
>>
>> ka_ep_p->req.complete(&ka_ep_p->ep, &req->req);
>> if (num == 0) {
>> ka_ep_p->req.length = 0;
>> usb_ep_queue(&ka_ep_p->ep, &req->req, 0);
>> ka_ep_p->desc = &ep0_in_desc;
>> }
>
> you should delete the request from your list. Whatever you do, has to be
> undone.
got it. i add list_del_init() to delete the request from the list.
>> i read the net2272.c, the net2272_enable() is called by gadget driver
>> enable_endpoint(). When i run the gadget driver, enable_endpoint() is
>> called for fsg->bulk_in and fsg->bulk_out. The enable_endpoint() of
>> fsg->intr_in is not called because transport_is_cbi() is false. So
>> how can the endpoint 0 be enabled?
>
> endpoint 0 has to be always enabled by the UDC driver. Gadget driver
> expects endpoint 0 to be ready.
i read through the net2272.c, i do not see where the endpoint 0 is
enabled. I blindly enable my endpoint zero. i think my code is wrong.
kagen2_ep_enable(&ka_ep->ep, &ep0_in_desc);
kagen2_ep_enable(&ka_ep->ep, &ep0_out_desc);
thanks,
victor
--
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: Linux USB file storage gadget with new UDC
Hi,
>> >> is it this code? i will remove the redundant code after complete.
>> >>
>> >> ka_ep_p->req.complete(&ka_ep_p->ep, &req->req);
>> >> if (num == 0) {
>> >> ka_ep_p->req.length = 0;
>> >> usb_ep_queue(&ka_ep_p->ep, &req->req, 0);
>> >> ka_ep_p->desc = &ep0_in_desc;
>> >> }
>> >
>> > you should delete the request from your list. Whatever you do, has to be
>> > undone.
>>
>> got it. i add list_del_init() to delete the request from the list.
>
> _init() is unnecessary
>
>>
>> >> i read the net2272.c, the net2272_enable() is called by gadget driver
>> >> enable_endpoint(). When i run the gadget driver, enable_endpoint() is
>> >> called for fsg->bulk_in and fsg->bulk_out. The enable_endpoint() of
>> >> fsg->intr_in is not called because transport_is_cbi() is false. So
>> >> how can the endpoint 0 be enabled?
>> >
>> > endpoint 0 has to be always enabled by the UDC driver. Gadget driver
>> > expects endpoint 0 to be ready.
>>
>> i read through the net2272.c, i do not see where the endpoint 0 is
>> enabled. I blindly enable my endpoint zero. i think my code is wrong.
>> kagen2_ep_enable(&ka_ep->ep, &ep0_in_desc);
>> kagen2_ep_enable(&ka_ep->ep, &ep0_out_desc);
>
> yeah, you need to enabled it during driver initialization
In the udc driver, i can't assign a single ep0 descriptor to both
ep0_in_desc and ep0_out_desc. i think i should skip ep0_out_desc. Bear
in mind that i only define 3 endpoints in udc driver: ep0, ep1 bulk
in, ep1 bulk out. Will it cause any problem to gadget driver?
thanks,
victor
--
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: Linux USB file storage gadget with new UDC
Hi, >> i do not see where req->length is checked in gadget >> driver. > > It isn't _checked_; it is _set_ in set_bulk_out_req_length(). > req->actual is checked in received_cbw(). > >> g_file_storage gadget: ep0-setup, length 8: >> : 00 09 01 00 00 00 00 00 >> g_file_storage gadget: set configuration >> g_file_storage gadget: ep0-setup, length 8: >> : a1 fe 00 00 00 00 01 00 >> g_file_storage gadget: get max LUN >> g_file_storage gadget: ep0-in, length 1: >> : 00 >> g_file_storage gadget: bulk-out, length 31: >> : 55 53 42 43 a8 48 ed 86 24 00 00 00 80 00 06 12 >> 0010: 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 >> g_file_storage gadget: bulk_out_complete --> 0, 31/0 > > Why is the bulk_out_intended_length field set to 0? Doesn't > set_bulk_out_req_length() work right? today i changed my udc driver code, now the set_bulk_out_req_length() sets the bulk_out_intended_length to 512 byte. thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> In the udc driver, i can't assign a single ep0 descriptor to both >> ep0_in_desc and ep0_out_desc. i think i should skip ep0_out_desc. Bear >> in mind that i only define 3 endpoints in udc driver: ep0, ep1 bulk >> in, ep1 bulk out. Will it cause any problem to gadget driver? > > There is no such thing as an ep0 descriptor. > > Alan Stern When ep1 receives CBW data, the isr routine is called. Then in isr, to get the usb_request: usb_request * req; req = list_entry(dev->ep[2].queue.next, struct kagen2_request, queue); however, the list_empty(&dev->ep[2].queue) is true. Where is the appropriate place to add list entry? thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> When ep1 receives CBW data, the isr routine is called. Then in isr, to >> get the usb_request: >> >> usb_request * req; >> req = list_entry(dev->ep[2].queue.next, struct kagen2_request, queue); >> >> however, the list_empty(&dev->ep[2].queue) is true. Where is the >> appropriate place to add list entry? > > only you will know, but your implementation of ep_queue is a nice bet. i have list_add_tail() in my ep_queue() function. Prior to ep1 receiving data, my ep_queue() is called to send 0x00 to ep0. then it is not called. how to make it to be called by file gadget, in order to queue the request before ep1 interrupt? victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> i have list_add_tail() in my ep_queue() function. Prior to ep1 >> receiving data, my ep_queue() is called to send 0x00 to ep0. then it >> is not called. how to make it to be called by file gadget, in order to >> queue the request before ep1 interrupt? > > This should happen when get_next_command() calls start_transfer(), > which calls usb_ep_queue(). I put printk in fsg_main_thread. After insmod g_file_storage, the fsg_main_thread goes to fsg->running. Then it sleeps. When ep1 receives data, get_next_command() is not called, so start_transfer() is not called. The fsg_main_thread is sleeping in sleep_thread(). How to make it wake up? is there anything udc driver has to do to wake up fsg_main_thread? thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi,
>> I put printk in fsg_main_thread. After insmod g_file_storage, the
>> fsg_main_thread goes to fsg->running. Then it sleeps.
>
> Do you mean that it executes these lines?
>
> if (!fsg->running) {
> sleep_thread(fsg);
> continue;
> }
>
> Here's how it's supposed to work. Initially fsg_main_thread does sleep
> there. But when the host sends a Set-Configuration request,
> standard_setup_req calls raise_exception, which wakes up
> fsg_main_thread (by calling send_sig_info).
>
> The next time though its big loop, fsg_main_thread calls
> handle_exception, which calls do_set_config, which calls
> do_set_interface, which sets fsg->running to 1 (near the end of the
> do_set_interface routine).
>
> Then when fsg_main_thread goes through its big loop again, it will call
> get_next_command.
Thanks, i made a big progress. The udc driver is able to pass the ep1
data (CBW) to gadget driver, and gadget driver handles the data (which
is SCSI Inquiry command), and udc driver is able to send out the reply
and CSW to host.
After that, in get_next_command(), in the statement below, the
bh->state is 2 (BUF_STATE_BUSY), and the get_next_command() goes to
sleep and never wakes up.
while (bh->state != BUF_STATE_EMPTY) {
rc = sleep_thread(fsg);
if (rc)
return rc;
}
How to set "bh->state" to BUF_STATE_EMPTY after the buffer is processed?
victor
--
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: Linux USB file storage gadget with new UDC
Hi,
>> How to set "bh->state" to BUF_STATE_EMPTY after the buffer is processed?
>
> It gets set to BUF_STATE_EMPTY in several different places, depending
> on the purpose the buffer was used for. See bulk_in_complete (your UDC
> driver should call this routine for every request over a bulk-IN
> endpoint, when it is safe for the gadget driver to overwrite the data
> in the transfer buffer and re-use the request). See also
> get_next_command, the line just after the call to received_cbw.
Thanks, i added in UDC driver to call bulk_in_complete for every
request over a bulk in ep, now the gadget driver is able to process
the SCSI Inquiry command. When it comes to SCSI Read Format Capacities
command, the gadget driver gives attention condition error in
check_command() in the code snippet below, and the command is not
processed by do_read_format_capacities().
if (curlun && curlun->unit_attention_data != SS_NO_SENSE &&
fsg->cmnd[0] != INQUIRY &&
fsg->cmnd[0] != REQUEST_SENSE) {
curlun->sense_data = curlun->unit_attention_data;
curlun->unit_attention_data = SS_NO_SENSE;
return -EINVAL;
}
Besides the code snippet, the only place that sets unit_attention data
to SS_NO_SENSE is in handle_exception(). How is UDC driver able to
overcome this problem?
victor
--
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: Linux USB file storage gadget with new UDC
Hi, >> >> How to set "bh->state" to BUF_STATE_EMPTY after the buffer is processed? >> > >> > It gets set to BUF_STATE_EMPTY in several different places, depending >> > on the purpose the buffer was used for. See bulk_in_complete (your UDC >> > driver should call this routine for every request over a bulk-IN >> > endpoint, when it is safe for the gadget driver to overwrite the data >> > in the transfer buffer and re-use the request). See also >> > get_next_command, the line just after the call to received_cbw. >> >> Thanks, i added in UDC driver to call bulk_in_complete for every >> request over a bulk in ep, now the gadget driver is able to process > > UDC shouldn't call bulk_in_complete() directly, you should be calling > request->complete() instead. > Yes, the UDC driver calls the request->complete() which in turn calls the bulk_in_complete(). I am sorry my writing is not clear. victor -- 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: Linux USB file storage gadget with new UDC
Hi,
>>> Thanks, i added in UDC driver to call bulk_in_complete for every
>>> request over a bulk in ep, now the gadget driver is able to process
>>
>> UDC shouldn't call bulk_in_complete() directly, you should be calling
>> request->complete() instead.
>>
>
> Yes, the UDC driver calls the request->complete() which in turn calls
> the bulk_in_complete(). I am sorry my writing is not clear.
>
When it comes to SCSI Read Format Capacities command, the gadget
driver gives attention condition error in
check_command() in the code snippet below, and the command is not
processed by do_read_format_capacities().
if (curlun && curlun->unit_attention_data != SS_NO_SENSE &&
fsg->cmnd[0] != INQUIRY &&
fsg->cmnd[0] != REQUEST_SENSE) {
curlun->sense_data = curlun->unit_attention_data;
curlun->unit_attention_data = SS_NO_SENSE;
return -EINVAL;
}
Besides the code snippet, the only place that sets unit_attention data
to SS_NO_SENSE is in handle_exception(). How is UDC driver able to
overcome this problem? SCSI READ CAPACITY also has the same attention
condition problem. What can i do now?
Victor
--
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: Linux USB file storage gadget with new UDC
Hi,
>> Thanks, i added in UDC driver to call bulk_in_complete for every
>> request over a bulk in ep, now the gadget driver is able to process
>> the SCSI Inquiry command. When it comes to SCSI Read Format Capacities
>> command, the gadget driver gives attention condition error in
>> check_command() in the code snippet below, and the command is not
>> processed by do_read_format_capacities().
>>
>> if (curlun && curlun->unit_attention_data != SS_NO_SENSE &&
>> fsg->cmnd[0] != INQUIRY &&
>> fsg->cmnd[0] != REQUEST_SENSE) {
>> curlun->sense_data = curlun->unit_attention_data;
>> curlun->unit_attention_data = SS_NO_SENSE;
>> return -EINVAL;
>> }
>>
>> Besides the code snippet, the only place that sets unit_attention data
>> to SS_NO_SENSE is in handle_exception(). How is UDC driver able to
>> overcome this problem?
>
> What problem? This all sounds perfectly normal.
>
> Maybe you should post the kernel debugging log.
>
The problem is READ FORMAT CAPACITIES command is not processed, and no
reply is sent back in response to the command.
the kernel log does not show any error that is related to SCSI commands.
thanks,
victor
--
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: Linux USB file storage gadget with new UDC
Hi,
>> I am able to solve the SCSI command timeout problem by adding a code
>> to check the hardware register busy bit continuously, in
>> kagen2_ep_queue():
>>
>> do {
>> read_hardware_register_busy_bit
>> } while (hardware_is_busy)
>
> This is silly. Drivers shouldn't poll in this way. That's what
> interrupts are for.
>
>> however, it causes the linux prompt to be non-responsive because the
>> checking hardware register code is run continuously. If i add a
>> schedule() to the do-while loop, the kagen2_ep_queue() will not be
>> continued. How to go about fixing this dilemma?
>
> I can't say much more without seeing the code. However, you should not
> need to wait for the hardware to do something -- instead the interrupt
> handler routine should be called when the hardware is finished.
Yes, it is silly. The hardware interrupt is not being generated for
every SCSI command received, so the driver has to poll. I put the
polling code in a thread, and this dilemma is fixed.
I still observe the SCSI_WRITE_10 command time out sometimes. When
time out happens, the gadget log shows:
g_file_storage gadget: invalid CBW: len 512 sig 0x6f007442
g_file_storage gadget: bulk-in set wedge
Is it because the gadget expects 31 byte command, but 512 byte data is
received instead?
The full UDC/gadget log is attached. Hope it is useful. If not, i will
add in more printk statements.
Thanks,
victor
EP1 OUT IRQ 0x28
[start_transfer] f8 6005fff0
ept1 out queue len 0x200, buffer 0xc1338000
before kagen2_ep_queue
after kagen2_ep_queue
kagen2_ep_queue 31 512 31
[kagen2_ep_queue] 43425355 4d
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 4d 00 00 00 00 02 00 00 00 00 0a 2a
0010: 00 00 00 00 04 00 00 01 00 00 00 00 00 00 00
EP1 OUT IRQ 0x28
g_file_storage gadget: SCSI command: WRITE(10); Dc=10, Do=512; Hc=10, Ho=512
[start_transfer] 43425355 4d
ept1 out queue len 0x200, buffer 0xc1338000
before kagen2_ep_queue
after kagen2_ep_queue
kagen2_ep_queue 512 512 512
[kagen2_ep_queue] f8 fff0
g_file_storage gadget-lun0: file write 512 @ 2048 -> 512
g_file_storage gadget: before calling send_status
g_file_storage gadget: bulk-in, length 13:
: 55 53 42 53 4d 00 00 00 00 00 00 00 00
[start_transfer] 53425355 4d
ept1 in queue len 0xd, buffer 0xc0c3c000
0: 0x53425355
4: 0x4d
8: 0x0
bulk_in_complete --> 0, 13/13
EP1 OUT IRQ 0x28
[start_transfer] f8 fff0
ept1 out queue len 0x200, buffer 0xc1338000
before kagen2_ep_queue
after kagen2_ep_queue
kagen2_ep_queue 31 512 31
[kagen2_ep_queue] 43425355 4e
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 4e 00 00 00 00 02 00 00 00 00 0a 2a
0010: 00 00 00 00 06 00 00 01 00 00 00 00 00 00 00
EP1 OUT IRQ 0x28
g_file_storage gadget: SCSI command: WRITE(10); Dc=10, Do=512; Hc=10, Ho=512
[start_transfer] 43425355 4e
ept1 out queue len 0x200, buffer 0xc1338000
before kagen2_ep_queue
after kagen2_ep_queue
kagen2_ep_queue 512 512 512
[kagen2_ep_queue] 6f007442 7000
g_file_storage gadget-lun0: file write 512 @ 3072 -> 512
g_file_storage gadget: before calling send_status
g_file_storage gadget: bulk-in, length 13:
: 55 53 42 53 4e 00 00 00 00 00 00 00 00
[start_transfer] 53425355 4e
ept1 in queue len 0xd, buffer 0xc0c3c000
0: 0x53425355
4: 0x4e
8: 0x0
bulk_in_complete --> 0, 13/13
EP1 OUT IRQ 0x28
[start_transfer] 6f007442 7000
ept1 out queue len 0x200, buffer 0xc1338000
before kagen2_ep_queue
after kagen2_ep_queue
kagen2_ep_queue 31 512 31
[kagen2_ep_queue] 43425355 4f
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 4f 00 00 00 00 02 00 00 00 00 0a 2a
0010: 00 00 00 00 02 00 00 01 00 00 00 00 00 00 00
EP1 OUT IRQ 0x28
g_file_storage gadget: SCSI command: WRITE(10); Dc=10, Do=512; Hc=10, Ho=512
[start_transfer] 43425355 4f
ept1 out queue len 0x200, buffer 0xc1338000
before kagen2_ep_queue
after kagen2_ep_queue
kagen2_ep_queue 512 512 512
[kagen2_ep_queue] f8 fff0
g_file_storage gadget-lun0: file write 512 @ 1024 -> 512
g_file_storage gadget: before calling send_status
g_file_storage gadget: bulk-in, length 13:
: 55 53 42 53 4f 00 00 00 00 00 00 00 00
[start_transfer] 53425355 4f
ept1 in queue len 0xd, buffer 0xc0c3c000
0: 0x53425355
4: 0x4f
8: 0x0
bulk_in_complete --> 0, 13/13
[start_transfer] f8 fff0
ept1 out queue len 0x200, buffer 0xc1338000
before kagen2_ep_queue
EP1 OUT IRQ 0x28
after kagen2_ep_queue
kagen2_ep_queue 31 512 31
EP1 OUT IRQ 0x28
[kagen2_ep_queue] 43425355 50
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 50 00 00 00 00 02 00 00 00 00 0a 2a
0010: 00 00 00 00 06 00 00 01 00 00 00 00 00 00 00
g_file_storage gadget: SCSI command: WRITE(10); Dc=10, Do=512; Hc=10, Ho=512
[start_transfer] 43425355 50
ept1 out queue len 0x200, buffer 0xc1338000
before kagen2_ep_queue
after kagen2_ep_queue
kagen2_ep_queue 512 512 512
[kagen2_ep_queue] 6f007442 7000
g_file_storage gadget-lun0: file write 512 @ 3072 -> 512
g_file_storage gadget: before calling send_status
g_file_
Re: Linux USB file storage gadget with new UDC
Hi, >> Yes, it is silly. The hardware interrupt is not being generated for >> every SCSI command received, so the driver has to poll. I put the >> polling code in a thread, and this dilemma is fixed. > > Are you sure about this? If it is correct, you should _fix_ the > interrupt problem. Don't try to work around it by creating a new > thread. > > Figure out why there isn't an interrupt. Does your driver forget to > set an interrupt-enable bit? > >> I still observe the SCSI_WRITE_10 command time out sometimes. When >> time out happens, the gadget log shows: >> >> g_file_storage gadget: invalid CBW: len 512 sig 0x6f007442 >> g_file_storage gadget: bulk-in set wedge >> >> Is it because the gadget expects 31 byte command, but 512 byte data is >> received instead? > > No. It is because kagen2_ep_queue returned _before_ a new command was > received, probably as a result of your polling thread. Since there was > no new command, the data in the buffer was wrong. > >> The full UDC/gadget log is attached. Hope it is useful. If not, i will >> add in more printk statements. > > You can see the problem in the log: > >> g_file_storage gadget: bulk-in, length 13: >> : 55 53 42 53 50 00 00 00 00 00 00 00 00 >> [start_transfer] 53425355 50 >> ept1 in queue len 0xd, buffer 0xc0c3c000 >> 0: 0x53425355 >> 4: 0x50 >> 8: 0x0 >> bulk_in_complete --> 0, 13/13 > > That was the end of the previous command. Now the gadget waits for a > new command to arrive. > >> [start_transfer] 6f007442 7000 >> ept1 out queue len 0x200, buffer 0xc1338000 >> before kagen2_ep_queue >> after kagen2_ep_queue >> kagen2_ep_queue 512 512 512 >> [kagen2_ep_queue] 6f007442 7000 > > kagen2_ep_queue returned but there was no interrupt. This means no new > data was received, so the old data is still in the buffer. > >> g_file_storage gadget: bulk_out_complete --> 0, 512/31 >> g_file_storage gadget: invalid CBW: len 512 sig 0x6f007442 >> g_file_storage gadget: bulk-in set wedge > > That 0x6f007442 is the old data from the previous command, as you can > see from the log messages (it is the same data that was present when > kagen2_ep_queue was called). > Now the UDC driver is working on both Linux and Windows host, meaning the read/write operation is ok. I still use the polling method, because waiting for interrupt is not reliable. Is it possible to contribute the code to Linux community? On the other hand, i run the USB 2.0 command verifier to test the gadget, the gadget crashes at BOS descriptor test. I think the gadget is not able to handle BOS descriptor, is the gadget driver setup function returning negative error code for BOS descriptor? Thanks, victor g_file_storage gadget: high-speed config #1 Unable to handle kernel NULL pointer dereference at virtual address pgd = c0204000 [] *pgd= Internal error: Oops - BUG: 817 [#1] PREEMPT ARM Modules linked in: g_file_storage kagen2_udc ath6kl_sdio ath6kl_core ka2000_sdio ka2000_sdhc CPU: 0Not tainted (3.4.4+ #43) PC is at kagen2_irq+0x290/0x3bc [kagen2_udc] LR is at handle_irq_event_percpu+0x30/0x178 pc : []lr : []psr: 6093 sp : c132de98 ip : 0002 fp : c132debc r10: r9 : r8 : r7 : 0020 r6 : 0002 r5 : 0201 r4 : c12a8c00 r3 : r2 : 0001 r1 : c12a8d1c r0 : Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 0005717f Table: 0130c000 DAC: 0017 Process chkbusy_t (pid: 121, stack limit = 0xc132c270) Stack: (0xc132de98 to 0xc132e000) de80: 0080 0002 dea0: c12b9840 c049cf70 0020 c132dee4 c132dec0 c02496d0 bf02f484 dec0: c049cf70 c132c000 c12b9840 c132df94 c132df04 c132dee8 dee0: c0249878 c02496b0 f5006000 c049cf70 f5006000 c132df1c c132df08 df00: c024bd38 c0249828 c024bc24 0020 c132df34 c132df20 c02490e0 c024bc34 df20: 0040 0020 c132df4c c132df38 c0209c2c c02490c8 bf02f8c0 0013 df40: c132df5c c132df50 c0208410 c0209bd4 c132dfbc c132df60 c0208f14 c0208410 df60: 4000 0288001f c2886000 c12a8c00 c12a8c00 bf02f894 0013 df80: c132dfbc c132c000 c132dfa8 4001 bf02f8c0 dfa0: 0013 c128dd58 c132dff4 c132dfc0 c022f8f4 bf02f8a4 dfc0: c128dd58 c12a8c00 c132dfd0 c132dfd0 c128dd58 dfe0: c022f860 c02191c8 c132dff8 c02191c8 c022f870 08f0 0402 Backtrace: [] (kagen2_irq+0x0/0x3bc [kagen2_udc]) from [] (handle_irq_event_percpu+0x30/0x178) r7:0020 r6: r5:c049cf70 r4:c12b9840 [] (handle_irq_event_percpu+0x0/0x178) from [] (handle_irq_event+0x60/0x7c) [] (handle_irq_event+0x0/0x7c) from [] (handle_edge_irq+0x114/0x16c) r6:f5006000 r5: r4:c049cf70 r3:f5006000 [] (handle_edge_irq+0x0/0x16c) from [] (generic_handle_irq+0x28/0x38) r4:0020 r3:c024bc24 [] (generic_handle_irq+0x0/0x38) from [] (handle_IRQ+0x68/0x8c) r4:0020
Re: Linux USB file storage gadget with new UDC
Hi, >> Is it possible to >> contribute the code to Linux community? > > Yes. But first you should test it with other gadget drivers, not just > g_file_storage. Ok. What other gadget driver can i test with UDC driver? Is it the mass storage driver (mass_storage.c)? Has the g_file_storage passed the USB 2.0 Command Verifier test? >> On the other hand, i run the USB 2.0 command verifier to test the >> gadget, the gadget crashes at BOS descriptor test. I think the gadget >> is not able to handle BOS descriptor, is the gadget driver setup >> function returning negative error code for BOS descriptor? > > The crash dump you attached contained this line: > > PC is at kagen2_irq+0x290/0x3bc [kagen2_udc] > > This means the crash occurred inside the UDC driver, not the gadget > driver. Yes, the problem was solved just now. Thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> Ok. What other gadget driver can i test with UDC driver? Is it the >> mass storage driver (mass_storage.c)? > > That is essentially the same as g_file_storage. But there are lots of > others. You should start with g_zero and run the testusb suite. See > > http://www.linux-usb.org/gadget/ > > and > > http://www.linux-usb.org/usbtest/ > > for more information. Those web pages are pretty old and somewhat out > of date, but they still have useful stuff. I tested the g_zero with USB 2.0 Command Verifier. After the Command Verifier is run, the UDC gadget driver queue function is continuously being called, and the linux command prompt is frozen. Please see the attached UDC driver log. It looks like endpoint 1 in direction is called by USB 2.0 Command Verifier continuously. Is this weird? thanks, victor # insmod kagen2_udc.ko kagen2_init kagen2_plat_probe 1 kagen2_plat_probe 5 kagen2_plat_probe 6, 0xc2886000 0x1000 read pclk scu 7 irqmask ffbd 7fff val is 0x0 val is 0x8 check USB_OTGST 0x51000801 check USB_OTGIRQ 0x51000810 check USB_IRQINIT 0x70007 check USB_OTGFSM 0xa1d191f check USB_OTGCTRL 0x51300801 kagen2_plat_probe 8 register irq 32 kagen2_init 0 # insmod g_zero.ko bind epname ep1 epname ep1 epname ep1 epname ep1 gadget: Gadget Zero, version: Cinco de Mayo 2008 gadget: zero ready usb_gadget_udc_start 0xbf0386b8 0xbf0364c8 kagen2_start 0xbf0386b8 0xbf0364c8 0xc12d2cf0 0xbf030eb0 usb_gadget_connect # ept0 in queue len 0x12, buffer 0xc12d3000 USB_RECIP_DEVICE exit A ept0 in queue len 0x12, buffer 0xc12d3000 ept0 in queue len 0x9, buffer 0xc12d3000 ept0 in queue len 0x4, buffer 0xc12d3000 ept0 in queue len 0x42, buffer 0xc12d3000 ept0 in queue len 0x20, buffer 0xc12d3000 ept0 in queue len 0x4, buffer 0xc12d3000 ept0 in queue len 0x18, buffer 0xc12d3000 ept0 in queue len 0x4, buffer 0xc12d3000 ept0 in queue len 0x18, buffer 0xc12d3000 ept0 in queue len 0x20, buffer 0xc12d3000 ept0 in queue len 0xa, buffer 0xc12d3000 ept0 in queue len 0x9, buffer 0xc12d3000 ept0 in queue len 0x20, buffer 0xc12d3000 ept0 in queue len 0x4, buffer 0xc12d3000 ept0 in queue len 0x3a, buffer 0xc12d3000 ept0 in queue len 0x18, buffer 0xc12d3000 ept0 in queue len 0x42, buffer 0xc12d3000 ept0 in queue len 0x2a, buffer 0xc12d3000 ept0 in queue len 0x2a, buffer 0xc12d3000 ept0 in queue len 0x12, buffer 0xc12d3000 USB_RECIP_DEVICE exit A ept0 in queue len 0x12, buffer 0xc12d3000 ept0 in queue len 0x9, buffer 0xc12d3000 zero gadget: high-speed config #3: source/sink ept1 in queue len 0x1000, buffer 0xc180d000 len_num 4096, iter_num 0 len_num 3584, iter_num 1 len_num 3072, iter_num 2 len_num 2560, iter_num 3 len_num 2048, iter_num 4 len_num 1536, iter_num 5 len_num 1024, iter_num 6 len_num 512, iter_num 7 ept1 in queue len 0x1000, buffer 0xc180d000 len_num 4096, iter_num 0 len_num 3584, iter_num 1 len_num 3072, iter_num 2 len_num 2560, iter_num 3 len_num 2048, iter_num 4 len_num 1536, iter_num 5 len_num 1024, iter_num 6 len_num 512, iter_num 7 ept1 in queue len 0x1000, buffer 0xc180d000 len_num 4096, iter_num 0 len_num 3584, iter_num 1 len_num 3072, iter_num 2 len_num 2560, iter_num 3 len_num 2048, iter_num 4 len_num 1536, iter_num 5 len_num 1024, iter_num 6 len_num 512, iter_num 7 ept1 in queue len 0x1000, buffer 0xc180d000 len_num 4096, iter_num 0 len_num 3584, iter_num 1 len_num 3072, iter_num 2 len_num 2560, iter_num 3 len_num 2048, iter_num 4 len_num 1536, iter_num 5 len_num 1024, iter_num 6 len_num 512, iter_num 7 ept1 in queue len 0x1000, buffer 0xc180d000 len_num 4096, iter_num 0 len_num 3584, iter_num 1 len_num 3072, iter_num 2 len_num 2560, iter_num 3 len_num 2048, iter_num 4 len_num 1536, iter_num 5 len_num 1024, iter_num 6 len_num 512, iter_num 7 ept1 in queue len 0x1000, buffer 0xc180d000 len_num 4096, iter_num 0 len_num 3584, iter_num 1 len_num 3072, iter_num 2 len_num 2560, iter_num 3 len_num 2048, iter_num 4 len_num 1536, iter_num 5 len_num 1024, iter_num 6 len_num 512, iter_num 7 ept1 in queue len 0x1000, buffer 0xc180d000 len_num 4096, iter_num 0 len_num 3584, iter_num 1 len_num 3072, iter_num 2 len_num 2560, iter_num 3 len_num 2048, iter_num 4 len_num 1536, iter_num 5 len_num 1024, iter_num 6 len_num 512, iter_num 7 ept1 in queue len 0x1000, buffer 0xc180d000 len_num 4096, iter_num 0 len_num 3584, iter_num 1 len_num 3072, iter_num 2 len_num 2560, iter_num 3 len_num 2048, iter_num 4 len_num 1536, iter_num 5 len_num 1024, iter_num 6 len_num 512, iter_num 7 ept1 in queue len 0x1000, buffer 0xc180d000 len_num 4096, iter_num 0 len_num 3584, iter_num 1 len_num 3072, iter_num 2 len_num 2560, iter_num 3 len_num 2048, iter_num 4 len_num 1536, iter_num 5 len_num 1024, iter_num 6 len_num 512, iter_num 7
Re: Linux USB file storage gadget with new UDC
Hi, On Thu, May 30, 2013 at 10:44 PM, Alan Stern wrote: > On Thu, 30 May 2013, victor yeo wrote: > >> I tested the g_zero with USB 2.0 Command Verifier. After the Command >> Verifier is run, the UDC gadget driver queue function is continuously >> being called, and the linux command prompt is frozen. Please see the >> attached UDC driver log. It looks like endpoint 1 in direction is >> called by USB 2.0 Command Verifier continuously. Is this weird? > > I don't know. > > You can't tell what's going on just by looking at the gadget. You have > to know what the host is doing as well. > > Alan Stern When i run USB 2.0 Command Verifier on file gadget and UDC driver, an error in Command Verifier says "Device must support being set to Addressed/Configured state". Does it mean the gadget cannot support putting device in addressed state or configured state, as in supporting the Set Address and Set Configuration requests? Thanks, Victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> When i run USB 2.0 Command Verifier on file gadget and UDC driver, an >> error in Command Verifier says "Device must support being set to >> Addressed/Configured state". Does it mean the gadget cannot support >> putting device in addressed state or configured state, as in >> supporting the Set Address and Set Configuration requests? > > I don't know what it means. The gadget _does_ support being set to the > Addressed and Configured states. If it didn't support these things, > you would not have been able to test it at all. > > Alan Stern > The gadget log when Command Verifier says "Device must support being set to Addressed/Configured state" is attached. The log shows get device descriptor, get configuration descriptor, and set configuration requests are received. I see nothing wrong in gadget log. Does the log indicate any problem that corresponds to the error message in Command Verifier? Thanks, victor # dmesg g_file_storage gadget: disconnect or port reset after kagen2_ep_queue kagen2_ep_queue 31 512 31 [kagen2_ep_queue] 43425355 8a47aaf8 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 f8 aa 47 8a 00 00 00 00 00 00 0a 35 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 g_file_storage gadget: SCSI command: SYNCHRONIZE CACHE; Dc=10, Dn=0; Hc=10, Hn=0 attention condition g_file_storage gadget: after calling do_scsi_command g_file_storage gadget: reset config g_file_storage gadget: reset interface g_file_storage gadget: in handle_exception loop g_file_storage gadget: in fsg->running loop g_file_storage gadget: in fsg->running loop g_file_storage gadget: disconnect or port reset g_file_storage gadget: in handle_exception loop g_file_storage gadget: in fsg->running loop g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 12 00 g_file_storage gadget: get device descriptor ept0 in queue len 0x12, buffer 0xc1289800 g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 USB_RECIP_DEVICE g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 12 00 g_file_storage gadget: get device descriptor ept0 in queue len 0x12, buffer 0xc1289800 g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 09 00 g_file_storage gadget: get configuration descriptor ept0 in queue len 0x9, buffer 0xc1289800 g_file_storage gadget: ep0-in, length 9: : 09 02 20 00 01 01 04 c0 01 g_file_storage gadget: ep0-setup, length 8: : 00 09 01 00 00 00 00 00 g_file_storage gadget: set configuration g_file_storage gadget: set interface 0 g_file_storage gadget: high-speed config #1 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 09 00 g_file_storage gadget: get configuration descriptor ept0 in queue len 0x9, buffer 0xc1289800 g_file_storage gadget: ep0-in, length 9: : 09 02 20 00 01 01 04 c0 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 20 00 g_file_storage gadget: get configuration descriptor ept0 in queue len 0x20, buffer 0xc1289800 g_file_storage gadget: ep0-in, length 32: : 09 02 20 00 01 01 04 c0 01 09 04 00 00 02 08 06 0010: 50 05 07 05 81 02 00 02 00 07 05 01 02 00 02 01 g_file_storage gadget: in handle_exception loop [start_transfer] 43425355 8a47aaf8 ept1 out queue len 0x200, buffer 0xc0c44000 before kagen2_ep_queue g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 12 00 g_file_storage gadget: get device descriptor ept0 in queue len 0x12, buffer 0xc1289800 g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 06 00 00 0a 00 g_file_storage gadget: get device qualifier ept0 in queue len 0xa, buffer 0xc1289800 g_file_storage gadget: ep0-in, length 10: : 0a 06 00 02 00 00 00 40 01 00 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 09 00 g_file_storage gadget: get configuration descriptor ept0 in queue len 0x9, buffer 0xc1289800 g_file_storage gadget: ep0-in, length 9: : 09 02 20 00 01 01 04 c0 01 g_file_storage gadget: ep0-setup, length 8: : 80 08 00 00 00 00 01 00 g_file_storage gadget: get configuration ept0 in queue len 0x1, buffer 0xc1289800 g_file_storage gadget: ep0-in, length 1: : 01 g_file_storage gadget: ep0-setup, length 8: : 80 08 00 00 00 00 01 00 g_file_storage gadget: get configuration ept0 in queue len 0x1, buffer 0xc1289800 g_file_storage gadget: ep0-in, length 1: : 01 #
Re: Linux USB file storage gadget with new UDC
Hi,
>> The CV log is attached (Dev_desc_test-Address state.html). Is it helpful?
>
> It doesn't help very much. Can you get a more verbose log, one that
> lists all the transfers?
>
> It looks like the problem could be that the host and the gadget don't
> agree on what packets have been sent and received. If that's true,
> you may need to use a USB bus analyzer to diagnose it.
Unfortunately, that USB 2.0 command verifier is not able to generate a
more verbose log.
>> The "g_file_storage gadget: in handle_exception loop" is from the DBG
>> that i added in fsg_main_thread(). I also attach an updated gadget log
>> file, which corresponds to the CV log. I cannot figure out this part
>> of the code about handle_exception(). Is a signal received and
>> handle_exception() is supposed to perform some action?
>>
>> if (exception_in_progress(fsg) || signal_pending(current)) {
>> handle_exception(fsg);
>> DBG(fsg, "in handle_exception loop\n");
>> continue;
>> }
>
> Okay, now I understand. The "in handle_exception loop" line in the log
> is from an exception that happened earlier, before the
> Get-Config-Descriptor request. The exception was caused by the
> preceding request, Set-Config: The USB_REQ_SET_CONFIGURATION case in
> standard_setup_req() calls raise_exception(). The handle_exception()
> routine then does the real work of changing the configuration, by
> calling do_set_config(). The Get-Config-Descriptor request just
> happened to arrive before your DBG line was executed.
Thanks a lot. i understand this part now. Do you notice the Set
Address request is not seen by the gadget driver? The Set Address
request is handled by the hardware. Could it be the root cause? As
gadget driver may expect the address information from the host, and
for now UDC driver just ignore the Set Address request ?
victor
--
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: Linux USB file storage gadget with new UDC
Hi, >> Thanks a lot. i understand this part now. Do you notice the Set >> Address request is not seen by the gadget driver? The Set Address >> request is handled by the hardware. Could it be the root cause? As >> gadget driver may expect the address information from the host, and >> for now UDC driver just ignore the Set Address request ? > > That may very well be related to the problem. Gadget drivers expect > UDC drivers or UDC hardware to handle Set-Address requests > automatically. If your UDC or driver doesn't handle them, it could > cause a test to fail. The hardware handles Set Address request, and i can see the address of the USB gadget being shown in Windows host. Here i attach the gadget driver log for the "Device Descriptor Test - Addressed State". The test just failed after Get Configuration request. Another question, in ep0_complete(): if (req->status == 0 && req->context) ((fsg_routine_t) (req->context))(fsg); Is req->context pointing to a function in UDC driver? Thanks, victor # dmesg g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 12 00 g_file_storage gadget: get device descriptor ept0 in queue len 0x12, buffer 0xc1289800 ep0_complete g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 06 00 00 0a 00 g_file_storage gadget: get device qualifier ept0 in queue len 0xa, buffer 0xc1289800 ep0_complete g_file_storage gadget: ep0-in, length 10: : 0a 06 00 02 00 00 00 40 01 00 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 09 00 g_file_storage gadget: get configuration descriptor ept0 in queue len 0x9, buffer 0xc1289800 ep0_complete g_file_storage gadget: ep0-in, length 9: : 09 02 20 00 01 01 04 c0 01 g_file_storage gadget: ep0-setup, length 8: : 80 08 00 00 00 00 01 00 g_file_storage gadget: get configuration ept0 in queue len 0x1, buffer 0xc1289800 ep0_complete g_file_storage gadget: ep0-in, length 1: : 01 g_file_storage gadget: ep0-setup, length 8: : 80 08 00 00 00 00 01 00 g_file_storage gadget: get configuration ept0 in queue len 0x1, buffer 0xc1289800 ep0_complete g_file_storage gadget: ep0-in, length 1: : 01 #
Re: Linux USB file storage gadget with new UDC
Hi, >> The hardware handles Set Address request, and i can see the address of >> the USB gadget being shown in Windows host. Here i attach the gadget >> driver log for the "Device Descriptor Test - Addressed State". The >> test just failed after Get Configuration request. > > I can't tell what's wrong. You will have to use a USB bus analyzer. Ok. Today i tested the same mass storage gadget driver on Lenovo x100e Ubuntu. There is a strange problem. After SCSI_READ_10 command data is returned to the Ubuntu host. The gadget driver says: g_file_storage gadget: reset config g_file_storage gadget: reset interface Then the same process to get descriptors and receive SCSI commands are repeated. Is the SCSI_READ_10 command or something else causing the problem? Please see the attached gadget driver log. Thanks, Victor [start_transfer] 0 0 ept1 out queue len 0x200, buffer 0xc134 before kagen2_ep_queue after kagen2_ep_queue kagen2_ep_queue 31 512 31 [kagen2_ep_queue] 43425355 12 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 12 00 00 00 00 10 00 00 80 00 0a 28 0010: 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=4096; Hc=10, Hi=4096 g_file_storage gadget-lun0: file read 4096 @ 0 -> 4096 [start_transfer] 0 0 ept1 in queue len 0x1000, buffer 0xc134 len_num 4096, iter_num 0 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 3584, iter_num 1 0: 0x6d903ceb 4: 0x736f646b 8: 0x7366 c: 0x10402 len_num 3072, iter_num 2 0: 0xf8 4: 0xfff0 8: 0x0 c: 0x0 len_num 2560, iter_num 3 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 2048, iter_num 4 0: 0xf8 4: 0xfff0 8: 0x0 c: 0x0 len_num 1536, iter_num 5 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 1024, iter_num 6 0: 0x6f007442 4: 0x7000 8: 0xf00 c: 0xc100 len_num 512, iter_num 7 0: 0x0 4: 0x0 8: 0x0 c: 0x0 bulk_in_complete --> 0, 4096/4096 g_file_storage gadget: before calling send_status g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 12 00 00 00 00 00 00 00 00 [start_transfer] 53425355 12 ept1 in queue len 0xd, buffer 0xc0c5c000 0: 0x53425355 4: 0x12 8: 0x0 bulk_in_complete --> 0, 13/13 [start_transfer] 0 0 ept1 out queue len 0x200, buffer 0xc134 before kagen2_ep_queue g_file_storage gadget: disconnect or port reset after kagen2_ep_queue kagen2_ep_queue 31 512 31 [kagen2_ep_queue] 43425355 12 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 12 00 00 00 00 10 00 00 80 00 0a 28 0010: 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=4096; Hc=10, Hi=4096 g_file_storage gadget-lun0: file read 4096 @ 0 -> 4096 g_file_storage gadget: after calling do_scsi_command handle_exception begin handle_exception wait until handle_exception old_state 5 g_file_storage gadget: reset config g_file_storage gadget: reset interface g_file_storage gadget: in handle_exception loop g_file_storage gadget: in fsg->running loop g_file_storage gadget: in fsg->running loop g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 40 00 g_file_storage gadget: get device descriptor ept0 in queue len 0x12, buffer 0xc128b800 ep0_complete g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 g_file_storage gadget: disconnect or port reset handle_exception begin handle_exception wait until handle_exception old_state 5 g_file_storage gadget: in handle_exception loop g_file_storage gadget: in fsg->running loop USB_RECIP_DEVICE function address is 0x5d exit A g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 12 00 g_file_storage gadget: get device descriptor ept0 in queue len 0x12, buffer 0xc128b800 ep0_complete g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 06 00 00 0a 00 g_file_storage gadget: get device qualifier ept0 in queue len 0xa, buffer 0xc128b800 ep0_complete g_file_storage gadget: ep0-in, length 10: : 0a 06 00 02 00 00 00 40 01 00 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 09 00 g_file_storage gadget: get configuration descriptor ept0 in queue len 0x9, buffer 0xc128b800 ep0_complete g_file_storage gadget: ep0-in, length 9: : 09 02 20 00 01 01 04 c0 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 20 00 g_file_storage gadget: get configuration descriptor ept0 in queue len 0x20, buffer 0xc128b800 ep0_complete g_file_storage gadget: ep0-in, length 32: : 09 02 20 00 01 01 04 c0 01 09 04 00 00 02 08 06 0010: 50 05 07 05 81 02 00 02 00 07 05 01 02 00 02 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 03 00 00 ff 00 g_file_storage gadget: get string descriptor ept0 in queue len 0x4, buffer 0xc128b800 ep0_complete g_file_storage gadget: ep0-in, length 4: : 04 03 09 04 g_file_storage gadge
Re: Linux USB file storage gadget with new UDC
Hi, > Another possibility is to set up a virtual Windows system inside your > Linux host. Then try running the USB CV program on the virtual > machine, and use usbmon on the host system to capture the USB traffic. > > I don't know if that will work, but it might. Thanks. i will find a way to setup the virtual Windows inside Linux host. >> Ok. Today i tested the same mass storage gadget driver on Lenovo x100e >> Ubuntu. There is a strange problem. After SCSI_READ_10 command data is >> returned to the Ubuntu host. The gadget driver says: >> >> g_file_storage gadget: reset config >> g_file_storage gadget: reset interface >> >> Then the same process to get descriptors and receive SCSI commands are >> repeated. Is the SCSI_READ_10 command or something else causing the >> problem? Please see the attached gadget driver log. > > Perhaps you will recognize this answer (I have sent it several times > before): I can't tell what is happening without seeing _both_ the log > file on the gadget _and_ the usbmon trace on the host. > > Alan Stern > Yes, the matching gadget log and usbmon trace are attached in this email. From the usbmon trace, the error (-108) is ESHUTDOWN from SCSI_READ_10 command. From the gadget log, the last SCSI_READ_10 command is received twice. First time it is ok, second time it causes some problem. Which side could cause the ESHUTDOWN error? Thanks, victor [start_transfer] 43425355 35 ept1 out queue len 0x200, buffer 0xc0c44000 before kagen2_ep_queue after kagen2_ep_queue kagen2_ep_queue 31 512 31 [kagen2_ep_queue] 43425355 36 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 36 00 00 00 12 00 00 00 80 00 06 03 0010: 00 00 00 12 00 00 00 00 00 00 00 00 00 00 00 g_file_storage gadget: SCSI command: REQUEST SENSE; Dc=6, Di=18; Hc=6, Hi=18 g_file_storage gadget: bulk-in, length 18: : 70 00 06 00 00 00 00 0a 00 00 00 00 29 00 00 00 0010: 00 00 [start_transfer] 60070 a00 ept1 in queue len 0x12, buffer 0xc0c44000 0: 0x60070 4: 0xa00 8: 0x0 c: 0x29 bulk_in_complete --> 0, 18/18 g_file_storage gadget: before calling send_status g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 36 00 00 00 00 00 00 00 00 [start_transfer] 53425355 36 ept1 in queue len 0xd, buffer 0xc1338000 0: 0x53425355 4: 0x36 8: 0x0 bulk_in_complete --> 0, 13/13 [start_transfer] 60070 a00 ept1 out queue len 0x200, buffer 0xc0c44000 before kagen2_ep_queue after kagen2_ep_queue kagen2_ep_queue 31 512 31 [kagen2_ep_queue] 43425355 37 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 37 00 00 00 00 10 00 00 80 00 0a 28 0010: 00 00 00 00 18 00 00 08 00 00 00 00 00 00 00 g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=4096; Hc=10, Hi=4096 g_file_storage gadget-lun0: file read 4096 @ 12288 -> 4096 [start_transfer] 0 0 ept1 in queue len 0x1000, buffer 0xc0c44000 len_num 4096, iter_num 0 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 3584, iter_num 1 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 3072, iter_num 2 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 2560, iter_num 3 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 2048, iter_num 4 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 1536, iter_num 5 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 1024, iter_num 6 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 512, iter_num 7 0: 0x0 4: 0x0 8: 0x0 c: 0x0 bulk_in_complete --> 0, 4096/4096 g_file_storage gadget: before calling send_status g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 37 00 00 00 00 00 00 00 00 [start_transfer] 53425355 37 ept1 in queue len 0xd, buffer 0xc1338000 0: 0x53425355 4: 0x37 8: 0x0 bulk_in_complete --> 0, 13/13 [start_transfer] 0 0 ept1 out queue len 0x200, buffer 0xc0c44000 before kagen2_ep_queue after kagen2_ep_queue kagen2_ep_queue 31 512 31 [kagen2_ep_queue] 43425355 38 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 38 00 00 00 00 10 00 00 80 00 0a 28 0010: 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=4096; Hc=10, Hi=4096 g_file_storage gadget-lun0: file read 4096 @ 0 -> 4096 [start_transfer] 0 0 ept1 in queue len 0x1000, buffer 0xc0c44000 len_num 4096, iter_num 0 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 3584, iter_num 1 0: 0x6d903ceb 4: 0x736f646b 8: 0x7366 c: 0x10402 len_num 3072, iter_num 2 0: 0xf8 4: 0xfff0 8: 0x0 c: 0x0 len_num 2560, iter_num 3 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 2048, iter_num 4 0: 0xf8 4: 0xfff0 8: 0x0 c: 0x0 len_num 1536, iter_num 5 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 1024, iter_num 6 0: 0x6f007442 4: 0x7000 8: 0xf00 c: 0xc100 len_num 512, iter_num 7 0: 0x0 4: 0x0 8: 0x0 c: 0x0 bulk_in_complete --> 0, 4096/4096 g_file_storage gadget: before calling send_status g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 38 00 00 00 00 00 00 00 00 [start_transfer] 53425355 38 ept1 in queue len 0xd, buffer 0xc1338000 0: 0x53425355 4: 0x38 8: 0x0 bulk_in_complete --> 0, 13/13 [start_transfer] 0 0 ept1 o
Re: Linux USB file storage gadget with new UDC
Hi, > The usbmon trace shows lots of errors. All those -75 (EOVERFLOW) > status codes mean that the gadget sent a packet that was too large, > i.e., more than 512 bytes. This happened in all the READ(10) commands > except the last one -- none of them succeeded in transferring any data. > > After the last READ(10) command was sent, the usbmon trace shows that > the host's USB port got disabled. Maybe because of the too-long > packets. Whatever the reason, that's why the ESHUTDOWN error occurred. > > The gadget's log does indeed show that the last READ(10) was received > twice. The second time is a bug in the UDC driver. No command was > sent by the host, so the driver should not have reported that a command > was received. > > Alan Stern > I did another usbmon capture from the moment usb cable is plugged into the Ubuntu x100e laptop. This time the usbmon does not have -75 error. When the SCSI_READ_10 command request for 4096 bytes of data, and the data is returned by the gadget, usbmon simply shows -108 error. The gadget driver log and usbmon trace are attached. The FIFO size in gadget bulk out endpoint 1 is 512 bytes, so i break the 4096 bytes of data into 8 chunks of 512 bytes, before returning them to Ubuntu. I guess it would not be the root cause, won't it? thanks, victor # dmesg -c g_file_storage gadget: disconnect or port reset handle_exception begin handle_exception wait until handle_exception old_state 5 g_file_storage gadget: in handle_exception loop g_file_storage gadget: in fsg->running loop g_file_storage gadget: disconnect or port reset handle_exception begin handle_exception wait until handle_exception old_state 5 g_file_storage gadget: in handle_exception loop g_file_storage gadget: in fsg->running loop g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 40 00 g_file_storage gadget: get device descriptor ept0 in queue len 0x12, buffer 0xc128f800 ep0_complete g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 g_file_storage gadget: disconnect or port reset handle_exception begin handle_exception wait until handle_exception old_state 5 g_file_storage gadget: in handle_exception loop g_file_storage gadget: in fsg->running loop USB_RECIP_DEVICE fa is 0x2 exit A g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 12 00 g_file_storage gadget: get device descriptor ept0 in queue len 0x12, buffer 0xc128f800 ep0_complete g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 06 00 00 0a 00 g_file_storage gadget: get device qualifier ept0 in queue len 0xa, buffer 0xc128f800 ep0_complete g_file_storage gadget: ep0-in, length 10: : 0a 06 00 02 00 00 00 40 01 00 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 09 00 g_file_storage gadget: get configuration descriptor ept0 in queue len 0x9, buffer 0xc128f800 ep0_complete g_file_storage gadget: ep0-in, length 9: : 09 02 20 00 01 01 04 c0 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 20 00 g_file_storage gadget: get configuration descriptor ept0 in queue len 0x20, buffer 0xc128f800 ep0_complete g_file_storage gadget: ep0-in, length 32: : 09 02 20 00 01 01 04 c0 01 09 04 00 00 02 08 06 0010: 50 05 07 05 81 02 00 02 00 07 05 01 02 00 02 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 03 00 00 ff 00 g_file_storage gadget: get string descriptor ept0 in queue len 0x4, buffer 0xc128f800 ep0_complete g_file_storage gadget: ep0-in, length 4: : 04 03 09 04 g_file_storage gadget: ep0-setup, length 8: : 80 06 02 03 09 04 ff 00 g_file_storage gadget: get string descriptor ept0 in queue len 0x36, buffer 0xc128f800 ep0_complete g_file_storage gadget: ep0-in, length 54: : 36 03 46 00 69 00 6c 00 65 00 2d 00 62 00 61 00 0010: 63 00 6b 00 65 00 64 00 20 00 53 00 74 00 6f 00 0020: 72 00 61 00 67 00 65 00 20 00 47 00 61 00 64 00 0030: 67 00 65 00 74 00 g_file_storage gadget: ep0-setup, length 8: : 80 06 01 03 09 04 ff 00 g_file_storage gadget: get string descriptor ept0 in queue len 0x3a, buffer 0xc128f800 ep0_complete g_file_storage gadget: ep0-in, length 58: : 3a 03 4c 00 69 00 6e 00 75 00 78 00 20 00 33 00 0010: 2e 00 34 00 2e 00 34 00 2b 00 20 00 77 00 69 00 0020: 74 00 68 00 20 00 6b 00 61 00 67 00 65 00 6e 00 0030: 32 00 5f 00 75 00 73 00 62 00 g_file_storage gadget: ep0-setup, length 8: : 00 09 01 00 00 00 00 00 g_file_storage gadget: set configuration handle_exception begin handle_exception wait until handle_exception old_state 4 g_file_storage gadget: set interface 0 g_file_storage gadget: high-speed config #1 g_file_storage gadget: ep0-setup, length 8: : 80 06 04 03 09 04 ff 00 g_file_storage gadget: get string descriptor ept0 in queue len 0x1a, buffer 0xc12
Re: Linux USB file storage gadget with new UDC
Hi, >> I did another usbmon capture from the moment usb cable is plugged into >> the Ubuntu x100e laptop. This time the usbmon does not have -75 error. >> When the SCSI_READ_10 command request for 4096 bytes of data, and the >> data is returned by the gadget, usbmon simply shows -108 error. The >> gadget driver log and usbmon trace are attached. > > Again, the -108 indicates that the host controller disabled the port. > The usbmon trace confirms this. I think the most common reason for > disabling a port in this way is that the device tried to transmit a > packet across a microframe boundary. > >> The FIFO size in gadget bulk out endpoint 1 is 512 bytes, so i break >> the 4096 bytes of data into 8 chunks of 512 bytes, before returning >> them to Ubuntu. I guess it would not be the root cause, won't it? > > It's hard to say without looking at the signals on the wire. Are you > certain the hardware really is sending 512 bytes for each chunk? > That's why you need to use a bus analyzer -- to see what's actually > going on. I have an important finding. When the problem (SCSI_READ_10 command reads 4096 bytes of data, causing gadget to reset) happens, the PC shows that the gadget is detected as Full-speed device, but gadget reports that it is set to High-speed from: g_file_storage gadget: high-speed config #1 This is printed from do_set_config() in file_storage.c. In UDC driver, it is hardcorded to high speed in UDC driver start function. I changed it to be set depending on hardware value. Now it is: g_file_storage gadget: full-speed config #1 However, in usbmon, the SCSI_READ_10 command still requests for 4096 bytes of data, and this causes gadget to reset. Please see the gadget log, and usbmon trace, and host dmesg log. Thanks, Victor [ 3427.328908] usb 1-5.2: new full speed USB device using ehci_hcd and address 7 [ 3427.421804] usb 1-5.2: not running at top speed; connect to a high speed hub [ 3427.455274] usb-storage 1-5.2:1.0: Quirks match for vid 0525 pid a4a5: 1 [ 3427.457117] scsi3 : usb-storage 1-5.2:1.0 [ 3428.896784] usb 1-5.2: reset full speed USB device using ehci_hcd and address 7 f33fa400 1314593130 C Ci:1:007:0 0 9 = 09022000 010104c0 01 f33fa400 1314593147 S Ci:1:007:0 s 80 06 0200 0020 32 < f33fa400 1314593752 C Ci:1:007:0 0 32 = 09022000 010104c0 01090400 00020806 50050705 81024000 00070501 0240 f33fa400 1314593791 S Ci:1:007:0 s 80 06 0300 00ff 255 < f33fa400 1314594502 C Ci:1:007:0 0 4 = 04030904 f33fa400 1314594519 S Ci:1:007:0 s 80 06 0302 0409 00ff 255 < f33fa400 1314595120 C Ci:1:007:0 0 54 = 36034600 69006c00 65002d00 62006100 63006b00 65006400 20005300 74006f00 f33fa400 1314595918 S Ci:1:007:0 s 80 06 0301 0409 00ff 255 < f33fa400 1314596884 C Ci:1:007:0 0 58 = 3a034c00 69006e00 75007800 20003300 2e003400 2e003400 2b002000 77006900 f33fa400 1314597660 S Co:1:007:0 s 00 09 0001 0 f33fa400 1314598122 C Co:1:007:0 0 0 f33fa400 1314599768 S Ci:1:007:0 s 80 06 0304 0409 00ff 255 < f33fa400 1314612251 C Ci:1:007:0 0 26 = 1a035300 65006c00 66002d00 70006f00 77006500 72006500 6400 f2e1ee00 1314612435 S Ci:1:007:0 s 80 06 0305 0409 00ff 255 < f2e1ee00 1314613115 C Ci:1:007:0 0 26 = 1a034d00 61007300 73002000 53007400 6f007200 61006700 6500 f33a1380 1315254841 S Co:1:003:0 s 23 03 0016 0302 0 f33a1380 1315255168 C Co:1:003:0 0 0 f2e1e400 1315646807 S Ci:1:007:0 s a1 fe 0001 1 < f2e1e400 1315647355 C Ci:1:007:0 0 1 = 00 f2e1e400 1315655086 S Bo:1:007:1 -115 31 = 55534243 0100 2400 8612 0024 00 f2e1e400 1315655351 C Bo:1:007:1 0 31 > f2ed1a00 1315655414 S Bi:1:007:1 -115 36 < f2ed1a00 1315657108 C Bi:1:007:1 0 36 = 0202 1f00 4c696e75 78202020 46696c65 2d53746f 72204761 64676574 f2e1e400 1315657185 S Bi:1:007:1 -115 13 < f2e1e400 1315666355 C Bi:1:007:1 0 13 = 55534253 0100 00 f2e1e400 1315708514 S Bo:1:007:1 -115 31 = 55534243 0200 0600 00 f2e1e400 1315708845 C Bo:1:007:1 0 31 > f2e1e400 1315708919 S Bi:1:007:1 -115 13 < f2e1e400 1315718221 C Bi:1:007:1 0 13 = 55534253 0200 01 f2e1e400 1315718323 S Bo:1:007:1 -115 31 = 55534243 0300 1200 8603 0012 00 f2e1e400 1315718460 C Bo:1:007:1 0 31 > f2ed1700 1315718501 S Bi:1:007:1 -115 18 < f2ed1700 1315728467 C Bi:1:007:1 0 18 = 7600 000a 2900 f2e1e400 1315728630 S Bi:1:007:1 -115 13 < f2e1e400 1315737728 C Bi:1:007:1 0 13 = 55534253 0300 00 f2e1e400 1315738087 S Bo:1:007:1 -115 31 = 55534243 0400 0600 00 f2e1e400 1315738959 C Bo:1:007:1 0 31 > f2e1e400 1315739098 S Bi:1:007:1 -115 13 < f2e1e400 1315748116 C Bi:1:007:1 0 13 = 55534253 0400 00 f2e1e400 1315748392 S Bo:1:007:1 -115 31 = 55534243 0500 0800 8a25 00 f2e1e400 1315748596 C Bo:1:007:1 0 31 > f33faa00 1315748619 S Bi:1:007:1 -115
Re: Linux USB file storage gadget with new UDC
Hi, >> There is a mistake in the previous log file, because the fifo size is >> still set to 512 byte. Now i change it to 64 byte if it is Full speed. > > The FIFO size should always be set to the value in the endpoint > descriptor, no matter what speed the connection is. > >> The log file are attached. > > The log shows that your 64-byte transfers don't work very well. The > first one didn't send any bytes. The second one sent only 4 bytes. > And each of the ones after that sent 0 bytes. > > Alan Stern > > PS: Something was very wrong with the log file you posted. It is full > of bad characters. You can it here: Yes, i see the bad characters in the log file. I apologize for that, my eyes was in pain after looking thru the log files and did not notice that when i attached the log file. The good news is i can get gadget to work with Lenovo x100e on Ubuntu and Windows. The change is adding more delay after writing to endpoint one IN FIFO register, for the case of writing more than the endpoint buffer size. However, the gadget only work on high-speed mode. If i disable ehci_hcd driver in Ubuntu (force it to be full speed), the same problem of SCSI_READ_10 command asking 4096 bytes and gadget returning the data, and gadget reset, still happens. Thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, > Yes, i see the bad characters in the log file. I apologize for that, > my eyes was in pain after looking thru the log files and did not > notice that when i attached the log file. > > The good news is i can get gadget to work with Lenovo x100e on Ubuntu > and Windows. The change is adding more delay after writing to endpoint > one IN FIFO register, for the case of writing more than the endpoint > buffer size. However, the gadget only work on high-speed mode. If i > disable ehci_hcd driver in Ubuntu (force it to be full speed), the > same problem of SCSI_READ_10 command asking 4096 bytes and gadget > returning the data, and gadget reset, still happens. I can bring up the gadget in full speed mode now, so the SCSI_READ_10 command problem is fixed. It is caused by an error interfacing to hardware. Now there is another problem with SCSI_MODE_SELECT_6 command, when in full speed mode, the data for SCSI_MODE_SELECT_6 command is 72 byte, and somehow the gadget is reset. Is it because gadget is not able to handle the amount of data? Please see the attached gadget log. Normally, in high speed mode, the data of SCSI_MODE_SELECT_6 command is 24 byte. Thanks, victor g_file_storage gadget: reset config g_file_storage gadget: reset interface g_file_storage gadget: in handle_exception loop g_file_storage gadget: in fsg->running loop g_file_storage gadget: in fsg->running loop g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 40 00 g_file_storage gadget: get device descriptor ept0 in queue len 0x12, buffer 0xc128f800 ep0_complete g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 g_file_storage gadget: disconnect or port reset handle_exception begin handle_exception wait until handle_exception old_state 5 g_file_storage gadget: in handle_exception loop g_file_storage gadget: in fsg->running loop USB_RECIP_DEVICE fa is 0x3 exit A g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 12 00 g_file_storage gadget: get device descriptor exit C ept0 in queue len 0x12, buffer 0xc128f800 ep0_complete g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 09 00 g_file_storage gadget: get configuration descriptor ept0 in queue len 0x9, buffer 0xc128f800 ep0_complete g_file_storage gadget: ep0-in, length 9: : 09 02 20 00 01 01 04 c0 01 g_file_storage gadget: ep0-setup, length 8: : 00 09 01 00 00 00 00 00 g_file_storage gadget: set configuration handle_exception begin handle_exception wait until handle_exception old_state 4 g_file_storage gadget: set interface 0 g_file_storage gadget: full-speed config #1 EP1 OUT IRQ 0x28 ept0 in queue len 0x0, buffer 0xc128f800 g_file_storage gadget: in handle_exception loop [start_transfer] 800 0 ept1 out queue len 0x40, buffer 0xc134 before kagen2_ep_queue after kagen2_ep_queue kagen2_ep_queue 31 64 31 EP1 OUT IRQ 0x28 [kagen2_ep_queue] 43425355 87a68008 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 08 80 a6 87 18 00 00 00 00 00 06 15 0010: 10 00 00 18 00 00 00 00 00 00 00 00 00 00 00 g_file_storage gadget: SCSI command: MODE SELECT(6); Dc=6, Do=24; Hc=6, Ho=24 attention condition [start_transfer] 43425355 87a68008 ept1 out queue len 0x40, buffer 0xc134 before kagen2_ep_queue after kagen2_ep_queue kagen2_ep_queue 24 64 24 before kagen2_ep_queue g_file_storage gadget: disconnect or port reset after kagen2_ep_queue kagen2_ep_queue 48 64 24 before kagen2_ep_queue after kagen2_ep_queue kagen2_ep_queue 72 64 24 [kagen2_ep_queue] 800 0 g_file_storage gadget: bulk-out, length 72: : 00 00 00 08 00 00 00 00 00 00 02 00 08 0a 00 00 0010: ff ff 00 00 ff ff ff ff 00 00 00 00 00 00 00 5f 0020: c1 9f 75 00 58 1d 00 00 00 00 00 00 02 00 00 00 0030: 01 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 0040: 80 00 29 5f 22 e8 c2 4e g_file_storage gadget: bulk_out_complete --> 0, 72/24 g_file_storage gadget: before calling send_status g_file_storage gadget: sending command-failure status g_file_storage gadget: sense data: SK x06, ASC x29, ASCQ x00; info x0 g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 08 80 a6 87 18 00 00 00 01 [start_transfer] 53425355 87a68008 exit C ept1 in queue len 0xd, buffer 0xc135 0: 0x53425355 4: 0x87a68008 8: 0x18 bulk_in_complete --> 0, 13/13 handle_exception begin handle_exception wait until handle_exception old_state 5 g_file_storage gadget: reset config g_file_storage gadget: reset interface g_file_storage gadget: in handle_exception loop g_file_storage gadget: in fsg->running loop g_file_storage gadget: in fsg->running loop g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 40 00 g_file_storage gadget: get device descriptor ept0 in queue len 0x12, buffer 0xc128f800 ep0_complete g_file_storage gadget: ep0-in, length 18
Re: Linux USB file storage gadget with new UDC
Hi, >> Yes, i see the bad characters in the log file. I apologize for that, >> my eyes was in pain after looking thru the log files and did not >> notice that when i attached the log file. >> >> The good news is i can get gadget to work with Lenovo x100e on Ubuntu >> and Windows. The change is adding more delay after writing to endpoint >> one IN FIFO register, for the case of writing more than the endpoint >> buffer size. However, the gadget only work on high-speed mode. If i >> disable ehci_hcd driver in Ubuntu (force it to be full speed), the >> same problem of SCSI_READ_10 command asking 4096 bytes and gadget >> returning the data, and gadget reset, still happens. > > I can bring up the gadget in full speed mode now, so the SCSI_READ_10 > command problem is fixed. It is caused by an error interfacing to > hardware. > > Now there is another problem with SCSI_MODE_SELECT_6 command, when in > full speed mode, the data for SCSI_MODE_SELECT_6 command is 72 byte, > and somehow the gadget is reset. Is it because gadget is not able to > handle the amount of data? Please see the attached gadget log. > Normally, in high speed mode, the data of SCSI_MODE_SELECT_6 command > is 24 byte. The problem is in UDC driver. i made the change, it is ok now. Thanks, victor -- 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: Linux USB file storage gadget with new UDC
Hi, >> The problem is in UDC driver. i made the change, it is ok now. > > Good. I noticed that the usb_ep_set_wedge routine still isn't working > right. You might try to fix that. > > Alan Stern > Ok, is the usb_ep_set_wedge routine not working? I can't see that in the log file. Now, in USB 2.0 CV test, there is an error about GET_STATUS request, as shown below. g_file_storage gadget: ep0-setup, length 8: : 82 00 00 00 81 00 02 00 g_file_storage gadget: unknown control req 82.00 v i0081 l2 handle_setup status -95 I think the GET_STATUS request is not handled by the gadget driver. Isn't it so? thanks, victor -- 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
