Embedded, Mobile and Automotive
ARM SCP firmware porting
<p>Contemporary embedded SoCs increasingly act as a network of specialized CPU cores, some dedicated to user applications, other dedicated to real time tasks, others to security. All those cores still share one set of critical peripherals, which require resource access coordination. This is increasingly implemented by making all cores talk to a dedicated core called SCP, the System Control Processor, using SCMI protocol. The SCP is responsible for coordinating access to critical resources, clock, reset, power domain, and so on. An open source firmware, SCP-firmware, can be used on the SCP to offer the SCMI services. This talk explains how to implement a port of SCP-firmware to an SCP core, what is the architecture of SCP-firmware, its initialization process, its driver or module model, how the ordering of module start up is achieved, how to implement UART and mailbox driver modules, and finally how SCMI server services are bound to modules and exposed to other cores. This is illustrated by an example code from existing SCP-firmware port to contemporary SoC.</p>
<p>LINKS:
- ARM SCP firmware https://gitlab.arm.com/firmware/SCP-firmware
- SCMI specification v4.0 https://developer.arm.com/documentation/den0056/f</p>
Additional information
| Live Stream | https://live.fosdem.org/watch/ud2120 |
|---|---|
| Type | devroom |
| Language | English |
More sessions
| 2/1/26 |
<p>When a Python program crashes, a backtrace is printed — often enough to pinpoint and fix the issue. When a C or C++ program crashes on an embedded Linux system, however, nothing appears by default — except perhaps the dreaded “Segmentation fault” message. Unfortunately, there’s no simple --enable-backtrace option to enable human-readable backtraces at build time. Even worse, generating useful backtraces involves many subtle factors, and there’s no comprehensive resource that ...
|
| 2/1/26 |
<p>Rust is rapidly reshaping how we build reliable software — including in areas once dominated by C. But what does it really look like to bring Rust into an existing embedded codebase? This talk shares the hands-on experience of migrating a working ESP32 firmware from C to no_std Rust, highlighting what Rust changes, what it improves, and where the bumps in the road are.</p> <p>Starting from a hobby project — a wireless arcade button used in a multiplayer blind test game ...
|
| 2/1/26 |
<p>Ariel OS is a new RTOS for microcontrollers written fully in Rust. It supports popular hardware architectures (Cortex-M, ESP, RISC-V) and popular boards from vendors such as Espressif, Nordic, Raspberry Pi and ST. Ariel OS is built on top of Embassy and the embedded-hal traits, adding various OS functionalities and a multi-core capable scheduler. Ariel OS further aims to integrate the best of the available embedded Rust ecosystem to provide a seamless, batteries-included experience for ...
|
| 2/1/26 |
<p>What happens when you mix German luxury engineering with a bit of DIY spirit? You get the world’s most over-engineered office chair.</p> <p>This talk dives inside a BMW comfort seat — so when you get home in your 7-series, you can feel right at home in the same seat at your desk. Packed with ECUs, motors, pumps, heaters, ambient lighting and airbags, we’ll explore how it all works, how the seat communicates over CAN, j1850 CRCs, some quirks, and how an ESP32 can take control of ...
|
| 2/1/26 |
<p>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.</p> <p>This showcase illustrates how to avoid this entirely: one bootloader image that adapts securely to each lifecycle stage using fuse-based state transitions, device-bound unlock tokens, and policy-driven access control.</p> <p>With barebox and OP-TEE, we’ll show how these mechanisms enforce secure operation while still allowing ...
|
| 2/1/26 |
<p>Secure-boot chains in embedded systems have largely converged on common building blocks like FIT, dm-verity or UKIs.</p> <p>The bootloader is anchored in hardware trust, then verifies an operating system image, and the chain continues, eventually covering the application.</p> <p>But there is a gap when it comes to adding unit-specific bits of information, such as per-device configuration, hardware calibration, or MAC addresses needed early in boot.</p> <p>In this segment, I present the TLV ...
|
| 2/1/26 |
<p>Most modern embedded SoCs provide a ROM-based recovery mechanism to bootstrap an unflashed device or revive a system whose bootloader has failed. Unfortunately, these mechanisms are typically vendor-specific, poorly documented, and supported only non-standard, sometimes closed, tools. Engineers end up juggling different utilities for each SoC family, with varying user interfaces and commands.</p> <p>Snagboot addresses this fragmentation. It is a vendor-agnostic, fully open-source recovery and ...
|
