The Basic Input/Output System (BIOS) is firmware stored in non-volatile memory on a PC-class motherboard that initializes hardware at power-on and provides a pre-boot and boot-time interface between the operating system and platform hardware. In traditional x86 PC architecture, the BIOS runs before the OS bootloader and is responsible for POST (Power-On Self-Test), basic pre-boot hardware discovery and configuration, and loading boot code from a selected boot device.
In practice
In desktop and server x86 systems, the BIOS (or its successor UEFI) is the first code to execute after reset. It initializes DRAM controllers, PCIe fabric, storage controllers, and other platform hardware before loading a bootloader from a configured boot device. Embedded developers working on x86-based industrial PCs, COM Express modules, or single-board computers running Linux will encounter BIOS/UEFI settings that directly affect boot behavior, hardware availability, and power management.
On microcontroller-class targets (AVR, PIC, STM32, MSP430, etc.), there is no BIOS. The MCU's internal ROM may contain a vendor bootloader or factory-programmed startup code, but this is distinct from a BIOS both architecturally and functionally. The blog post "Boot Sequence for an ARM based embedded system" illustrates how ARM-based embedded systems use a layered bootloader chain (such as SPL + U-Boot) rather than a BIOS to bring up hardware. Similarly, "An overview of Linux Boot Process for Embedded Systems" covers how embedded Linux platforms typically rely on U-Boot or similar bootloaders in the role that a BIOS plays on PC hardware.
A common source of confusion for embedded developers moving between MCU targets and embedded x86 platforms is the scope of hardware initialization the BIOS handles transparently. On an x86 embedded board, DRAM training, PCIe link negotiation, and clock tree setup are completed by the BIOS before the OS or application sees any hardware. On a bare-metal MCU target, the developer or startup code is responsible for all of this explicitly. Mismatched assumptions about what the platform has already initialized can cause subtle bring-up bugs, a category of issue discussed in "The habitat of hardware bugs."
On modern x86 platforms, legacy BIOS has largely been replaced by UEFI (Unified Extensible Firmware Interface), which provides a more structured boot process, support for drives larger than 2 TB (via GPT), Secure Boot, and a richer pre-OS environment. Embedded x86 products sometimes ship with a reduced UEFI or a locked-down BIOS image, and developers may need to interact with it via serial console rather than a graphical setup menu.
Frequently asked
Do microcontrollers have a BIOS?
No. Microcontrollers do not have a BIOS. Some MCUs (for example, the STM32 series) have a factory-programmed ROM
bootloader that can load firmware over
UART,
USB, or
SPI, but this is a narrow-purpose bootloader, not a general-purpose hardware abstraction layer like a BIOS. On ARM-based application processors (such as the i.MX or AM335x families), a multi-stage bootloader chain (SPL, U-Boot) handles hardware init in the role a BIOS fills on x86.
What is the difference between BIOS and UEFI?
BIOS is the legacy x86 firmware standard, limited to 16-bit real-mode execution at startup and MBR-based boot; the familiar 2 TB bootable disk size limit is tied to MBR partition addressing rather than BIOS itself, though the two are closely associated in practice. UEFI is its modern replacement, supporting 32- or 64-bit execution environments, GPT partition tables, Secure Boot, a built-in network
stack, and a standardized driver model. Many x86 embedded boards have migrated to UEFI, though a significant portion of industrial platforms continued shipping with legacy BIOS well after the early 2010s; some UEFI implementations also include a legacy BIOS compatibility (CSM) mode.
Why does BIOS matter to embedded Linux developers?
On x86-based embedded platforms (industrial PCs, COM Express, Mini-ITX boards), the BIOS or UEFI controls hardware enablement, boot device order, Secure Boot policy, serial console redirection, and power-on behavior. Misconfigured BIOS settings are a common cause of board bring-up failures. On non-x86 embedded Linux targets, U-Boot or a similar
bootloader takes on the equivalent role, as covered in 'An overview of Linux Boot Process for Embedded Systems'.
Can the BIOS be updated on embedded x86 boards, and is it risky?
Yes, most x86 embedded boards support BIOS/UEFI firmware updates, typically via a vendor utility, UEFI capsule update, or by flashing the
SPI NOR chip directly. A failed or interrupted update can render the board unbootable ('bricking'), since the BIOS is the first code executed. Some boards mitigate this with a dual-BIOS scheme or a recovery partition. Always verify the update image matches the exact board variant before flashing.
What is POST, and what happens if it fails?
POST (Power-On Self-Test) is a diagnostic sequence the BIOS runs immediately after reset to verify that critical hardware (CPU,
RAM, chipset) is functional. On a PC-class board, POST failure is often signaled by beep codes, LED patterns, or serial console error messages before any OS code runs. In embedded x86 products without a display, developers typically redirect POST output to a
UART or use a BMC (Baseboard Management Controller) to capture early boot diagnostics.
Differentiators vs similar concepts
BIOS vs. UEFI: BIOS is the legacy x86 firmware interface, limited to 16-bit real-mode startup and MBR booting. UEFI is its modern replacement with a richer execution environment, GPT support, and Secure Boot. Most current x86 embedded platforms use UEFI, though the term "BIOS" is still informally used to refer to both. BIOS vs.
bootloader: On non-x86 embedded targets, a bootloader such as U-Boot performs hardware initialization and OS loading, filling a similar functional role but without the standardized hardware abstraction layer or interactive setup menu that a BIOS provides.
