USB enclosure with IDE disc

After years of fun and frustration I finally retired my Iyonix PC when it violently rejected its third replacement PSU after one month of completely troublefree use. I have a Raspberry Pi and inspired by a thread in the RISC OS section of the Pi forum, I bought a USB enclosure for the Iyonix’s disc in the hope I would be able to use it with the Pi. Doesn’t work.

My Linux box sees the device with no issues, but thinks the drive isn’t formatted of course.

Anyone familiar with this thing: http://www.pclcomputers.nl/productinfo.asp?productid=39875
More detailed description: http://www.sweburn.com/product.php?productid=1089

I know USB on RISC OS is not exactly a plug and play thing – I have another external hard drive which totally locks any RISC OS machine it’s plugged into. Yet I was hoping I might be lucky this time. Does anyone have any suggestion about what I could do to get close to what’s mentioned in this thread: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=55&t=30180

I’m not even thinking about actually running the Pi from the HD yet. Just having the HD show up on the Pi would be nice.

Some additional info. When the Pi is booted with SCSI discs set to 1 and the USB HD switched on, it doesn’t get past the second green boot up screen (eternal hourglass). If the HD is switched on or plugged in when the Pi is already running, the hourglass shows up as well and all USB devices (well, keyboard and mouse at least) stop responding. This is irrespective of SCSI discs setting. Booting with SCSI discs 0 works, but nothing shows. The device does show up in the USBDevices listing (number 4):

*usbdevices
No. Bus Dev Class Description
1 1 1 9/ 0 Synopsys DWC OTG root hub
2 1 2 9/ 0 Standard Microsystems Product ID 9512
3 1 3 9/ 0 Vendor ID 1A40 USB 2.0 Hub [MTT]
4 1 4 0/ 0 Super Top USB 2.0 IDE DEVICE
5 1 5 0/ 0 Tangtop USBPS2
6 1 6 FF/ 0 Standard Microsystems SMSC9512/9514 Ethernet device

*usbdevinfo 4
USB release : 0200
Device class : 00
Device subclass : 00
Device protocol : 00
Max packet size : 40
Vendor ID : 14CD
Product ID : 6600
Device ID : 0201
number of configs : 1
Manufacturer : ‘Super Top ’
Product : ’USB 2.0 IDE DEVICE ’
Serial number : ’??????’

Was this just another waste of time and money?

Edit: had to replace the hash with ‘number’ in the usbdevinfo listing to prevent this ******* forum software from screwing up.

I have no experience with the enclosure you have, but I ran my Raspberry Pi with a USB hard drive from day 1. No trouble at all. The one I have is a 2.5" portable USB drive that was on offer at Maplin at the time – I don’t remember the exact size but I think it was probably 250 GB.

I’ve use it with the the original model B and the later revision model B (the one where they kindly moved the IIC pins).

I always use the RPi with a 7 port powered hub. The drive has a Y cable in order to pick up power from two outlets.

Do make sure that your hardware setup provides enough power to all items. Failure to do so seems to be a frequent problem. Resistance of cables and of internal RPi protection devices is a well known cause.

I hope this at least gives you encouragement that it is possible.

