Non-OBP card in a SPARC machine

Question

I'm working on a Solaris driver for the Adaptec AHA-2940U2W scsi card.
But, I've got a question that I can't seem to answer.
The PCI vid & devid are: 0x9005 and 0x0010, respectively. When I plug this card into my Ultra 10 here is what I get from 'prtconf -pv'
            Node 0xf0095f5c
                assigned-addresses:  81021810.00000000.00002000.00000000.00000100.83021814.00000000.02900000.00000000.00001000
                power-consumption:  00000000.007270e0
                reg:  00021800.00000000.00000000.00000000.00000000.01021810.00000000.00000000.00000000.00000100.03021814.00000000.00000000.00000000.00001000
                compatible: 'pci9005,a180' + 'pci9005,10' + 'pciclass,010000'
                name:  'scsi'
                fast-back-to-back:
                devsel-speed:  00000001
                class-code:  00010000
                interrupts:  00000001
                max-latency:  00000019
                min-grant:  00000027
                subsystem-vendor-id:  00009005
                subsystem-id:  0000a180
                revision-id:  00000000
                device-id:  00000010
                vendor-id:  00009005I can't figure out why it the device tree is picking this device up as 'scsi' and not something like 'pci9005,0010'..
Is there a way to make it appear in the devinfo tree as something else?
Thanks.
-brad walker

Answer 1

Martin_Rosenau wrote:
But, if I put the following into my /etc/driver_aliases file, the system should look for a driver called "shim" to bind to this device, correct?
shim "pci9005,10"Did you add your driver using add_drv? If you do not add your driver using add_drv the system will not load it even if it is mentioned in the driver_aliases file.
Does prtconf say that the device is handled by a driver or that a driver is not assigned?prtconf says this:
scsi (driver not attached)
I guess what I'm really asking is why doesn't prtconf show the name as "pci9005,10" or the VID,PID.. Why does it show as the class name?
Brad_Walker wrote:
Btw: (For other people reading this thread): It will not be possible to boot from disks attached to the controller.Unless, I write an HBA driver for this device, correct? Not that implying this is what I am doing, just trying to be semantically correct.Booting from a disk is done before the operating system and the drivers are loaded. So if you'd like to boot from a disk attached to a controller not supported by OpenBoot you had to modify the OpenBoot code stored on the OPB chip.
Agreed.. Now I see what you were referring to.
Thanks for all help. It has been enlightening.
-brad w.