lkml.org 
[lkml]   [2003]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: UDMA 133 on a 40 pin cable
On Thu, Jan 02, 2003 at 11:00:56PM +0100, Lionel Bouton wrote:
> Happy new year everybody
>
>
> Alan Cox wrote:
>
> >It got CRC errors, not suprisingly and will drop back. Nevertheless it
> >shouldnt have gotten this wrong, so more info would be good.
> >
> >
>
> I'm wondering some things about IDE 40/80 pin cables since some time ago :
> - somehow the circuitry can make the difference between 40 and 80 pin
> (probably some pins are shorted or not by the cables or some
> cable-type-dependent impedance between wires is mesured) and set a bit
> for us to use.

Yes. There are two types of this circuitry:

1) Just-a-capacitor-on-mainboard. When the pin in question (CBLID) is
connected to ground via a capacitor on the mainboard, the attached
devices can detect the cable and the IDE driver can ask them.

2) GPIO pin on mainboard. One of the chipset's GPIO pins gets wired to
CBLID and then the chipset can see what cable is installed.
Unfortunately, the wiring is mainboard (not chipset) dependent, and thus
only the BIOS can know.

Anyway, mixing various types of devices and mainboards there are always
cases where you get incorrect results. For some reason the ATA people
couldn't get this ever right.

The second method is safer, and mostly works for chipsets where there is
a 'cable detect scratch register', where the BIOS writes the 80/40 pin
cable information. Modern chipsets (Intel, AMD) implement this. VIA
doesn't. There is no way for a driver to read the cable type on a VIA
mainboard - it can ask the drives (but they can lie if they're mixed
with older devices, and if there is no cap on the mainboard), and it can
guess from the settings the BIOS used to program the UDMA speeds.

Currently it does the later, because it works in 99% of cases - the BIOS
will only set the chipset to UDMA66+ if it sees the cable on the right
GPIO pins.

> - most probably the same circuitry can't verify the length of the cables
> or their overall quality but I'm unsure.

It can not. Very modern drives and chipsets can adapt the termination
and various aspects of signalling, but cannot measure whether the cable
is suitable for a certain speed or not. The only way to really know is
to try to do a transfer. Or two. Or a thousand.

> #1 How is the 40/80 pin detection done at the hardware level ?

See above. Also see the ATA specs, it's there.

> #2 Are there any other cable-quality hardware tests done by the chipsets
> ? How ?

Not really.

> I've encountered a barebone design (Mocha P4, uses 2.5" drives) where
> the IDE cable was 40-pin but :
> - has a single drive connector instead of the common two,
> - its length is only around 10 or 15 cm.
> A buyer contacted me for SiS IDE driver directions on this platform and
> confirmed this at least for his purchase.
>
> #3 Is the above cable electrically able to sustain 66+ UDMA transfers
> (could I hack a driver in order to bypass the 80pin cable detection and
> make it work properly) ?

If you use ide0=ata66, the cable should be forced to 80pin. Also, it can
work if the cable is short and there is only one drive. Make sure it's
not bent too much, too.

> #4 Are the electrical specs for 66+ UDMA transfers public (couldn't find
> by googling) ? Where can we find them ?
> Here I mean some really basic specs (max Resistance/Capacity/Inductance
> between wires, max signal propagation delays and so on) and not general
> high level specs (material, connector design, length ranges allowed in
> the general 80-pin, 2 drives case).

Mostly. See the ATA spec.

> Any hints on these Andre ?

--
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:32    [W:0.067 / U:0.468 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site