Specifications

TURBOchannel Bus Support
12.2 TURBOchannel on DEC 3000 Model 500
12.2.3.2 Mailbox Register Access on DEC 3000 Model 500 TURBOchannel
DEC 3000 Model 500 does not implement hardware mailboxes as described
in the Alpha SRM. However, OpenVMS AXP still provides the CRAM data
structures and CRAM routines for I/O register access on DEC 3000 Model 500
TURBOchannel. Basically, IOC$CRAM_CMD is used to specify the transaction
type and length, and then the IOC$CRAM_IO routine issues the appropriate load
or store instruction based on the command field in the CRAM. There is no MBPR,
the mailbox is not actually queued to an I/O bridge, and there is no need to wait
for the DONE bit. The actual access is accomplished by a load or a store directed
to an address in the processors’ virtual address space, exactly as in direct access.
On DEC 3000 Model 500, IOC$CRAM_QUEUE simply calls IOC$CRAM_IO, and
IOC$CRAM_WAIT simply returns SS$_NORMAL.
For I/O register access, the OpenVMS/AXP CRAM routines expect the option
registers to be mapped into sparse space. Sparse space was chosen as the design
center for IOC$CRAM_CMD on DEC 3000 Model 500/TURBOchannel because
it allows byte write granularity and avoids dense space side effects. Before
performing any kind of register access on DEC 3000 Model 500 TURBOchannel,
the option registers must be mapped into the processors’ virtual address space.
Thus the driver must be told the base physical address of the TURBOchannel slot
into which its option is installed. When a driver is loaded using the SYSMAN
IO CONNECT command, the value specified as the "csr" parameter is copied to
the IDB$Q_CSR field in the IDB. For the TURBOchannel, the csr parameter
should be specified as the TURBOchannel slot base physical address of the
TURBOchannel option. For mailbox register access on DEC 3000 Model 500
TURBOchannel, the csr parameter should be the sparse space base slot physical
address (which is displayed in the SYSMAN IO SHOW BUS command). Then
in the driver controller init routine, the driver should map its option registers
into sparse space and copy the base virtual address of the option registers back
into the IDB$Q_CSR field. The IDB$Q_CSR field is used by IOC$CRAM_CMD as
the base address of the option registers. A driver can call IOC$MAP_IO to map
registers as described previously. For more information about IOC$MAP_IO, see
Appendix A.
IOC$CRAM_CMD and IOC$CRAM_IO on DEC 3000 Model 500 have been
designed together to accomplish register access in sparse space. IOC$CRAM_
CMD initializes the COMMAND, MASK, and RBADR fields based on the
command_index and byte_offset input parameters. IOC$CRAM_IO interprets the
COMMAND field and generates the proper instruction (LDL, STL, or STQ) to the
address in the RBADR field. The RBADR field in the CRAM is initialized using
the byte offset parameter and the IDB$Q_CSR field in the IDB. The byte offset is
longword aligned, multiplied by 2 to account for sparse space mapping, and added
to the IDB$Q_CSR field. The resulting address is stored in the RBADR field of
the CRAM.
The COMMAND field in the CRAM is derived from the command index
parameter. All quadword length command indices are rejected, as the
TURBOchannel does not support quadword I/O transactions. If the caller
specifies a read transaction (one of cramcmd$k_rdlong32/64, cramcmd$k_
rdword32/64, or cramcmd$k_rdbyte32/64), the command index is converted to
cramcmd$k_rdlong32 and stored in the COMMAND field in the CRAM, so that
IOC$CRAM_IO will issue a LDL instruction for all TURBOchannel I/O reads. If
the caller specifies a byte or word length write (one of cramcmd$k_wtbyte32/64 or
cramcmd$k_wtword32/64), IOC$CRAM_CMD must also generate the proper byte
mask. The byte mask is generated using the command index to determine the
transaction length (byte or word), and the byte offset parameter to determine the
12–6