Fact-checked by Grok 2 weeks ago

Power-on self-test

The power-on self-test (POST) is a series of diagnostic tests executed by a computer's firmware, such as BIOS or UEFI, immediately upon powering on to verify the presence and basic functionality of essential hardware components, including the processor, memory, and devices required for initial program loading. Introduced as a core function of the ROM-based BIOS in the IBM Personal Computer released in 1981, POST ensures system reliability by detecting faults early in the boot process, a practice that has since been standardized across personal computers, servers, and many embedded systems. In operation, POST sequentially checks hardware integrity—such as memory addressing, interrupt controllers, and basic I/O ports—and upon successful completion, typically signals readiness with a single beep or green LED status before transferring control to the operating system ; any detected issues trigger error indicators like beep codes, LED patterns, or on-screen messages to facilitate targeted diagnostics and repairs.

Overview and Fundamentals

Definition and Purpose

A power-on self-test (POST) is a diagnostic testing sequence performed by a computer's , such as the Basic Input/Output System () or Unified Extensible Firmware Interface (), immediately after power is applied to verify the functionality of essential hardware components before the operating system is loaded. This routine, first implemented in the PC 5150 in 1981, executes automatically upon startup or reset, checking components like the , , and basic devices to ensure they are operational. The primary purposes of POST include early detection of hardware failures to prevent boot failures or system instability, initialization of core hardware such as the CPU, RAM, and peripherals to establish a reliable foundation for subsequent operations, and provision of immediate feedback on system status through indicators like beeps or display codes. In UEFI-based systems, POST similarly involves firmware execution from flash memory to initialize silicon components and verify integrity during the pre-operating system phase. By halting the boot process if critical issues are found, POST serves as a gatekeeper, allowing the system to proceed only when basic integrity is confirmed. Key benefits of POST encompass reduced system downtime through rapid fault isolation, which facilitates targeted and repairs, and its longstanding role in diagnostics since the early , when it became a standard feature in to enhance reliability. This self-diagnostic approach ensures safe progression to operating system loading, minimizing the risk of crashes or from undetected defects.

Historical Development

This practice drew from earlier diagnostic techniques in mainframe computing but became more standardized with the advent of accessible personal systems. The concept was formalized in 1981 with the release of the Personal Computer (model 5150), whose included essential self-testing sequences for , CPU, and basic peripherals, establishing POST as a cornerstone of PC initialization. 's design, detailed in its technical reference materials, significantly influenced the widespread adoption of POST in compatible systems, setting a benchmark for hardware verification in consumer computing. In the 1980s, the explosion of IBM PC clones necessitated compatible BIOS implementations, leading to innovations by third-party developers that expanded POST's scope and reliability. Phoenix Technologies released the first reverse-engineered BIOS in 1984, enabling POST routines to support diverse hardware configurations while maintaining error detection features. This was followed by (AMI) in 1985 with AMIBIOS, which introduced more robust diagnostic checks, and Award Software's offerings later in the decade, which further standardized error reporting through beep codes and on-screen messages to facilitate troubleshooting across clone ecosystems. These advancements ensured POST's compatibility with the growing variety of peripherals, solidifying its role in the burgeoning PC market. The 2000s marked a transitional phase with the development of the , initially conceived by in the mid-1990s for systems and formalized through the UEFI Forum established in 2005. aimed to supersede legacy 16-bit limitations, streamlining by delegating extensive hardware checks to the operating system or modular drivers, thereby significantly reducing boot times, often from tens of seconds to a few seconds in optimized systems. This shift preserved core functions like integrity validation but emphasized and extensibility for modern hardware. By the 2010s, POST evolved further with the integration of secure boot into UEFI specifications, introduced in version 2.3.1 in December 2011 to address rising firmware vulnerabilities such as rootkits targeting boot processes. Secure boot enhanced POST by cryptographically verifying bootloaders and drivers against trusted keys, a feature prominently implemented in Windows 8 in 2012 and refined in response to exploits like those disclosed in early 2010s research on UEFI weaknesses. Post-2020, these principles have been adapted to ARM-based systems and IoT devices, where firmware platforms like Arm's SystemReady certification incorporate lightweight self-tests for secure, efficient booting in resource-constrained environments.

General Process

Initialization Sequence

