Arm’s open source EBBR (Embedded Base Boot Requirements) specification is heading for its v1.0 release in December. Within a year or two, the loosely defined EBBR standard should make it easier for Linux distros to support standardized bootup on major embedded hardware platforms.
At the recent Embedded Linux Conference Europe, Grant Likely, a Linux kernel engineer who works at Arm, explained the basics of EBBR and why we need it. Previous ELC talks by Likely include a primer on hardware hacking basics for software developers.
EBBR is not a new technology, but rather a requirements document based on existing standards that defines firmware behavior for embedded systems. Its goal is to ensure interoperability between embedded hardware, firmware projects, and the OS.
The spec is based largely on the desktop-oriented Unified Extensible Firmware Interface (UEFI) spec and incorporates work that was already underway in the U-Boot community. EBBR is designed initially for Arm Linux boards loaded with the industry standard U-Boot or UEFI’s TianoCore bootloaders. EBBR also draws upon Arm’s Linaro-hosted Trusted Firmware-A project, which supplies a preferred reference implementation of Arm specifications for easier porting of firmware to modern hardware.
EBBR is currently “working fine” on the Raspberry Pi and has been successfully tested on several Linux hacker boards, including the Ultra96 and MacchiatoBIN, said Likely. Despite the Arm Linux focus, EBBR is already in the process of supporting multiple hardware and OS architectures. The FreeBSD project has joined the effort, and the RISC-V project has shown interest. Additional bootloaders will also be supported.
Why EBBR now?
The UEFI standard emerged when desktop software vendors struggled to support a growing number of PC platforms. Yet, it never translated well to embedded, which lacks the uniformity of the PC platform, as well as the “economic incentives toward standardization that work on the PC level,” said Likely. Unlike the desktop world, a single embedded firm typically develops a custom software stack to run on a custom-built device “all bound together.”
In recent years, however, several trends have pushed the industry toward a greater interest in embedded standards like EBBR. “We have a lot of SBCs now, and embedded software is getting more complicated,” said Likely. “Fifteen years ago, we could probably get by with the Linux kernel, BusyBox, and a bit of custom code on top. But with IoT, we’re expected to have things like network stacks, secure updates, and revision control. You might have multiple hardware platforms to support.”
As a result, there’s a growing interest in using pre-canned distros to offload the growing burden of software maintenance. “There’s starting to be an economic incentive to boot an embedded system on all the major distros and all the major SBCs,” said Likely. “We’ve been duplicating a lot of the same boot setup work.”
The problem is that bootloaders like U-Boot behave differently on different hardware, “with slightly different bootstrips and Device Tree setup on each board,” he continued. “It’s impossible for Linux distros to support more than a couple of boards. The growing number of board-specific images also poses problems. Not only is it a problem of the boot flow — getting the firmware on the system into the OS — but of how to tell the OS what’s on the board.”
As the maintainer of the Linux Device Tree, Likely is an expert on the latter issue. “Device Tree gives us the separation of the board description and the OS, but the next step is to make that part of the platform,” he explained. “So far we haven’t had a standard pre-boot environment in embedded. But if you had a standard boot flow and the machine could describe itself to the OS, the distros would be able to support it. They wouldn’t need to create a custom kernel, and they could do kernel and security updates in a standard way.”
Some embedded developers have expressed skepticism about EBBR’s dependence on the “bloated” UEFI code, with fears that it will slow down boot time. Yet, Likely claimed that the EBBR implementation adds “insignificant” overhead.
EBBR also differs from UEFI in that it’s written with consideration of embedded constraints and real-world practices. “Standard UEFI says if your storage is on eMMC, then firmware can’t be loaded there, but EBBR is flexible enough to account for doing both on same media,” said Likely. “We support limited hardware access at runtime and limited variable access to deal with things like the mechanics of device partitioning.” In addition, the spec is flexible enough that “you can still do your custom thing within the standard’s framework without breaking the flow.”
EBBR v1.0 and beyond
When Arm initially released its initial universal boot proposal “nobody was interested,” said Likely. The company returned with a second EBBR proposal that was launched as an open source project with a CC-BY-SA license and a GitHub page. Major Linux distro projects started taking interest.
Arm is counting on the distro projects to pressure semiconductor and board-makers to get onboard. Already, several chipmakers including ST, TI, and Xilinx have shown interest. “Any board that is supported in U-Boot mainline should work,” said Likely. “Distros will start insisting on it, and it will probably be a requirement in a year or two.”
The upcoming v1.0 release will be available in server images for Fedora, SUSE, Debian, and FreeBSD that will boot unmodified on mainline U-Boot. The spec initially runs on 32- and 64-bit Arm devices and supports both ACPI power management and Linux Device Tree. It requires Arm’s PSCI (Power State Coordination Interface) technology on 64-bit Arm devices. The v1.0 spec provides storage guidance and runtime services guidance, and it may include a QEMU model.
Future releases will look at secure boot, capsule updates, more embedded use cases, better UEFI compliance, and improved non-Linux representation, said Likely. Other goals include security features and a standard testing platform.
“These are all solvable problems,” said Likely. “There are no technical barriers to boot standardization.”
You can watch the complete presentation here:
