RISC OS Open
A fast and easily customised operating system for ARM devices
ROOL
Home | News | Downloads | Bugs | Bounties | Forum | Documents | Photos | Contact us
Account
Forums → General →

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

Subscribe to Can you use a USB floppy drive with RISC OS on a Pi? 120 posts, 16 voices

Posts per page:

Pages: 1 2 3 4 5

 
Jan 30, 2019 1:10pm
Avatar Jeffrey Lee (213) 5870 posts
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?

 
Jan 30, 2019 3:17pm
Avatar Jon Abbott (1421) 2180 posts

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.

 
Jan 30, 2019 4:47pm
Avatar Colin (478) 2309 posts

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.

 
Jan 30, 2019 7:20pm
Avatar Jon Abbott (1421) 2180 posts

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.

 
Jan 30, 2019 8:01pm
Avatar Steve Pampling (1551) 6783 posts

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
 
Jan 30, 2019 9:32pm
Avatar Jeffrey Lee (213) 5870 posts

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.

 
Jan 31, 2019 4:45am
Avatar Raik (463) 1868 posts

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.

 
Jan 31, 2019 5:44pm
Avatar Colin (478) 2309 posts

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.

 
Jan 31, 2019 6:34pm
Avatar Steve Pampling (1551) 6783 posts
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?

 
Jan 31, 2019 6:52pm
Avatar Colin (478) 2309 posts

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

 
Jan 31, 2019 10:28pm
Avatar Martin Avison (27) 1140 posts

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

 
Feb 1, 2019 5:40pm
Avatar Jon Abbott (1421) 2180 posts

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.

 
Feb 1, 2019 7:11pm
Avatar Colin (478) 2309 posts

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.

 
Feb 4, 2019 5:38pm
Avatar Colin (478) 2309 posts

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.

 
Feb 4, 2019 6:33pm
Avatar Jon Abbott (1421) 2180 posts

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.

 
Feb 4, 2019 7:07pm
Avatar Colin (478) 2309 posts

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 : 
        +----+----+---------------------------+----------+------------+
 
Feb 4, 2019 9:39pm
Avatar Will Ling (519) 98 posts

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

 
Feb 4, 2019 10:45pm
Avatar Colin (478) 2309 posts

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.

 
Feb 4, 2019 11:34pm
Avatar Will Ling (519) 98 posts

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+

 
Feb 5, 2019 4:32am
Avatar Raik (463) 1868 posts

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.

 
Feb 5, 2019 12:19pm
Avatar Colin (478) 2309 posts

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.

 
Feb 5, 2019 10:05pm
Avatar Jon Abbott (1421) 2180 posts

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.

 
Feb 5, 2019 10:46pm
Avatar Colin (478) 2309 posts

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.

 
Feb 6, 2019 6:03am
Avatar Jon Abbott (1421) 2180 posts

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
 
Feb 6, 2019 10:56am
Avatar Colin (478) 2309 posts

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.

Next page

Pages: 1 2 3 4 5

Reply

To post replies, please first log in.

Forums → General →

Search forums

Social

Follow us on and

ROOL Store

Buy RISC OS Open merchandise here, including SD cards for Raspberry Pi and more.

Donate! Why?

Help ROOL make things happen – please consider donating!

RISC OS IPR

RISC OS is an Open Source operating system owned by RISC OS Developments Ltd and licensed primarily under the Apache 2.0 license.

Description

General discussions.

Voices

  • Jeffrey Lee (213)
  • Jon Abbott (1421)
  • Colin (478)
  • Steve Pampling (1551)
  • Raik (463)
  • Martin Avison (27)
  • Will Ling (519)

Options

  • Forums
  • Login
Site design © RISC OS Open Limited 2018 except where indicated
The RISC OS Open Beast theme is based on Beast's default layout

Valid XHTML 1.0  |  Valid CSS

Powered by Beast © 2006 Josh Goebel and Rick Olson
This site runs on Rails

Hosted by Arachsys