On Thu, 15 Jul 1999, Grant Stockly wrote:

> Is there a way to find the base address of a SCSI controller by using the
> MacToolbox?
> 
> When sending or receiving SCSI data from MacToolbox, can you accomplish low
> level access?

Uhm, why are you asking about the MacToolbox if you're writing a NetBSD
driver?

> Is there a list somewhere that lists all ppc machines, the SCSI controller
> used, and the base addresses it resides at?
> 
> I'm building the beginning of a NetBSD driver and have started to collect
> information about all NetBSD compatible computers that have SCSI ports.

What exactly are you trying to do? A NetBSD driver to do what?

> I'll have to look at the scsi source in the kernel to see if I need to
> issue low level SCSI commands.  Some newer cards don't like doing that.  If
> the card is NCR 5380 compatible, then it will support Target mode (the mode
> required by the serial port controller).

Ahhh. You want to communicate with a serial port controller...


> This code will open a 'connection' with the NCR5380 on 68k macs with A0
> being the base address, D1 containing the ID of the serial device, and DO
> containing the exit status.
> 
> I'd like to do this on ppc macs too.

This is not a path you want to go down. NetBSD has worked hard on sticking
in levels of abstraction to make things cleaner. If you try to fight that,
you'll get resistance. Which'd be a shame as it really doesn't seem like
you need to do the things which will generate the resistance. :-)

I missed the first part of your thread (mass mailings get deleted really
quick).

From this message, I gather you're writing a driver to talk to a serial
port device which hooks to a SCSI bus. The rest of this mesage is based on
that assumption.

Does this device follow the SCSI standard? i.e. you feed it standard SCSI
commands to which it replies in a standard way? If yes, life's easy. If
no, you're SOL.

If it follows the standard, forget about talking to the hardware directly.
You don't need to. Just make your driver a scsi device driver, and it'll
be able to feed SCSI commands to the SCSI bus. Then you won't have to
worry about where this chip is or what kind of chip that machine has -
it'll just work.

I'd suggest you look at both the se and uk drivers. The se is SCSI
Ethernet - a prime example of a driver making a scsi device look like
something other than mass storage (i.e. an ethernet driver).

Also look at the uk driver. It's the "unknown" driver, for unknown SCSI
devices. It will let you generate scsi commands from userspace, and it
should be matching your device now (if it's config'd in your kernel). It
will let you focus on figuring out how to talk to your device from
userland. Then once you have things figured out, you can work on making a
kernel driver. It should save you a lot of time & effort.

Take care,

Bill