Can you use a USB floppy drive with RISC OS on a Pi?

And the underlying SCSI commands? (The UFI commands are basically SCSI commands)

I’m not sure what you’re asking. If you want my to try specific SCSI commands, you’ll have to spell it out for me!

You’ve written a program that can read (and write?) USB floppies by sending UFI commands straight to the USB stack.

UFI commands are just SCSI commands.

What happens if you send the UFI/SCSI commands to SCSI_Op instead?

Try scsisoftusbd2. It looks like the length of the enquiry command was wrong – it may be the reason it failed. I’ve forced the length to 12 – it was 6 – for the test download.

SCSIFS_DiscOp does now access the floppy, but doesn’t return, requiring a reboot to recover. From my experience over the past few days, that’s a result of not calling REQUEST_SENSE around a READ. If you don’t do that, the drive just rejects commands.

I’ve not looked at the linux driver yet, but to get it working I coded DiscOp 1 as:

BL USB_REQUEST_SENSE
BL USB_UNIT_READY
BL USB_REQUEST_SENSE
BL USB_READ
BL USB_REQUEST_SENSE

The first REQUEST_SENSE puts the drive into a known state and without the others the drive dies.

You’ve written a program that can read (and write?) USB floppies by sending UFI commands straight to the USB stack.

UFI commands are just SCSI commands.

What happens if you send the UFI/SCSI commands to SCSI_Op instead?

I know all that, I just don’t know how to call SCSI_Op as it’s not documented on the wiki. I did try doing a Lookup for it in StrongHelp which just crashes on a Pi3 (v2.90-1 from PackMan). Anyhow, I have now eventually found the help file in question which doesn’t really help me.

How do I change a DeviceFS_CallDevice call to SCSI_Op? If StrongHelp is to be believed, I need to implement call back code, wrap the command in a SCSI control block and it wants an “access key” – whatever that is!

I’m using Colin’s code from the front page:

DEF PROCusb_control(usb$,bmRType%,bRequest%,wValue%,wIndex%,wLength%,buf%)
  SYS "XDeviceFS_CallDevice",(1<<31),usb$+CHR$(0),,(bmRType% OR (bRequest%<<8) OR (wValue%<<16)),(wIndex% OR (wLength%<<16)),buf%, 0 
ENDPROC

If you want to translate that into a SCSI_Op equivalent, I’ll certainly try it.

I have to say that the documentation on the wiki for both USB and SCSI is woefully inadequate, these must have been implemented by RISCOS devs – didn’t they consider documenting their creations? Why for example does DeviceFS_CallDevice need bit 31 set – there’s no mention of it in the documentation.

Last try – scsisoftusbd3. I don’t hold out much hope for it I’d need a floppy drive here to investigate further. I’ve bracketed all commands, except the sense command, with a sense command with 0 parameter length. Note any changes are only affecting UFI devices.

Last try – scsisoftusbd3

Just reports “The disc drive is empty”

a sense command with 0 parameter length

REQUEST SENSE should be 18, bytes 2, 12 and13 hold the result.

Most curious. I’m not sure whether what I’m seeing is an artefact of Jon’s quoting, a problem with Reporter, or a fault in the driver you’re working on but notice in the long lines that get wrapped after column 79 and character 80 is missing.
Most obvious on the lines with the (CBI bulk-out clear stall) where the last l or the ) is missing.

As a regular user of remote SSH sessions onto switches I tend to set the line length to 132

