I've been trying to figure out the relationship of SDIO to ATA. The reason
is to find more ATA compatible hardware for DEC Alpha machines. Lots of
them had ATA interfaces for CDROMs or system drives. However, most appear
to support IDE rather than EIDE. I'm basing that off the lack of a keyed
connector with a missing pin.
Many SD2IDE devices adapt SD cards to an IDE bus. However, I've noticed
that the systems with ACER M1543C controllers like the ones in the
Alphastation DS10 will throw CAM errors and generally act-out, slow down,
and misbehave (under Tru64, Linux, or BSD - I figure it's a hardware
thing). However, systems with the CMD PCI0646 controller like the
Alphastation 600a have no trouble whatsoever with SD2IDE devices.
So, can anyone speculate on what is going on? Here's my cockamamie theory.
I think SDIO is only a subset of the ATA standard and that those little
$10 gizmos are basically only changing the electrical interface. They
aren't like a SCSI2SD that actually has to "translate" the SDIO into SCSI
CDBs. My guess is that the ACER controller is asking the SD card ATA
questions it doesn't know the answer to, so to speak.
Does anyone who has worked with SDIO know what the relationship to SDIO
and ATA is? Is it the same for CF cards? I ask because CF2IDE devices work
even worse - they show up (wrong) as WORM or CDROM drives on my Alpha's.
I've skimmed over this document:
https://www.sdcard.org/developers/overview/sdio/sdio_spec/Simplified_SDIO_Card_Spec.pdf
However, it's difficult to get a "summary" or intuit why some SD2IDE &
CF2IDE devices work or don't work. My fundamental question is this:
Is SDIO a superset of ATA or is ATA a superset of SDIO? Something else?
I'm also scratching my head wondering if CAM handles SDIO directly or
deals with it via ATA (ie.. in kernel land) ?
-Swift
