Linux SBCs in Real Embedded Products: What I Would Review Before Committing

Linux SBCs are easy to like during early development. You can put one on the bench, flash an image, connect Ethernet, log in over SSH, and have a basic application running the same day. For a prototype, that is a huge advantage. It lets the software team move, lets the customer see something real, and gives the hardware team a reference point before the final electronics are fully defined.

The hard part comes later. A board that is convenient for a prototype is not automatically a good production platform. Once the same board has to live inside a cabinet, kiosk, gateway, controller, access terminal, medical cart, or industrial display, the questions change. The discussion becomes less about whether Linux boots and more about whether the whole system can run for years without creating service problems.

This is how I usually look at a Linux SBC when the project is moving from “it works on my desk” toward “we need to ship this as a product.”

The First Question Is Not CPU Performance

Processor choice matters, but it is rarely the only thing that decides whether a Linux SBC is suitable. In many embedded products, the CPU spends most of its time waiting for I/O, network traffic, serial packets, user input, or a cloud response. A faster processor may not fix the real issues.

I would rather start with the product environment:

• Where is the device installed?
• What input voltage is available?
• Does the product need a screen or run headless?
• Which ports connect to users or field wiring?
• Is the enclosure sealed?
• Will the device be reachable after installation?
• How long does the same hardware need to stay available?
• Who will debug a failed unit in the field?

These questions are less exciting than comparing benchmark charts, but they are closer to the problems that show up after deployment. A Linux SBC selected only by CPU and memory can still fail because the power input is wrong, the storage wears out, the kernel is poorly supported, or the connector layout does not fit the enclosure.

Treat The SBC As Part Of A System

A Linux SBC is not the product by itself. It is one part of the product system. Around it there may be a power board, display, touch panel, enclosure, cable harness, sensor interface, antenna, battery, relay board, or custom carrier board.

That surrounding system changes the requirements. For example, a standard development board may expose several USB ports and HDMI, but the product may need isolated RS485, a 24 V input, a locking connector, a SIM slot, a watchdog line, and a display interface that fits a specific panel. In that case, the standard SBC is useful for early software work, but probably not enough for production hardware.

A simple review table helps keep the discussion grounded.

Review Area	What I Check	Why It Matters
Power input	Nominal voltage, dips, surges, reverse polarity, current peaks	Field power is often less stable than lab power
Interfaces	Ethernet, RS485, CAN, USB, GPIO, display, camera, audio	Missing or weak interface planning causes late hardware changes
BSP status	Kernel version, bootloader, device tree, driver maturity	A board that boots is not always production-ready
Storage	eMMC, SD, NVMe, write volume, log rotation	Continuous writes can shorten product life
Thermal	Final enclosure, ambient temperature, radio modules, CPU load	Open-bench testing hides enclosure problems
Updates	Image signing, rollback, recovery, remote access	Failed updates are expensive when devices are deployed
Manufacturing	Flashing, serial numbers, MAC addresses, functional tests	Manual test steps do not scale well

This table is not meant to be a formal specification. It is a way to expose risk early, before the team has already committed to a board and enclosure.

Linux Gives You A Lot, But It Also Expects Discipline

The main reason Linux works well for embedded products is that it comes with a serious set of system capabilities. Networking is strong. File systems are mature. There are good tools for logging, process supervision, remote access, security, package management, and debugging. Most engineering teams can build applications faster on Linux than on a bare-metal or RTOS platform when the product needs rich connectivity.

For a gateway, Linux can run MQTT, Modbus, local buffering, VPN, firewall rules, and diagnostics. For a smart display, it can run Qt, a browser engine, camera preview, audio, and touch input. For an industrial device, it can bridge serial equipment to Ethernet and keep local logs for service teams.

The downside is that Linux systems can become messy if nobody owns the system image. Debug services remain enabled. Logs grow without limits. Temporary files fill the filesystem. SSH credentials are reused. Kernel changes are made once and never documented. These are not Linux problems; they are product engineering problems.

