Hi all,
I finally decided to get one of these and I finally got it working.

I had no end of trouble getting this to work, but the resolution to my
problems was completely trivial. 

My first problem was that the card was listed as a 'raid' device in
the OF device tree rather than 'ide'. There were no disks listed as
children of the controller and no way to boot. After checking that I
really did have a PCI IDE controller, I shrugged my shoulders and
figured that the builtin drivers were just assuming that any version
of CMD chip more advanced than the one on the motherboard must be
RAID. I used my cunning bit of FCode to fool the builtin drivers into
thinking it was an IDE controller. So far so good. OF loaded the
NetBSD kernel just fine.

Now the kernel couldn't find the boot device. It would always ask
where the root device was, and I would have to type in "wd0". Hmm, not
so hot. After quite a bit of digging, I found that
autoconf.c:dev_compatible() didn't seem to be picking the ide node as
IDE mass storage. The PCI card has a device class of 1040002 which is
01 for mass storage and 04 for RAID. D'oh. That's where the original
OF 'raid' node had come from, and the kernel isn't about to try and
match up an ide boot path entry with a RAID device. 

I altered dev_compatible() so that it would match RAID devices from
CMDTECH as well as IDE devices and while building the new kernel I
started looking through the 649 specification. You know, the low level
one that talks about pinouts and registers. Some PCI devices have the
ability to have their ID info reprogrammed, usually accompanied by
dire warnings in the manual about the consequences of doing so. I
figured that fixing the problem at the source would be best.

At the top of page 3-1 of the spec is the definition of pin JP0. The
JPx pins are there to allow the bootstrap properties of the chip to be
set via jumpers. JP0 controls whether or not the chip gives itself a
subclass code of 01 (for IDE) or 04 (for RAID). WTF. You mean I don't
even have reprogram a bit of EEPROM with mystical incantations?

I pulled the board out of the Ultra 10 and found that the jumpers were
in fact a bunch of wire links soldered in place. That explains why
they weren't mentioned in the user manual (such as it was). 5 seconds
with a pair of transistor nippers and JP0 was no longer pulled low.

I slapped the board back in the Ultra 10 and it all worked. I removed
all by NVRAMRC jiggery pokery and it still all worked. I booted an old
kernel with my autoconf changes and it still all worked. Woohoo.

I can heartily recommend the CMD 649. Unlike the Promise controller,
it doesn't interfere with the SCSI and USB cards that I have in the
same PCI bus. 

Now I'm off to see if 'device registration' is documented in the sparc
port. It sure isn't documented in the sparc64 port.

Cheers,
Lloyd