Custom Board Bringup In Zephyr

The explosive growth of The Zephyr Project RTOS has resulted in Zephyr supporting close to 850 boards and 200 shields. However, one of the challenges that any embedded software engineer faces is customizing their application for the hardware used in their commercial product. The same challenge exists for Zephyr as well.

In this talk, Mohammed will demonstrate some personal best practices he applies when creating a Zephyr application for custom hardware. His talk will cover the following topics:

• Migrating away from development boards
• Leveraging existing boards in Zephyr for minor tweaks
• Creating entirely new boards in Zephyr for major projects
• Strategies for new board creation
• Upstream considerations

What this presentation is about and why it matters

When does a Zephyr overlay stop being a neat shortcut and start becoming a maintenance problem? Mohammed Billoo uses that tension to frame a practical talk on board bringup for custom hardware. The session is a hands-on walkthrough, grounded in the path from a known development kit to a real board definition, with examples drawn from device tree, Kconfig, pin control, and sample validation. It is less about theory than about the decisions that keep bringup manageable when the hardware changes, the board evolves, or the project needs to be shared across a team.

Who will benefit the most from this presentation

• Firmware engineers who are moving from dev kits to production hardware and need a repeatable bringup approach
• Embedded developers who already use Zephyr samples but are now dealing with custom sensors, buses, or pin assignments
• Hardware-software integrators who have to decide whether to adapt an existing board or define a new one
• Team leads who want fewer ad hoc project changes and a cleaner path for colleagues to build and test

What you need to know

Helpful background, but not strict requirements:

• Basic familiarity with Zephyr projects and building/flashing applications
• Comfort reading device tree overlays and simple Kconfig settings
• Some exposure to custom embedded hardware bringup, especially UART, GPIO, or I2C peripherals

Glossary (terms used in this talk)

• Device Tree: A data-description format used to describe the hardware layout of a board so that application code is decoupled from pin numbers and peripheral addresses.
• Kconfig: A menu-driven build configuration system used to enable or disable features at compile time so only required modules are included.
• UART: A serial communication peripheral widely used for debug output and host-device messaging. It can carry logs or test results during embedded startup and shutdown flows.
• Devicetree: A hardware description format used to express board layout, peripherals, buses, and their relationships in a structured way. It lets software describe the target hardware without hard-coding board-specific details into application code.
• Pin control: A mechanism for configuring how microcontroller pins are routed and electrically configured for peripherals and board functions. It is commonly used to match software behavior to custom board wiring.

Toolbox (mentioned in this talk)

• West: The Zephyr project meta-tool and workspace/build frontend used to manage projects and builds, commonly invoked alongside CMake in Zephyr-based development.
• Zephyr: Zephyr is an open-source real-time operating system for resource-constrained devices, supported by many embedded toolchains and debuggers.
• NXP MCX A156 Development Board: A vendor development board used to prototype on the same MCU family before moving to custom hardware. Development boards are useful for validating samples, flashing, and debugging before a custom PCB is ready.
• nRF52840 Development Kit: A development kit for prototyping on Nordic's nRF52840 platform. It provides a convenient starting point for bringup, especially when comparing a custom module or board against a known-good reference design.
• SEGGER J-Link: A hardware debugger and probe used to flash and debug embedded targets. It is commonly used when a custom board does not include an onboard debugger.
• Tag-Connect: A compact programming and debug connection system that avoids a permanent header on the PCB. It is often used on custom boards where space is tight and an external debug probe is expected.

Final thoughts

Practical, opinionated, and grounded in real bringup tradeoffs, this talk gives you a useful way to think about board-level changes in Zephyr without turning every problem into a new board definition. The value here is a sharper diagnostic lens for deciding where hardware-specific details belong, how to keep project configuration from drifting into board configuration, and how to make future maintenance less painful. It will help engineers who own custom hardware, and the teams who have to live with it. The spirit is simple: start with the smallest thing that can work, then make the structure fit the hardware.

This overview is AI-generated from the session transcript. Spot an issue? Let us know.