A production Linux SBC needs a controlled image, a repeatable build process, and a clear policy for services, users, logs, updates, and recovery.

BSP Quality Is More Important Than A Pretty Spec Sheet

I do not trust a Linux SBC only because the datasheet lists the right interfaces. I want to know how well those interfaces work in the BSP.

A practical BSP review includes:

- Bootloader behavior after failed boots
- Device tree accuracy
- Ethernet stability after repeated reconnects
- Wi-Fi or cellular recovery after network loss
- Watchdog behavior when the main service hangs
- USB device handling during hot plug
- Display and touch stability after reboots
- GPIO and serial port mapping
- Storage mount behavior after power loss
- Kernel update plan

The difference between a demo BSP and a product BSP can be large. A demo image often proves that hardware can work. A product BSP proves that hardware keeps working under bad conditions.

For example, it is not enough that the cellular module appears as a device once. The design should check whether it recovers after a carrier drop, whether a hardware reset line exists, whether SIM detection is reliable, and whether the modem can be power-cycled by software when it gets stuck.

The same thinking applies to display panels, cameras, USB peripherals, and industrial I/O.

Storage Problems Usually Arrive Late

Storage is easy to ignore until the product has been running for a while. During development, the team may use an SD card because it is convenient. Logs are verbose because debugging is still active. Databases are written frequently because nobody has tuned the flush behavior. Everything seems fine for a few weeks.

A deployed product is different. It may run continuously for years. If it loses network connectivity, it may buffer data locally. If logs are not rotated, storage can fill. If a database writes too aggressively, flash wear becomes a real issue. If power is cut during writes, filesystem corruption may appear.

For Linux SBC products, I would review:

- Whether SD card use is acceptable for the target environment
- Whether eMMC endurance is enough for expected write volume
- Which directories are writable
- Whether logs have size limits
- Whether debug logging is disabled in production
- Whether temporary files are cleaned up
- Whether application data is separated from the root filesystem
- How the system behaves when storage is nearly full

These details are not glamorous, but they are the difference between a product that runs quietly and a product that starts failing after months in the field.

Power Loss Is A Normal Event

Embedded products should not treat power loss as an exceptional lab accident. In many installations, power will be cut. Someone will unplug the device. A breaker will trip. A vehicle battery will dip. A technician will turn off a cabinet. The product should recover.

A Linux SBC should be tested under repeated power cycling. It should also be tested with power cuts during boot, during logging, during configuration changes, and during software updates. If the board requires a clean shutdown every time, the product design needs to account for that.

A few practical checks:

1. Boot the device 100 times and record failures
2. Remove power while the application is writing logs
3. Remove power during network reconnection
4. Remove power during an update and verify recovery
5. Check whether the watchdog restores service after a forced hang
6. Confirm that the filesystem remains mountable
7. Confirm that configuration files are not corrupted

It is better to find these problems on the bench than after hundreds of units are installed.

Thermal Testing Needs The Real Mechanical Design

A Linux SBC can behave very differently inside a product enclosure. On an open bench, the board has free airflow. In a product, it may be inside plastic, near a display backlight, beside a power supply, or sealed in a metal box. The ambient temperature may also be much higher than the office.

Thermal testing should use a realistic workload. If the product normally uses Ethernet, Wi-Fi, a display, USB devices, and local data processing, those functions should be active during the test. If a cellular module transmits periodically, include that too. Radio modules and power regulators can add more heat than expected.

It is also worth checking performance after throttling. Some products can tolerate reduced CPU speed. Others cannot. If the device must process data in near real time, thermal throttling may become a functional problem, not just a temperature issue.

Interface Details Need Written Decisions

Many late-stage problems come from loose interface definitions. A requirement like “support serial port” is not precise enough. RS232, RS485, TTL UART, and CAN are different. So are connector choices, isolation needs, cable lengths, and termination requirements.

A good interface definition should answer practical questions:

