Re: Bug in DWC2 UDC driver on Raspberry PI [was: g_mass_storage emulation of flash drive - difficulties with passing vendor/product ID]

[Alan Robertson]

On Tue, Jul 11, 2017 at 7:29 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Tue, 11 Jul 2017, Alan Robertson wrote:
>
>> Hi Alan
>>
>> Yes, have read about that now and certainly external build would
>> definitely be quicker.
>>
>> However - GREAT NEWS!!!  The update to 4.9.36+ seems to have done the trick 
>> :)
>>
>> See new dmesg...
>> [6.131569] 2098.usb supply vusb_d not found, using dummy regulator
>> [6.131853] 2098.usb supply vusb_a not found, using dummy regulator
>> [6.224457] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
>> [6.621834] dwc2 2098.usb: EPs: 8, dedicated fifos, 4080 entries in 
>> SPRAM
>> [6.624073] dwc2 2098.usb: DWC OTG Controller
>> [6.624161] dwc2 2098.usb: new USB bus registered, assigned bus 
>> number 1
>> [6.624238] dwc2 2098.usb: irq 33, io mem 0x
>> [6.624602] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
>> [6.624619] usb usb1: New USB device strings: Mfr=3, Product=2,
>> SerialNumber=1
>> [6.624629] usb usb1: Product: DWC OTG Controller
>> [6.624639] usb usb1: Manufacturer: Linux 4.9.36+ dwc2_hsotg
>> [6.624648] usb usb1: SerialNumber: 2098.usb
>> [6.625894] hub 1-0:1.0: USB hub found
>> [6.625986] hub 1-0:1.0: 1 port detected
>> [7.555421] usbcore: registered new interface driver brcmfmac
>> [7.838601] brcmfmac: Firmware version = wl0: May 27 2016 00:13:38
>> version 7.45.41.26 (r640327) FWID 01-df77e4a7
>> [8.005836] systemd-journald[113]: Received request to flush
>> runtime journal from PID 1
>> [   10.192605] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
>> [   10.192643] brcmfmac: power management disabled
>> [   11.155348] uart-pl011 20201000.serial: no DMA platform data
>> [   12.677636] Adding 102396k swap on /var/swap.  Priority:-1
>> extents:4 across:241660k SSFS
>> [   13.991319] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
>> [   15.718015] Bluetooth: Core ver 2.22
>> [   15.718147] NET: Registered protocol family 31
>> [   15.718154] Bluetooth: HCI device and connection manager initialized
>> [   15.719660] Bluetooth: HCI socket layer initialized
>> [   15.719683] Bluetooth: L2CAP socket layer initialized
>> [   15.719740] Bluetooth: SCO socket layer initialized
>> [   15.755080] Bluetooth: HCI UART driver ver 2.3
>> [   15.755097] Bluetooth: HCI UART protocol H4 registered
>> [   15.755102] Bluetooth: HCI UART protocol Three-wire (H5) registered
>> [   15.755300] Bluetooth: HCI UART protocol Broadcom registered
>> [   16.384300] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
>> [   16.384312] Bluetooth: BNEP filters: protocol multicast
>> [   16.384341] Bluetooth: BNEP socket layer initialized
>> [   30.810852] Mass Storage Function, version: 2009/09/11
>> [   30.810882] LUN: removable file: (no medium)
>> [   30.811154] LUN: removable file: /home/pi/piusb.bin
>> [   30.811166] Number of LUNs=1
>> [   30.811433] g_mass_storage gadget: Mass Storage Gadget, version: 
>> 2009/09/11
>> [   30.811451] g_mass_storage gadget: g_mass_storage ready
>> [   30.811468] dwc2 2098.usb: bound driver g_mass_storage
>> [  252.357976] dwc2 2098.usb: new device is full-speed
>> [  252.418061] dwc2 2098.usb: new device is full-speed
>> [  252.439667] dwc2 2098.usb: new address 1
>> [  252.538245] dwc2 2098.usb: new device is full-speed
>> [  252.598321] dwc2 2098.usb: new device is full-speed
>> [  252.619670] dwc2 2098.usb: new address 2
>> [  254.059693] g_mass_storage gadget: full-speed config #1: Linux
>> File-Backed Storage
>>
>> I've quite happily booted it and moved it between Systems 1-4, it is
>> read perfectly in each one, saves without a problem.  Work when
>> directly powered from it too.  No need to plug into Windows laptop or
>> System 1 first.  I thought it was particularly interesting that it
>> connected at full-speed when it was low-speed before (that you had
>> identified as a bug, Alan).
>>
>> Delighted to finally have it working - thanks for your help.  I had
>> tried apt-get dist-upgrade previously but always ran into issues, at
>> least this gave me a drive to try and work out a bit more why it
>> wasn't working and it was clearly worth it to solve the dwc2 issue!
>
> Okay -- congratulations!  You probably won't even need all those extra
> parameters to make g_mass_storage look just like the Cruzer flash
> drive.  :-)

Haha no, indeed not - will try it in a more basic form tomorrow,
although I'll miss my old fake Cruzer flash drive!!

A.
--
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: Bug in DWC2 UDC driver on Raspberry PI [was: g_mass_storage emulation of flash drive - difficulties with passing vendor/product ID]

[Alan Robertson]

On Tue, Jul 11, 2017 at 2:42 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Mon, 10 Jul 2017, Alan Robertson wrote:
>
>> OK have now updated to kernel 4.9.36+, unfortunately g_mass_storage
>> isn't working at all in that!  apt-get upgrade gave me 4.9.35+ then
>> rpi-update got me to 4.9.36+.  Unfortunately getting a kernel panic on
>> boot (even on fresh install) when g_mass_storage trying to load (have
>> posted about it at
>> https://www.raspberrypi.org/forums/viewtopic.php?f=28=188046).  It
>> looks like only 4.9.36+ is available on rpi-update, so will need to
>> look into how to compile a newer kernel to see if that helps, although
>> frustrating it's not even working on this version.
>
> Note that you don't have to build the kernel on a Raspberry Pi.  With
> the proper tools installed, you can build it on any Linux computer and
> then write it to the SD card.  That should speed things up quite a bit.

Hi Alan

Yes, have read about that now and certainly external build would
definitely be quicker.

However - GREAT NEWS!!!  The update to 4.9.36+ seems to have done the trick :)

