25 Jun
2006
25 Jun
'06
6:01 p.m.
Out of interest, has anyone else ever managed to persuade linux to talk to any
of the Xebec/Omti/Emulex/Adaptec ST506-SCSI bridge boards? Most of the boards
are SASI, or at best semi-SCSI, so Linux refuses to talk to them.
Just wondered if anyone on here had hacked any of the kernel drivers so that
they'll work. As I understand it, the main problem's that the kernel drivers
issue a SCSI identify command at boot time - which of course doesn't exist on
any of these boards, and from that point on the kernel refuses to acknowledge
that there's even a board there.
I *think* a SASI board should work with a SCSI HBA, providing there's nothing
else on the SCSI bus (at least that's what the Omti manuals suggest).
Sure would be useful for backup purpose, but last time I looked at the kernel
SCSI code (for an adaptec driver in that case) it was pure spaghetti :-(
cheers
Jules
25 Jun
25 Jun
5:15 p.m.
On 6/26/2006 at 1:01 AM Jules Richardson wrote:
Out of interest, has anyone else ever managed to
persuade linux to talk
to any
of the Xebec/Omti/Emulex/Adaptec ST506-SCSI bridge boards? Most of the
boards
are SASI, or at best semi-SCSI, so Linux refuses to talk to them.
Well, the firmware on the OMTI boards is in EPROM and the CPU's a Z8--it
shouldn't be too difficult to add an IDENTIFY command to it. I seem to
recall that the OMTI puts the geometry information into the transfer buffer
at bootup--but I'll have to check my docs.
Cheers,
Chuck
26 Jun
26 Jun
5:28 a.m.
Chuck Guzis wrote:
On 6/26/2006 at 1:01 AM Jules Richardson wrote:
By that same measure, the same's true of the Adaptec and Emulex boards too -
but I'm not aware of useful details (such as source listings) for the ROM
contents existing anywhere. [1]
[1] customer EPROMs did exist for these boards, so the necessary info possibly
existed (at a price) - unless the custom ROMs were done by the vendor to the
customer's spec, rather than by the customer themselves.
The Xebec board seems to have a pair of 40-pin ICs and a 24-pin IC all with
Xebec part numbers; presumably one of those holds the firmware.
Assuming Identify could be added (or worked around in the kernel), that still
leaves the following two problems:
1) Whether a SCSI HBA talking to a SASI target will work. Sure, they're
electrically compatible, but I don't know if the SCSI spec includes a feature
where the HBA must detect that the target's SASI (and so missing the extra
control line pair) and automagically cope.
2) How to set up the board in software; I expect the kernel will get upset
if it can't query drive geometry at boot time - but it's going to do that as
part of driver set up, before any vendor-specific commands can be sent to the
board in order to set *it* up.
A simple SCSI adapter hanging off a PC parallel port and driven purely in
user-space would be in theory a lot easier - problem is that the PC port
doesn't quite have enough data lines. Building an ISA or PCI board is $$$, and
doing anything else (such as a USB interface) is unfortunately beyond me :-(
cheers
Jules
Out of interest, has anyone else ever managed to
persuade linux to talk
to any
of the Xebec/Omti/Emulex/Adaptec ST506-SCSI bridge boards? Most of the
boards
are SASI, or at best semi-SCSI, so Linux refuses to talk to them.
Well, the firmware on the OMTI boards is in EPROM and the CPU's a Z8--it
shouldn't be too difficult to add an IDENTIFY command to it.
8:30 a.m.
On 6/26/2006 at 12:28 PM Jules Richardson wrote:
[1] customer EPROMs did exist for these boards, so the
necessary info
possibly existed (at a price) - unless the custom ROMs were done by the
vendor to
the customer's spec, rather than by the customer
themselves.
As a matter of fact, my two OMTI boards are identified as having "Macintosh
SCSI" ROMs, ostensibly identifying them as something different from other
types of SCSI (?).
But why anyone would want to set up something with an ST-412 interface on
the far end at this late date is beyond me.
Cheers,
Chuck
3:20 p.m.
But why anyone would want to set up something with an
ST-412 interface on
the far end at this late date is beyond me.
The obvious reason is that you have a classic computer that uses one of
these boards with an ST412-interfaced hard disk hung off it [1] and you
want to make an image of that disk on an more modern system.
[1] Many machines in the UK did this. Just looking around me, there's the
Acorn Cambridge Workstation, the PERQ 3a (AGW3300), the Torch XXX and
Torch QaudX. And that's the ones I can see without leaving my chair
-tony
5:21 p.m.
Tony Duell wrote:
In my case it's the RML fileserver that's the real priority as no OS or setup
media's known for that one - things like the ACW, Torch XXX machines etc. I do
at least have media for - but I'd still like to archive the drives in "as
found" condition as they're ex-employee systems and so may have something
interesting on there that I've overlooked.
But why anyone
would want to set up something with an ST-412 interface on
the far end at this late date is beyond me.
The obvious reason is that you have a classic computer that uses one of
these boards with an ST412-interfaced hard disk hung off it [1] and you
want to make an image of that disk on an more modern system.
[1] Many machines in the UK did this. Just looking around me, there's the
Acorn Cambridge Workstation, the PERQ 3a (AGW3300), the Torch XXX and Torch QaudX.
Mine use SCSI drives luckily (although I gather it's more common for them to
have ST506 drives and abridge board). I've only ever seen bridge boards on the
XXX, though.
It's a shame someone with the necessary electronics smarts can't whip up a
ST506/412 ==> something (USB, parallel, PCI card, Ethernet, whatever) gadget
that can access a drive at the raw signal level, then do the decoding in
software to 'emulate' a particular ST506/412 disk controller. It's been talked
about enough darn times on here :-) There are commercial devices to do it,
but they're serious $$$...
I bet there are a few people on here who could handle the hardware, and a few
again that have the right software skills. I'm surprised there isn't more
desire to get on and do it to be honest, given that a lot of us are clued-up
about the importance of archiving other forms of media.
cheers
Jules
5:09 p.m.
Torch QaudX.
Mine use SCSI drives luckily (although I gather it's more common for them to have ST506 drives and abridge board). I've only
ever seen bridge boards on the
XXX, though.
Actually, I think QaudX machines did generally have SCSI hard drives and
a Manta board for the floppy (for the rst of the people here, Torch
boards were named after water creatures, the mainboard in a XXX is a
Stickleback, the memory expansion board for that is a Limpet, and so on).
XXXes had either the Omti board (which linked to a floppy drive and an
ST412 hard disk [1]) or the SCSI hard disk and a Manta.
[1] The original Torch hard drives were NEC units, and they are
well-known for developping stiction...
-tony
7:13 p.m.
Tony Duell wrote:
No QuadX configuration can be considered 'common', surely?
true. Although I believe only the later ones generally got SCSI drives -
earlier ones had bridge boards fitted and lower-capacity ST506 drives.
Torch QaudX.
Mine use SCSI drives luckily
(although I gather it's more common for them to a Manta board for the floppy (for the rst of the
people here, Torch
boards were named after water creatures, the mainboard in a XXX is a
Stickleback, the memory expansion board for that is a Limpet, and so on).
The never-happened QuadX memory board was to be called Mussel, by the way.
XXXes had either the Omti board (which linked to a
floppy drive and an
ST412 hard disk [1]) or the SCSI hard disk and a Manta.
I *think* they'll work with anything. There's a flag in the first sector on
the drive that says which bridge board is being used (or cleared if the unit's
pure SCSI). I suppose at boot time the firmware pulls the first block off the
disk, sets the drive geometry on the bridge board accordingly, and from then
on they all work the same way.
In practice, I think they all got Omti boards as you say. There were a handful
of Emulex, Adaptec and Xebec bridges amongst all my ex-workshop stock though,
so they obviously played around with them at least.
[1] The original Torch hard drives were NEC units, and
they are
well-known for developping stiction...
Yep. I had a couple with that problem this last week when I was digging around
my Torch stuff. Luckily the spindles are exposed on the underside; they're not
completely sealed units and so can be given a helping hand.
cheers
Jules
3:02 p.m.
On 6/26/2006 at 1:01 AM Jules Richardson wrote:
For the OMTI 5000 series boards, there were actually data sheets for the
3 custom chips (IIRC they were a buffer memory controller, the actual
data encoder/decoder and a VFO/PLL/data separator thein). Those data
sheets did (IIRC) document the various registers in the chips. So it
should be possible to completely understand the firmware.
-tony
Out of interest, has anyone else ever managed to
persuade linux to talk
to any
of the Xebec/Omti/Emulex/Adaptec ST506-SCSI bridge boards? Most of the
boards
are SASI, or at best semi-SCSI, so Linux refuses to talk to them.
Well, the firmware on the OMTI boards is in EPROM and the CPU's a Z8--it
shouldn't be too difficult to add an IDENTIFY command to it. I seem to
6753
days inactive
6754
days old
8 comments
3 participants
participants (3)
-
ard＠p850ug1.demon.co.uk -
cclist＠sydex.com -
julesrichardsonuk＠yahoo.co.uk