From: Vojtech Pavlik <vojtech@suse.cz>
To: Lionel Bouton <Lionel.Bouton@inet6.fr>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Andre Hedrick <andre@linux-ide.org>,
Teodor Iacob <Teodor.Iacob@astral.kappa.ro>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: UDMA 133 on a 40 pin cable
Date: Fri, 3 Jan 2003 17:14:33 +0100 [thread overview]
Message-ID: <20030103171433.A4502@ucw.cz> (raw)
In-Reply-To: <3E14B698.8030107@inet6.fr>; from Lionel.Bouton@inet6.fr on Thu, Jan 02, 2003 at 11:00:56PM +0100
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
prev parent reply other threads:[~2003-01-03 16:06 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-02 18:29 UDMA 133 on a 40 pin cable Teodor Iacob
2003-01-02 19:37 ` Alan Cox
2003-01-02 18:59 ` Teodor Iacob
2003-01-02 19:21 ` Samuel Flory
2003-01-02 19:23 ` Teodor Iacob
2003-01-02 19:47 ` Samuel Flory
2003-01-02 20:37 ` Teodor Iacob
2003-01-03 2:26 ` Joshua Stewart
2003-01-02 22:00 ` Lionel Bouton
2003-01-02 22:40 ` Ross Biro
2003-01-02 22:42 ` Teodor Iacob
2003-01-03 1:04 ` Lionel Bouton
2003-01-03 1:57 ` Alan Cox
2003-01-03 10:20 ` IDE termination (was Re: UDMA 133 on a 40 pin cable) John Bradford
2003-01-03 10:29 ` Andre Hedrick
2003-01-02 23:24 ` UDMA 133 on a 40 pin cable Alan Cox
2003-01-02 22:45 ` Ross Biro
2003-01-03 1:15 ` Lionel Bouton
2003-01-03 16:14 ` Vojtech Pavlik [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030103171433.A4502@ucw.cz \
--to=vojtech@suse.cz \
--cc=Lionel.Bouton@inet6.fr \
--cc=Teodor.Iacob@astral.kappa.ro \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=andre@linux-ide.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox