Anyone tried BlueSCSI with a Sun Sparcstation?

[rreiner]

Has anyone tried BlueSCSI with a Sun Sparcstation or Ultra Sparc?

I have several (a Sparcstation 20, Sparcstation 10, Sparcstation 2, SparcClassic, and an Ultra 1) that all need SCSI-2 drives.

I'm willing to be the guinea pig if it hasn't been tried, but if there is known no-go I'd be glad to hear of it before trying...

Thx!

[teiram]

I tried it myself on a Sparc classic but was not able to make it work. The same BlueScsi unit works flawlessly on a Macintosh LC, so I don't think it's a building issue.
I compiled a debug version to try to see where it gets stuck and what I can see after issuing a 'probe-scsi' command from the openboot prompt in the Sparc machine is that there is a bus reset and then a command is detected by the BlueSCSI device. It seems it gets stuck in the call readHandshake() in this place in the code:

I understand this is the case since I get a "Command:" log in the serial port and then nothing else happens.
I have no idea about the SCSI protocol but would be eager to support in testing. Don't know if this could be a timing issue or what and I'm also aware the Sun Sparc is not among in the supported devices list, but if there is any idea to try to make it work, just let me know. :-)

[realfogman]

Hello teiram,

you are right.
There is something in the function readHanshake().
Specifically in the while loop while( ! SCSI_IN(vACK)) { if(m_isBusReset) return 0; } after SCSI_OUT(vREQ,active), waiting for the response?!
This could be due to a better/different/"newer" implementation of the SCSI stack (HW and SW) in these machines? Timings?
Or maybe, the vACK signal is never thrown by the machine?

Currently I'am testing BlueSCSI on a SUN SPARCClassic, but using the BlueSCSI implementation from https://github.com/mynameistroy/BlueSCSI.

Hopefully I can give some more information in the next days.

[teiram]

Hey @realfogman, looking forward to hear from your findings :)

I guess it can be some timing issue, but not sure of that. Probably I could attach a logic analyzer to the relevant lines but I'm not confident with the SCSI protocol and probably wouldn't know what to look for. It looks like the BlueSCSI detects a command from the host, but then it's not able to decode it. It could be that the timing for the three SCSI_OUT commands that are issued after the command is detected plays a key role here?

[realfogman]

Hello @teiram ,

I think I know, whats going on here.
I have attached my little logic analyzer and captured the vREQ and vACK signals (PB6 and PA10).
Right after powering the sun, the vREQ signal is thrown and around 113 us later, the vACK responds was set to high by the sun classic.
Furthermore, the vACK stays high all the time, so the BlueSCSI device should be capable of capturing the vACK signal?!
Since it is not recognized by the BlueSCSI device, I attached a voltmeter and measured only 2.8 volts on PA10 (vACK).
I then did some term-jumper-switching!
E voila, by setting term jumper JP2 open and JP1 closed, the sun recognized the BlueSCSI as a

Target 0
  Unit 0 Disk QUANTUMFIREBALL11.0

The problem now seems to be timing, since I am reciving SCSI bus DATA IN phase parity error messages and the disk won't format.
So, no luck at the end (yet).

Greetings.

[gammy]

Just to clarify (as I had to look at the KiCAD files to check), JP2 is the jumper closest to the MCU (BluePill), and JP1 is the jumper closest to the SCSI connector. I had to leave them both closed (which is to be expected since I'm connected to the external bus as the only device), but the behaviour is a bit different for me: probe-scsi identifies drives on the correct IDs ("targets") as I've specified in my images, but they show up as all LUNs (0-7) as seen in this photo.
The format utility fails to identify (any of the) drive(s). I've so far tried this on a Sun IPX and SparcStation 10 (varying versions of OpenBoot), with format on SunOS 4.1.3 and Solaris 2.5.1 (iirc). The BlueSCSI FW revision I'm using is 1.1-20220404-USB, and the hardware revision is 1.1-a. I am powering the BlueSCSI via an external supply.
I have not yet tried enabling debugging - I only just assembled my BlueSCSI and tried it out.
I, too, am able to assist in further testing & fault-finding if needed; I'm comfortable with C (and arduino dev in general) as well as hardware debugging (I have a logic analyzer, scope, etc if needed), so let me know if there's anything I can do to help!

[teiram]

Hi @realfogman. Thanks for sharing your progress.
I will try to find some time to setup everything again and see if I run into the same issue (what I expect). But just to double check.
Found this though: https://docs.oracle.com/cd/E19455-01/806-1075/msgs-2013/index.html

I guess you have disabled all debug, right? I understand that can have a huge impact in performance.

Additionally, are you powering up the blueScsi using the SCSI bus lines or with an additional supply?

Best regards

[teiram]

Weird. I don't get more than 3.5V on PA10 on any jumper combination :)

[ajacocks]

Has anyone else made any progress, here? I’d really like to replace some of my SPARCstation HDDs with bluescsi units.

[jamesy0ung]

I've tried the BlueSCSI F1 in my Multia/UDB. It enumerates under the SRM console, and boots off the virtual Tru64 5.1B CD fine, but I repeatedly receive SCSI Parity Errors.

[mlasham]

I have just used a bluescsi v1 with a SparcStation 1+ . HDD works perfectly but cannot get the CDROM to work. CDROM does not boot, I get a wrong magic number. I think it is tied to the cd sector size - I tried naming the cd image CD60_512.iso but it still came through as 2048. Also tried a .ini file to set cdrom to 512 but that did not work either.