The HP Vectra 486 basic I/O system

An Intel486 processor, the EISA bus standard, and a new memory subsystem all required enhancements to the Basic I/O System to ensure that the HP Vectra 486 made the best possible use of these new features.

The Basic I/O System (BIOS) is the lowest-level software interface between the hardware and the operating system in the HP Vectra 486 personal computer. The BIOS consists of a power-on self-test and function support for the DOS operating system. The power-on self-test performs testing and initialization of the various components of the system and loads the operating system. The rest of the BIOS supports functions to access the various DOS devices. This article describes the development process and the features incorporated into the HP Vectra 486 BIOS to support the Intel486 microprocessor and the Extended Industry Standard Architecture (EISA).

BIOS Source Base

The Vectra 486 BIOS code was heavily leveraged from the source code of the Vectra ES, RS, and QS personal computer series, which support the HP-HIL (human interface link) BIOS extensions (EXBIOS). The EXBIOS support was stripped off and support for EISA, the micro-DIN mouse, and other enhancements were added to create the Vectra 486 BIOS (see Fig. 1).

To maximize BIOS leverage for future systems, team members focused on keeping a large part of the new source files reusable. A common collection of reusable software modules ensures a more compatible and easily upgradable software system. This commonality ensures that during development, potential compatibility problems only have to be addressed once, and when a compatibility problem in a released product is fixed in a common routine, the fix is done once and automatically goes into all subsequent software releases.

The BIOS development of code was shared between the engineers at HP's California Personal Computer Division in Sunnyvale, California and HP's Grenoble Personal Computer Division in France. The configuration for transferring files back and forth between the two groups is shown in Fig. 2. This code sharing created issues related to ensuring file security and tracking changes to the code. For this reason the BIOS source base is managed by a software revision control system. The source files are structured into common and machine-specific directories. The machine-specific files contain code that handles the initialization requirements of different chip sets and different processors and processor speeds. EISA and ISA differences are also handled by the code in these files.

EISA Initialization

One of the most important features of the EISA architecture is its ability to detect the I/O expansion boards inserted in the system's motherboard slots. The configuration utility easy config generates information for each EISA or ISA card installed in a system expansion card slot. When the user is satisfied with the system configuration with either the defaults presented by easy config or after making any desired changes, the configuration is stored in nonviolate RAM.

The configuration files for each board contain function data structures for each slot that provide information on the DMA initialization, IRQ (interrupt request) trigger, memory information, and I/O initialization. easy config resolves I/O initialization, memory conflicts, and identification for the individual expansion boards in each slot.

EISA Configuration Support

Support for storage and retrieval of EISA configuration information is provided by 8K bytes of nonvolatile RAM and by system BIOS support routines. The EISA configuration utility easy config uses these routines to clear nonvolatile RAM, store EISA configuration information (on a slot-by-slot basis), and retrieve information for all functions of a slot (brief format) or for one function detailed format). Fig. 3 shows some of the processes involved in retrieving data from or storing data to the nonvolatile RAM containing configuration data.

The system BIOS power-on software also retrieves the configuration data to initialize the hardware in each slot. After the system boots, other system drivers, utilities, or the operating system may also store and/or retrieve configuration data (or any other data) from nonvolatile RAM.

To accommodate various operating environments the BIOS routines that interface to the nonvolatile RAM can operate in the Intel486s real or protected modes. In real mode, 16-bit segments and offsets are used to address a 1M-byte address space. In protected mode, segment registers become selectors into descriptor tables which with offsets allow for 16-bit to 32-bit addressing (up to 4 gigabytes).

To save space, input data is compressed by the caller before it is stored in nonvolatile RAM by the BIOS routines. When configuration data is retrieved from memory it is expanded by the BIOS routines before being passed to the caller. Expanding the output data involves padding variable-length data fields and blocks into fixed lengths. Slot configuration data consists of a variable number of variable-length function blocks that describe each function of a card in an EISA or ISA slot. The function blocks consist of fixed and variable-length fields and variable repetitions of fixed and variable-length subfields. These fields consist of descriptive text information and memory, interrupt, DMA, and I/O resource and configuration data. Free-form data can also be stored in some of these fields. The slot configuration data is stored sequentially by slot number (including empty slots) until the last physical or virtual slot is reached. The minimum size of a slot's configuration data is zero (empty) and the maximum size can be as long as the remaining available space in nonvolatile RAM.

