Tuesday, April 26, 2005

Multiple Conflicting FireWire Enclosures from the Same Manufacturers

I currently use a Titanium PowerBook as my primary computer. However, I’m also a power user and a laptop has a limited amount of upgradeability. That means I have a lot of external devices connected to my laptop using FireWire. FireWire supports 63 devices which is great for someone like me and I’m nowhere close to 63. I have three external hard drives (two 250GB 3.5” and one bus powered 30GB 2.5”), two external DVD burners (a Pioneer 109, and a Pioneer 104), one external CD-RW burner (a Plextor W4824A), and an iPod as well as a 6 port FireWire hub. That’s only 8 devices. Not very close to the limit of 63, however, when I added my latest DVD burner (the Pioneer 109), I had a lot of problems. I eventually solved them, and I’m writing down my experiences so hopefully someone can learn from my pain.


In short…
It turns out, that FireWire devices have unique IDs similar to the MAC address on Ethernet devices. Some manufacturers use the same ID on all of their devices, which causes problems if you connect two devices from the same manufacturer to your computer. My guess is the FireWire people told the manufacturers they needed to supply unique IDs, however, somewhere along the line, that information didn’t make it to the assembly line personnel.

I’ve seen this problem with enclosures from Plumax and Acomdata and I’m sure many other manufacturers out there are doing this as well. I can also say for certain that the Mercury Elite Pro 3.5” enclosures do not suffer from this problem, as I’ve been using two identical ones for a while without fail. In fact, these are my favorite FireWire 3.5” enclosures, and I highly recommend them. You can get them here:
Other World Computing


I’ll describe how I fixed the problem below by manually changing the FireWire ID. I spent most of the time trying to isolate the problem, and then reading detailed specifications about the Oxford FireWire bridge chipsets (thanks to Oxford making their information available for download in PDF format!). But I’m getting ahead of myself.

First of all, this applies to enclosures that use the Oxford FireWire chipsets. I believe it applies to 911, 911+, 912, and 922 chipsets. Although I specifically was working with 911+ and 912. If you have an enclosure that uses a different chipset, such as Prolific, I don’t know how to help you. I’ve worked with enough enclosures to know that when you are shopping, you want to make sure you get one that has an Oxford chipset in it. All other brands have received reports of bugs and data corruption issues, that I ignored, until I lost data that I was able to trace back to a problem with the Prolific chipset. Since then, I will only buy Oxford (I should write another entry just covering that experience!) There are probably ways to do this for the other chipsets, I just don’t know what it is. I believe Prolific, and Initio are the other FireWire chipsets. Not sure of any other brands.

Second, flashing or modifying firmware can toast your enclosure. For some reason while following the instructions that worked previously and using the same flash software, I erased a 911+ chipset, and was never able to upload a new firmware to it, rendering the enclosure unusable. If anyone knows how to revive a 911+ that claims it’s ready to be flashed, but just seems to ignore the flash, contact me. So standard disclaimer…you do this at your own risk.

This should apply to Windows as well as Mac or Linux and other supported Unix computers. The flash software I’m going to discuss is Java based, so it’s cross platform. How Oxford got a Java app to access FireWire hardware is beyond me, unless they are imbedding some OS specific binaries in there. If someone from Oxford Semiconductors wants to contact me, I’d love to chat!


Ok, so let’s assume, you’ve purchased two new identical model enclosures for those two new drives you just got. And you’ve found, like I did, that whenever both of them were connected and powered on, your computer had a terrible time talking to them. Some of the symptoms were:
Incomplete directory listings
Long pauses when accessing either drive
One drive never mounting/showing up on the desktop
And occasionally, when I told one drive (a DVD drive) to eject, it would eject the other drive. It was at that point I realized that the computer wasn’t able to tell the drives apart.

Basically there are two reasons to muck with your firmware. You can upgrade to the latest version (which was my goal at first, although that didn’t solve my problems) and you can also edit some of the “advanced settings” of the drives, which are stored in the flash memory as well. It’s worth noting, that you can update the settings in flash memory without actually flashing a new firmware, which makes changing the settings a bit less risky than uploading new firmware.

Now that you’ve identified the problematic enclosures, and verified that they are running Oxford chipsets, it’s time to start getting some software that lets us mess around with the internals. I found the software by searching in many places, and was able to verify the latest version, at this time 1.64, was here:
Cool Drives FireWire Info
Specifically, the 1.64 Java updater/uploader/cloner apps for Mac OS X:
uploader_164.zip
Since it’s Java you would think that would work on Windows too, however they list a separate Windows version here:
windows_uploader.zip

Ok, if you want to get some more recent firmware you can get it from links I supply below. When I download the flash apps, they didn’t usually include the firmware files, although they had directories where you could put your own.