Thanks Dave.
This enclosure has its own power supply.
I also have a 7 port powered hub, so your solution would be feasible. However, with my luck I’ll probably end up buying another failure. :(

Besides, I would really like to be able to get at one particular piece of data on the Iyonix disc. My last backup was done Saturday evening and I did some work on Sunday morning. Sunday afternoon the machine decided it didn’t like the new PSU after all (can’t understand why it took a whole month to make up its mind…).

had to replace the hash with ‘number’ in the usbdevinfo listing to prevent this ******* forum software from screwing up.

Did you try using <pre> tags?

I have two different IDE to USB enclosures, self powered, both I think from Maplin in the distant past. I have a pile of old IDE drives from previous and this Iyonix (ADFS format), of sizes of 80 – 120GB. I have often put them in to one of the enclosures to look for old files and never had any trouble on this Iyonix. RISC OS format drives over usb are rather slow of course. I have used one of these once on the BB and it was fine.

On the BB and RPi, using modern usb-SATA enclosures and SSD drives is a bit more unpredictable. All mine have the double usb lead in to an external powered hub, but even then there are sometimes problems which I think are due to power or timing issues. The same drives when used on the Iyonix have never given any problem – an Iyonix is not all bad!

Besides, I would really like to be able to get at one particular piece of data on the Iyonix disc.

D’oh. Linux kernel has support for adfs discs. Getting stuff off the HD is a piece of cake.

As this confirms that both the enclosure and the HD are fine, I would still like to be able to use it with the Pi. I have no expertise at all where USB is concerned. Is there any way to make RISC OS see this particular device anyway?

My apologies for not looking thoroughly enough the first time.

I see your problem. The enclosure needs to be seen as 8-6-80, but it is seen as 0-0-0.

I can only hope that the class-subclass-protocol are seen at interface level as 8-6-80, but I can’t remember how to find out, apart from writing some code to get hold of the descriptor and then parsing it by eye.

How does XAT’s !USBInfo app see it?

How does XAT’s !USBInfo app see it?

   Device: 4
      DeviceFS  : USB11
      USB spec  : 2.00
      Class     : 0     (Defined at Interface level)
      Subclass  : 0
      Protocol  : 0
      MaxPacket : 64
      Vendor    : 14cd
      Product   : 6600
      Release   : 2.01
      Speed     : Hi-speed (480 Mb/s)
      NumConfigs: 1

      Config: 1
         MaxPower  : 2 mA
         Attributes: (Self-powered)
         Interfaces: 1

         Interface: 0
         Alternate: 0
            Class     : 8     Mass Storage
            Subclass  : 6     SCSI
            Protocol  : 80    Bulk (Zip)
            Endpoints : 2

            Endpoint: 1
               Direction : IN
               Transfer  : Bulk
               MaxPacket : 512
               Interval  : -

            Endpoint: 2
               Direction : OUT
               Transfer  : Bulk
               MaxPacket : 512
               Interval  : -

This looks like the same problem as Raik’s on another thread. I think you will find that *usbconfinfo will show an 8,6:80 interface. Usbconfinfo is derived from the same data that is passed to scsisoftusb for it to recognise a device.

“My problem” I have only with a newer ROM (after 28 May). If I use older ROMs (eg from 28.May or the original RC8) all things are fine.

This looks like the same problem as Raik’s on another thread. I think you will find that *usbconfinfo will show an 8,6:80 interface.

Yup.

*usbconfinfo 4
Current config  : 1

number of interfaces : 1
Config value    : 1
Name            : ''
Attributes      : Bus powered
                  Self powered
Maximum power   : 2mA

Interface 0.0 class 8.6:80 ''
 1 IN  Bulk 512 bytes 0 frames
 2 OUT Bulk 512 bytes 0 frames

“My problem” I have only with a newer ROM (after 28 May). If I use older ROMs (eg from 28.May or the original RC8) all things are fine.

This is with the March ROM from the Raspberry Pi site.

I’m just confused ;-) I mean I use in my Lapdock the RC8 Image from March the surfstick cardreader worked perfectly. With a new ROM not.
On the Pandora I have just checked again 28 May ROM is ok, 30.May card reader is not detected.
My *usbconfinfo output you can find in the Bug-thread.

I’m just confused

As am I. usbconfinfo shows that the USB layer can read the information from your device. The test program I sent shows that opening and closing the device doesn’t cause an error – which may have been a problem caused by a change to usbmodule on May 27. Also some 8.6:80 devices work.

I’ve made up a debug version of scsisoftusb (scsisoftusbdebug/zip) which hopefully will tell us where it fails.

It includes the DADebug module and SCSISoftUSB modules. To use it put it in a nonusb filing system – the ramdisc will do. Unplug your usb drives and run ‘setup’ in the archive. This loads DADebug and SCSISoftUSB. Now in a taskwindow type ‘*dadreset’ – this clears the debug data. Insert the problem disc and type ‘*dadprint’ this results in debugdata being printed in the taskwindow.

If either of you would like to try it and make the debug data available. I may be able to trace the problem.

If you have a drive that works it may be useful to see the debug info for that. (just *dadreset, insert the drive and *daprint)