See new dmesg...
[6.131569] 2098.usb supply vusb_d not found, using dummy regulator
[6.131853] 2098.usb supply vusb_a not found, using dummy regulator
[6.224457] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[6.621834] dwc2 2098.usb: EPs: 8, dedicated fifos, 4080 entries in SPRAM
[6.624073] dwc2 2098.usb: DWC OTG Controller
[6.624161] dwc2 2098.usb: new USB bus registered, assigned bus number 1
[6.624238] dwc2 2098.usb: irq 33, io mem 0x
[6.624602] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[6.624619] usb usb1: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[6.624629] usb usb1: Product: DWC OTG Controller
[6.624639] usb usb1: Manufacturer: Linux 4.9.36+ dwc2_hsotg
[6.624648] usb usb1: SerialNumber: 2098.usb
[6.625894] hub 1-0:1.0: USB hub found
[6.625986] hub 1-0:1.0: 1 port detected
[7.555421] usbcore: registered new interface driver brcmfmac
[7.838601] brcmfmac: Firmware version = wl0: May 27 2016 00:13:38
version 7.45.41.26 (r640327) FWID 01-df77e4a7
[8.005836] systemd-journald[113]: Received request to flush
runtime journal from PID 1
[   10.192605] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   10.192643] brcmfmac: power management disabled
[   11.155348] uart-pl011 20201000.serial: no DMA platform data
[   12.677636] Adding 102396k swap on /var/swap.  Priority:-1
extents:4 across:241660k SSFS
[   13.991319] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[   15.718015] Bluetooth: Core ver 2.22
[   15.718147] NET: Registered protocol family 31
[   15.718154] Bluetooth: HCI device and connection manager initialized
[   15.719660] Bluetooth: HCI socket layer initialized
[   15.719683] Bluetooth: L2CAP socket layer initialized
[   15.719740] Bluetooth: SCO socket layer initialized
[   15.755080] Bluetooth: HCI UART driver ver 2.3
[   15.755097] Bluetooth: HCI UART protocol H4 registered
[   15.755102] Bluetooth: HCI UART protocol Three-wire (H5) registered
[   15.755300] Bluetooth: HCI UART protocol Broadcom registered
[   16.384300] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   16.384312] Bluetooth: BNEP filters: protocol multicast
[   16.384341] Bluetooth: BNEP socket layer initialized
[   30.810852] Mass Storage Function, version: 2009/09/11
[   30.810882] LUN: removable file: (no medium)
[   30.811154] LUN: removable file: /home/pi/piusb.bin
[   30.811166] Number of LUNs=1
[   30.811433] g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11
[   30.811451] g_mass_storage gadget: g_mass_storage ready
[   30.811468] dwc2 2098.usb: bound driver g_mass_storage
[  252.357976] dwc2 2098.usb: new device is full-speed
[  252.418061] dwc2 2098.usb: new device is full-speed
[  252.439667] dwc2 2098.usb: new address 1
[  252.538245] dwc2 2098.usb: new device is full-speed
[  252.598321] dwc2 2098.usb: new device is full-speed
[  252.619670] dwc2 2098.usb: new address 2
[  254.059693] g_mass_storage gadget: full-speed config #1: Linux
File-Backed Storage

I've quite happily booted it and moved it between Systems 1-4, it is
read perfectly in each one, saves without a problem.  Work when
directly powered from it too.  No need to plug into Windows laptop or
System 1 first.  I thought it was particularly interesting that it
connected at full-speed when it was low-speed before (that you had
identified as a bug, Alan).

Delighted to finally have it working - thanks for your help.  I had
tried apt-get dist-upgrade previously but always ran into issues, at
least this gave me a drive to try and work out a bit more why it
wasn't working and it was clearly worth it to solve the dwc2 issue!

Cheers

Alan
--
To unsubscribe from this list: send the line "unsubscribe l

Re: Bug in DWC2 UDC driver on Raspberry PI [was: g_mass_storage emulation of flash drive - difficulties with passing vendor/product ID]

[Alan Robertson]

On Mon, Jul 10, 2017 at 11:09 PM, Alan Robertson
<clinicalit...@gmail.com> wrote:
> On Mon, Jul 10, 2017 at 5:43 PM, Alan Robertson <clinicalit...@gmail.com> 
> wrote:
>> On Mon, Jul 10, 2017 at 3:46 PM, Alan Stern <st...@rowland.harvard.edu> 
>> wrote:
>>> On Mon, 10 Jul 2017, Alan Robertson wrote:
>>>
>>>> On Sat, Jul 8, 2017 at 5:26 PM, Alan Robertson <clinicalit...@gmail.com> 
>>>> wrote:
>>>> > On Sat, Jul 8, 2017 at 4:52 PM, Alan Stern <st...@rowland.harvard.edu> 
>>>> > wrote:
>>>> >> On Sat, 8 Jul 2017, Alan Robertson wrote:
>>>> >>
>>>> >>> On Sat, Jul 8, 2017 at 2:04 AM, Alan Stern <st...@rowland.harvard.edu> 
>>>> >>> wrote:
>>>> >>> > On Fri, 7 Jul 2017, Alan Robertson wrote:
>>>> >>> >
>>>> >>> >> Sorry to return to this topic & appreciate it might be either 
>>>> >>> >> specific
>>>> >>> >> to either the Pi or the system(s) I'm connecting it to, but have now
>>>> >>> >> had time to try a few more combinations out and would appreciate any
>>>> >>> >> thoughts from the experts here.
>>>> >>> >>
>>>> >>> >> To give some extra background - I've got the Pi configured to
>>>> >>> >> automatically overwrite the mass storage device filestore upon boot,
>>>> >>> >> so it is always presenting a fresh filesystem.  Each system below is
>>>> >>> >> made by a different manufacturer and is a closed system, so I have 
>>>> >>> >> no
>>>> >>> >> ability to perform any diagnostics at that end.
>>>> >>> >>
>>>> >>> >> System 1 - Always works
>>>> >>> >> System 2 - Shows no USB stick connected
>>>> >>> >> System 3 - Gives error when trying to save (memory error)
>>>> >>> >> System 4 - Says unidentified USB
>>>> >>> >> (Windows PC - Always works)
>>>> >>> >> (Linux PC - Always works)
>>>> >>> >>
>>>> >>> >> At first I thought this was due to minor subtleties of how the
>>>> >>> >> g_mass_storage device was being presented as a standard Sandisk USB
>>>> >>> >> memory stick works fine in all systems.
>>>> >>> >>
>>>> >>> >> However I then started to notice some unusual behaviour, if rather
>>>> >>> >> than doing a reboot (and wiping it fresh), I kept the power running
>>>> >>> >> and moved it between machines.
>>>> >>> >>
>>>> >>> >> If I started with System 1 first, then systems 2, 3, 4 would all
>>>> >>> >> recognise/write to it OK.
>>>
>>> ...
>>>
>>>> OK I've had another play about with things this afternoon and
>>>> annotated the dmesg outputs to describe what I was doing at each
>>>> point.
>>>>
>>>> I haven't yet tried to recompile the kernel as that seems a slightly
>>>> slow process on the Pi (due to processing speed) and it make take me a
>>>> few goes to get it right - I thought I'd just check back initially in
>>>> case these logs provide sufficient clues!  Obviously if not then I'll
>>>> look into that more.
>>>>
>>>> The key bit to my untrained eye seemed to be that until the line
>>>> 'g_mass_storage gadget: high-speed config #1: Linux File-Backed
>>>> Storage' appears, the Pi is unreadable by Systems 2-4.  After that has
>>>> appeared in then appears to be readable, even though when connecting
>>>> to System 2 it (understandably and correctly) shows as low-speed
>>>> instead.  Stop/start g_mass_storage doesn't appear to make a
>>>> difference.
>>>
>>> I agree.  In fact, your logs seem to indicate pretty clearly that the
>>> problem doesn't lie in g_mass_storage at all, but rather in the dwc2
>>> USB Device Controller driver.  I have CC'ed the maintainer of the dwc2
>>> driver.
>>>
>>> Here's the first log:
>>>
>>>> [   15.891896] Mass Storage Function, version: 2009/09/11
>>>> [   15.891929] LUN: removable file: (no medium)
>&g

