In 2024, PremDay was introduced at OSFC as a new conference created by bare-metal infrastructure operators to share field experience with peers and hardware vendors. Two years later, the initiative has matured into a structured user group, and open firmware has moved from a discussion topic to a concrete workstream.

This talk proposes a synthesis of the open-firmware topics covered during the third edition of the PremDay conference and the actions that followed. It will summarize the main outcomes of the panel discussions, the growing call from infrastructure operators to adopt LVFS and fwupd for server firmware distribution, and the renewed interest in OpenBMC as a credible path away from opaque and closed-source management stacks. It will also present the creation of the SONiC portal, designed to gather technical knowledge, operational feedback, and a shared hardware compatibility list for the community.

The objective is not to present a single-vendor solution or a single company roadmap, but to show how a group of mid-scale infrastructure operators is converging on common expectations for firmware lifecycle, observability, transparency, and operational autonomy. These topics are now officially supported by the PremDay user group, giving them a broader base than an isolated company initiative.

For the OSFC audience, this is field feedback from operators who are not hyperscalers, but who still need firmware that is automatable, inspectable, supportable, and open enough to fit modern SRE practices.

High-speed interfaces are rare on MCUs, and cost-effective FPGAs often come with limited LUTs, leaving developers caught between slow protocols like I2C/UART and the complexity of rolling a custom SPI protocol from scratch.

This talk explores a cleaner alternative: interfacing an FPGA as a memory-mapped device with an MCU running Zephyr, and extending that interface to expose gateware peripherals inside the FPGA. We'll cover two approaches, direct memory mapping over STM32's FMC bus, and a QSPI-based approach treating the FPGA as a SPI memory device, comparing their trade offs in speed, complexity, and flexibility.

Key takeaways:

1) Writing Devicetree for Memory mapped FPGAs using STM32’s FMC Bus.
2) Writing Devicetree for Memory Mapped FPGAs using Generic serialised SPI/QSPI interfaces.
3) Using the FPGA as MMU for external memory like HyperRAM.
4) Interfacing gateware peripherals in the FPGA from MCU running Zephyr

Security requires isolation and for most ARM systems, this comes in the form of the ARM TrustZone, which divides the CPU into a secure and normal world. This allows the system to run a trusted exectuion environment (TEE) in the secure world and a rich execution environment (REE) in the normal world.

Of course, the TEE needs to be loaded from somewhere and be executed somewhere else. Doing this in a secure manner requires careful orchestration between multiple firmwares and failure to do so leads to serious vulnerabilities.

The talk starts off with a TEE setup that should sound familiar to many:
A prebootloader starts at the highest privilige level, does some DDR initialization and loads TF-A and OP-TEE as well as the final bootloader into memory. Then TF-A is invoked installing itself as secure monitor and OP-TEE as trusted OS before returning to the bootloader in a lower privilige level.

From there on, the CPU should fault trying to access secure memory, however hard the normal world tries. However, as Marco will show, there is no shortage on creative alternative ways to access memory and unfortunately, they are often overlooked leading to real world exploits.

This work culiminated into a number of patches across TF-A, OP-TEE and the barebox bootloader.

This talk will go into detail how porting Tamago to the AST2700 went, what blockers came up and which milestones were reached along the way. This includes proper baremetal networking in Go and even implementing a small filesystem to work on the storage you usually find on these type of chips. I will show a small DCSCM board running the code in a short demo and some initial comparisons with other BMC stacks like OpenBMC and even Hubris or WalaBMC.

Almost everywhere OpenBMC runs, it is a server BMC stack, acting as sidecar to a much bigger host CPU, and it carries assumptions one can't see by reading the code. The only way to find assumptions buried that deep is to take the stack somewhere it was never meant to go, so we ran it on a high-radix fabric switch, then on a chassis of eighteen BMCs, and watched what broke. Our fabric switch has no separate control-plane processor, so the BMC is the switch's main processor.

