{"$schema": "https://c3voc.de/schedule/schema.json", "generator": {"name": "pretalx", "version": "2026.3.0.dev0", "url": "https://talks.osfc.io"}, "schedule": {"url": "https://talks.osfc.io/osfc-2026/schedule/", "version": "1.6", "base_url": "https://talks.osfc.io", "conference": {"acronym": "osfc-2026", "title": "Open Source Firmware Conference 2026", "start": "2026-09-15", "end": "2026-09-17", "daysCount": 3, "timeslot_duration": "00:05", "time_zone_name": "Europe/Berlin", "colors": {"primary": "#221f1d"}, "rooms": [{"name": "2nd Room", "slug": "5633-2nd-room", "guid": "cacef857-684a-5993-b24c-f0df83f73c13", "description": "Several small rooms are located down the hallway", "capacity": null}, {"name": "Main", "slug": "5632-main", "guid": "7c7748d1-b003-53c7-bcde-f2c198b47c4c", "description": null, "capacity": 250}, {"name": "3rd Room", "slug": "5634-3rd-room", "guid": "1680ef23-962d-54d4-b9cc-9dcf6a16a20b", "description": null, "capacity": 35}], "tracks": [], "days": [{"index": 1, "date": "2026-09-15", "day_start": "2026-09-15T04:00:00+02:00", "day_end": "2026-09-16T03:59:00+02:00", "rooms": {"Main": [{"guid": "12bf0bb3-8c2a-5781-af4a-4a34ddfb5ed2", "code": "T3CSGU", "id": 101749, "logo": null, "date": "2026-09-15T09:45:00+02:00", "start": "09:45", "end": "2026-09-15T10:15:00+02:00", "duration": "00:30", "room": "Main", "slug": "osfc-2026-101749-open-firmware-beyond-the-hyperscalers-outcomes-from-the-premday-user-group", "url": "https://talks.osfc.io/osfc-2026/talk/T3CSGU/", "title": "Open Firmware Beyond the Hyperscalers: Outcomes from the PremDay User Group", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\n\nThis 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.\n\nThe 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.\n\nFor 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.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "USHJUP", "name": "Erwan Velu", "avatar": "https://talks.osfc.io/media/avatars/PT8YJE_4DttqNT.webp", "biography": "Opensource enthusiast & contributor, interested in low-level and performance.\nKernel & Embedded Recipes founder.\nPremday founder\nWorked for Mandriva (HPC), Redhat (Ceph).\nCo-designed an In-Flight-Entertainment (IFE) system for Zodiac.\nCurrently part of the Hardware team at Criteo.", "public_name": "Erwan Velu", "guid": "b7968156-448d-5ed6-9fe2-79974d93f63d", "url": "https://talks.osfc.io/osfc-2026/speaker/USHJUP/"}], "links": [], "feedback_url": "https://talks.osfc.io/osfc-2026/talk/T3CSGU/feedback/", "origin_url": "https://talks.osfc.io/osfc-2026/talk/T3CSGU/", "attachments": []}, {"guid": "68a4a7ae-5410-547b-bab4-eb8979d7cca3", "code": "9HUU8E", "id": 102523, "logo": null, "date": "2026-09-15T10:30:00+02:00", "start": "10:30", "end": "2026-09-15T11:00:00+02:00", "duration": "00:30", "room": "Main", "slug": "osfc-2026-102523-memory-mapped-fpga-peripherals-on-zephyr-fmc-and-qspi-approaches", "url": "https://talks.osfc.io/osfc-2026/talk/9HUU8E/", "title": "Memory-Mapped FPGA Peripherals on Zephyr: FMC and QSPI Approaches", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\n\nThis 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.\n\nKey takeaways:\n\n1) Writing Devicetree for Memory mapped FPGAs using STM32\u2019s FMC Bus.\n2) Writing Devicetree for Memory Mapped FPGAs using Generic serialised SPI/QSPI interfaces.\n3) Using the FPGA as MMU for external memory like HyperRAM.\n4) Interfacing gateware peripherals in the FPGA from MCU running Zephyr", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "CD7EFA", "name": "Sahaj Sarup", "avatar": "https://talks.osfc.io/media/avatars/FLJ8JZ_DqrtzuP.webp", "biography": "Hardware and Firmware hacker with over a decade of professional experience in embedded Linux user space, RTOS (Zephyr), and Yocto/Buildroot environment maintenance, complemented by a strong background in hardware debugging and PCB Designing and prototyping", "public_name": "Sahaj Sarup", "guid": "8c2e24e5-e7e8-5814-839a-c7c4324c718d", "url": "https://talks.osfc.io/osfc-2026/speaker/CD7EFA/"}], "links": [], "feedback_url": "https://talks.osfc.io/osfc-2026/talk/9HUU8E/feedback/", "origin_url": "https://talks.osfc.io/osfc-2026/talk/9HUU8E/", "attachments": []}, {"guid": "f800287d-d706-5f1e-bfb7-84d123f38be4", "code": "GSLJUP", "id": 101738, "logo": null, "date": "2026-09-15T11:30:00+02:00", "start": "11:30", "end": "2026-09-15T12:00:00+02:00", "duration": "00:30", "room": "Main", "slug": "osfc-2026-101738-setting-boundaries-securing-overlooked-op-tee-attack-vectors", "url": "https://talks.osfc.io/osfc-2026/talk/GSLJUP/", "title": "Setting Boundaries: Securing overlooked OP-TEE attack vectors", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\n\nOf 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. \n\nThe talk starts off with a TEE setup that should sound familiar to many:\nA 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.\n\nFrom 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.\n\nThis work culiminated into a number of patches across TF-A, OP-TEE and the barebox bootloader.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "9UNBSR", "name": "Marco Felsch", "avatar": "https://talks.osfc.io/media/avatars/CGG7GF_rSf8t84.webp", "biography": "Marco joined the Pengutronix graphics team in 2017. His work covers everything from system architecture to low-level bootloader firmware up to kernel and user-space development.", "public_name": "Marco Felsch", "guid": "87e50e8a-3966-5216-9f0f-71b7c817eeba", "url": "https://talks.osfc.io/osfc-2026/speaker/9UNBSR/"}], "links": [], "feedback_url": "https://talks.osfc.io/osfc-2026/talk/GSLJUP/feedback/", "origin_url": "https://talks.osfc.io/osfc-2026/talk/GSLJUP/", "attachments": []}, {"guid": "ee20c3d5-edb6-5349-b073-be4ed7c1f407", "code": "UYLY99", "id": 98960, "logo": null, "date": "2026-09-15T12:15:00+02:00", "start": "12:15", "end": "2026-09-15T12:45:00+02:00", "duration": "00:30", "room": "Main", "slug": "osfc-2026-98960-running-baremetal-go-in-the-ast2700-for-simpler-server-management", "url": "https://talks.osfc.io/osfc-2026/talk/UYLY99/", "title": "Running baremetal Go in the AST2700 for simpler server management", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "ETLMMZ", "name": "Marvin Drees", "avatar": null, "biography": "Working at 9elements as a firmware developer with a focus on RoT and BMC firmware that prefers writing in more safe languages like Go or Rust.", "public_name": "Marvin Drees", "guid": "77d3a5a9-27ea-52f2-b6bc-c2927d5f7423", "url": "https://talks.osfc.io/osfc-2026/speaker/ETLMMZ/"}], "links": [], "feedback_url": "https://talks.osfc.io/osfc-2026/talk/UYLY99/feedback/", "origin_url": "https://talks.osfc.io/osfc-2026/talk/UYLY99/", "attachments": []}, {"guid": "105f5f6d-ef98-53b5-91dc-42a11f793447", "code": "RHDDHV", "id": 102512, "logo": null, "date": "2026-09-15T14:00:00+02:00", "start": "14:00", "end": "2026-09-15T14:30:00+02:00", "duration": "00:30", "room": "Main", "slug": "osfc-2026-102512-the-switch-has-no-cpu-running-an-entire-fabric-switch-on-its-bmc", "url": "https://talks.osfc.io/osfc-2026/talk/RHDDHV/", "title": "The Switch Has No CPU: Running an Entire Fabric Switch on Its BMC", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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. \n\nBecause 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.\n\nWe 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.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "SHXXYF", "name": "Sam Cook", "avatar": null, "biography": "Embedded engineer at Cornelis Networks", "public_name": "Sam Cook", "guid": "101afce9-56f6-5856-aa0e-5ee9dc7c6808", "url": "https://talks.osfc.io/osfc-2026/speaker/SHXXYF/"}], "links": [], "feedback_url": "https://talks.osfc.io/osfc-2026/talk/RHDDHV/feedback/", "origin_url": "https://talks.osfc.io/osfc-2026/talk/RHDDHV/", "attachments": []}, {"guid": "217068f0-a17d-5480-8fa0-073fae7c4d6f", "code": "KQ8LNV", "id": 102256, "logo": null, "date": "2026-09-15T14:45:00+02:00", "start": "14:45", "end": "2026-09-15T15:15:00+02:00", "duration": "00:30", "room": "Main", "slug": "osfc-2026-102256-a-whole-new-world-running-a-pba-on-bare-metal-uefi-with-tamago", "url": "https://talks.osfc.io/osfc-2026/talk/KQ8LNV/", "title": "A whole new world - Running a PBA on 'bare-metal UEFI' with TamaGo", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\n\nTrustedPBA 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:\n- Different methods to unlock the drive - TPM PCR-based, TPM NVRAM-based, Password Input and many others\n- Boot Policy Configuration\n\nTrustedPBA enables the user to chainload every operating system which includes Windows which is a common limitation of 'classical' busybox PBAs.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "LUJX7J", "name": "Christian Walter", "avatar": null, "biography": "Classic \"behind the curtain'-looker.", "public_name": "Christian Walter", "guid": "e5258ad5-190a-5d57-8fae-173f213e1cc4", "url": "https://talks.osfc.io/osfc-2026/speaker/LUJX7J/"}, {"code": "8RMAYE", "name": "Christian Gr\u00f6nke", "avatar": "https://talks.osfc.io/media/avatars/8ZYCKJ_bTIfD4p.webp", "biography": "I am a firmware and embedded systems engineer with experience in safety\u2011critical operating systems, high\u2011security platform design, and host firmware development for modern hardware platforms. I have spent the past decade working on microkernel\u2011 and Linux\u2011based systems for defense and high\u2011assurance environments, focusing on partitioning, isolation, and robust system architectures that meet safety and security certification requirements. \n\nMost recently, I have led open\u2011source firmware efforts at 9elements, driving host firmware projects around coreboot, EDK2 (UEFI), and secure storage. Contributing to the development of secure and transparent firmware solutions for servers and security\u2011sensitive platforms.", "public_name": "Christian Gr\u00f6nke", "guid": "cf731e71-6d83-5023-b905-ecc6e2ac4f24", "url": "https://talks.osfc.io/osfc-2026/speaker/8RMAYE/"}], "links": [], "feedback_url": "https://talks.osfc.io/osfc-2026/talk/KQ8LNV/feedback/", "origin_url": "https://talks.osfc.io/osfc-2026/talk/KQ8LNV/", "attachments": []}, {"guid": "5c247bbc-6b20-562f-afe1-312253867268", "code": "AAGWG7", "id": 101723, "logo": null, "date": "2026-09-15T15:30:00+02:00", "start": "15:30", "end": "2026-09-15T16:00:00+02:00", "duration": "00:30", "room": "Main", "slug": "osfc-2026-101723-barebox-and-the-last-nasal-demon-riders", "url": "https://talks.osfc.io/osfc-2026/talk/AAGWG7/", "title": "barebox and the Last Nasal Demon Riders", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\n\nThe 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 \u2014 until its optimizer wasn't.\n\nThis 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).\nSome cleverness has Linux ancestry; much was grown locally.\n\nTopics 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).\n\nYou'll leave entertained (or slightly unnerved?), but with a feel for which problems belong in C and where we've exorcised nasal demons firsthand.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "YEDRRM", "name": "Ahmad Fatoum", "avatar": "https://talks.osfc.io/media/avatars/KQM3TB_kQMKDVd.webp", "biography": "Ahmad joined the kernel team at Pengutronix in 2018 to work full-time on furthering Linux world domination. He does so by helping automotive and industrial customers build embedded Linux systems based on the mainline Linux kernel.\nHaving a knack for digging in low-level guts, his tasks include hardware enablement, Linux driver development and boot loader porting.\nAhmad is a contributor to a number of open-source projects, including the Linux kernel and the barebox boot loader.", "public_name": "Ahmad Fatoum", "guid": "8bc89db0-3896-5f81-8a4c-b62f4a113e02", "url": "https://talks.osfc.io/osfc-2026/speaker/YEDRRM/"}], "links": [], "feedback_url": "https://talks.osfc.io/osfc-2026/talk/AAGWG7/feedback/", "origin_url": "https://talks.osfc.io/osfc-2026/talk/AAGWG7/", "attachments": []}, {"guid": "e595b3bd-13cc-5388-8f2e-3e38a4235edb", "code": "LE99ND", "id": 101626, "logo": null, "date": "2026-09-15T16:35:00+02:00", "start": "16:35", "end": "2026-09-15T17:05:00+02:00", "duration": "00:30", "room": "Main", "slug": "osfc-2026-101626-automated-bare-metal-remediation-closing-the-zero-trust-loop-with-staged-firmware-sanitization", "url": "https://talks.osfc.io/osfc-2026/talk/LE99ND/", "title": "Automated Bare-Metal Remediation: Closing the Zero-Trust Loop with Staged Firmware Sanitization", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\nWe 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`.\nThis 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.", "description": "This talk introduces a self-healing firmware state machine that bridges attestation and active-remediation, without shipping a powerful, portable, signed key-clearing payload across the fleet.", "recording_license": "", "do_not_record": false, "persons": [{"code": "GZMHPB", "name": "Nnamdi Ajah", "avatar": null, "biography": "Embedded plumber. Working on OpenBMC and UEFI at Cloudflare.", "public_name": "Nnamdi Ajah", "guid": "a2eaa64d-f391-5783-85bb-b9778e80deff", "url": "https://talks.osfc.io/osfc-2026/speaker/GZMHPB/"}, {"code": "R88FE8", "name": "Giovanni Zantedeschi", "avatar": null, "biography": "Giovanni Zantedeschi is a seasoned firmware engineer with 14 years of experience specializing in embedded systems development. For the past four years, Giovanni has been focused on OpenBMC at Cloudflare, working to advance open-source firmware solutions at scale. His deep background in low-level system architecture and embedded environments drives his commitment to building secure, transparent, and robust open firmware ecosystems.", "public_name": "Giovanni Zantedeschi", "guid": "b85a5068-448a-5419-b9e6-4ea11fb67b52", "url": "https://talks.osfc.io/osfc-2026/speaker/R88FE8/"}], "links": [], "feedback_url": "https://talks.osfc.io/osfc-2026/talk/LE99ND/feedback/", "origin_url": "https://talks.osfc.io/osfc-2026/talk/LE99ND/", "attachments": []}, {"guid": "c35ee749-0c64-52f8-90d1-8f989f9aea69", "code": "BVGH3B", "id": 96642, "logo": null, "date": "2026-09-15T17:20:00+02:00", "start": "17:20", "end": "2026-09-15T17:50:00+02:00", "duration": "00:30", "room": "Main", "slug": "osfc-2026-96642-agentic-ai-software-debugging-in-openbmc-extracting-ground-truth-from-binaries-to-eliminate-hallucinations", "url": "https://talks.osfc.io/osfc-2026/talk/BVGH3B/", "title": "Agentic AI Software Debugging in OpenBMC: Extracting Ground Truth from Binaries to Eliminate Hallucinations", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\nThis 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.\nThis 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).", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "QLJXQQ", "name": "Jia, Chunhui", "avatar": "https://talks.osfc.io/media/avatars/EFEHKN_QBwUN0l.webp", "biography": "Chunhui Jia is the firmware team architect at ByteDance and a seasoned expert in the firmware industry. With deep experience across UEFI BIOS, BMC, and OS driver development, he has built a strong track record in tackling complex firmware challenges. His current focus centers on improving firmware debuggability, enhancing observability, and advancing automated issue diagnosis and troubleshooting.", "public_name": "Jia, Chunhui", "guid": "5c534765-3dbb-5eee-8797-d7b4b9327616", "url": "https://talks.osfc.io/osfc-2026/speaker/QLJXQQ/"}], "links": [], "feedback_url": "https://talks.osfc.io/osfc-2026/talk/BVGH3B/feedback/", "origin_url": "https://talks.osfc.io/osfc-2026/talk/BVGH3B/", "attachments": []}]}}, {"index": 2, "date": "2026-09-16", "day_start": "2026-09-16T04:00:00+02:00", "day_end": "2026-09-17T03:59:00+02:00", "rooms": {"Main": [{"guid": "f9eb5671-b3fa-540f-b0ed-8d605c5b87c5", "code": "QY9E7T", "id": 101698, "logo": null, "date": "2026-09-16T09:10:00+02:00", "start": "09:10", "end": "2026-09-16T09:40:00+02:00", "duration": "00:30", "room": "Main", "slug": "osfc-2026-101698-fear-of-flashing-building-confidence-in-firmware-through-automated-testing", "url": "https://talks.osfc.io/osfc-2026/talk/QY9E7T/", "title": "Fear of Flashing: Building confidence in firmware through automated testing", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "This talk introduces sp-test, a stand-alone harness for testing\nservice-processor and root-of-trust firmware, and follows a single test\nfrom a developer's bench to hardware-based CI. A live demo runs on an\noff-the-shelf ST Nucleo board.", "description": "The release-note caution \"Do not update if your system is working\"\nmay be less common than it was a decade ago, but the implied risk has\nnot gone away. Easier recovery keeps a failed update from bricking the\ndevice, but it still wastes the customer's time and turns the next install\nfrom a button press into a risk to schedule. So customers learn to avoid\ninstalling, while developers learn to avoid change, all from fear of\nflashing.\n\nAt Oxide, the Service Processor and Root of Trust run our Hubris-based\nfirmware in place of a typical BMC or EC, on our servers, power shelf\ncontrollers, and network switches.\n\nThere is no call-home; customers update when they choose, and once a rack\nships, whether we can reach it is up to them. We require confidence before\nrelease, and hope to earn customer trust afterwards. Improving our testing regime\nis one way to strengthen both.\n\nsp-test is a new harness for direct hardware testing. It uses\ntools developers know, can emulate parts of the control plane,\nand lets a test declare what it needs so it runs where it applies and\nskips without failure when it doesn't. Tests once described only in PR\ncomments can now be checked in and reused.\n\nTests can run unchanged from a developer's bench to hardware-based\nCI, so someone with no board of their own can get results from\nscarce, shared hardware. The hardest tests to run are often the ones most\nworth sharing: the update path exercised as it is in production, code\nthat runs only when something has gone wrong, and fault insertion tests.\nTelemetry, task dumps, and logs make test results actionable for someone\nwho was not there when it failed.\n\nThis pattern is not specific to Hubris or to Oxide; any team could build the\nsame kind of testing.\nA live demo on an off-the-shelf ST Nucleo board makes it concrete.", "recording_license": "", "do_not_record": false, "persons": [{"code": "AJ8NAJ", "name": "Ben Stoltz", "avatar": null, "biography": "Ben Stoltz is an engineer at Oxide Computer Company, where he works on\nservice processor and root of trust firmware: its security, its update\npath, and, most recently, the testing infrastructure this talk covers.\nBefore Oxide, he worked on systems and infrastructure at Sun Microsystems,\nCisco, and Google.", "public_name": "Ben Stoltz", "guid": "d28f8105-0286-578e-85bc-dc8b576c67be", "url": "https://talks.osfc.io/osfc-2026/speaker/AJ8NAJ/"}], "links": [], "feedback_url": "https://talks.osfc.io/osfc-2026/talk/QY9E7T/feedback/", "origin_url": "https://talks.osfc.io/osfc-2026/talk/QY9E7T/", "attachments": []}, {"guid": "49f3d970-79d2-5d66-aa29-75ebd5a6b357", "code": "ADBDGY", "id": 101746, "logo": null, "date": "2026-09-16T09:55:00+02:00", "start": "09:55", "end": "2026-09-16T10:25:00+02:00", "duration": "00:30", "room": "Main", "slug": "osfc-2026-101746-bringing-up-linux-on-a-memory-safe-cheri-risc-v-system", "url": "https://talks.osfc.io/osfc-2026/talk/ADBDGY/", "title": "Bringing up Linux on a memory-safe CHERI RISC-V system", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "This talk will discuss our work in bringing Linux to a hardware platform we (lowRISC) are developing - CHERI [Mocha](https://github.com/lowRISC/mocha) - complete with drivers for our hardware devices.\n\nCHERI [Mocha](https://github.com/lowRISC/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.\n\nIn 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\u2019re interested in novel computing architectures, learning the RISC-V boot stack, and aren\u2019t afraid of debugging a new system with just an instruction trace and wave viewer, then this talk is for you.\n\nCHERI Mocha is part of the [COSMIC](https://cosmic-project.lowrisc.org/) 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.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "LXMJJQ", "name": "Alice Ziuziakowska", "avatar": "https://talks.osfc.io/media/avatars/8YZ8RQ_i4z8r2b.webp", "biography": "Alice is a Software Engineer at lowRISC. She is passionate about the theory and practice of Operating Systems, new Instruction Set Architectures, and where software and hardware intersect.", "public_name": "Alice Ziuziakowska", "guid": "de5913a0-9df9-5557-957e-7fc3411786be", "url": "https://talks.osfc.io/osfc-2026/speaker/LXMJJQ/"}], "links": [], "feedback_url": "https://talks.osfc.io/osfc-2026/talk/ADBDGY/feedback/", "origin_url": "https://talks.osfc.io/osfc-2026/talk/ADBDGY/", "attachments": []}, {"guid": "f06fa20a-d9f2-56ee-9757-23613ef957de", "code": "JQNFL3", "id": 100597, "logo": null, "date": "2026-09-16T11:00:00+02:00", "start": "11:00", "end": "2026-09-16T11:30:00+02:00", "duration": "00:30", "room": "Main", "slug": "osfc-2026-100597-trustzone-bring-up-on-qualcomm-qcm6490-open-firmware-from-el3-to-linux-el2-with-a-buildroot-developer-workflow", "url": "https://talks.osfc.io/osfc-2026/talk/JQNFL3/", "title": "TrustZone Bring-Up on Qualcomm QCM6490: Open Firmware from EL3 to Linux EL2 with a Buildroot Developer Workflow", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "A complete open-source TrustZone stack \u2014 TF-A at EL3, OP-TEE at Secure EL1, U-Boot and Linux at EL2 \u2014 built from source on the Qualcomm RB3 Gen2 (QCM6490/Kodiak). \n\nThis 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. \n\nQualcomm 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** \u2014 integrated into OP-TEE/build.git \u2014 enables fast iteration at any layer of the stack and live OP-TEE regression testing, which will be demonstrated. \n\nWork will be upstreamed to OP-TEE/build.git", "description": "The Qualcomm RB3 Gen2 (QCM6490/Kodiak) is a commercially available AArch64 development board with upstream Linux and U-Boot support.\n  \n  The official firmware environment is delivered through Qualcomm Linux and meta-qcom \u2014 a  comprehensive but heavyweight Yocto-based BSP that is the right answer for production integration but a slow inner loop for firmware engineers iterating on TF-A, OP-TEE, or the boot chain.\n\n  This talk describes the boot architecture of the QCM6490 platform while providing a Buildroot-based developer workflow \u2014 integrated into OP-TEE/build.git \u2014 as a fast alternative to meta-qcom for firmware engineers. A single make all builds the full stack from source. From that point, rebuilding any individual component in the bootloader stack or the kernel UKI \u2014 and  regenerating and flashing the resulting image \u2014 becomes a lightweight operation, enabling fast iteration at any layer.\n\n  The architecture is the main thread. Topics covered include:\n\n  - Exception level layout\n  - Boot chain: PBL \u2192 XBL \u2192 BL2 (TF-A, signed with Qualcomm Sectools in TEST mode) \u2192 FIP (OP-TEE + U-Boot) \u2192 Unified Kernel Image (UKI) containing kernel, DTB, initramfs, and cmdline as a single EFI binary.\n  - OP-TEE integration\n  - DSP remoteproc chain: sourcing ADSP/CDSP firmware and embedding the qcom_pas PAS Trusted Application as an OP-TEE early TA\n  - Developer ergonomics vs. meta-qcom: a fetch-blobs target that pulls Qualcomm boot binaries from public Qualcomm and CodeLinaro repositories in minutes, replacing the need for a full Yocto build during development.\n\n  **Demo**\n  The talk closes with a live run of the OP-TEE **xtest** regression suite on the board, demonstrating the full Normal/Secure World path end to end.\n\n  The talk is aimed at firmware engineers working on Qualcomm Arm platforms, and more broadly at anyone integrating OP-TEE with a vendor boot chain that diverges from the standard reference flow.", "recording_license": "", "do_not_record": false, "persons": [{"code": "CLWWQV", "name": "Jorge Ramirez-Ortiz", "avatar": "https://talks.osfc.io/media/avatars/DKYPDW_3AHpuLp.webp", "biography": "Jorge Ramirez-Ortiz is a software engineer at the Qualcomm Innovation Center. \n\nHe is a maintainer of the Qualcomm platform ports in Trusted Firmware-A and OP-TEE, and a long-term contributor and maintainer across a broad range of open-source projects \u2014 FFmpeg, Zephyr, U-Boot, Linux, OpenSSL, and cryptographic libraries, among others. He is part of the open boot firmware \nstrategy at Qualcomm, working across multiple boards to bring up fully open-source firmware stacks.", "public_name": "Jorge Ramirez-Ortiz", "guid": "dd712c19-5376-582d-bbc9-c9a05f02ab5d", "url": "https://talks.osfc.io/osfc-2026/speaker/CLWWQV/"}], "links": [], "feedback_url": "https://talks.osfc.io/osfc-2026/talk/JQNFL3/feedback/", "origin_url": "https://talks.osfc.io/osfc-2026/talk/JQNFL3/", "attachments": []}, {"guid": "c1b0dd0a-5c4e-59ff-ab61-0376863516f3", "code": "ZHW9PB", "id": 102358, "logo": null, "date": "2026-09-16T11:45:00+02:00", "start": "11:45", "end": "2026-09-16T12:15:00+02:00", "duration": "00:30", "room": "Main", "slug": "osfc-2026-102358-amd-embedded-open-source-strategy-the-past-now-and-moving-forward", "url": "https://talks.osfc.io/osfc-2026/talk/ZHW9PB/", "title": "AMD Embedded open-source strategy - The past, now and moving forward", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "MXWVHP", "name": "Ritul Guru", "avatar": null, "biography": null, "public_name": "Ritul Guru", "guid": "5671c5b1-a722-51e9-a1b4-9c214fa59acb", "url": "https://talks.osfc.io/osfc-2026/speaker/MXWVHP/"}], "links": [], "feedback_url": "https://talks.osfc.io/osfc-2026/talk/ZHW9PB/feedback/", "origin_url": "https://talks.osfc.io/osfc-2026/talk/ZHW9PB/", "attachments": []}, {"guid": "0937e327-421e-5105-b349-10f62aa601b4", "code": "PCYGKN", "id": 101595, "logo": null, "date": "2026-09-16T13:30:00+02:00", "start": "13:30", "end": "2026-09-16T14:00:00+02:00", "duration": "00:30", "room": "Main", "slug": "osfc-2026-101595-beyond-efi-what-is-next-for-firmware-and-booting", "url": "https://talks.osfc.io/osfc-2026/talk/PCYGKN/", "title": "Beyond EFI - what is next for firmware and booting?", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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?\n\nIn 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.\n\nThis 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.\n\nIt ends with a demo contrasting the status quo with this new approach, including boot time, code size and security.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "L9VZVH", "name": "Simon Glass", "avatar": null, "biography": "Simon Glass has worked in embedded systems for many years, at ARM, Bluewater Systems (which he founded) and Google. He is a primary contributor to U-Boot and custodian of its driver model, with around 10000 commits in total. Simon is married with three children and lives in Colorado.", "public_name": "Simon Glass", "guid": "edb23a1d-342c-51e0-94dd-d986ce372c3e", "url": "https://talks.osfc.io/osfc-2026/speaker/L9VZVH/"}], "links": [], "feedback_url": "https://talks.osfc.io/osfc-2026/talk/PCYGKN/feedback/", "origin_url": "https://talks.osfc.io/osfc-2026/talk/PCYGKN/", "attachments": []}, {"guid": "32f9d2f2-9ad3-5666-9627-c50b5cc1da9b", "code": "Z7PTYB", "id": 101829, "logo": null, "date": "2026-09-16T14:15:00+02:00", "start": "14:15", "end": "2026-09-16T14:45:00+02:00", "duration": "00:30", "room": "Main", "slug": "osfc-2026-101829-shipping-the-hypervisor-in-firmware-a-static-partitioning-payload-for-slim-bootloader", "url": "https://talks.osfc.io/osfc-2026/talk/Z7PTYB/", "title": "Shipping the Hypervisor in Firmware: A Static-Partitioning Payload for Slim Bootloader", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "This talk introduces HypervisorPayload \u2014 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.\n\nAt 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 \u2014 with no Service VM, no post-launched VMs, and no runtime control channel \u2014 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.\n\nFrom the OS side, HypervisorPayload simply looks like the hypervisor that BIOS provides.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "NGW7DU", "name": "Guo Dong", "avatar": null, "biography": "Guo Dong has been actively engaged in firmware development since 2007, beginning with contributions to EDK and EDK2. After several years of experience with coreboot, he co-founded the Slim Bootloader (SBL) project alongside his team. Guo Dong currently focuses on advancing SBL and developing UEFI payload solutions, maintaining a strong commitment to open-source firmware innovation and platform enablement.", "public_name": "Guo Dong", "guid": "2e161ca5-fb6a-5491-9251-5b388ba409a1", "url": "https://talks.osfc.io/osfc-2026/speaker/NGW7DU/"}, {"code": "3NBFTB", "name": "Ravi Rangarajan", "avatar": null, "biography": null, "public_name": "Ravi Rangarajan", "guid": "7a89f62a-238c-546c-b672-c4d87484c382", "url": "https://talks.osfc.io/osfc-2026/speaker/3NBFTB/"}], "links": [], "feedback_url": "https://talks.osfc.io/osfc-2026/talk/Z7PTYB/feedback/", "origin_url": "https://talks.osfc.io/osfc-2026/talk/Z7PTYB/", "attachments": []}, {"guid": "1fb35d74-8716-5b91-b57a-d0e10948037d", "code": "XHMWY9", "id": 101741, "logo": null, "date": "2026-09-16T15:20:00+02:00", "start": "15:20", "end": "2026-09-16T15:50:00+02:00", "duration": "00:30", "room": "Main", "slug": "osfc-2026-101741-openbmc-at-cloud-scale-scaleway-s-journey-to-firmware-autonomy", "url": "https://talks.osfc.io/osfc-2026/talk/XHMWY9/", "title": "OpenBMC at Cloud Scale: Scaleway\u2019s Journey to Firmware Autonomy", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "This talk presents Scaleway\u2019s journey in adopting OpenBMC at cloud-operator scale.\nAs 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.\n\nBringing OpenBMC into production exposed several real-world challenges:\n\n- Complexity of qualifying firmware on early hardware prototypes and pre-production platforms.\n- Driving the organizational transformation required to integrate an entirely new firmware stack across multiple operational teams.\n- Managing the coexistence of OpenBMC and legacy proprietary firmware within a heterogeneous infrastructure fleet.\n\nTo 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.\n\nAs 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.\n\nLooking 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.", "description": "Beyond Scaleway\u2019s own experience, we advocate for cross-industry collaboration and co-design, leveraging communities and events such as Premday to align operator requirements and accelerate shared solutions. We also believe that building in-house expertise around open firmware is becoming a strategic capability for infrastructure owners seeking greater control, flexibility, and innovation.", "recording_license": "", "do_not_record": false, "persons": [{"code": "CCAJGS", "name": "Elyes Zekri", "avatar": "https://talks.osfc.io/media/avatars/XDFFXD_tCZVzE9.webp", "biography": "PhD-level Systems Architect with 15+ years across Hardware, Firmware, and Software. \nCurrently working as Hardware team lead at Scaleway, a french Cloud Service Provider.\nUniquely experienced on both sides of the ecosystem: HPC HW manufacturer and neocloud operator.\nPassionate about design and development of IT systems with a particular interest in embedded systems, firmware and hardware management.", "public_name": "Elyes Zekri", "guid": "ff2e50df-4f20-5037-b28c-0eeaff70c90b", "url": "https://talks.osfc.io/osfc-2026/speaker/CCAJGS/"}, {"code": "F3JJMZ", "name": "Gauthier CARPENTIER", "avatar": "https://talks.osfc.io/media/avatars/8ZKRGH_Q9qFbdE.webp", "biography": "Currently working as hardware system engineer at Scaleway, a french Cloud Service Provider.\n\nPassionate about both side of the force Firmware and Hardware.", "public_name": "Gauthier CARPENTIER", "guid": "69bf13da-6355-51f7-b313-0759e94e3a39", "url": "https://talks.osfc.io/osfc-2026/speaker/F3JJMZ/"}], "links": [], "feedback_url": "https://talks.osfc.io/osfc-2026/talk/XHMWY9/feedback/", "origin_url": "https://talks.osfc.io/osfc-2026/talk/XHMWY9/", "attachments": []}, {"guid": "e60c884c-704b-5cd4-969d-f5ab81dfe72a", "code": "7788YB", "id": 99146, "logo": null, "date": "2026-09-16T16:05:00+02:00", "start": "16:05", "end": "2026-09-16T16:35:00+02:00", "duration": "00:30", "room": "Main", "slug": "osfc-2026-99146-boot-chains-and-build-systems", "url": "https://talks.osfc.io/osfc-2026/talk/7788YB/", "title": "Boot Chains and Build Systems", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\n\nWith 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.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "KQUT8Y", "name": "Jiji Freya Daniel Maslowski", "avatar": "https://talks.osfc.io/media/avatars/V9XHZH_ASG4M8g.webp", "biography": "I like giving [talks and workshops](https://metaspora.org).\n\nIn my free time, I work on free and open source software, especially operating systems and distributions, bringup and application firmware, with a focus on tooling, integration, and documentation.\n\nI created [Fiedka, the firmware editor](https://fiedka.app), started the [Platform System Interface project](https://github.com/platform-system-interface), and inherited stakes in [oreboot](https://github.com/oreboot/oreboot) and [LinuxBoot](https://linuxboot.org).", "public_name": "Jiji Freya Daniel Maslowski", "guid": "b76b4146-4cad-571d-a4e5-87e994b721e9", "url": "https://talks.osfc.io/osfc-2026/speaker/KQUT8Y/"}], "links": [], "feedback_url": "https://talks.osfc.io/osfc-2026/talk/7788YB/feedback/", "origin_url": "https://talks.osfc.io/osfc-2026/talk/7788YB/", "attachments": []}, {"guid": "984ac695-7bdf-561b-9721-ab6f7b2c8227", "code": "PZQ8JW", "id": 101754, "logo": null, "date": "2026-09-16T16:50:00+02:00", "start": "16:50", "end": "2026-09-16T17:20:00+02:00", "duration": "00:30", "room": "Main", "slug": "osfc-2026-101754-teaching-an-old-soc-new-tricks-native-raminit-for-bay-trail", "url": "https://talks.osfc.io/osfc-2026/talk/PZQ8JW/", "title": "Teaching an Old SoC New Tricks: Native raminit for Bay Trail", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "There has been a long-term urban legend around the difficulty of implementing native DRAM initialization in coreboot.\nFirmware code running at this stage has no main memory available, and must grapple with a\nsmall amount of CPU cache as data storage.\n\nDRAM 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.\nAfterwards 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.\nAnd all this has lived in proprietary \"MRC\" blobs with hardly any documentation for a long time,\ndeterring most coreboot developers from even attempting to produce open source code for this task.\n\nThis talk takes the 10+ year-old Intel Bay Trail platform, which has lived in coreboot ever since\nChromebooks were released with this SoC.\nInstead of focusing on the low-level details of this specific platform, this talk will use it as a\ncase study for modern techniques for reverse engineering and then implementing open source code\nfor this DRAM initialization step.\n\nIt 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.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "RFYPRN", "name": "Mate Kukri", "avatar": null, "biography": "Mate is a software engineer passionate about building a more secure and reliable computing experience by bringing free and open source to the lowest levels of the software stack.\nHe has been a contributor to the coreboot project for the last few years, working on retrofitting coreboot to various pieces of existing hardware.\nHe is currently a maintainer of the bootloader stack and UEFI Secure Boot support in a major Linux distribution.", "public_name": "Mate Kukri", "guid": "bc4a6d36-2b2d-5085-9795-73bc8134a52e", "url": "https://talks.osfc.io/osfc-2026/speaker/RFYPRN/"}], "links": [], "feedback_url": "https://talks.osfc.io/osfc-2026/talk/PZQ8JW/feedback/", "origin_url": "https://talks.osfc.io/osfc-2026/talk/PZQ8JW/", "attachments": []}]}}, {"index": 3, "date": "2026-09-17", "day_start": "2026-09-17T04:00:00+02:00", "day_end": "2026-09-18T03:59:00+02:00", "rooms": {"Main": [{"guid": "fff6a6e5-1de6-5f3b-aa4d-1c6a017f1519", "code": "39MQKB", "id": 102494, "logo": null, "date": "2026-09-17T10:00:00+02:00", "start": "10:00", "end": "2026-09-17T10:15:00+02:00", "duration": "00:15", "room": "Main", "slug": "osfc-2026-102494-go-tcg-storage-state-of-the-project-and-the-future", "url": "https://talks.osfc.io/osfc-2026/talk/39MQKB/", "title": "go-tcg-storage: State of the Project and the Future", "subtitle": "", "track": null, "type": "Lightning Talk", "language": "en", "abstract": "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.", "description": "TCG Storage self-encrypting drives (SEDs) put full-disk encryption in the drive controller itself, exposed through the Trusted Computing Group's Security Subsystem Classes \u2014 Opal, Pyrite, Enterprise, and Ruby. In practice, managing them means wrestling with ComIDs, locking ranges, pre-boot authentication and shadow MBR, usually via legacy tooling like sedutil or vendor specific tools.\n\ngo-tcg-storage takes a different path: a pure-Go, kernel-independent implementation of the TCG Storage stack, layered from a low-level drive interface (IF-SEND/IF-RECV over NVMe, SATA, and SAS) up through a core session library to a high-level locking API.\n\nThis lightning talk covers three things: (1) a short primer on TCG Storage and why an open, library matters for firmware and boot security; (2) the current state of go-tcg-storage \u2014 what works, which drives and SSCs are covered, and where the rough edges are; and (3) the roadmap: broader SSC and transport coverage, PBA workflows, release and packaging, testing, and documentation.", "recording_license": "", "do_not_record": false, "persons": [{"code": "8RMAYE", "name": "Christian Gr\u00f6nke", "avatar": "https://talks.osfc.io/media/avatars/8ZYCKJ_bTIfD4p.webp", "biography": "I am a firmware and embedded systems engineer with experience in safety\u2011critical operating systems, high\u2011security platform design, and host firmware development for modern hardware platforms. I have spent the past decade working on microkernel\u2011 and Linux\u2011based systems for defense and high\u2011assurance environments, focusing on partitioning, isolation, and robust system architectures that meet safety and security certification requirements. \n\nMost recently, I have led open\u2011source firmware efforts at 9elements, driving host firmware projects around coreboot, EDK2 (UEFI), and secure storage. Contributing to the development of secure and transparent firmware solutions for servers and security\u2011sensitive platforms.", "public_name": "Christian Gr\u00f6nke", "guid": "cf731e71-6d83-5023-b905-ecc6e2ac4f24", "url": "https://talks.osfc.io/osfc-2026/speaker/8RMAYE/"}], "links": [], "feedback_url": "https://talks.osfc.io/osfc-2026/talk/39MQKB/feedback/", "origin_url": "https://talks.osfc.io/osfc-2026/talk/39MQKB/", "attachments": []}, {"guid": "5933f85c-ccd1-5396-bf63-c235816ed12a", "code": "GN3GDN", "id": 102490, "logo": null, "date": "2026-09-17T10:15:00+02:00", "start": "10:15", "end": "2026-09-17T10:30:00+02:00", "duration": "00:15", "room": "Main", "slug": "osfc-2026-102490-nvidia-s-openbmc-contributions-and-the-road-ahead", "url": "https://talks.osfc.io/osfc-2026/talk/GN3GDN/", "title": "NVIDIA's OpenBMC Contributions and the Road Ahead", "subtitle": "", "track": null, "type": "Lightning Talk", "language": "en", "abstract": "NVIDIA's upstream OpenBMC progress, challenges, and roadmap", "description": "Over the past year, NVIDIA has deepened its investment in upstream OpenBMC, shifting from downstream patches toward upstreamt development. This talk covers what's landed upstream, and the tradeoffs in choosing to contribute rather than fork. We'll discuss the challenge of aligning fast-moving platform requirements with OpenBMC's community cadence, and how NVIDIA is restructuring internal workflows to reduce drift from upstream. Looking forward, we'll outline near-term priorities: and areas where closer collaboration with the community is needed.", "recording_license": "", "do_not_record": false, "persons": [{"code": "CKMVEZ", "name": "Deepak Kodihalli", "avatar": null, "biography": "Deepak Kodihalli is a Principal Engineer at Nvidia, where he leads the architecture of OpenBMC for the company's platforms. He is also actively working on contributing Nvidia's OpenBMC modifications back to the upstream community.", "public_name": "Deepak Kodihalli", "guid": "d548de09-421e-5791-bb61-c4414aa6bce3", "url": "https://talks.osfc.io/osfc-2026/speaker/CKMVEZ/"}, {"code": "G9ZR7R", "name": "Harshit Aghera", "avatar": "https://talks.osfc.io/media/avatars/VPHRHW_rgMBmSh.webp", "biography": "Harshit Aghera is a Software Engineer at NVIDIA, where he develops platform BMC software. He also contributes to the OpenBMC project, enhancing manageability support for NVIDIA platforms and devices.", "public_name": "Harshit Aghera", "guid": "f79ff143-c01c-5d1f-97ab-94e1a13b72c5", "url": "https://talks.osfc.io/osfc-2026/speaker/G9ZR7R/"}], "links": [], "feedback_url": "https://talks.osfc.io/osfc-2026/talk/GN3GDN/feedback/", "origin_url": "https://talks.osfc.io/osfc-2026/talk/GN3GDN/", "attachments": []}, {"guid": "977be292-1803-51d4-814e-1e636d940931", "code": "DERT3G", "id": 101729, "logo": null, "date": "2026-09-17T10:30:00+02:00", "start": "10:30", "end": "2026-09-17T10:45:00+02:00", "duration": "00:15", "room": "Main", "slug": "osfc-2026-101729-runtime-access-control-in-the-bootloader", "url": "https://talks.osfc.io/osfc-2026/talk/DERT3G/", "title": "Runtime Access Control in the Bootloader", "subtitle": "", "track": null, "type": "Lightning Talk", "language": "en", "abstract": "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.\n\nIn 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.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "YEDRRM", "name": "Ahmad Fatoum", "avatar": "https://talks.osfc.io/media/avatars/KQM3TB_kQMKDVd.webp", "biography": "Ahmad joined the kernel team at Pengutronix in 2018 to work full-time on furthering Linux world domination. He does so by helping automotive and industrial customers build embedded Linux systems based on the mainline Linux kernel.\nHaving a knack for digging in low-level guts, his tasks include hardware enablement, Linux driver development and boot loader porting.\nAhmad is a contributor to a number of open-source projects, including the Linux kernel and the barebox boot loader.", "public_name": "Ahmad Fatoum", "guid": "8bc89db0-3896-5f81-8a4c-b62f4a113e02", "url": "https://talks.osfc.io/osfc-2026/speaker/YEDRRM/"}], "links": [], "feedback_url": "https://talks.osfc.io/osfc-2026/talk/DERT3G/feedback/", "origin_url": "https://talks.osfc.io/osfc-2026/talk/DERT3G/", "attachments": []}, {"guid": "f34f8004-87ac-5977-98a9-0868fdc28428", "code": "FVUHU8", "id": 96896, "logo": null, "date": "2026-09-17T11:15:00+02:00", "start": "11:15", "end": "2026-09-17T11:30:00+02:00", "duration": "00:15", "room": "Main", "slug": "osfc-2026-96896-norbert-open-source-spi-flash-emulation", "url": "https://talks.osfc.io/osfc-2026/talk/FVUHU8/", "title": "NORbert: Open source SPI flash emulation", "subtitle": "", "track": null, "type": "Lightning Talk", "language": "en", "abstract": "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. \n\nThe 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.\n\nLink to NORbert: https://github.com/ArthurHeymans/NORbert", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "PDD8CN", "name": "Arthur Heymans", "avatar": null, "biography": "I'm Arthur Heymans. I've always been quite interested in how computers work, however, this interest only fully developed much later. While studying physics and philosophy at the university, I became very interested in the concept of free software via the \"about GNU\" page in my editor of choice, Emacs. The GNU/Linux OS is very usable as free software these days, however, firmware and some low-level drivers tend to present a different, much more closed story. This led me to discover coreboot, which is a project that offers an alternative to closed-source firmware/BIOS. Fast forward a few years and I'm a regular contributor to coreboot and have learned a great deal from incredible people who were willing to invest time in reviewing my patches. I secured a job at 9elements, which professionally involved me in multiple open-source firmware projects.\n\nThese days I'm expanding my horizon with firmware related web applications, rust firmware and FPGA programming.", "public_name": "Arthur Heymans", "guid": "9755d1a7-de9a-5803-a9d5-47d05a8a70be", "url": "https://talks.osfc.io/osfc-2026/speaker/PDD8CN/"}], "links": [], "feedback_url": "https://talks.osfc.io/osfc-2026/talk/FVUHU8/feedback/", "origin_url": "https://talks.osfc.io/osfc-2026/talk/FVUHU8/", "attachments": []}, {"guid": "350b8172-2812-5698-ac6b-238939436524", "code": "HMEUSQ", "id": 97648, "logo": null, "date": "2026-09-17T11:30:00+02:00", "start": "11:30", "end": "2026-09-17T11:45:00+02:00", "duration": "00:15", "room": "Main", "slug": "osfc-2026-97648-rewriting-firware-tools-in-rust-lowering-the-barrier-with-web-tools", "url": "https://talks.osfc.io/osfc-2026/talk/HMEUSQ/", "title": "Rewriting firware tools in rust, lowering the barrier with web tools", "subtitle": "", "track": null, "type": "Lightning Talk", "language": "en", "abstract": "\"If you cannot use a CLI, you probably have no business in doing firmware.\"\n\nThis 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.\n\nRust 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.\n\nRust 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.\n\nThe goal of this talk is to showcase how making a webui alongside a CLI is possible and give some examples.\n\nSome examples\nhttps://rflasher.9elements.com\nhttps://rem100.9ements.com\nhttps://github.com/ArthurHeymans/NORbert/pull/9 (PR for web tool)", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "PDD8CN", "name": "Arthur Heymans", "avatar": null, "biography": "I'm Arthur Heymans. I've always been quite interested in how computers work, however, this interest only fully developed much later. While studying physics and philosophy at the university, I became very interested in the concept of free software via the \"about GNU\" page in my editor of choice, Emacs. The GNU/Linux OS is very usable as free software these days, however, firmware and some low-level drivers tend to present a different, much more closed story. This led me to discover coreboot, which is a project that offers an alternative to closed-source firmware/BIOS. Fast forward a few years and I'm a regular contributor to coreboot and have learned a great deal from incredible people who were willing to invest time in reviewing my patches. I secured a job at 9elements, which professionally involved me in multiple open-source firmware projects.\n\nThese days I'm expanding my horizon with firmware related web applications, rust firmware and FPGA programming.", "public_name": "Arthur Heymans", "guid": "9755d1a7-de9a-5803-a9d5-47d05a8a70be", "url": "https://talks.osfc.io/osfc-2026/speaker/PDD8CN/"}], "links": [], "feedback_url": "https://talks.osfc.io/osfc-2026/talk/HMEUSQ/feedback/", "origin_url": "https://talks.osfc.io/osfc-2026/talk/HMEUSQ/", "attachments": []}, {"guid": "ebccc91d-871f-5b03-a610-f451fe9a3608", "code": "C8URL3", "id": 95920, "logo": null, "date": "2026-09-17T12:15:00+02:00", "start": "12:15", "end": "2026-09-17T12:30:00+02:00", "duration": "00:15", "room": "Main", "slug": "osfc-2026-95920-minimalist-uefi-implementation-for-virtual-machines", "url": "https://talks.osfc.io/osfc-2026/talk/C8URL3/", "title": "Minimalist UEFI Implementation for Virtual Machines", "subtitle": "", "track": null, "type": "Lightning Talk", "language": "en", "abstract": "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.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "8R7PTL", "name": "Borhan Tu\u011fsan Balc\u0131", "avatar": "https://talks.osfc.io/media/avatars/CDTBLR_8eJVhDm.webp", "biography": "A low level enthusiast focusing on Windows internals, UEFI, Hypervisors, SMM and security.", "public_name": "Borhan Tu\u011fsan Balc\u0131", "guid": "ebcdbae0-9e58-5ab4-b08c-c969fcfb6d1a", "url": "https://talks.osfc.io/osfc-2026/speaker/8R7PTL/"}], "links": [], "feedback_url": "https://talks.osfc.io/osfc-2026/talk/C8URL3/feedback/", "origin_url": "https://talks.osfc.io/osfc-2026/talk/C8URL3/", "attachments": []}, {"guid": "9f2afbe0-386f-5a55-a2d2-fb89c9325960", "code": "EUBBBZ", "id": 100966, "logo": null, "date": "2026-09-17T12:30:00+02:00", "start": "12:30", "end": "2026-09-17T12:45:00+02:00", "duration": "00:15", "room": "Main", "slug": "osfc-2026-100966-state-of-the-uefi-open-firmware-standards-across-modern-computing-platforms", "url": "https://talks.osfc.io/osfc-2026/talk/EUBBBZ/", "title": "State of the UEFI: Open Firmware Standards Across Modern Computing Platforms", "subtitle": "", "track": null, "type": "Lightning Talk", "language": "en", "abstract": "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.\n\nA 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.\n\nIn 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\u2019s 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.\n\nThe 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\u2019s standards efforts.\n\nFinally, 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.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "WUZF9T", "name": "Dong Wei", "avatar": "https://talks.osfc.io/media/avatars/J7CFPR_WnYDsmb.webp", "biography": "Dong Wei is an Arm Fellow and Lead Standards Architect of the Architecture and Technology Group in Arm Limited. Dong joined Arm in 2016. He leads the Arm SystemReady compliance program as well as PC BSA specification with definitions of the hardware, firmware requirements for the Arm-based systems. He also leads the system manageability and security requirements for these systems. In this standards-based effort, he covers industry standards such as PCI Express, TCG, CXL, UCIe, UEFI/ACPI, DMTF, and OCP.", "public_name": "Dong Wei", "guid": "54fe4a7a-7db2-5494-a5e8-77cdbd1e2520", "url": "https://talks.osfc.io/osfc-2026/speaker/WUZF9T/"}], "links": [], "feedback_url": "https://talks.osfc.io/osfc-2026/talk/EUBBBZ/feedback/", "origin_url": "https://talks.osfc.io/osfc-2026/talk/EUBBBZ/", "attachments": []}], "2nd Room": [{"guid": "f21c1010-2c34-59d3-9328-38eceb72883d", "code": "BHNZZ9", "id": 97102, "logo": null, "date": "2026-09-17T10:00:00+02:00", "start": "10:00", "end": "2026-09-17T12:00:00+02:00", "duration": "02:00", "room": "2nd Room", "slug": "osfc-2026-97102-automation-of-firmware-analysis-and-government-standard-reporting", "url": "https://talks.osfc.io/osfc-2026/talk/BHNZZ9/", "title": "Automation of Firmware Analysis and Government Standard Reporting", "subtitle": "", "track": null, "type": "Workshop", "language": "en", "abstract": "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.\n\nThe 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\u2019s usability, reporting structure, and relevance to real firmware security workflows. Feedback gathered during the workshop will inform the next stage of development and evaluation.", "description": "Attendees will see a live demonstration of the firmware analysis prototype, including security findings and severity ratings mapped to relevant NIST framework categories. The session will offer examples and discussions on the tool's usefulness, accuracy, and actionability. Participants do not need any prior knowledge of firmware reverse engineering, though a basic understanding of cybersecurity would aid in interpreting the tools' outputs. Feedback from both technical and non-technical attendees will inform future improvements to the prototype, including its interface, reporting structure, and relevance to practical firmware security workflows.", "recording_license": "", "do_not_record": false, "persons": [{"code": "HRSVQ7", "name": "Paul Underhill", "avatar": null, "biography": "Paul Underhill is an IT professional and Senior Lecturer at the University of Chester. His research interests include cybersecurity, firmware and digital forensics. He is currently completing a PhD focused on automation of firmware analysis and NIST-aligned reporting to support clearer identification, prioritisation, and understanding of firmware security issues.", "public_name": "Paul Underhill", "guid": "deabeb71-bb4c-5a45-9310-a8bbe455ca70", "url": "https://talks.osfc.io/osfc-2026/speaker/HRSVQ7/"}], "links": [], "feedback_url": "https://talks.osfc.io/osfc-2026/talk/BHNZZ9/feedback/", "origin_url": "https://talks.osfc.io/osfc-2026/talk/BHNZZ9/", "attachments": []}, {"guid": "96ab19f2-873b-5cd1-b860-f3e2b9091535", "code": "JBDWBK", "id": 103794, "logo": null, "date": "2026-09-17T14:30:00+02:00", "start": "14:30", "end": "2026-09-17T16:30:00+02:00", "duration": "02:00", "room": "2nd Room", "slug": "osfc-2026-103794-arm-systemready-workshop-open-platforms-and-firmware-development", "url": "https://talks.osfc.io/osfc-2026/talk/JBDWBK/", "title": "Arm SystemReady Workshop: Open Platforms and Firmware Development", "subtitle": "", "track": null, "type": "Workshop", "language": "en", "abstract": "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.\nThis 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.\nBeyond 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.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "XFX3P8", "name": "Ann Cheng", "avatar": "https://talks.osfc.io/media/avatars/RPJPFH_H0QZXRi.webp", "biography": "An engineer specialized in miscellaneous tasks. Over the years I've worked on BMC software, and validation, debugging problems that nobody wanted to own. ;)\n\n`I enjoy solving messy problems, building demos, and learning new things.`\n`AND I'm much better at debugging systems than speaking English.`", "public_name": "Ann Cheng", "guid": "a5482840-d7ba-5ae8-9ac1-4a8a046a0d22", "url": "https://talks.osfc.io/osfc-2026/speaker/XFX3P8/"}, {"code": "RWZHKU", "name": "Dong Wei", "avatar": null, "biography": null, "public_name": "Dong Wei", "guid": "b461d6f5-3f91-5b2a-9b86-1529620b6f63", "url": "https://talks.osfc.io/osfc-2026/speaker/RWZHKU/"}], "links": [], "feedback_url": "https://talks.osfc.io/osfc-2026/talk/JBDWBK/feedback/", "origin_url": "https://talks.osfc.io/osfc-2026/talk/JBDWBK/", "attachments": []}], "3rd Room": [{"guid": "9f4fdfb7-e51d-527b-b286-a3a7a3a0fcfe", "code": "FK9WNA", "id": 103798, "logo": null, "date": "2026-09-17T14:30:00+02:00", "start": "14:30", "end": "2026-09-17T16:30:00+02:00", "duration": "02:00", "room": "3rd Room", "slug": "osfc-2026-103798-hands-on-workshop-turning-manual-hubris-debugging-into-formal-shareable-tests", "url": "https://talks.osfc.io/osfc-2026/talk/FK9WNA/", "title": "Hands-on workshop: turning manual Hubris debugging into formal, shareable tests", "subtitle": "", "track": null, "type": "Workshop", "language": "en", "abstract": "A developer tooling pattern does double duty:  everyday Hubris debugging\ntools `humility`, `faux-mgs`, and `faux-ipcc`, become the core for\nmore formal tests anyone on the team can run. `sp-test` drives the tests,\nrecording each run so tests and results can be shared, analyzed, and reproduced, on\nan emulator and on real hardware.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "AJ8NAJ", "name": "Ben Stoltz", "avatar": null, "biography": "Ben Stoltz is an engineer at Oxide Computer Company, where he works on\nservice processor and root of trust firmware: its security, its update\npath, and, most recently, the testing infrastructure this talk covers.\nBefore Oxide, he worked on systems and infrastructure at Sun Microsystems,\nCisco, and Google.", "public_name": "Ben Stoltz", "guid": "d28f8105-0286-578e-85bc-dc8b576c67be", "url": "https://talks.osfc.io/osfc-2026/speaker/AJ8NAJ/"}], "links": [], "feedback_url": "https://talks.osfc.io/osfc-2026/talk/FK9WNA/feedback/", "origin_url": "https://talks.osfc.io/osfc-2026/talk/FK9WNA/", "attachments": []}]}}]}}}