Re: Bug in DWC2 UDC driver on Raspberry PI [was: g_mass_storage emulation of flash drive - difficulties with passing vendor/product ID]

[Alan Robertson]

On Mon, Jul 10, 2017 at 5:43 PM, Alan Robertson <clinicalit...@gmail.com> wrote:
> On Mon, Jul 10, 2017 at 3:46 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
>> On Mon, 10 Jul 2017, Alan Robertson wrote:
>>
>>> On Sat, Jul 8, 2017 at 5:26 PM, Alan Robertson <clinicalit...@gmail.com> 
>>> wrote:
>>> > On Sat, Jul 8, 2017 at 4:52 PM, Alan Stern <st...@rowland.harvard.edu> 
>>> > wrote:
>>> >> On Sat, 8 Jul 2017, Alan Robertson wrote:
>>> >>
>>> >>> On Sat, Jul 8, 2017 at 2:04 AM, Alan Stern <st...@rowland.harvard.edu> 
>>> >>> wrote:
>>> >>> > On Fri, 7 Jul 2017, Alan Robertson wrote:
>>> >>> >
>>> >>> >> Sorry to return to this topic & appreciate it might be either 
>>> >>> >> specific
>>> >>> >> to either the Pi or the system(s) I'm connecting it to, but have now
>>> >>> >> had time to try a few more combinations out and would appreciate any
>>> >>> >> thoughts from the experts here.
>>> >>> >>
>>> >>> >> To give some extra background - I've got the Pi configured to
>>> >>> >> automatically overwrite the mass storage device filestore upon boot,
>>> >>> >> so it is always presenting a fresh filesystem.  Each system below is
>>> >>> >> made by a different manufacturer and is a closed system, so I have no
>>> >>> >> ability to perform any diagnostics at that end.
>>> >>> >>
>>> >>> >> System 1 - Always works
>>> >>> >> System 2 - Shows no USB stick connected
>>> >>> >> System 3 - Gives error when trying to save (memory error)
>>> >>> >> System 4 - Says unidentified USB
>>> >>> >> (Windows PC - Always works)
>>> >>> >> (Linux PC - Always works)
>>> >>> >>
>>> >>> >> At first I thought this was due to minor subtleties of how the
>>> >>> >> g_mass_storage device was being presented as a standard Sandisk USB
>>> >>> >> memory stick works fine in all systems.
>>> >>> >>
>>> >>> >> However I then started to notice some unusual behaviour, if rather
>>> >>> >> than doing a reboot (and wiping it fresh), I kept the power running
>>> >>> >> and moved it between machines.
>>> >>> >>
>>> >>> >> If I started with System 1 first, then systems 2, 3, 4 would all
>>> >>> >> recognise/write to it OK.
>>
>> ...
>>
>>> OK I've had another play about with things this afternoon and
>>> annotated the dmesg outputs to describe what I was doing at each
>>> point.
>>>
>>> I haven't yet tried to recompile the kernel as that seems a slightly
>>> slow process on the Pi (due to processing speed) and it make take me a
>>> few goes to get it right - I thought I'd just check back initially in
>>> case these logs provide sufficient clues!  Obviously if not then I'll
>>> look into that more.
>>>
>>> The key bit to my untrained eye seemed to be that until the line
>>> 'g_mass_storage gadget: high-speed config #1: Linux File-Backed
>>> Storage' appears, the Pi is unreadable by Systems 2-4.  After that has
>>> appeared in then appears to be readable, even though when connecting
>>> to System 2 it (understandably and correctly) shows as low-speed
>>> instead.  Stop/start g_mass_storage doesn't appear to make a
>>> difference.
>>
>> I agree.  In fact, your logs seem to indicate pretty clearly that the
>> problem doesn't lie in g_mass_storage at all, but rather in the dwc2
>> USB Device Controller driver.  I have CC'ed the maintainer of the dwc2
>> driver.
>>
>> Here's the first log:
>>
>>> [   15.891896] Mass Storage Function, version: 2009/09/11
>>> [   15.891929] LUN: removable file: (no medium)
>>> [   15.892120] LUN: removable file: /home/pi/piusb.bin
>>> [   15.892135] Number of LUNs=1
>>> [   15.894168] g_mass_storage gadget: Mass Storage Gadget, version: 
>>> 2009/09/11
>>> [   15.894200] g_mass_storage gadget: g_mass_storage ready
>>> [   15.894245] dwc2 2098.usb: dwc2_hsotg_enqueue_setup: failed queue 
>>> (-11)
>>> [   15.897276] dwc2 2098.usb: 

Re: Bug in DWC2 UDC driver on Raspberry PI [was: g_mass_storage emulation of flash drive - difficulties with passing vendor/product ID]

[Alan Robertson]

