Stefan Richter <[email protected]> writes:
> AFAIK all 6306 are OHCI 1.0. I presume that currently produced 6307 are
> OHCI 1.1 and maybe only first revisions of it were 1.0 --- but that's
> just my speculation. I would be surprised though if it was merely a
> matter of EEPROM contents.
Both VT6306 and VT6307 datasheets claim selectable OHCI 1.0/1.1.
I guess they did that for compatibility or something like that.
The 6307 chip allows for either I^2C (24c01 etc) or 93c64 EEPROM (there
is a pin to select), while 6306 works with 93c64 only (4-wire: chip
select, clock, data-in, data-out).
I examined 3 machines with VT6307 using a simple home-made signal
analyzer:
a) using 93C46 EEPROM and OHCI 1.0
b) using 24C01A EEPROM and OHCI 1.0
c) using 24C01A EEPROM and OHCI 1.1
All 3 chips have PCI vendorID 1106 and deviceID 3044, revision is 0x80.
The VT6307 chip reads the EEPROM (after reset) in the following order:
ADDR ADDR a) b) c)
4-wire I^2C
A 14 subsystem vendor ID
B 16 subsystem device ID
10 20 103C 103C 103C values same on all machines
C 18 DF03 DF03 DF03
D 1A 8040 8040 8040
E 1C 2000 2000 2000
F 1E 7300 7300 7300
11 22 0000 0000 0008
12 24 0000 0000 0000
0 0 4000 0000 1000 config_rom: offset 0E
1 2 0063 DC10 00DC (GUID) 0C
2 4 0100 FD00 0101 12
3 6 D0D4 8F75 F2D4 10
4 8 0404 0404 0404 values same on all machines
5 A 5532 5532 5532
6 C 00F8 00F8 00F8
7 E 02A2 02A2 02A2
8 10 00A1 00A1 00A1
9 12 6340 6340 6340
The only difference (not counting GUID) is at address 0x11 (0x22
for I2C).
I haven't yet checked if it changes OHCI version - I of course
could program the EEPROM externally but I think I'd better find
how to do that from PCI side.
--
Krzysztof Halasa
Krzysztof Halasa <[email protected]> writes:
[VIA VT6306/6307]
> I haven't yet checked if it changes OHCI version - I of course
> could program the EEPROM externally but I think I'd better find
> how to do that from PCI side.
Added Cc:lkml, perhaps someone at VIA could find that strictly
confidential and destroy-before-reading document and spare me
the effort? :-)
All I need to know is:
a) meaning of the config EEPROM data for VIA firewire chips
b) how to read/write the EEPROM from PCI side (i.e., probably
EECS, EEDO, EEDI/SDA and EECK/SCL bit locations or however
it's done).
--
Krzysztof Halasa
Krzysztof Halasa wrote:
> Both VT6306 and VT6307 datasheets claim selectable OHCI 1.0/1.1.
> I guess they did that for compatibility or something like that.
I wouldn't read too much into these data sheets. Note that actual OHCI
1.1 features are nowhere documented in these data sheets; i.e. this
documentation can't be trusted to begin with.
As far as VT6306 is concerned, the wording could be copy'n'waste from
the VT6307 datasheet. And in case of VT6307, I suspect it's VIA who
selects the implementation level (based on chip revision), not the card
vendor.
--
Stefan Richter
-=====-=-=== =-=- =----
http://arcgraph.de/sr/
Stefan Richter <[email protected]> writes:
> And in case of VT6307, I suspect it's VIA who
> selects the implementation level (based on chip revision), not the card
> vendor.
Can't be, the customers (real ones - board makers) would kill them
at once and then buy a different brand. That's not selling a different
wifi card under the old name.
Anyway, I just connected a programmer to the EEPROM (machine "a" in my
previous mail = EPIA-M 600 MHz), wrote "8" to the 16-bit word at address
0x11 (93c46 EEPROM), and now this VT6307S dated 0239CD (2002, 39th week)
says:
ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[12] MMIO=[de000000-de0007ff]
Max Packet=[2048] IR/IT contexts=[4/8]
Unfortunately it's not much good for general consumption, and I haven't
yet found a way to write to the EEPROM using VT6307 registers (one can
easily read it using documented GUID register).
Nobody with a good VIA contact?
I'm not asking for something extraordinary, am I?
--
Krzysztof Halasa
Krzysztof Halasa wrote:
> Stefan Richter <[email protected]> writes:
>
>> And in case of VT6307, I suspect it's VIA who
>> selects the implementation level (based on chip revision), not the card
>> vendor.
>
> Can't be, the customers (real ones - board makers) would kill them
> at once and then buy a different brand. That's not selling a different
What I meant was: First revisions may have had incomplete OHCI 1.1
support and were sold as OHCI 1.0 chips, and as soon as they stabilized
it they sold them as OHCI 1.1 chips. But that's mere speculation on my
part. I can't think of any other reason though why anybody would hide
OHCI 1.1 compatibility.
> Anyway, I just connected a programmer to the EEPROM (machine "a" in my
> previous mail = EPIA-M 600 MHz), wrote "8" to the 16-bit word at address
> 0x11 (93c46 EEPROM), and now this VT6307S dated 0239CD (2002, 39th week)
> says:
> ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[12] MMIO=[de000000-de0007ff]
> Max Packet=[2048] IR/IT contexts=[4/8]
And are you going to test if and how stable OHCI 1.1 features work?
(Which features are these? Right now only dual buffer reception comes
to my mind.)
--
Stefan Richter
-=====-=-=== =-=- =---=
http://arcgraph.de/sr/
Stefan Richter <[email protected]> writes:
> What I meant was: First revisions may have had incomplete OHCI 1.1
> support and were sold as OHCI 1.0 chips, and as soon as they stabilized
> it they sold them as OHCI 1.1 chips. But that's mere speculation on my
> part. I can't think of any other reason though why anybody would hide
> OHCI 1.1 compatibility.
Perhaps some MS Windows had troubles with 1.1?
VIA has a history of similar things (e.g. some C3 CPUs).
All 3 chips I have, including that dated 2002, are single
revision "80" so I guess there are absolutely no silicon changes.
> And are you going to test if and how stable OHCI 1.1 features work?
> (Which features are these? Right now only dual buffer reception comes
> to my mind.)
On this old EPIA? No :-)
At least unless I have any doubt.
On the other machine (currently) 1.0? Sure, that's why I did it.
Is the "dual buffer reception" involved in receiving video from
a DV camera, using the new driver?
--
Krzysztof Halasa
Krzysztof Halasa wrote:
> Is the "dual buffer reception" involved in receiving video from
> a DV camera, using the new driver?
Yes, isochronous reception (and thus DV) with the new drivers currently
requires dual buffer mode.
--
Stefan Richter
-=====-=-=== =-=- =---=
http://arcgraph.de/sr/
Stefan Richter <[email protected]> writes:
> And are you going to test if and how stable OHCI 1.1 features work?
I've "upgraded" the other machine ("b"), it uses the same VT6307
(not sure the packaging letter but I've already closed the case)
and is made in 2006 (week 22 or 20).
firewire_ohci: Added fw-ohci device 0000:02:03.0, OHCI version 1.10
firewire_core: created new fw device fw0 (0 config rom retries)
firewire_core: created new fw device fw1 (0 config rom retries)
firewire_core: phy config: card 0, new root=ffc1, gap_count=5
Just watching live DV stream across Ethernet from this machine.
OTOH, it's no magic - they claim OHCI 1.1 and they do it. We don't
only know how to enable it with (only) software. I suspect all those
VT6306 could be "upgraded" as well.
--
Krzysztof Halasa
> OTOH, it's no magic - they claim OHCI 1.1 and they do it. We don't
> only know how to enable it with (only) software. I suspect all those
> VT6306 could be "upgraded" as well.
BTW: I've looked at it a bit closer and it seems the EEPROM lines
are controlled by VT6307 I/O ports (region #1) 0x0 and 0x20:
01:04.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host
Controller (rev 80) (prog-if 10 [OHCI])
Memory at feafe800 (32-bit, non-prefetchable) [size=2K]
I/O ports at d480 [size=128]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
port 0x20 R/O bit 8 is set in 93c46 mode and reset in I^2C mode
port 0x20 bit 4 must be set to drive CS, CLK and DATA-OUT outputs
port 0x20 bits 3, 2 and 1 are, respectively, CS, CLK and DATA-OUT
pins in 93c46 mode and unused, SCL and SDA pins in I^2C mode
port 0x20 R/O bit 0 is DATA-IN input in 93c46 mode
port 0x0 bit 8 must be set to enable access
port 0x20 must be written 0x20 (bit 5 only) to disable access
(clears port 0x0 bit 8).
They are all 32-bit I/O ports.
The above allows for complete control in 93c46 mode (I'll make the
program available later) and unfortunately I don't yet know how to
read SDA (and SCL) state in I^2C mode (I can blindly write to the
EEPROM and I can read the EEPROM data using GUID PROM register so
there is a workaround).
--
Krzysztof Halasa
Krzysztof Halasa wrote:
> OTOH, it's no magic - they claim OHCI 1.1 and they do it. We don't
> only know how to enable it with (only) software. I suspect all those
> VT6306 could be "upgraded" as well.
What if we add a whitelisting in the driver which ignores the register
contents which state OHCI 1.0 implementation level, and just treats
these VIA chips as OHCI 1.1 implementations?
--
Stefan Richter
-=====-=-=== =-=- =-=--
http://arcgraph.de/sr/
Stefan Richter <[email protected]> writes:
> What if we add a whitelisting in the driver which ignores the register
> contents which state OHCI 1.0 implementation level, and just treats
> these VIA chips as OHCI 1.1 implementations?
It would be interesting but I'm not sure it would work. I guess
if these chips are in OHCI 1.0 mode the 1.1 functionality may be
unavailable (the datasheet seems to suggest that).
OTOH I think it's better to change the EEPROM contents anyway,
it's a simple program (which I'm going to write when I'm a bit
less loaded).
I wonder if OHCI 1.0 hardware based on VT6307 (and 6306) is
a common thing, or is it just an exception.
--
Krzysztof Halasa
Krzysztof Halasa wrote:
> (the datasheet seems to suggest that)
Well, as mentioned, I don't put much trust into the datasheet. It is
incomplete regarding the 1.0/1.1 issue.
> I wonder if OHCI 1.0 hardware based on VT6307 (and 6306) is
> a common thing, or is it just an exception.
Both chips are quite widespread. From what I remember to have seen,
most VT6307 are programmed in OHCI 1.1 mode while all VT6306 seem to be
OHCI 1.0.
--
Stefan Richter
-=====-=-=== =-=- =-=--
http://arcgraph.de/sr/
Ok. I just put a program on something like
http://www.kernel.org/~chris/vt6307ohciver.c
Anybody with OHCI-1.0 VT6307* Firewire chip may want to try. Obviously
it's based on undocumented features, it may blow your machine etc.
Please remove your ohci1394 or firewire-ohci driver before using this
program.
Compile with the usual spell: gcc -Wall -O2 vt6307ohciver.c -o vt6307ohciver
Examine (and backup) the EEPROM data first:
# /sbin/lspci | grep 1394
01:04.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host
Controller (rev 80)
# ./vt6307ohciver 01:04.0
[some debug info]
It seems your VT6307 chip is connected to I^2C (24c01 or similar) EEPROM
EEPROM dump:
00: 00 10 DC 00 01 01 D4 F2 04 04 32 55 F8 00 A2 02
10: A1 00 40 63 62 14 0D 25 03 DF 40 80 00 20 00 73
20: 3C 10 00 00 00 00 FF FF FF FF FF FF FF FF FF FF
^^
Your VT6307 chip is in OHCI 1.0 mode
(If you have only one VIA firewire chip you can use "" as the argument.)
I'd check if there is a small SMD 8-pin 24c01 or similar EEPROM
near VT6307 if I were you. Alternatively the program may say you
have 93c46, also a small 8-pin chip.
Now you can try upgrading to OHCI-1.1:
# ./vt6307ohciver "" 1.1
It seems your VT6307 chip is connected to I^2C (24c01 or similar) EEPROM
writing 0x08 at address 0x22
Please reboot
People with 93c46 will see 0x11 address.
Do as commanded, reboot (PCI reset) is required for the VT6307 to reload
the configuration from its EEPROM.
Please let me know if it doesn't work.
This program may possibly run on VT6306-based board/card as well,
though I don't know what would happen (I suspect it could work,
but may need some modifications).
The "dump" function should work with any OHCI firewire device,
though for non-VIA chips you would have to change PCI device/vendor
ID in the source.
If you have a VT6306-based card and you run this program, I'd
appreciate it if you let me know the EEPROM contents (make sure
you mention chip type) and, if you tried "upgrading" or
"downgrading", if it worked. In theory VT6306 should be able to
run in OHCI-1.1 mode, but I don't really know.
VT6306 only supports 93c46 EEPROM so if the program says 24c01
you may want to force it (edit the source) and let me know.
VT6305 users may not bother, this chip doesn't support OHCI-1.1.
Not sure if anything like it ever existed, though.
--
Krzysztof Halasa
Krzysztof Halasa wrote:
> Ok. I just put a program on something like
> http://www.kernel.org/~chris/vt6307ohciver.c
>
> Anybody with OHCI-1.0 VT6307* Firewire chip may want to try. Obviously
> it's based on undocumented features, it may blow your machine etc.
>
> Please remove your ohci1394 or firewire-ohci driver before using this
> program.
>
> Compile with the usual spell: gcc -Wall -O2 vt6307ohciver.c -o vt6307ohciver
I also had to specify "-lpci" on Mandrake 10.1, "-lpci -lz" on Gentoo.
...
> If you have a VT6306-based card and you run this program, I'd
> appreciate it if you let me know the EEPROM contents (make sure
> you mention chip type)
# lspci|grep 1394
00:0a.3 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394
Host Controller (rev 46)
00:0c.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394
Host Controller (rev 46)
These are both VT6306, one on the motherboard and one on a PCI card.
# ./a.out 00:0a.3
I/O region #1 is at C800
It seems your VT6307 chip is connected to 93c46 EEPROM
Page size is 4096 (0x1000) bytes
GUID PROM register address is 0xec101004
Mapping 8 (0x8) bytes of memory at 0xec101000
Mapped mem region #0 at virtual address 0xb7f3a000
GUID PROM register is at virtual address 0xb7f3a004
EEPROM dump:
00: 00 11 06 00 00 00 E3 32 00 88 00 08 44 00 00 00
10: A1 E4 2F 00 06 11 44 30 03 DF 40 00 00 20 00 73
20: 3C 10 00 00 00 00 FF FF FF FF FF FF D7 57 55 75
Your VT6307 chip is in OHCI 1.0 mode
# ./a.out 00:0c.0
I/O region #1 is at D000
It seems your VT6307 chip is connected to 93c46 EEPROM
Page size is 4096 (0x1000) bytes
GUID PROM register address is 0xec103004
Mapping 8 (0x8) bytes of memory at 0xec103000
Mapped mem region #0 at virtual address 0xb7f1a000
GUID PROM register is at virtual address 0xb7f1a004
EEPROM dump:
00: 00 30 1B AC 00 00 2B A4 04 04 32 55 F8 00 A2 02
10: A1 00 40 63 06 11 44 30 03 DF 40 00 00 20 00 73
20: 3C 10 00 00 00 00 FF FF FF FF FF FF FF FF FF FF
Your VT6307 chip is in OHCI 1.0 mode
On another PC:
# lspci | grep 1394
02:02.0 FireWire (IEEE 1394): Texas Instruments TSB82AA2
IEEE-1394b Link Layer Controller (rev 01)
05:04.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394
Host Controller (rev 80)
06:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394
Host Controller (rev 46)
The "rev 80" chip is a VT6307 on the motherboard.
# ./a.out 05:04.0
I/O region #1 is at ED00
It seems your VT6307 chip is connected to I^2C (24c01 or
similar) EEPROM
Page size is 4096 (0x1000) bytes
GUID PROM register address is 0xfbffd004
Mapping 8 (0x8) bytes of memory at 0xfbffd000
Mapped mem region #0 at virtual address 0xb7f76000
GUID PROM register is at virtual address 0xb7f76004
EEPROM dump:
00: 00 10 DC 56 00 FE D2 D4 04 04 32 55 F8 00 A2 02
10: A1 00 40 63 20 63 62 14 03 DF 40 80 00 20 00 73
20: 3C 10 08 00 00 00 FF FF FF FF FF FF FF FF FF FF
Your VT6307 chip is in OHCI 1.1 mode
The "rev 46" chip is on a CardBus card. So far I believed it to be a
VT6306 but I can't easily open the card's casing...
# ./a.out 06:00.0
I/O region #1 is at E000
It seems your VT6307 chip is connected to I^2C (24c01 or
similar) EEPROM
Page size is 4096 (0x1000) bytes
GUID PROM register address is 0x80000004
Mapping 8 (0x8) bytes of memory at 0x80000000
Mapped mem region #0 at virtual address 0xb7f2f000
GUID PROM register is at virtual address 0xb7f2f004
EEPROM dump:
00: 00 11 06 00 00 00 41 CC 04 04 32 55 F8 00 92 02
10: A1 00 40 63 06 11 44 30 03 DF 40 80 00 20 00 73
20: 3C 10 00 00 00 00 A0 00 FF FF FF FF FF FF FF FF
Your VT6307 chip is in OHCI 1.0 mode
> and, if you tried "upgrading" or "downgrading", if it worked.
I haven't tried it yet.
--
Stefan Richter
-=====-=-=== =-=- ===--
http://arcgraph.de/sr/
Stefan Richter <[email protected]> writes:
>> Compile with the usual spell: gcc -Wall -O2 vt6307ohciver.c -o vt6307ohciver
>
> I also had to specify "-lpci" on Mandrake 10.1, "-lpci -lz" on Gentoo.
Of course you're right, just typed faster than thought.
Actually I had to add these two on Fedora, too.
> 00:0c.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394
> Host Controller (rev 46)
Ok so it seems rev 80 is VT6307 and (at least) rev 46 is VT6306.
I think my googling for lspci reports confirms that.
> These are both VT6306, one on the motherboard and one on a PCI card.
>
> # ./a.out 00:0a.3
> I/O region #1 is at C800
> It seems your VT6307 chip is connected to 93c46 EEPROM
Interesting, really. Perhaps they aimed at I2C too with 9306 but
screwed up the silicon? Would have to look at the pinout but for
now I'm sick and high fever makes it hard.
It's all consistent, amazingly.
6306#1
> 00: 00 11 06 00 00 00 E3 32 00 88 00 08 44 00 00 00
> 10: A1 E4 2F 00 06 11 44 30 03 DF 40 00 00 20 00 73
> 20: 3C 10 00 00 00 00 FF FF FF FF FF FF D7 57 55 75
Obviously some values are different than these for my 3 vt6307
(not counting GUID + PCI sub IDs). Though data at 0x20+ is equal.
The last 4 bytes are almost certainly rubbish, that asks the question
if the contents hasn't been changed through some tests, works on
the drivers etc, or if the manufacturer did it right (for example
I somehow managed to clear the GUID on I^2C version before I had the
code to write to it, quite a mystery (writing correct I^2C sequence
for it isn't trivial due to the need of non-all-zeros DEVSEL byte
preceded by the start sequence).
I wonder if the EEPROM has more non-FF data? IIRC the chips addresses
0x80 bytes, or maybe 0x100? I limited it to 0x40 in the code because
the rest is never read by the chip, except if requested by the user.
(For 93c46 the program could read any location directly but I didn't
implement that).
6306#2
> EEPROM dump:
> 00: 00 30 1B AC 00 00 2B A4 04 04 32 55 F8 00 A2 02
> 10: A1 00 40 63 06 11 44 30 03 DF 40 00 00 20 00 73
> 20: 3C 10 00 00 00 00 FF FF FF FF FF FF FF FF FF FF
Only one different byte (vs my 6307s) at 0x1B if I see correctly.
> The "rev 80" chip is a VT6307 on the motherboard.
> 00: 00 10 DC 56 00 FE D2 D4 04 04 32 55 F8 00 A2 02
> 10: A1 00 40 63 20 63 62 14 03 DF 40 80 00 20 00 73
> 20: 3C 10 08 00 00 00 FF FF FF FF FF FF FF FF FF FF
Same as mine.
> The "rev 46" chip is on a CardBus card. So far I believed it to be a
> VT6306 but I can't easily open the card's casing...
> It seems your VT6307 chip is connected to I^2C (24c01 or
> similar) EEPROM
Hmm... They say 6306 only supports 93c46, perhaps I should force
it based on revision.
Or the datasheet doesn't know.
> 00: 00 11 06 00 00 00 41 CC 04 04 32 55 F8 00 92 02
> 10: A1 00 40 63 06 11 44 30 03 DF 40 80 00 20 00 73
> 20: 3C 10 00 00 00 00 A0 00 FF FF FF FF FF FF FF FF
It seems a difference at 0x1e only, that A0 00 at the end - who
knows (would require an analyzer).
>> and, if you tried "upgrading" or "downgrading", if it worked.
>
> I haven't tried it yet.
I guess chances for the last card are lower.
--
Krzysztof Halasa
Krzysztof Halasa wrote:
> Stefan Richter <[email protected]> writes:
>> # ./a.out 00:0a.3
>> I/O region #1 is at C800
>> It seems your VT6307 chip is connected to 93c46 EEPROM
>
> Interesting, really. Perhaps they aimed at I2C too with 9306 but
> screwed up the silicon? Would have to look at the pinout but for
> now I'm sick and high fever makes it hard.
>
> It's all consistent, amazingly.
>
> 6306#1
>> 00: 00 11 06 00 00 00 E3 32 00 88 00 08 44 00 00 00
>> 10: A1 E4 2F 00 06 11 44 30 03 DF 40 00 00 20 00 73
>> 20: 3C 10 00 00 00 00 FF FF FF FF FF FF D7 57 55 75
>
> Obviously some values are different than these for my 3 vt6307
> (not counting GUID + PCI sub IDs). Though data at 0x20+ is equal.
>
> The last 4 bytes are almost certainly rubbish, that asks the question
> if the contents hasn't been changed through some tests, works on
> the drivers etc, or if the manufacturer did it right (for example
> I somehow managed to clear the GUID on I^2C version before I had the
> code to write to it, quite a mystery (writing correct I^2C sequence
> for it isn't trivial due to the need of non-all-zeros DEVSEL byte
> preceded by the start sequence).
>
> I wonder if the EEPROM has more non-FF data? IIRC the chips addresses
> 0x80 bytes, or maybe 0x100? I limited it to 0x40 in the code because
> the rest is never read by the chip, except if requested by the user.
> (For 93c46 the program could read any location directly but I didn't
> implement that).
This device is a somewhat buggy PCI card which somebody sent me after
unsuccessful attempts to get it properly working under Linux. Among
more serious trouble, ohci1394 reads a bogus maximum async payload (a
zero value) from the BusOptions register during startup. This has
occasionally been reported for some VT6306 in the past. I haven't
really tested this card myself yet, it's currently stuck in a PC which I
don't use anymore.
Bad VT6306 card:
PCI: Found IRQ 11 for device 0000:00:0a.3
PCI: Sharing IRQ 11 with 0000:00:0a.0
PCI: Sharing IRQ 11 with 0000:00:10.1
ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[11]
MMIO=[ec101000-ec1017ff] Max Packet=[2] IR/IT contexts=[4/8]
ohci1394: fw-host0: Serial EEPROM has suspicious values, attempting to
set max_packet_size to 512 bytes
ieee1394: Host added: ID:BUS[0-00:1023] GUID[001106000000e332]
VT6306 onboard controller:
PCI: setting IRQ 5 as level-triggered
PCI: Found IRQ 5 for device 0000:00:0c.0
PCI: Sharing IRQ 5 with 0000:00:0a.2
ohci1394: fw-host1: OHCI-1394 1.0 (PCI): IRQ=[5]
MMIO=[ec103000-ec1037ff] Max Packet=[2048] IR/IT contexts=[8/8]
ieee1394: Host added: ID:BUS[1-00:1023] GUID[00301bac00002ba4]
VT6306 CardBus card in my main PC:
ACPI: PCI Interrupt 0000:06:00.0[A] -> GSI 17 (level, low) -> IRQ 18
ohci1394: fw-host2: OHCI-1394 1.0 (PCI): IRQ=[18]
MMIO=[80000000-800007ff] Max Packet=[1024] IR/IT contexts=[4/8]
ieee1394: Host added: ID:BUS[2-00:1023] GUID[00110600000041cc]
The Max Packet value of the CardBus card is OK; all CardBus cards seem
to have this limitation regardless of their link layer chip.
I wonder what's up with the varying number of IR contexts. The
datasheet talks about 8 IR contexts and 8 IR context registers, but also
has a sentence "These registers are Context Control registers for
isochronous Receive Contexts 0-3" which may be an editorial error.
--
Stefan Richter
-=====-=-=== =-=- ===--
http://arcgraph.de/sr/
Stefan Richter <[email protected]> writes:
> This device is a somewhat buggy PCI card which somebody sent me after
> unsuccessful attempts to get it properly working under Linux. Among
> more serious trouble, ohci1394 reads a bogus maximum async payload (a
> zero value) from the BusOptions register during startup. This has
> occasionally been reported for some VT6306 in the past. I haven't
> really tested this card myself yet, it's currently stuck in a PC which I
> don't use anymore.
I see. I think you may be able to cure this problem with my program,
adding corrected values in addition to write to 0x11 should do the
trick. 93c46 is 16-bit, little-endian here. You'd have to divide the
addresses shown by the dump by 2 of course.
I'd make sure the values are ok before rebooting, there is some
possibility a badly corrupted EEPROM may prevent BIOS from starting.
I think I'd leave GUID (16-bit words at 0, 1, 2, 3) and PCI subsystem
IDs (words at 0xA and 0xB) unchanged, and for all other locations I'd
fill in the 6307 values.
Of course I don't know if the program will be able to write to VT6306,
so I'd test the broken card first.
> VT6306 CardBus card in my main PC:
> MMIO=[80000000-800007ff] Max Packet=[1024] IR/IT contexts=[4/8]
> ieee1394: Host added: ID:BUS[2-00:1023] GUID[00110600000041cc]
The difference is of course at 0x0E, not 0x1E. Maybe the byte at 0x0A
is 0x92 for 4 IR contents and 0xA2 for 8 contents. That would also
make sense wrt the broken 6306 as it has 0x00 there.
--
Krzysztof Halasa
Krzysztof Halasa wrote:
> The difference is of course at 0x0E, not 0x1E. Maybe the byte at 0x0A
> is 0x92 for 4 IR contents and 0xA2 for 8 contents. That would also
> make sense wrt the broken 6306 as it has 0x00 there.
Somebody pointed me to this thread in a support forum of Asustek:
http://vip.asus.com/forum/view.aspx?id=20070710054607250&board_id=1&model=M2A-VM+HDMI
For special occasions, Asustek hand out a testing and reprogramming
utility from VIA to their customers (viafire.exe, together with EEPROM
image files and instructions; see the link to the RAR archive at this
page). The documentation of the tool also contains a partial
description of the EEPROM contents.
--
Stefan Richter
-=====-=-=== =-== ---=-
http://arcgraph.de/sr/
Stefan Richter <[email protected]> writes:
> For special occasions, Asustek hand out a testing and reprogramming
> utility from VIA to their customers (viafire.exe, together with EEPROM
> image files and instructions; see the link to the RAR archive at this
> page). The documentation of the tool also contains a partial
> description of the EEPROM contents.
I see. I guess there is no much mystery in the EEPROM, i.e.
we know where to place GUID and PCI subsystem IDs and we know
how to initialize the rest (for both VT6306 and 6307, as it's
almost certainly the same). And we know how to handle VT6307
EEPROM programming.
I have no 6306 personally and I haven't connected a logic analyzer
to any so programming 6306 EEPROM is a speculation.
I will look at their archive "really soon" of course.
--
Krzysztof Halasa
Hi,
On Sun, Oct 28, 2007 at 09:40:41PM +0100, Krzysztof Halasa wrote:
> Stefan Richter <[email protected]> writes:
>
> >> Compile with the usual spell: gcc -Wall -O2 vt6307ohciver.c -o vt6307ohciver
> >
> > I also had to specify "-lpci" on Mandrake 10.1, "-lpci -lz" on Gentoo.
>
> Of course you're right, just typed faster than thought.
> Actually I had to add these two on Fedora, too.
And in general the pciutils-dev package should be installed.
> Ok so it seems rev 80 is VT6307 and (at least) rev 46 is VT6306.
> I think my googling for lspci reports confirms that.
As does my card:
# lspci |grep 1394
00:09.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host
Controller (rev 46)
root@andi:/tmp# ./vt6307ohciver 00:09.0
I/O region #1 is at A000
It seems your VT6307 chip is connected to 93c46 EEPROM
Page size is 4096 (0x1000) bytes
GUID PROM register address is 0xdb140004
Mapping 8 (0x8) bytes of memory at 0xdb140000
Mapped mem region #0 at virtual address 0xb7ee5000
GUID PROM register is at virtual address 0xb7ee5004
EEPROM dump:
00: 00 11 06 66 45 55 56 E1 04 04 32 55 F8 00 A2 02
10: A1 00 40 63 06 11 44 30 03 DF 40 80 00 20 00 73
20: 3C 10 00 00 00 00 FF FF FF FF FF FF FF FF FF FF
Your VT6307 chip is in OHCI 1.0 mode
And viewing from a quite problematic angle (card is in running PC,
difficult to view) strongly seems to indicate a VT630_6_ (the "6" is
quite clearly visible).
This means that I currently cannot offer any mfct. date data however,
unfortunately.
Andreas Mohr
Andreas Mohr <[email protected]> writes:
> EEPROM dump (VT6306)
> 00: 00 11 06 66 45 55 56 E1 04 04 32 55 F8 00 A2 02
--------- GUID --------
> 10: A1 00 40 63 06 11 44 30 03 DF 40 80 00 20 00 73
- subs ID -
> 20: 3C 10 00 00 00 00 FF FF FF FF FF FF FF FF FF FF
>
> Your VT6307 chip is in OHCI 1.0 mode
Thanks for the data. It's the same as for all my VT6307, excluding
GUID (different for every card) and PCI subsystem vendor/device IDs.
I guess Stefan could now try to write these values (except GUID
and probably PCI subsystem IDs, and with OHCI 1.1 bit) to the "bad"
card :-) I wouldn't try with a good card yet, though (unless you
know how to repair it and/or you want to risk it, and/or you
want to use the DOS utility mentioned by Stefan).
I would try myself but I have no VT6306.
BTW I don't know where I found the info about VT6306 not working
with I^2C EEPROMs but it seems to be false, the datasheets claim
both chips can get startup info from 4-wire or I^2C EEPROM. Given
that both chips have identical EEPROM interface (except "fast I^2C
mode" which means nothing) I'd be surprised if the program can't
set OHCI 1.1 on VT6306.
> And viewing from a quite problematic angle (card is in running PC,
> difficult to view) strongly seems to indicate a VT630_6_ (the "6" is
> quite clearly visible).
> This means that I currently cannot offer any mfct. date data however,
> unfortunately.
Yeah. I think (feel or something) VIA does the usual thing with
revision numbers so rev 0x46 means always the same silicon (VT6306)
and rev 0x80 is always the same VT6307. There might be other
revisions but I think we won't find non-VT6306 rev 0x46 or
non-VT6307 rev 0x80.
And, for someone using the old driver, VT6306 should probably have
8/8 IR/IT contexts while VT6307 - 4/8 (the new driver doesn't seem
to show this info and I think VT6306 can be limited to 4 as well).
--
Krzysztof Halasa
Hi,
On Mon, Nov 05, 2007 at 12:00:16AM +0100, Krzysztof Halasa wrote:
> Andreas Mohr <[email protected]> writes:
> > And viewing from a quite problematic angle (card is in running PC,
> > difficult to view) strongly seems to indicate a VT630_6_ (the "6" is
> > quite clearly visible).
> > This means that I currently cannot offer any mfct. date data however,
> > unfortunately.
>
> Yeah. I think (feel or something) VIA does the usual thing with
> revision numbers so rev 0x46 means always the same silicon (VT6306)
> and rev 0x80 is always the same VT6307. There might be other
> revisions but I think we won't find non-VT6306 rev 0x46 or
> non-VT6307 rev 0x80.
OK, PC was off now (good to be using S2D instead of S2R ;),
the card data is:
"SN1394", "STARNET V1.0"
mfct.: 0450
VIA VT6306
0449CD TAIWAN
2HG1002703
(IOW, a moderately new VT6306 card)
SEEPROM:
ATMEL 418
93C46
PI27 A
I'm only an occasional Firewire user (external backup HDD, miniDV
grabbing), but I'm very thankful for your nice investigations!
Andreas Mohr
Krzysztof Halasa wrote:
> I guess Stefan could now try to write these values (except GUID
> and probably PCI subsystem IDs, and with OHCI 1.1 bit) to the "bad"
> card :-)
I will get back to this in about two weeks.
--
Stefan Richter
-=====-=-=== =-== ---=-
http://arcgraph.de/sr/