Board intake
01Read the schematic, vendor drop, boot logs and product constraints before changing the tree.
PMIC and railspanel and touchstorage and flashing
Platforms
Android and Linux bring-up for real hardware
We take silicon vendor BSPs, evaluation-kit assumptions and custom carrier-board changes, then turn them into booting, maintainable platform images for products that have to ship.
Boards we support
- Rockchip
- RK3588 / RK3576 / RK3568, etc.
- NXP
- i.MX 8M / i.MX 93 / i.MX 95, etc.
- NVIDIA Jetson
- Orin / Xavier / Nano, etc.
- Qualcomm
- QCS / QCM / SA, etc.
- TI
- AM62x / AM335x / TDA4VM, etc.
- Custom boards, etc.
- SoMs / carrier boards, etc.
- silicon vendors
- 12+
- named parts
- 87+
- production stacks
- AOSP + Yocto
Mobile, industrial, media and automotive SoC families.
SoCs, modules, EVKs and single-board computers in our support map.
Android, embedded Linux and vendor BSPs carried into products.
Bring-up surface
The work between an EVK booting and your product booting
Most schedule risk sits in the board-specific details: power sequencing, peripheral dependencies, vendor forks and the update path that has to survive future releases.
Boot chain
02Get the SoC from mask ROM to a repeatable boot path that matches the product security model.
U-Boot / LKsecure bootfactory images
Kernel bring-up
03Move the reference board files onto your carrier and stabilize the peripherals that make the device real.
device treedriversclocks and pinmux
Platform release
04Turn the bring-up into something your product team can flash, test, update and keep shipping.
HALs and SELinuxOTA pathvalidation notes
What we usually touch
The exact stack changes by vendor, but the failure points tend to rhyme. We keep the board support work connected to the product image instead of treating each layer as a separate handoff.
- Bootloader, boot media and flashing tools
- Kernel config, device tree, pinmux, clocks and regulators
- Display, touch, camera, audio, wireless, USB, PCIe and sensors
- Android HALs, SELinux policy, init services and vendor interface cleanup
- Yocto layers, board support packages and long-term kernel maintenance
- Factory images, OTA strategy, diagnostics and regression test notes
Board map
Parts teams ask about by name
The current support map covers 10 board families and 87+ named SoCs, modules and development kits. Custom carrier boards are expected, not an exception.
Rockchip
Android & LinuxRK3588RK3588SRK3576RK3568RK3566etc.
Radxa ROCK 5BRadxa ROCK 4Radxa CM3Radxa CM5Firefly ROC-RK3588Orange Pi 5etc.
Our most requested family. Strong price-to-performance for signage, HMI and edge AI — and vendor trees rough enough that custom boards always need work.
NXP
Android & Linuxi.MX 8M Plusi.MX 8M Minii.MX 8M Nanoi.MX 8QuadMaxi.MX 93i.MX 95etc.
Variscite DART-MX8MVariscite VAR-SOM-MX8Toradex Verdin iMX8MphyCORE-i.MX 8MCompulab UCM-iMX8Metc.
Long-lifecycle industrial and medical work. Android and Yocto on the same module, plus NPU enablement on the 8M Plus.
Qualcomm
Android / AOSPQCS6490QCM6490QCS8550SM8550SA8155PSA8295Petc.
Thundercomm TurboXQualcomm RB5RB3 Gen 2Lantronix Open-Qetc.
Mobile-class performance for handhelds and automotive cockpits. Vendor BSP integration and CRD-to-custom-board porting.
NVIDIA
Embedded LinuxJetson Orin NanoJetson Orin NXAGX OrinXavier NXetc.
Jetson devkitsAuvidea carriersConnect Tech carriersSeeed reComputeretc.
Robotics and edge AI, where the GPU and camera pipeline are the product. Jetson Linux (L4T) rather than Android — we say so rather than overpromise.
Texas Instruments
Android & LinuxAM62xAM62AAM335xTDA4VMSitaraJacintoetc.
BeagleBone BlackBeaglePlayBeagleBone AI-64TI SK-AM62etc.
Industrial control and automotive, often paired with real-time cores. Linux is the norm; Android is viable on AM62-class parts.
Raspberry Pi
Android & LinuxBCM2711BCM2712etc.
Compute Module 4Compute Module 5Raspberry Pi 4Raspberry Pi 5etc.
Excellent for prototypes and low-volume products. Android runs via community AOSP ports rather than official support, so GMS certification is not available — worth knowing before you design it in.
STMicroelectronics
Embedded LinuxSTM32MP1STM32MP157STM32MP2STM32MP25etc.
STM32MP157F-DK2Octavo OSD32MP1custom carriersetc.
Cortex-A7 plus Cortex-M4 for deterministic control. OpenSTLinux and Yocto — Android is not a realistic fit on this class of part, and we will tell you that up front.
Amlogic
Android / AOSPS905X4S905X5S922XA311Detc.
Khadas VIM3Khadas VIM4ODROID-N2+reference STB designsetc.
Android TV and set-top boxes, including Google TV requirements and operator launcher variants.
Allwinner
Android & LinuxA133A64T507H616H618etc.
Olimex SOMBanana PiOrange Picustom tabletsetc.
Cost-sensitive consumer and industrial devices where BOM cost drives the design.
MediaTek
Android & LinuxGenio 700Genio 1200MT8395MT8195etc.
Genio 1200-EVKGenio 700-EVKPumpkin boardsetc.
Genio platform bring-up and MediaTek BSP customisation for non-reference hardware.
Silicon vendors
Where the BSP comes from
Each vendor has its own release cadence, kernel fork and set of sharp edges. Familiarity with those details saves months when the reference design stops matching your hardware.
Qualcomm
01Snapdragon mobile, QCS / QCM IoT, SA automotive, etc.
Vendor BSP integration, CRD-to-custom-board porting, and the Qualcomm release cadence.
MediaTek
02Genio IoT, Dimensity, MT8xxx, etc.
Genio platform bring-up and MediaTek BSP customisation for non-reference hardware.
NXP
03i.MX 8, i.MX 8M Plus, i.MX 93 / 95, etc.
Android and Yocto on i.MX, including the vendor kernel and NPU enablement.
Rockchip
04RK3588 / RK3576 / RK3568, etc.
Popular for signage, HMI and edge AI. Strong price-to-performance, rough vendor trees.
Texas Instruments
05AM62, AM62A, Sitara, Jacinto, etc.
Industrial and automotive targets, frequently paired with real-time cores.
Amlogic
06S9xx series, etc.
Android TV and set-top box platforms, including Google TV requirements.
Renesas
07R-Car series, etc.
Automotive cockpit and gateway programmes with functional safety expectations.
NVIDIA
08Jetson Orin, Tegra, etc.
Edge AI and robotics targets where the GPU stack is the point.
Samsung
09Exynos, etc.
Mobile and wearable platforms on the Exynos vendor stack.
Allwinner
10A-series, T-series, etc.
Cost-sensitive consumer and industrial devices.
Intel
11x86 Android, Celadon, etc.
x86 Android targets for kiosk, retail and virtualised deployments.
Broadcom
12Connectivity and STB SoCs, etc.
Wi-Fi and Bluetooth module integration across many of the platforms above.
Working on something not listed? The bring-up process is the same — ask us.
Device classes
What we build them into
The stack changes shape depending on what the device has to do. These are the categories we see most.
Automotive
IVI head units, instrument clusters, rear-seat entertainment and telematics gateways, where boot deadlines and vehicle bus integration drive the architecture.
IVI head unitDigital clusterTelematics unitRear-seat display
Industrial & medical
Rugged handhelds, HMIs and instrument controllers that need long support windows, deterministic behaviour and a documented security posture.
Rugged handheldMachine HMIDiagnostic instrumentControl panel
Retail & payments
Point-of-sale terminals, payment devices and self-service kiosks where the platform must be locked down and certifiable.
POS terminalPayment deviceSelf-service kioskDigital signage
Consumer & media
Set-top boxes, streaming devices, tablets and smart displays, typically with GMS or Google TV certification in scope.
Android TV boxSmart displayTabletStreaming stick
Robotics & edge AI
Platforms where camera pipelines, accelerators and real-time control matter more than the application framework.
Service robotDrone payloadEdge AI gatewaySmart camera
Connectivity & IoT
Gateways and headless devices, often on embedded Linux rather than Android, with fleet update requirements from day one.
IoT gatewayRouter / CPESensor hubAsset tracker
Reality check
Three things that matter before the board spins
Reference board to custom board
Vendor BSPs are written for the vendor's evaluation kit. The moment your schematic diverges — a different PMIC, a new panel, a relocated bus — the reference tree stops being correct. Closing that gap is the work.
Vendor trees are a starting point
Vendor kernels carry out-of-tree patches, stale forks and code that never expected your peripheral set. We keep what is useful, rebase what is not, and document what we carried and why.
Upgradability is a design decision
Whether a board can take the next Android release is decided during bring-up, in how cleanly the vendor interface is separated. We build for the upgrade you have not scheduled yet.