Zephyr on Chromebooks Next generation open source Embedded Controller Paul Fagerburg - [email protected] Jack Rosenthal - [email protected] The ChromiumOS Embedded Controller ● Initially created in ~2012 for the Google Chromebook Pixel and Samsung Chromebook. ● Handles tasks like: ○ Keyboard ○ AP power sequencing ○ Type C power delivery ○ Battery charging ○ Sensors ○ Buttons ● Open source (https://chromium.googlesource.com/chromiumos/platform/ec.git) The Motivation While platform/ec OS meets our a technical requirements, it has non-technical limitations: ● In-House OS Kernel ○ Limited number of community contributors ○ Hard for SoC vendors, chip vendors, and OEMs to collaborate ● Develop twice ○ Once for proprietary OS machine ○ Again for ChromeOS machine ○ SoC power sequencing ○ Chip drivers ○ OEM-specific features Zephyr OS “The Zephyr Project TM strives to deliver the best-in-class RTOS for connected resource-constrained devices, built to be secure and safe.” ● Support for over 200 boards ● Joined the Linux Foundation in 2016 Why Zephyr? “The Zephyr Project has built a strong community of experts, and we look forward to working with all of the participating organizations to improve the state of the RTOS our products depend on.” Puneet Kumar, Director of Engineering, Chrome OS. With Zephyr OS, everyone can pool their efforts for chip/platform support into one RTOS kernel. What Zephyr Brings To Google ● Community ● Open source ● Neutral governance ● In-depth security development lifecycle ● Additional chip support ● Better collaboration with enterprise partners Technical cool stuff: multicore, memory sandboxing, options for scheduling algorithms What Google can bring to Zephyr ● Standards-compliant USB-C PD stack ○ Robust test suite ○ Charger quirk detection ● Vendors adding support upstream ○ Chip support ○ SoC support ● Google engineers participating in working groups, code review, and design How we're transitioning ● Implemented a shim adapter layer for our existing EC code, which enables the APIs of Zephyr application EC application our existing OS to work on Zephyr OS. (thread) (task) ○ Rename EC APIs to avoid collisions ● platform/ec is now also a Zephyr Module, EC API allowing it to seamlessly compile with Shim Zephyr OS ● After products begin to launch using Zephyr Zephyr API (e.g. i2c, gpio, keyboard driver) OS, we will start migrating modules to use native Zephyr APIs instead. Zephyr kernel ● See zephyr/shim in the public platform/ec repository Example shim: console commands /* Converts from the EC's command declaration to a Zephyr shell command */ #define DECLARE_SAFE_CONSOLE_COMMAND(NAME, ROUTINE, ARGDESC, HELP) \ static int stub_ ## ROUTINE(const struct shell *shell, size_t argc, \ char **argv) \ { \ global_shell = shell; \ return ROUTINE(argc, argv); \ } \ SHELL_CMD_REGISTER(NAME, NULL, HELP, stub_ ## ROUTINE) How we're transitioning ● Unit tests are being moved to the Ztest API ○ Makes upstreaming easier ● Unit tests build directly for Zephyr's native_posix target ● A compile-time translation layer allows the EC Unit Test unit tests to build for the EC host target Ztest API Test shim EC test API Zephyr EC host target native_posix target Thank you.