From Nekochan
Revision as of 14:41, 4 April 2016 by Dexter1 (Talk | contribs) (Re-edit pictures to include thumbnails and position and cleaned up a bit of text.)

Jump to: navigation, search


A SCSI block device emulator PCB board using a microSD card

Picture of the red PCB SCSI2SD board, revision 5
SCSI2SD board, revision 5

This is a compilation of information in the forum threads Indy with SCSI2SD setup and SCSI2SD+microSD bundles in stock and ready to ship from USA and some experiments of my own.


In my quest in building a silent Indy workstation i searched for a replacement for the old SCSI root disk, because the drive bearings were worn out. Everytime i booted the Indy i was welcomed with a terrible howl from the not-so-very-old IBM DDRS 34560 4.5GB.

Fortunately, fellow Nekochanners Smj, Aperezbios, Tomvos and Jirka discovered the SCSI2SD interface board as a cheap alternative to the ACARD SCSI2IDE solutions i had been using in the past. The latter two 'channers have had successful reports of this device inside the Indy, so when i purchased the board and tested it, i figured it was time for a wiki page.


The SCSI2SD board is designed by Michael McMaster to emulate a SCSI device, be it a Hard Disk drive, Removable drive, Floppy drive, CDROM or Magneto-Optical device.

The board has a 50-pin internal SCSI flatcable connector and Molex power connector which interfaces with the computer or sampler and has (optional) termination resistors installed. At the back of the board there is a microSD card holder for data storage and a micro-USB type B connector to (optionally) power the device and program it. A LED post completes the design.

The hardware design and software are open-source and the boards are produced by a Chinese company called Itead.

The official web page for the SCSI2SD board is here. There is also a FAQ.

Things you need

screenshot of log window of scsi2sd-util tool
scsi2sd-util finds a device and microSD card

In order to use the board you have to provide it with a microSD card with SD/SDHC capability. For my endeavours i used two microSD cards: a Sandisk 8GB class 4 and a Sandisk Ultra 8GB class 10. You need to program the device (and possibly update the firmware) with the scsi2sd-util tool. This tool runs in Windows, Macs and Linux and can be downloaded here

Make sure the board has the latest firmware (currently 4.6). If you need to update it, you can get it from the above repository as well.

Start the software. It will poll for the SCSI2SD card via the USB port. Next, connect the SCSI2SD board with a USB-cable to the PC/Mac. The software displays the board and SD-card blocksize in the log window. My sandisk microSD cards both report 15467520 blocks of 512 bytes, so i used that number in the next step.

Now program the device to emulate a SCSI root disk for the Indy. Use the following parameters in the General Settings tab:

  • Enable Parity = ON
  • Enable SCSI2 Mode = ON

Click on the Device 1 tab and change the following parameters:

  • SCSI-ID = 1
  • Device Type = Hard Drive
  • SD card start sector = 0
  • Sector size = 512
  • Sector count = 15467520 (the number reported in the log window)

Leave the rest to their default values. Now click on "Save to device" and let the ssi2sd-util program the device.

Screenshot of General Settings tab window of scsi2sd-util
General Settings
Screenshot of Device 1 tab
Device 1 Settings

SCSI2SD card inside the Indy

Because my board is the small revision 5 (red PCB) it only has two bottom mounting holes. Initially i tried to bolt the card on the edge of the bracket to keep the scsi connector flush with other harddisks, but the elongated holes in the bracket causes the board to move when inserting/removing sd-cards and USB-cables, so i decided to mount the PCB at the middle bracket holes.

Photo of SCSI2SD card mounted inside an Indy disk bracket
Top view of SCSI2SD card in Indy disk bracket
Photo of SCSI2SD card in Indy bracket, rear view
Rear view. Note the black vinyl standoffs
Photo of Indy with installed SCSI2SD on bracket
The SCSI2SD with bracket inside the Indy

You need 2 M3 bolts with length 1/2" or 15mm, two lock-nuts and four washers. To protect the board from the underside, cut out some clear plastic the same size as the board, make holes for the bolts and place it underneath. In the middle bracket hole position the board has to be elevated about 2 mm to get sufficient clearance from the steel bracket. To accomplish that i used two small plates which i cut out of black vinyl. Make the plates sufficiently large to prevent the board from rocking.

I've secured the PCB by placing the M3 bolt through a washer, bracket hole, clear protect plastic, vinyl, PCB, washer and lock it with a lock-nut.

Put the bracket in the top position and use the bottom SCSI-connector to connect the board. The revision 5 board has a led post to attach an extra led, but the onboard led is bright enough and can be seen through the floppy port if you leave out the steel cover plate. (note: the extra molex connector in the bottom left of the picture is for providing power to the 92mm fan in the power supply.)