Because there is no host CPU underneath, the BMC drives the fabric hardware itself. A daemon reads the switch ASIC's port counters directly, and through the module-management layer the BMC talks to every cable in the switch to read presence, temperature, identity, and more. All of that gets republished on D-Bus and projected into the DMTF Fabrics / Switches / Ports resource tree. We'll show where a standard built for servers bends to fit a fabric, and the one or two places where we decided an empty field was more honest than a server's answer.

We then put a switch into a chassis with multiple individually managed line cards, and that is where it gets interesting. Upstream bmcweb's Redfish aggregation is built for a single satellite and on our quest to aggregate multiple satellites, we discover how challenging lifting a seemingly simple assumption can be. We walk through each change as a concrete gap with a concrete fix, able to handle the single-server case the code was built for and our chassis paradigm.

Pre-Boot Authentication (PBA) is a software that is used in the context of Self-Encrypting Drives (SEDs) - it unlocks the drive and makes it usable for the user.

TrustedPBA is a new PBA that is based on TamaGo and is executed as a EFI application. We wanted the simplicity of Golang combined with the benefits of the running the PBA in UEFI directly. TrustedPBA provides you with these benefits and is highly customizable:

• Different methods to unlock the drive - TPM PCR-based, TPM NVRAM-based, Password Input and many others
• Boot Policy Configuration

TrustedPBA enables the user to chainload every operating system which includes Windows which is a common limitation of 'classical' busybox PBAs.

Nearly 17 years ago, barebox forked from Das U-Boot with a simple question: Why can't bootloader developers have nice things? "Nice" meant feeling like the Linux kernel and that included portability and being free of per-board assembly.

The catch: the kernel is nice because the bootloader does the unpleasant work of turning a reset vector into a place where portable code may run. Undeterred, barebox's very earliest code was written in C anyway, fueled by a heavy dose of GNU extensions, macro magic, linker-script choreography, and, in hindsight, behavior neither the C standard nor GCC ever promised. GCC was charitable — until its optimizer wasn't.

This talk narrates how barebox came to confront its past: sometimes by writing better C, sometimes by admitting C wasn't the right language (ARMv8 MMU disablement: please don't).
Some cleverness has Linux ancestry; much was grown locally.

Topics span build time (hundreds of per-board entry points sharing common relocatable objects), early init (C relocation code that fixes up its own relocations live), and runtime challenges (legitimate uses for accessing page zero; pointer-dereference woes across caches, MMIO, and hardware virtualization) and nifty features (green threads; pressing KASAN into tracking DMA-buffer ownership).

You'll leave entertained (or slightly unnerved?), but with a feel for which problems belong in C and where we've exorcised nasal demons firsthand.

At hyperscale, detecting a firmware compromise is a solved problem; recovering from it is not. While Static Root-of-Trust Measurement (SRTM) provides reliable platform measurement, responding to a Secure Boot compliance breach typically results in a dead node awaiting manual intervention. Standard OS-level tools are blocked by System Management Mode, SMM, runtime locks, and proprietary out-of-band BMC APIs are too fragmented across heterogeneous fleets to provide a unified, automated recovery pipeline.
We introduce a self-healing firmware state machine designed to bridge the gap between attestation and active remediation without distributing a powerful, portable signed key-clearing payload across the fleet. By delivering a custom EFI application via iPXE during the Boot Device Selection (BDS) phase, infrastructure control planes can evaluate a node's hardware compliance strictly in-band. Upon detecting unauthorized state drift, the application stages a vendor-agnostic, BDS-staged UEFI variable, StageOptimzedDefaults.
This architecture circumvents runtime firmware constraints without violating the platform's security boundary. Together with our OEM hardware partners, we are currently adapting this mechanism, and are bringing this approach to OSFC for feedback.

