Embedded Linux BSP and STM32 firmware development

Obeita helps equipment manufacturers bring up embedded boards, adapt firmware and resolve faults that block product delivery. Start with a defined development task or a reproducible problem. We connect software changes to the board, interfaces and physical tests needed to verify the agreed behavior.

Embedded Linux, BSP, drivers and U-Boot

Scope board bring-up from the boot path through peripherals and application startup. Depending on the board and available sources, work can include U-Boot adaptation, device-tree changes, driver integration, Buildroot configuration and image deployment. Android BSP adaptation is reviewed separately against its vendor platform and image.

For boot or stability problems, we examine supply conditions, serial logs, startup and DDR behavior, electrical levels, drivers and application interactions. Changes are tied to a defined board revision and software build, with reproduction steps and excluded causes recorded.

Related delivered work includes RK3566 terminal and BSP adaptation, Linux/Qt HMI development and RK3528 Linux network gateway development. Their case descriptions define the delivered scope; individual Linux, Android and bootloader requirements still need project-specific agreement.

STM32 firmware and RTOS project scoping

For MCU work, define peripheral behavior, acquisition timing, communication frames, error handling and recovery before implementation. If your application requires an RTOS, share the kernel and version, task priorities, interrupt use, memory limits and scheduling requirements so the scope and tests can be agreed.

The STM32 data-acquisition and multi-interface IoT gateway cases demonstrate delivered STM32 work. Their published descriptions do not identify an RTOS, so they should be read as STM32 hardware and firmware references.

Deliverables and verification

• A diagnostic conclusion or agreed firmware/BSP changes, with the relevant board and software versions identified.
• Build and configuration notes, flashing or recovery instructions, and test records as included in the project scope.
• Source code, patches, design revisions and maintenance responsibilities explicitly defined before handover.

Acceptance can cover startup, peripheral operation, communication, fault reproduction and recovery using agreed test conditions. Test duration, load and pass criteria are set for the application. A successful boot alone does not establish long-term stability or validate every interface.

The linked customer projects were completed and delivered after physical hardware and software testing met their agreed requirements. A new board revision, driver, RTOS or software image needs its own verification.

Inputs for an actionable review

Send the board revision, schematic or interface details, supply conditions, boot or serial logs, reproduction steps, current firmware, source availability and expected behavior. Identify any source restrictions and the hardware available for testing. We can then separate diagnosis from a larger port, rewrite or hardware change.

Relevant embedded platforms

Discuss your firmware or BSP task