The Hidden Code That Wakes Your Computer Before Windows Does

Firmware lives between chips and software, and it does the jobs neither side can handle alone.

Press the power button.

The CPU resets. Registers clear to zero. The program counter points to a fixed address. No Windows, no Linux, no browser, no app. A piece of code burned into SPI Flash or ROM runs first.

It initializes memory, trains DDR, enumerates PCIe, configures clocks, lights the screen, finds the drive, verifies signatures, then hands control to the operating system.

That code is firmware.

So why does a layer of firmware sit between hardware and software? Is it necessary, or is it a leftover from an earlier era?

Look at the line between hardware and software.

Between Hardware and Software, There Is No Sharp Divide

We split the world into hardware and software. Hardware means circuits, chips, boards. Software means code, programs, logic. In engineering, the two form a continuous spectrum.

At one end sits ASIC. Logic is frozen into circuits. Function is fixed at tape-out. It is fast, power-efficient, specialized, and hard to change. At the other end sits application software. Logic lives in code and can be changed, iterated, and released at any time. It is flexible, but it must pass through the operating system, drivers, runtime, and libraries before it reaches hardware.

Between those ends stand FPGA, firmware, drivers, and the operating system. Firmware falls in the middle.

This spectrum exists because Turing equivalence answers “can it be done,” not “is it worth doing.”

In 1936, Turing described a machine with an infinite tape, a read/write head, and a finite-state controller. It is slow and impractical, but it defines what “computable” means. Any real computer, ignoring finite memory, matches a Turing machine in computational power. Two ideas follow.

Turing complete: a system can simulate a universal Turing machine and compute anything computable. C, Python, Rust, and JavaScript are Turing complete.

Turing equivalent: two systems can simulate each other with equal capability.

One result: a function built in software can also be built in hardware circuits. A function built in hardware can also be built in software.

AES encryption began as thousands of lines of C. Today every ARM chip has an AES instruction. GPU shaders are floating-point operations that once ran on the CPU, moved into hardware. Floating-point math, MMUs, audio and video codecs, encryption, and AI acceleration all moved from software to hardware.

In 1947, Turing said: “We have often simplified the circuit at the expense of the code.” The line between circuits and code can move. Hardware and software have no natural gulf. People draw the line through trade-offs.

Those trade-offs come down to performance, cost, and modifiability.

Specialized circuits run in parallel and respond fast. They beat general-purpose instructions. They are also expensive to develop and hard to change after they are fixed. Software is cheap to develop and free to iterate. Its performance depends on the hardware it runs on. Functions with high volume, high speed, and low tolerance for change move toward hardware. Everything else stays in software.

Firmware found its place on that spectrum.

What Firmware Is

Firmware is a program fixed in hardware, usually stored in ROM, Flash, or EEPROM. It starts when the hardware powers on, long before the operating system.

Its position is unusual.

To upper-layer software, firmware looks like hardware. The operating system passes through firmware to reach hardware. When you flash a BIOS, upgrade SSD firmware, or update NIC firmware, you change how the hardware behaves.

To hardware, firmware is software inside hardware. It can be updated. The BIOS chip on a motherboard used to be a read-only ROM. Now most motherboards support flashing the BIOS. One flash can fix a compatibility bug, close a security hole, or add support for a new CPU. SSD firmware, NIC firmware, and router firmware work the same way. A chip cannot change after tape-out. Firmware can. That makes it the cheapest repair path after hardware leaves the factory.

Firmware engineers work with registers, timing, and electrical characteristics. Other programmers write against software APIs. They read hardware specs. Every line of code gets checked against the chip manual. They write C, run it without an operating system, and read and write memory and I/O ports directly. It is software doing the work of hardware.

Firmware is where the same logic lands under different constraints. It lets software act more like hardware. When a function must run close to the hardware, with nanosecond timing and direct register access, firmware gives you hardware capability with software agility. It also lets hardware act more like software. When hardware needs to adapt, change behavior with configuration, upgrade with new requirements, or fix a hardware bug, firmware gives it software capability.

Why Firmware Is Necessary

Turing equivalence alone makes firmware look replaceable. Real systems show two gaps: pure hardware lacks mutability, and pure software lacks directness.

Firmware covers at least six jobs.

First, the boot chain. After the CPU resets, some code must run. The operating system does not appear on its own. BootROM, BIOS, UEFI, and bootloaders are firmware. Without them, the CPU does not know where memory is, which disk to boot from, or how to light the screen. UEFI boot moves through stages such as SEC, PEI, DXE, and BDS. Each stage prepares the next. During the few seconds a user sees a brand logo, firmware has already run memory training, bus enumeration, device scanning, and boot option selection.