The power-on self-test (POST) initiates immediately upon the application of power to the system, triggered by the CPU reset signal that vectors the processor to the starting address in the , typically stored in (ROM) or . This reset clears the CPU and begins execution of the firmware's initialization , ensuring a clean start for hardware verification. The core initialization sequence follows a prioritized order, beginning with essential setup. First, the performs a , initializing the CPU by verifying its type, configuring registers, and disabling non-maskable interrupts (NMI) to prevent premature disruptions. Next, the is established, followed by a comprehensive RAM test that involves sizing the available , enabling refresh cycles, and writing/reading specific patterns (such as marching ones or zeros) to each to detect faults like stuck bits or addressing errors. If faults are identified during the memory test, the process halts or reports them before proceeding. Subsequent steps focus on system infrastructure and connectivity. The registers are programmed with initial values, and buses—such as the PCI bus—are enumerated to detect and configure connected hardware components. This includes initializing (DMA) controllers and identifying legacy devices. Peripheral detection then occurs, systematically checking for devices like the (via basic assurance test or BAT commands), video adapters (configuring modes and testing video ), and controllers (resetting floppy and hard disk interfaces). Finally, the interrupt controller (e.g., 8259 ) and circuits (e.g., 8254 ) are set up to handle system events and timing accurately. Upon successful completion of these steps, the POST concludes by preparing the environment, such as building vectors and selecting the boot device, transitioning control to the operating system loader. The sequence is designed to be adaptable based on system scale and configuration, always prioritizing critical components like the CPU and memory to minimize boot time, though the full process typically spans 1-10 seconds depending on complexity and the extent of testing enabled. Errors encountered during these steps may trigger audible signals or diagnostic codes for further .

Hardware Diagnostics

The hardware diagnostics phase of the power-on self-test (POST) begins with a verification of the (CPU), ensuring its fundamental operations are intact before proceeding to other components. This involves executing a series of self-check loops that test basic instructions, processor registers, and clock speed. For instance, the CPU is instructed to perform and , with results compared against expected outputs to detect faults in internal logic or timing mechanisms. If discrepancies arise, such as incorrect register values or mismatched clock frequencies, the test flags the error for further handling. Memory diagnostics follow the CPU check, focusing on random access memory (RAM) integrity to prevent data corruption during system operation. Address line integrity is assessed by writing unique patterns to specific locations and verifying retrieval, often using a "walking ones" method where a single bit is set to 1 while others are 0, then shifted across all address bits to isolate stuck or shorted lines. Data pattern writes, such as alternating ones and zeros or complementary patterns, are then applied across the memory array to detect bit flips or coupling errors. Systems with parity or error-correcting code (ECC) memory include validation of these mechanisms by inducing simulated errors and confirming correction or detection. These tests ensure reliable storage and retrieval, with comprehensive coverage of installed modules to identify defective cells early. Input/output (I/O) and peripheral probing occurs next, systematically scanning system buses for connected devices and confirming basic functionality. The firmware probes standard ports and expansion slots, such as those for video adapters, by sending initialization signals and checking responses; for example, a video adapter test may involve writing to display memory and verifying output via a POST diagnostic card inserted into an expansion slot. Similar checks are performed for storage devices like floppy or hard drives, where seek commands are issued to confirm and head positioning, and for USB controllers, which are enumerated to detect attached hubs or devices through protocol handshakes. These probes establish device presence and minimal operability without deep . In modern systems, advanced checks extend diagnostics to performance-critical and safety features. Cache validation involves flushing and reloading data patterns into CPU caches (, , or L3 levels) to test tag arrays, associativity, and logic, ensuring no silent during high-speed operations. BIOS shadowing copies code from (ROM) to faster system , verifying the transfer integrity by comparison to accelerate subsequent accesses. Environmental sensors for temperature and voltage are also interrogated, reading values against predefined thresholds to detect anomalies like overheating or instability that could compromise longevity. Failure thresholds dictate the diagnostic flow, with critical errors prompting an immediate halt to prevent unsafe operation. For example, if no is detected during the RAM test—due to absent or incompatible modules—the halts with an explicit , as continued execution without viable would lead to . Non-essential faults, such as a missing USB controller, allow POST to proceed, logging the issue for later review while configuring the around the deficiency. This tiered approach balances thoroughness with reliability.

Error Reporting Methods

Audible Signals

Audible signals during the power-on self-test (POST) are produced by a small piezoelectric integrated into the or connected via dedicated header pins, allowing the to output tonal patterns independent of the main audio subsystem. These beeps are triggered when the firmware detects issues that halt the boot process, using simple to vary duration and frequency for encoding error information, particularly useful in scenarios without display output. The patterns typically consist of short and long beeps separated by pauses, where a single short beep indicates a successful POST completion and readiness to proceed to the operating system loader. More complex sequences signal failures; for instance, one long beep followed by two short beeps commonly denotes a video adapter error, such as improper seating or malfunction. Continuous or repeating beeps often point to power supply problems, like insufficient voltage or overheating. These conventions stem from early PC standards but have been adapted by vendors for broader diagnostics. BIOS implementations from major vendors feature proprietary beep schemes to specify error types. In AMI BIOS, sequences range from 1 to 11 short beeps, with three short beeps indicating a base 64K failure and five short beeps signaling errors. Award BIOS employs similar tonal variations, where one long and three short beeps suggest video issues, while high-frequency repeating beeps highlight CPU or problems. Phoenix BIOS uses grouped codes, such as 1-1-3 for refresh failures or 1-2-2-3 for errors, often represented as numeric patterns for reference. With the shift to UEFI firmware, audible signals can be suppressed entirely or customized through setup menus, as modern systems prioritize graphical interfaces and LED diagnostics over audio output. This reflects broader trends in hardware design. Despite their utility, beep codes have inherent limitations, requiring users to recall or consult vendor-specific manuals for interpretation, which can delay in field scenarios. Additionally, they are increasingly irrelevant in contemporary systems without onboard speakers, where silent operation and alternative reporting methods prevail.

