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

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.

I see identical behaviour with usbstack3. Try sending a REQUEST SENSE prior to INQUIRY, to clear “POWER ON RESET OR BUS DEVICE RESET OCCURRED” otherwise it may refuse commands – just a guess.

There is a SCSI_Control command that sets for every device (or bus? I don’t remember…) if automatic request sense is done after a command, or not. For CD/DVD/BD writer control, I always set it to “I do everything myself”, because in the old times the SCSI podules sometimes did strange things.

I also dimly remember that there were devices out there that needed a double TEST UNIT READY command before operating correctly.

I see identical behaviour with usbstack3

Do you also have a problem with key presses?

usbstack4 does a REQUEST_SENSE requesting 0 data on connection.

Your last debug report showed it worked fine after the reset sent by the SCSI module so I could have just issued a reset command and I think it would work. umass.c doesn’t issue any REQUEST_SENSE commands.

I think we are just trying to work around a quirk with your device – mine and other floppies on here seem to work ok.

Uups, my answer is in “BBC Basic” thread … Bad eyesight, small Smartphone Display. Sorry.

usbstack4 does a REQUEST_SENSE requesting 0 data on connection.

REQUEST SENSE should be requesting 18, otherwise it won’t do anything.

umass.c doesn’t issue any REQUEST_SENSE commands

I believe REQUEST SENSE is required by the UFI spec:

3.5 UFI Command Process Flow
…
After the UFI device fails a command, it shall enter the Persistent Command Block Failure state. In this state,
the UFI device shall reject all command blocks, except INQUIRY, REQUEST SENSE, and SEND
DIAGNOSTIC.
The UFI device continues in this state until the host supplies a REQUEST SENSE or SEND DIAGNOSTICS
command block or performs a USB Suspend.

The implication being that REQUEST SENSE should be issued after every command.

I’ve tried usbstack4, but it locks the machine too quickly to be able to test.

Raik

So you have it working on a Titanium and ArmX6 but the filing system icon doesn’t appear in your pi but otherwise it works ok. As a matter of interrest which pi is that. I only have a B+ and it works ok with that.

The mouse driver may be too old to support your touchpad I think we can ignore this problem at the moment.

No, it is only required if a command fails – and I had thought that SCSISwitch would do that. In any case I am not getting any failures when attaching and you are not getting any failures after attachment when it’s working correctly with no REQUEST SENSE commands

with usbstack3 can you open a filer with Filer_OpenDir as Raik did?

The device icon is on the PiTopV1 Iconbar. I must remove the Floppy to use a mouse for the Screenshot and other action.
I use a Pi3B in my PiTopV1.
It is also working with my Pandora (OMAP3).

The reason I did a REQUEST SENSE of 0 bytes is that REQUEST SENSE is supposed to only return the number of bytes requested and reading any bytes sent is going to be a bit tricky.

No, it is only required if a command fails

Ah…but how do you know if a command fails without checking via REQUEST SENSE? If REQUEST SENSE isn’t sent after every command and any failure actioned, you’ll only find out it failed when you try to issue a new command and it’s rejected.

The reason I did a REQUEST SENSE of 0 bytes is that REQUEST SENSE is supposed to only return the number of bytes requested and reading any bytes sent is going to be a bit tricky.

REQUEST SENSE has to be 18..its in the UFI spec:

Outputs
The UFI device returns 18 bytes of sense data in response to a REQUEST SENSE command.

but how do you know if a command fails

The interrupt end point is used.

ufi10.pdf 4.11

Allocation Length: specifies the maximum number of bytes of sense data that the host can receive. If this is less than the size of the sense data the UFI device shall return the number of bytes requested.

The problem appears to be that the command hasn’t technically failed. It looks like the data transfer has been queued on the usb host and the device is sending NAKs keeping the process waiting. On NetBSD it would have timed out in about 5 seconds SCSISwitch aborts the transfer after 1 second.

but how do you know if a command fails

The interrupt end point is used.

There’s also this in 4.11:

Persistent Command Block Failure and UNIT ATTENTION conditions, such as media change or power on
reset, shall be cleared by the UFI device when retrieved by a REQUEST SENSE command block.

Which I believe is what’s causing the initial failure in my case.

Allocation Length: specifies the maximum number of bytes of sense data that the host can receive. If this is less than the size of the sense data the UFI device shall return the number of bytes requested.

Unfortunately the spec doesn’t define what should happen if a zero transfer length is requested for REQUEST SENSE, so is it possible the device simply ignores the command and doesn’t clear the Command Block? I certainly couldn’t get it working with a length of zero.

usb_msc_cbi_1.1.pdf

3.4.3.1.1 Common Interrupt Data Block

Table 3.7 bit 1…0 of offset 1: 11 = persistent failure

under that table.

In response to a persistent failure the host shall send an op 03h REQUEST SENSE command block.

I haven’t written any usb code for SCSISoftUSB I just made a module and passed the SCSI commands to umass.c which is unchanged from NetBSD. If REQUEST SENSE was required after every command you would expect it would appear somewhere in the NetBSD code and it doesn’t. There would also be no need to make a special case for persistant failure. I expect that, like riscos scsiswitch, netbsd will issue REQUEST SENSE commands in the SCSI layer as required.

