Data (computing)

From Wikipedia, the free encyclopedia

Jump to: navigation, search
In computer science, data is anything in a form suitable for use with a computer.[1] Data is often
distinguished from programs. A program is a set of instructions that detail a task for the
computer to perform. In this sense, data is thus everything that is not program code.[2]
In an alternate usage, binary files (which are not human-readable) are sometimes called "data" as
distinguished from human-readable "text".[3] The total amount of digital data in 2007 was
estimated to be 281 billion gigabytes (= 281 exabytes).[4][5]

[edit] Data vs programs

Fundamentally, computers follow the instructions they are given. A set of instructions to perform
a given task (or tasks) is called a "program". In the nominal case, the program, as executed by the
computer, will consist of binary machine code. The elements of storage manipulated by the
program, but not actually executed by the CPU, contain data.
Typically, different files are used to store programs vs data. Executable files contain programs;
all other files are data files. However, executable files may also contain data which is "built-in"
to the program. In particular, some executable files have a data segment, which nominally
contains constants and initial values (both data).
For example: a user might first instruct the operating system to load a word processor program
from one file, and then edit a document stored in another file. In this example, the document
would be considered data. If the word processor also features a spell checker, then the dictionary
(word list) for the spell checker would also be considered data. The algorithms used by the spell
checker to suggest corrections would be considered code.
The line between program and data can become blurry. An interpreter, for example, is a
program. The input data to an interpreter is itself a program—just not one expressed in native
machine language. In many cases, the interpreted program will be a human-readable text file,
which is manipulated with a text editor—more normally associated with plain text data.
Metaprogramming similarly involves programs manipulating other programs as data.

[edit] See also

 Data
 Data segment
 Data type
 Von Neumann architecture
Power-on self-test (POST) refers to routines run immediately after power is applied, by nearly all electronic
devices. Perhaps the most widely-known usage pertains to computing devices (personal computers, PDAs,
networking devices such as routers, switches, intrusion detection systems and other monitoring devices). Other
devices include kitchen appliances, avionics, medical equipment, laboratory test equipment -- all embedded devices.
The routines are part of a device's pre-boot sequence. Once POST completes successfully, bootstrapping code is
invoked.
Routines included during POST include routines to set an initial value for internal and output signals and to execute
internal tests, as determined by the device maker. These initial conditions are also referred to as the device's state.
They may be stored in firmware or included as hardware, either as part of the design itself, or the may be part of
semiconductor substrate either by virtue of being part of a device mask, or after being burned into a device such as a
programmable logic array (PLA).
Test results may be enunciated either on a panel that is part of the device, or output via bus to an external device.
They may also be stored internally, or may exist only until the next power-down. In some cases, such as in aircraft
and automobiles, only the fact that a failure occurred may be displayed (either visibly or to an on-board computer)
but may also upload detail about the failure(s) when a diagnostic tool is connected.
POST protects the bootstrapped code from being interrupted by faulty hardware. Diagnostic information provided
by a device, for example when connected to an engine analyzer, depends on the proper function of the device's
internal components. In these cases, if the device is not capable of providing accurate information, subsequent code
(such as bootstrapping code) may not be permitted to run. This is one to ensure that, if a device is not safe to run, it
is not permitted to run.

Contents
[hide]
 1 General internal workings
 2 Fundamental structure
 3 Error reporting
 3.1 Original IBM POST beep codes
 3.2 POST AMI BIOS beep codes
 3.3 POST beep codes on CompTIA A+ Hardware Core exam
 3.4 IBM POST diagnostic code descriptions
 4 Macintosh POST
 4.1 Old World Macs (until 1998)
 4.2 New World Macs (1998-1999)
 4.3 New World Macs (1999 onward) and Intel-based Macs
 5 Amiga POST
 5.1 POST Sequence of Amiga
 5.2 Sequence for all main Amiga models
 5.3 Amiga Color Screens Scheme
 5.4 Sequence for A4000
 5.4.1 Failed Tests Color Scheme
 5.5 Amiga Keyboard LED error signals
 6 See also
 7 External links