To access nonvolatile RAM data efficiently (in terms of speed and space), a table approach is used. A table of pointers that point to slot configuration data blocks is allocated dynamically and grows inward from one end of the nonvolatile RAM. The data space for slot configuration blocks is also allocated dynamically and also grows inward but from the opposite end of nonvolatile RAM (see Mg. 4).When the pointer table and data space meet, the nonvolatile RAM is full. This technique saves memory space and allows for a single look-up to reach any data block.

Power-on Initialization

When the system is rebooted the BIOS initializes one EISA or ISA slot at a time and one function at a time using the configuration information stored in nonvolatile RAM. The initialization proceeds in two steps; error checking is performed first and then the slot is initialized.

Error Checking. The system ROM BIOS begins the initialization only if the nonvolatile memory's checksum is good. The BIOS also has to check whether the correct card is installed in the right slot before it initializes the card in that slot. The BIOS checks for the following combinations in each slot.

* A slot could be defined as empty according to the configuration data, but the user may have plugged a card into the slot.

* A slot could be defined to have a particular identifier according to the configuration data but may be read as empty.

* A slot could be defined to have no readable identifier according to the configuration data but BIOS reads an identifier from the slot.

An identifier read from the slot may not agree with the identifier in the configuration data.

An identifier for a slot is checked by reading certain slotspecific I/O ports as defined by the EISA specifications. After verifying that the slot that needs to be initialized has the correct card in it, the BIOS start the initialization for that slot. Fig. 5 shows the error checking process performed by the BIOS during initialization.

Slot initialization. As in error checking, slot initialization data comes from the configuration data in nonvolatile memory. The configuration data for a slot is retrieved as a block of data, and there could be many blocks of data for a particular slot. Fig. 6 shows the flow for slot initialization.

Slot initialization starts with the BIOS code reading a block of data from nonviolatile memory for a particular slot. It checks to see if there are any DMA initializations for that slot. If DMA is not shared, then the BIOS initializes the extended DMA registers defined for that slot. Next the code checks to see if the slot has any IRQs that need to be set as edge- or level-triggered. It then sets up the cache map for noncacheable regions as defined for that slot. The code then continues with the I/O initializations if any. Once this sequence is complete the code continues with the next function for the slot until all the functions are completed for that slot.

The BIOS provides a feature that allows the user to make blocks of memory cacheable or not. This is very useful for boards that have memory-mapped I/O. The BIOS builds a cache map in which each bit defines the cache on/off state of a particular segment (each segment is 64K bytes). A function in the configuration information for a slot can define the start address of the memory and the length of memory for which caching needs to be turned on or off. The BIOS initially sets all segments' caching to be on. It then checks for segments of memory for which the caching needs to be turned off and then turns caching off for the segments that are within the memory length specified. The cache map is updated and is later used in the boot process to initialize a 64K-bit static RAM, which the hardware uses in its cache on/off logic. Each bit of the static RAM represents a segment, allowing 64K segments (or four gigabytes) to be represented (see Fig. 7).

The BIOS then initializes the various I/O ports as defined in the configuration data. The I/O can be 8-bit, 16-bit, or 32-bit reads or writes. The configuration data also defines the mask for the particular I/O port. Thus, the I/O port is read, the data is masked (ANDed) with the mask value, ORed with the bits that need to be set, and written back to the I/O port.

Finally the BIOS enables the board in the initialized slot. Any time the initialization fails, the BIOS makes sure that the system can boot from a flexible disk and that the video is initialized correctly. This is done so that the machine is in a minimum working state so that the user can execute easy config and reconfigure the system.

Variable Speed Control

For backwards compatibility, it is sometimes necessary to reduce the speed of the PC. This is particularly true for copy-protected software applications that are speed sensitive. The Vectra 486 can reduce its speed for all operations, or only for flexible disk operations. The system BIOS is responsible for this control. To change speeds the BIOS programs the duty cycle of a square wave generated by a hardware timer which modulates the Spd_Hold_Req (hold request) input of the microprocessor (see Fig. 8a).

