Writing Privileged Software under MicroVMS for MicroVAX I Systems o Hardware differences between VAX and MicroVAX I systems o Converting UNIBUS drivers to QBUS drivers o Other privileged (non-user mode) code Hardware Differences Between VAX and MicroVAX I Systems MicroVAX I: cpu and memory are plugged into QBUS (i.e., QBUS is the backplane) VAX: cpu, memory, and buses plug into backplane Block Diagram of Typical VAX System +---------+ +----------+ +-------+ | | | | | | +------------+ +---------+ | | | | | |---| CONTROLLER |---| DRIVE | | CPU | | MEMORY | | BUS | +------------+ +---------+ | | | | | | | | | | | | +---------+ +----------+ +-------+ | | | +----------------------------------------------------------------+ | BACKPLANE | +----------------------------------------------------------------+ Block Diagram of MicroVAX I System +---------+ +----------+ +------------+ | | | | | | +-------------+ | | | | | |---| DRIVE | | CPU | | MEMORY | | CONTROLLER | +-------------+ | | | | | | | | | | | | +---------+ +----------+ +------------+ | | | +----------------------------------------------------------------+ | QBUS | +----------------------------------------------------------------+ Hardware Differences, cont. o QBUS vs UNIBUS differences (DMA devices only) MicroVAX I QBUS: No adapter or adapter CSRs No scatter-gather map No buffered data path No odd-byte aligned buffer support 22-bit physical addresses VAX UNIBUS: Standard adapter CSRs Scatter-gather map Buffered data path (except on 11/730) Odd-byte aligned buffer support 18-bit physical addresses Hardware Differences, cont. Summary: Non-DMA devices: No differences for non-DMA devices, provided UNIBUS and QBUS versions of controllers are compatible (e.g., DZ11 and DZV11). DMA devices: No scatter-gather map means: MicroVAX I QBUS does not support DMA transfers into non-contiguous physical pages of memory. No odd-byte alignment support means: Buffers for DMA transfers must be aligned on a word boundary. User Buffer in Virtual and Physical Memory USER VA SPACE PHYSICAL (MAIN) MEMORY +------------+ +------------------------+ 0 | | | 1 | 2 | 3 |... | | +------------+ +------------------------+ 200 | | | | | | | | +------------+ +------------------------+ 400 | | +-------------------|--->|130 | | | | +------------+ | +------------------------+ 600 | | | | | | | | | +------------+ | +------------------------+ 800 |XXXXXXXXXXXX|----------+ | | | | | | +------------+ +------------------------+ A00 |XXXXXXXXXXXX|------------------------------|----|--->|220 | | | +------------+ +------------------------+ C00 | | | | | | | | +------------+ +------------------------+ Virtual addresses: 800-BFF (pages 4 and 5), virtually contiguous. Physical addresses: 26000-261FF (page 130) and 44000-441FF (page 220), physically discontiguous. Hardware Differences, cont. Scatter-gather map is used by controllers to translate virtual addresses into physical addresses, just as page tables are used by the cpu to translate virtual addresses into physical addresses. Converting UNIBUS Drivers to QBUS Drivers o 3 solutions to lack of a scatter-gather map problem 1) Build smart hardware controller that takes address of pseudo scatter-gather map 2) Buffer transfers through a physically-contiguous memory buffer 3) Segment transfers at physically-discontiguous page boundaries Converting drivers, cont. Solution 1: Pass pseudo map address to smart controller. o Allocate pseudo map from main memory and page for odd-byte aligned transfer buffer (driver INIT routine). o Provide physical address of map with each I/O request (New field in port-specific part of MSCP command packet). o Use standard VMS allocate/deallocate map routines. o Example: RQDX controller (PUDRIVER). Converting drivers, cont. Solution 2: Buffer transfers through physically-contiguous memory buffer. o Allocate physically-contiguous buffer from main memory (driver INIT routine). o Write I/O: Move user data to buffer before starting transfer. Read I/O: Move user data from buffer after transfer completes. o Do not allocate/deallocate map. o Example: DEQNA controller (XQDRIVER). Converting drivers, cont. Solution 3: Segment transfers at physically-discontiguous page boundaries. o Request first segment of transfer, i.e., up to the first physically-discontiguous page of user data (Start I/O routine). o Compute next segment when transfer of first part completes (Interrupt service routine). o Do not allocate/deallocate map. o Example: DHV11 controller (YFDRIVER). Converting drivers, cont. Pros and cons of the three solutions: Solution 1: Pseudo scatter-gather map. Useful if building own hardware. Solution 2: Buffer into physically-contiguous buffer. Use for high speed, block-structured devices, like disks. Solution 3: Segment transfers at physically-discontiguous pages. Use for DMA communications devices. Converting drivers, cont. Other DMA driver changes needed: o Do not allocate/deallocate a buffered data path. o Call IOC$PURGDATAP to check for memory errors after transfer completes (same as 11/730). o If device does word DMA transfers (RQDX), then have to buffer odd-byte aligned transfers. (Devices that do byte DMA transfers (DHV11) do not need this change.) o Load 22 bits of physical address instead of 18 bits. Converting drivers, cont. Miscellaneous information: o SYSGEN does not differentiate between UNIBUS and QBUS (CONNECT command uses UB0 not QB0). o CSR's and vectors are same on UNIBUS and QBUS. o High priority devices must be closest to cpu, because all device interrupts occur at same IPL. o Reference material: MicroVAX Handbook, Order # EB-25156-47. Converting drivers, cont. Useful VMS subroutines: o EXE$ALOPHYCNTG - allocates physically-contiguous pages of memory and maps them into system space. o IOC$MOVTOUSER - moves data from physically-contiguous buffer to user buffer. (MOVC3 will not work as code is not in the process' context.) o IOC$PURGDATAP - scans memory controller CSRs for parity error that might have occurred during DMA transfer. Other Privileged Code, cont. Differences in Internal Processor Registers: Clocks/timers: No ICR, NICR, TODR. Other: No ACCS, PME. Kernel-mode code changes: o For timeouts, use new TIMEDWAIT macro. o For system time, use new cpu-dependent routines, EXE$READ_TODR, EXE$WRITE_TODR, etc. o Eliminate use of ACCS and PME. o All cpu-dependent IPR definitions have been moved from $PRDEF to new cpu-dependent macros, $PR780DEF, $PR750DEF, $PRUV1DEF, etc.