Visual and Diagnostic Codes

Visual and diagnostic codes in power-on self-test (POST) provide non-audible feedback on system initialization progress and hardware issues, typically through light-emitting diodes (LEDs), textual displays, or specialized hardware tools. These methods allow users or technicians to identify failures without relying on sound, complementing audible signals in environments where noise is impractical. Motherboard LED indicators are a common visual method, often consisting of a series of small lights labeled for components like power, CPU, DRAM, and VGA, which illuminate sequentially to show POST stages. For instance, during successful boot, the power LED lights first, followed by CPU, then DRAM, and finally boot device, indicating normal progression; if a stage fails, the corresponding LED remains lit or flashes in patterns to signal errors such as memory faults. These debug LEDs, popularized in consumer motherboards since the early 2000s, enable quick troubleshooting without advanced tools. On-screen messages appear after video initialization, displaying textual updates or error notifications on the connected to the graphics adapter. Common progress indicators include phrases like "Verifying DMI Pool Data," which confirms system inventory checks, while error strings such as " checksum error" alert to corrupted configuration data requiring replacement or reset. These messages, generated by or , provide descriptive diagnostics during the limited pre-boot environment before the operating system loads. Diagnostic cards, also known as cards, are hardware adapters inserted into or PCIe expansion slots to decode and display codes (ranging from 00 to FF) corresponding to specific POST routines or failures. For example, code 61 typically indicates a controller error, while 00 might signify a successful pass; users consult the card's manual or documentation to map codes to issues like CPU or problems. These tools, essential for headless systems or silent failures, originated in the 1980s for PC diagnostics and remain useful for . In modern UEFI-based systems, visual POST feedback has evolved to include progress bars in user-friendly BIOS interfaces, which graphically represent boot phases for easier monitoring, and advanced features like QR codes displayed on-screen for quick access to error logs via mobile apps. For instance, some implementations generate scannable QR codes linking to detailed diagnostic reports on manufacturer sites, enhancing remote . App integrations, such as those in Intel's Management Engine, allow logging and visualization over networks, reducing reliance on physical indicators.

Implementations in Personal Computers

IBM-Compatible PCs

The Power-on self-test (POST) in IBM-compatible PCs began with the original PC model 5150 introduced in 1981, where the ROM-BIOS included an initial 8-bit diagnostic routine to verify basic hardware functionality such as the CPU, , and I/O ports before loading the operating system. This early implementation was limited by the 8088 processor's architecture and the system's modest 16 KB to 640 KB capacity, focusing on simple checks like errors and controller initialization to ensure compatibility with expansion cards on the bus. Over time, as PC clones proliferated in the 1980s, third-party BIOS vendors like and developed compatible that maintained with legacy ISA hardware, including support for 8-bit and 16-bit expansion slots by scanning and initializing option ROMs during POST. In legacy BIOS systems prevalent through the 1990s and early 2000s, the POST process involved a detailed initialization sequence, starting with CPU and setup, followed by an extended memory test that wrote patterns to and read from RAM locations beyond the first 1 to detect faults in conventional and areas. This test, often configurable in setup menus, could take several seconds on systems with gigabytes of RAM and was crucial for identifying defective modules before . The then scanned for option ROMs in the C0000-EFFFF range, executing initialization code from add-on cards like network adapters or controllers to integrate them into the system. For testing purposes, emulators like replicate this x86 environment, loading to simulate POST execution and allowing developers to debug without physical hardware. Modern IBM-compatible PCs have transitioned to firmware since the mid-2000s, which minimizes tests in "fast boot" modes to reduce startup time from tens of seconds to under 10 by skipping redundant checks like full testing, relying instead on prior validation from the operating hibernate . integrates with for power management, passing control to the OS after abbreviated diagnostics while exposing tables for dynamic , enabling features like S3 states without reinitializing all components on resume. Error reporting in IBM-compatible POST varies by BIOS vendor but commonly uses audible beep patterns or hexadecimal codes displayed via debug cards inserted into ISA or PCI slots. For AMI BIOS, widely used in clone systems, a pattern of one long beep followed by three short beeps indicates a conventional or extended memory failure, often due to faulty RAM modules. In Phoenix BIOS implementations, the 1-1-3 beep code (one short, pause, one short, pause, three short) signals a CMOS RAM checksum error, though CompTIA A+ certification materials highlight similar patterns like 1-1-3 for base memory read/write failures as common RAM diagnostics. Debug cards capture POST progress codes output to I/O port 80h; for example, in AMI firmware, code 0x32 during CPU post-memory initialization may indicate processor-related issues if the system halts there, while Award BIOS variants ensure ISA bus compatibility by adding latency cycles during POST to accommodate slower legacy peripherals.

Apple Macintosh Systems