If the microprocessor did not have an internal cache then it would effectively be idle while it relinquishes the bus during a hold request. Its effective speed would thereby be reduced by the modulation factor. Since the Intel486 has an internal cache it will continue execution, even when in a Hold state, until a cache miss occurs, when it must wait for the bus. Therefore, to control the microprocessor's effective speed accurately when it is reduced from its maximum (unmodulated) value, it is necessary to disable and flush the processor's internal cache. With its internal cache empty, the processor will halt execution (because of cache misses) until the modulated Spd_Hold_Req signal is deasserted. The BIOS programs an I/O port which disables and flushes the internal cache via the Intel486 control lines. This avoids having to use, the Intel486 control registers to disable the cache. These control registers could be in use by other software applications and might be disrupted by the actions of the BIOS.

If the speed is restored, or after a flexible disk access when at autospeed ( At autospeed the system operates at its highest speed unmodulated and switches to an effective speed of 8 HHz modulated only when it is accessing a flexible disk.) the BIOS reprograms the cache control I/O port and the duty cycle of the square wave (see Fig. 8b). Therefore, the control state of the cache is maintained after resumption of maximum speed without interfering with resources Intel486 control registers) that applications may depend upon.

Micro-DIN and Security Features

The input system consists of three components: the input devices, BIOS functions, and the Intel 8042 keyboard controller. The 8042 keyboard controller communicates with the keyboard and an auxiliary device in a bidirectional, serial format with a synchronized clock generated by the input device. The auxiliary device may be any type of serial input device compatible with the 8042 keyboard controller interface. Some of these are: mouse, touchpad, trackball, and keyboard.

The 8042 keyboard controller receives the serial data, checks the parity, translates keyboard scan codes (if requested), and presents the data to the system as a byte of data. It also provides a password security mechanism to support the network server mode and application software.

Additional security features of the Vectra 486 PC are the power-on password and the mechanical keylock. Both schemes are designed to prevent unauthorized access to the PC. The BIOS provides the software to support the power-on password feature whenever the Vectra 486 is powered on.

The password function can be configured via the easy config utility to request a password either when the PC is powered on, or only when a user needs to use the input devices. If the PC is configured to request a password, the BIOS will display a graphical key symbol to prompt the user for the password. If the user types in the correct password, the PC will continue with its initialization. Otherwise, the BIOS allows three attempts for the user to type in the password before halting the CPU. If the user knows the correct password, the BIOS will allow the user to change or delete the password during the power-on sequence.

When the password is set up to allow limited access, which is also known as the network server mode, all micro-DIN input devices are disabled via the 8042. A PC configured as an unattended Me server would typically install the password in the network server mode. In the network server mode, if the BIOS detects a diskette in drive A, it will prompt the user for the installed password because an unauthorized user may be trying to gain access to the PC via a bootable diskette.

The mechanical keylock, used for locking the input devices, can be used in conjunction with the power-on password to provide maximum security. If the keylock is in the locked position and the password function is installed to request the password at power-on, then the user will have to unlock the keylock before typing the password. But if the password function is installed in the network server mode, the keylock doesn't have to be unlocked to type in the password until a user needs to use the input devices.

Since the user may occasionally forget the installed password, the BIOS supports a DIP switch within the Vectra 486 that disables the password. The BIOS uses this switch to allow the user to erase the password without any knowledge of the installed password. This switch is also used to forbid the installation of a password by an unauthorized user. To access the switch, the user must unlock a mechanical keylock to open the PC.

Shadowing and Remapping

The system memory of a Vectra 486 is partitioned into three areas: base memory, reserved memory, and extended memory. The base memory is within the physical address range from 0 to 640K bytes. The reserved address space is within the physical address range from 640 bytes to 1M bytes. Lastly, the extended memory area is all memory above 1M bytes. This memory architecture is known as the PC AT system memory architecture.

Most software applications typically use the base area and some use the extended memory area. The reserved memory is set aside for special system functions and is generally not available for typical software application use. The reserved memory is organized to support the main functional components of a microcomputer (see Mg. 9). The video display area and the video RAM can occupy the lowest portion of the reserved address space, A0000 to BFFFF. The video ROM BIOS can begin at C0000 and typically ends at C7FFF. The address space that begins at C8000 and ends at DFFFF is reserved for special I/O adapters and memory drivers. E0000 to EFFFF is used for onboard option ROMs or backplane I/O ROMs (located in the I/O slots for ISA or EISA cards). F0000 to FFFFF is reserved for the Basic Input/Ouput System (system ROM BIOS).

