Hardware Platforms

Hardware Platforms

Each basic hardware design results in differences in the operating system kernel such that a driver must be compiled for each architecture. Because there is some duplication of CPUs across hardware architectures, Table 1-1 may be useful.

Hardware Series and the CPUs They Use
Product Family CPU R2000 R3000 R4000 R8000
POWER CHALLENGE/POWER Onyx POWER Indigo2 Series IP21
IP26 X
CHALLENGE/Onyx Series IP19 X
Crimson Series IP17 X
Indigo Series IP12
IP20
IP22 X

X
X
Indigo2 Series IP22 X
Indy Series IP22 X
IRIS-4D(TM)/20/30/100/200/300/400 Series IP4
IP5
IP6
IP7
IP9
IP11
IP12
IP15 X
X
X
X
X

X
X
X

Hardware Series and the CPUs They Use
Product Family	CPU	R2000	R3000	R4000	R8000
POWER CHALLENGE/POWER Onyx POWER Indigo2 Series	IP21 IP26				X
CHALLENGE/Onyx Series	IP19			X
Crimson Series	IP17			X
Indigo Series	IP12 IP20 IP22		X	X X
Indigo2 Series	IP22			X
Indy Series	IP22			X
IRIS-4D(TM)/20/30/100/200/300/400 Series	IP4 IP5 IP6 IP7 IP9 IP11 IP12 IP15	X X X X X	X X X

For purposes of writing device drivers, however, all R4000-series processors may be considered identical, although their clock speeds and performance characteristics may vary. That is, source code can be the same if interfaces are followed carefully. For further details, see "CPU Types" in Appendix A MIPS RISC Processors

All MIPS 32-bit and 64-bit RISC processors have an on-chip memory management unit (MMU) that supports demand-paged virtual memory. For detailed information on the MIPS architecture, see MIPS RISC Architecture.

MIPS RISC Processors Interrupt Masking

Each device interrupts the CPU at a specific interrupt priority level. While the CPU is serving an interrupt, it ignores any other interrupts at the same or lower interrupt level. To prevent device interrupts from occurring before your driver is ready for them, your driver can raise the processor interrupt level in the device driver at any time. After your driver executes the critical segment of code, it must restore the previous interrupt priority.

Note: Only kernel-level drivers can handle interrupts. Raising the interrupt level is usually not sufficient to prevent your driver from being interrupted on multiprocessing systems. (See "Reliable Multiprocessor Spinlocks" in Appendix A, "System-specific Issues.") Drivers on multiprocessing systems must use additional mechanisms, such as semaphores and spinlocks. (See psema(D3X) in the IRIX Device Driver Reference Pages.)

Understanding Driver Address Space

Drivers have different functional needs for addresses, including:

Mapping to (usually cached) physical memory for the driver's own code
Static and stack data
Dynamically allocated data
Mapping to I/O control registers (called Programmed I/O or PIO)
DMA address to map to physical memory for a controller to use

To describe kernel-resident driver address spaces, first recall the following points about the form of addresses in a user process:

The virtual address is either 32 or 64 bits.
The most significant bits are those in the virtual page number, which is translated to a physical page.
An invalid address causes the user process to get a SIGSEGV, which typically results in a core dump.

With respect to addresses in a kernel-resident driver:

The virtual address is either 32 or 64 bits.
A range of values, varying by processor type, called kseg0, translates 1:1 to physical addresses.
kseg0 is often used for kernel code and data, as well as for some PIOs.
A range of values, translated by the translation look-aside buffer (TLB), are often used for dynamically allocated kernel data.
A driver should not assume that it knows that one type or the other is in use.

A driver also has to manipulate DMA addresses. These address values cannot be used for driver (processor) load/store instructions; rather, they are for controller usage in DMA operations.

Caution: If a driver executes a load/store to an address that is not valid, data corruption may result, or the kernel may panic.

Virtual to Physical Memory Mapping

The R2000/3000 uses 4096-byte pages for virtual address mapping in the format shown in Figure 1-1. The most significant 20 bits of a 32-bit virtual address (the virtual page number, or VPN) allow mapping of 4 KB pages. The least significant 12 bits (offset within a page) are passed along unchanged. The three most significant bits of VPN (bits 31-29) further define how the addresses are mapped, according to whether the R2000/3000 processor is in user mode or kernel mode.

Note: For all device drivers, the R2000 and the R3000 processors are considered identical.