I can’t help with the USB enclosure issue, but one thing from your first mesaage:

When the Pi is booted with SCSI discs set to 1 and the USB HD switched on, it doesn’t get past the second green boot up screen (eternal hourglass)

I think the SCSI discs setting is for real SCSI hard discs connected via a SCSI podule, so it’s not surprising it hangs on a Pi!

Well I’ve taken the Pandora and surf stick to job;-)
You can download dadprint.zip.

Many thanks.

That looks an easy one. If you reload scsisoftusbdebug/zip it should now work.

SCSISoftUSB was swapping the Alternate and Interface values in the usb special field. Prior to fixes I made to special fields, in devicefs, values could be ignored. After that fix all values in the special field work so it exposed this bug in SCSISoftUSB.

I would be interested if it fixed Frank’s drive too.

I think the SCSI discs setting is for real SCSI hard discs connected via a SCSI podule, so it’s not surprising it hangs on a Pi!

When something doesn’t work, you fiddle with settings. :)

As I wrote in my first posting, plugging the drive in when the Pi was already running – which was my first attempt, with SCSI still at 0 – had the same effect.

First short test on the Pandora works fine. Online with Surfstick and the storage card is working. RPi I can try at the evenning.

Many thanks.

@Frank
Is it possible that the Filer sees old stuff in root and execute this? E.g. have you renamed your old !Boot in Boot etc.?

I would be interested if it fixed Frank’s drive too.

Was that second zip supposed to contain a different version of scsisoftusb? I got one that was identical to the first.

There’s a zip at http://aconet.org/tmp/taskwindow.zip with three taskwindow outputs. Doing what is described in your zip’s !readme results in that behaviour: either a hang with hourglass (until the drive is unplugged again) or nothing at all.

Edit: actually, I’m starting to wonder if this whole excercise is worth it. When I transferred the taskwindow output to my linux box over my local network, writing 400KB took 10 seconds. I knew outbound ether over usb was slow, but this is ridiculous. I need something I can run a (small) server on. That is so not going to be anything this slow!

@Raik.

Great I’ll submit the changes.

@Frank.

The file is the same I just updated scsisoftusb in it

This isn’t the same problem as Raiks – obvious really as your alternative value and interface value are the same so swapping them won’t matter. Your drive is failing with a USB IOERROR. When I’ve encountered this it has been due to an overrun error.

There’s an outside chance that changes to buffersize seen in the latest ROMs fix this. Failing that I may have a fix. In the usb modules I’m running I’ve fixed a problem I was having with overrun errors. Unfortunately I don’t know how to softload the USB modules for you to try them out as softloading causes the computer to hang.

@Frank
I have “played” a bit with xM, Panda and Rpi. James had EtherUSB suspected but the problem is something else. LAN and surfstick is about 10x slower than I upload with the Rpi than with xM under RISC OS. Under Linux, this is not like that. The download on both boards have the same speed.
RPi, Panda and xM are using the same SMSC chipset.

Edit: Forgot … I have also tested with the RPi Model A and my Lindy adapter. The upload is similarly slow.

The new SCSISoftUSB module fixed also the detectproblem on the RPi.
But I have a new “Error Message” if I Shutdown RISC OS (I try xM, Pandora, RPi). On shutdown I become a “Device not found” Message but no device is dismount/removed.

Thats a consequence of softloading SCSISoftUSB. USB modules don’t seem to take kindly to softloading. It won’t happen when the rom is changed. Do you have a drive plugged in when you softload SCSISoftUSB?

Do you have a drive plugged in when you softload SCSISoftUSB?

Pandora and RPi only SDFS. xM = PIK = ARMini and PandaXL DVDROM, HD and Cardreader are plugged.
I need the SurfStick only for my RPi Lapdock and for the Pandora.

It happens for me on an Iyonix if I softload scsisoftusb when I have a usbdrive plugged in. In fact you don’t need to softload scsisoftusb just rmkill scsisoftusb and shutdown. !closefiles shows that after rmkilling scsisoftusb the usbdrive devices are still open. When you shutdown DeviceFS tries to close them but they don’t exist.

I note that the fix has made it to the sources so presumably it will appear in tomorrows roms.