With the rapid development of AI, its applications in the embedded software field are increasingly widespread. However, debugging OpenBMC in production environments remains notoriously difficult. Runtime logs are overwhelmingly long, making routine inspections highly time-consuming, and traditional troubleshooting relies heavily on manual analysis to reconstruct causal relationships. Even with current Agentic assistance, AI tools typically rely on superficial text-matching or vector embeddings to retrieve context. Because these methods lack deep semantic understanding of the codebase, directly feeding raw logs to AI agents rapidly exhausts context windows and produces factually incorrect diagnoses.
This talk introduces a non-intrusive, zero-hallucination Agentic AI debugging workflow for OpenBMC. Instead of guessing logic, the Agent extracts deterministic ground truth from compiled artifacts. By leveraging binary analysis tools to pre-analyze symbol-rich binaries, we extract accurate call chains and static log strings. When a crash occurs, the Agent automatically captures runtime logs, reverse-matches isolated log lines to their precise source context, and traverses accurate call graphs to reconstruct the execution flow. By feeding the LLM this highly condensed, deterministic evidence chain rather than massive log dumps and raw source files, the Agent focuses solely on logical deduction.
This approach requires zero modifications to the OpenBMC build process, ensures non-intrusiveness, significantly reduces token consumption, and enables end-to-end automated, highly accurate root cause analysis (RCA).

This talk introduces sp-test, a stand-alone harness for testing
service-processor and root-of-trust firmware, and follows a single test
from a developer's bench to hardware-based CI. A live demo runs on an
off-the-shelf ST Nucleo board.

This talk will discuss our work in bringing Linux to a hardware platform we (lowRISC) are developing - CHERI Mocha - complete with drivers for our hardware devices.

CHERI Mocha is an open-source reference design for a secure enclave, which is a secure environment for running trusted code and security-sensitive applications that boots independently to the rest of the SoC it is co-located with. The modified CVA-6 core at the heart of the system implements CHERI RISC-V - an extension to the RISC-V ISA that extends ordinary registers into permission and bounds-checking capabilities that are checked in hardware, allowing for architectural memory safety guarantees.

In this talk, we will detail the work needed to bring this system - or any other RISC-V system - up from boot ROM to booting into CHERI Linux, explore interactions between hardware and various layers of software, and share the experiences of developing and debugging the hardware platform hand-in-hand with software efforts. We also discuss some of the differences required to support CHERI software/firmware during system bring-up, and where there was little difference over the standard Integer ISA. If you’re interested in novel computing architectures, learning the RISC-V boot stack, and aren’t afraid of debugging a new system with just an instruction trace and wave viewer, then this talk is for you.

CHERI Mocha is part of the COSMIC project, which is funded by DSIT and IUK (grant number 10168492). The hardware design including peripheral IP and software are all licensed under the permissive Apache 2.0 license.

A complete open-source TrustZone stack — TF-A at EL3, OP-TEE at Secure EL1, U-Boot and Linux at EL2 — built from source on the Qualcomm RB3 Gen2 (QCM6490/Kodiak).

This talk describes the boot architecture of the platform while walking through the constraints that make this SoC non-trivial to bring up: Sectools signing, running Linux at EL2 without Gunyah, QTEE vs OP-TEE device tree conflicts, and DSP remoteproc bring-up.

Qualcomm Linux ships official support via meta-qcom, but a multi-hour Yocto build is a poor inner loop for firmware developers; a Buildroot-based alternative — integrated into OP-TEE/build.git — enables fast iteration at any layer of the stack and live OP-TEE regression testing, which will be demonstrated.

Work will be upstreamed to OP-TEE/build.git

In this talk, AMD will present its current open-source strategy for embedded platforms. Over the past few years, AMD has collaborated with 9elements and the broader open-source firmware community to enable multiple programs directly upstream. This session will provide an overview of the current status across these programs and highlight key milestones achieved. It will also offer a forward-looking perspective on the enablement of coreboot and openSIL, along with the primary focus areas for AMD and its partners.

