Designing a custom single-board computer around an ARM system-on-chip looks straightforward on a block diagram. Select a processor, connect some DDR memory, add storage and Ethernet, and send the design to a PCB manufacturer. The real process is less tidy. A modern ARM SoC may expose hundreds of pins, several power domains, high-speed memory buses, multiple boot sources, and interfaces with strict layout requirements. Small mistakes can leave a board that powers up normally but never executes its first instruction.

This article describes the main engineering decisions involved in developing a custom ARM SoC SBC. It is written from the perspective of building a practical Linux-capable board rather than an evaluation platform with every possible connector. The intended system might be an industrial controller, network appliance, robotics computer, smart display, or embedded data-collection unit.

Start with the Product, Not the Processor

One of the easiest mistakes is choosing the SoC first because it has attractive specifications. A better starting point is a short list of product requirements: operating temperature, expected lifetime, power budget, software workload, production volume, physical size, and required interfaces. These constraints usually reduce the processor list quickly.

A quad-core Cortex-A55 device may appear more capable than an older Cortex-A7 part, but CPU performance is only one variable. The newer device may require LPDDR4, a more expensive PCB stack-up, a vendor-controlled bootloader, or a power-management IC with long lead times. If the application only collects sensor data and forwards it over Ethernet, the faster processor can add cost and development risk without improving the final product.

Software support deserves the same weight as hardware features. Before selecting a device, I normally check whether the vendor maintains U-Boot and Linux trees, whether important drivers are upstream, and whether documentation is available without a restrictive agreement. A powerful SoC with incomplete documentation can consume months of engineering time.

Typical Hardware Architecture

A minimal Linux SBC contains more than the SoC itself. The processor needs external memory, nonvolatile boot storage, regulated power rails, clocks, reset control, and at least one debug interface. Networking, USB, display, audio, and expansion connectors are added according to the product requirements.

Schematic Design and Pin Multiplexing

ARM SoCs often reuse physical pins for several functions. A pin may operate as GPIO, UART transmit, SPI clock, or an Ethernet signal depending on its configuration. Pin multiplexing must therefore be planned before the schematic becomes crowded. It helps to maintain a spreadsheet containing every used ball, its selected function, voltage domain, pull resistor, and boot-time state.

Boot-configuration pins need special attention. Their levels are sampled during reset and may select the boot device, oscillator mode, or test function. Reusing one of these pins as a peripheral signal can work, but the external circuit must not override the required level while reset is active. I prefer to make the boot resistors clearly visible in one schematic section instead of scattering them across peripheral pages.

Unused pins should be handled according to the datasheet rather than by habit. Some inputs may be left open because they include internal biasing. Others require an external pull-up or pull-down. Unused power pins, analog references, and exposed package pads are rarely optional, even if their names make them look unrelated to the selected interfaces.

DDR Memory Is Usually the Hardest Interface

External DDR memory is where many first custom boards fail. The bus operates on both clock edges and has little timing margin. Trace length, impedance, reference-plane continuity, via count, and termination all affect reliability. A board may boot at room temperature yet fail after warming up or when built with memory from another production lot.

The safest approach is to follow the SoC vendors reference layout closely. Use the same memory topology, similar component placement, and the recommended PCB stack-up. The address and command group, clock pair, and each byte lane have different matching rules. Applying one arbitrary length tolerance to the entire bus is not sufficient.

Memory placement should happen early in PCB layout. Put the DDR device close to the SoC, reserve uninterrupted reference planes, and avoid routing unrelated high-speed signals through the area. If the processor supports several memory types, choose the one for which the vendor provides tested initialization parameters and layout examples.

DDR initialization is also a software problem. The bootloader must configure the memory controller and PHY before normal code can use external RAM. Record the exact memory part number, geometry, speed grade, and topology in the hardware documentation. “One gigabyte DDR4” is not enough information when someone has to debug initialization a year later.

Power Architecture and Sequencing

A Linux-class SoC commonly requires separate rails for the CPU core, internal logic, DDR, analog circuits, and I/O banks. Some rails must rise in a defined order, while others have ramp-time or discharge requirements. A PMIC designed for the processor family can reduce component count, but it still needs careful configuration.

Average current is not the only sizing parameter. CPU load changes can create fast current transients, especially when several cores leave an idle state. The regulator and decoupling network must keep the core voltage inside its allowed range during these events. Place small ceramic capacitors close to power balls and use larger capacitors near the regulator or SoC power region.

Provide measurement points for the major rails. Tiny test pads cost almost nothing and save considerable time during bring-up. If possible, include options to isolate major loads or measure current using a removable zero-ohm resistor. A board reporting nothing on the UART is much easier to diagnose when each rail can be checked independently.

Clocks, Reset, and the Debug UART

