Schematic and PCB — building an embedded operating system substrate

Research · Substrate Engineering

Building operating systems for the embedded world.

Hardware choices, schematic design, OS substrate selection — the foundation guides on what you should know before writing a single line of EoS code. Open hardware reference designs, Yocto/buildroot meta-layers, and the EoS RTOS substrate, all under permissive licenses.

Overview

Hardware-software co-design from day one

The biggest mistake in embedded development is treating the OS as something you bolt on after silicon arrives. The right approach is co-design: silicon constrains the OS, and the OS shapes silicon choices.

This page captures what the foundation has learned across hundreds of hardware reviews, schematic critiques, and OS-bring-up exercises with member organisations.

The Four Layers

From silicon to substrate

Hardware interfaces, schematic design, and the two OS-substrate choices the foundation supports.

Hardware

Electrical Engineering Interfaces

Choosing the right MCU/SoC, peripherals, and power tree before any line of OS code is written. The EoS HAL targets 33 peripheral classes — UART, SPI, I²C, CAN, USB, Ethernet, QSPI, MMC, ADC, DAC, PWM, RTC, and more — across Cortex-M0/M4/M7/M85, RV32IMAC, and select RV64.

33 peripheral classes in HAL
Cortex-M0/M4/M7/M85 + RV32/RV64
Power-tree analysis tooling
DMA + interrupt arbitration patterns

CAD

Schematic & PCB layout

Open hardware reference designs maintained by the Hardware Reference Designs working group. KiCad sources, full BOMs, gerber output, and JLCPCB-ready production files. Reference designs for 7 popular MCU families published; 12 more in active review.

KiCad source for all reference boards
Full BOM + JLCPCB production files
12 more boards in working-group review
CC-BY-SA 4.0 hardware license

OS Choice

Open-source Linux substrate

For Cortex-A class targets and Linux-capable RISC-V cores. Yocto + buildroot meta-layers maintained by the foundation; mainline kernel patches contributed back. Use when you need POSIX, full networking stack, and a rich userland.

Yocto meta-eos layer
Buildroot defconfig presets
Mainline kernel patches upstreamed
systemd-free init option

OS Choice

EoS RTOS substrate

For deterministic real-time on Cortex-M and microcontroller-class RISC-V. Sub-microsecond context switch, deterministic priority ceiling, optional EoS-S Safety-Certified subset for SIL-3. Use when timing matters more than richness.

Sub-µs context switch
Priority ceiling protocol
EoS-S SIL-3 subset (in review)
Footprint as low as 6 KB code

Decision Matrix

Linux or RTOS — which substrate?

Side-by-side on the eight axes that usually decide the choice. Both substrates ship in the EoS ecosystem; choose per profile.

Aspect	Linux substrate	EoS RTOS substrate
Determinism	Soft real-time (PREEMPT_RT helps)	Hard real-time, sub-µs guarantees
Memory footprint	Linux kernel ~ 4-8 MB minimum	EoS RTOS from 6 KB
Boot time	1-3 s typical with systemd	< 50 ms cold boot
POSIX	Full POSIX	Subset (threads, mutexes, queues)
Networking	Full TCP/IP, BSD sockets	lwIP integration
Filesystem	ext4, btrfs, F2FS	FatFs, LittleFS via eDB
Userland richness	Glibc + thousands of packages	C standard library only
Use case	Gateways, infotainment, edge servers	Microcontrollers, motors, safety

Best Practices

What to do (and what to avoid)

Recurring patterns from hundreds of foundation code reviews. The shortcuts that bite you later.

DO: separate the HAL from your business logic

The EoS HAL exists for a reason — every peripheral access goes through a portable interface. New silicon? Implement the HAL trait once; all your application code Just Works. The most common mistake we see in code reviews is direct register access from app-level code.

DON'T: build your own scheduler unless you must

The EoS RTOS scheduler has been hand-tuned for sub-µs context switch and formally verified for context preservation. There are very few legitimate reasons to write your own. If you think you have one, file an RFC — the kernel WG has probably considered it.

DO: pin your toolchain version

Reproducible builds depend on toolchain stability. The Reproducible Builds working group publishes pinned toolchain bundles for every EoS release. Consume those, not 'latest GCC' from your distro.

DON'T: skip the eBoot chain of trust

Yes, you can boot directly into EoS without eBoot for development. Don't ship that. The chain of trust gives you signed manifests, anti-rollback, and runtime attestation — non-trivial to retrofit later.

DO: use eos-platform profiles, not hand-rolled configs

The eos-platform 1.0 manifest schema captures every configuration choice you'd make manually — and gates them behind validation. Profile inheritance lets you derive variants without copy-paste drift.

Start building. Read the source.

Reference designs, meta-layers, and the EoS RTOS — every line is open-source. Or join the Hardware Reference Designs working group.

Read the docs GitHub ↗Join a working group

Building operating systems for the embedded world.

Hardware-software co-design from day one

Electrical Engineering Interfaces

Schematic & PCB layout

Open-source Linux substrate

EoS RTOS substrate

Neural Link Architecture

AI Operating Systems

Neural Link & AI

Future Research

Start building. Read the source.