From: EVMS::GWANG "GRACE WANG --- DTN 381 - 1869" 16-OCT-1995 14:46:48.60 To: STAR::EVERHART CC: Subj: architecture notes on SCSI init Subjet: (1) How should VMS locate port drivers? The question is changed to "How *does* VMS locate port driver for loading?"; we don't plan to alter the current OpenVMS system initialization scheme. (2) How should VMS initialize SCSI subsystems? ============================================================================= (1) In system initialization, I examined three occasions that a SCSI port driver is loaded with CALLS #5, SYS$LOAD_DRIVER. The stages of system initialization is included below for refernece. image stages: console ---> APB---> SYSBOOT---> SYSBOOT---> EXE$INIT software process stages: ---> Swapper---> SYSINIT---> Startup process process process (a) In EXEC_INIT image: When the boot device is a SCSI device, its runtime driver is to be loaded. Generally, a runtime driver is located twice - specified in CNBTDRIVER, and get again in [SYS]INIT_IO_DB/IOC$FIND_RUNTIME_DRIVER. EXE$INIT calls [SYS]INIT_IO_DB to load driver executive image of each device in IOVEC list and creates the I/O database data structure. This runtime driver associates with each of the boot drivers required for a specific boot adapter. For each boot driver located in the I/O vector (IOVEC), the queue of boot adapters is walked to locate (G^IOC$FIND_BOOT_ADP) each of the runtime adapter structures. Routine [SYS]IOC$FIND_RUNTIME_DRIVER uses the Boot_Bus_Array and Boot_ADP and the ADP Config Table to find the name of the runtime driver again just before loading the system device driver. *** note *** IOC$FIND_RUNTIME_DRIVER was added to work around CNBTDRIVER's bug before it was fixed in 12/94. IOC$FIND_RUNTIME_DRIVER is left in; maybe the driver name in the descriptor pointed to by CDRVR_DESC_ADDRESS can be incorrect due to other possible broken algorithm in CNBTDRIVER for selecting the system device driver name? (b) SYSINIT creates STACONFIG when a node plans to join a VMScluster boot. STACONFIG calls IOGEN$AUTOCONFIGURE. (see (c)) (c) STARTUP process' VMS$DEVICE_STARTUP.COM executes SYS$MANAGER:SYCONFIG.COM which runs the SYSMAN untility to configure external IO devices by calling IOGEN$AUTOCONFIGURE. Briefly, "IOGEN$AUTOCONFIGURE is called to allocates space for the ACDB, initializes it, activates ICBMs, parses the select and exclude lists/flags and then walks the ADP list to cause system autoconfig to occur." Shown below is its formal parameters. For details, the best documentation is Richard Critz's Autoconfiguration Master Plan. flags - control optional behavior in IOGEN$AUTOCONFIGURE prefix_list - list of ICBM filename prefixes select_list - list of (potentially) wildcarded devices to configure exclude_list - list of (potentially) wildcarded devices to exclude bus_list - list of ADP/bus types to include log_callback - routine to process log messages exclude_callback- routine to read permanent exclusion list if the default routine will fail (e.g., during STACONFIG) During AUTOCONFIG, all hardware attached to a system are identified and configured. For each system/platform, there exists a configuration routine (eg SYS$ICBM_07 is for Pelican Autoconfig) and a ABM (Autoconfigure Bus Mapping Table) to list a set of bus and/or device configuration modules (eg. IOGEN$TURBO_CONFIG, IOGEN$XMI_CONFIG, IOGEN$PCI_CONFIG, IOGEN$XMI_CONFIG, ..etc.). Since we are interested in SCSI devices only, I noticed that IOGEN$SCSI_CONFIG is called by various bus configuration modules that each one can exist in many system configuration routines. For example, IOGEN$PCI_CONFIG is listed in the ABMs of SYS$ICBM_09, SYS$ICBM_0C, SYS$ICBM_0D, SYS$ICBM_0F, SYS$ICBM_11, SYS$ICBM_14, and SYS$ICBM_15. To do bus configuration, its Bus Array (adp$ps_bus_array) is walked to attempt to configure bus devices. I looked up IOGEN$TURBO_CONFIG and here is its process description lifted from code comments. "The Turbochannel ADP Bus Array contains an entry for every TC device in the system. For Flamingo, this includes a maximum of 6 user TC option slots and 3 integrated TC options (integrated SCSI asic, Core I/O, and CXTurbo graphics). Sandpiper and other Turbochannel systems may have a different mix of option slots and integrated options. Devices in the user slots are generally single channel adapters, and usually share the Turbochannel ADP. On Flamingo, the integrated SCSI asic and Core I/O have their own ADPs and bus arrays. As we go through the Turbo Bus Array, we use the Iogen Config Table (connected to the Turbo ADP) via call to iogen$find_config_table_entry (.hardware_id, .turbo_config_table, config_table_entry) to determine if 1) we recognize this device and 2) to identify its driver. We then determine whether the device has its own ADP or not. If the device shares the Turbo ADP, we load a single instance of its driver. If the device has its own ADP and bus array, we load an instance of the driver for each entry in the device bus array." Device driver identificaiton and loading is done in bus-specific routine CONNECT_%%_DRIVER using information in an IOGEN Configuration Table. This routine connects a specific driver, in SCSI case this is the port driver, "by finding the interrupt vectors associated with the device, allocating vectors if necessary, building the item list associated with the connect operation, and calling [IOGEN]LOAD_DRIVER/SYS$LOAD_DRIVER to perform the actual operation. If the SCSI flag is set for the driver just loaded, it means the driver being loaded is a SCSI port driver, and then the SCSI autoconfiguration routine IOGEN$SCSI_CONFIG" is to be called to load its class drivers. (2) After a SCSI port driver is located, the next step is to configure the port. There are two situations that the configuration of SCSI devices is done earlier than STARTUP time: when device is the boot device (EXEC_INIT), or device is in a VMScluster or a SCSIcluster (SYSINIT). But, of all three situations, the configuration of port or devices is done by routine SYS$LOAD_DRIVER (IOGEN$CONNECT,...) which in term executes the following routines in order. IOGEN$LOAD IOGEN$CONNECT IOGEN$INIT_DB IOGEN$INIT_MAPPING IOGEN$INIT_CONTROLLER IOGEN$INIT_UNIT But at EXEC_INIT time, [SYS]IOSUBNPAG/EXE$INIT_DEVICE_PWRUP is called ??? to call device drivers (both class and port drivers) at their unit and controller initialization routines via CALLS #2,G^IOC$CTRL_INIT and CALLS #1,G^IOC$UNIT_INIT. To not alter the current VMS initialization scheme, but making minor enhancements to SCSI subsystem's initialization, for example to send SDTR message to a SCSI adapter or to capture certain INQUIRY data in database, at EXEC_INIT time: there is no way to issue $QIOW to request SCSI command through the port driver because no process exists to do so. at SYSINIT time: both [CLUSTER]STACONFIG and [SCSI]SCSI2AUTO are to be altered. Currently, STACONFIG uses $QIOW_S to request INQUIRY through SCSI2AUTO. It should be easy to expand these modules to add the SDTR message handler. at STARTUP time: the INQUIRY command is handled in IOGEN$SCSI_CONFIG routine to the port directly before any SCSI device is configured. "This routine is responsible for autoconfiguring all supported devices on a SCSI bus. If there is no bus array associated with the SCSI port's CRB, it allocates and initializes one. It then makes a working copy of this bus array on the stack so that it doesn't have to bounce back and forth between exec and kernel modes. It makes two passes over this copy of the busarry. The first is to poll the unidentified SCSI bus id's to find what is there (via INQUIRY). The second is to configure those devices found in the first pass which are supported by default." Since INQUIRY $QIOW is issued inside IOGEN$SCSI_CONFIG, any modification to INQUIRY processing means change in IOGEN$SCSI_CONFIG. However, this routine "can be used by any BSR to configure the devices accessible through a specific SCSI port once that port has been configured." This suggests a new system utility can run immediately after the AUTOCONFIGURATION to obtain necessary INQUIRY or SDTR info.