Real hardware


Let's cover a few hardware terms you may see batted around and make sure that you have a basic understanding of what they mean.

  • MMU The Memory Management Unit is the hardware piece that controls mapping a virtual address into a real physical memory address. If the mapping fails, the MMU will signal the CPU with an interrupt (a page fault) and let the kernel figure out what to do about it. The MMU is set up by the kernel at boot time, and even the kernel code itself uses the MMU to perform memory accesses . The mappings are done in terms of pages, which are short chunks of memory of a fixed size , usually 4 kilobytes (older Sun-4 systems use 8-kilobyte pages). These mappings use Page Table Entries (PTEs) to describe allowable actions and the actual physical page to be used.

    You will not see a device driver specifically for an MMU. The code to support this hardware is in the virtual memory subsystem. In most Sun systems, the drivers will use virtual addresses to set up and perform input and output operations. Device accesses and I/O transfers will go through the MMU and thus use virtual rather than physical addresses.

  • Cache As a means of speeding up memory accesses, frequently used bits of memory are often cached ( copied into a local, high-speed storage area). If the data is present in the cache, it will be fetched from there immediately without even touching memory. There are complex methods to keep cache contents up-to-date and consistent with real physical memory contents. There may be some requirements for a driver to ensure that caching is done properly, since I/O (which references memory) may require the cache to be flushed out or reloaded.

  • SCSI (Small Computer Systems Interface) SCSI is a type of I/O bus used for access to multiple devices. It's a fairly well defined interface specification, originally developed for small microcomputer systems (hence the name ). It allows for one main CPU (an initiator ) and seven devices, or controllers, to be present.

  • ESP (Enhanced SCSI Processor) The ESP, known as the host adaptor, is the interface between the SCSI bus and the main I/O bus (SBus) on a SPARC machine. It issues SCSI requests , receives responses, and sets up data transfers between the devices and memory.

  • SCSA (Sun Common SCSI Architecture) The SCSA is not really hardware, but it's related . SCSA is a standard to define how a device driver, such as a SCSI tape driver, should communicate with the host adaptor. Since host adaptors may vary on different systems, this standard provides a way for drivers to be more hardware-independent in this area (they need only be written for a device, not for the device plus the host adaptor!).

  • SBus The SBus is the I/O bus (data path ) for SPARCstations and later Sun systems. Older systems used the VMEbus for I/O, but a requirement for faster throughput and higher-speed devices led to the development of a newer bus. The ESP, graphics displays, and the Ethernet controller are connected to the SBus. Most SBus devices are known as "self-identifying" because the actual hardware contains a read-only memory with code to identify the device on that circuit card to the kernel.

  • MBus The MBus is the internal data path between one or more processors and memory or devices. It is the main machine bus for the sun4m architecture family.

  • XDBus With the development of yet faster processors and multiprocessor systems, the MBus was found to be too limited and slow. A newer internal bus was developed for the larger server systems (sun4d family).

  • Ethernet One of the original network implementations , Ethernet is a simple and popular method of connecting machines. Since it just needs a cable, it's flexible and easy to install. Speed and distance limitations restrict its applications, but it is still very useful for Local Area Network (LAN) setups. Messages can be sent directly to a specific machine on the wire or as a broadcast, received by everything on the net.

  • PROM (Programmable Read-Only Memory) Every Sun system has a PROM that performs power-on testing, identifies a console, and either interacts with a user or automatically boots up a specific system from a specific device. There are two types of PROMs on Sun systems. The older one is fairly primitive but does have a set of commands available for basic hardware debugging. The newer version, known as the OpenBoot PROM, actually contains a FORTH interpreter along with a sophisticated command language.

    Some examples of useful commands can be found in Chapter 27, "Watchdog Resets," since they are the only thing available for debugging this particular condition.

  • DMA (Direct Memory Access) DMA is used by devices to perform I/O without directly involving the CPU. Older or slower input and output is often done by having the processor communicate directly with the device for each word or character transferred. This involves a great deal of overhead, which severely limits the speed of an I/O operation.

    An alternate approach is to have the device itself perform the transfer directly to or from the main memory of the machine, signaling the CPU when it's finished. This procedure, known as DMA, is used by most high-speed devices (disk, tape, and network interfaces); the alternate method is called "polled I/O" because the device must be polled (queried) for each data element. The CPU, when setting up a DMA transfer, must provide the device with a starting address in memory (a buffer location), a transfer size (byte count), and then issue a command to start. It will be interrupted by the device when the transfer is completed or when something unexpected happens (like an I/O error).

    Sun systems generally use DVMA, or Direct Virtual Memory Access. The addresses used by the device for memory accesses are all virtual addresses, and all data transfers go through an MMU.



PANIC. UNIX System Crash Dump Analysis Handbook
PANIC! UNIX System Crash Dump Analysis Handbook (Bk/CD-ROM)
ISBN: 0131493868
EAN: 2147483647
Year: 1994
Pages: 289
Authors: Chris Drake

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net