search

PiSCSI / piscsi

PiSCSI allows a Raspberry Pi to function as emulated SCSI devices (hard disk, CD-ROM, and others) for vintage SCSI-based computers and devices. This is a fork of the RaSCSI project by GIMONS.
https://piscsi.org
BSD 3-Clause "New" or "Revised" License
545 stars 82 forks source link

[Wild Idea]: Allow RaSCSI to act as a SCSI/USB bridge for modern PCs #496

Open marciot opened 2 years ago

marciot commented 2 years ago

Here is a pie-in-the-sky idea I had the other day. It would be swell if RaSCSI was able to act as a USB bridge for SCSI devices :grin: The motivation for this is that even though dedicated USB/SCSI adapters exist, they are rare and very expensive, running several hundred dollars on eBay.

So the idea is that if I had, say, a SCSI Zip drive, and I wanted to read it on a modern PC, I could connect a USB cable from my PC to the RaSCSI board and connect the SCSI device I wanted to use to RaSCSI. Then maybe I would check a checkbox next to a device in the web interface so that:

  1. The USB port was switched into OTG mode and present itself using the USBMassStorageDeviceClass profile
  2. The RaSCSI would begin forwarding SCSI commands between the USB interface and the checkmarked SCSI device, allowing the PC to mount and read/write to the drive.

At first blush, it would seem like this would be a software only hack, but discussion thread https://github.com/akuker/RASCSI/issues/454 indicates that maybe it would require a hardware modification.

At the least, I would hope that this new use case would give some motivation for including this change on future hardware revisions. It certainly would allow the RaSCSI to do something no other projects is doing and maybe increase the user base to people who merely want to read data off a drive on their modern PCs and don't necessarily have a vintage PC.

Hell, one could slap RaSCSI's in a 3D printed case and sell them on eBay for a few hundred at a pop... at least until the word gets out! 😆

akuker commented 2 years ago

That's a pretty slick idea. Its definitely do-able, especially if you only have one SCSI device connected. I'm going to tag this as an "enhancement" though ;)

The first step of just having the Raspberry Pi host be able to mount/read the SCSI device directly would be a huge one as well. From there, you could do a NFS mount (or something similar) to make the files accessible by another host.

uweseimet commented 2 years ago

@marciot This idea is more or less the counterpart of https://github.com/akuker/RASCSI/issues/497, isn't it? I also created https://github.com/akuker/RASCSI/issues/498 after reading your ticket. I had this in mind for some time, but due to the big effort required I did not create a ticket till now. https://github.com/akuker/RASCSI/issues/498 might be an alternative approach to your ticket, because a modern PC could simply access the SCSI device connected to the Pi via a network share, assuming that the data on the SCSI drive are filesystems the Pi can mount. No USB would be required. I think that's similar to what @akuker says in his comment.

marciot commented 2 years ago

The first step of just having the Raspberry Pi host be able to mount/read the SCSI device directly would be a huge one as well. From there, you could do a NFS mount (or something similar) to make the files accessible by another host.

@akuker: I am not recommending that the Raspberry Pi mount the drive, instead I am recommending it pass-through the SCSI commands directly to the host via the USB. This would potentially allow devices other than drives to be used by the host.

This idea is more or less the counterpart of #497, isn't it?

@uweseimet: No, as I said, my suggestion does not involve having the Raspberry Pi mount the drive.

So basically there are two different suggestions on the table:

  1. Have the Raspberry Pi be able to mount a drive so that it can be accessed from the Pi and/or exported via NFS
  2. Have the Raspberry Pi pass-thru the SCSI commands to the USB port so the connected PC host can mount the volume and/or send low level commands to a non-disk device.

These are two very different approaches.

marciot commented 2 years ago

TBH, approach 2 could probably be tackled by something like the BlueSCSI, as when doing a simple-passthru adapter, Linux and WiFi are kind of redundant.

uweseimet commented 2 years ago

