SGI: Hardware

The aggregator is rather vague on compatibility. All it says is that red Adaptec cards work. Others say that only certain TI chipset cards work. Others say Irix sees it as a DM10 .

Anyways, I tried two of my own cards. First one was an Adaptec (1394B-BL3) with TI TSB482AA2 and TSB81BA3 link and physical layer chipsets. It as red. It was Adaptec. Only odd things was it was PCI-X and had FW800. Under 6.5.30 it isn't even seen.




Next card is a Macally FH-701 with TSB41LV03 and TSB12LV23 chips.
Irix complains about it while booting and only sees it as a 1394 interface when fully booted.





What use is the card if only seen as a 1394 interface andnot as a DM10 or is there any real difference according to Irix at all beyond the naming?

The DM10 is a PCI card. Just a generic FireWire card with a DM10 sticker, to be precise

The device driver doesn't care about the manufacturer or the color of the PCB. It cares about the PCI vendorID:deviceID of the chip(s) on the board. In IRIX, a device driver can register itself as a handler for one or more PCI IDs using the function pciio_driver_register() . It usually does this in the entry point ${DRIVER_NAME}_init().

It wouldn't be kind to Nekonoko to post disassembled IRIX code here, but if you run fire.o through dis and have a look at fire_init(), you'll see it calls pciio_driver_register() three times, for these PCI IDs:

• 104c:8009 : TI TSB12LV22 IEEE-1394 Controller
• 104c:8019 : TI TSB12LV23 IEEE-1394 Controller
• 104c:8024 : TI TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link)

The Adaptec board recognized as a DM10 has a PCI ID of 104c:8024.

So, it is to be expected that any card with a PCI ID of 104c:8024 is recognized as a DM10. The other two IDs are probably a courtesy of the driver writer because SGI didn't ship products with those IDs. These appear to be recognized as '1394 high speed OHCI card'.

The IRIX kernel will not call the 1394 driver for any devices not registered by it. This includes your FW800 Adaptec, regardless of it's shiny red appearance

TI made quite a few different 1394 link layer chips (and corresponding PHYs), but the three mentioned here are the most common in consumer equipment. Hence Hamei's sentiment that 'anything with a TI chip' works (even if the PCB is green )

Those handy with hex editors might get creative and patch the PCI IDs supported by the driver. I'd be careful with that, though: several 1394 chips, especially VIA chips, have really weird quirks. An 800Mb TI chip might work, though. Maybe I'll give it a shot.

And that, boys and girls, concludes today's introduction to reverse engineering

I have a Belkin 800Mb card at home, NIB and unused. This actually got me thinking... Hmmm...

OK, I couldn't resist. Put a MacPower FireWire 800 card in the Fuel , and patched the link layer PCI ID in (104c:8025).

It is picked up, and reported in hinv:

(notice the IEEE 1394 High performance serial bus controller and Integral SCSI controller 2: Version IEEE1394 SBP2 )

*but* at boot it mutters something about a loss of SCLK and unable to reset the bus.

I happen to know a thing or two about FireWire (cough) and this isn't good. Basically the interface between the discrete link layer (TSB82AA2) and PHY (TSB81BA3) chips isn't properly initialized. The TSB82AA2 is a 1394B OHCI 1.1 link layer, and that's too different from 1394A OHCI 1.0 chips to 'just' work without changes to the code. Additionally, the TI TSB81BA3 PHY has a bug described here: http://www.ti.com/lit/er/sllz059/sllz059.pdf which needs to be worked around or it simply won't work.

And indeed, an attached Lacie FireWire 800 hard disk doesn't show.

OK, now back to work

Someone else tried that card before. You got farther than they did, if that's any consolation

What are the chances of something like this becoming Irix-useful ?

http://www.dennedy.org/libraw1394/

And guess what I found on this particular board? (Belkin F5U623)

TSB82AA2 and it's partner TSB81BA3. Fsck.
Back to the pile again...

