Firewire support

Status

• Video transfer is working fine -- also on the 2.6 kernel on spello
• Firewire harddrives daisy-chain on cyberspace's 2.4 kernel
• unmounting and remounting is now working
  
• iPod works fine on sigillo's 2.6 kernel
• Combo Firewire/USB2.0 works as USB2.0 on spello and USB1.0 on trevi
• seems very fast -- see USB file for details
  

To do (see also Todo file)

• See if the 6-6 firewire cable also supplies power
• I'm assuming the 6-4 cable doesn't
• Test firewire on sigillo and spello (the 2.6 kernel)
  

Guides

• Digital video pages
• dvgrab

Commands

• cat /proc/scsi/scsi
• rescan-scsi-bus.sh
  
• echo "scsi add-single-device 0 0 0 0" >/proc/scsi/scsi
• echo "scsi add-single-device 0 0 1 0" >/proc/scsi/scsi
• rescan-scsi-bus.sh -r
• echo "scsi remove-single-device 0 0 1 0" >/proc/scsi
• echo "scsi remove-single-device 0 0 0 0" >/proc/scsi

Software

• You just need a recent kernel -- 2.4.19 or better
• IEEE 1394 for Linux
  
• http://www.singingwizard.org/programming.php and http://www.singingwizard.org/ftp/programming/ -- a new module/package called dv_utils from the libdv project to provide all sorts of utilites to work with and between AVI, Quicktime, and raw file formats -- try it!
• Dan Maas wrote a dv1394io utility (Dan Dennedy sent it to me in early Oct 02  -- don't know whether it's still installed)

Hardware

• PCI-X 1394b cards -- best way to get removable drives?
• iDT882 PCI -- three external 1394b ports
  
• QuikFire iDT804PCI -- four channels, $600, supports software RAID -- would allow Trevi to act as fast firewire storage hub
• Low-profile cards from Roalan (UK, but they ship global)
  
• Drive enclosures
• Back-up Q Penr-35u2f (already bought two)
• USB2.0 supports 480 MB/s and ieee1394 400 MB/s
• USB2.0 is faster and cheaper but doesn't daisy-chain
  
• Acortech has several
  
• Towers and stuff -- some of these are very cool
  

Instructions

Firewire harddrive

To mount a firewire harddrive on a 2.4 kernel, ensure first that the modules ieee1394 and ohci1394 load on boot. The drive will also be recognized during booting. Run rescan-scsi-bus.sh to attach the drive and then mount it.

To unattach and then reattach the drive without rebooting, follow this procedure:

• trevi: umount /dev/tv1  (unmount the nfs-mounts)
• cybers: stop nfs-kernel-server (this frees the exported drives)
• cybers: umount /dev/tv1
• cybers: start nfs-kernel-server (make /vc available again)
  