Since the introduction of this architecture, the cost of memory devices has declined while the density and speed of the components have increased. Processor speeds have increased far beyond the speed that any programmable read-only memory device can effectively support. With the advent of 32-bit bus architectures, systems can physically address four gigabytes of memory, when can be used to support larger, more complex software applications.

Better system performance can be obtained with efficient management of the reserved memory. The Vectra 486 makes use of two memory management schemes: ROM BIOS shadowing and memory remapping. ROM BIOS shadowing is a method used to speed up ROM memory access so that portions of reserved memory that are frequently used can be accessed as quickly as possible. Memory remapping permits unused reserved memory to be used as extended memory.

Shadowing. BIOS and video ROM BIOS routines and data are stored in EPROM electrically programmable read-only memory). This type of memory is considerably slower than dynamic random access memory (DRAM). Since the BIOS and video ROM routines are frequently used by the system, contents of the ROM BIOS and video ROM are copied into memory having a faster access time. This technique is known as shadowing.

The conventional organization of the reserved address space, in Fig. 9, shows the locations of the system RAM and BIOS ROMS. In the Vectra 486, as in other microcomputing systems, the conventional organization of reserved memory is enhanced to accommodate some additional system RAM which is located at the same address locations as the system BIOS and video ROMs (see Mg. 10). This memory is called shadow RAM. Another advantage of shadowing is that memory fetches for the Intel486 can be accomplished four times faster because the EPROM is an 8-bit device and system DRAM consists of 32-bit devices.

The conventional approach to shadowing is to copy the contents of the system ROM BIOS and video ROM BIOS to some temporary location. The ROM is then disabled and the shadow RAM is enabled. THE BIOS information, which currently resides in the temporary storage area, is copied into the shadow memory at the same memory address locations from which the information was originally retrieved. Following the shadowing process, any data that was originally in ROM will be accessed from the corresponding location in the faster shadow RAM. This approach requires that the state variables of the memory controller indicate whether the ROM or the shadow RAM is being accessed and if write access to the shadow memory is permitted. These state variables prevent data corruption by ensuring that either the ROM or the shadow RAM is enabled at any time, but not both, and that, once copied, the contents of the shadow memory cannot be inadvertently overwritten.

The disadvantage of the conventional shadowing method is that system memory control states are wasted. The Vectra 486 overcomes this problem by eliminating the ROM and shadow RAM enable variable. The write protect and shadow RAM enable variables are combined into a single state variable. On power-up, the default state of the system will read BIOS (system and video ROM) data from ROM and write this data to the BIOS address space in the shadow RAM. Whenever the shadow RAM is enabled, data read from the BIOS address space will be read from the shadow memory and all write operations to addresses within the BIOS address space are ignored. The shadowing method used in the Vectra 486 system results in a tremendous savings of hardware and valuable system ROM BIOS code space. The additional step of copying BIOS data is eliminated since data can be copied directly from ROM into the shadow RAM.

Remapping. It is often the case that following completion of the shadowing process, portions of the RAM in the reserved memory area are not used. Since typical software applications are not designed to be able to access reserved memory for general storage purposes, the free portions of reserved RAM remain unused. A software application can directly access reserved memory, but without prior knowledge of the configuration of the system, the application could unknowingly cause a device to malfunction by corrupting sensitive data One approach to this problem is to incorporate an expanded memory manager into the system configuration. An expanded memory manager manages the free reserved memory by allowing the application to use the space as additional base memory, and makes the system appear as if the amount of base memory has been expanded. The disadvantage of using an expanded memory driver is that it is used during run time. This mode of operation degrades system performance. The expanded memory manager also requires memory space for storage of the software routines, thereby leaving less memory for the application to use.

Another conventional method is to remap portions of reserved memory to the top of the physical address space of the system. The disadvantage of this method is that the memory location to which the free memory is moved sometimes does not border on existing memory locations and results in creating a noncontiguous memory structure. Most applications cannot make use of fragmented memory. Also, the conventional remapping scheme is a machine-specific feature, and therefore, all software applications must be customized to take advantage of the remapped memory.