Unlucky! looking at the PCI ID database, 8025 is only one of two in the run of IDs 8000 - 802e that has separate link and PHY (tho' the list is far from sequential). <speculation>Devices with 8032, 803a, 8101 might also be worth trying - the last is a TSB43DB42 so presumably not unrelated to the TSB43AB23 in a 104c:8024 device and has the same "IEEE-1394a-2000" description.</speculation>

Thing is, once you've got Firewire, what do you do with it? In my case, I should be backing up my Fuel to the 1TB FW external disk I bought after I'd added the FW card! I really should be backing up my Fuel somewhere!!

There was chatter in the IRC the other day that when seen as a DM10 you can attach DV devices like MiniDV cameras and decks and both stream and control to whatever software you have installed. Stuff like the iSight tries to work but apparently crashes and burns.
That's a hell of a lot more than just hanging disks off the system and a fair bit more useful. From the one picture I could find of the card it looked like any other PCI firewire controller with TI chipsets.
It IS worth nothing that my Macally card (and possibly the Adaptec card too) has an "EEPROM WRITE PROTECT" jumper. I'm curious if you can change the Device ID to something Irix would be more expecting.

Edited: Yes, this was actually asked once before.

Best to ask the chatterers whether they have actually achieved this or whether they are typing out their nether regions. The people with the most experience here have never to my knowledge been able to get farther than a single upside-down frame displayed on the desktop.

Getting a DVD-writer to work is an interesting possibility tho. CD-ROMS have been reported as working in the Real World (tm). Memory card readers also work, but only up to 2 GB*. Perhaps some of the enthusiasts who want to open-source Irix could start by writing a userland VFAT driver ?

*Some day, just for fun, someone should try formatting a 4+ gig memory card as xfs, just to see if it works. That might be a useful way to transfer files to-from a Linux computer - kind of a super-floppy, what we used to call sneakernet. (Sneakers as in Keds, not the CIA type.)

All true.

Whoa there. There's a *big* difference between changing the sub VendorID: sub DeviceID (the essence of 'fixing' a 3c996bT or other OEMed TG3 gigabit card) and changing the vendorID:deviceID of a card.

The subVendorID:subDeviceID exists to allow the likes of SGI to sell an otherwise identical $10 IEEE1394 card as a $1000 video option.

The vendorID:deviceID exists to uniquely identify different, potentially incompatible, pieces of hardware. *How* incompatible is anybody's guess.

If *I* wanted to do this, I'd try a different approach. This is all documented, you know . The mechanism of a PCI driver roughly works like this:

1) The fire_init() function register the driver as the handler for the three device IDs mentioned yesterday.
2) The IRIX kernel scans the PCI bus(es) when booting, and if it encounters PCI devices, it attaches the registered driver for every instance it finds. If nothing is registered for a PCI ID, noting is attached.
3) So fire_attach() is called if any of the three device IDs is probed. But we've seen it doesn't *act* the same for each of these PCI IDs. In other words: these likely a secondary check in fire_attach() which checks the PCI ID for which it's being called, and depending on the results, registers either a "high performance IEEE1394 bus" or a "DMediaPro DM10 FW option" vertex in the hardware graph (the pseudo-fs under /hw).

So, to turn one of the two devices (device IDs 0x8009, 0x8019) into pseudo-DM10's, you'd have to locate the secondary check for 0x8024 and patch it out, or change the check to match your device.

And if your time is worth anything at all, you spend $10 on a card with the right PCI ID and it just 'works' (with all the limitations and quirks of the original DM10)

J-J : are you saying someone somewhere has got this to work in Irix or that it is all supposed to work in theory ?

It would be very nifty if it's possible to get these devices to function as advertised ...

I have personally used my Panasonic mini-DV camera (NV-GS220), a FireWire webcam and a Lacie FireWire disk with a 'fake' DM10 (random 1394 card with the right [104c:8024] TI chip). I could crash the O2 running 'fsr' with a 1394 disk attached initially, but at some point that was fixed. The lack of hot plug makes it rather unusable though.

I am aware that people have had troubles with various FireWire devices over time, but how much of that was due to non-genuine DM10's, problems with early releases of the DM10 software? I don't know...

But my last message was more about the difference between cards with 104c:8009, 104c:8019 IDs and the 'DM10' (or compatible), the 104c:8024. The latter has the DigitalMedia functionality, and my post was about ways to (in theory) unlock this functionality on the 104c:8009 and 104c:8019 devices.

That was all speculation, but that's how I would do it. I had a quick look at fire_attach() and indeed it does the equivalent of



0x8020 is a TSB12LV26 IEEE-1394 Controller (Link). Sloppy, the device driver has not even been registered to handle this device ... but I'm pretty sure if you patch 0x8009 or 0x8019 in there it will unlock DMedia functionality on those boards I don't think I have either of these two boards, so I'll leave this for others to figure out.

And that, boys and girls, concludes today's reverse engineering tutorial.

j-j, you're a prince. Thank you.

That's most likely the more efficient thing.