When an embedded product uses an Android or Linux single board computer, the board itself is only one part of the project. A product-ready SBC also needs stable BSP support, reliable driver integration, repeatable firmware flashing, and a functional testing process that can be used during manufacturing.
Many embedded projects look successful during early bring-up. The board powers on, the operating system boots, and the application runs on the bench. But production requirements are different. A board must boot consistently, support all required interfaces, survive repeated power cycles, pass factory testing, and remain maintainable after deployment.
This is why BSP support and functional testing should be considered early, not after the hardware design is already finished.
What BSP Means in an SBC Project
BSP stands for Board Support Package. In an embedded SBC project, the BSP connects the hardware design to the operating system.
For Android and Linux boards, BSP work may include:
- Bootloader configuration
- Kernel adaptation
- Device tree changes
- Driver integration
- Display and touch bring-up
- Wi-Fi, Bluetooth, Ethernet, USB, and audio testing
- GPIO and peripheral mapping
- System image generation
- Recovery or factory reset behavior
- Firmware flashing process
- Update and maintenance planning
A standard development board usually comes with a vendor BSP. That BSP may be enough for evaluation, but a custom SBC often changes display panels, touch controllers, wireless modules, connectors, power design, and peripheral layout. Each change may require BSP adjustment.
Why BSP Quality Matters
A product can fail in the field even if the hardware design is technically correct. Many issues happen because hardware and software were not validated together.
For example:
- A display panel may need different timing parameters.
- A touch controller may require driver changes or coordinate mapping.
- A Wi-Fi module may need firmware, driver, and antenna validation.
- Ethernet may work during testing but fail to reconnect after cable loss.
- USB devices may behave differently after suspend or reboot.
- GPIO mapping may not match the application team’s expectation.
- Storage may become unstable after repeated power interruption.
These problems are not always visible in a simple boot test. They require structured validation.
Good BSP support reduces uncertainty because the operating system is configured for the actual board and the actual product requirements.
Android BSP Considerations
Android SBC projects usually involve user-facing products. Examples include HMI panels, smart control panels, access control terminals, retail devices, commercial display equipment, and smart connected terminals.
In these products, the BSP may need to support:
- Display resolution and rotation
- Touch panel calibration
- Backlight control
- Audio input and output
- Camera or scanner modules
- Wi-Fi and Bluetooth stability
- USB peripheral behavior
- Application permissions
- Kiosk mode or launcher customization
- Boot animation
- OTA update behavior
- Factory reset and recovery
Android gives product teams a familiar application platform, but it also adds system-level requirements. The final device should not feel like a generic development board. It should boot into the correct application, hide unnecessary system behavior, handle peripherals reliably, and support the intended user experience.
Linux BSP Considerations
Linux SBC projects often focus on gateways, controllers, audio devices, industrial terminals, and headless embedded systems. Linux is usually selected when engineers need more control over services, networking, drivers, and system maintenance.
A Linux BSP may need to support:
- Bootloader and kernel configuration
- Device tree customization
- Network service setup
- Watchdog configuration
- Filesystem layout
- Logging strategy
- Remote update process
- Driver integration for industrial interfaces
- Recovery after power failure
- Long-term kernel and package maintenance
Linux gives engineers flexibility, but that flexibility requires clear system planning. A gateway or controller may run for months or years without direct user interaction, so stability and recovery behavior matter more than appearance.
Bring-Up Should Be Systematic
Board bring-up should follow a clear order. Random testing can miss important issues.
A typical bring-up flow may include:
- Power rail validation
- Clock and reset checks
- Bootloader startup
- DDR initialization
- Storage access
- Kernel boot logs
- Display output
- Touch input
- USB, Ethernet, Wi-Fi, Bluetooth, and audio
- GPIO and external peripherals
- Application-level testing
- Reboot, suspend, update, and recovery testing
This process helps isolate problems. If the board has unstable power sequencing, it should be found before application debugging begins. If the display interface is not stable, it should be solved before user interface testing.
Functional Testing in Manufacturing
Functional testing is the bridge between engineering and production. A prototype can be tested manually by engineers, but production boards need a repeatable test process.
A useful functional test process may verify:
- Power input
- Boot behavior
- Memory
- Storage
- Display
- Touch panel
- Ethernet
- Wi-Fi
- Bluetooth
- USB ports
- Audio
- GPIO
- RS485, CAN, UART, I2C, SPI, or other interfaces
- MAC address or serial number programming
- Firmware version
- Final system image
The goal is not only to detect failed boards. It is also to make production quality consistent. If every board goes through the same test process, later troubleshooting becomes easier.
Test Fixtures and Factory Firmware
For higher-volume projects, a test fixture can improve efficiency. The fixture may connect to test points, ports, buttons, display output, or external interfaces. It allows factory operators to test boards quickly and consistently.
Some projects also use factory firmware or a dedicated test image. This image may include test scripts, interface checks, serial number programming, and pass/fail reporting. After testing, the final production image can be flashed.
This approach is especially useful when the product has many interfaces or when manual testing would be slow and inconsistent.
Common Mistakes to Avoid
Several issues appear repeatedly in SBC projects:
- Treating BSP work as a small task after hardware design
- Selecting displays or wireless modules without checking driver support
- Leaving functional testing until pilot production
- Testing only the main application and not the system behavior
- Ignoring reboot, power loss, suspend, and recovery cases
- Using a development image as if it were a production image
- Not documenting GPIO, connector, and interface mapping
- Not planning firmware flashing and version control
These mistakes can delay production even when the hardware design is mostly correct.
Choosing an SBC Development Partner
For custom Android and Linux SBC projects, it is useful to work with a team that understands hardware, BSP, and manufacturing together.
A practical partner should be able to support:
- Embedded hardware development
- Android and Linux BSP adaptation
- Display and touch integration
- I/O and wireless module integration
- Production image preparation
- Functional testing
- Manufacturing coordination
- Lifecycle supply planning
Avontek develops and manufactures Android and Linux embedded SBCs for industrial, commercial, and custom hardware projects. Its work includes hardware development, BSP support, display and touch integration, I/O customization, wireless module integration, manufacturing, and functional testing.
Conclusion
A production-ready SBC is not only a board that boots. It is a board with stable BSP support, tested interfaces, reliable firmware flashing, and a repeatable manufacturing test process.
For embedded product teams, BSP and functional testing should be planned early. When hardware, software, and manufacturing are validated together, the project has a better chance of moving from prototype to production without unnecessary rework.