[edit] General internal workings

On power up, the main duties of POST are handled by the BIOS, which may hand some of these duties to other
programs designed to initialize very specific peripheral devices, notably for video and SCSI initialization. These
other duty-specific programs are generally known collectively as option ROMs or individually as the video BIOS,
SCSI BIOS, etc.
The principal duties of the main BIOS during POST are as follows:
 verify the integrity of the BIOS code itself
 find, size, and verify system main memory
 discover, initialize, and catalog all system buses and devices
 pass control to other specialized BIOSes (if and when required)
 provide a user interface for system's configuration
 identify, organize, and select which devices are available for booting
 construct whatever system environment that is required by the target OS
The BIOS will begin its POST duties when the CPU is reset. The first memory location the CPU tries to execute is
known as the reset vector. In the case of a hard reboot, the northbridge will direct this code fetch (request) to the
BIOS located on the system flash memory. For a warm boot, the BIOS will be located in the proper place in RAM
and the northbridge will direct the reset vector call to the RAM. On your ASUS screen, you have to press the Tab
key to show the POST screen.
During the POST flow of a contemporary BIOS, one of the first things a BIOS should do is determine the reason it
is executing. For a cold boot, for example, it may need to execute all of its functionality. If, however, the system
supports power savings or quick boot methods, the BIOS may be able to circumvent the standard POST device
discovery, and simply program the devices from a preloaded system device table.
The POST flow for the PC has developed from a very simple, straightforward process to one that is complex and
convoluted. During POST, the BIOS must integrate a plethora of competing, evolving, and even mutually exclusive
standards and initiatives for the matrix of hardware and OSes the PC is expected to support. However, the average
user still knows the POST and BIOS only through its simple visible memory tests and setup screen.

[edit] Fundamental structure

In the case of the IBM PC compatible machines, the main BIOS is divided into two basic sections. The POST
section, or POST code, is responsible for the tasks mentioned above, and the environment POST constructs for the
OS is known as the runtime code, the runtime BIOS, or the runtime footprint. Primarily these two divisions can be
distinguished in that POST code should be flushed from memory before control is passed to the target OS while the
runtime code remains resident in memory. This division may be a misleading oversimplification, however, as many
Runtime functions are executed while the system is POSTing.

Error Reporting:
The original IBM BIOS reported errors detected during POST by outputting a number to a fixed I/O port address,
80. Using a logic analyzer or a dedicated POST card, an interface card that shows port 80 output on a small display,
a technician could determine the origin of the problem. (Note that once an operating system is running on the
computer, the code displayed by such a board is often meaningless, since some OSes, e.g. Linux, use port 80 for I/O
timing operations.) In later years, BIOS vendors used a sequence of beeps from the motherboard-attached
loudspeaker to signal error codes. Some vendors have developed proprietary variants or enhancements, such as
MSI's D-Bracket. POST beep codes vary from manufacturer to manufacturer.
[edit] Original IBM POST beep codes
 1 short beep - Normal POST - system is OK
 2 short beeps - POST error - error code shown on screen
 No beep - Power supply, system board problem, disconnected CPU, or disconnected speaker,
 Continuous beep - Power supply, system board, or keyboard problem
  Repeating short beeps - Power supply or system board problem or keyboard
 1 long, 1 short beep - System board problem
 1 long, 2 short beeps - Display adapter problem (MDA, CGA)
 1 long, 3 short beeps - Enhanced Graphics Adapter (EGA)
 3 long beeps - 3270 keyboard card
[edit] POST AMI BIOS beep codes
 1 - Memory refresh timer error
 2 - Parity error in base memory (first 64 KiB block)
 3 - Base memory read/write test error
 4 - Mother board timer not operational (check all PSU to MB connectors seated)
 5 - Processor failure
 6 - 8042 Gate A20 test error (cannot switch to protected mode)
 7 - General exception error (processor exception interrupt error)
 8 - Display memory error (system video adapter)
 9 - AMI BIOS ROM checksum error
 10 - CMOS shutdown register read/write error
 11 - Cache memory test failed
 12 - Mother board does not detect a RAM module (continuous beeping)
Reference: AMIBIOS8 Check Point and Beep Code List, version 2.0, last updated 10 June 2008
[edit] POST beep codes on CompTIA A+ Hardware Core exam
These POST beep codes are covered specifically on the CompTIA A+ Core Hardware Exam:

Beeps Meaning

Steady, short
Power supply may be bad
beeps

Long continuous
Memory failure
beep tone

Steady, long
Power supply bad
beeps

No beep Power supply bad, system not plugged in, or power not turned on

If everything seems to be functioning correctly there may be a problem with the 'beeper' itself.
No beep
The system will normally beep one short beep.

One long, two

Video card failure
short beeps

[edit] IBM POST diagnostic code descriptions

 100 to 199 - System boards
 200 to 299 - Memory
  300 to 399 - Keyboard
 400 to 499 - Monochrome display
 500 to 599 - Color/graphics display
 600 to 699 - Floppy-disk drive or adapter
 700 to 799 - Math coprocessor
 900 to 999 - Parallel printer port
 1000 to 1099 - Alternate printer adapter
 1100 to 1299 - Asynchronous communication device, adapter, or port
 1300 to 1399 - Game port
 1400 to 1499 - Color/graphics printer
 1500 to 1599 - Synchronous communication device, adapter, or port
 1700 to 1799 - Hard drive and/or adapter
 1800 to 1899 - Expansion unit (XT)
 2000 to 2199 - Bisynchronous communication adapter
 2400 to 2599 - EGA system-board video (MCA)
 3000 to 3199 - LAN adapter
 4800 to 4999 - Internal modem
 7000 to 7099 - Phoenix BIOS chips
 7300 to 7399 - 3.5-inch disk drive
 8900 to 8999 - MIDI adapter
 11200 to 11299 - SCSI adapter
 21000 to 21099 - SCSI fixed disk and controller
 21500 to 21599 - SCSI CD-ROM system

[edit] Macintosh POST

Apple's Macintosh computers also perform a POST after a cold boot. In the event of a fatal error, the Mac will not
make its startup chime.
[edit] Old World Macs (until 1998)
Macs made after 1987 but prior to 1998, upon failing the POST, will immediately halt with a "death chime," which
is a sound that varies by model; it can be a beep, a car crash sound, the sound of shattering glass, a short musical
tone, or more. On the screen will be the Sad Mac icon, along with two hexadecimal strings, which can be used to
identify the problem. Macs made prior to 1987 crashed with the hexadecimal string and a Sad Mac icon silently.
[edit] New World Macs (1998-1999)
When Apple introduced the iMac in 1998, it was a radical departure from other Macs of the time. The iMac began
the production of New World Macs, as they are called; New World Macs, such as the iMac, Power Macintosh G3
(Blue & White), Power Mac G4 (PCI Graphics), PowerBook G3 (bronze keyboard), and PowerBook G3 (FireWire),
load the Mac OS ROM from the hard drive. In the event of a fatal error, they give these beeps:[1]
 1 beep = No RAM installed/detected
 2 beeps = Incompatible RAM type installed (for example, EDO)
 3 beeps = No RAM banks passed memory testing
  4 beeps = Bad checksum for the remainder of the boot ROM
 5 beeps = Bad checksum for the ROM boot block
[edit] New World Macs (1999 onward) and Intel-based Macs
The beep codes were revised in October 1999,[2] and have been the same since. In addition, on some models, the
power LED would flash in cadence.
 1 beep = no RAM installed
 2 beeps = incompatible RAM types
 3 beeps = no good banks
 4 beeps = no good boot images in the boot ROM (and/or bad sys config block)
 5 beeps = processor is not usable

[edit] Amiga POST

Amiga historical line of computers, from A1000 to 4000 present an interesting POST sequence that prompts the user
with a sequence of flashing screens of different colors (rather than audible beeps as in other systems) to show if
various hardware POST tests were correct or else if they failed:
[edit] POST Sequence of Amiga
The Amiga system performs the following tests at boot:
 Step 1 - Delays beginning the tests a fraction of a second to allow the hardware to stabilize.
 Step 2 - Jumps to ROM code in diagnostic card (if found)
 Step 3 - Disables and clears all DMA and interrupts.
 Step 4 - Turns on the screen.
 Step 5 - Checks the general hardware configuration.
If the screen remains a light gray colors and the tests continue, the hardware is OK. If an error occurs, the system
halts.
 Step 6 - Performs checksum test on ROMs.
If the system fails the ROM test, the screen display turns red and the system halts.
[edit] Sequence for all main Amiga models
Almost all Amiga models present the same color sequence when turned on:
Black screen, dark gray, light gray color screens filling all monitor screen in a rapid sequence (Amigas taken up
usually 2, or at least max 3 seconds to turn on and boot).
[edit] Amiga Color Screens Scheme
 Red = Bad ROM
 Yellow = CPU Exception Before Bootstrap Code is Loaded
 Green = Bad Chip RAM or fail of Agnus Chip (check seating of Agnus)
 Black = No CPU
 White = Expansion passed test successfully
 Grey = CPU Passed
 Constant White = Failure of CPU
[edit] Sequence for A4000
<====Correct Tests Color Sequence Scheme====>
A4000 presents just a light gray screen during its boot time (it just occurs in 2 or max 3 seconds)
 Light Gray
 = Initial hardware configuration tests passed
 = Initial system software tests passed)
 = Final initialization test passed
[edit] Failed Tests Color Scheme
 Red = ROM Error - Reset or replace
 Green = CHIP RAM error (reset AGNUS and re-test)
 Blue = Custom Chip(s) Error
 Yellow = 68000 detected error before software trapped it (GURU)
[edit] Amiga Keyboard LED error signals
The keyboards of historical Amiga models are not proprietary as it happened in early computer ages, but more
pragmatically it was based on international standard ANSI/ISO 8859-1. The keyboard itself was an intelligent
device and had its own processor and 4 kilobytes of RAM for keeping a buffer of the sequence of keys that were
being pressed, thus can communicate with the user if a fault is found by flashing its main LED in sequence:
 One Blink = ROM Checksum failure
 Two Blinks = RAM test failed
 Three Blinks = Watchdog timer failed
 Four Blinks = A shortcut exists between two row lines or one of the seven special keys (not implemented)

BIOS
In IBM PC Compatible computers, the basic input/output system (BIOS), also known as the
System BIOS, is a de facto standard defining a firmware interface.[1]

Phoenix AwardBIOS CMOS (non-volatile memory) Setup utility on a standard PC

The BIOS of a PC software is built into the PC, and is the first code run by a PC when powered
on ('boot firmware'). The primary function of the BIOS is to load and start an operating system.
When the PC starts up, the first job for the BIOS is to initialize and identify system devices such
as the video display card, keyboard and mouse, hard disk, CD/DVD drive and other hardware.
The BIOS then locates software held on a peripheral device (designated as a 'boot device'), such
as a hard disk or a CD, and loads and executes that software, giving it control of the PC.[2] This
process is known as booting, or booting up, which is short for bootstrapping.

BIOS software is stored on a non-volatile ROM chip built into the system on the mother board.
The BIOS software is specifically designed to work with the particular type of system in
question, including having a knowledge of the workings of various devices that make up the
complementary chipset of the system. In modern computer systems, the BIOS chip's contents can
be rewritten allowing BIOS software to be upgraded.
A BIOS will also have a user interface (or UI for short). Typically this is a menu system
accessed by pressing a certain key on the keyboard when the PC starts. In the BIOS UI, a user
can:

 configure hardware
 set the system clock
 enable or disable system components
 select which devices are eligible to be a potential boot device
 set various password prompts, such as a password for securing access to the BIOS UI
functions itself and preventing malicious users from booting the system from
unauthorized peripheral devices.

The BIOS provides a small library of basic input/output functions used to operate and control the
peripherals such as the keyboard, text display functions and so forth, and these software library
functions are callable by external software. In the IBM PC and AT, certain peripheral cards such
as hard-drive controllers and video display adapters carried their own BIOS extension ROM,
which provided additional functionality. Operating systems and executive software, designed to
supersede this basic firmware functionality, will provide replacement software interfaces to
applications.

The role of the BIOS has changed over time; today BIOS is a legacy system, superseded by the
more complex Extensible Firmware Interface (EFI), but BIOS remains in widespread use, and
EFI booting has only been supported in x86 Windows since 2008. BIOS is primarily associated
with the 16-bit and 32-bit architecture eras (x86-32), while EFI is used for some 32-bit and most
64-bit architectures. Today BIOS is primarily used for booting a system, and for certain
additional features such as power management (ACPI) and video initialization (in X.org), but
otherwise is not used during the ordinary running of a system, while in early systems
(particularly in the 16-bit era), BIOS was used for hardware access – operating systems (notably
MS-DOS) would call the BIOS rather than directly accessing the hardware. In the 32-bit era and
later, operating systems instead generally directly accessed the hardware using their own device
drivers. However, the distinction between BIOS and EFI is rarely made in terminology by the
average computer user, making BIOS a catch-all term for both systems.

Contents
[hide]

 1 Terminology
 2 IBM PC-compatible BIOS chips
 3 Flashing the BIOS
 4 BIOS chip vulnerabilities
 5 Overclocking
 6 Virus attacks
o 6.1 CIH
o 6.2 Black Hat 2006
 o 6.3 Persistent BIOS Infection
 7 Firmware on adapter cards
 8 BIOS boot specification
 9 Changing role of the BIOS
 10 The BIOS business
 11 See also
 12 References
 13 Further reading
 14 External links
o 14.1 Specifications

[edit] Terminology
The term first appeared in the CP/M operating system, describing the part of CP/M loaded during
boot time that interfaced directly with the hardware (CP/M machines usually had only a simple
boot loader in their ROM). Most versions of DOS have a file called "IBMBIO.COM" or
"IO.SYS" that is analogous to the CP/M BIOS.

Among other classes of computers, the generic terms boot monitor, boot loader or boot ROM
were commonly used. Some Sun and PowerPC-based computers use Open Firmware for this
purpose. There are a few alternatives for Legacy BIOS in the x86 world: Extensible Firmware
Interface, Open Firmware (used on the OLPC XO-1) and coreboot.

[edit] IBM PC-compatible BIOS chips

In principle, the BIOS in ROM was customized to the particular manufacturer's hardware,
allowing low-level services (such as reading a keystroke or writing a sector of data to diskette) to
be provided in a standardized way to the operating system. For example, an IBM PC might have
had either a monochrome or a color display adapter, using different display memory addresses
and hardware - but the BIOS service to print a character on the screen in text mode would be the
same.

Boot Block
DMI Block
Main Block

PhoenixBIOS D686. This BIOS chip is housed in a PLCC package, which is, in turn, plugged
into a PLCC socket.

Prior to the early 1990s, BIOSes were stored in ROM or PROM chips, which could not be
altered by users. As its complexity and need for updates grew, and re-programmable parts
became more available, BIOS firmware was most commonly stored on EEPROM or flash
memory devices. According to Robert Braver, the president of the BIOS manufacturer Micro
Firmware, Flash BIOS chips became common around 1995 because the electrically erasable
PROM (EEPROM) chips are cheaper and easier to program than standard erasable PROM
(EPROM) chips. EPROM chips may be erased by prolonged exposure to ultraviolet light, which
accessed the chip via the window. Chip manufacturers use EPROM programmers (blasters) to
program EPROM chips. Electrically erasable (EEPROM) chips come with the additional feature
of allowing a BIOS reprogramming via higher-than-normal amounts of voltage.[3] BIOS versions
are upgraded to take advantage of newer versions of hardware and to correct bugs in previous
revisions of BIOSes.[4]

Beginning with the IBM AT, PCs supported a hardware clock settable through BIOS. It had a
century bit which allowed for manually changing the century when the year 2000 happened.
Most BIOS revisions created in 1995 and nearly all BIOS revisions in 1997 supported the year
2000 by setting the century bit automatically when the clock rolled past midnight, December 31,
1999.[5]

The first flash chips were attached to the ISA bus. Starting in 1997, the BIOS flash moved to the
LPC bus, a functional replacement for ISA, following a new standard implementation known as
"firmware hub" (FWH). In 2006, the first systems supporting a Serial Peripheral Interface (SPI)
appeared, and the BIOS flash moved again.

The size of the BIOS, and the capacities of the ROM, EEPROM and other media it may be
stored on, has increased over time as new features have been added to the code; BIOS versions
now exist with sizes up to 16 megabytes. Some modern motherboards are including even bigger
NAND Flash ROM ICs on board which are capable of storing whole compact operating system
distribution like some Linux distributions. For example, some recent ASUS motherboards
included SplashTop Linux embedded into their NAND Flash ROM ICs.

[edit] Flashing the BIOS

In modern PCs the BIOS is stored in rewritable memory, allowing the contents to be replaced or
'rewritten'. This rewriting of the contents is sometimes termed 'flashing'. This is done by a
special program, usually provided by the system's manufacturer. A file containing such contents
is sometimes termed 'a BIOS image'. A BIOS might be reflashed in order to upgrade to a newer
version to fix bugs or provide improved performance or to support newer hardware, or a
reflashing operation might be needed to fix a damaged BIOS.

[edit] BIOS chip vulnerabilities

An American Megatrends BIOS registering the “Intel CPU uCode Error” while doing POST,
most likely a problem with the POST.

EEPROM chips are advantageous because they can be easily updated by the user; hardware
manufacturers frequently issue BIOS updates to upgrade their products, improve compatibility
and remove bugs. However, this advantage had the risk that an improperly executed or aborted
BIOS update could render the computer or device unusable. To avoid these situations, more
recent BIOSes use a "boot block"; a portion of the BIOS which runs first and must be updated
separately. This code verifies if the rest of the BIOS is intact (using hash checksums or other
methods) before transferring control to it. If the boot block detects any corruption in the main
BIOS, it will typically warn the user that a recovery process must be initiated by booting from
removable media (floppy, CD or USB memory) so the user can try flashing the BIOS again.
Some motherboards have a backup BIOS (sometimes referred to as DualBIOS boards) to recover
from BIOS corruptions.

[edit] Overclocking
Some BIOS chips allow overclocking, an action in which the CPU is adjusted to a higher clock
rate than its factory preset. Overclocking may, however, seriously compromise system reliability
in insufficiently cooled computers and generally shorten component lifespan.

[edit] Virus attacks

There are at least three known BIOS attack viruses, two of which were for demonstration
purposes.

[edit] CIH

The first was a virus which was able to erase Flash ROM BIOS content, rendering computer
systems unstable. CIH, also known as "Chernobyl Virus", appeared for the first time in mid-1998
and became active in April 1999. It affected systems' BIOS's and often they could not be fixed
on their own since they were no longer able to boot at all. To repair this, Flash ROM IC had to
be removed from the motherboard to be reprogrammed elsewhere. Damage from CIH was
possible since the virus was specifically targeted at the then widespread Intel i430TX
motherboard chipset, and the most common operating systems of the time were based on the
Windows 9x family allowing direct hardware access to all programs.
Modern systems are not vulnerable to CIH because of a variety of chipsets being used which are
incompatible with the Intel i430TX chipset, and also other Flash ROM IC types. There is also
extra protection from accidental BIOS rewrites in the form of boot blocks which are protected
from accidental overwrite or dual and quad BIOS equipped systems which may, in the event of a
crash, use a backup BIOS. Also, all modern operating systems like Linux, Mac OS X, Windows
NT-based Windows OS like Windows 2000, Windows XP and newer, do not allow user mode
programs to have direct hardware access. As a result, as of 2008, CIH has become essentially
harmless, at worst causing annoyance by infecting executable files and triggering alerts from
antivirus software. Other BIOS viruses remain possible, however[6]: since most Windows users
run all applications with administrative privileges, a modern CIH-like virus could in principle
still gain access to hardware.

[edit] Black Hat 2006

The second one was a technique presented by John Heasman, principal security consultant for
UK based Next-Generation Security Software at the Black Hat Security Conference (2006),
where he showed how to elevate privileges and read physical memory, using malicious
procedures that replaced normal ACPI functions stored in flash memory.

[edit] Persistent BIOS Infection

The third one, known as "Persistent BIOS infection", was a method presented in CanSecWest
Security Conference (Vancouver, 2009) and SyScan Security Conference (Singapore, 2009)
where researchers Anibal Sacco [7] and Alfredo Ortega, from Core Security Technologies,
demonstrated insertion of malicious code into the decompression routines in the BIOS, allowing
for nearly full control of the PC at every start-up, even before the operating system is booted.

The proof-of-concept does not exploit a flaw in the BIOS implementation, but only involves the
normal BIOS flashing procedures. Thus, it requires physical access to the machine or for the user
on the operating system to be root. Despite this, however, researchers underline the profound
implications of their discovery: “We can patch a driver to drop a fully working rootkit. We even
have a little code that can remove or disable antivirus.”[8]

[edit] Firmware on adapter cards

A computer system can contain several BIOS firmware chips. The motherboard BIOS typically
contains code to access hardware components absolutely necessary for bootstrapping the system,
such as the keyboard (either PS/2 or on a USB human interface device), and storage (floppy
drives, if available, and IDE or SATA hard disk controllers). In addition, plug-in adapter cards
such as SCSI, RAID, Network interface cards, and video boards often include their own BIOS
(e.g. Video BIOS), complementing or replacing the system BIOS code for the given component.
(This code is generally referred to as an option ROM.) Even devices built into the motherboard
can behave in this way; their option ROMs can be stored as separate code on the main BIOS
flash chip, and upgraded either in tandem with, or separately to, the main BIOS.

An add-in card usually only requires an option ROM if it:

  Needs to be used before the operating system can be loaded (usually this means it is
required in the bootstrapping process), and
 Is too sophisticated or specific a device to be handled by the main BIOS

Older PC operating systems, such as MS-DOS (including all DOS-based versions of Microsoft
Windows), and early-stage bootloaders, may continue to use the BIOS for input and output.
However, the restrictions of the BIOS environment means that modern OSes will almost always
use their own device drivers to directly control the hardware. Generally, these device drivers
only use BIOS and option ROM calls for very specific (non-performance-critical) tasks, such as
preliminary device initialization.

In order to discover memory-mapped option ROMs during the boot process, PC BIOS
implementations scan real memory from 0xC0000 to 0xF0000 on 2 KiB boundaries, looking for a
ROM signature: 0xAA55 (0x55 followed by 0xAA, since the x86 architecture is little-endian). In
a valid expansion ROM, this signature is immediately followed by a single byte indicating the
number of 512-byte blocks it occupies in real memory. The next byte contains an offset
describing the option ROM's entry point, to which the BIOS immediately transfers control. At
this point, the expansion ROM code takes over, using BIOS services to register interrupt vectors
for use by post-boot applications, provide a user configuration interface, or display diagnostic
information.

There are many methods and utilities for examining the contents of various motherboard BIOS
and expansion ROMs, such as Microsoft DEBUG or the UNIX dd.

[edit] BIOS boot specification

If the expansion ROM wishes to change the way the system boots (such as from a network
device or a SCSI adapter for which the BIOS has no driver code), it can use the BIOS Boot
Specification (BBS) API to register its ability to do so. Once the expansion ROMs have
registered using the BBS APIs, the user can select among the available boot options from within
the BIOS's user interface. This is why most BBS compliant PC BIOS implementations will not
allow the user to enter the BIOS's user interface until the expansion ROMs have finished
executing and registering themselves with the BBS API.[citation needed]

[edit] Changing role of the BIOS

Some operating systems, for example MS-DOS, rely on the BIOS to carry out most input/output
tasks within the PC.[9] A variety of technical reasons makes it inefficient for some recent
operating systems written for 32-bit CPUs such as Linux and Microsoft Windows to invoke the
BIOS directly. Larger, more powerful, servers and workstations using PowerPC or SPARC
CPUs by several manufacturers developed a platform-independent Open Firmware (IEEE-1275),
based on the Forth programming language. It is included with Sun's SPARC computers, IBM's
RS/6000 line, and other PowerPC CHRP motherboards. Later x86-based personal computer
operating systems, like Windows NT, use their own, native drivers which also makes it much
easier to extend support to new hardware, while the BIOS still relies on a legacy 16-bit runtime
interface.

There was a similar transition for the Apple Macintosh, where the system software originally
relied heavily on the ToolBox—a set of drivers and other useful routines stored in ROM based
on Motorola's 680x0 CPUs. These Apple ROMs were replaced by Open Firmware in the
PowerPC Macintosh, then EFI in Intel Macintosh computers.

Later BIOS took on more complex functions, by way of interfaces such as ACPI; these functions
include power management, hot swapping and thermal management. However BIOS limitations
(16-bit processor mode, only 1 MiB addressable space, PC AT hardware dependencies, etc.)
were seen as clearly unacceptable for the newer computer platforms. Extensible Firmware
Interface (EFI) is a specification which replaces the runtime interface of the legacy BIOS.
Initially written for the Itanium architecture, EFI is now available for x86 and x86-64 platforms;
the specification development is driven by The Unified EFI Forum, an industry Special Interest
Group.

Linux has supported EFI via the elilo boot loader. The Open Source community increased their
effort to develop a replacement for proprietary BIOSes and their future incarnations with an open
sourced counterpart through the coreboot and OpenBIOS/Open Firmware projects. AMD
provided product specifications for some chipsets, and Google is sponsoring the project.
Motherboard manufacturer Tyan offers coreboot next to the standard BIOS with their Opteron
line of motherboards. MSI and Gigabyte Technology have followed suit with the MSI K9ND
MS-9282 and MSI K9SD MS-9185 resp. the M57SLI-S4 models.

Some BIOSes contain a "SLIC", a digital signature placed inside the BIOS by the manufacturer,
for example Dell. This SLIC is inserted in the ACPI table and contains no active code. Computer
manufacturers that distribute OEM versions of Microsoft Windows and Microsoft application
software can use the SLIC to authenticate licensing to the OEM Windows Installation disk
and/or system recovery disc containing Windows software. Systems having a SLIC can be
activated with an OEM Product Key, and they verify an XML formatted OEM certificate against
the SLIC in the BIOS as a means of self-activating. If a user performs a fresh install of Windows,
they will need to have possession of both the OEM key and the digital certificate for their SLIC
in order to bypass activation; in practice this is extremely unlikely and hence the only real way
this can be achieved is if the user performs a restore using a pre-customised image provided by
the OEM.

[edit] The BIOS business

The vast majority of PC motherboard suppliers license a BIOS "core" and toolkit from a
commercial third-party, known as an "independent BIOS vendor" or IBV. The motherboard
manufacturer then customizes this BIOS to suit its own hardware. For this reason, updated
BIOSes are normally obtained directly from the motherboard manufacturer.

Major BIOS vendors include American Megatrends (AMI), Insyde Software, Phoenix
Technologies and Byosoft. Former vendors include Award Software and Microid Research
which were acquired by Phoenix Technologies in 1998. Phoenix has now phased out the Award
Brand name. General Software, which was also acquired by Phoenix in 2007, sold BIOS for Intel
processor based embedded systems.