We have Tianocore for PCs and U-Boot for embedded systems. Both of these support EFI and can boot common Linux distros. So are we done now, with firmware and booting?

In fact we are just getting started on the road to genuinely open firmware and boot. EFI was designed in the 1990s for a closed-source environment. It has resulted in growing intermediation between firmware and the OS, with lots of code and complexity which is not really useful in an open source world. The good news is that we have a lot of the pieces in place to move to the next step.

This talk examines the process of assembling firmware and booting an OS, looking at how EFI handles these elements and the design decisions that led us here. It then proposes a set of incremental improvements leading towards a more open, straightforward and performant boot.

It ends with a demo contrasting the status quo with this new approach, including boot time, code size and security.

This talk introduces HypervisorPayload — a Slim Bootloader payload that bundles and launches an open-source hypervisor (currently ACRN) as a single signed firmware artifact. Internally it has two parts: HvLoader, a small launcher that runs first, and the hypervisor binary it carries. The bootloader verifies HypervisorPayload once and forwards the platform VM configuration to it, eliminating the need for a separate hypervisor verification step.

At runtime, HvLoader retrieves the SBL VM configuration (CPU, memory, MMIO, IRQ, PCI passthrough) and passes it through to the hypervisor, loads guest kernels from boot media, builds a multiboot2 module table, and performs a one-shot register handoff to the hypervisor before leaving the control path. Statically pre-launched guests then boot natively on their dedicated vCPUs and passthrough devices — with no Service VM, no post-launched VMs, and no runtime control channel — allowing heterogeneous OS combinations (for example, Zephyr alongside Linux, Trusty alongside Android, or any mix of RTOS, general-purpose, and trusted guests) to run side by side on a single SoC with strong isolation and deterministic boot.

From the OS side, HypervisorPayload simply looks like the hypervisor that BIOS provides.

This talk presents Scaleway’s journey in adopting OpenBMC at cloud-operator scale.
As a growing European cloud service provider operating more than 100,000 servers and thousands of GPUs, Scaleway is pursuing two strategic initiatives: adopting OCP Open Rack v3 (ORv3) to optimize rack-level power delivery, cooling, and modularity, and deploying OpenBMC as a unified firmware stack across server platforms to enable native Redfish support and greater firmware autonomy.

Bringing OpenBMC into production exposed several real-world challenges:

• Complexity of qualifying firmware on early hardware prototypes and pre-production platforms.
• Driving the organizational transformation required to integrate an entirely new firmware stack across multiple operational teams.
• Managing the coexistence of OpenBMC and legacy proprietary firmware within a heterogeneous infrastructure fleet.

To address these challenges, we established a close co-design relationship with hardware vendors through an iterative feedback loop and invested in developing in-house expertise. This approach enabled rapid internal adoption and progressively increased our autonomy over the firmware layer.

As we integrated OpenBMC into our infrastructure, we also explored how far we could go in developing our own firmware features to provide a consistent operational experience across OpenBMC-enabled platforms. During this talk, we will share practical examples related to hardware inventory management, highlighting our efforts to harmonize firmware APIs across different server platforms.

Looking ahead, the focus will gradually shift from onboarding to long-term sustainment: keeping pace with evolving industry standards, maintaining firmware quality over time, and ensuring sustainable operational support.

It is clear that booting a system based on an application processor requires multiple binaries and possibly multiple hardware components - at the very least, one to initialize the DRAM and one to run in it. This implies that the various components of the chain, however many, need to be aware of the respective next and previous one somehow: Any component has to know the source, the protocol, and the destination for loading the next one, and the build system needs to create an overall image for the target platform, typically also requiring extra data structures that adhere to the mask ROM or other prior loader, possibly containing signatures or similar for a secure boot flow.

