ODP Integrator Track Overview

The Integrator track is designed for individuals who are interested in integrating various components and systems within the Open Device Partnership (ODP) framework. This track focuses on the design, implementation, and testing of integration solutions that ensure seamless interoperability between different ODP components. Participants will learn how to create robust integration solutions that enhance system functionality, improve performance, and ensure reliability across ODP implementations.

flowchart TD
    A[Bootloader / Coreboot]
    B[Patina DXE Core - _EFI_]
    C[Runtime OS]
    D[EC Subsystem - _Services_]
    E[EC Hardware Platform]

    A --> B --> C
    C --> D
    D --> E

Overall integration may be broken down into separate areas of concern, often managed by different individuals or teams:

Facet	Role/Responsibility
Patina Platform	Build and sign DXE Core Images
EC Runtime Integration	Connect EC Services to HAL and mock/live backends
Update + Bootflow	ENsure Patina and EC stay in sync across restarts
Test Infrastructure	Run Integration Test suites, validate behaviors
Security/Compliance	Validate signature chain, FF-A flows, runtime policies

Patina Integration

Integration approaches for Patina are covered at Patina DXE Core Platform Integration

This is part of the larger Developer documentation for Patina that should be fully reviewed before attempting integrations.

Integration for a virtual environment for examples or testing may benefit from the QEMU support repositories

Find other Patina relevant repositories in the What's in ODP? table.

Embedded Controller Integration

EC integration, like Patina, is performed statically at build time. Subsystems, services, and hardware abstraction layers (HALs) are all compiled into the final binary. There is no dynamic component registration at runtime. Integration focuses on correctly assembling services, devices, and component instances into the expected structure and ensuring testability and modularity are preserved.

Embedded Controller Integration Goals

Build and wire up runtime subsystems (e.g., Battery, Charger, Thermal)
Inject real or simulated hardware abstraction layers (HALs)
Ensure Service trait implementations are registered and running
Test full EC behavior with cargo test, using mock HALs

flowchart TD
    A[Component - _Implements Trait_] --> B[Device - _Manages State + HAL_]
    B --> C[Controller - _Implements Service Trait_]
    C --> D[Service Registry - _Static at Compile Time_]
    D --> E[Executor - _Runs Polling Loop_]

Key Integration Elements

Device<T>: A wrapper around a trait-implementing component that manages shared state, message passing, and HAL access
Controller: Implements the Service trait; manages component lifecycle and message dispatch
ServiceRegistry: Central runtime registry for services, used by the executor to poll or handle messages
Executor: The async runtime (usually embassy::executor::Executor) that drives services

Integration Test Example

In the Battery Subsystem Walkthrough, we construct a BatteryController, register it with the service registry, and run a full test loop using a virtualized SmartBattery device. This integration-style test validates runtime behavior without requiring actual hardware.

pseudo-code

#![allow(unused)]
fn main() {
let battery = BatteryDevice::new(...);
let controller = BatteryController::new(battery.clone());

SERVICE_REGISTRY.register(controller);
EXECUTOR.run();
}

Comparison of Patina vs EC Integration Concerns

Concern	Patina	EC
✅ Component Registration	Static via `.with_component()` chaining	Static via `init()` + `register()`
✅ Execution Model	EFI boot entrypoint	`embassy` async executor
✅ Dependency Injection	Function-level parameters	Struct-wrapped traits
✅ Component Lifetime Management	Core-managed	Controller-managed
✅ Unit test support	Host-driven tests (mocked context)	Host-driven tests (mocked HALs)
✅ Integration Testing	Possible via QEMU or structured test harness	Async harness + host logging

Preparing for Hardware Targets

While QEMU-based builds are ideal for development and testing, most real-world use cases require deployment to actual hardware platforms. Here we will point out some of the key steps, challenges, and considerations when preparing an ODP-based firmware system for hardware targets.

Changes when targeting real hardware

Aspect	QEMU	Hardware
Peripherals	Virtualized and generic	Must match actual hardware
Flash Layout	Loosely defined	Must adhere to board specifications
Console / Logs	`stdout` or `debug.log`	UART/serial or memory-mapped output
Bootloader	`stuart_build` wrapper	coreboot, U-Boot, ROM Bootloader
EC-HAL	Fully mocked	Must be implemented for real I/O

Firmware Packaging

For Patina:
- The .efi binary must be embedded into the platform firmware image
- Secure boot considerations apply (keys, signatures)
- On some platforms (coreboot, U-Boot), a custom payload loader may be required
For EC:
- The final .elf or .bin must target your microcontroller's flash layout.
- Build system should include appropriate memory map
- External flash programming may be needed (e.g. SWD/JTAG, USB DFU)

HAL Transition Checklist

Replacing mocks with real hardware access requires caution and hardware validation.

☐ Is your HAL for I2C, GPIO, ADC, etc. implemented for your board?

☐ Are your EC services updated to use the correct HAL instance?

☐ Have you validated pin mappings and timing constraints?

☐ Is your async runtime configured correctly for interrupts, clocks, and wake/sleep behavior?

☐ Are all non-implemented traits hidden behind feature flags or marked unimplemented!()?

Secure Services and Platform Constraints

FF-A support (used by EC secure services) is not available on x86 platforms — fallback mechanisms are needed
Memory buffers for FF-A (on ARM) must be in reserved and trusted memory regions
BIOS/UEFI loaders on some x86 platforms may block or filter EC messages
Ensure your platform’s firmware is not intercepting ACPI or EC I/O, unless explicitly intended

ODP Documentation Guide