The Power-on self-test (POST) on Apple Macintosh systems has evolved significantly across hardware generations, reflecting the company's shift from proprietary ROM-based firmware to more standardized and secure boot architectures. In early models, known as Old World Macs (pre-1998), the POST was handled by dedicated ROM code on the logic board, which performed hardware diagnostics including memory, CPU, and peripheral checks during system initialization. Successful completion displayed the iconic "Happy Mac" smiling face on a blank screen, signaling readiness for the operating system loader, while failures triggered the "Sad Mac" frowning icon accompanied by a distinctive error chime to indicate issues like faulty RAM or logic board problems. These systems also incorporated keyboard-based cues during POST, such as requiring a key press to test or disable system extensions, providing users with interactive feedback on software compatibility. With the introduction of Macs in 1998-1999, Apple transitioned to , an IEEE 1275-compliant system that replaced much of the traditional with a more modular Forth-based interpreter for . The in this era involved dynamic device tree probing, where scanned buses and peripherals to construct a hierarchical representation of the hardware configuration before loading the OS. Users observed a gray screen during these tests, a visual indicator of ongoing diagnostics without the previous iconic animations, emphasizing a cleaner, more abstracted boot process. Subsequent New World models from 1999 onward integrated Mac OS elements directly into the or boot volume, streamlining the by combining hardware checks with early OS components like the nanokernel for handling and loading. Startup tones varied by model to signify completion or errors, often a melodic for success, while disk checks were visualized through a spinning with a , probing for bootable volumes and reporting failures via extended tones or icons. The shift to Intel-based Macs in 2006 introduced EFI (Extensible Firmware Interface) as the foundation for POST, replacing with a UEFI-compliant implementation that verified firmware integrity before enumerating hardware components, including Core i-series CPUs via ACPI tables and bus scans. , activated by holding Command-V during startup, displayed detailed text logs of the POST sequence, aiding troubleshooting of hardware enumeration and driver initialization. Models with the T2 Security Chip added secure boot layers, where the chip authenticated EFI firmware and performed initial diagnostics before handing off to the Intel CPU. Apple Silicon Macs, introduced in 2020, employ an ARM-based architecture with integrated processing for , executing code from audited to verify the chain and perform diagnostics in a highly secure, unified manner. The process features minimal visual feedback due to rapid execution—often completing in seconds without a —prioritizing speed and security over user-visible indicators, with errors logged internally for retrieval via macOS tools like Apple Diagnostics (invoked by holding the power button or D key). The handles cryptographic verification of system components, ensuring tamper-resistant diagnostics even in failure states.

Amiga Computers

The Power-on self-test (POST) in computers was implemented within the Kickstart ROM, which upon power-up initialized and tested core hardware components including the 68000-series CPU, CHIP RAM, and custom chips such as Agnus and Denise. The sequence began with the ROM loading and disabling interrupts while clearing registers, followed by targeted diagnostics; progress during successful execution was visually indicated through rapid full-screen color changes from black (reset) to dark gray (hardware check passed), light gray (RAM test passed), and white (initialization complete), allowing brief monitoring of the boot process before advancing to the operating system. Any failure halted execution and displayed a persistent error color tied to the affected component. In primary models such as the A500, A1200, and A2000, error reporting used specific colors to indicate faults: red for Kickstart ROM errors, green for Chip issues, blue for custom chip problems (e.g., Agnus, Denise, Paula), and yellow for CPU exceptions before error trapping. The absence of errors resulted in the standard gray-to-white progression without halting. The used a similar process with the standard gray progression for normal boot but included additional error colors for its enhanced , such as cyan for early Kickstart version errors and magenta for single-task or cold-start initialization failures, alongside the core CPU, , and custom chip diagnostics. Failures resulted in a solid error color halt to isolate the issue. Amiga POST eschewed audible signals in favor of purely visual and LED-based reporting to align with the system's multimedia-oriented design. Keyboard LEDs served as secondary indicators, blinking in specific patterns for detected faults—such as activation for errors and for failures—enabling precise diagnosis without external tools.

Embedded and Other Systems

Embedded Systems POST

In embedded systems, the power-on self-test (POST) is typically minimalist and automated, designed for resource-constrained environments without user interfaces, prioritizing quick verification of essential hardware to ensure operational readiness. Unlike comprehensive PC diagnostics, embedded POST focuses on core components such as the microcontroller unit (MCU), , and integrated sensors, often integrated into real-time operating systems (RTOS) or bare-metal to minimize boot time and power consumption. For instance, in based microcontrollers, POST commonly includes (CRC) computations on code and to detect corruption before execution. This approach ensures reliability in applications like wearables and industrial controls, where failures must be contained without external intervention. Specific implementations vary by domain but emphasize targeted tests for connectivity and peripherals. In (IoT) devices, POST routines verify wireless modules such as or by performing basic transmission tests and checking loading, such as verifying firmware images via hash or signature checks in ESP32-based systems. Automotive electronic control units (ECUs) extend this to bus validation, such as confirming Controller Area Network (CAN) transceiver functionality through messages during initialization, critical for vehicle safety systems. These tests are designed to meet real-time constraints, contrasting with the more elaborate sequences in . Error reporting in embedded POST diverges from audible or visual displays, relying instead on non-intrusive methods suited to headless deployments. Common indicators include patterned LED blinks for fault categorization or console logs for during , while production units may implement silent failures with automatic power-cycling retries to maintain uptime. In safety-critical contexts like devices, POST may trigger timers for unrecoverable errors, ensuring system isolation without user notification. Unlike standardized codes in personal computers, embedded POST lacks uniform error protocols, with designs favoring robustness and over detailed diagnostics due to deployment in inaccessible locations. This emphasis on reliability supports the proliferation of systems in fields from smart grids to , where continuous operation outweighs comprehensive troubleshooting.