The system oscillator looks simple, but poor component selection or layout can prevent startup. Follow the crystal manufacturers load-capacitance guidance and keep the traces short. Do not place fast digital signals under the crystal network. Where practical, add a footprint that allows an external oscillator to be fitted during debugging.

Reset should remain asserted until critical power rails and clocks are stable. The PMIC may provide a power-good output, or a dedicated supervisor can generate reset. Manual reset is worth adding even on a compact board. It avoids repeatedly disconnecting power during early software work.

A boot UART is the single most useful interface on a new SBC. Route it to a clearly marked header and document its voltage. Most SoC UARTs use 1.8 V or 3.3 V logic and must never be connected directly to an RS-232 port. The first successful boot message is often the point when a pile of components finally begins to feel like a computer.

Boot Chain and Software Preparation

The boot process normally starts in immutable code inside the SoC. This boot ROM reads configuration pins, selects a source, and loads a small first-stage program. That program initializes DDR and loads U-Boot or another second-stage loader. U-Boot then loads the Linux kernel, device tree, and root filesystem.

It is worth proving this chain on the vendors evaluation board before the custom PCB arrives. Build the bootloader and kernel from source, confirm the flashing method, and save known-good binaries. During custom-board bring-up, software uncertainty should be reduced as much as possible.

A typical U-Boot build might look like this:

 export CROSS_COMPILE=aarch64-linux-gnu- make custom_sbc_defconfig make -j8

The device tree describes the hardware Linux cannot discover automatically. It defines memory, regulators, GPIO assignments, buses, clocks, and connected devices. Copying the evaluation-board device tree and changing only the model name is rarely enough. Disabled interfaces, different PMIC connections, and changed pin assignments must all be represented accurately.

PCB Stack-Up and High-Speed Layout

A four-layer PCB may be adequate for a modest SoC with DDR3 and limited interfaces, but six or eight layers usually make routing and power distribution more manageable. The correct choice depends on package pitch, memory speed, interface count, and compliance requirements. Saving money by removing layers can increase layout time and create a board that is difficult to manufacture consistently.

High-speed traces need continuous reference planes. A signal crossing a split in its reference plane forces return current to take a longer path, increasing noise and radiation. Differential pairs such as USB, PCIe, and Ethernet should use the impedance specified by the relevant standard. Their routing constraints should be calculated from the actual stack-up supplied by the PCB manufacturer.

Connectors also affect signal quality. USB data lines should not wander across the board before reaching the connector, and ESD protection should sit near the point of entry. Ethernet magnetics and PHY termination components should follow the PHY vendors recommendations. These details are easy to postpone and awkward to repair later.

Bring-Up in Controlled Steps

Do not populate every optional component on the first prototypes unless assembly cost makes it unavoidable. Begin with the power system, SoC, memory, boot storage, clock, reset, and debug UART. Check the assembled board visually before applying power, then use a current-limited supply.

I usually verify the rails, reset timing, and oscillator before expecting any software output. If the SoC supports a USB recovery or serial-download mode, test it before attempting normal storage boot. Recovery mode can confirm that the processor is alive even when DDR or flash initialization is still broken.

Once U-Boot runs, test memory over a wide address range before enabling complex peripherals. Then bring up storage, Ethernet, USB, and the remaining interfaces one at a time. Keep a log of measurements, register values, board modifications, and software revisions. Without a log, teams tend to repeat experiments or forget which change actually fixed the problem.

Production Concerns

A working prototype is not yet a production design. Component availability, alternate parts, assembly tolerances, thermal behavior, electromagnetic emissions, and programming procedures still need attention. Run sustained CPU, memory, storage, and network loads while monitoring temperature and supply stability. Test cold starts, repeated resets, and unexpected power removal.

For field updates, use a partition scheme that can recover from an interrupted installation. An A/B root filesystem or a small recovery image is usually worth the storage overhead. If secure boot is required, plan key provisioning early; it affects factory tools, repair procedures, and ownership of signing credentials.

Finally, preserve the engineering data. Archive schematics, PCB sources, fabrication outputs, bills of materials, bootloader configurations, device trees, programming images, and bring-up notes together. Custom SBC development involves many small decisions that are obvious during the project and almost impossible to reconstruct later.

Conclusion

Building a custom ARM SoC SBC is a multidisciplinary job. Processor selection, power integrity, DDR routing, boot software, Linux configuration, thermal design, and manufacturing all interact. The best results usually come from keeping the first revision conservative: follow the reference design where it matters, expose useful debug points, and avoid adding interfaces without a clear product requirement.

A first revision may still need wire modifications or component changes. That is normal. The real measure of a good design process is not whether the board is perfect immediately, but whether failures can be observed, understood, and corrected without guesswork. A board designed for diagnosis is far more valuable than one designed only to look complete on a schematic.