On Mon, Jul 10, 2017 at 3:46 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Mon, 10 Jul 2017, Alan Robertson wrote:
>
>> On Sat, Jul 8, 2017 at 5:26 PM, Alan Robertson <clinicalit...@gmail.com> 
>> wrote:
>> > On Sat, Jul 8, 2017 at 4:52 PM, Alan Stern <st...@rowland.harvard.edu> 
>> > wrote:
>> >> On Sat, 8 Jul 2017, Alan Robertson wrote:
>> >>
>> >>> On Sat, Jul 8, 2017 at 2:04 AM, Alan Stern <st...@rowland.harvard.edu> 
>> >>> wrote:
>> >>> > On Fri, 7 Jul 2017, Alan Robertson wrote:
>> >>> >
>> >>> >> Sorry to return to this topic & appreciate it might be either specific
>> >>> >> to either the Pi or the system(s) I'm connecting it to, but have now
>> >>> >> had time to try a few more combinations out and would appreciate any
>> >>> >> thoughts from the experts here.
>> >>> >>
>> >>> >> To give some extra background - I've got the Pi configured to
>> >>> >> automatically overwrite the mass storage device filestore upon boot,
>> >>> >> so it is always presenting a fresh filesystem.  Each system below is
>> >>> >> made by a different manufacturer and is a closed system, so I have no
>> >>> >> ability to perform any diagnostics at that end.
>> >>> >>
>> >>> >> System 1 - Always works
>> >>> >> System 2 - Shows no USB stick connected
>> >>> >> System 3 - Gives error when trying to save (memory error)
>> >>> >> System 4 - Says unidentified USB
>> >>> >> (Windows PC - Always works)
>> >>> >> (Linux PC - Always works)
>> >>> >>
>> >>> >> At first I thought this was due to minor subtleties of how the
>> >>> >> g_mass_storage device was being presented as a standard Sandisk USB
>> >>> >> memory stick works fine in all systems.
>> >>> >>
>> >>> >> However I then started to notice some unusual behaviour, if rather
>> >>> >> than doing a reboot (and wiping it fresh), I kept the power running
>> >>> >> and moved it between machines.
>> >>> >>
>> >>> >> If I started with System 1 first, then systems 2, 3, 4 would all
>> >>> >> recognise/write to it OK.
>
> ...
>
>> OK I've had another play about with things this afternoon and
>> annotated the dmesg outputs to describe what I was doing at each
>> point.
>>
>> I haven't yet tried to recompile the kernel as that seems a slightly
>> slow process on the Pi (due to processing speed) and it make take me a
>> few goes to get it right - I thought I'd just check back initially in
>> case these logs provide sufficient clues!  Obviously if not then I'll
>> look into that more.
>>
>> The key bit to my untrained eye seemed to be that until the line
>> 'g_mass_storage gadget: high-speed config #1: Linux File-Backed
>> Storage' appears, the Pi is unreadable by Systems 2-4.  After that has
>> appeared in then appears to be readable, even though when connecting
>> to System 2 it (understandably and correctly) shows as low-speed
>> instead.  Stop/start g_mass_storage doesn't appear to make a
>> difference.
>
> I agree.  In fact, your logs seem to indicate pretty clearly that the
> problem doesn't lie in g_mass_storage at all, but rather in the dwc2
> USB Device Controller driver.  I have CC'ed the maintainer of the dwc2
> driver.
>
> Here's the first log:
>
>> [   15.891896] Mass Storage Function, version: 2009/09/11
>> [   15.891929] LUN: removable file: (no medium)
>> [   15.892120] LUN: removable file: /home/pi/piusb.bin
>> [   15.892135] Number of LUNs=1
>> [   15.894168] g_mass_storage gadget: Mass Storage Gadget, version: 
>> 2009/09/11
>> [   15.894200] g_mass_storage gadget: g_mass_storage ready
>> [   15.894245] dwc2 2098.usb: dwc2_hsotg_enqueue_setup: failed queue 
>> (-11)
>> [   15.897276] dwc2 2098.usb: bound driver g_mass_storage
>> CONNECTED TO SYSTEM 2
>> [  263.798965] dwc2 2098.usb: new device is low-speed
>> [  269.497623] dwc2 2098.usb: new device is low-speed
>> [  275.115548] dwc2 2098.usb: new device is low-speed
>> STILL NOT SHOWING UP ON SYSTEM 2 SO UNPLUGGED
>> (no extra message)
>
> Connecting at low speed is definitely a bug.  The UDC driver should
> have connected

Re: g_mass_storage emulation of flash drive - difficulties with passing vendor/product ID

[Alan Robertson]

On Sat, Jul 8, 2017 at 5:26 PM, Alan Robertson <clinicalit...@gmail.com> wrote:
> On Sat, Jul 8, 2017 at 4:52 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
>> On Sat, 8 Jul 2017, Alan Robertson wrote:
>>
>>> On Sat, Jul 8, 2017 at 2:04 AM, Alan Stern <st...@rowland.harvard.edu> 
>>> wrote:
>>> > On Fri, 7 Jul 2017, Alan Robertson wrote:
>>> >
>>> >> Sorry to return to this topic & appreciate it might be either specific
>>> >> to either the Pi or the system(s) I'm connecting it to, but have now
>>> >> had time to try a few more combinations out and would appreciate any
>>> >> thoughts from the experts here.
>>> >>
>>> >> To give some extra background - I've got the Pi configured to
>>> >> automatically overwrite the mass storage device filestore upon boot,
>>> >> so it is always presenting a fresh filesystem.  Each system below is
>>> >> made by a different manufacturer and is a closed system, so I have no
>>> >> ability to perform any diagnostics at that end.
>>> >>
>>> >> System 1 - Always works
>>> >> System 2 - Shows no USB stick connected
>>> >> System 3 - Gives error when trying to save (memory error)
>>> >> System 4 - Says unidentified USB
>>> >> (Windows PC - Always works)
>>> >> (Linux PC - Always works)
>>> >>
>>> >> At first I thought this was due to minor subtleties of how the
>>> >> g_mass_storage device was being presented as a standard Sandisk USB
>>> >> memory stick works fine in all systems.
>>> >>
>>> >> However I then started to notice some unusual behaviour, if rather
>>> >> than doing a reboot (and wiping it fresh), I kept the power running
>>> >> and moved it between machines.
>>> >>
>>> >> If I started with System 1 first, then systems 2, 3, 4 would all
>>> >> recognise/write to it OK.
>>> >>
>>> >> I then copied a backup of the filesystem after it had been in System 1
>>> >> - however that still didn't seem to solve the problem after a reboot.
>>> >> What I did then notice though was that if I powered the Pi up and then
>>> >> first connected it to a Windows system it then worked fine when
>>> >> plugged in to the others.  To be clear I didn't read/write any files
>>> >> to the device, just started it up, then plugged it into Windows, saw
>>> >> the home directory on the USB open, then unplugged it and plugged it
>>> >> into one of the other systems - they all now recognised it.
>>> >>
>>> >> I tried starting/stopping g_mass_storage but that in itself didn't
>>> >> seem to do it.
>>> >
>>> > Sorry, this is unclear.
>>> >
>>> >  1. By starting/stopping g_mass_storage, do you mean doing:
>>> >
>>> > rmmod g_mass_storage
>>> > modprobe g_mass_storage file=...
>>>
>>> Yes - at least I believe I've effectively been doing the same albeit a
>>> slightly different version of stopping...
>>> sudo modprobe -rv g_mass_storage
>>
>> That's basically the same as rmmod g_mass_storage.
>
> Good, that's what I hoped.
>
>>> and then to start...
>>> sudo modprobe g_mass_storage file=/home/pi/piusb.bin stall=0
>>> removable=1 idVendor=0x0781 idProduct=0x5572 bcdDevice=0x0126
>>> iManufacturer="SanDisk" iProduct="Cruzer Switch"
>>> iSerialNumber="4C597515973308202393"
>>>
>>>
>>> >  2. Did you start/stop g_mass_storage after plugging the device
>>> > into a Windows system or System 1?  Or did you do this after
>>> > booting the device but not plugging it into anything?
>>>
>>> Upon startup it mounts the filesystem as read-only:
>>> sudo losetup -o 1048576 /dev/loop0 /home/pi/piusb.bin
>>> sudo mount -t vfat -r /dev/loop0 /mnt
>>>
>>> Then copies contents off, unmounts it, overwrites pisub.bin with
>>> backup blank filesystem, then remounts the filesystem read-only again
>>> and starts USB.
>>
>> This does not answer the question I asked.  Had you plugged the device
>> into a Windows system or System 1 before you stopped/started
>> g_mass_storage?
>
> Ah, sorry - I was providing this info to help answer th