Anyway, they recommend that you disconnect all other FireWire devices except the one you want to work with. I just powered them down, so the only things that were active were my FireWire hub and the drive I wanted to mess with.

Then I launched the uploadergui.jar file.


Right away this found my Oxford based drive, and brought up the firmware information on it. It looked like this:


I then clicked the Modify Configuration button. If that button is grayed out, make sure you launched uploadergui.jar and NOT updatergui.jar. You should see something like this after clicking the Modify Configuration button:


Note the all important Chip ID Hi and Chip ID Lo fields. The reason I even thought to start messing with them, is because the other app that came with the uploader is called the clonergui.jar. It’s designed to take the already flashed firmware from one device and propagate it to other identical devices. It stresses that every time it uploads a clone, that it will increment the chip id by 1 for every device it flashes. Unfortunately, it didn’t make it clear to me if it only changed the Chip ID Hi or Lo or both fields. I’m guessing it simply added 1 to the hex value in the Chip ID Lo field. To be safe, I modified the values in both fields, just changing a number in each position and incrementing it by a value of one. So for example, I think Chip ID Hi, was 02, so I changed it to 03. If someone wants to clarify the usage of the Hi and Lo values, feel free to contact me. Anyway, after changing both values, I simply clicked the Upload Changes button. After that, everything started working. Obviously I only had to change that value for one of the drives, and could keep the other drive at its factory default.

While this sounds pretty simple now, it took me a lot of research to find all this information. None of it was sitting in one place. Hopefully this entry will help someone else out in the same situation. And maybe more importantly, Plumax will start making their Chip IDs unique.

Links that helped me solve the puzzle:

Thank you for the latest 1.64 updater utility.
Cool Drives

Latest firmware files, and some good info.
FireWire Depot

Thanks for making the awesome Oxford FireWire chipsets.
Oxford Semiconductor

Detailed guide on using the flash uploaded app.
Uploader Guide in PDF

I think this is the same guide as I listed before with some other chipset documents.
More docs at Oxford

Firmware 1.02 for 912 chipset:
912_v1_02.bin

Firmware 4.00 for the 911 chipset (I believe this includes the 911+ chipset):
911_v4_00.bin

Firmware 1.07 for the 922 chipset:
922_v1_07.bin.zip

6 comments:

Skymuse said...

Thank you SO much for this! I have also been pulling my hair out trying to get my identical drives to read simultaneously, and all the other 'fixes' I have found have not worked.

Yours is the best and most reliable source on this subject. Thanks and Congratulations!

John Armstead said...

Aric, many thanks for your detailed and useful description. I have wasted hours trying to fix the problem when daisy chaining devices. After many hours of frustration and reading that everyone is having similar problem, you have shed the light and solution for Oxford chips. However no one has developed a generic Java script program for all makers and brands of chipsets.

Why don't the manufactures change the ID numbers at the point of assembly? The chances we would buy the an identical ID second or third drives etc, would be extremely remote. Nothing has changed or improved in the last 2 years.

Thanks again for shedding the light and solutions.

John Armstead Australia

John Armstead said...

I have found the solution.

CoolerMaster external hard drive enclosures have chipsets with their own unique address. So there is no problems daisy chaining as many drives as you want.

Unknown said...

The structure of Firewire (IEEE1394) addresses is defined in IEEE1212, but mores the pity, IEEE standards documents are held behind a firewall and copies are purchased by implementors ... but trawling thru some suitable code (search the OpenSolaris codebase for IEEE1394, eg. http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/1394/s1394_hotplug.c), leads to a number of interesting refs.

Anyway, there is a discussion document regarding firewire bus binding at http://playground.sun.com/1275/proposals/Closed/Accepted/435-it.txt, which covers the address composition.

Looks like modifying the LO segment of the GUID will suffice, the outcome will be sufficient to differentiate the devices.

HTH

Craig

pdef1949 said...

I am having trouble getting Western Digital HDDs connewcted via Oxf911 chipsets and 1394 ports. While the devices are recognized in Device Manager, the drives will not start. The Vista troubleshooting features tell me the driver software is loaded but encounters a problem when trying to run.

I have also tried to get the 911 updater software to run, but when I start it I get a message that no 1394 host card can be found. I tried several versions of the software but my two 911 chipsets are not detected.

I am running Vista Hpnme Premium 64bit with SP1 on an HP Pavilion a6700f with an AMD Phenom X4 processor and 4 GBG of Ram. Two 1394 ports are integrated into the motherboard, and I have a generic VIA PCI 1394 card as well. Both devices show up in Device Manager and operate correctly. I am running a dvd drive off one 911 board thorugh the PCI card and it works perfectly.

Anybody have any ideas?

Shiwani said...

This one of the best post read by me today and by the way thanks a lot for your informative post.
For more details, Please visit our website @ http://www.rvwireteknologies.com/