@marciot Are there any advantages of approach 2. compared to 1. except for the PC being able to also access devices which do not have a filesystem the Pi can mount (and export)? 1. already means a lot of work, but 2. is IMO even more complicated. You say a "simple" pass-through adapter, but I doubt that it's that simple ;-). Do you have a (common) use case where 2. would be required and 1. would not work?

marciot commented 2 years ago

@uweseimet: well, I don't have a specific use case in mind. Just thinking out loud. I agree that 1 would probably bring the most benefit to the most people.

I would think the two approaches would be roughly the same amount of work if someone has already written some code to allow a Raspberry Pi to act as USB Mass Storage device. If that is the case, then would only have to write the code to allow RaSCSI to send commands to the drive, which would also be required for the first approach. I know implementing USB Mass Storage devices is pretty common stuff in the microcontroller world, but I don't know how common it is in the RaspPi world.

marciot commented 2 years ago

@uweseimet: Well, so I guess you can already share a mounted file system as a USB mass storage device, as described here:

https://magpi.raspberrypi.com/articles/pi-zero-w-smart-usb-flash-drive

So arguably if you implemented it the first way, you get the second way for free. It just would not support direct SCSI commands for esoteric devices and you couldn't, for instance, have the host eject the disk in a removable drive.

But I agree the first method is more beneficial.

uweseimet commented 2 years ago

@marciot Is the USB mass storage device interface easily mappable to the SCSI interface? If there is no (more or less) one-to-one mapping of USB interface to SCSI interface commands approach 2. may be impossible. (SCSI to USB is possible, though, so maybe vice versa is as well.) There are interfaces that are so different that they are hardly mappable. From what I know mapping SCSI to NVMe is such a case because the NVMe protocol is fundamentally different from the SCSI protocol.

marciot commented 2 years ago

I know that in the case of a USB Mass Storage Device, the interface is very simple, basically read a block at this address, write a block. This would have a slight advantage over method 1, in that the host could read file systems that the Raspberry Pi could not understand; but it still would not allow custom vendor specific commands.

I have not been able to determine yet is whether there is a SCSI specific USB storage class that would allow arbitrary commands to pass through unchanged. I am surmising that it does because USB SCSI adapters that work with the Zip drive do exist.

berlin4apk commented 2 years ago

For the way 2* I have a direct use Case: I have a old high speed A3 scanner, which need the vendor software on a old windows version. With the way 2, i cud have a qemu or virtualbox running the vendor software with windows and attach the scanner via rascsi

vonj commented 2 years ago

My interest is connecting SCSI film scanners to modern computers. That would require pass through:

device <> linux SCSI sg

ajacocks commented 2 years ago

Given the very high cost of USB-SCSI interfaces, this would be a very valuable enhancement to RaSCSI. I have to go through gyrations every time I want to either image a SCSI disk, or to write an OS to one, that I don't have to go through for IDE or MFM devices.

DrReD commented 2 years ago

Yeah. And old usb2scsi adapters, or old PCs with SCSI cards, ain't gonna live forever either...

jeroenbrons commented 2 years ago

maybe this feature could run a iSCSI target which other systems can use as a block device (no USB needed then)

DrReD commented 2 years ago

Il giorno gio, 03/03/2022 alle 03.29 -0800, Jeroen Brons ha scritto:

maybe this feature could run a iSCSI target which other systems can use as a block device (no USB needed then) — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.Message ID: @.***>

It would be great already, if it could read SCSI devices on the Pi itself. :)

-- Bye, ReD

raybellis commented 2 years ago

There are other non-disk use cases - in my case it would be for audio sample interchange over SCSI.

dericed commented 9 months ago

