Re: Issues with TI XIO2213 chipset?

[Stefan R. <st...@s5...>]

On Dec 30 Charlie McMackin wrote:
> > Given that this endless series of bus reset IRQs happens with a known
> > good physical layer chip, it is a very strong indication of a hardware
> > fault.  E.g. said power supply problem.
> 
> I have now tested with a dedicated power supply but I still get errors
> mentioned previously. While disappointing, it also allowed me to
> attempt the 4-pin 1394a connector on the ADVC110.  I connected to it
> using a 1394b 9-pin male to 1394a  4-pin male cable into one of the
> 1394b ports on the SD-PEX30009 and lo :
[...]

All of the kernel log looks good.

> At the end, the /dev/raw1394 surprised me because I had freshly booted
> the machine and I knew the old ieee1394 firewire drivers were
> blacklisted.  To be sure, I removed the device and then rmmod'd the
> modules as root and then plugged the device back in.  I received the
> same output -- the ieee1394 modules are being loaded automatically:
> 
> root@onyx:~#
> dv1394                 18602  0
> ohci1394               30338  1 dv1394
> raw1394                25814  0
> ieee1394               95219  3 dv1394,ohci1394,raw1394
> firewire_ohci          24615  0
> firewire_core          54327  1 firewire_ohci
> crc_itu_t               1739  1 firewire_core

raw1394 and dv1394 have module aliases for the AV/C unit identifiers
which the ADVC110's configuration ROM contains, that's why they would
be auto-loaded if you had _no_ blacklist entries.

Maybe your modprobe configuration is not complete, or
an /etc/modprobe.conf exists but was not updated from /etc/modprobe.d/*
or whatever.  As far as I know, the modprobe of most current
distributions accesses /etc/modprobe.d/* only if /etc/modprobe.conf
does not exist.  Some distributions do not install /etc/modprobe.conf
anymore, others do and provide a script (e.g. /sbin/update-modules)
which creates /etc/modprobe.conf based on the contents
of /etc/modprobe.d/*.

ieee1394 was autoloaded because both raw1394 and dv1394 depend on it,
and ohci1394 was autoloaded because dv1394 depends on it.

>  I also have both a /dev/fw1 and a /dev/raw1394.

/dev/fw* is created for each node (with active link layer and regular
configuration ROM) by firewire-core¹ if firewire-ohci is bound to the
FireWire controller(s).  /dev/raw1394 on the other hand is created by
raw1394¹ whenever raw1394 is beaing loaded, independently of whether
ohci1394 was loaded or not and was bound to any controller or not and
whether any IEEE 1394 nodes are present or not.

¹) actually by udev, when it gets respective events from the kernel
from firewire-core or raw1394 respectively

> I assumed, for the
> time being, that might be a ubuntu configuration issue...maybe with
> lshal or udev rules (?)  Then I tried dvgrab 3.5 (dvgrab -buffers 300)
> and it appears to select /dev/fw1 automatically -- 'lsof' shows
> /dev/fw1 being 'grabbed' by dvgrab and nothing on /dev/raw1394 -- and
> the video does come through fine. Yay!

Libraw1394 first searches for /dev/fw* and only accesses /dev/raw1394
if no /dev/fw* could be opened.

> I'm happy that it appears I'll be able to grab video with my desired
> pipeline, but I'm still a little miffed that the 1394a port didn't
> work. The next step I believe would be to test with a different 1394a
> cable  to see if that is the point of failure and, of course, I don't
> have one at the moment :(
> 
> My final question is: are the drivers known to work with 1394a and
> 1394b TI XIO2213A combo cards?  I ask because your 'lspci' output
> doesn't mention the XIO2221 like the output from my 'lspci'.  Maybe
> this is just a difference in lspci 3.1.4 vs. 3.1.7?

For completeness,
here is what I get from my XIO2213A card with lspci -nn.  (I don't want
to take the card out of the PC right now to read the label on the
chip... Maybe it is actually a XIO2213B, not a XIO2213A.)

    08:00.0 PCI bridge [0604]: Texas Instruments XIO2213A PCI Express to PCI Bridge [104c:823e] (rev 01)
    09:00.0 FireWire (IEEE 1394) [0c00]: Texas Instruments XIO2213A 1394b OHCI with 3-Port PHY [104c:823f] (rev 01)

XIO2213A, XIO2213B, and XIO2221 all have Vendor ID/ Device ID/ Revision
ID = 104c/ 823e/ 01 in their PCIe-PCI bridge part and 104c/ 823f/ 01 in
their PCI-OHCI1394 link layer controller part.  I suppose lspci was
updated after v3.1.4 for the two newer chip variants.

It is this card, which is sold as no-name card at various places:
http://www.delock.com/produkte/gruppen/pci-express/Delock_PCI_Express_card_FireWire_A_SLASH_B_89153.html

> I guess for now,
> I'll assume either there is something wrong with either the 1394a
> cable or the 1394a port on the card.

I find it unlikely to be an issue of chip revisions.  It could be a
matter of sloppy board layout, bad cable, damaged 6-pin port on the
Canopus, or two or three out of card port -- cable -- Canopus port
being slightly off the spec so that the combination of them does not
work.

XIO2213A, XIO2213B, and XIO2221 have so-called bilingual ports (the
former ones have three and XIO2221 has one port), i.e. ports which can
operate in 1394b signal mode ("beta" mode) or 1394a signal mode
("alpha" mode, data-strobe mode, legacy mode...).  This is in contrast
to monolingual 1394b ports which only operate in "beta" mode, i.e. are
not backwards compatible with 1394a devices.  (9-pin sockets of
monolingual ports are keyed such that you can only plug 9-pin--9-pin
cables into them, but not the 9-pin end of a 9-pin--6-pin or
9-pin--4-pin cable.)

Card designers can thus provide a FireWire 400 port simply by putting a
6-pin connector onto the terminals of one of the bilingual ports (and
by pulling a certain control terminal high to prevent beta mode to be
used over the 6-pin port, in case that another 1394b device is
connected to that port).  For system software, there is no difference
between a bilingual port with 6-pin socket + 6-pin--4/6-pin cable +
1394a device on one hand, or a bilingual port with 9-pin socket +
9-pin--4/6-pin cable + 1394a device on the other hand.
-- 
Stefan Richter
-=====-==-== ---= ----=
http://arcgraph.de/sr/