What it actually takes to bring up embedded Linux on a new board — CAN bus data acquisition on i.MX6 and a full OpenWrt smart-home router.
Every embedded project plan has the same quiet assumption: the board support package will more or less work, and the real engineering starts with the application. In practice, the opposite is true. BSP bring-up — getting the bootloader, kernel, device tree, drivers, and userspace to all agree with a brand-new piece of hardware — is the phase where schedules go to die. The kernel compiles cleanly. The build system reports success. And then the board does nothing, or worse, does something subtly wrong that only surfaces three weeks later under load.
At XTELL we have done this work across automotive, industrial, and consumer products. Two recent projects sit at opposite ends of the linux embedded spectrum and, taken together, cover most of what a team needs to know. The first was a multi-channel CAN bus data acquisition system on an i.MX6 Quad/Dual platform, built around our CanMain module for automotive and industrial control. The second was a smart home router built on OpenWrt, running on an MT7621 with 512MB of RAM and dual-band WiFi, integrating Zigbee, Bluetooth, MQTT, and CoAP into one unified control center. One is a bare-metal-style bring-up where you own every driver decision; the other is a deliberate decision not to own the networking stack, and to build on top of a mature distribution instead.
This article distills the practical lessons from both: where to start, how to integrate a real-time peripheral like CAN, when OpenWrt is the right answer instead of a custom distro, how to choose userspace languages, and the checklist we run on every new board before we call the BSP done. If you are facing a board that does not yet run Linux, our Linux BSP development services are built around exactly this kind of work.
On every new board, the first peripheral that matters is not the display, not the network, not the CAN controller — it is the serial console. Until you have a reliable serial path out of the board, you are debugging blind. This was the first lesson of the i.MX6 project, and it is a lesson we relearn on every platform.
The early days of the i.MX6 bring-up were spent with minicom and cutecom, watching boot logs scroll by and hunting for the exact line where things went wrong. Serial debugging sounds trivial until you are doing it at 2 a.m. with a board that prints nothing at all. A silent board is the hardest failure mode in bring-up: no panic, no stack trace, no error — just nothing. In almost every case we have seen, the root cause is one of a short list: the console UART is not the one the bootloader configured, the baud rate is mismatched, the device tree points the console at the wrong node, or the bootloader never handed control to the kernel in the first place.
Rule of thumb: if you cannot see the bootloader, you do not have a Linux problem. You have a hardware or bootloader problem, and no amount of kernel configuration will fix it.
Our discipline is simple. Before touching the kernel, we establish a stable serial session with minicom or cutecom and confirm the bootloader prompt. Then we confirm the kernel command line actually names the console we are watching. Only then do we start reading kernel boot logs. This sounds obvious, but we have seen teams lose days to a kernel that was booting perfectly while they stared at the wrong UART.
Once the console is live, it becomes the ground truth for the rest of the bring-up. Every driver added to the device tree, every clock tree change, every pinmux adjustment is validated against serial output first. Automated logging of the full boot sequence — captured from first bootloader character to login prompt — is part of our standard workflow, because the day you need to diff a working boot against a broken one, you will be glad the log exists.
The i.MX6 project — our i.MX6 CAN bus system — is a good case study in driver-level bring-up because the challenge was not getting Linux to boot. The challenge was real-time, multi-channel CAN data acquisition with reliable communication, for automotive and industrial control applications where dropped frames are not an option.
The architecture centers on the CanMain module, which handles multi-channel CAN data acquisition, parsing, and storage. Bringing this up meant getting several layers right at once. First, the FlexCAN controllers on the i.MX6 had to be correctly described in the device tree — clocks, pin multiplexing, and interrupt routing all had to match the actual board layout, not the reference design. Reference designs are a starting point, never the final answer; every board spin changes something, and the device tree must change with it.
Second, the bring-up validated a principle we apply to every peripheral: test at the lowest layer first. Before the CanMain module ever parsed a frame, we verified raw CAN traffic with simple send and receive tools against a known-good node on the bus. Only when the hardware path was proven did we move up the stack. Layers of abstraction are wonderful for productivity and terrible for debugging, so we peel them off deliberately during bring-up.
Acquisition is only half the job. Raw CAN frames are meaningless until they are parsed into structured data, and for this project the protocol in question was BMS_CAN — the battery management system protocol. Parsing CAN protocols on Linux is a userspace discipline as much as a kernel one: the kernel delivers frames reliably, and userspace turns them into measurements, stores them, and exposes them to the rest of the system.
The practical lesson from the BMS_CAN work is that protocol parsing code should be developed and tested off-target first, against captured frame logs, before it ever runs on the board. CAN traffic is timing-sensitive and hard to reproduce on demand; a recorded log of real bus traffic is worth more than a week of live testing. We captured, replayed, and validated the parsing logic on the bench, so that when it ran on the i.MX6, the only remaining variable was the acquisition path itself — which we had already proven.
Storage deserves a mention too. Multi-channel acquisition generates a continuous stream of data, and on an embedded target the storage path — filesystem choice, write buffering, wear leveling on flash — is part of the BSP, not an afterthought. A system that acquires perfectly and then corrupts its filesystem under sustained write load has not been brought up; it has been demoed.
The smart home router project faced a fundamentally different question. The challenge was not a single peripheral: home networks and smart home devices were poorly integrated, and users were juggling multiple systems and apps to control their homes. The product needed to be a smart home control center — router, Zigbee coordinator, Bluetooth gateway, and cloud-connected hub in one box.
We built it on OpenWrt 19.07, running on an MT7621 platform with 512MB of RAM and dual-band WiFi, integrating Zigbee 3.0, MQTT, and CoAP, with unified device management and scene control including home mode and sleep mode, plus cloud connectivity through Alibaba Cloud IoT and AWS IoT. You can read the full story in our smart home router case study.
The key decision was the distribution itself. For a device whose core function is routing, WiFi management, and network services, building a custom minimal distro would have meant re-implementing — and then maintaining — a huge surface of networking functionality: firewall rules, DHCP and DNS services, wireless configuration, and the web of small utilities that make a router actually work. OpenWrt ships all of that, tested by a large community, with a package system that makes adding MQTT brokers, CoAP stacks, and Zigbee coordinators a matter of integration rather than invention.
The build-vs-adopt decision for a distro should be driven by your product's differentiating value. If your differentiation is the networking stack, build it. If your differentiation is what runs on top of the network — as it was here — adopt the stack and spend your engineering budget on the differentiation.
That said, adopting OpenWrt is not the same as flashing a stock image. The bring-up work shifts rather than disappears. We had to validate the MT7621 target support, confirm the dual-band WiFi radios initialized correctly with the board's RF design, integrate the Zigbee 3.0 radio and Bluetooth alongside the WiFi without interference or resource conflicts, and make sure the MQTT and CoAP messaging paths performed under the load of a whole home's devices. Scene control — home mode, sleep mode — sits in userspace, but it depends on every radio and protocol below it being solid. OpenWrt gave us the foundation; the integration and validation were still ours.
The general rule we use with clients: choose a custom distro (Yocto, Buildroot) when you need tight control over the root filesystem, long-term reproducibility, or a minimal footprint for a single-purpose device — like the i.MX6 CAN system. Choose OpenWrt when the product is network-centric and the value of its mature networking stack outweighs the footprint cost. Both are linux embedded engineering; they just allocate the effort differently.
Once the kernel and drivers are solid, the next decision is what the userspace is written in. The smart home router used all three of C, Lua, and Python, which makes it a useful example of how to think about the split.
C is for the hot path and the system boundary: anything timing-sensitive, anything that talks directly to hardware or kernel interfaces, anything that must run with minimal memory overhead. On the router, the low-level integration points — protocol handling close to the radios, performance-critical message routing — belong in C. The cost is development speed and the unforgiving nature of memory bugs on a device you cannot easily attach a debugger to.
Lua earns its place on OpenWrt specifically: it is the language of the platform's own configuration and web interface ecosystem, it starts fast, and it uses little memory — real considerations on a 512MB system running routing, WiFi, Zigbee, MQTT, and application logic simultaneously. Glue logic, configuration-driven behavior, and scene definitions are natural Lua territory.
Python is for development speed and ecosystem: cloud SDK integration, complex business logic, data processing, and anything where the available libraries (including the Alibaba Cloud IoT and AWS IoT SDKs) outweigh the runtime cost. The trade-off is memory footprint and startup time, which is why Python belongs in the application layer, behind the C and Lua components that keep the system responsive.
The principle is not about language loyalty. It is about matching the language to the layer: C where the system meets the hardware, Lua where the platform expects it and resources are tight, Python where velocity and libraries matter most. Getting this split right early prevents the two classic failure modes — everything in C, which grinds feature development to a halt, or everything in Python, which collapses under resource pressure on the target.
Every board we bring up goes through the same sequence. It is not glamorous, but it is the difference between a BSP that works in the lab and one that survives production.
BSP bring-up rewards a specific temperament: methodical, skeptical of assumptions, and respectful of the hardware. The serial console comes before the kernel config. The raw frame comes before the parsed protocol. The distro decision comes before the application code. None of this is exciting, and all of it is what separates a product that ships from a demo that almost worked.
The i.MX6 CAN acquisition system and the OpenWrt smart home router look like very different projects — one a bare-board driver bring-up for automotive and industrial control, the other a full networked product built on a mature distribution. But the discipline underneath is the same: prove each layer before building on it, choose your battles (and your distro) deliberately, and validate under real load, not demo conditions.
If you are starting a new board and want that discipline applied from day one, take a look at our Linux BSP development services — or browse the i.MX6 CAN bus system and smart home router case studies to see what the finished work looks like.
Contact us for customized solutions and quotes