In SCSISoftUSB-0_27 all residue values were replaced with a locally computed one, however this seems to be tripped up by some brands of CD/DVD-ROM drive which stall, resulting in a differently wrong value being placed in the residue. Combat this by only replacing the residue with a locally computed one if it's obviously incorrect (as would be the case for reversed endianness and garbage upper byte).

Thanks to Doug Webb, Chris Dale, and Chris Hall for helping test this on a variety of devices at their disposal; this restores some makes of drive that worked with SCSISoftUSB-0_26 and earlier, while also adding classes of quirky ones that now work.

Version 0.28. Tagged as 'SCSISoftUSB-0_28'

There's a class of devices which manage to get the dCSWDataResidue value wrong (for example, reversed endianness, or just garbage). This causes an error to be propagated up to SCSIDriver in and the initial CDB_CAPACITY to fail (only 8 bytes are expected). The error response is to fill the capacity with 0xFFFFFFFF's, which are then reported as a device of apparently 512TB in size.
Take the stance that umass.c revision 1.146 in NetBSD takes, and simply ignore the device's residue; use the actual number of bytes transferred by the USB stack instead.
umass.c: Compute dCSWDataResidue locally.
global.h: Fix debug build, pointer type of states[] needs constifying.
glue.c: Simplify the entry to glue_Tick; it is assumed to be entered with interrupts disabled, and all exits restore the interrupt state, so unconditionally disable - note that this is only needed for debugging when debuglib might enable interrupts for some output types, and thus allow reentrancy via RTSupport. Clean up a few comments in passing.

Tested with a known bogus USB stick - now mounts successfully. Ref: Elesar ticket #78A-D76-74EC3.

Version 0.27. Tagged as 'SCSISoftUSB-0_27'

Contemporary with umass.c revision 1.123 from NetBSD. This is the latest version we can take without needing to make changes to USBDriver to reflect additions to the usb_attach_args struct (short of having a local copy which overrides it).

Version 0.26. Tagged as 'SCSISoftUSB-0_26'

Contemporary with umass.c revision 1.112 from NetBSD.
Tagged as SCSISoftUSB-0_25-netbsd-1_112.

Contemporary with umass.c revision 1.102 from NetBSD.
Tagged as SCSISoftUSB-0_25-netbsd-1_102.

Fake implementation of usbd_do_request_flags(), slight collusion with USBDriver due to fudge introduced in 2004 - beware!
Contemporary with umass.c revision 1.99 from NetBSD.
Tagged as SCSISoftUSB-0_25-netbsd-1_99.

Wrap the RISC OS-isms with #ifdef __riscos, and some noisy tab/whitespace changes.
Removed sc_sense from umass_softc (never set), was added in SCSISoftUSB-0_07, but appears to be left over from a future version - it'll be back later.
Contemporary with umass.c revision 1.95 from NetBSD.
Tagged as SCSISoftUSB-0_25-netbsd-1_95.

Found by cppcheck static analysis.
Tagged as SCSISoftUSB-0_25-1 since our va_end is an empty macro.

Detail:
  A misbehaving USB SDcard adaptor caused unexpected duplication of some
  structure free calls. Ensured this is protected
Admin:
  tested on iMx6

Version 0.25. Tagged as 'SCSISoftUSB-0_25'

Detail:
  More precise detection of sense status error condition, and blocked
  reentrancy possible condition at start of Glue_Tick().
  Previous fix didn't always fix offending device.
Admin:
  Tested on iMx6

Version 0.24. Tagged as 'SCSISoftUSB-0_24'

Detail:
  In certain circumstances the Sense Status command can be sent more bytes
  than it requested. When this happened the system stalled until the device
  was unplugged. (The transfer was not completed because the system said
  there were still bytes to be read, though the command had read all it
  required.)
Admin:
  Tested on iMx6

Version 0.23. Tagged as 'SCSISoftUSB-0_23'