• detach the firewire cable (mandatory unless it's the first drive)
  
• turn off the drive enclosure unit
• issue rescan-scsi-bus.sh -r
  
• issue cat /proc/scsi/scsi to confirm the drive is removed
  
• give the drive a rest to cool down
  
• turn on the drive enclosure unit
• wait until the drive is up to speed (a few seconds)
• reattach the firewire cable
  
• wait a few seconds for the drive to be reattached
• issue rescan-scsi-bus.sh
• issue cat /proc/scsi/scsi to confirm the drive is reattached

Installation history

Firewire harddrive
21 February 2005

The firewire/usb 2.0 harddrive enclosures I got work fine as USB 1 drives off Trevi, and would likely work fine off Spello's USB 3.0 card.

Spello already has other stuff on the firewire card, but I gave it a shot to see if it would mount, unmount, and remount. Well, plugging in the drive had no effect -- it didn't even get detected, even after sbp2 was loaded manually, so I let that be. You could use the USB 2.0 card, however -- that wouldn't interfere with anything and probably won't mind mounting and unmounting. You could do some speed tests to compare with firewire.

I installed a USB 2.0 card on Cyberspace, but first tried the unused firewire card. I  attached the external drive and then nfs-mounted it on Trevi -- and this is with an ancient 2.4.21-ac2 kernel. Here's how:

• the modules ieee1394 and ohci1394 were already loaded
• when I plugged in the drive, the sbp2 module loaded automatically
• to attached the device, run /sbin/rescan-scsi-bus.sh (2.4 kernels only)
  
• the drive attaches to /dev/sda1 (see dmesg or /var/log/syslog)
  
• this particular 200GB drive mounted as ext2 on /mnt/tv1
• I added the mount point to /etc/exports and exportfs -ra
• finally I mounted it on trevi at /mnt/tv1

• trevi: umount /dev/tv1  (unmount the nfs-mounts)
  
• cybers: stop nfs-kernel-server (this frees the drive)
  
• cybers: umount /dev/tv1
  
• physically detach the drive
  
• rmmod sbp2 sd_mod scsi_mod ohci1394 ieee1394 (free modules)
  
• modprobe ieee1394 && modprobe ohci1394 (set up for remount later)
  

• physically detach the drive
• rmmod sbp2 sd_mod scsi_mod ohci1394 ieee1394 (free modules)
• modprobe ieee1394 && modprobe ohci1394
  
• turn on the drive
• reattach the firewire cable
  
• sbp2 sd_mod scsi_mod will load automatically (they do but it still fails)
  
• /sbin/rescan-scsi-bus.sh (doesn't find the drive)
  
• cybers: mount /mnt/tv1
• trevi: mount /mnt/tv1
  

# /sbin/rescan-scsi-bus.sh
Host adapter 0 (sbp2_0) found.
Scanning for device 0 0 0 0 ...
NEW: Host: scsi0 Channel: 00 Id: 00 Lun: 00
      Vendor: ST320082 Model: 2A               Rev:
      Type:   Direct-Access                    ANSI SCSI revision: 06
Scanning for device 0 0 1 0 ...
NEW: Host: scsi0 Channel: 00 Id: 01 Lun: 00
      Vendor: Maxtor 9 Model: 1020U3           Rev:
      Type:   Direct-Access                    ANSI SCSI revision: 06
2 new device(s) found.

scsi singledevice 0 0 0 0
  Vendor: ST320082  Model: 2A                Rev:
  Type:   Direct-Access                      ANSI SCSI revision: 06
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB)
 sda: sda1
scsi singledevice 0 0 1 0
  Vendor: Maxtor 9  Model: 1020U3            Rev:
  Type:   Direct-Access                      ANSI SCSI revision: 06
Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0
SCSI device sdb: 19941264 512-byte hdwr sectors (10210 MB)
 sdb: sdb1 sdb2 sdb3

echo "scsi remove-single-device 0 0 0 0" >/proc/scsi

rescan-scsi-bus.sh -r

echo "scsi add-single-device 0 0 0 0" >/proc/scsi/scsi

echo "scsi add-single-device 0 0 1 0" >/proc/scsi/scsi

cat /proc/scsi/scsi

• test USB 2.0 again -- USB 1.0 worked great with Trevi
• see if you can mount, umount, and remount repeatedly
• test ieee1394 under the 2.6 kernel
• see if you can mount, umount, and remount repeatedly
• move /vd into the second drive enclosure
• the current drive can be used for an OS
  

• unmount the drive
• detach the firewire cable
• turn off the drive enclosure unit
• issue rescan-scsi-bus.sh -r
  
• wait a minute
• turn on the drive enclosure unit
• wait until the drive is up to speed (a few seconds)
• reattach the firewire cable
• wait a minute

ieee1394: sbp2: Logged into SBP-2 device
ieee1394: sbp2: Node 0-01:1023: Max speed [S400] - Max payload [2048]
ieee1394: Node changed: 0-01:1023 -> 0-02:1023
ieee1394: unsolicited response packet received - no tlabel match
ieee1394: unsolicited response packet received - no tlabel match

• rescan-scsi-bus.sh

iPod -- see separate page

Networking (I've not tested this)

Configuring the cards works just as a normal network card:

- on machine 1
ifconfig eth1 10.0.139.1 netmask 255.255.255.0 up

- on machine 2
ifconfig eth1 10.0.132.2 netmask 255.255.255.0 up

Now let's ping the other node:

[root@dhcp71 root]# ping 10.0.139.2
PING 10.0.139.2 (10.0.139.2) from 10.0.139.1 : 56(84) bytes of data.
64 bytes from 10.0.139.2: icmp_seq=1 ttl=64 time=0.659 ms
64 bytes from 10.0.139.2: icmp_seq=2 ttl=64 time=0.195 ms

--- 10.0.139.2 ping statistics ---
2 packets transmitted, 2 received, 0% loss, time 1006ms
rtt min/avg/max/mdev = 0.195/0.427/0.659/0.232 ms

Source (describes how to establish an openMosix cluster over Firewire -- this would be good for my lab). See also

Remote capturing and encoding

dvcont rewind
dvcont play
dvgrab --autosplit --format dv2 --frames 7500 --index small --timestamp Tape01- >& logfile &
(Make sure you don't use --timestamp if you don't have one on the tape)

This will start the capturing. To complete it, send a SIGINT to the process pid:

kill -2 <pid dvgrab>

This will cleanly close it, as you can verify in the log file.

dvcont rewind
dv2divx.sh >& logfile &

This will compress the files and complete on its own.

Note that there are three ways to export data back to the camcorder:

1. dvconnect from the libdv package.
   
2. Kino's Export IEEE-1394 function.
   
3. The dv1394 driver (see details).

I've not tried dvconnect.

Loading modules and defining nodes

The modules must now be manually loaded in this order on reboot -- use source .mods:

insmod ieee1394
insmod ohci1394
insmod raw1394
insmod dv1394

To remove modules, do rmmod <module>.

For information:

cat /proc/bus/ieee1394/devices
cat /proc/bus/ieee1394/dv/host0/NTSC/in
cat /proc/bus/ieee1394/dv/host0/NTSC/out

To set export values (may not be required)::

echo cip_n=1 >/proc/bus/ieee1394/dv/host0/NTSC/out
echo cip_n=16 >/proc/bus/ieee1394/dv/host0/NTSC/out
echo syt_offset=2 >/proc/bus/ieee1394/dv/host0/NTSC/out

To set import values (may not be required)::

echo cip_n=1 >/proc/bus/ieee1394/dv/host0/NTSC/in
echo cip_n=16 >/proc/bus/ieee1394/dv/host0/NTSC/in
echo syt_offset=2 >/proc/bus/ieee1394/dv/host0/NTSC/in

How to use the new dv1394 driver

1. start camera playback:

% dvcont play

2. preview:

% playdv --no-mmap /dev/ieee1394/dv/host0/NTSC/in

3. capture DV:

% cat /dev/ieee1394/dv/host0/NTSC/in > my.dv

3. stop camera:

% dvcont stop

4. view in monitor:

% playdv my.dv

5. export DV (run dv1394out as root):

% dv1394out *.dv

This worked fine on 26 October 02 (see tweak below). It's also possible to us this:

cat my.dv >/dev/ieee1394/dv/host0/NTSC/out

or this:

cat test.dv > /dev/dv1394in

This worked on 30 Sep 02. You need to press Record on the camcorder (while still in VTR mode), and it records the video perfectly, with sound.

It's possible to adjust the DV export settings, but dv1394io appears to set them automatically, which is clearly preferable.

echo cip_n=1 >/proc/bus/ieee1394/dv/host0/NTSC/out
echo cip_n=16 >/proc/bus/ieee1394/dv/host0/NTSC/out
echo syt_offset=2 >/proc/bus/ieee1394/dv/host0/NTSC/out

Note that syt_offset is specified in different units (whole cycles) than video1394/Kino currently uses!

12 February 2005 update

The Sony TRV-900 is shipped with the pass-through NOT activated.  However, there is a hack that will allow you to activate the pass-through function.  It requires purchasing a service remote. The RM-95 is a wired LANC remote which can control any LANC camera or VCR.  Source

TRV900 NTSC   DV-IN enabled (factory setup)
By clearing LSB of 0D:27 on my TRV900 (disable DV-in) I can do direct analog-DV conversion.  Source

RM-95 WIRED REMOTE
The RM-95 is a LANC wired remote, similar to the standard IR remote, though with some other functions too.  It is intended for sale to service technicians and not the general public; nevertheless, anyone in the USA can order it, just go to servicesales.sel.sony.com and enter part # J6082053B [I verified that this works -- $78].

The RM-95 wired remote looks a little like the standard IR remote, but it has a LCD display and comes with a 16 foot long LANC cable. No batteries, it's powered from the camera. The LCD display shows timecode as H:MM:SS (no frame number). In addition to the normal record/pause and tape transport functions you can control zoom and focus with it. The focus is manual-mode only, there is no push-to-autofocus feature on the remote. Focusing and zoom have only a single speed (fairly slow). You can also turn the camera off and on (unless the physical camera switch is "off"). The RM-95 is not specific to the TRV900 but can be used with any Sony or Canon camcorders with a LANC jack. It also works with my GV-D900 MiniDV VCR. It can be useful if you want to use the camera mounted remotely, eg. mounted on a tilt/pan head. If you're planning that, also check out Fred Wilharm's page. You can also use the RM-95 to read out internal camera data such as the number of hours on the video head, as described here.

source

You could also make your own connector and control this through a Linux program.

20 March 2004 update

The Sony Digital Handycam D8 DCR-TRV-140 NTSC device gets this response in syslog on Sigillo running 2.6.4:

Mar 20 12:32:08 sigillo kernel: ieee1394: Node added: ID:BUS[0-00:1023]  GUID[0800460102217f94]
Mar 20 12:32:08 sigillo kernel: ieee1394: Node changed: 0-00:1023 -> 0-01:1023
Mar 20 12:32:08 sigillo ieee1394.agent[3597]: ... no drivers for IEEE1394 product 0x/0x/0x
Mar 20 12:32:08 sigillo ieee1394.agent[3606]: ... no drivers for IEEE1394 product 0x/0x/0x
Mar 20 12:32:08 sigillo ieee1394.agent[3611]: kernel driver dv1394 already loaded
Mar 20 12:32:08 sigillo ieee1394.agent[3611]: kernel driver raw1394 already loaded

The camcorder is not recognized on Spello's 2.4.21-ac2 -- but it's great news that it's recognized on 2.6.4!

This worked (but you have to press play on the camcorder):

playdv --no-mmap /dev/ieee1394/dv/host0/NTSC/in

dvgrab | xine -D stdin://#demux:rawdv

Late October update

On 26 October 2002, I redefined the /dev/ieee1394/dv/host0/NTSC/out node as follows:

mknod -m 666 out c 171 32

Note that this means it's defined identically to /dev/ieee1394/dv/host0/NTSC/in. The problem (see below) is that without devfs, you only get one node. However, this single node works for both in and out. So the solution is to define both the nodes as minor 32. This means that Dan Maas' dv1394out works! Note that you should run this as root.

I also switched /dev/video1394 from 172 0 to 171 16 with this command:

mknod -m 666 video1394 c 171 16

Early October update

On 6 October 2002, after installing dv1394in and dv1394out (from Dan Maas' dv1394io utility) in /usr/bin (they should be used as root), I modified the settings in /dev to accomodate a larger number of cards and input ports.

Then I created /dev/ieee1394/dv/host0/NTSC/in and out:

mknod -m 666 in c 171 32
mknod -m 666 out c 171 33

Note that I didn't delete the existing nodes at /dev/1394in and out, or the symlink dv1394 to dv1394in. The system doesn't seem to mind the duplication. (Note that the c -- the first letter in the line and in the file permissions -- indicates that this is a character node (c) rather than a block node (b) or a FIFO (p). See man pages for mknod.)

I then tested dv1394in 2000.07.12.dv and it seems robust and reliable. It creates raw dv files. I then read that file into kino, removed the very orderly empty frames at the beginning, and exported with 7500 and timestamp, with worked fine. So this appears to be a workable method of capturing using the new dv1394 driver (though it's not even clear that dv1394io is using the dv1394 driver -- it probably is).

This is also a possible method of making copies of tapes. However, the fact remains that using the old method with a working dvgrab works better and simpler. There's so far no real gain with the dv1394 driver.

Since the system didn't appear to mind the duplication of nodes in /dev, I reinstated the old node too, in an attempt to see if I can still use the old dvgrab on gubbio:

mknod -m 666 /dev/video1394 c 172 0

I now have the following device nodes:

/dev
crw-rw-rw-    1 steen    users    171,  32 Sep 27 14:19 dv1394in
crw-rw-rw-    1 steen    users    171,  33 Sep 27 14:19 dv1394out
crw-rw-rw-    1 root     root     171,   0 Dec 29  2001 raw1394
crw-rw-rw-    1 root     root     172,   0 Oct  6 12:51 video1394

/dev/ieee1394/dv/host0/NTSC
crw-rw-rw-    1 root     root     171,  32 Oct  6 12:26 in
crw-rw-rw-    1 root     root     171,  33 Oct  6 12:26 out

These are used as follows:

• dv1394in and dv1394out are used by the new dv1394 driver, for instance for the cat command and the new dvgrab, /usr/bin/dvgrab. This system is not working properly.
• in and out are used by the dv1394io utilities, /usr/bin/dv1394in and /usr/bin/dv1394out (used by user root). They seem to be working fine.

When I ran the old dvgrab after reestablishing the old video1394 node, it appears to be working as before, which is a relief.

Early September update

On 4 September 2002 I updated my gubbio kernel to 2.4.19-ac4 and changed the character numbers as follows (note that this means that the 2.4.16m5 kernel will likely no longer work for video!):

This version comes with an updated video1394 that uses a different char- major and -minor number. From your 'ls -l' output you can see it is using c-172-0. However, 172 really belonged to another device driver, so the new number is c-171-16:

su root
rm /dev/video1394
mknod -m 666 /dev/video1394 c 171 16

Source: http://www.schirmacher.de/dcforum/DCForumID1/256.html

Some day dv1394 will replace the use of raw1394 and video1394 for all DV I/O.

Here's what happened on insmod:

gubbio:~ # insmod ieee1394
Using /lib/modules/2.4.19-ac4/kernel/drivers/ieee1394/ieee1394.o

gubbio:~# insmod ohci1394
Using /lib/modules/2.4.19-ac4/kernel/drivers/ieee1394/ohci1394.o

gubbio:~ # insmod raw1394
Using /lib/modules/2.4.19-ac4/kernel/drivers/ieee1394/raw1394.o

gubbio:~ # insmod dv1394
Using /lib/modules/2.4.19-ac4/kernel/drivers/ieee1394/dv1394.o

Here's what's in proc:

cat /proc/bus/ieee1394/devices
cat /proc/bus/ieee1394/dv/host0/NTSC/in
cat /proc/bus/ieee1394/dv/host0/NTSC/out

gubbio:/proc/bus/ieee1394 # cat devices
Node[00:1023]  GUID[00308d010001a64c]:
  Vendor ID: `Linux OHCI-1394' [0x000000]
  Capabilities: 0x0083c0
  Bus Options:
    IRMC(1) CMC(1) ISC(1) BMC(0) PMC(0) GEN(0)
    LSPD(2) MAX_REC(2048) CYC_CLK_ACC(0)
  Host Node Status:
    Host Driver     : ohci1394
    Nodes connected : 1
    Nodes active    : 1
    SelfIDs received: 1
    Irm ID          : [00:1023]
    BusMgr ID       : [00:1023]
    In Bus Reset    : no
    Root            : yes
    Cycle Master    : no
    IRM             : yes
    Bus Manager     : yes


gubbio:/proc/bus/ieee1394/dv/host0/NTSC # cat in
format=NTSC
channel=63
cip_n=0
cip_d=0
syt_offset=0

gubbio:/proc/bus/ieee1394/dv/host0/NTSC # cat out
format=NTSC
channel=63
cip_n=0
cip_d=0
syt_offset=0

The PAL directory shows the same thing -- the values haven't been set yet. Setting works fine:

echo syt_offset=2 >/proc/bus/ieee1394/dv/host0/NTSC/out

gubbio:/proc/bus/ieee1394/dv/host0/NTSC # cat out
format=NTSC
channel=63
cip_n=0
cip_d=0
syt_offset=2

So that's it -- this looks fine, though I still haven't tested it. I set the syt_offset back to 0.

gubbio:/proc/bus/ieee1394/dv/host0/NTSC # lsmod
Module Size Used by
dv1394 18528 3
raw1394 7552 0 (unused)
ohci1394 17712 0 [dv1394]
ieee1394 33264 1 [dv1394 raw1394 ohci1394]

Notice that raw1394 isn't used by any of the other modules -- but kino and dvgrab may still be using it.

On 27 September I found the following on the old kino boards:

for NTSC:
mknod /dev/dv1394in c 171 32
mknod /dev/dv1394out c 171 33

This should complete the installation of the new dv1394 driver.

August 2002 update

On 20 August 2002, I tried to get ieee1394 to work on cyberspace. Note that to install firewire on cyberspace, I simply followed the instructions on this page. I did have to define the node for ieee1394, but the node for raw1394 was already present; I changed the chmod as instructed.

I also added a parameter to the modprobe 1394ohci -- see the instructions.

I also compared the two cards in the lspci -vvx listing. There are two differences: the Studio DV card on gubbio is listed as OHCI compliant with a latency of 32, while the new card on cyberspace is not listed as OHCI complient (which doesn't at all mean that it isn't), with a latency of 64. That sounds worse, but likely won't matter -- we'll see. Cyberspace should now be set up for video work; details below.

You should install gscanbus, at least if you have problems of any kind.

1. I verified that the kernel had been defined correctly; all the relevant parts are modules. I did this by checking /usr/src/linux/.config, but note that you can check the configuration of the running kernel via less /proc/config.gz. In any case, here are the details:

# IEEE 1394 (FireWire) support (EXPERIMENTAL)
CONFIG_IEEE1394=m

# Device Drivers
CONFIG_IEEE1394_PCILYNX=m
CONFIG_IEEE1394_PCILYNX_LOCALRAM=y
CONFIG_IEEE1394_PCILYNX_PORTS=y
CONFIG_IEEE1394_OHCI1394=m

# Protocol Drivers
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_SBP2=m
CONFIG_IEEE1394_RAWIO=m

Note that you're not using PCILYNX (a driver for certain firewire cards), or SBP2 (firewire harddrive).

2. I loaded raw1394 with the command,

modprobe raw1394

3. There was no receipt, but when I issued

testlibraw

I got this (before I loaded the module, I got handle not found):

successfully got handle
current generation number: 0
0 card(s) found

4. So the card is not found. I then loaded more modules:

modprobe ieee1394

and when I now did lsmod, I got this:

cyberspace:/home/steen # lsmod
Module Size Used by
raw1394 6336 0
ieee1394 23536 0 [raw1394]

5. For the card itself, I need the OHCI1394 driver, and issued:

modprobe ohci1394 (note that caps don't work)

I now got,

        cyberspace:/home/steen # lsmod
        Module                  Size  Used by
        ohci1394               14992   0  (unused)
        raw1394                 6336   0
        ieee1394               23536   0  [ohci1394 raw1394]

And the card is now found:

cyberspace:/home/steen # testlibraw
successfully got handle
current generation number: 2
1 card(s) found
nodes on bus: 1, card name: ohci1394
using first card found: 1 nodes on bus, local ID is 0, IRM is 63

doing transactions with custom tag handler
trying to send read request to node 0... completed with value 0x0f4bc578

using standard tag handler and synchronous calls
trying to read from node 0... completed with value 0x2d54c578

testing FCP monitoring on local node
got fcp command from node 0 of 8 bytes: 01 23 45 67 89 ab cd ef
got fcp response from node 0 of 8 bytes: 01 23 45 67 89 ab cd ef
polling for leftover messages

And after running testlibraw, I also get this:

cyberspace:/home/steen # lsmod
Module Size Used by
ohci1394 14992 0
raw1394 6336 0
ieee1394 23536 0 [ohci1394 raw1394]

Note that it no longer says that the ohci1394 driver is unused.

6. Now, there are also two protocol drivers -- VIDEO1394 and RAWIO. I doubt these need to be loaded explicitly, but I attempt to do so:

modprobe video1394

Well, this worked, so I was wrong: video1394 should also be loaded. I now get,

cyberspace:/home/steen # lsmod
Module Size Used by
video1394 14896 0 (unused)
ohci1394 14992 1 [video1394]
raw1394 6336 0
ieee1394 23536 0 [video1394 ohci1394 raw1394]

Note that video1394 is listed us unused, but also as used by ohci1394 and ieee1394. I then try the last one:

modprobe rawio

This fails; apparently this is not the right name of what .config calls CONFIG_IEEE1394_RAWIO=m module. Locate rawio yields nothing. I tried ieee1394io (part of the kino package), but that's clearly not the kernel module. I checked the kernel source directories with a locate ieee1394 and found the kernels I've already loaded and no others that I need. I'm guessing I have everything I need.

Mid-December 2001 Installation (see also 2001-12-29 installation)

In brief, you need some libraries and a recent kernel; I used 2.4.16 (see kernel story). See also initial installation of firewire.

libraw1394

I began by installing the libraw1394 0.9.0 RPM file from the SuSE mirror; the libraw1394-devel wouldn't install directly in Packager, so I had to download and then install it by opening it in Packager. Both packages seemed to install fine. However, when I test libraw with the command /usr/bin/testlibraw (testlibraw is enough), I get errors. So this is the first thing to make sure works.

quicktime4linux

I have no reason to believe this package is needed, but when libraw wasn't working, I tried to fix it by downloading quicktime4linux from the SuSE mirror. It contains a number of firewire components, including the libraw1394. However, it didn't solve my problem and was probably irrelevant; on the other hand, it may contain some useful codecs.

ieee_1394 kernel support

However, libraw1394 is probably just the raw capture mode for firewire, and it won't check out unless firewire is enabled in the kernel (or in loaded modules). SuSE's 7.3 Personal edition has most of the firewire support as modules. In addition, I read at the http://linux1394.sourceforge.net/ site that the 2.4.10 kernel I have is unstable for firewire and I may simply need to update to 2.4.12 or later; for this story, see kernel.

I found the configuration of the running kernel via less /proc/config.gz

# IEEE 1394 (FireWire) support (EXPERIMENTAL)
CONFIG_IEEE1394=m

# Device Drivers
CONFIG_IEEE1394_PCILYNX=m
CONFIG_IEEE1394_PCILYNX_LOCALRAM=y
CONFIG_IEEE1394_PCILYNX_PORTS=y
CONFIG_IEEE1394_OHCI1394=m

# Protocol Drivers
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_SBP2=m
CONFIG_IEEE1394_RAWIO=m
# CONFIG_IEEE1394_VERBOSEDEBUG is not set

Note that several of the components, including all the protocol drivers and one important device driver, are modules and must be loaded before use.

PCI devices

You see a list of pci devices by typing #/sbin/lspci

00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03)
00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03)
00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
00:0d.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 05)
00:0d.1 Input device controller: Creative Labs SB Live! (rev 05)
00:0f.0 Ethernet controller: National Semiconductor Corporation DP83815
00:11.0 FireWire (IEEE 1394): Texas Instruments TSB12LV23 OHCI Compliant IEEE-1394 Controller
01:00.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo Banshee (rev 03)

The firewire controller is running -- I'm not sure what that corresponds to in the list of kernel devices above. To get the verbose output, try /sbin/lspci -vvx -- I see that Linux has detected my card as a Pinnacle Systems Inc. Studio DV!

Create the device points

However, the /dev/video1394 and /dev/raw1394 devices have not been created -- this is getting closer to the problem -- and I create them using mknod:

mknod /dev/video1394 c 172 0
chmod a+rw /dev/video1394
mknod /dev/raw1394 c 171 0
chmod a+rw /dev/raw1394

Load the modules

Then there's a routine for loading modules (note that it's better to define these drivers in the kernel itself, as I do in kernel story):

echo "Adding modules...
/sbin/modprobe ieee1394
/sbin/modprobe raw1394
/sbin/modprobe ohci1394 attempt_root=1
/sbin/modprobe video1394
/sbin/lsmod

To load these automatically, add these lines to the end of some script -- in Red Hat, it's /etc/rc.d/rc.local but I suppose in SuSE it's just /etc/rc.config -- at least that configuration file loads lots of modules.

Verify the modules are loaded

And here's how to find out which modules are loaded: type /sbin/lsmod (lsmod is enough) and see a long list, including

video1394 14704 0 (unused)
ohci1394 16656 1 [video1394]
raw1394 6528 0 (unused)
ieee1394 22000 0 [video1394 ohci1394 raw1394]

Test using dvgrab

In spite of my labors, none of this really worked -- notably, dvgrab didn't work. My

dvgrab --frames 25 test

just seems to stall and I have to interrupt it. The error message says 'kernel: ohci1394_0: Physical register received outside of bus reset sequence.' This could be the buggy kernel. However, raw1394 is now showing 1 instance used, and so is ohci1394, so something is happening. Verdict: most likely cause is a buggy kernel. You should get a later kernel -- for the details, see kernel story.

I tried to apply a patch, but could not because my own kernel source was not in /usr/src/linux where it should be.

Compile a new kernel

See details here. In short, I got the 2.4.16 kernel source, which reportedly has better firewire support, and included the firewire components in the kernel itself rather than placing them in modules. The build was successful and firewire is now working.

Test using gscanbus

Start gscanbus (cf. installation history). It should produce a graphic presentation of the firewire port and any attached devices. You can click on the devices for further information, and you can use the camcorder window to control the camcorder (start, stop, record, etc).

Test using dvgrab

dvgrab works beautifully -- I'm amazed I succeeded in doing this.