SCSISoftUSB: going into wire_state, state, status = f 0
SCSISoftUSB: USBMassStorage0.25: Handling CBI state 15 (CBI Reset), xfer=2005db
4, NORMAL_COMPLETION
SCSISoftUSB: umass_clear_endpoint_stall New device call returned no error
SCSISoftUSB: state, state => 10 0
SCSISoftUSB: USBMassStorage0.25: Handling CBI state 16 (CBI bulk-in clear stall
, xfer=2005dbd4, NORMAL_COMPLETION
SCSISoftUSB: umass_clear_endpoint_stall New device call returned no error
SCSISoftUSB: state, state => 11 0
SCSISoftUSB: USBMassStorage0.25: Handling CBI state 17 (CBI bulk-out clear stal
), xfer=2005dbd4, NORMAL_COMPLETION

If you want to translate that into a SCSI_Op equivalent, I’ll certainly try it.

There’s no direct equivalent, since SCSI_Op accepts both the SCSI command ptr and the data buffer ptr in the same call.

Callbacks and access keys are optional (IIRC SCSIFS will use an access key to lock access to a device if it’s able to successfully mount it).

Here are a couple of examples:

SCSI_READ = 1<<24
SCSI_WRITE = 1<<25

DEF PROCrequestsense
cmd%!0=(lun%<<13)+3
cmd%!4=18
cmd%!8=0
SYS "SCSI_Op",device%+SCSI_READ+(1<<27),12,cmd%,buf%,18
ENDPROC

DEF PROCtestunitready
cmd%!0=(lun%<<13)
cmd%!4=0
cmd%!12=0
SYS "SCSI_Op",device%+(1<<27),12,cmd%
ENDPROC

*devices outputs device IDs in the form bus:dev.lun, which corresponds to a device% value of dev+(bus<<3)+(lun<<5)

I have to say that the documentation on the wiki for both USB and SCSI is woefully inadequate, these must have been implemented by RISCOS devs – didn’t they consider documenting their creations?

There’s some (probably partially outdated) SCSI docs in CVS: https://www.riscosopen.org/viewer/view/apache/RiscOS/Sources/HWSupport/SCSI/SCSIDriver/doc/Spec?rev=1.2

USB docs are also there (IIRC these used to be on iyonix.com back in the day): https://www.riscosopen.org/viewer/view/mixed/RiscOS/Sources/HWSupport/USB/NetBSD/build/Doc/USB?rev=1.5

Why for example does DeviceFS_CallDevice need bit 31 set – there’s no mention of it in the documentation.

IIRC bit 31 is for “driver specific operations”, e.g. operation 5+(1<<31) on a USB device may do something completely different to 5+(1<<31) on a UART device.

Last try – scsisoftusbd3.

Have try.
The USB icon disappears from the iconbar and will not come back. The harddisc icon also disappears, but comes back.

The screenshot of USBInfo looks very promising.

scsisoftusbd3 turned out to be a load of rubbish I used MODE_SENSE instead of REQUEST_SENSE and did it wrong anyway.

I’m not sure whether what I’m seeing is an artefact of Jon’s quoting, a problem with Reporter, or a fault in the driver you’re working on

I think it’s a problem with the reporter part of RISC OS’s DebugLib. That does the 80 char wrap. I have no problem with reporter with my own library.

What happens if you send the UFI/SCSI commands to SCSI_Op instead?

Your SCSI commands as you have written them may well work however they are not standard SCSI commands. The standard length of those scsi commands would have a command length of 6. Commands sent by scsiswitch use the standard lengths.

Doing a quick comparison of SCSISoftUSB against the NetBSD code it’s built around, I can’t spot any glaring omissions which would explain why UFI devices don’t work with SCSISoftUSB.

NetBSD gets the status with a REQUEST_SENSE command if it is a CBI device which doesn’t have an interrupt end point by responding to STATUS_CMD_UNKNOWN when the transfer completes in umass_scsipi_cb in umass_scsipi.c. We don’t appear to do that. For a CBI device with an interrupt endpoint the interrupt endpoint is opened with the ‘bulk’ special field which I think means it will fail to open as the endpoint it specifies isn’t bulk.

I think it should work with SCSISoftUSB but will require some work – you really need a device available to test.

I’m not sure whether what I’m seeing is an artefact of Jon’s quoting, a problem with Reporter, or a fault in the driver you’re working on

I think it’s a problem with the reporter part of RISC OS’s DebugLib. That does the 80 char wrap. I have no problem with reporter with my own library.

That would be the 10 year old stuff here and here you’re referring to then?

The first one. debug_reporter_output discards a character when it wraps.

Reporter itself is not limited to only 80 characters – it copes with lines up to 255 long.

scsisoftusbd3 turned out to be a load of rubbish I used MODE_SENSE instead of REQUEST_SENSE and did it wrong anyway.

Did you want me to test a corrected version? scsisoftusbd2 was pretty close as *. scsi::0.$ did attempt to read the floppy.

scsisoftusbd2 just forced the scsi commands to be 12 bytes long – it didn’t use any sense commands.

I can’t see an easy fix and scsisoftusb has done a good job at mangling the NetBSD code – which is easier to understand. So I’ll send for a USB floppy drive and a floppy disc and see what I can do. I appear to have thrown all of my floppy discs out – who knew I’d find a use for one.

Unfortunately it will take about a week to arrive so nothing will happen quickly.

My floppy drive just arrived but the bad news – or is it good – is that it appears to be working fine with scsisoftusbd2. The icon is on the iconbar and clicking on it gives the error ’Disc drive is empty" as expected.

*scsi:devices
Device Type              Capacity    Vendor   Product          Revision
0:0.0  Direct-access      233 Gbytes CT250MX5 00SSD1           M3CR
0:1.0  Direct-access     Unknown     TEAC     USB UF000x       0.00

I’m just waiting for a floppy to arrive to test if it is working with a disc in.

My floppy drive just arrived but the bad news – or is it good – is that it appears to be working fine with scsisoftusbd2. The icon is on the iconbar and clicking on it gives the error ’Disc drive is empty" as expected.

What’s different between your USB Descriptor and mine? Accessing mine with SCSIsoftUSBD2 just results in a locked machine.

Nothing really.

*usbdesc. usb9
USBDescriptors v1.07a (29-Apr-2018)

=============================================
 Device USB9
=============================================
:  0 :  2 : total size of ServiceCall block : 91
:  2 :  2 : offset to descriptor list       : 0x20
:  4 : 20 : name                            : USB9
: 24 :  1 : bus number                      : 1
: 25 :  1 : device address                  : 5
: 26 :  1 : host address                    : 2
: 27 :  1 : host port                       : 4
: 28 :  1 : speed                           : 2 full speed
---------------------------------------------

 Standard Device Descriptor
+----+----+---------------------------+----------+------------+
:Off :Sz  :Name                       :Value hex :Value dec   :
+----+----+---------------------------+----------+------------+
:  0 :  1 : bLength                   :       12 :         18 : 
:  1 :  1 : bDescriptorType           :        1 :          1 : 
:  2 :  2 : bcdUSB                    :      110 :        272 : 
:  4 :  1 : bDeviceClass              :        0 :          0 : 
:  5 :  1 : bDeviceSubClass           :        0 :          0 : 
:  6 :  1 : bDeviceProtocol           :        0 :          0 : 
:  7 :  1 : bMaxPacketSize            :       40 :         64 : 
:  8 :  2 : idVendor                  :      644 :       1604 : 
: 10 :  2 : idProduct                 :        0 :          0 : 
: 12 :  2 : bcdDevice                 :      200 :        512 : 
: 14 :  1 : iManufacturer             :        1 :          1 : 'TEACV0.0'
: 15 :  1 : iProduct                  :        2 :          2 : 'TEACV0.0'
: 16 :  1 : iSerialNumber             :        0 :          0 : ''
: 17 :  1 : bNumConfigurations        :        1 :          1 : 
+----+----+---------------------------+----------+------------+

 Standard Configuration Descriptor
+----+----+---------------------------+----------+------------+
:Off :Sz  :Name                       :Value hex :Value dec   :
+----+----+---------------------------+----------+------------+
:  0 :  1 : bLength                   :        9 :          9 : 
:  1 :  1 : bDescriptorType           :        2 :          2 : 
:  2 :  2 : wTotalLength              :       27 :         39 : 
:  4 :  1 : bNumInterfaces            :        1 :          1 : 
:  5 :  1 : bConfigurationValue       :        1 :          1 : 
:  6 :  1 : iConfiguration            :        0 :          0 : ''
:  7 :  1 : bmAttributes              :       80 :        128 : (bit7) USB 1.0 bus powered (bit6) Bus powered, (bit5) No remote wakeup
:  8 :  1 : bMaxPower                 :       fa :        250 : 500mA
+----+----+---------------------------+----------+------------+

     Standard Interface Descriptor
    +----+----+---------------------------+----------+------------+
    :Off :Sz  :Name                       :Value hex :Value dec   :
    +----+----+---------------------------+----------+------------+
    :  0 :  1 : bLength                   :        9 :          9 : 
    :  1 :  1 : bDescriptorType           :        4 :          4 : 
    :  2 :  1 : bInterfaceNumber          :        0 :          0 : 
    :  3 :  1 : bAlternateSetting         :        0 :          0 : 
    :  4 :  1 : bNumEndpoints             :        3 :          3 : 
    :  5 :  1 : bInterfaceClass           :        8 :          8 : Mass Storage
    :  6 :  1 : bInterfaceSubClass        :        4 :          4 : 
    :  7 :  1 : bInterfaceProtocol        :        0 :          0 : 
    :  8 :  1 : iInterface                :        0 :          0 : ''
    +----+----+---------------------------+----------+------------+

         Standard Endpoint Descriptor
        +----+----+---------------------------+----------+------------+
        :Off :Sz  :Name                       :Value hex :Value dec   :
        +----+----+---------------------------+----------+------------+
        :  0 :  1 : bLength                   :        7 :          7 : 
        :  1 :  1 : bDescriptorType           :        5 :          5 : 
        :  2 :  1 : bEndpointAddress          :       82 :        130 : Endpoint 2 - IN
        :  3 :  1 : bmAttributes              :        2 :          2 : Bulk
        :  4 :  2 : wMaxPacketSize            :       40 :         64 : 1 x 64 byte max packets
        :  6 :  1 : bInterval                 :        0 :          0 : 
        +----+----+---------------------------+----------+------------+

         Standard Endpoint Descriptor
        +----+----+---------------------------+----------+------------+
        :Off :Sz  :Name                       :Value hex :Value dec   :
        +----+----+---------------------------+----------+------------+
        :  0 :  1 : bLength                   :        7 :          7 : 
        :  1 :  1 : bDescriptorType           :        5 :          5 : 
        :  2 :  1 : bEndpointAddress          :        1 :          1 : Endpoint 1 - OUT
        :  3 :  1 : bmAttributes              :        2 :          2 : Bulk
        :  4 :  2 : wMaxPacketSize            :       40 :         64 : 1 x 64 byte max packets
        :  6 :  1 : bInterval                 :        0 :          0 : 
        +----+----+---------------------------+----------+------------+

         Standard Endpoint Descriptor
        +----+----+---------------------------+----------+------------+
        :Off :Sz  :Name                       :Value hex :Value dec   :
        +----+----+---------------------------+----------+------------+
        :  0 :  1 : bLength                   :        7 :          7 : 
        :  1 :  1 : bDescriptorType           :        5 :          5 : 
        :  2 :  1 : bEndpointAddress          :       83 :        131 : Endpoint 3 - IN
        :  3 :  1 : bmAttributes              :        3 :          3 : Interrupt
        :  4 :  2 : wMaxPacketSize            :        2 :          2 : 1 x 2 byte max packets
        :  6 :  1 : bInterval                 :       7f :        127 : 
        +----+----+---------------------------+----------+------------+

Just to pop another in the mix… I dug out an old usb floppy drive to try with scsisoftusbd2
It’s recognised, and I get an icon. Although, to not too much surprise, clicking it just makes the disc spin, seek, pause, and repeat indefinitely. Popping it out then eventually gives The disc drive is empty. (I tested the drive on windows with the disc, and it does work)

*dev.
Device Type              Capacity    Vendor   Product          Revision
0:0.0  Direct-access     Unknown     MITSUMI  USB FDD          1050

If anyone is feeling experimental would they like to try this usbstack. It replaces the current USB stack. The version of SCSISoftUSB it contains is much closer to the NetBSD version – it doesn’t use devicefs to transfer data.

However SCSISoftUSB is not complete it doesn’t support scatter lists – the netbsd code doesn’t support them. This means it fails to write depending on whether the front end uses scatter lists or not. I have a FATFS pen drive that reads and writes but a card reader with a filecore sdcard gives an error when writing – I think *save uses scatterlists.

It would be interesting to know if your floppy disc works as the code is close to the original NetBSD code.

If you want to test it I’d take the precaution of having no USB drives connected to the computer just in case there is a problem. So if using a pi just use sdfs as the disc, run the application then plug the disc drive in. I’d use a spare disc as well just in case.

Just run the application. It copies the modules to RAMFS before loading them.

I’ve tested it on a Pi B+ and ArmX6.

If anyone is feeling experimental would they like to try this usbstack.

Well, that worked! Not an extensive test, but it appears to read, and write. It opened up under fat32fs and I could read the text file I put on the disc from Windows when I was checking it worked earlier.
Edit: I just wrote and read a 1.3mb sprite ok. This is on a PI2 B+

Wow!!!
Have changed my test enviroment from Titanium to ArmX6 and try !usbstack.
My DOS Discs are working. The Data are readable (Screenshot)
. Have try any other DOS Discs (720kb, 1,44M) and with or without FAT32FS, looks like all are working.

If I try a old TopModel (1,6M) or !Killer (800kB) disc it gives a “Target Error – Medium Error”.

Edit: Is also working with my Titanium if I remove the “EHCI” and “kick_” lines from !run.

Good.

It only took me a couple of days, while waiting for the drive, to make the SCSISoftUSB module from scratch with the only changes to the NetBSD code – other than forcing UFI commands to 12 bytes for risc os – being due to compiler differences – bodes well for porting other netbsd usb stuff.

At least it shows that the problem is in the ROOL SCSISoftUSB module and it should be able to read DOS discs. I’ll see if I can get it to work when the disc arrives.

If anyone is feeling experimental would they like to try this usbstack

With this stack it does now display my floppy correctly in *devices but I don’t get an icon for the drive. The keyboard on my pi-top also becomes unusable, with major key repeat issues. It appears to be dropping or missing both up and down key data.

Keyboard issue aside, I’d say it’s progress given the current USB stack can’t ID my floppy.

Ah ok this was an old project that I dusted off and it didn’t have the repeating keyboard fix in it. Try usbstack2. This version has scatterlists working. I have a suspicion that your device is working like an 8:4:1 device where it uses a REQUEST_SENSE command instead of the interrupt endpoint which it is supposed to use. If you get any Reporter output can you send it to me to the address on this page.

Keyboard is no different with usbstack2. I’ve not yet managed to get debug output from a *. to work, the machine keeps locking up with the new USB stack. Between the keyboard issues and locking, a *. reported the drive as empty, although the *devices output clearly shows it has a 720KB floppy inserted.

your device is working like an 8:4:1 device where it uses a REQUEST_SENSE command instead of the interrupt endpoint

The data is coming in via interrupt endpoint, from my limited understanding of the UFI spec. the REQUEST_SENSE is required after all commands to both check the result and to clear any errors. If the sense value not zero the device is to reject commands until its cleared. When I read that bit (dont have it to hand, but probably in the REQUEST SENSE section), I added REQUEST_SENSE around all commands and all the previous issues I noted went away.

If you get any Reporter output can you send it to me to the address on this page.

Getting it from my Pi to eMail involves three computers…so I’ll attach it direct from my pi-top instead…

*Devices

Device Type              Capacity    Vendor   Product          Revision
0:0.0  Direct-access      720 kbytes Y-E DATA USB-FDU          6.01

Inserting the device:

Checking device name 'USB6' (sum_length 91, descriptors_offset 32, class 00, subclass 00, protocol 00)
Device descriptor: Length=18, Type=1, Configurations=1, csDeviceClass=0x0
Device descriptor: iManufacturer=1, iProduct=2, iSerialNumber=0
Device descriptor: Vendor=0x057b, Product=0x0000, Device=0x0601
Configuration descriptor: NumInterfaces=1 
Interface descriptor: InterfaceNumber=0, InterfaceClass=8 (3 is HID), iInterface=4, csInterfaceClass=0x80400
Endpoint descriptor: EndpointAddress=129, (on TnterfaceNumber=0)
Endpoint descriptor: We think this isn't a joystick - ignore this endpoint
Endpoint descriptor: EndpointAddress=2, (on TnterfaceNumber=0)
Endpoint descriptor: We think this isn't a joystick - ignore this endpoint
Endpoint descriptor: EndpointAddress=131, (on TnterfaceNumber=0)
Endpoint descriptor: We think this isn't a joystick - ignore this endpoint
SSUMod: module_service(447 - 33409): Service_USB_Attach USB6
SSUMod: udevice_add(133 - 33409): devname=USB6
SSUMod: udevice_add(137 - 33409): 
SSUMod: udevice_add(140 - 33409): 
SSUMod: udevice_add(150 - 33409): device=2005d6f4
SSUMod: umass_attach (515):: opening iface 2005da74 epaddr 2 for BULKOUT
SSUMod: umass_attach (527):: opening iface 2005da74 epaddr 129 for BULKIN
SSUMod: umass_attach (551):: opening iface 2005da74 epaddr 131 for INTRIN
SSUMod: umass_attach (658):: Attach finished
SSUMod: scsi_entry_point_handler(403 - 33409): reason=0 udevice=201cb834
SSUMod: scsi_entry_point_handler(403 - 33409): reason=5 udevice=201cb834
SSUMod: scsi_background_operation(371 - 33409): scatter_list_total_length=36, d
r=1
SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x12, len=36
SSUMod: scsi_background_operation(381 - 33409): 
SSUMod: umass_setup_transfer (778):: start xfer buffer=361544a4 buflen=36 flags
0x5 timeout=5000
SSUMod: scsi_entry_point_handler(403 - 33509): reason=6 udevice=201cb834
SSUMod: umass_cbi_reset (1392):: CBI Reset
SSUMod: umass_clear_endpoint_stall (823):: Clear endpoint 0x81 stall
SSUMod: umass_clear_endpoint_stall (823):: Clear endpoint 0x02 stall
SSUMod: scsi_cb(317 - 33514): status=3
SSUMod: scsi_command_complete(277 - 33514): not_transferred=36, status=0, err=0
000013

Debug output from *devices

SSUMod: scsi_entry_point_handler(403 - 41266): reason=5 udevice=201cb834
SSUMod: scsi_background_operation(371 - 41266): scatter_list_total_length=8, di
=1
SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x25, len=8
SSUMod: scsi_background_operation(381 - 41266): 
SSUMod: umass_setup_transfer (778):: start xfer buffer=361544a4 buflen=8 flags=
x5 timeout=5000
SSUMod: umass_cbi_state (1558):: CBI_DATA actlen=0
SSUMod: umass_cbi_state (1564):: Data-in 8 failed, STALLED
SSUMod: umass_clear_endpoint_stall (823):: Clear endpoint 0x81 stall
SSUMod: scsi_cb(317 - 41384): status=2
SSUMod: scsi_command_complete(277 - 41384): not_transferred=8, status=2, err=00
00000
SSUMod: scsi_entry_point_handler(403 - 41384): reason=5 udevice=201cb834
SSUMod: scsi_background_operation(371 - 41384): scatter_list_total_length=8, di
=1
SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x03, len=8
SSUMod: scsi_background_operation(381 - 41384): 
SSUMod: umass_setup_transfer (778):: start xfer buffer=361544a4 buflen=8 flags=
x5 timeout=5000
SSUMod: umass_cbi_state (1558):: CBI_DATA actlen=8
SSUMod: umass_setup_transfer (778):: start xfer buffer=201cb8d4 buflen=2 flags=
x0 timeout=5000
SSUMod: umass_cbi_state (1642):: CBI_STATUS actlen=2
SSUMod: umass_cbi_state (1667):: UFI CCI, ASC = 0x28, ASCQ = 0x00
SSUMod: scsi_cb(317 - 41384): status=2
SSUMod: scsi_command_complete(277 - 41384): not_transferred=0, status=2, err=00
00000
SSUMod: scsi_entry_point_handler(403 - 41384): reason=5 udevice=201cb834
SSUMod: scsi_background_operation(371 - 41384): scatter_list_total_length=36, d
r=1
SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x12, len=36
SSUMod: scsi_background_operation(381 - 41384): 
SSUMod: umass_setup_transfer (778):: start xfer buffer=361544a4 buflen=36 flags
0x5 timeout=5000
SSUMod: umass_cbi_state (1558):: CBI_DATA actlen=36
SSUMod: umass_setup_transfer (778):: start xfer buffer=201cb8d4 buflen=2 flags=
x0 timeout=5000
SSUMod: umass_cbi_state (1642):: CBI_STATUS actlen=2
SSUMod: umass_cbi_state (1667):: UFI CCI, ASC = 0x00, ASCQ = 0x00
SSUMod: scsi_cb(317 - 41386): status=0
SSUMod: scsi_command_complete(277 - 41386): not_transferred=0, status=0, err=00
00000
SSUMod: scsi_entry_point_handler(403 - 41386): reason=5 udevice=201cb834
SSUMod: scsi_entry_point_handler(403 - 41386): reason=5 udevice=201cb834

If you look at your debug output

output from *devices

SSUMod: scsi_entry_point_handler(403 - 41384): reason=5 udevice=201cb834
SSUMod: scsi_background_operation(371 - 41384): scatter_list_total_length=36, d
r=1
SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x12, len=36
SSUMod: scsi_background_operation(381 - 41384): 
SSUMod: umass_setup_transfer (778):: start xfer buffer=361544a4 buflen=36 flags
0x5 timeout=5000
SSUMod: umass_cbi_state (1558):: CBI_DATA actlen=36
SSUMod: umass_setup_transfer (778):: start xfer buffer=201cb8d4 buflen=2 flags=
x0 timeout=5000
SSUMod: umass_cbi_state (1642):: CBI_STATUS actlen=2
SSUMod: umass_cbi_state (1667):: UFI CCI, ASC = 0x00, ASCQ = 0x00
SSUMod: scsi_cb(317 - 41386): status=0
SSUMod: scsi_command_complete(277 - 41386): not_transferred=0, status=0, err=00

inserting the device

SSUMod: scsi_entry_point_handler(403 - 33409): reason=5 udevice=201cb834
SSUMod: scsi_background_operation(371 - 33409): scatter_list_total_length=36, d
r=1
SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x12, len=36
SSUMod: scsi_background_operation(381 - 33409): 
SSUMod: umass_setup_transfer (778):: start xfer buffer=361544a4 buflen=36 flags
0x5 timeout=5000
SSUMod: scsi_entry_point_handler(403 - 33509): reason=6 udevice=201cb834
SSUMod: umass_cbi_reset (1392):: CBI Reset
SSUMod: umass_clear_endpoint_stall (823):: Clear endpoint 0x81 stall
SSUMod: umass_clear_endpoint_stall (823):: Clear endpoint 0x02 stall
SSUMod: scsi_cb(317 - 33514): status=3
SSUMod: scsi_command_complete(277 - 33514): not_transferred=36, status=0, err=0
000013

The scsi_entry_point_handler is the entry point for SCSI requests – the numbers in brackets are line number and time in cs. When you insert the device the INQUIRY command fails waiting in umass_setup_transfer for 1 second before a cancel command (reason=6) is sent from SCSI. When you do *devices the INQUIRY command succeeds.

So in usbstack3 I’ve cleared the endpoint stall on attachment. I’ve also disabled the loading of DWCDriver in the !run file – it should work without it.