The Vectra 486 solution to memory remapping uses the system configuration information in nonvolatile RAM to instruct the memory controller how to organize the system memory. As an EISA machine, the Vectra 486 has an autoconfiguration program which identifies system components and allocates system resources to obtain maximal system performance.

Memory remapping in the Vectra 486 is a two-step process. The first step is to find the largest contiguous chunk of free reserved memory that can be remapped. The video RAM space (A0000 to BFFFF) is generally not used because the video cards and the embedded subsystems are currently made with their own RAM. On-board option ROMS, which physically reside at E0000 to EFFFF, are rarely used, and the video BIOS address space, C0000 to C8000, fragments the reserved memory area. The way to create the largest contiguous section for reserved memory is to shadow the video BIOS in shadow memory at E0000, provided that the system does not contain onboard option ROMs and if I/O considerations of the video BIOS support portability. This paradigm creates a 256K-byte (A0000 to DFFFF) chunk of memory that can be remapped (see Fig. 11). The 32K-byte portion between E8000 and EFFFF is unused. The system memory controller is told what area of reserved memory is to be remapped. It must also be noted that systems that use the DOS shell rely heavily on the system BIOS and video BIOS routines, so maximally, only 256K bytes of memory is available for remapping. Systems that use OS/2 and the UNIX [R] operating system can maximally remap all of reserved memory because these operating systems replace system BIOS and video BIOS and supply all of their own drivers.

The second step in the remapping process is to determine where the physical existence of memory ends. The system BIOS knows this information following the system memory test procedure during the system power-on self-test. This address is passed to the system memory controller. Following the first step, the memory controller has the necessary information for memory remapping. The system memory controller then does the proper address translation.

BIOS shadowing and reserved memory remapping are powerful system features that enhance system performance and make better use of system resources. BIOS shadowing is a common feature among all machines currently on the market. Its primary advantage is to bring more parity between processor speed and ROM access times. To implement this functionality in an efficient manner saves hardware and code space which translates into a cost savings to the customer.

System Memory Initialization

Finite state machines implemented in software can be a very powerful tool. For a system's BIOS,_ a software finite state machine is ideal for component test situations in which scratchpad memory is not available. This technique is used in testing the system memory configuration in the Vectra 486.

The memory subsystem of the Vectra 486 is a two-way interleaved, linear memory architecture. The system memory board has four memory banks. Each bank can hold two memory modules. The two memory modules are two-way word interleaved. The banks of memory are organized in a linear fashion. See the article on page 78 for more information about the Vectra 486 memory subsystem.

The memory modules are packaged in single in-line memory modules and come in 1M-byte, 2M-byte, 4M-byte, and 8M-byte varieties. The 1M-byte and 4M-byte modules are single-density modules. The 2M-byte and 8M-byte modules are double-density modules. Each memory bank on the system memory board must contain a pair of memory modules that are the same size and have the same density type. Moreover, density restrictions require that all memory banks contain memory modules of the same density type. The linear structure of the memory subsystem requires that the amount of memory in a bank be less than or equal to the amount of memory in a bank that logically precedes it. The exception to this rule is the first bank because no other memory bank precedes it.

Before system memory can be tested, the memory subsystem configuration must be verified. The power-on self-test procedure in the system BIOS is responsible for this task. The use of system resources must be kept to a minimum because system memory is not available at this stage in the system power-on initialization process. A software finite state machine is ideal in this situation, since only the registers within the processor are available. The finite state control is guided by the memory module identification encoding (each memory module has information encoded within it that specifies the size and density type of the module). The memory state machine evaluates the identification for each memory bank and verifies that the current memory configuration linearity, uniform bank densities, etc.) is valid.

The software finite state method is very effective when considering that each of the four banks can have one of five types of memory modules. The number of possible memory configurations is 4[sup.5], or 1024 possible configurations. Of the 1024 possible configurations, 28 are valid. If module density errors are found first, then the linearity check can be done with a software finite state machine with four states. Fig. 12 shows the finite state machine for testing the Vectra 486 memory configuration.

Defect Tracking

Because BIOS source code was shared among independently managed projects in different locations, BIOS problems had to be tracked not only for the Vectra 486 product but also for several other HP personal computer products as will.