With this presentation, we summarize the development of the oreboot and LinuxBoot build systems over time, what has been considered and attempted, and how things worked out, and compare with other firmware projects, such as U-Boot and coreboot. We explain why it is important to know and understand the full chain and its build process for both security and reliability, and finally provide a list of necessary features to be worked on for the future.

There has been a long-term urban legend around the difficulty of implementing native DRAM initialization in coreboot.
Firmware code running at this stage has no main memory available, and must grapple with a
small amount of CPU cache as data storage.

DRAM initialization entails retrieving memory chip characteristics for each channel, calculating common parameters, programming a large set of memory controller registers, and then DDR PHY registers.
Afterwards a set of SoC-specific and JEDEC-standard training algorithms must be performed to empirically derive a set of delays based on limited hardware-level signal feedback.
And all this has lived in proprietary "MRC" blobs with hardly any documentation for a long time,
deterring most coreboot developers from even attempting to produce open source code for this task.

This talk takes the 10+ year-old Intel Bay Trail platform, which has lived in coreboot ever since
Chromebooks were released with this SoC.
Instead of focusing on the low-level details of this specific platform, this talk will use it as a
case study for modern techniques for reverse engineering and then implementing open source code
for this DRAM initialization step.

It will showcase the use of SerialICE modernized with the Unicorn Engine to trace the operation of binary blobs, and how it can also be repurposed and combined with new harnesses to allow the rapid prototyping of the core algorithms. It will then show how careful, skeptical use of modern LLM-based tooling accelerated the conversion of this into a working, prototype-quality coreboot implementation capable of booting on multiple real boards.

A quick tour of go-tcg-storage, the pure-Go library for driving TCG Storage self-encrypting drives. Where the project stands today, what might be next, and a perspective from someone stepping up to help maintain it.

This workshop introduces an early-stage web-based firmware analysis tool designed to make firmware security assessment more accessible to students, researchers, and security practitioners. Many organisations do not routinely include firmware analysis in their security workflows, even though firmware may contain insecure services, exposed credentials, weak configuration, unsafe permissions, or other security-relevant artefacts. The tool allows users to upload a firmware image and receive structured findings generated through automated static analysis, including extraction results, suspicious network indicators, authentication artefacts, permission issues, and transport security indicators.

The workshop will demonstrate how low-level firmware evidence can be converted into clearer security findings, including severity information, contextual explanations, and NIST-aligned reporting to support governance and remediation discussions. Participants will be guided through example firmware analysis outputs and invited to critique the clarity, usefulness, and accuracy of the results. The session is intended to be practical and discussion-based, focusing on improving the tool’s usability, reporting structure, and relevance to real firmware security workflows. Feedback gathered during the workshop will inform the next stage of development and evaluation.

NVIDIA's upstream OpenBMC progress, challenges, and roadmap

Secure-boot projects often end up with a zoo of nearly-identical bootloader images for development, factory, and field use with each variant adding more risk.

In this lightning talk, I present barebox's Security Policy support, which facilitates adapting securely to each lifecycle stage and how the state transition can be controlled via eFuses, device-bound unlock tokens or hardware-rooted storage.

SPI NOR flash is a very common IC used as a boot medium for both BMC and Host firwmare. Data can be read bytewise and pretty fast. Writes on the other hand are much slower. NORbert is an open source RTL project with open source tooling that emulates this kind of IC.

The content of the talk will be about why you'd want to emulate a SPI NOR flash and why you need to use an FPGA for this. I want to touch on what similar tools were previously available (dediprog EM100 & Trammel's spispy) and how NORbert improves upon them. IThe talk will showcase NORbert's functionality like logging and automated TOCTOU (time of check, time of use) vulnerability exploits. Lastly I will talk about the co-designed rust tooling which works also on the web.

Link to NORbert: https://github.com/ArthurHeymans/NORbert

"If you cannot use a CLI, you probably have no business in doing firmware."

This used to be true. Firmware is a hard thing to get into. You need to get familiar with a lot of things before you can do something meaningful. At least part of this barrier is having to use a CLI.

