Case Studies
BSP and driver development for a navigation platform
Key Results
- Linux, RTEMS, and bootloader support
- NAND, SD, USB, and Ethernet integration
- Cross-platform abstraction for four targets
About the project
A global manufacturer of GNSS and positioning systems was developing a navigation platform based on a multicore SoC with ARM and LEON processor subsystems. Linux ran on the ARM subsystem, while RTEMS ran on LEON. Each processor used a separate bootloader and accessed integrated NAND, SD, USB, and Ethernet controller IP through its own runtime and initialization stack.
PerformaCode extended the existing BSP and developed additional platform components in C. The scope covered Linux and RTEMS drivers, storage support in the ARM and LEON bootloaders, Linux Device Tree configuration, board-level initialization, and functional and performance testing.
Some drivers were implemented from scratch, while others were adapted from existing drivers for known controller IP. Common storage-driver logic was reused between the ARM and LEON bootloaders where the controller interfaces and execution constraints allowed it.
The work covered the platform from early boot through operating-system-level peripheral access, including boot from NAND and SD, USB host and device integration, Ethernet support, and verification against functional and performance requirements.
2-4
engineers
26
months
FP
delivery model
Client challenges
The navigation platform combined two processor architectures with different operating systems, runtime environments, and boot sequences. Linux ran on the ARM subsystem, while RTEMS handled real-time workloads on LEON. Storage and peripheral support had to behave consistently across operating-system and bootloader layers without treating each environment as an independent implementation.
The platform relied on NAND flash, SD storage, USB host, USB device, and Ethernet interfaces from the earliest boot stages through normal system operation. Drivers had to integrate with existing BSP components, Linux Device Tree configuration, and board-specific initialization while accounting for differences in processor architecture, execution context, and driver models.
The objective extended beyond making individual peripherals operational. The platform software had to provide a stable foundation for the navigation application, requiring reusable low-level components, deterministic hardware initialization, and verified storage and network performance on the target hardware.
Tasks performed
- Set up the development environment for Linux, RTEMS, and the separate ARM and LEON boot chains, including kernel, RTOS, bootloader, root filesystem, and boot-image builds.
- Extended existing BSP components for a heterogeneous ARM/LEON SoC with Linux on the ARM subsystem and RTEMS on LEON.
- Reviewed controller specifications and existing driver code to determine which implementations could be ported and which required development from scratch.
- Developed and ported NAND flash drivers for Linux, RTEMS, and both bootloader environments.
- Developed and ported SD controller drivers for Linux, RTEMS, and both bootloader environments.
- Implemented boot from NAND and SD media for the ARM and LEON subsystems.
- Reused common storage-driver logic between the ARM and LEON bootloaders where the controller interface and execution constraints permitted.
- Adapted USB host support to the custom board, including controller initialization and mass-storage access.
- Adapted USB device support to the board configuration and verified device recognition by an external USB host.
- Integrated Ethernet support for the target hardware and verified communication over TCP/IP and UDP.
- Configured Linux Device Tree entries for the supported peripherals and board resources.
- Implemented board-specific initialization for GPIO multiplexing, clocks, power-related settings, and peripheral resources.
- Built Linux test utilities and shell scripts for block access, file operations, operating modes, USB enumeration, and network communication.
- Built RTEMS test applications using native device interfaces for storage functionality and performance verification.
- Measured storage access and transfer performance against the available hardware requirements.
- Measured Ethernet behavior against the required throughput and timing characteristics.
- Integrated and verified boot images for Linux and RTEMS on the target development boards.
Project results
Boot from NAND and SD
Both processor subsystems gained boot support for NAND flash and SD media through bootloader storage initialization and read-path implementation, enabling flexible software deployment.
5 peripheral subsystems
NAND, SD, USB host, USB device, and Ethernet support was delivered through new and ported C drivers with BSP integration, providing the hardware services required by the navigation platform.
Shared ARM/LEON code
Common controller logic was separated from processor-specific initialization and reused across ARM and LEON bootloaders, reducing duplicate low-level code.
Linux and RTEMS support
The same storage hardware became available under Linux and RTEMS by adapting drivers to different APIs and runtime models, ensuring consistent platform behavior.
Board bring-up completed
The custom hardware became ready for software development through BSP extensions, Device Tree configuration, and board-level initialization, completing platform bring-up.
3 communication interfaces
USB host, USB device, and Ethernet became operational through controller adaptation and target-hardware validation, providing the platform’s external communication interfaces.
Performance targets met
Storage and Ethernet performance was validated using dedicated Linux and RTEMS test applications, confirming compliance with platform requirements.
Target platform validated
The BSP, bootloaders, and device drivers were verified on target hardware through functional and performance testing, reducing integration risk for higher software layers.
4 execution environments
Storage support was implemented across Linux, RTEMS, and the ARM and LEON bootloaders by adapting common controller logic to each runtime API and initialization sequence, allowing the same hardware resources to operate from early boot through runtime.
Value we bring
Building platform software while hardware is still changing
Prototype boards rarely stay fixed long enough for firmware to wait. Pin assignments move, clocks change, peripherals are replaced, and initialization sequences are revised as hardware faults are found. We keep the platform usable through those changes by working from schematics, controller specifications, board revisions, register-level diagnostics, and target-hardware tests, then updating the BSP, bootloader, Device Tree, and drivers in the same development loop.
Taking vendor code beyond the reference board
Reference BSPs and example drivers are written for evaluation hardware, not the final product. We use them where they are technically sound, replace them where assumptions no longer hold, and write missing components from scratch when the controller, board layout, or boot flow requires it. The resulting software reflects the actual memory map, clock tree, interrupt routing, storage configuration, and peripheral set of the production board.
Sharing code without hiding hardware differences
Multi-processor platforms create pressure either to duplicate drivers or to force every target through one abstraction. We separate reusable controller logic from processor-specific startup, interrupt handling, memory access, and OS integration. That allows common code to be reused across ARM and LEON while keeping the parts that genuinely depend on architecture or runtime explicit and testable.
Technologies
- Linux
- RTEMS
- C/C++
- ARM
- LEON
- BSP
- Bootloaders
- Linux Device Tree
- NAND
- SD
- USB
- Ethernet
- TCP/IP
- UDP
Other Case Studies
Shift-Left PCI Express Device Modeling
Developed 20+ PCI Express device models enabling full-system softw...