Remove the on-board termination resistors. There is termination at the end of the SCSI band cable. If you need to reapply them, orient the resistors so that the dot on the resistor is closest to the power connector.

People who are using this board in the Indy strongly advise to apply termination on the SCSI chain at the back of the machine. Since the Indy only has one WD33C93, all the SCSI devices are on a single bus so make sure proper termination is applied on both ends.

Partitioning with fx

After netbooting fx, i made a basic root disk of about 7.3GB space and increased the swap space to 256MB. I used 512 bytes as block size. The fx full dump is then:

Error correction enabled          Disable data transfer on error
Do report recovered errors        Do delay for error recovery
Do transfer bad blocks            Error retry attempts           0
No auto bad block reallocation (read)
No auto bad block reallocation (write)
Drive readahead disabled          Drive buffered writes disabled
Drive disable prefetch       0    Drive minimum prefetch         0
Drive maximum prefetch       0    Drive prefetch ceiling         0
Number of cache segments     1
Read buffer ratio        0/256    Write buffer ratio         0/256
Command Tag Queueing disabled

----- current drive geometry-----
      Tracks/zone =    0       Sect/track =   63
    Alt sect/zone =    0       Interleave =    1        Cylinders =  962
 Alt track/volume =    0    Cylinder skew =    0            Heads =  255
   Alt track/zone =    0       Track skew =    0   Data bytes/sec =  512
  Rotational rate = 5400
----- partitions-----
part  type        blocks            Megabytes   (base+size)
  0: xfs      528384 + 14939136     258 + 7294 
  1: raw        4096 + 524288         2 + 256  
  8: volhdr        0 + 4096           0 + 2    
 10: volume        0 + 15467520       0 + 7552 
----- bootinfo-----
 root partition = 0     swap partition = 1    bootfile = /unix
----- directory entries-----
 0: sgilabel   block    2 size     512  2: sash       block  673 size  343040
 1: ide        block    3 size  343040
----- sgi-info-----
   serial =                              name =  codesrc         SCSI2SD 4.2

Readahead and Buffered Writes cannot be enabled, most likely because the board doesn't have a cache.

Installing and running IRIX

I've installed IRIX 6.5.22m on the SCSI2SD device for my 180MHz R5000 Indy with 192MB ram and a XL24 graphics board. The installation is the same as installing on a regular disk, but because the SCSI2SD board does not support sync negotiation, you will receive the following warnings:

- sc0,1,0: SYNC negotiation error, resetting SCSI bus.
- NOTICE: wd93 SCSI Bus=0 ID=1: SYNC negotiation error, resetting bus.

These are messages from the wd93 SCSI controller driver. It is possible to disable sync negotiation for the SCSI2SD device after IRIX is installed. To do this, go to /var/sysgen/master.d/ and edit wd93 as root:

/*  Bitmap of target ID's for which synchronous SCSI mode may be
        negotiated (per scsi adapter, or channel or bus).  If unit
        doesn't support this mode, and the device obeys the protocols,
        then it is OK to enable it here;  If device doesn't follow
        protocols, then do not set the bit (devices that don't follow
        the protocols typically result in SCSI bus timeouts and
        resets.  At this time, only disks and DAT tape are considered
        candidates.  Set the 0x80 bit for ID 7, 0x40 for ID 6 ... 0x2
        for ID 1.  On machines that don't support sync. SCSI, (such as
        4D80 and 4D70) this variable will be zeroed at boot time.  This
        is a bitmap per adapter; for systems with a single SCSI
        channel, you only need to change the first value.
u_char wd93_syncenable[SC_MAXADAP] = {0xfe /* scsibus 0 */, 0xfe /* scsibus 1 */, 0xfe /* scsibus 2 */, 0xfe /* scsibus 3 */};

Change the last line, replace the first hex 0xfe with 0xfc like this:

u_char wd93_syncenable[SC_MAXADAP] = {0xfc /* scsibus 0 */, 0xfe /* scsibus 1 */, 0xfe /* scsibus 2 */, 0xfe /* scsibus 3 */};

By doing this you've set bit 1 of the sync-enable bitmap of the first SCSI-bus (= 0) to 0 which disables sync negotiation for the SCSI device with id = 1 (which is the SCSI2SD device)

Then perform the kernel reconfiguration by entering the command autoconfig and when finished, reboot the Indy.

The IRIX bootloader will still report and display sync negotiation errors when booting IRIX because to my knowledge only the wd93 driver in the main IRIX kernel can be adjusted this way, and not the bootloader.

The IRIX Disk and Filesystem managers see the SCSI2SD device as a regular Hard Drive. In short, it works :)

Screenshot of IRIX Desktop with File and Disk Manager showing the parameters for the SCSI2SD device
IRIX Desktop with File- and Disk Manager showing the SCSI2SD device


