On Sat, 21 Oct 2000, Michael Wolfson wrote:


{ sorry for the delay - was travelling }
> 
> Here's the rewritten section on boot ROMs and SCSI.  Comments?
> 
>   -- MW
> 
>      The OBP1 machines (SPARCstation/server 1, SPARCstation/server 1+, IPC,
>      and SLC) have an odd SCSI quirk you should be aware of.  There are three
>      SCSI addressing schemes used by your system: SCSI ID (set by physical
>      jumpers on the device), SCSI target (set by OBP1, based on its SCSI ID),

Prom 'unit' number in this case. A SCSI Target ID is a SCSI Target ID is a
SCSI Target ID. The whole problem here is a mismatch between the 'unit' number
as understood by the PROM and whether this matches the 'unit' number used by
the Operating System (any operating system).

This is not restricted to OBP1- it just takes a different form.

>      and the name you reference within an operating system (set by the kernel,
>      based on the SCSI target).
> 
>      Sun shipped these systems with the internal drive at SCSI ID 0.  The de-

No- they had the internal drives strapped to 3 and 1.

>      fault value of the OBP variable `sd-targets' is 31204567.  The means that
>      the device at SCSI ID 3 is at SCSI target 0, and the SCSI device at ID 0
>      is at target 3.  When you type ``boot scsi(0,0,0)'', OBP will boot from
>      target 0 (that is, SCSI ID 3).  The SunOS kernel is hard-wired to map sd0

Close! If you said:

      fault value of the OBP variable `sd-targets' is 31204567.  The means that
      the device at SCSI ID 3 is at considered 'unit' 0, and the SCSI device
      at ID 0 is considered 'unit' 3.  When you type ``boot scsi(0,0,0)'', OBP
      will boot from 'unit' 0 (and select SCSI Target ID 3 as the real device
      address).

>      to SCSI target 3, and sd3 to SCSI target 0.  This means that SCSI ID 0
>      (target 3) is sd0, SCSI ID 1 (target 1) is sd1, and so on.  Essentially,
>      SunOS reverses the OBP target remapping.

No- Default SunOS matches the PROM unit mapping (the original notion was to
simply match the sd-targets index). So this:

>            SCSI ID    SCSI Target    SunOS name

Should be

 
>           Prom Unit#  SCSI Target    SunOS name
>               0          3              sd0
>               1          1              sd1
>               2          2              sd2
>               3          0              sd3
>               4          4              st0
>               5          5              st1
>               6          6              cdrom
> 
>      The NetBSD kernel is not hard-wired in this manner and names the disks in

Better stated as:

      The NetBSD GENERIC sparc kernel does not by default wire things down in
      this manner and names the disks in

>      the order that the targets are probed (01234567).  If you only have one
>      disk, it is always sd0 irregardless of its SCSI ID or target, and there
>      are no problems.  If you have two disks, one at SCSI ID 2 (target 2) and
>      SCSI ID 3 (target 0), then they are recognized as sd1 and sd0 respective-
>      ly.  This can be a problem if you are not aware of it, particularly when
>      creating an fstab.
> 
>      There are two approaches to fixing this problem: changing OBP1, and

change to:

      There are two approaches to fixing this problem: changing the
      mapping that OBP1 does , and

>      changing the NetBSD kernel.  To get OBP1 to number the SCSI targets the
>      same as the SCSI IDs, you need to run this command:
>            ok setenv sd-targets 01234567
>      This may, however, cause problems if you were to later attempt to use
>      SunOS on this machine or if you reset the OBP variables.
> 
>      The other approach is to use a NetBSD kernel that reverses this odd tar-
>      get mapping by treating target 0 (i.e. SCSI ID 3) as sd3 and target 3
>      (i.e. SCSI ID 0) as sd0.  The GENERIC_SCSI3 kernel performs this target
>      remapping, but the GENERIC and INSTALL kernels do not.
> 
>      Note:  This is also a concern when you start building your own customised
>             kernels.
> 
>      The sun4 models and the machines with OBP2 (SPARCstation/server 2, ELC,
>      IPX, and all sun4m models) do not have this target mapping problem.  You
>      should be aware, however, that some models have their internal hard
>      drives fixed at SCSI ID 3, so it may still be advantageous to use the
>      GENERIC_SCSI3 kernel to ensure that your internal drive shows up as sd0.


Uh, it's the same problem on an SS2 with OBP2. Instead of indexing into
sd-targets to get a 'unit #'<>SCSI Target ID map, the default device alias
naming is (something like):

	disk0 /devices/sbus/esp/sd@3,0
	disk1 /devices/sbus/esp/sd@1,0
	disk2 /devices/sbus/esp/sd@2,0
	disk3 /devices/sbus/esp/sd@0,0

You can also change this with the devalias PROM command- but the same issues
you mentioned above still also apply.


Good job, though! And thanks very much for writing this up!

-matt