Re: g_mass_storage emulation of flash drive - difficulties with passing vendor/product ID

[Alan Robertson]

On Mon, Jul 10, 2017 at 11:07 AM, Felipe Balbi
 wrote:
>
> Hi,
>
> Paul Zimmerman  writes:
> > Did you try enabling verbose debugging in g_mass_storage?  This
> > requires setting CONFIG_USB_GADGET_DEBUG and CONFIG_USB_GADGET_VERBOSE
> > in the kernel configuration and then rebuilding g_mass_storage.ko.
> > And at runtime you may need to enable dynamic debugging by doing
> >
> > echo 'module g_mass_storage =p' 
> > >/sys/kernel/dynamic_debug/control
> >
> > before plugging the device into anything.  Then compare the contents of
> > the dmesg log for the different scenarios.  In particular, look for
> > differences between plugging it into System 2 (say) right after boot
> > vs. after plugging it into System 1.
>
> OK interesting - I'll need to do some searching to understand how to
> change that and rebuild g_mass_storage.ko but I like the idea of
> seeing more detail about what is happening as the systems are closed
> so I'm unable to do any troubleshooting at that end.

 Do you have any experience in building a kernel for the Raspberry Pi?
 The procedure is explained on several web sites, but you have to know
 what you're doing.
>>>
>>> No I don't - I'll have a read over things to see what I can suss out.
>>
>> The 'Linux File-Stor Gadget' string is part of the SCSI inquiry data, and
>> is set by the fsg_common_set_inquiry_string() function in f_mass_storage.c.
>> This must be what the problematic host systems are reacting to, and not any
>> of the USB info that you have overridden. It looks like there is a way to
>> override this string using configfs, perhaps Alan will know how to do this.
>
> There should be a file named "inquiry_string" on mass storage's function
> directory:
>
> # find /c/usb_gadget/storage/functions/mass_storage.1/
> /c/usb_gadget/storage/functions/mass_storage.1/
> /c/usb_gadget/storage/functions/mass_storage.1/lun.0
> /c/usb_gadget/storage/functions/mass_storage.1/lun.0/inquiry_string
> /c/usb_gadget/storage/functions/mass_storage.1/lun.0/nofua
> /c/usb_gadget/storage/functions/mass_storage.1/lun.0/cdrom
> /c/usb_gadget/storage/functions/mass_storage.1/lun.0/removable
> /c/usb_gadget/storage/functions/mass_storage.1/lun.0/ro
> /c/usb_gadget/storage/functions/mass_storage.1/lun.0/file
> /c/usb_gadget/storage/functions/mass_storage.1/stall
>
> Just write your string to it:
>
> # echo "My Inquiry String" > 
> /c/usb_gadget/storage/functions/mass_storage.1/lun.0/inquiry_string

Thanks Felipe & Paul - that's useful to know and I'll have a wee play
about with it to see if I can get it showing more consistently.
However now I can get it working reliably with plugging it into
another system first I suspect that this isn't quite the problem - I'm
about to reply to Alan's message shortly with dmesg logs to see if
that helps clarify things at all!

Cheers

Alan
--
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: g_mass_storage emulation of flash drive - difficulties with passing vendor/product ID

[Alan Robertson]

On Sat, Jul 8, 2017 at 4:52 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Sat, 8 Jul 2017, Alan Robertson wrote:
>
>> On Sat, Jul 8, 2017 at 2:04 AM, Alan Stern <st...@rowland.harvard.edu> wrote:
>> > On Fri, 7 Jul 2017, Alan Robertson wrote:
>> >
>> >> Sorry to return to this topic & appreciate it might be either specific
>> >> to either the Pi or the system(s) I'm connecting it to, but have now
>> >> had time to try a few more combinations out and would appreciate any
>> >> thoughts from the experts here.
>> >>
>> >> To give some extra background - I've got the Pi configured to
>> >> automatically overwrite the mass storage device filestore upon boot,
>> >> so it is always presenting a fresh filesystem.  Each system below is
>> >> made by a different manufacturer and is a closed system, so I have no
>> >> ability to perform any diagnostics at that end.
>> >>
>> >> System 1 - Always works
>> >> System 2 - Shows no USB stick connected
>> >> System 3 - Gives error when trying to save (memory error)
>> >> System 4 - Says unidentified USB
>> >> (Windows PC - Always works)
>> >> (Linux PC - Always works)
>> >>
>> >> At first I thought this was due to minor subtleties of how the
>> >> g_mass_storage device was being presented as a standard Sandisk USB
>> >> memory stick works fine in all systems.
>> >>
>> >> However I then started to notice some unusual behaviour, if rather
>> >> than doing a reboot (and wiping it fresh), I kept the power running
>> >> and moved it between machines.
>> >>
>> >> If I started with System 1 first, then systems 2, 3, 4 would all
>> >> recognise/write to it OK.
>> >>
>> >> I then copied a backup of the filesystem after it had been in System 1
>> >> - however that still didn't seem to solve the problem after a reboot.
>> >> What I did then notice though was that if I powered the Pi up and then
>> >> first connected it to a Windows system it then worked fine when
>> >> plugged in to the others.  To be clear I didn't read/write any files
>> >> to the device, just started it up, then plugged it into Windows, saw
>> >> the home directory on the USB open, then unplugged it and plugged it
>> >> into one of the other systems - they all now recognised it.
>> >>
>> >> I tried starting/stopping g_mass_storage but that in itself didn't
>> >> seem to do it.
>> >
>> > Sorry, this is unclear.
>> >
>> >  1. By starting/stopping g_mass_storage, do you mean doing:
>> >
>> > rmmod g_mass_storage
>> > modprobe g_mass_storage file=...
>>
>> Yes - at least I believe I've effectively been doing the same albeit a
>> slightly different version of stopping...
>> sudo modprobe -rv g_mass_storage
>
> That's basically the same as rmmod g_mass_storage.