Can you try usbstack5 it resets after connecting – it will just eliminate my idea.

Can you try usbstack5 it resets after connecting – it will just eliminate my idea.

No difference, the drive doesn’t appear and trying to *. returns drive is empty.

Hmm. The reset is just a SEND DIAGNOSTICS command followed by clear endpoint stalls. It’s only what happens after the INQUIRY command fails to return at connection after which everything looks normal. More reading required I think.

I’ll modify my driver to only send an INQUIRY when started and see if I get the same issue.

I’ll also have a look at the SCSI_MiscOp 1 code as the drive may not be appearing because it’s incorrectly flagging the drive as empty.

EDIT: I’ve just spotted CDB_TestUnitReady is the wrong length, did you correct it?

Ah…but how do you know if a command fails without checking via REQUEST SENSE?

The SCSI return state which usually triggers a REQUEST SENSE is a state called “CHECK CONDITION”. Only on “CHECK CONDITION” a REQUEST SENSE should be ever used. I would expect UFI spec to follow usual SCSI conventions, but I have not studied it.

The part you’ve quoted here

After the UFI device fails a command, it shall enter the Persistent Command Block Failure state. In this state,
the UFI device shall reject all command blocks, except INQUIRY, REQUEST SENSE, and SEND
DIAGNOSTIC.

suggests to me that the “fail” is the “CHECK CONDITION” state, and only that should be followed by a REQUEST SENSE to clear the CHECK CONDITION state.

EDIT: I’ve just spotted CDB_TestUnitReady is the wrong length, did you correct it?

The source you have linked to shows a 6 byte CDB, which is correct.

Jon, have you tried some plain SCSI_ SWIs if they work wth your floppy? Try a plain TEST UNIT READY, INQUIRY, READ or something like that with SCSI_Op.

Not sure if the ROOL website has the docs anywhere, you can read about the SCSI_ SWIs in the Morley SCSI podule manual…

http://chrisacorns.computinghistory.org.uk/docs/Morley/Morley_SCSIInterface.pdf

Just to report, I tried the same setup as before, but swapped out the pi b+ for a Pi 3, and that worked too. I also swapped to original Pi 1, and although I got a drive icon, I get ‘Target error – Medium error’ trying to access the disc. Although I suspect this is more to do with the fact the Pi1 can’t power the drive properly, as unlike the others, it didn’t spin when connected. I don’t currently have a powered hub to try with. Over on the Iyonix, I get Abort on data transfer &FC1E86D4 RMLoading USBdriver, requiring a reboot. (Though I appreciate Iyonix was probably not your target, I was being optimistic. Of course, I could just use the standard floppy there)

The SCSI return state which usually triggers a REQUEST SENSE

The problem Jon’s drive is having is the command is in progress when it fails so it doesn’t get the return state. By fails I mean the device has stopped working not that it has returned a ‘command failed value’ The device hasn’t returned a Stall or acked the data request so the usbhost and therefore the driver is just waiting for the data. It’s like waiting for a register value to become valid. After a reset the problem goes away but that is too late to initialise SCSIFS.

Jon has got his device to work by bracketing his commands with REQUEST SENSE – not normal but it works – so the first one before the first command must kick the device into life. I’ve not been able to repeat this.

This is only a problem with Jons drive other peoples drives work ok.

The source you have linked to shows a 6 byte CDB, which is correct.

It’s definitely 12 for a UFI command as detailed in the UFI spec

Jon, have you tried some plain SCSI_ SWIs if they work wth your floppy?

Yes, I’ve successfully read data via SCSI_Op. INQUIRY does however report “Unexpected disconnection”, so I simply avoid using it as its not required to use the device. It’s possible that’s a quirk of my device, I’m waiting for another floppy drive to confirm.

Jon has got his device to work by bracketing his commands with REQUEST SENSE

Not strictly true, I issue an initial REQUEST SENSE to clear the block caused by POWER ON RESET OR BUS DEVICE RESET OCCURRED. I then issue REQUEST SENSE after commands as per the UFI spec.

There’s a real world example of a UFI conversation here and the NEC USB Floppy Disk Drive Operating Sequence details when REQUEST SENSE should be used.

There’s a real world example of a UFI conversation here and the NEC USB Floppy Disk Drive Operating Sequence details when REQUEST SENSE should be used.

That’s not quite how I read it. The device in the blog reports itself as an 8:6:80 device not a UFI device (8:4:0) so not sure what is happening there. The diagrams in the NEC document shows Interrupt Endpoint 3 as an alternative to REQUEST_SENSE so either should work.

REQUEST_SENSE would definitely be used if it was an 8:4.1 device as they don’t have an interrupt endpoint so I suppose an 8:4:0 endpoint can be used either way.

I’ve successfully read data via SCSI_Op. INQUIRY does however report “Unexpected disconnection”,

If you do a REQUEST_SENSE before INQUIRY does it work. It definitely works in the log you posted when doing *scsi:devices.

I’m waiting for another floppy drive to confirm.

I hope you don’t get the same one in a different box.