Figure 1-1 : MIPS 32-bit Virtual Address Format (MIPS II Mode) The Crimson, R4000 Indigo, Indigo2, and Indy series workstations use a MIPS R4000 series microprocessor in MIPS II mode (see Figure 1-1). R4000 MIPS II mode implements the same address map as R2000/3000. (See the MIPS R4000 User's Manual for further details.)

Figure 1-2 : MIPS 64-bit Virtual Address Format (MIPS III Mode) The CHALLENGE/Onyx series uses the R4400, which is functionally the same as the R4000 for driver purposes, and the POWER CHALLENGE/POWER Onyx series uses the R8000 processor. All MIPS processors use the same address mapping scheme in 32-bit mode; in 64-bit mode, they use R8000 (MIPS III) address mapping (see Figure 1-2).

Privilege States/Modes

The R2000/3000 provide two privilege modes:

Kernel: Analogous to the "supervisor" mode provided by other systems.
User: The mode in which the system executes non-supervisory programs.

The R4000/4200/4400/4600 provide three privilege modes:

Kernel: Full privilege state (same as the R2000/3000 kernel mode).
Supervisor: A state of lesser privilege than kernel mode. When executing in supervisor state, the system has access to the supervisor and user address space, but not the kernel address space. This mode is currently unused in IRIX.
User: The same as the R2000/3000 user mode.

The R8000 also provides three privilege modes:

Kernel: Full privilege state.
User 32-bit: The same as the R2000/3000/4000 user mode.
User 64-bit: R8000 64-bit user mode.

User Mode Virtual Addressing

In user mode, a 32-bit process has 2 GB of virtual address space, appearing to start at location zero. Therefore, all valid user-mode virtual addresses have the most significant bit cleared. If, when in user mode, your code tries to reference an address with the most significant bit set, it will generate an Address Error Exception. To help programmers detect a common error, page 0 is never mapped.

Kernel Mode Virtual Addressing

Because kernel virtual memory divides physical memory several different ways, you can control the use of data caches and Translation Look-aside Buffers (TLBs) by specifying ranges of virtual addresses with different attributes.

When the processor is operating in kernel mode, three distinct address spaces (in addition to kuseg) are simultaneously available:

kseg0

This virtual address range is cached but not mapped by the TLBs. This is the type of memory you get when you declare a global in your driver code. This memory goes through the data cache during read/write operations but is not mapped by the TLBs. It is easy to convert the kseg0 address to a physical address by using the masking address bits.

Note: Driver globals may not always reside in kseg0; with loadable drivers, they may live in kseg2.

kseg0 consists of 512 MB of cached, unmapped address space, starting at virtual address 0xa800000000000000.

When the most significant three bits of an address are "100," the virtual address space selected is the 512 MB of kernel physical space, kseg0. The R2000/3000 directly maps references within kseg0 onto the first 512 MB of physical address space. These references use cache memory, but they do not use TLB entries. Typically, the operating system uses this segment of memory for kernel-executable code and static kernel data.

kseg1

This virtual address range is neither cached nor mapped. Memory does not go through the data cache during read/write operations, nor are the addresses translated by the TLBs. This space is used for volatile memory.

kseg1 consists of 512 MB of uncacheable, unmapped virtual address space, starting at 0x9000000000000000.

When the most significant three bits of a virtual address are "101," the virtual address space selected is the 512 MB of kernel physical space, kseg1. The processor directly maps kseg1 onto the first 512 MB of physical space. The operating system typically uses kseg1 for I/O registers and ROM code.

kseg2

Although this virtual address range can be both cached and mapped by the TLBs, it is not physically contiguous. This is where automatic variables declared in your driver come from, and it is where calls such as kmem_alloc() get their memory.

Note: Use the PHYSCONTIG flag to request physically contiguous pages.

kseg2 consists of and address range of 1024 MB of cacheable, mapped virtual address space starting at 0xc000000000000000.

When the most significant two bits of the virtual address are "11," the virtual address space selected is the 1 GB of kernel virtual address, kseg2, which uses TLB entries to map virtual addresses to arbitrary physical ones, with or without caching. The operating system uses kseg2 for stacks and per-process data that it must trap on context switches, for user page tables (memory map), and for some dynamically allocated data areas.

kuseg

This user physical space has only physical pages, from the point of view of a device driver. In kernel mode, access generates a bus error.

Kernel virtual memory spaces k0, and k1 remain mapped unless you specifically unmap them; consequently, you can read from and write to these spaces from the bottom half of your driver. This is not true for kuseg.

MIPS processors enter kernel mode whenever an interrupt, a system instruction, or an exception occurs, and return to user mode only with a "Return from Exception" instruction. In general, address mapping is different for user and kernel modes. However, the translation lookaside buffer (TLB) maps all references to user address space, kuseg, identically, whether those references are made from kernel or user mode. In addition, the TLB controls cache access. Figure 1-3 is a diagram of the address/data path flow corresponding to the preceding descriptions.

Figure 1-3 : Architectural Block Diagram of Address/Data Flow To simplify the management of user mode from within the kernel, the user-mode address space is a subset of the kernel-mode address space.
Figure 1-4 illustrates the virtual-to-physical memory mapping for both user and kernel modes, and Figure 1-5 contrasts 32-bit (MIPS II) with 64-bit (MIPS III) modes for R4000 and R8000 platforms. There is a description of address mapping in various modes after the figures.

Note: Not all systems have physical memory at location 0. Also, while the class of device determines the VME address range, each GIO device responds to the same address range.

Figure 1-4 : MIPS II Virtual Memory Map

Figure 1-5 : MIPS II 32-bit versus MIPS III 64-bit Kernel Mode Address Space