Good, that's what I hoped.

>> and then to start...
>> sudo modprobe g_mass_storage file=/home/pi/piusb.bin stall=0
>> removable=1 idVendor=0x0781 idProduct=0x5572 bcdDevice=0x0126
>> iManufacturer="SanDisk" iProduct="Cruzer Switch"
>> iSerialNumber="4C597515973308202393"
>>
>>
>> >  2. Did you start/stop g_mass_storage after plugging the device
>> > into a Windows system or System 1?  Or did you do this after
>> > booting the device but not plugging it into anything?
>>
>> Upon startup it mounts the filesystem as read-only:
>> sudo losetup -o 1048576 /dev/loop0 /home/pi/piusb.bin
>> sudo mount -t vfat -r /dev/loop0 /mnt
>>
>> Then copies contents off, unmounts it, overwrites pisub.bin with
>> backup blank filesystem, then remounts the filesystem read-only again
>> and starts USB.
>
> This does not answer the question I asked.  Had you plugged the device
> into a Windows system or System 1 before you stopped/started
> g_mass_storage?

Ah, sorry - I was providing this info to help answer the second part
of your question 'did you do this after booting the device'.

I did not start/stop g_mass_storage before or after plugging it into a
Windows system or System 1.  I simply let it run through its normal
boot process, then plugged it into Windows PC (or System 1), then
unplugged from there and plugged into any of the other systems.  If I
omitted the step of plugging into WPC/Sys1 it would then not be
recognised by Sys2

Re: g_mass_storage emulation of flash drive - difficulties with passing vendor/product ID

[Alan Robertson]

On Sat, Jul 8, 2017 at 2:04 AM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Fri, 7 Jul 2017, Alan Robertson wrote:
>
>> Sorry to return to this topic & appreciate it might be either specific
>> to either the Pi or the system(s) I'm connecting it to, but have now
>> had time to try a few more combinations out and would appreciate any
>> thoughts from the experts here.
>>
>> To give some extra background - I've got the Pi configured to
>> automatically overwrite the mass storage device filestore upon boot,
>> so it is always presenting a fresh filesystem.  Each system below is
>> made by a different manufacturer and is a closed system, so I have no
>> ability to perform any diagnostics at that end.
>>
>> System 1 - Always works
>> System 2 - Shows no USB stick connected
>> System 3 - Gives error when trying to save (memory error)
>> System 4 - Says unidentified USB
>> (Windows PC - Always works)
>> (Linux PC - Always works)
>>
>> At first I thought this was due to minor subtleties of how the
>> g_mass_storage device was being presented as a standard Sandisk USB
>> memory stick works fine in all systems.
>>
>> However I then started to notice some unusual behaviour, if rather
>> than doing a reboot (and wiping it fresh), I kept the power running
>> and moved it between machines.
>>
>> If I started with System 1 first, then systems 2, 3, 4 would all
>> recognise/write to it OK.
>>
>> I then copied a backup of the filesystem after it had been in System 1
>> - however that still didn't seem to solve the problem after a reboot.
>> What I did then notice though was that if I powered the Pi up and then
>> first connected it to a Windows system it then worked fine when
>> plugged in to the others.  To be clear I didn't read/write any files
>> to the device, just started it up, then plugged it into Windows, saw
>> the home directory on the USB open, then unplugged it and plugged it
>> into one of the other systems - they all now recognised it.
>>
>> I tried starting/stopping g_mass_storage but that in itself didn't
>> seem to do it.
>
> Sorry, this is unclear.
>
>  1. By starting/stopping g_mass_storage, do you mean doing:
>
> rmmod g_mass_storage
> modprobe g_mass_storage file=...

Yes - at least I believe I've effectively been doing the same albeit a
slightly different version of stopping...
sudo modprobe -rv g_mass_storage

and then to start...
sudo modprobe g_mass_storage file=/home/pi/piusb.bin stall=0
removable=1 idVendor=0x0781 idProduct=0x5572 bcdDevice=0x0126
iManufacturer="SanDisk" iProduct="Cruzer Switch"
iSerialNumber="4C597515973308202393"


>  2. Did you start/stop g_mass_storage after plugging the device
> into a Windows system or System 1?  Or did you do this after
> booting the device but not plugging it into anything?

Upon startup it mounts the filesystem as read-only:
sudo losetup -o 1048576 /dev/loop0 /home/pi/piusb.bin
sudo mount -t vfat -r /dev/loop0 /mnt

Then copies contents off, unmounts it, overwrites pisub.bin with
backup blank filesystem, then remounts the filesystem read-only again
and starts USB.

I didn't do anything when plugging into Windows system or System 1 -
just started up, plugged into one of those, unplugged and then plugged
into one of the other systems.


>  3. By "that in itself didn't seem to do it", do you mean that
> starting/stopping g_mass_storage resulted in no change to the
> behavior?  Or did it always lead to a failure when the device
> was attached to systems 2 - 4, even if it had been plugged into
> System 1 before the start/stop?

Correct - the only way I could get it to work with systems 2-4 was if
it had been initially started up then plugged into PC or system 1.
Obviously not ideal given I was hopeful a unit could remain plugged
into each system, just starting up whenever the system booted.