To keep track of prerelease problems across the various projects and to provide a means of collecting more global process improvement metrics, a custom dBASE IV[R] application was written for use by all of the BIOS teams. Problems reported on the Vectra 486 were sent by testers to a special electronic mail account to be entered into the database. The use of a standard problem form allowed the collection of valuable statistical as well as problem-specific information. Information about BIOS problems in common files was shared directly with each team by exchanging database files. The flexibility of the PC database application allowed each team to adapt the database application to their needs without affecting the ability to share data. This was important, because several BIOS teams could have been involved in resolving any one problem.

As each problem was investigated and resolved, status information was entered into the database. Detailed information, such as which code module contained the problem and when the problem was introduced, was readily available. The typical weekly status report contained a simple summary of the active problems, the problem owners, and their current status. One BIOS team member acted as the bug manager and helped keep everyone informed of the progress being made to resolve a problem.

BIOS Qualification and Test

The BIOS qualification effort for the Vectra 486 project was an improvement over previous BIOS development efforts. Because of major revisions to the BIOS in the Vectra 486 and the need to produce quality software in minimum time, a special BIOS qualification team was formed. This team consisted of four engineers and a software technician whose main job was to verify that the BIOS specifications were correct. In the past, the job of qualification of the BIOS was left up to the developer of the BIOS code. For the Vectra 486, it was felt that qualification would be more thorough if the persons developing and executing the tests were not the individuals developing the BIOS code.

To make best use of our limited resources, two types of test strategies were developed: white box and black box testing. Black box testing used a high-level language program, such as C, to verify the functionality and quality of the BIOS. The C functions invoked DOS functions, BIOS functions, and I/O registers to test the BIOS. This was the standard method of testing most programs. However, when testing the BIOS, we did not always have the luxury of relying on an operating system such as DOS because much of the BIOS functionality had to be tested during the machine initialization, and was inaccessible to high-level programs.

An alternate method was developed using some new approaches and working with special development tools to perform white box testing. New features such as EISA initialization, memory initialization, and shadowing routines were tested using this approach. This method forced two engineers to read and understand the actual code: the original designer and the one developing the test. This task alone required an in-depth understanding of the BIOS modules on an instruction-by-instruction basis. The concept of having two people intimately understand each module is not new, but typically resource limitations make such an arrangement a luxury.

There were many advantages to this type of testing. For one thing, it allowed us to simulate some of the system errors. For example, if the user had an invalid memory configuration, this error could be simulated without even changing the memory inside the computer. Furthermore, all the valid memory configuration could be tested via this program. There were well over 1000 memory configurations that could be tested through one automated program. Normally, this process would involve a technician physically changing the configuration each time. Another advantage was that the BIOS could be tested without the hardware. This proved to be very helpful since the BIOS was being developed before the hardware was available. With this method, two tasks could be done concurrently. Once the hardware was available, the tests could also be executed on the hardware.

The test strategy that was developed by the BIOS qualification team enabled the team to perform tests on the BIOS that would normally not have been done. Once the tests were developed, they could be added to the test suite for regression testing and other BIOS related tests.

Conclusion

The HP Vectra 486 BIOS development effort was a major milestone in HP's Personal Computer Groups software development history from the perspective of both new PC technology advances supported and new processes introduced. Support for new technologies and features like the EISA architecture and an advanced memory controller was incorporated into BIOS with high quality while meeting system schedules.

New or enhanced processes with their associated tools were incorporated to meet customer needs and HP business requirements. A customized source version control process and tools allowed efficient, multi-site, simultaneous PC BIOS development with maximum code reuse. Brand new defect tracking and component qualifacation processes and tools allowed quality BIOS development concurrent with PC hardware development.

Acknowledgments

The BIOS group would like to thank the Vectra 486 hardware team, the easy config utility team, the quality assurance group, the test development group, and other individuals throughout the division who participated in the Vectra 486 development. In particular we would like to thank Joyce Higa, Ruth Lim, Dave Wilkins, Roderick Young, Jongwon Yuk, Van T. Dam, Tewelde Stephanos, Paul Schlegelmann, Becky Smith, Dirk Massen, Martin Goldstein, and Chin Pin Wu. A special thanks to our project manager Anil R. Desai and section manager Tom Battle for their continued support. The support of all these people has made the Vectra 486 project a success and helped us deliver a high-performance and high-quality machine to the end user.

COPYRIGHT 1991 Hewlett Packard Company
COPYRIGHT 2004 Gale Group