It looks like the table came from NetBSD revision 1.39 (despite the claim it was 1.37, perhaps that line wasn't updated?).
Go up to 1.45, which is the last revision before code changes to umass.c are needed (which ultimately obsolete many of the quirks).
Add back the EASYDISK quirk, this was commented out in SCSISoftUSB-0_06 because the vendor was renamed in usbdevs 1.364, via a define to its new vendor name.

Version 0.22. Tagged as 'SCSISoftUSB-0_22'

In the module post init service call handler SCSIdriver -> SCSIDriver. While a caseless compare would also solve this, the only disc loading copy in RO5x0Hook loads the disc based SCSIDriver first anyway, so there's always a matched set there (as in ROM). Remove unused module post final service call handler too.
module.c: adjust case, remove unused code
modhdr.cmhg: remove unused service call table entry
glue.c: adjust case (of debug/comments)
Makefile: simplified given recent shared makefile improvements, notably the debug flags are now picked up from CDFLAGS/CMHGDFLAGS based on the target
!MkDebug/!MkRam: pass in the target for which the obey file relates rather than 'all'

Version 0.21. Tagged as 'SCSISoftUSB-0_21'

Detail:
  If IRQs were not off, reenable them on exit. This is an academic fix as the CMHG veneers would reenable them when the CPSR is restored, but now self consistent with the other exits in this file.
Admin:
  Spotted by Colin Granville. Not tested here.

Version 0.20. Tagged as 'SCSISoftUSB-0_20'

Detail:
  In order to keep block-based SCSI devices happy, the data transfer length must be a multiple of the block size. Unfortunately the RISC OS SCSI API considers the act of padding requests out to the correct size to be a driver problem rather than a client problem, and the USB SCSI spec doesn't provide a guaranteed way for a host to determine the correct transfer length for a command which has failed.
  To cope with this SCSISoftUSB contains some code to pad block read/write transfer lengths out to a multiple of the USB packet size. For high-speed USB devices using standard 512 byte sector sizes this works fine, but for low-speed devices or devices with less common block sizes it falls short.
  To rectify this SCSISoftUSB now listens out for any CAPACITY commands which are sent to the device and peeks at the result to determine the correct block size to use. Except for rare cases where the client takes a random guess at the block size this should allow SCSISoftUSB to get the correct block size itself without having to implement lots of extra logic to deal with devices being slow to initialise, etc.
  Additionally the padding code has been rewritten to ensure writes are padded with nulls (previously would read off the end of the supplied source data), and excess read bytes are discarded (previously would write off the end of the destination buffer)
  File changes: c/glue, h/global
Admin:
  Tested on Raspberry Pi
  USB2 devices forced to run at USB1 speed now behave themselves during non-sector sized filecore ops


Version 0.19. Tagged as 'SCSISoftUSB-0_19'

Reorder the open pipe special fields to match those in the USB driver to side step the DeviceFS parsing problem prior to DeviceFS-0_69
Make the upcall handler robust to device streams being shut, see
  http://www.riscosopen.org/forum/forums/3/topics/1970
for the gritty details.

Version 0.18. Tagged as 'SCSISoftUSB-0_18'

In glue.c revision 1.4 the interface and alternate were swapped round when generating the USB device special string. Presumably this was to work around DeviceFS not parsing them properly? DeviceFS does now, so this was tripping up any mass storage devices whose interface and alternate weren't the same.

Version 0.17. Tagged as 'SCSISoftUSB-0_17'

Detail:
  Previously the RTSupport routine would execute in SYS mode, and use assembler veneers to make direct calls to the buffer manager.
  Despite being against the buffer manager spec (only IRQ or SVC should be used, according to PRM 5a), the buffer manager was coping with SYS mode calls fine. However the buffer manager would call DeviceFS, and DeviceFS would then call USBDriver, entering the module via one of CMHG's generic veneers.
  These veneers attempt to switch to SVC mode on entry, but they do so by only interacting with the bottom two bits of the PSR - so the CPU was remaining in SYS mode.
  Although this isn't a problem in and of itself, immediately after the mode change comes some code to set up the static relocation offsets at the SVC stack limit.
  This is done by aligning the stack pointer to a MB boundary. If we were in SVC mode this would be fine, but since we're still in SYS mode we're using a stack that was allocated by SCSISoftUSB and isn't aligned to a boundary at all; thus resulting in two words of RMA being swapped out with something completely different while the USBDriver code executes.
  With RTSupport in ROM this will most likely end up being the first two words of the heap - which is enough to stop OS_Module from manipulating the heap (the heap manager will see it as corrupt), but without causing any lasting damage.
  To solve this issue we now run the entire routine in SVC mode, using the MB-aligned SVC stack that RTSupport provides for us.
  File changes:
  c/global, c/cmodule, h/global - Get rid of the SYS mode stack since we no longer need it
  c/glue, h/glue - Extern RTSupportWrapper so it can be called from the assembler veneer. Tweak RT_Register parameters to pass in the relocation offsets (and no SYS stack)
  s/asm, h/asm - Added asm_RTSupportWrapper to get us into and out of SVC mode around the call to RTSupportWrapper. Also sets up our stack limit & relocation offsets within the SVC stack.
Admin:
  Tested in BCM2835 ROM


Version 0.16. Tagged as 'SCSISoftUSB-0_16'

Detail:
  Makefile, !MkDebug,fd7 - Rewritten to use makefile fragments
  c/svcprint, h/debug - Removed obsolete svcprint code
  c/module - Collapse MESSAGES option. Use STANDALONE #define instead of ROM_MODULE to decide whether resources are embedded or not.
Admin:
  Tested in softload on Iyonix


Version 0.15. Tagged as 'SCSISoftUSB-0_15'

Detail:
  c/glue - Not all operations make use of device->current_pipe, but glue_DoCommand was accessing the pipe pointer regardless of whether the maxpacket value was needed or not. This causes the code to fail if zero page is relocated.
Admin:
  Tested on rev C2 BB.


Version 0.14. Tagged as 'SCSISoftUSB-0_14'

Detail:
  c/glue, c/umass - tweaked a few debug output messages and converted some disabled printf() calls to DPRINTF() to make SCSISoftUSB's debugging output much more useful.
Admin:
  Tested in ROM on rev C2 beagleboard.
  Changes shouldn't affect non-debug builds.


Version 0.13. Tagged as 'SCSISoftUSB-0_13'

Detail:
  c/global, c/module, cmhg/header, h/global - The new command *SCSISoftUSB_PopUpDelay can now be used to control the popup delay value. Additionally, no delay is used if outside the desktop.
  Makefile, Resources/UK/Messages - Added resources file containing text for the new * command
  c/module, cmhg/header - Devices are now registered with SCSISwitch from a callback instead of from a ticker event. This ensures the registration won't fail due to insufficient RMA space (e.g. as is often the case for devices detected during OMAP ROM initialisation)
Admin:
  Tested in ROM on rev C2 beagleboard, and in RAM on Iyonix.
  Messages file needs translating!


Version 0.12. Tagged as 'SCSISoftUSB-0_12'

Detail:
  On initialisation SCSISoftUSB now checks if a suitable version of the RTSupport module is loaded (0.05 or above), and if so, will use RTSupport in preference to TickerV to schedule USB transfers. When combined with tweaked DeviceFS buffer thresholds and some extra code to listen out for buffer filling/emptying upcalls, this allows for significant performance improvements for USB 2.0 devices.
  If at any point RTSupport becomes unavailable or the RT_Register SWI fails (or if a suitable version of RTSupport is not present) the code will (potentially temporarily) fall back to using TickerV to ensure the filesystem remains functional.
Admin:
  Tested on RISC OS 5.15 rev C2 beagleboard & RISC OS 5.12 Iyonix with & without RTSupport 0.05.


Version 0.11. Tagged as 'SCSISoftUSB-0_11'

Detail:
        some combinations of card readers were causing an abort late in the
	shutdown sequence. this cleans things up
Admin:
        Tested at Castle .. Castle added IP


Version 0.10. Tagged as 'SCSISoftUSB-0_10'

Detail:
Admin: in test at CTL


Version 0.09. Tagged as 'SCSISoftUSB-0_09'

increase delay prior to scsi register from 2 secs to 4 secs as a result of beta site feedback.. certain devices not appearing if connected at reboot. (was seen occasionally in local test too).

Detail:
Admin:


Version 0.08. Tagged as 'SCSISoftUSB-0_08'

Detail:
	now checks any mass storage device for usability .. nolonger
	restricts to types 8-5 and 8-6
	delays scsi registration for 2 seconds beyond point where
	module has finished initialising (overcomes issue seen with some
	devices that fail an inquiry command if sent immediately after
	device is enabled)
Admin:
	castle added IP. tested locally. now a release candidate to
	be checked via the beta software site.


Version 0.07. Tagged as 'SCSISoftUSB-0_07'

	Re-synced with NetBSD mass storage
	Added part sector fill/ignore needed by SCSIFS

Detail:
Admin:  tested at castle.. to go to beta site.. Castle added IP


Version 0.06. Tagged as 'SCSISoftUSB-0_06'

Version 0.05. Tagged as 'SCSISoftUSB-0_05'

Version 0.04. Tagged as 'SCSISoftUSB-0_04'

Detail:
  * Returns separate error numbers for the different "cancel background
    operation" reasons
  * Reports that it supports scatter lists
  * Debugging output is LF-CR terminated, not CR-LF
Admin:
  Tested briefly.

Version 0.03. Tagged as 'SCSISoftUSB-0_03'

Detail:
  * Unplugging of devices is now reliable.
  * Stall handling now works (requires USBDriver 0.17).
  * We now do max LUN checking, since devices don't seem to do it reliably
    themselves.
  * Unknown SCSI driver handler reason codes now return an error.
  * Scatter list handling improvements - eg individual transfers can now be
    bigger than the DeviceFS buffer size (accounting for the last.
Admin:
  Tested with various mass storage devices.

Version 0.02. Tagged as 'SCSISoftUSB-0_02'

Retagged as 'SCSISoftUSB-0_01'

Version 0.01. Tagged as 'SCSISoftUSB-0_01'

Initial import of SCSISoftUSB, a driver for USB mass storage devices that use a SCSI command set over bulk-only or control-bulk-interrupt protocols.