BIOS & Firmware Engineering

Hardware Boots, Product Does Not

Firmware Engineering Starts After the Board Can Power On

A motherboard can complete POST and still be wrong for the deployed product. It may stop at the wrong boot device, stay off after AC returns, expose setup options that field operators should never change, report incorrect product identity, or fail to recover when application software stops responding.

Firmware engineering converts those product requirements into a controlled platform behavior. The starting point is an exact motherboard revision, current firmware build, operating system image, attached devices, power-state requirements, security policy, and update method.

Custom Mini-ITX Board Design → Platform Specifications →

Product-Level Firmware Scope

What We Can Define in BIOS and UEFI Firmware

Setup Defaults

Boot priority, enabled devices, virtualization, storage mode, serial settings, security options, and production defaults.

Setup Access

Hide selected menus, restrict changes, set administrator access, and remove field-service options that should remain factory controlled.

Boot Policy

NVMe, SATA, USB, PXE, or supported HTTP boot priority, fallback order, boot delay, and recovery entry conditions.

Power Policy

AC-loss recovery, RTC wake, soft-off behavior, supported sleep states, and board-specific wake sources.

Platform Identity

Manufacturer, product name, serial information, board identity, SMBIOS fields, asset data, and approved boot-logo changes.

Security & Updates

Secure Boot key ownership, TPM exposure, setup protection, signed-update policy, recovery path, and production provisioning.

Power-State Requirements

Define Exactly What Happens at Boot, Shutdown, and AC Return

Unattended equipment cannot depend on a technician pressing a key after a power event. Boot and power behavior must be defined against the actual UEFI implementation, board power logic, attached storage, network path, and OS image.

Power Input Platforms →

Board-Level Control

Firmware Can Control Only What the Board Exposes

Embedded Mini-ITX designs often include controls that do not appear in a desktop BIOS. Their behavior depends on the fitted Super I/O, embedded controller, GPIO expander, transceiver, watchdog, fan controller, or chipset.

Multiple Serial Ports → GPIO & CAN Platform →

Firmware-to-OS Data

ACPI and SMBIOS Must Describe the Shipped Hardware

Firmware presents standardized information that the operating system and management software use for configuration, power management, and hardware inventory. Correct structure is not enough; the data must match the exact production board and product identity.

Pre-Boot Trust

Secure Boot Requires a Defined Key Owner and Update Path

Production Secure Boot is not simply an enable/disable setting. The project must define who controls the Platform Key, which Key Exchange Keys are trusted, what enters the allowed-signature database, how revoked images enter dbx, and how authorized field updates remain recoverable.

Current UEFI requirements set the Secure Boot Platform Key format at a minimum of RSA-2048 and require UEFI image hashes stored in dbx to use at least SHA-256. These are minimum cryptographic requirements, not a complete product-security policy.

PK Ownership

Decide whether the OEM, customer, or another authorized owner controls the Platform Key used to establish Secure Boot ownership.

KEK, db & dbx

Define trusted update authorities, allowed images, revoked signatures, and the provisioning method used in production.

TPM 2.0

Expose and provision the platform TPM where supported, with ownership and deployment policy defined by the final system.

Recovery

Preserve an authorized recovery route for failed updates or key changes without bypassing the intended trust policy.

Network Security Systems →

Production Firmware Control

Release the Binary With Its Board, Defaults, and Change Record

A firmware file becomes a production artifact only when its identity and compatibility are controlled. The released binary must stay tied to the motherboard revision, default configuration, security provisioning, update method, and reason for change.

1. Binary Identity Record firmware version, exact board revision, file size, SHA-256 digest, and release date.
2. Production Defaults Freeze shipped setup values separately from engineering debug settings and local technician changes.
3. Change Record Identify changed functions, affected hardware or OS versions, known constraints, and required regression checks.
4. Update & Recovery Define the approved flashing method, version policy, power-loss precautions, rollback rules, and recovery route.

Reference Specifications

Firmware Interfaces and Reference Specifications

UEFI 2.11

Current UEFI specification for the standardized pre-OS firmware environment, boot services, runtime services, variables, and protocols.

ACPI 6.6

Current ACPI specification for OS-directed device configuration, platform description, power management, and system events.

SMBIOS 3.9.0

DMTF specification for standardized management information exposed by system firmware about the platform and installed hardware.

TCG TPM 2.0 v185

March 2026 TPM 2.0 Library specification defining the architecture, structures, and commands used by TPM 2.0 implementations.

Certifications & Quality Standards →

Firmware Release Gate

Validate the Exact Firmware Build You Intend to Ship

Firmware engineering ends with a defined binary and production configuration. Engineering validation then runs that exact release on the target board with the intended OS image, peripherals, power-state cases, security provisioning, update method, and recovery path.

Engineering Validation → All Engineering Services →

FAQ

BIOS & Firmware Engineering Questions