<<< EVMS::DOCD$:[NOTES$LIBRARY]SCSI_ARCHITECTURE.NOTE;1 >>> -< SCSI ARCHITECTURE >- ================================================================================ Note 39.2 Discussion topic: initialization 2 of 2 EVMS::GWANG 163 lines 25-OCT-1995 15:24:47.34 -< Current SCSI Subsystem Initialization Scheme >- -------------------------------------------------------------------------------- Item #10 is broken into two questions: (1) How should VMS locate port drivers? This question should be How *does* VMS locate port driver for loading? This change claims that there is no plan to alter the current Alpha OpenVMS system initialization scheme. (2) How should VMS initialize SCSI subsystems? ============================================================================= Investigation result: (1) In system initialization, I examined all three instances when a SCSI port driver is loaded with CALLS #5, SYS$LOAD_DRIVER. The stages of system initialization is shown 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 near the end of EXEC_INIT execution. Generally, there is a runtime driver associates with a boot driver required for a specific boot adapter. Each runtime driver is specified in CNBTDRIVER, and is found again by IOC$FIND_RUNTIME_DRIVER, in module [SYS]INIT_IO_DB, when EXE$INIT loads driver executive image of each device in I/O vector(IOVEC) list and creates the I/O database data structure. For each boot driver located in the IOVEC, the queue of boot adapters is walked to locate each of the runtime adapter structures (see G^IOC$FIND_BOOT_ADP). Uses Boot_Bus_Array, Boot_ADP and the ADP Config Table, IOC$FIND_RUNTIME_DRIVER finds the name of the runtime driver again just before loading the system device driver calling SYS$LOAD_DRIVER. *** note *** IOC$FIND_RUNTIME_DRIVER was added to work around a CNBTDRIVER bug before the bug was fixed in 12/94. It was left in there without known reason. Could be the driver name in the descriptor pointed to by CDRVR_DESC_ADDRESS incorrect due to other broken algorithm in CNBTDRIVER in 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 runs VMS$DEVICE_STARTUP.COM to execute SYS$MANAGER:SYCONFIG.COM to run the SYSMAN untility which configures 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. I will try to describe the process more in the rest of this section. For details, the best documentation is Richard Critz's Autoconfiguration Master Plan. 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.). Each of these bus configuration modules may exist in multiple 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. SYS$LOAD_DRIVER is called for every driver, port or class. By walking through routine IOGEN$TURBO_CONFIG below, we can see how a Turbochannel is configured, or more specifically, how SCSI drivers are located during AUTOCONFIGURATION. 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) by calling 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. How is device driver identificaiton and loading handled 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 routine [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. IOGEN$SCSI_CONFIG is responsible for configuring all supported devices on the 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. (2) After a SCSI port driver is located, configuration of the port follows. As stated above, there are instances prior to STARTUP time that a SCSI device may be configured. Whenever it is, the configuration of ports or devices is done by SYS$LOAD_DRIVER (IOGEN$CONNECT,..) which in term calls the following routines: IOGEN$LOAD IOGEN$CONNECT IOGEN$INIT_DB IOGEN$INIT_MAPPING IOGEN$INIT_CONTROLLER IOGEN$INIT_UNIT Note that EXEC_INIT will call [SYS]IOSUBNPAG/EXE$INIT_DEVICE_PWRUP to init all controllers and units of loaded drivers (both class and port drivers) at their unit and controller initialization routines once more via CALLS #2,G^IOC$CTRL_INIT and CALLS #1,G^IOC$UNIT_INIT. If one wish to make minor changes in SCSI subsystem's initialization without alter the general scheme, say to send SDTR message to a SCSI adapter or to capture certain INQUIRY data, at (a) EXEC_INIT time, addition of QIO issuer routine inside runtime driver is required. However, forcing application code into driver code is not desirable at all. (b) SYSINIT time, both [CLUSTER]STACONFIG and [SCSI]SCSI2AUTO need 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. (c) STARTUP time, the INQUIRY command is issued by IOGEN$SCSI_CONFIG routine to a SCSI port before any SCSI device is configured (see (1)(c) above.) Since INQUIRY $QIOW is issued internally, any change to INQUIRY processing means change in IOGEN$SCSI_CONFIG. However, this routine be used by any BSR to configure the devices accessible through a specific SCSI port once that port has been configured. This suggests that a system utility/process may be added to run immediately after the AUTOCONFIGURATION to obtain necessary INQUIRY or SDTR info.