Rust has many advantages. When people advocate for rust it's usually about it being memory safe, rust having a good tooling like package managers and linters/formatters, a strong compiler telling exactly what you messed up, ... This is all very true and also applies when making CLI tools that relate to firmware development, but this talk wants to highlight another advantage of rust.

Rust has a wasm target arch which makes it easy to support both a CLI as well as a web application in the same codebase. The advantage of a web application for beginners is substantial: no need to download and compile a tool, no need to copy a command of which you understand only half, just visit a website and be greeted with an intuitive UI.

The goal of this talk is to showcase how making a webui alongside a CLI is possible and give some examples.

Some examples
https://rflasher.9elements.com
https://rem100.9ements.com
https://github.com/ArthurHeymans/NORbert/pull/9 (PR for web tool)

We all know the OVMF TianoCore2. The great virtual machine firmware framework used by VirtualBox and KVM (by default). It's a complete and beautiful reference implementation of the UEFI spec. But do we need the PEI phase? The SEC phase in a virtual machine? That we can directly start from a DXE (or PEI phase to setup DXE environment) that skips SEC phase and legacy burdens (via usage of VMCS/VMCB or corresponding control structure for firmware) directly. Hypervisor provides the ACPI tables and PCIe configuration space. So firmware is used more as a "get it done" layer to boot a modern OS than a full implementation.

The UEFI Forum is a global technology consortium that advances firmware innovation through industry collaboration while developing and maintaining the Unified Extensible Firmware Interface (UEFI), Platform Initialization (PI), and Advanced Configuration and Power Interface (ACPI) specifications. Together, these standards provide the foundation for platform initialization, firmware bootstrap, system configuration, power management, security, and operating system interoperability across modern computing platforms.

A key strength of these specifications is their architecture-neutral design. Today, UEFI, PI, and ACPI are deployed across x86, Arm, RISC-V, and LoongArch systems, helping to enable a consistent software experience across an increasingly diverse hardware ecosystem.

In this State of the UEFI session, UEFI Forum President Dong Wei will provide an overview of the UEFI Forum, recent developments in the UEFI, PI, and ACPI specifications, the Forum’s working group structure, Code First process. Attendees will learn how organizations and individuals can participate in future specification development and collaborate with the broader firmware community.

The session will also highlight ongoing collaboration between the UEFI Forum and adjacent open-source communities, including the Open Compute Project (OCP) Open Platform Firmware (OPF) Project, where Dong serves as a Steering Committee representative. Attendees will learn about emerging opportunities for synergy between OCP initiatives such as OpenSFI and UPCI and the UEFI Forum’s standards efforts.

Finally, attendees will receive updates on key industry topics including platform security, confidential computing, post-quantum cryptography, and other trends shaping the future of open firmware.

Building firmware that can boot an unmodified operating system across different Arm platforms requires more than implementing UEFI or ACPI. It also requires a practical understanding of open firmware standards, validation tools, and common integration issues.
This workshop introduces the open-source Arm SystemReady Architecture Compliance Suite (ACS) from a firmware developer's perspective. Participants will learn how to prepare a platform, run compliance tests, interpret results from UEFI SCT, FWTS, and BSA/SBSA tests, and investigate common firmware issues that affect OS boot and interoperability.
Beyond the testing flow, the session will provide an overview of the Arm SystemReady program, recent updates, and the open tools and reference platforms available to help developers build firmware that supports standard operating systems. The goal is to help firmware engineers adopt open standards earlier in development, reduce integration effort, and improve software portability across the Arm ecosystem.

A developer tooling pattern does double duty: everyday Hubris debugging
tools humility, faux-mgs, and faux-ipcc, become the core for
more formal tests anyone on the team can run. sp-test drives the tests,
recording each run so tests and results can be shared, analyzed, and reproduced, on
an emulator and on real hardware.