• How many ports are needed?
• What electrical standard is used?
• What connector is used?
• Is the port exposed to field wiring?
• Does it need isolation?
• Is termination required?
• What is the maximum cable length?
• How will production test this port?
• Which Linux device name should software use?

The last point matters more than it sounds. If device naming changes between boots, software can attach to the wrong port. For multi-port gateways and controllers, stable naming rules should be part of the BSP or system configuration.

Security Should Start With The Shipping Image

Security does not need to begin with a large architecture document. It can start with the image that leaves the factory.

A production Linux image should not include shared default credentials. SSH should not be open to the world. Debug ports should be controlled. Update packages should be verified. Private keys should not be copied into every device. Logs should not expose customer data or passwords.

For a connected product, I would also document which outbound connections the device makes. Customers often ask this during installation, especially in corporate or industrial networks. If nobody can answer, deployment gets delayed.

Reasonable first steps include:

- Disable unused services
- Remove default passwords
- Use unique device credentials where practical
- Sign software updates
- Limit SSH or remote shell access
- Keep a clear list of open ports
- Record software versions and build IDs
- Provide a way to collect logs without exposing secrets

These are basic steps, but they prevent many avoidable problems.

Manufacturing Test Is Part Of Product Design

A Linux SBC project is not finished when the application runs. It also has to be built, programmed, tested, labeled, and shipped consistently.

Manufacturing test should be considered before the hardware is frozen. The factory may need access to UART, USB, Ethernet, test pads, display, touch, GPIO, or serial ports. If those points are difficult to reach, test time increases. If there is no factory mode in the software, operators may need manual steps. Manual steps create mistakes.

A typical test flow might look like this:

1. Flash bootloader and Linux image
2. Program serial number and MAC address
3. Verify RAM and storage
4. Test Ethernet traffic
5. Test Wi-Fi, Bluetooth, or cellular module
6. Test serial ports, CAN, GPIO, relay, or other field I/O
7. Check display, touch, camera, or audio if used
8. Run watchdog and reboot tests
9. Save test results with the device serial number
10. Lock or disable factory-only access

If the product volume is low, the process can be simple. If the product volume grows, the same test flow should still be repeatable.

Standard Board, Carrier Board, Or Custom SBC

There are three common paths.

A standard Linux SBC is fastest. It is good for early development, demos, pilot runs, and low-volume products where mechanical fit and lifecycle are acceptable.

A custom carrier board is useful when the compute module is acceptable but the product needs different power input, connectors, field interfaces, mounting, or test access. This can keep processor risk lower while still making the hardware product-specific.

A fully custom SBC makes sense when the product needs tight mechanical integration, cost optimization, long lifecycle control, special interfaces, or higher volume. It takes more work up front, but it can remove unused parts and improve production consistency.

The right path depends on volume, schedule, certification, support expectations, and how much control the product needs. Companies such as Avontek often support this middle ground, where a Linux SBC platform has to become a real embedded product rather than just a development board in a box.

Final Review Before Committing

Before committing to a Linux SBC for production, I would want the team to review these items:

• The required interfaces are defined electrically and mechanically.
• The BSP has been tested beyond first boot.
• The final enclosure has been used for thermal testing.
• The power input and reset behavior match the installation environment.
• Storage write patterns are known.
• The software image is controlled and repeatable.
• Remote update failure has a recovery plan.
• Security basics are applied before shipment.
• Manufacturing test is practical and traceable.
• Long-term board and component availability has been checked.

None of these checks are difficult by themselves. The discipline is doing them early enough.

Closing Notes

A Linux SBC can be an excellent base for an embedded product. It gives teams a capable operating system, strong connectivity, familiar development tools, and a faster path to application work. But the board should be treated as the beginning of product engineering, not the end.

The products that hold up well in the field usually have less mystery around them. The team knows how they boot, how they fail, how they recover, how they are updated, how they are tested, and how they are serviced. That is more valuable than a slightly faster processor or a longer feature list.

For embedded products, a Linux SBC is successful when it disappears into the product and just keeps doing its job.