>> To be honest I'm now a bit flummoxed!  It is clearly able to work with
>> all 4 systems (I've been able to save files from them), but it seems
>> to want to be plugged into either a PC or System 1 first before then
>> working with the others.  Can anyone think of anything that is
>> happening when I do this?  Unfortunately the idea of doing it this way
>> is just not workable for what I'm wanting to do.  Ideally I would have
>> 1 Pi for each system, plugged into it just by the one USB data/power
>> cable such that when the system powered on the Pi booted and then the
>> USB was available to it to read/write.
>
> Did you try enabling verbose debugging in g_mass_storage?  T

Re: g_mass_storage emulation of flash drive - difficulties with passing vendor/product ID

[Alan Robertson]

On Tue, Jun 6, 2017 at 3:33 PM, Alan Robertson <clinicalit...@gmail.com> wrote:
> On Tue, Jun 6, 2017 at 3:03 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
>> On Mon, 5 Jun 2017, Alan Robertson wrote:
>>> > Try changing bcdDevice to a valid number, and change the serial number
>>> > string to something different from what you were using before.
>>>
>>> Have changed both and also cleared Windows USB cache with DriveCleanup
>>> from www.uwe-sieber.de (which forces redetection).  Eject removable
>>> media is showing as Cruzer Switch, but it is still showing as "Linux
>>> File-Stor Gadget USB Device" in device manager (and as File-Stor on
>>> other non-Windows devices I tried).
>>>
>>> I'm guessing we've now changed all that's changeable with
>>> g_mass_storage but happy to take any further suggestions! - something
>>> is still making it appear subtly different to systems cf a native USB
>>> flash drive :(
>>
>> It's hard to say what that could be.  From your description, the gadget
>> does not send any information to the host that could identify it as a
>> Linux-based gadget.
>
> Agree in lsusb -v there's nothing obvious, but the way File-Stor is
> coming up on router & KDE and Windows is also identifying as that
> (even after clearing devices and changing SN) make me think there must
> be something that is still 'giving the game away'!  Sadly I've got no
> control of the devices I'm trying to use this in, I just know that
> they're not recognising this as a valid memory stick when they will
> happily recognise any other actual sticks that I try to use in them.
>

Sorry to return to this topic & appreciate it might be either specific
to either the Pi or the system(s) I'm connecting it to, but have now
had time to try a few more combinations out and would appreciate any
thoughts from the experts here.

To give some extra background - I've got the Pi configured to
automatically overwrite the mass storage device filestore upon boot,
so it is always presenting a fresh filesystem.  Each system below is
made by a different manufacturer and is a closed system, so I have no
ability to perform any diagnostics at that end.

System 1 - Always works
System 2 - Shows no USB stick connected
System 3 - Gives error when trying to save (memory error)
System 4 - Says unidentified USB
(Windows PC - Always works)
(Linux PC - Always works)

At first I thought this was due to minor subtleties of how the
g_mass_storage device was being presented as a standard Sandisk USB
memory stick works fine in all systems.

However I then started to notice some unusual behaviour, if rather
than doing a reboot (and wiping it fresh), I kept the power running
and moved it between machines.

If I started with System 1 first, then systems 2, 3, 4 would all
recognise/write to it OK.

I then copied a backup of the filesystem after it had been in System 1
- however that still didn't seem to solve the problem after a reboot.
What I did then notice though was that if I powered the Pi up and then
first connected it to a Windows system it then worked fine when
plugged in to the others.  To be clear I didn't read/write any files
to the device, just started it up, then plugged it into Windows, saw
the home directory on the USB open, then unplugged it and plugged it
into one of the other systems - they all now recognised it.

I tried starting/stopping g_mass_storage but that in itself didn't
seem to do it.

To be honest I'm now a bit flummoxed!  It is clearly able to work with
all 4 systems (I've been able to save files from them), but it seems
to want to be plugged into either a PC or System 1 first before then
working with the others.  Can anyone think of anything that is
happening when I do this?  Unfortunately the idea of doing it this way
is just not workable for what I'm wanting to do.  Ideally I would have
1 Pi for each system, plugged into it just by the one USB data/power
cable such that when the system powered on the Pi booted and then the
USB was available to it to read/write.

Thanks in advance for any thoughts.

Alan
--
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: g_mass_storage emulation of flash drive - difficulties with passing vendor/product ID

[Alan Robertson]

On Tue, Jun 6, 2017 at 3:03 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Mon, 5 Jun 2017, Alan Robertson wrote:
>
>> >> >> USBSTOR\DISK_LINUX_FILE-STOR_GADGET_0404\123456789012&0
>> >
>> > It looks like Windows is remembering an earlier version of your gadget
>> > and matching it with the current version based on the serial number
>> > string.
>>
>> I've changed the SN and still getting it showing as 'File-Stor Gadget'
>> on Linux, Windows, router
>
> When you say "on Linux", you mean in some userspace program (some sort
> of device manager), not in the kernel, right?  Everything the kernel
> knows about the gadget will show up in the "lsusb -v" output and in
> /sys/kernel/debug/usb/devices (assuming you have mounted a debugfs
> filesystem on /sys/kernel/debug).

Sorry, yes - I mean in KDE - when I go to eject it I can see File-Stor mentioned

>> > This all seems to be valid, except for the bcdDevice value.
>>
>> Does the 3/4/5 (vs 1/2/3) number of iManufac/Prod/Serial matter at all?
>
> No, it does not.

OK

>> > Try changing bcdDevice to a valid number, and change the serial number
>> > string to something different from what you were using before.
>>
>> Have changed both and also cleared Windows USB cache with DriveCleanup
>> from www.uwe-sieber.de (which forces redetection).  Eject removable
>> media is showing as Cruzer Switch, but it is still showing as "Linux
>> File-Stor Gadget USB Device" in device manager (and as File-Stor on
>> other non-Windows devices I tried).
>>
>> I'm guessing we've now changed all that's changeable with
>> g_mass_storage but happy to take any further suggestions! - something
>> is still making it appear subtly different to systems cf a native USB
>> flash drive :(
>
> It's hard to say what that could be.  From your description, the gadget
> does not send any information to the host that could identify it as a
> Linux-based gadget.

Agree in lsusb -v there's nothing obvious, but the way File-Stor is
coming up on router & KDE and Windows is also identifying as that
(even after clearing devices and changing SN) make me think there must
be something that is still 'giving the game away'!  Sadly I've got no
control of the devices I'm trying to use this in, I just know that
they're not recognising this as a valid memory stick when they will
happily recognise any other actual sticks that I try to use in them.

> There's one more thing you can try: Use usbmon on a Linux host to
> capture the packet data when the gadget is initialized and configured.

OK will do.

Cheers

Alan
--
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: g_mass_storage emulation of flash drive - difficulties with passing vendor/product ID

[Alan Robertson]

On Mon, Jun 5, 2017 at 9:52 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> [Please use Reply-To-All so that your message gets sent to the mailing
> list as well as to me.]

Oops, apologies - now done!

> On Mon, 5 Jun 2017, Alan Robertson wrote:
>
>> On Mon, Jun 5, 2017 at 3:02 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
>> > On Sun, 4 Jun 2017, Alan Robertson wrote:
>> >
>> >> Hi
>> >>
>> >> Apologies for my first post here being a request for help, but after
>> >> extensive searching online I've not yet been able to find and answer
>> >> and am hopeful the expertise here may be able to help!
>> >>
>> >> I have a Raspberry Pi Zero W that I'm using in OTG/gadget mode. I've
>> >> activated dwc2 USB, partitioned and formatted the file that is to be
>> >> used as filesystem and loaded g_mass_storage.
>> >>
>> >> It is working fine in Windows - I can connect and see the contents,
>> >> add/delete files, eject and reconnect seeing changes fine. I can mount
>> >> it in Raspbian to check contents and can also attach it to other
>> >> devices and interact with it fine.
>> >>
>> >> However, I've got some devices that are very picky about what USB
>> >> devices they will connect to (solely flash drives). The problem is the
>> >> OTG mass storage gadget is being identified as "File-Stor Gadget (Rev:
>> >> 0404)" for device type, which is causing it to be rejected.
>> >>
>> >> I can successfully use a USB flash drive in the target devices and
>> >> have scraped the vendor/product ID, etc from this flash drive to see
>> >> if I can mimic them via g_mass_storage.
>> >>
>> >> I have adjusted modprobe to the following:
>> >>
>> >> $ sudo modprobe g_mass_storage file=/home/pi/piusb.bin stall=0
>> >> removable=1 idVendor=0x0781 idProduct=0x5572 bcdDevice=0x011a
>
> I should point out that this bcdDevice value is not valid (it isn't a
> binary-coded-decimal value).

Thanks, now corrected to 0x0126 - this seems to show up OK in lsusb as 1.26 now

>> >> iManufacturer="SanDisk" iProduct="Cruzer Switch"
>> >> iSerialNumber="123456789012"
>> >>
>> >> Unfortunately this doesn't seem to have made any difference and it is
>> >> still rejected by the target devices.
>> >>
>> >> As far as I can tell the above parameters are getting passed through 
>> >> correctly
>> >> $ ls /sys/module/g_mass_storage/parameters/*
>> >> /sys/module/g_mass_storage/parameters/bcdDevice
>> >> /sys/module/g_mass_storage/parameters/cdrom
>> >> /sys/module/g_mass_storage/parameters/file
>> >> /sys/module/g_mass_storage/parameters/idProduct
>> >> /sys/module/g_mass_storage/parameters/idVendor
>> >> /sys/module/g_mass_storage/parameters/iManufacturer
>> >> /sys/module/g_mass_storage/parameters/iProduct
>> >> /sys/module/g_mass_storage/parameters/iSerialNumber
>> >> /sys/module/g_mass_storage/parameters/luns
>> >> /sys/module/g_mass_storage/parameters/nofua
>> >> /sys/module/g_mass_storage/parameters/removable
>> >> /sys/module/g_mass_storage/parameters/ro
>> >> /sys/module/g_mass_storage/parameters/stall
>> >>
>> >> $ cat /sys/module/g_mass_storage/parameters/*
>> >> 282
>> >> /home/pi/piusb.bin
>> >> 21874
>> >> 1921
>> >> SanDisk
>> >> Cruzer_Switch
>> >> 123456789012
>> >> 0
>> >> Y
>> >> N
>> >>
>> >> However when connecting to Windows, here's what the USB mass storage
>> >> displays - it appears that the iSerialNumber is making it through, but
>> >> nothing else is being altered.  My router shows similar issues,
>> >> identifying it as "File-Stor Gadget (Rev: 0404)"
>> >>
>> >> USBSTOR\DISK_LINUX_FILE-STOR_GADGET_0404\123456789012&0
>
> It looks like Windows is remembering an earlier version of your gadget
> and matching it with the current version based on the serial number
> string.

I've changed the SN and still getting it showing as 'File-Stor Gadget'
on Linux, Windows, router

>> >> USBSTOR\DiskLinux___File-Stor_Gadget0404
>> >> USBSTOR\DiskLinux___File-Stor_Gadget
>> >> USBSTOR\DiskLinux___
>> >> USBSTOR\Linux___File-Stor_Gadget0
>> >>

g_mass_storage emulation of flash drive - difficulties with passing vendor/product ID

[Alan Robertson]

Hi

Apologies for my first post here being a request for help, but after
extensive searching online I've not yet been able to find and answer
and am hopeful the expertise here may be able to help!

I have a Raspberry Pi Zero W that I'm using in OTG/gadget mode. I've
activated dwc2 USB, partitioned and formatted the file that is to be
used as filesystem and loaded g_mass_storage.

It is working fine in Windows - I can connect and see the contents,
add/delete files, eject and reconnect seeing changes fine. I can mount
it in Raspbian to check contents and can also attach it to other
devices and interact with it fine.

However, I've got some devices that are very picky about what USB
devices they will connect to (solely flash drives). The problem is the
OTG mass storage gadget is being identified as "File-Stor Gadget (Rev:
0404)" for device type, which is causing it to be rejected.

I can successfully use a USB flash drive in the target devices and
have scraped the vendor/product ID, etc from this flash drive to see
if I can mimic them via g_mass_storage.

I have adjusted modprobe to the following:

$ sudo modprobe g_mass_storage file=/home/pi/piusb.bin stall=0
removable=1 idVendor=0x0781 idProduct=0x5572 bcdDevice=0x011a
iManufacturer="SanDisk" iProduct="Cruzer Switch"
iSerialNumber="123456789012"

Unfortunately this doesn't seem to have made any difference and it is
still rejected by the target devices.

As far as I can tell the above parameters are getting passed through correctly
$ ls /sys/module/g_mass_storage/parameters/*
/sys/module/g_mass_storage/parameters/bcdDevice
/sys/module/g_mass_storage/parameters/cdrom
/sys/module/g_mass_storage/parameters/file
/sys/module/g_mass_storage/parameters/idProduct
/sys/module/g_mass_storage/parameters/idVendor
/sys/module/g_mass_storage/parameters/iManufacturer
/sys/module/g_mass_storage/parameters/iProduct
/sys/module/g_mass_storage/parameters/iSerialNumber
/sys/module/g_mass_storage/parameters/luns
/sys/module/g_mass_storage/parameters/nofua
/sys/module/g_mass_storage/parameters/removable
/sys/module/g_mass_storage/parameters/ro
/sys/module/g_mass_storage/parameters/stall

$ cat /sys/module/g_mass_storage/parameters/*
282
/home/pi/piusb.bin
21874
1921
SanDisk
Cruzer_Switch
123456789012
0
Y
N

However when connecting to Windows, here's what the USB mass storage
displays - it appears that the iSerialNumber is making it through, but
nothing else is being altered.  My router shows similar issues,
identifying it as "File-Stor Gadget (Rev: 0404)"

USBSTOR\DISK_LINUX_FILE-STOR_GADGET_0404\123456789012&0
USBSTOR\DiskLinux___File-Stor_Gadget0404
USBSTOR\DiskLinux___File-Stor_Gadget
USBSTOR\DiskLinux___
USBSTOR\Linux___File-Stor_Gadget0
Linux___File-Stor_Gadget0
USBSTOR\GenDisk
GenDisk

By comparison, here's what SanDisk shows:

USBSTOR\DISK_SANDISK_CRUZER_SWITCH_1.26\4C532015741508522393&0
USBSTOR\DiskSanDisk_Cruzer_Switch___1.26
USBSTOR\DiskSanDisk_Cruzer_Switch___
USBSTOR\DiskSanDisk_
USBSTOR\SanDisk_Cruzer_Switch___1
SanDisk_Cruzer_Switch___1
USBSTOR\GenDisk
GenDisk

Any thoughts/suggestions as to how I can get the g_mass_storage module
to replicate the above SanDisk information & thus work with these more
picky devices?

Thanks in advance

Alan
--
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