Second, hardware initialization. DDR training, PCIe link negotiation, clock configuration, and power management often finish before the operating system loads. They depend on the specific chip and board. DDR training adjusts timing parameters to find the voltage and phase window. PCIe negotiates link width and speed. ACPI tables and SMBIOS information must be ready before the operating system recognizes the board. These jobs cannot all go into the operating system, and they cannot all be hardwired.

Third, device autonomy. SSDs, NICs, Wi-Fi chips, GPUs, and BMCs often have their own processors and firmware. The operating system sees an abstract device. An SSD’s FTL firmware handles scheduling, error correction, and flash management. It maintains the mapping from logical to physical addresses, performs wear leveling, and runs background garbage collection. Display panel timing control and server BMCs are firmware too. The BMC manages fans, temperature, power, and remote power on/off through interfaces such as IPMI or Redfish. If the operating system hangs, the BMC keeps running.

Fourth, repair after release. A chip cannot change after tape-out. Firmware can. CPU microcode, BIOS updates, SSD firmware upgrades, and router firmware patches all repair hardware after it ships. When Spectre and Meltdown appeared, many CPUs were mitigated through microcode updates. Without firmware, a compatibility bug could mean a recall, a board replacement, or a scrapped product batch.

Fifth, the root of security. Secure Boot, chains of trust, and measured boot begin in firmware. Firmware is the first trusted code in the boot process. It is also a target for attackers. Without firmware security, the operating system above sits on sand.

Sixth, real-time determinism. Hard drive head servoing, power control, and motor control run in nanosecond or microsecond feedback loops. Once tuned, they rarely change. They do not suit a general-purpose operating system. They need firmware or hardware state machines. A hard drive head must position itself to micron precision on a spinning platter. If the control loop runs one cycle late, data can be read incorrectly.

Firmware is a structural layer in modern computer systems.

ASIC, FPGA, and Firmware

ASIC is a printed book. The circuit is fixed at tape-out. To change its function, you redesign and re-tape-out, often for millions of dollars. One wrong word ruins the batch.

FPGA is an erasable blackboard. You draw a circuit diagram in a hardware description language, compile it into a configuration file, and load it at power-on into an array of logic cells. The chip becomes the circuit you want. Load an encryption engine today, and it is an encryption chip. Load another configuration tomorrow, and it becomes an AI accelerator. You can put a soft-core CPU inside it, using hardware logic to create a processor, then run programs on that processor.

Firmware is a loose-leaf page inside a printed book. The book is printed, but the contents can change. A chip cannot change after tape-out. Firmware can. Firmware chooses code and trades a little performance for flexibility. ASIC chooses circuits and trades flexibility for performance. FPGA sits in the middle. It offers a rewritable intermediate state, keeps the hardware cost of circuits, and buys flexibility. Each generation costs an order of magnitude more than firmware.

Firmware and FPGA are two directions of the same trade-off. Both sit in the middle of the spectrum. Firmware leans toward software. FPGA leans toward hardware. They can work together. An FPGA running a soft core, with firmware on that soft core, appears in communications equipment, industrial control, and data center accelerator cards.

Firmware Engineers

A common joke in the field: other people write code against software APIs. Firmware engineers face hardware specs.

Firmware engineers also become the scapegoats for hardware problems. When hardware fails, changing firmware is the easiest fix, so firmware gets the workaround. After the change, someone asks:

“If it wasn’t your problem, why did you change it?”

That question shows firmware’s position. It sits close to hardware and close to software. It needs circuit knowledge and code knowledge. It must protect performance and keep modifiability.

That awkward position makes firmware a quiet part of the system. Without firmware, the operating system cannot start. Without firmware, hardware cannot initialize. Without firmware, chips cannot be repaired after shipment. Without firmware, the security trust chain has no root.

The Boundary Will Move. Firmware Will Stay.

The line between hardware and software keeps moving. Floating-point math, MMUs, audio and video codecs, encryption, and AI acceleration moved from software to hardware. Some hardware modules were too costly or too inflexible, so they moved back into software.

The movement will continue. Some firmware functions will harden into chips. Some driver functions will sink into DPUs, SmartNICs, and FPGAs. Some firmware will be replaced by verifiable firmware. Open-source firmware such as coreboot, OpenBMC, U-Boot, UEFI EDK II, and RISC-V OpenSBI is changing how firmware is built.

Firmware will not disappear. It will become more modular, more verifiable, more rollback-capable, and more secure. Systems will still need the first code after power-on, hardware initialization, internal device control, repair after release, and a root of security trust.

The power button is pressed. The CPU resets. The program counter points to a fixed address. Firmware wakes first.

The operating system arrives later.