No update of IEEE 1394 driver for XP since 2001?

D

Doc

Under 1394 driver, device manager says 5.1.2535.0 7/1/2001. Selecting update driver says none found.

There was never an update for this?

Also, is it no longer possible to post to multiple groups in Google Groups?
 
H

Hot-Text

Doc said:
Under 1394 driver, device manager says 5.1.2535.0 7/1/2001. Selecting update driver says none >found.

Designer Apple Computer (now Apple, Inc.)
IEEE 1394 <<(FireWire) <<Devices

< http://en.wikipedia.org/wiki/IEEE_1394 >

There was never an update for this?


Also, is it no longer possible to post to multiple groups in Google Groups?

news.mixmin.net @ http//www.mixmin.net

Why who you need to Post,
too more then one Group for,
When all the Answer is here...
 
P

Paul

Doc said:
Under 1394 driver, device manager says 5.1.2535.0 7/1/2001. Selecting update driver says none found.

There was never an update for this?

Also, is it no longer possible to post to multiple groups in Google Groups?

I'm running WinXP Pro x32 SP3 and the date on my 1394bus.sys
file is April 14, 2008, 12:00:00 PM. This is presumably
as provided by the installer CD, and not installed via
an update or anything. The file itself could be identical
to an older one, and just the build date was stamped on it.

The number you're seeing, is from the INF file, and
doesn't get updated like it should.

For example, look at C:\Windows\INF\1394.INF

"; 1394.INF -- This file contains descriptions of all the 1394
; Host controllers supported in Windows NT and Memphis
;
;*** Created 07/09/97 (Creation Date)
"

That's the date they started working on the Firewire -- maybe.

Then, below that is this line. If the driver writer doesn't
care to update this, then things will look "pretty crusty".
This is a bit deceptive.

"DriverVer=07/01/2001,5.1.2535.0"

That is what is being used in Device Manager. But the date
on the files that do the actual work, at least on my machine,
are April 14, 2008, 12:00:00 PM. If you haven't installed
any Service Packs, the file could be older (but perhaps,
not changed in any way, for all I know).

Now, analyse the VEN\DEV part. There are two lines for VIA. The first
is a specific, older device. The second line is a generic, where
the BIOS passes a table and identifies the device with a Class Code
or "CC". It's intended to mark standards compliant devices. It would
mean that the lowest portion of the device register set, conforms
to the standard. If all the chips use the same register locations
and definitions, it means not having to re-issue the drivers every
week. Only if a new manufacturer were to appear on the scene and
start making chips, might a change be required.

PCI\VEN_1106&DEV_3044.DeviceDesc="VIA OHCI Compliant IEEE 1394 Host Controller"
PCI\VEN_1106&CC_0C0010.DeviceDesc="VIA OHCI Compliant IEEE 1394 Host Controller"

OK, so I look at my own machine with Everest, looks like mine
can use the specific device line (the first line, of the previous pair).

INF File 1394.inf
Hardware ID PCI\VEN_1106&DEV_3044&SUBSYS_81FE1043&REV_C0

Now, I check how many Firewire chips VIA made. There's only one
entry, for three different chips, all OHCI compliant.

http://pciids.sourceforge.net/pci.ids

1106 VIA Technologies, Inc.
...
3044 VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller

If I look at the Texas Instruments section, TI made a metric boatload
of Firewire chips.

104c Texas Instruments
...
8000 PCILynx/PCILynx2 IEEE 1394 Link Layer Controller
8009 TSB12LV22 IEEE-1394 Controller
8017 PCI4410 FireWire Controller
8019 TSB12LV23 IEEE-1394 Controller
8020 TSB12LV26 IEEE-1394 Controller (Link)
8021 TSB43AA22 IEEE-1394 Controller (PHY/Link Integrated)
8022 TSB43AB22 IEEE-1394a-2000 Controller (PHY/Link) [iOHCI-Lynx]
8023 TSB43AB22A IEEE-1394a-2000 Controller (PHY/Link) [iOHCI-Lynx]
8024 TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link)
8025 TSB82AA2 IEEE-1394b Link Layer Controller
8026 TSB43AB21 IEEE-1394a-2000 Controller (PHY/Link)
8027 PCI4451 IEEE-1394 Controller
8029 PCI4510 IEEE-1394 Controller
802b PCI7410,7510,7610 OHCI-Lynx Controller
802e PCI7x20 1394a-2000 OHCI Two-Port PHY/Link-Layer Controller
8032 OHCI Compliant IEEE 1394 Host Controller

Yet, there are only three entries in the Microsoft 1394.inf file. So
some of those must be handled by class codes. Not all of them
have OHCI in the title either. Those would be more interesting
to study, if you had one (as to what it says in Everest). TI
made some nice stuff, in that at one time, the MAC and PHY
were split, so you could do a properly isolated PHY. Why that's
important now, escapes me. Perhaps that had more to do with
supporting Firewire networking, than Firewire storage trees.

Paul
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top