Firmware Variations

Legacy BIOS implementations typically execute a full power-on self-test (POST) that includes comprehensive hardware diagnostics, such as memory checks and peripheral initialization, which can result in slower boot times due to the sequential and thorough nature of these tests. In contrast, the Unified Extensible Firmware Interface (UEFI) introduces a modular architecture for POST, allowing for optional fast boot modes that skip non-essential tests like extensive memory verification or legacy compatibility checks to accelerate the pre-OS phase. This design enables UEFI systems to achieve quicker initialization, often reducing boot times by streamlining hardware enumeration while maintaining core integrity verification. Open-source firmware alternatives further optimize POST for specific use cases. , an open-source replacement, minimizes POST duration to milliseconds by performing only essential hardware initialization and relying on pre-validated configurations or cached data from prior boots, thereby avoiding redundant testing on stable components. Similarly, U-Boot, widely used in embedded systems and routers, integrates network boot capabilities directly into its POST routine, enabling seamless retrieval of boot images over protocols like TFTP or HTTP without additional hardware intervention. Secure variants of firmware enhance POST with integrity-focused mechanisms. Measured Boot, implemented in Trusted Platform Module (TPM)-enabled systems, extends the POST process by computing and storing cryptographic hashes of firmware and boot components in the TPM's Platform Configuration Registers (PCRs), allowing remote attestation of the boot chain's integrity post-execution. For ARM-based mobile devices and System-on-Chips (SoCs), ARM Trusted Firmware (TF-A) incorporates secure boot during POST by verifying digital signatures on firmware images through its BL2 stage, ensuring a trusted execution environment before loading the operating system. Emerging trends in the incorporate advanced techniques into . In cloud virtual machines, zero-touch provisioning automates and deployment, enabling rapid instance spin-up in scalable environments.