I've been fascinated to find this issue as I find it highly needed; I'm specifically referring to @marciot's approach 2 scenario. In my use-case I'd like the connectivity options to DDS drives to be more accessible (currently I use a Mac G3 with a SCSI PCI board and another with a SCSI<-> firewire solution but I would love to use more modern computers). As noted, SCSI adapters are $$$ and hard to obtain, so an open hardware effort would be a great help to many that still need SCSI devices around. @akuker I dug through the sponsor section on this repo and saw general ways to sponsor this project but none to sponsor a particular issue. I'm quite interested in this proposed enhancement so if sponsorship helps, feel welcome to let me know how.

littlejackal commented 5 months ago

+1 for this feature. My use case is to passthrough non-disk SCSI devices to a Linux host.

For the sake of this conversation let’s assume that adding a SCSI add-on adapter isn’t desireable or feasible for any number of reasons.

The envisioned use for me would be to (example) attach a SCSI tape drive to the RaSCSI, plug the RaSCS into the linux host as USB, and allow the system to control it as it would a directly connected tape device. Not something that is accomplished simply by exposing it via an NFS mount.

I’m handwaving the complexity of actually having the operating system recognize the RaSCSI as a SCSI HBA, but conceptually this functionality if of great use to me.

ewanuno commented 2 months ago

+1 for this idea. i would like to use scsi hardware samplers with modern computers too.

this would probably involve an iscsi server running on the PI sharing the scsi device over the network, and an iscsi client in an xp virtual machine with the old native sampler control software.

iscsi device sharing for non disk devices has been demonstrated with scsi scanners. https://sprocketfox.io/xssfox/2024/05/08/jbos/

a proof of concept for this could be done with pc with a scsi card running an iscsi target.

wmlive commented 2 months ago

Adding a pointer to https://github.com/svenschnelle/teensyscsi where a working implemenation for USB SCSI Controller utilizing Teensy 4.1 has already been put into reality three years ago. There is an associated forum thread https://forum.classic-computing.de/forum/index.php?thread/24720-low-cost-usb-scsi-adapter/ at a German vintage computer forum. Maybe this might serve as inspiration for interested parties.

On the BlueSCSI side, there seem to be similar ideas at https://tinkerdifferent.com/threads/scsi-to-usb-adapter-reverse-engineering.1878/ but no implementation attempts so far beyond initial brain storming.

Would love being able to use SCSI MO drives and other SCSI devices on modern laptops via USB.

lucianjames commented 1 week ago

+1 for this idea for the purpose of using non-storage SCSI devices (scanners in my desired use case)

akuker commented 1 week ago

I've been looking into this a bit, and I'm thinking of taking a different approach, that I think will meet all your use cases.

What I'm thinking is to use the BlueSCSI as a USB/SCSI adapter that will work like those expensive USB/SCSI adapters on ebay. image

This eliminates a lot of the complexity of the Linux kernel/drivers/etc. BlueSCSI also has better performance due to the PIO in the RP2040.

I'm planning to do the work under this issue if you want to watch it. The ticket currently only calls out mass storage devices, but I'm thinking this can be expanded to also included Scanners https://github.com/BlueSCSI/BlueSCSI-v2/issues/13

(One note: This feature will only work with the BlueSCSI "Desktop" version with initiator support.)

ZigZagJoe commented 1 week ago

I've been looking into this a bit, and I'm thinking of taking a different approach, that I think will meet all your use cases.

What I'm thinking is to use the BlueSCSI as a USB/SCSI adapter that will work like those expensive USB/SCSI adapters on ebay. image

This eliminates a lot of the complexity of the Linux kernel/drivers/etc. BlueSCSI also has better performance due to the PIO in the RP2040.

I'm planning to do the work under this issue if you want to watch it. The ticket currently only calls out mass storage devices, but I'm thinking this can be expanded to also included Scanners BlueSCSI/BlueSCSI-v2#13

(One note: This feature will only work with the BlueSCSI "Desktop" version with initiator support.)

FWIW, ZuluSCSI already has USB mass storage support implemented for SD card access (I wrote it :) ). It ought to be pretty easy to mate that up to the initiator code that's shared between Zulu and Bluescsi. It's been on the "when I get bored" to-do list for a while.