Embedded · OS & Drivers · Cloud
From device to cloud,
engineered at every layer.
EOTICS designs and builds the hard layers of connected products: firmware and board support, kernels and drivers, the middleware in between, and the cloud platform that runs the fleet. One senior team, accountable end to end.
What we do
Three layers. One team.
Connected products fail at the boundaries between layers. We work across all of them, so the interfaces get designed once instead of negotiated between vendors.
⚙ Embedded systems
Firmware, RTOS integration, bootloaders and board support packages: from first power-on to a production image your team can rebuild with one command.
Typical work
- Board and SoC bring-up
- Yocto and Buildroot BSPs
- U-Boot, UEFI and secure boot
- Zephyr and FreeRTOS firmware
⚡ OS, drivers & middleware
Kernel and driver work on Linux and Windows, plus the layers that connect hardware to services: protocol stacks, IPC, OTA agents and SDKs.
Typical work
- Linux kernel drivers and subsystems
- Windows kernel-mode drivers (WDM, KMDF, NDIS, StorPort, WDDM)
- USB, PCIe, SDIO, Wi-Fi and Ethernet
- MQTT, gRPC and CoAP stacks, OTA clients
☁ Cloud platforms for fleets
Device identity and provisioning, telemetry ingestion, fleet management and staged OTA rollouts, built cloud-native and observable from day one.
Typical work
- AWS IoT Core and Azure IoT Hub integrations
- MQTT brokers and time-series pipelines
- OTA servers and rollout orchestration
- Kubernetes-based device services
Already shipping?
We take the bugs other teams gave up on.
Intermittent crashes on multi-core boards. DMA corruption nobody can reproduce. A Wi-Fi link stuck at a tenth of its datasheet throughput. A boot that takes forty seconds. Root-causing problems at the hardware and kernel boundary is the work we like most, and every diagnostic ends with a written root-cause report and a regression test.
How we work
Clear scope, visible progress, no black boxes.
01
Discovery call
Thirty minutes, free. We listen, ask the awkward questions and tell you honestly whether we are the right team for the problem.
02
Assessment and plan
When the problem is unclear, a short paid assessment: we read the code, run the hardware and deliver a written plan with scope, risks and an estimate.
03
Build in your repositories
Work lands in your repositories and CI from day one, with weekly demos on real hardware and design decisions written down as they are made.
04
Handover
Documentation, tests and a knowledge-transfer session, so your team owns the result and does not depend on us to maintain it.
Engineering depth
The layers we work in, concretely.
No buzzwords, just the subsystems, buses and tools we actually work with. Our engineering blog documents what we learn on the way.
Boot & kernel
- UEFI / EDK2 and U-Boot
- Arm Trusted Firmware, secure boot chains
- Linux kernel: drivers, memory management, SMP bring-up
- Windows kernel-mode drivers and NT internals
- Page tables, exceptions and unwinding on ARM64
- RTOS: Zephyr, FreeRTOS, ThreadX
Hardware & buses
- Raspberry Pi 4 / 5 and Compute Modules
- Cortex-A76 / A72 and Cortex-M targets
- PCIe, xHCI USB 3, SDIO, I²C, SPI, GPIO
- GICv3 interrupt controllers, MSI and ITS
- Broadcom CYW43xx Wi-Fi, Gigabit Ethernet
- DMA, cache coherency, memory ordering
Middleware & OS layers
- MQTT, CoAP, gRPC, AMQP
- D-Bus, ZeroMQ, shared-memory IPC
- OTA agents: Mender, RAUC, SWUpdate
- TCP/IP stacks and socket layers
- Compatibility layers and emulation (Wine, ReactOS, FEX)
- Cross-platform C and C++ SDKs
Cloud & fleet
- AWS IoT Core, Azure IoT Hub
- EMQX and Mosquitto brokers
- TimescaleDB and InfluxDB pipelines
- Kubernetes and containerised services
- Device identity: X.509, mTLS, provisioning
- Prometheus and Grafana observability
Why EOTICS
What working with us looks like.
One team across the stack
The firmware engineer and the cloud engineer sit in the same conversation. Interfaces are designed once and tested end to end, not negotiated between vendors.
We reproduce before we fix
Every bug gets a reproducible rig first: real boards on the bench, QEMU models with a kernel debugger attached, and telemetry that shows what actually happened.
Senior engineers only
No hand-off to a junior bench after the sales call. The engineer who scopes the work is the one who writes it, tests it on hardware and ships it.
Written down
Architecture decisions, runbooks and root-cause reports ship with the code. Your team can maintain, extend and audit what we build.
Engineering blog
Notes from the bench.
Root causes, design decisions and checklists from real bring-ups, driver work and fleet platforms. Written by the engineers who did the work.
- Bringing an OS up on Raspberry Pi 5: what the RP1, PCIe and the GIC demand from your kernelNotes from an ARM64 kernel bring-up on the Raspberry Pi 5: almost every peripheral sits behind a PCIe link, DMA is not coherent with the CPU caches, MSIs go through the GIC ITS, secondary cores arrive at EL2, and one xHCI flag decides whether USB bulk transfers ever complete.
- ARM64 SMP bugs are memory-ordering bugs until proven otherwiseCode that ran for years on x86 falls over one boot in fifty on a four-core Cortex-A76. The six patterns behind almost every such failure we have chased, the barriers that fix them, and why QEMU on a laptop will hide all of them.
- Where the packets per second go: SDIO Wi-Fi throughput on a Broadcom CYW43455A Wi-Fi link that tops out around one megabit with an idle CPU is not a radio problem. Six host-side causes, from missing receive glomming to a byte-mode CMD53 bug, and how to count SDIO transactions per packet before touching anything else.
Questions
Before you get in touch.
What size of project do you take on?
Anything from a two-week diagnostic to a multi-month build. We decline work we cannot test properly, and we say so on the first call rather than three months in.
Do you work with existing codebases?
Most of our work starts inside code someone else wrote: vendor BSPs, legacy drivers, half-finished cloud backends. We read before we rewrite, and we only rewrite when we can show why.
Who owns the code?
You do. Work is delivered into your repositories under your licence terms. We sign an NDA before any technical detail is shared, and we never reuse client code elsewhere.
How do you charge?
Fixed scope where the outcome is well defined, time-and-materials retainers for ongoing engineering. Every proposal is written and itemised, so you know what you are paying for before we start.
How do we communicate during a project?
A shared channel of your choice, a weekly demo on real hardware, and written status notes. You always know what was done, what is blocked and what comes next.
Tell us what you are building.
We reply within one business day, usually with questions.