Re: Linux USB file storage gadget with new UDC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 9 Apr 2013, victor yeo wrote:

> Hi,
> 
> > Earlier, you complained that your gadget was able to read the boot
> > sector but not the MBR!  :-)
> >
> > How do you know the reads were sending all zeros?  The usbmon output
> > shows only the first 32 bytes of each transfer, and the gadget
> > debugging output doesn't show the data for READ or WRITE commands at
> > all.
> >
> > What makes you think the gadget isn't reading the boot sector?  What is
> > the boot sector's LBA (logical block address)?
> 
> 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;
		}

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux