Editing BIOS (section)

== Operation ==
=== System startup ===
The [[8086]] and [[8088]] start at physical address FFFF0h.<ref>{{cite web|url = http://bitsavers.org/components/intel/_dataBooks/1981_iAPX_86_88_Users_Manual.pdf|title=iAPX 86,88 User's Manual|at=System Reset, p. 2-29, table 2-4|publisher=[[Intel]]|year=1981|access-date=April 15, 2018}}</ref> The [[80286]] starts at physical address FFFFF0h.<ref>{{cite web|url=https://en.wikichip.org/w/images/3/3e/AMD_80286_Datasheet_%28November_1985%29.pdf|title=AMD 80286 Datasheet|at=p. 13|publisher=[[AMD]]|quote=the 286 begins execution in real mode with the instruction at physical location FFFFF0H.|year=1985}}</ref> The [[80386]] and later x86 processors start at physical address FFFFFFF0h.<ref>{{cite web|url=http://bitsavers.org/components/intel/80386/230985-003_386DX_Microprocessor_Programmers_Reference_Manual_1990.pdf|title=80386 Programmer's Reference Manual|at=Section 10.1 Processor State After Reset, pages 10-1 - 10.3|publisher=Intel|year=1990}}</ref><ref>{{cite web|url = http://bitsavers.org/components/intel/80386/230985-003_386DX_Microprocessor_Programmers_Reference_Manual_1990.pdf|title=80386 Programmer's Reference Manual|at=Section 10.2.3 First Instruction, p. 10-4|publisher=Intel|quote=Execution begins with the instruction addressed by the initial contents of the CS and IP registers. To allow the initialization software to be placed in a ROM at the top of the address space, the high 12 bits of addresses issued for the code segment are set, until the first instruction which loads the CS register, such as a far jump or call. As a result, instruction fetching begins from address 0FFFFFFF0H.|year=1990|accessdate=November 3, 2013}}</ref><ref>{{cite web | url=http://download.intel.com/products/processor/manual/325462.pdf | at=Section 9.1.4 First Instruction Executed, p. 2611 | publisher=Intel | title=Intel® 64 and IA-32 Architectures Software Developer's Manual | date=May 2012 | accessdate=August 23, 2012 | quote=The first instruction that is fetched and executed following a hardware reset is located at physical address FFFFFFF0h. This address is 16 bytes below the processor’s uppermost physical address. The EPROM containing the software-initialization code must be located at this address. | archive-url=https://web.archive.org/web/20120808162037/http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf | archive-date=2012-08-08 | url-status=dead}}</ref> When the system is initialized, the first instruction of the BIOS appears at that address.

If the system has just been powered up or the reset button was pressed ("[[cold boot]]"), the full [[power-on self-test]] (POST) is run. If Ctrl+Alt+Delete was pressed ("[[Reboot|warm boot]]"), a special flag value stored in [[nonvolatile BIOS memory]] ("[[CMOS]]") tested by the BIOS allows bypass of the lengthy POST and memory detection.

The POST identifies, tests and initializes system devices such as the [[central processing unit|CPU]], [[chipset]], [[random-access memory|RAM]], [[motherboard]], [[video card]], [[computer keyboard|keyboard]], [[computer mouse|mouse]], [[hard disk drive]], [[optical disc drive]] and other [[computer hardware|hardware]], including [[integrated peripheral]]s.

Early IBM PCs had a routine in the POST that would download a program into RAM through the keyboard port and run it.<ref name="technical-ref-5-27"/><ref>{{cite web | title = IBM 5162 PC XT286 TechRef 68X2537 Technical Reference manual | date = August 1986 | page = 35 (System BIOS A-5) | url = http://www.reenigne.org/crtc/PC-XT.pdf | access-date = 2014-12-11 |url-status = live| archive-url = https://web.archive.org/web/20141211141709/http://www.reenigne.org/crtc/PC-XT.pdf | archive-date = 2014-12-11 }}</ref> This feature was intended for factory test or diagnostic purposes.

After the motherboard BIOS completes its POST, most BIOS versions search for option ROM modules, also called BIOS extension ROMs, and execute them. The motherboard BIOS scans for extension ROMs in a portion of the "[[upper memory area]]" (the part of the x86 real-mode address space at and above address 0xA0000) and runs each ROM found, in order. To discover memory-mapped option ROMs, a BIOS implementation scans the real-mode address space from <code>0x0C0000</code> to <code>0x0F0000</code> on 2&nbsp;[[kilobyte|KB]] (2,048 bytes) boundaries, looking for a two-byte ROM ''signature'': 0x55 followed by 0xAA. In a valid expansion ROM, this signature is followed by a single byte indicating the number of 512-byte blocks the expansion ROM occupies in real memory, and the next byte is the option ROM's [[entry point]] (also known as its "entry offset"). If the ROM has a valid checksum, the BIOS transfers control to the entry address, which in a normal BIOS extension ROM should be the beginning of the extension's initialization routine.

At this point, the extension ROM code takes over, typically testing and initializing the hardware it controls and registering [[interrupt vector]]s for use by post-boot applications. It may use BIOS services (including those provided by previously initialized option ROMs) to provide a user configuration interface, to display diagnostic information, or to do anything else that it requires.

An option ROM should normally return to the BIOS after completing its initialization process. Once (and if) an option ROM returns, the BIOS continues searching for more option ROMs, calling each as it is found, until the entire option ROM area in the memory space has been scanned. It is possible that an option ROM will not return to BIOS, pre-empting the BIOS's boot sequence altogether.

=== Boot process ===
[[File:Legacy BIOS boot process fixed.png|thumb|493x493px|Boot process|none]]
After the POST completes and, in a BIOS that supports option ROMs, after the option ROM scan is completed and all detected [[Read-only memory|ROM]] modules with valid [[Checksum|checksums]] have been called, the BIOS calls [[BIOS interrupt call#Interrupt table|interrupt 19h]] to start boot processing. Post-boot, programs loaded can also call interrupt 19h to reboot the system, but they must be careful to disable interrupts and other asynchronous hardware processes that may interfere with the BIOS rebooting process, or else the system may hang or crash while it is rebooting.

When interrupt 19h is called, the BIOS attempts to locate [[boot loader]] software on a "boot device", such as a [[hard disk]], a [[floppy disk]], [[CD]], or [[DVD]]. It loads and executes the first boot [[software]] it finds, giving it control of the PC.<ref name="hsw1"/>

The BIOS uses the boot devices set in [[Nonvolatile BIOS memory]] ([[CMOS]]), or, in the earliest PCs, [[DIP switch]]es. The BIOS checks each device in order to see if it is bootable by attempting to load the first sector ([[boot sector]]). If the sector cannot be read, the BIOS proceeds to the next device. If the sector is read successfully, some BIOSes will also check for the boot sector signature 0x55 0xAA in the last two bytes of the sector (which is 512 bytes long), before accepting a boot sector and considering the device bootable.{{efn|The signature at offset <code>+0x1FE</code> in boot sectors is <code>0x55 0xAA</code>, that is <code>0x55</code> at offset <code>+0x1FE</code> and <code>0xAA</code> at offset <code>+0x1FF</code>. Since [[little-endian]] representation must be assumed in the context of [[IBM PC–compatible]] compatible, this can be written as 16-bit word <code>0xAA55</code> in programs for [[Intel x86|x86]] processors (note the swapped order), whereas it would have to be written as <code>0x55AA</code> in programs for other CPU architectures using a [[big-endian]] representation. Since this has been mixed up numerous times in books and even in original Microsoft reference documents,<!-- one example of many: http://technet.microsoft.com/en-us/library/cc977219.aspx as of 2012-01-14 --> this article uses the offset-based byte-wise on-disk representation to avoid any possible misinterpretation.}}

When a bootable device is found, the BIOS transfers control to the loaded sector. The BIOS does not interpret the contents of the boot sector other than to possibly check for the boot sector signature in the last two bytes. Interpretation of data structures like partition tables and BIOS Parameter Blocks is done by the boot program in the boot sector itself or by other programs loaded through the boot process.

A non-disk device such as a [[network adapter]] attempts booting by a procedure that is defined by its [[option ROM]] or the equivalent integrated into the motherboard BIOS ROM. As such, option ROMs may also influence or supplant the boot process defined by the motherboard BIOS ROM.

With the [[El Torito (CD-ROM standard)|El Torito optical media boot standard]], the optical drive actually emulates a 3.5" high-density floppy disk to the BIOS for boot purposes. Reading the "first sector" of a CD-ROM or DVD-ROM is not a simply defined operation like it is on a floppy disk or a hard disk. Furthermore, the complexity of the medium makes it difficult to write a useful boot program in one sector. The bootable virtual floppy disk can contain software that provides access to the optical medium in its native format.

If an expansion ROM wishes to change the way the system boots (such as from a network device or a SCSI adapter) in a cooperative way, 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|date=October 2008}}

Also, if an expansion ROM wishes to change the way the system boots unilaterally, it can simply hook interrupt 19h or other interrupts normally called from interrupt 19h, such as interrupt 13h, the BIOS disk service, to intercept the BIOS boot process. Then it can replace the BIOS boot process with one of its own, or it can merely modify the boot sequence by inserting its own boot actions into it, by preventing the BIOS from detecting certain devices as bootable, or both. Before the BIOS Boot Specification was promulgated, this was the only way for expansion ROMs to implement boot capability for devices not supported for booting by the native BIOS of the motherboard.{{Citation needed|date=October 2014}}

==== Boot priority ====
The user can select the boot priority implemented by the BIOS. For example, most computers have a hard disk that is bootable, but sometimes there is a removable-media drive that has higher boot priority, so the user can cause a removable disk to be booted.

In most modern BIOSes, the boot priority order can be configured by the user. In older BIOSes, limited boot priority options are selectable; in the earliest BIOSes, a fixed priority scheme was implemented, with floppy disk drives first, fixed disks (i.e., hard disks) second, and typically no other boot devices supported, subject to modification of these rules by installed option ROMs. The BIOS in an early PC also usually would only boot from the first floppy disk drive or the first hard disk drive, even if there were two drives installed.

==== Boot failure ====
On the original [[IBM PC]] and XT, if no bootable disk was found, the BIOS would try to start [[IBM BASIC|ROM BASIC]] with the interrupt call to [[BIOS interrupt call#INT 18h: execute BASIC|interrupt 18h]]. Since few programs used BASIC in ROM, clone PC makers left it out; then a computer that failed to boot from a disk would display "No ROM BASIC" and halt (in response to interrupt 18h).

Later computers would display a message like "No bootable disk found"; some would prompt for a disk to be inserted and a key to be pressed to retry the boot process. A modern BIOS may display nothing or may automatically enter the BIOS configuration utility when the boot process fails.

=== Boot environment ===
The environment for the boot program is very simple: the CPU is in real mode and the general-purpose and segment registers are undefined, except SS, SP, CS, and DL. CS:IP always points to physical address <code>0x07C00</code>. What values CS and IP actually have is not well defined. Some BIOSes use a CS:IP of <code>0x0000:0x7C00</code> while others may use <code>0x07C0:0x0000</code>.<ref>{{Cite journal |last=Akeljic |first=Bekir |date=2017-01-01 |title=BIOS BASIC INPUT/ OUTPUT SYSTEM BIOS FUNCTIONS AND MODIFICATIONS |url=https://www.academia.edu/38015589 |url-status=live |journal=BIOS|pages=12 |url-access=subscription |archive-url=https://web.archive.org/web/20220808223747/https://www.academia.edu/38015589/BIOS_BASIC_INPUT_OUTPUT_SYSTEM_BIOS_FUNCTIONS_AND_MODIFICATIONS |archive-date=2022-08-08 |access-date=2022-08-08 |via=INTERNATIONAL UNIVERSITY TRAVNIKFACULITY OF INFORMATION TECHNOLOGY TRAVNIKSOFTWARE PROGRAMMING}}</ref> Because boot programs are always loaded at this fixed address, there is no need for a boot program to be relocatable. DL may contain the drive number, as used with [[INT 13H|interrupt 13h]], of the boot device. SS:SP points to a valid stack that is presumably large enough to support hardware interrupts, but otherwise SS and SP are undefined. (A stack must be already set up in order for interrupts to be serviced, and interrupts must be enabled in order for the system timer-tick interrupt, which BIOS always uses at least to maintain the time-of-day count and which it initializes during POST, to be active and for the keyboard to work. The keyboard works even if the BIOS keyboard service is not called; keystrokes are received and placed in the 15-character type-ahead buffer maintained by BIOS.) The boot program must set up its own stack, because the size of the stack set up by BIOS is unknown and its location is likewise variable; although the boot program can investigate the default stack by examining SS:SP, it is easier and shorter to just unconditionally set up a new stack.<ref>{{Cite web |title=BIOS - CodeDocs |url=https://codedocs.org/what-is/bios |access-date=2022-08-08 |website=codedocs.org |language=en}}</ref>

At boot time, all BIOS services are available, and the memory below address <code>0x00400</code> contains the [[interrupt vector table]]. BIOS POST has initialized the system timers, interrupt controller(s), DMA controller(s), and other motherboard/chipset hardware as necessary to bring all BIOS services to ready status. DRAM refresh for all system DRAM in conventional memory and extended memory, but not necessarily expanded memory, has been set up and is running. The [[interrupt vector]]s corresponding to the BIOS interrupts have been set to point at the appropriate entry points in the BIOS, hardware interrupt vectors for devices initialized by the BIOS have been set to point to the BIOS-provided ISRs, and some other interrupts, including ones that BIOS generates for programs to hook, have been set to a default dummy ISR that immediately returns. The BIOS maintains a reserved block of system RAM at addresses <code>0x00400–0x004FF</code> with various parameters initialized during the POST. All memory at and above address <code>0x00500</code> can be used by the boot program; it may even overwrite itself.<ref>{{Cite web |title=Memory Layout and Memory Map |url=http://flint.cs.yale.edu/feng/cos/resources/BIOS/mem.htm |access-date=2022-08-08 |website=flint.cs.yale.edu}}</ref><ref>{{Cite journal |year=2020 |title=BIOS Data ACPI Table (BDAT) |url=https://uefi.org/sites/default/files/resources/BDAT%20Specification%20v4.0%20Draft5_0.pdf |url-status=live |journal=[[Interface Specification]] |volume=4 |issue=5 |pages=67 |archive-url=https://web.archive.org/web/20210703231310/https://uefi.org/sites/default/files/resources/BDAT%20Specification%20v4.0%20Draft5_0.pdf |archive-date=2021-07-03 |access-date=2022-08-08}}</ref>