References

  1. [1]
    Troubleshooting Common Boot Failures - AMD
    When a PC is turned on, a set of diagnostic tests known as the Power-On-Self-Test (POST) are performed to verify that all required hardware components are ...
  2. [2]
    General diagnostic information - IBM
    Jan 23, 2023 · Power-on self-test. Power-On Self-Test (POST) programs check the devices that are needed to accomplish an initial program load. The POST also ...
  3. [3]
    3.4: Reading- Booting - Workforce LibreTexts
    Nov 13, 2021 · The IBM Personal Computer included ROM-based firmware called the BIOS; one of the functions of that firmware was to perform a power-on self test ...
  4. [4]
    Diagnostic tool overview - PC Server 330 - IBM
    Jan 28, 2019 · Power-On Self-Test (POST): Each time you power-on the system, it performs a series of tests that check the operation of the system and some ...<|control11|><|separator|>
  5. [5]
    POST error messages, event, and error log overview - IBM
    This series of tests is called the power-on self-test or POST. If POST finishes without detecting any problems, a single beep sounds and the first screen of ...
  6. [6]
    What is Power-On Self-Test (POST)? - TechTarget
    Aug 2, 2022 · A Power-On Self-Test (POST) is an operation initiated by a computer after it has been turned on but before it boots up the OS.
  7. [7]
    What is POST(Power-On-Self-Test)? - GeeksforGeeks
    Jun 3, 2020 · A power-on self-test (POST) is a set of routines performed by firmware or software immediately after a computer is powered on, to determine if the hardware is ...
  8. [8]
    [PDF] IBM PC Technical Reference - Bitsavers.org
    Operation with non-certified peripherals is likely to result in interference to radio and TV reception. First Edition (August 1981). Changes are periodically ...
  9. [9]
    How to Update BIOS - Intel
    The Power-On Self Test, or POST, is the part of this process that determines whether hardware is operating correctly. If an error occurs at this stage, the ...
  10. [10]
    [PDF] Boot Loader Choices for Small and Fast System Initialization ... - Intel
    As part of the power on self test (POST), the system firmware begins to execute out of flash memory to initialize all the necessary silicon components ...
  11. [11]
    Power on Self-Test - an overview | ScienceDirect Topics
    Power-On Self-Test (POST) refers to the routines that run after a computer system is powered on. These routines are designed to check system resources and ...
  12. [12]
    How the IBM PC Won, Then Lost, the Personal Computer Market
    Jul 21, 2021 · On 12 August 1981, at the Waldorf Astoria Hotel in midtown Manhattan, IBM unveiled the company's entrant into the nascent personal computer ...How The Ibm Pc Won, Then... · The Ibm Pc Was A... · Ibm Couldn't Keep Up With...Missing: origins | Show results with:origins
  13. [13]
    philspil66/IBM-PC-BIOS - GitHub
    This is a reconstruction of the original 1981-82 IBM PC BIOS source code using scanning and transcription of the BIOS listings found in the IBM Technical ...<|separator|>
  14. [14]
    The PC BIOS - DOS Days
    The most common BIOS firmware manufacturers aside from IBM themselves were Phoenix Technologies, American Megatrends (AMI), and Award Software. ... AMI and Award ...
  15. [15]
    AMIBIOS - The SoftHistory Wiki!
    AMIBIOS, commonly stylized as AMI BIOS, is a personal computer BIOS firmware. It was initially released by Access Methods Inc. in 1985 and later acquired ...
  16. [16]
    The PC's BIOS (Basic Input/Output System) and Beyond
    Due to the increased complexity of even decades old BIOS code, completing these items came to be known as the POST (Power On Self Test), since the BIOS also ...<|control11|><|separator|>
  17. [17]
    UEFI - OSDev Wiki
    The original EFI was developed in the mid-1990s by Intel for use developing firmware/BIOS for Itanium platforms. In 2005 Intel transitioned the specification to ...UEFI App Bare Bones · Posix-uefi · Debugging UEFI applications...
  18. [18]
    The history of BIOS and UEFI - DEV Community
    Jan 8, 2021 · UEFI. In 2005, the Unified Extensible Firmware Interface (UEFI) was born as a firmware specification for various platforms including PCs.
  19. [19]
    [PDF] UEFI Secure Boot Customization - DoD
    Mar 20, 2023 · Notices and history ... Secure Boot is a feature added to UEFI specification 2.3.1. Each ...
  20. [20]
    [PDF] UEFISECURE BOOT IN MODERN COMPUTER SECURITY ...
    Most authors of articles describing these vulnerabilities of the UEFI interfaces indicate that a solution like Secure Boot is needed to prevent these attacks.
  21. [21]
    Running Malware Below the OS - The State of UEFI Firmware ...
    They were only really viable threats in the early 2010s. ... Boot Services are exited, allowing for the complete circumvention of UEFI Secure Boot.
  22. [22]
    Test SystemReady IR - Arm Developer
    This guide tells you how to prepare for SystemReady IR IoT system certification in the Arm SystemReady Certification Program.Missing: POST | Show results with:POST
  23. [23]
    [PDF] PhoenixBIOS 4.0 Release 6.0 POST Tasks and Beep Codes
    At the beginning of each POST task, the BIOS outputs the test-point error code to I/O port 80h. Programmers and technicians use this code during trouble ...
  24. [24]
    [PDF] AMIBIOS POST Checkpoint Codes - acelab.ru
    Power on delay is starting. Next, the initialization code checksum will be verified. D1h. Initializing the DMA controller, performing the keyboard controller ...Missing: steps | Show results with:steps
  25. [25]
    Hardware Diagnostics and Power on Self Tests - EventHelix
    This test checks the internal working of the CPU. This test is run by executing processor instructions and then verifying the output of the instruction. All the ...Missing: methodology | Show results with:methodology
  26. [26]
    Software Based Memory Testing - EmSA
    This article shows how to test for the most common memory problems with a set of three efficient, portable, public-domain memory test functions.
  27. [27]
    Cache test - IBM
    Runs all tests in this menu in current mode. This test performs a walking 1 in a field of zeroes and a walking 0 in a field of ones. This test is repeated at ...Missing: POST zeros
  28. [28]
    C H A P T E R 11 - Power-On Self-Test - Oracle Help Center
    Power-on self-test (POST) performs tests on workstation core components such as CPU and memory. POST checks low-level interaction between the CPU, caches, ...
  29. [29]
    [PDF] AWARD BIOS Code (hex) Name C0 Turn Off Chipset Cache 01 ...
    AWARD BIOS. Code. (hex) Name. C0 Turn Off Chipset Cache. 01 Processor Test 1. 02 Processor Test 2. 03 Initialize Chips. 04 Test Memory Refresh Toggle.<|separator|>
  30. [30]
    What is BIOS Shadowing? - rigacci.org
    Shadowing refers to the technique of copying BIOS code from slow ROM chips into faster RAM chips during boot-up so that any access to BIOS routines will be ...
  31. [31]
    [PDF] System Event Log (SEL) - Troubleshooting Guide - Intel
    Apr 8, 2022 · The System Event Log (SEL) is a troubleshooting guide for events generated by Intel server boards based on 1st or 2nd Gen Intel Xeon Scalable ...Missing: validation | Show results with:validation
  32. [32]
    No memory is available. If DIMMs are installed, verify ... - HPE Support
    Memory configuration error: No memory is available. If DIMMs are installed, verify that the DIMMs are installed properly. System Halted!
  33. [33]
    Does the BIOS beep come from the same sound hardware channel
    Jul 14, 2010 · No. Motherboards either have a small speaker on the motherboard or have pins on the motherboard that connect to a small speaker on the case to make the beep.Missing: mechanism | Show results with:mechanism
  34. [34]
    What is beep code? | Definition from TechTarget
    Apr 17, 2023 · After a computer first powers on and performs the power on self test (POST), it emits an audio signal called a beep code.
  35. [35]
    What Happens When You Press the Power Button? - AMI
    Feb 5, 2018 · If POST returns with errors, the boot process will stop and beep codes will help indicate what problems are affecting the boot process. 3 ...
  36. [36]
    Computer POST and Beep Codes
    Jul 13, 2023 · Computer beep codes and POST issues, covering AMI, Award, Dell, IBM, and Phoenix BIOS. Learn to troubleshoot beep codes and identify ...POST Troubleshooting Steps · Base 64 K RAM failure. · My Video Card Isn't Working<|separator|>
  37. [37]
    AwardBIOS Beep Codes: A Common List - Lifewire
    Jan 10, 2023 · A single short beep is normal. One long, two short beeps indicates video card issues. Repeating high/low beeps mean CPU problems. Other codes ...
  38. [38]
    PhoenixBIOS Beep Code Troubleshooting - Lifewire
    Jul 27, 2022 · A 1-2-2-3 beep code pattern means that there has been a BIOS ROM checksum error. Literally, this would indicate an issue with the BIOS chip on ...Missing: sequence | Show results with:sequence
  39. [39]
    Do UEFI Mobos have beep codes? - Super User
    Jun 5, 2015 · Beep codes are a per-manufacturer decision and system. There is nothing about UEFI specifically which prevents or does not support beep codes.Why does my computer beep when I turn it on? What are these beep ...Asus EFI BIOS beep error codes - Super UserMore results from superuser.comMissing: suppression | Show results with:suppression
  40. [40]
    Why Do Some Motherboards No Longer Have Speaker Connectors?
    Oct 30, 2024 · The old BIOS beep codes , gone , mostly due to UEFI being predominant now. You are usually able to get a readout on the screen from UEFI or from ...
  41. [41]
    Step-By-Step: Deciphering BIOS beep codes - TechRepublic
    Mar 7, 2002 · Another option is to purchase a POST diagnostic card to intercept POST errors at their source via the ISA or PCI bus. Cards are available for ...
  42. [42]
    [PDF] 1502234_PC_Technical_Refere...
    The IBM Personal Computer Technical Reference manual describes the hardware design and provides interface information for the IBM Personal Computer. This ...
  43. [43]
    Pinczakko's Guide to Award BIOS Reverse Engineering - Google Sites
    It provides a thorough tutorial on Award BIOS version 6.00PG reverse engineering as well as AMI BIOS version 8 reverse engineering.
  44. [44]
    System Initialization of Intel x86 with BIOS Firmware - Gentoo Wiki
    Oct 5, 2023 · Verifies the integrity of the BIOS code, typically with a simple checksum. Initialize RAM, prior to this step the CPU may only have its ...
  45. [45]
    [PDF] NIST SP 800-147, BIOS Protection Guidelines
    This includes Option ROMs and UEFI drivers that are stored with the system BIOS firmware and are updated by the same mechanism. It does not apply to Option ROMs ...
  46. [46]
    QEMU User Documentation
    Jun 17, 2006 · The QEMU PC System emulator simulates the following peripherals: SMP is supported with a large number of virtual CPUs (upper limit is configuration dependent).Missing: POST | Show results with:POST
  47. [47]
    [PDF] Clarifying the Ten Most Common Misconceptions About UEFI
    One can verify the boot process timing with a stopwatch: Start the watch while pressing the system. “power on” button and stop the watch when the OS splash ...
  48. [48]
    5. ACPI Software Programming Model - UEFI Forum
    ACPI defines a hardware register interface that an ACPI-compatible OS uses to control core power management features of a machine.
  49. [49]
    AMI Support & Additional Sources
    Aptio 4 Checkpoint and Beep Codes. Standard checkpoint codes and beep codes generated by Aptio 4.x core firmware.<|separator|>
  50. [50]
    [PDF] AMI BIOS POST Codes Supermicro C7/X9/X10/X11/B9/B10/B1/A1 ...
    Aug 1, 2014 · This document lists the AMI BIOS POST codes for Supermicro's C7/X9/X10/X11/. B9/B10/B1/A1 motherboards. The contents included in this document ...
  51. [51]
    [PDF] Award BIOS Setup
    Quick Power On Self Test. Select Enabled to reduce the amount of time required to run the power-on-self-test (POST). A quick POST skips certain steps. We.<|separator|>
  52. [52]
    [PDF] Start Manager - Apple Developer
    This chapter describes the system initialization and system startup process performed by the Macintosh computer. It describes the Start Manager, ...
  53. [53]
    Page Not Found - Apple Developer
    No readable text found in the HTML.<|separator|>
  54. [54]
    If your Mac beeps during startup - Apple Support
    Mar 20, 2025 · One beep every 5 seconds. Your Mac isn't detecting any memory (RAM). If you recently added or replaced memory, make sure that it's properly installed.
  55. [55]
    Boot process for an Intel-based Mac - Apple Support
    Feb 18, 2021 · When an Intel-based Mac computer with the Apple T2 Security Chip is turned on, the chip performs a secure boot from its Boot ROM in the same fashion as iPhone, ...
  56. [56]
    Mac startup key combinations - Apple Support
    Mar 13, 2025 · Command (⌘)-R: Start up from the built-in macOS Recovery system. Or use Option-Command-R or Shift-Option-Command-R to start up from macOS Recovery over the ...
  57. [57]
    Boot process for a Mac with Apple silicon
    Feb 18, 2021 · When a Mac with Apple silicon is turned on, the chip executes code from read-only memory that is audited and trusted.Missing: POST | Show results with:POST
  58. [58]
    Secure Enclave - Apple Support
    Dec 19, 2024 · When the device starts up, the Secure Enclave Boot ROM generates a random ephemeral memory protection key for the Memory Protection Engine.
  59. [59]
    Amiga boot error code colours - the classicamiga Wiki!
    Dec 17, 2008 · Red - An error in the Kickstart rom as detected. · Green - An error in the Chip Ram was detected. · Blue - An error in the custom chip set was ...
  60. [60]
    Amiga Boot-Up Self Diagnostics - Retro-Programming
    At several points in this sequence the screen color changes. If an error occurs at any point, the sequence stops. The color than changes depending on the error.
  61. [61]
    -- Amiga Error Colours, Blinks and Guru Codes -- - Lemon Amiga
    Nov 29, 2016 · Change screen colour to Green if RAM is faulty, or change to Light Grey if RAM is OK. 12. Check to see if the ROM software is coming in OK and ...
  62. [62]
    A4000 boot error colours - Magenta? - Page 1 - Amiga.org
    Jul 18, 2012 · By Magenta do you mean purple? Red = boot ROMs, Blue = custom chips, and Green = Chip ram. These are the initial colors on cold boot. Only OS ...Variation on A4000 dark gray screen problem - Page 1 - Amiga.orga4000 color error codes - Page 1 - Amiga.orgMore results from forum.amiga.orgMissing: self- | Show results with:self-
  63. [63]
    [PDF] Hardvvare Reference Manual - iKod.se
    Page 1. Page 2. Page 3. Hardvvare Reference Manual. Third Edition. Commodore-Amiga, Inc. AMIGA TECHNICAL REFERENCE SERIES ... .,..,. Addison-Wesley Publishing ...
  64. [64]
    hardware:selftest [Amiga FAQ]
    Mar 5, 2010 · SelfTest Output · Dark Grey: The hardware test has been completed OK, and the registers are readable. · Light Grey: The software side has passed.
  65. [65]
    Why does UEFI support a faster boot time than BIOS? - Quora
    Jun 3, 2022 · the legacy bios can access to lower 1 MB of system memory only, and uefi worked in Flat mode, thus uefi can access all resource that the system ...What is the difference between UEFI and Legacy Mode ... - QuoraWhat is the difference between UEFI mode and Legacy ... - QuoraMore results from www.quora.com
  66. [66]
    BIOS vs UEFI: The ultimate firmware comparison - SuperOps
    Confused about BIOS vs UEFI? Get a clear breakdown of how the boot process works, the difference between BIOS and UEFI, and which one is the better choice.
  67. [67]
    coreboot FAQ — coreboot 25.09-63-gfba92daed3 documentation
    coreboot's goal is to just initialize the hardware and exit. This makes coreboot smaller and simpler, leading to faster boot times, and making it easier to find ...
  68. [68]
    UEFI HTTP and HTTPs Boot in U-Boot | Blog - Linaro
    Oct 16, 2023 · UEFI HTTP boot simplifies the network boot process by allowing the firmware to retrieve operating system images and EFI executables directly ...
  69. [69]
    Measured boot and host attestation - Azure Security - Microsoft Learn
    Sep 10, 2024 · This article describes how Microsoft ensures integrity and security of hosts through measured boot and host attestation.Measured boot · Host Attestation Service
  70. [70]
    Armed to Boot: an enhancement to Arm's Secure Boot chain
    Jan 25, 2023 · Arm defines a trusted boot process through an architecture called Trusted Board Boot Requirements (TBBR), or Arm Trusted Firmware (ATF) Secure Boot.
  71. [71]
    Firmware development: Redefining root cause analysis with AI - EDN
    Apr 30, 2025 · Below are the AI techniques that streamline the RCA process, speeding up identification of root causes and improving firmware reliability.
  72. [72]
    What is Zero Touch Provisioning (ZTP)? - Scale Computing
    Feb 7, 2024 · The essence of ZTP in the cloud is to enable virtual servers to automatically configure themselves based on predefined templates or policies.Missing: POST | Show results with:POST