Disk I/O performance can be tested in IRIX using diskperf. I tested both Sandisk microSD cards to see whether the speed class made any difference. First diskperf test is with the class 4 Sandisk 8GB

indy 3% diskperf -W -D -n SCSI2SD -t 10 -c 100m testfile
# Disk Performance Test Results Generated By Diskperf V1.2
# Test name     : SCSI2SD
# Test date     : Tue Mar 22 21:24:04 2016
# Test machine  : IRIX indy 6.5 10070055 IP22
# Test type     : XFS data subvolume
# Test path     : testfile
# Request sizes : min=4096 max=4194304
# Parameters    : direct=1 time=10 scale=1.000 delay=0.000
# XFS file size : 104857600 bytes
# req_size  fwd_wt  fwd_rd  bwd_wt  bwd_rd  rnd_wt  rnd_rd
#  (bytes)  (MB/s)  (MB/s)  (MB/s)  (MB/s)  (MB/s)  (MB/s)
       4096    0.54    0.91    0.54    0.90    0.45    0.84
       8192    0.58    1.03    0.24    1.03    0.03    0.91
      16384    0.83    1.14    0.26    1.13    0.03    1.02
      32768    0.75    1.20    0.41    1.18    0.07    0.93
      65536    0.75    1.23    0.65    1.23    0.17    1.18
     131072    0.92    1.24    0.75    1.24    0.26    1.14
     262144    0.74    1.25    0.42    1.25    0.34    1.06
     524288    0.79    1.27    0.82    1.27    0.79    1.27
    1048576    0.84    1.28    0.96    1.28    0.90    1.27
    2097152    0.96    1.25    1.06    1.28    1.16    1.28
    4194304    1.09    1.16    1.18    1.28    1.42    1.28

My first impression was that the SCSI2SD board was quite slow, which is what i more or less expected from reports. The WD33C93 controller in the Indy is able to reach 10 MB/sec on a modern SCSI disk, but the numbers are nowhere near that.

Logging into IRIX felt like a chore, and i frequently noticed the card "locking up" when trying to display the desktop. You would see partially completed window decorations, which finish one minute later.

However, if i clone the disk to a class 10 Sandisk Ultra 8GB and redo the diskperf test, we get:

indy 3% diskperf -W -D -n SCSI2SD-10 -t 10 -c 100m testfile
# Disk Performance Test Results Generated By Diskperf V1.2
# Test name     : SCSI2SD-10
# Test date     : Sun Apr  3 14:55:08 2016
# Test machine  : IRIX indy 6.5 10070055 IP22
# Test type     : XFS data subvolume
# Test path     : testfile
# Request sizes : min=4096 max=4194304
# Parameters    : direct=1 time=10 scale=1.000 delay=0.000
# XFS file size : 104857600 bytes
# req_size  fwd_wt  fwd_rd  bwd_wt  bwd_rd  rnd_wt  rnd_rd
#  (bytes)  (MB/s)  (MB/s)  (MB/s)  (MB/s)  (MB/s)  (MB/s)
       4096    0.58    0.79    0.66    0.56    0.79    0.91
       8192    0.89    1.05    0.99    1.04    0.43    1.04
      16384    1.19    1.14    0.98    1.14    0.56    1.13
      32768    1.22    1.20    0.64    1.20    0.16    1.19
      65536    1.09    1.23    0.96    1.23    0.30    1.22
     131072    1.03    1.25    0.95    1.24    0.44    1.24
     262144    1.28    1.25    1.19    1.25    0.65    1.25
     524288    1.34    1.27    1.12    1.26    0.97    1.26
    1048576    1.29    1.28    1.20    1.27    1.01    1.28
    2097152    1.44    1.23    1.45    1.28    1.25    1.28
    4194304    1.43    1.28    1.40    1.28    1.38    1.28

The sequential write values have improved quite a lot. It looks like the microSD write performance is a bottleneck which fast class microSD cards can mitigate. Subsequently, the Indy feels more responsive and almost never stalls. Since my microSD card is the exact same card Tomvos used in his diskperf measurements, our measured values are very similar. Actually, his measurements were the reason why i sourced the Sandisk Ultra Class 10 card.

I therefore recommend using a class 10 micro SD(HC) card. The 8 and 16 GB Ultra cards by Sandisk are relatively cheap and can be had for about 7-8 Euros

Cloning the microSD card

To create a file image of the IRIX installation on the microSD card, use dd in Linux:

dd if=/dev/sde of=6522.raw bs=512 count=15523840

Where /dev/sde is the device for the SD card. You can then use the .raw file to mount it via a loop device for interesting effects :) or clone it to another microSD card:

dd if=6522.raw of=/dev/sde bs=512 count=15523840