Designing a Reliable File System on FMQL45T900 with VxWorks

Designing a Reliable File System on FMQL45T900 with VxWorks

🌍 Strategic Context: Domestic SoC Adoption

#

In the current landscape of supply-chain constraints and export controls, reliance on imported semiconductor platforms introduces systemic risk for critical embedded systems. As a result, domestically developed system-on-chip (SoC) platforms have become increasingly important across aerospace, defense, and industrial domains.

A 2025 study published in Computer Measurement & Control presents a complete implementation of a production-grade file system on the FMQL45T900, a fully domestic programmable SoC. The work demonstrates that high-performance, reliable storage subsystems can be achieved without dependence on external silicon or proprietary storage stacks.

The target system integrates VxWorks in symmetric multiprocessing (SMP) mode, leveraging its deterministic scheduling and mature I/O subsystem to support robust embedded storage.

🧩 Platform Overview: FMQL45T900 Characteristics

#

The FMQL45T900 follows a heterogeneous architecture comparable to Zynq-class devices, combining:

• Quad-core ARM Cortex-A7 processing system (PS)
• Programmable logic (PL) fabric for hardware acceleration
• Native support for VxWorks with a production-ready BSP

This architecture enables tight coupling between software-defined storage logic and hardware-level acceleration if required. The primary engineering challenge addressed in the paper is the implementation of a reliable file system over the onboard eMMC interface.

🏗️ System Architecture

#

The design adheres to the standard VxWorks layered I/O model, ensuring modularity and maintainability:

• Hardware Layer — eMMC 5.1 controller operating in 4-bit SDR mode at 25 MHz
• Driver Layer (VxBus) — Block device driver abstraction
• Middleware Layer — XBD (eXtended Block Device) and DosFS
• Application Layer — POSIX-compliant file I/O

This separation enforces clear boundaries between hardware interaction and application logic, allowing independent evolution of each layer while preserving system stability.

⚙️ eMMC Interface Configuration

#

The eMMC device is accessed through an SDIO-compatible interface using multiplexed I/O (MIO) pins:

• MIO40 → EMMC_CLK
• MIO41 → EMMC_CMD
• MIO42–45 → EMMC_D0–D3

Device configuration is defined through a device tree structure, enabling platform portability:

mmc0: dwmmc@e0043000 {
    compatible = "fmsh.psoc-dw-mshc";
    reg = <0xe0043000 0x1000>;
    clocks = <&clkc NCLK_AHB_SDIO0>, <&clkc NCLK_SDIO0>;
    clock-names = "biu", "ciu";
    bus-width = <4>;
    cap-mmc-highspeed;
    status = "okay";
};

This approach decouples hardware description from driver implementation, allowing reuse across multiple SoC variants with minimal modification.

🔌 Driver Stack and Storage Pipeline

#

The storage subsystem is built on VxWorks’ modern block I/O architecture:

Block Device Driver

#

• Operates on 512-byte sectors

• Implements core primitives:

  • mmcStorageBlkRead
  • mmcStorageBlkWrite

• Handles command sequencing, data transfer, and error conditions

XBD (eXtended Block Device)

#

• Provides a unified abstraction layer for block devices

• Supports caching and request scheduling

• Key structures:

  struct xbd { ... xbd_blocksize, xbd_nblocks ... };
  struct bio { device_t bio_dev; sector_t bio_blkno; ... };
  

DosFS File System

#

• FAT16/FAT32-compatible implementation with VFAT support
• Ensures interoperability with standard desktop environments
• Provides predictable performance under real-time constraints

VxBus Integration

#

• Enables automatic driver discovery and binding
• Simplifies system configuration through modular component inclusion

All components are integrated via INCLUDE_ macros in the kernel configuration, maintaining a clean and scalable build system.

🔄 Read and Write Operation Flow

#

The implementation directly maps to standard eMMC command sequences:

Read Path (CMD17)

#

• Configure block length
• Issue CMD17 (single-block read)
• Receive response (R1), data payload, and CRC
• Issue CMD12 (stop transmission)

Write Path (CMD24)

#

• Configure block length
• Issue CMD24 with data and CRC
• Monitor device busy state
• Wait for DATA0 line release

These operations are encapsulated within the driver layer, exposing a consistent block interface to XBD and higher-level components.

🧪 Validation and Reliability Testing

#

The system was validated on physical FMQL45T900 hardware using end-to-end data integrity tests:

• File upload via FTP followed by POSIX read() verification
• Pattern-based write tests with subsequent retrieval and comparison
• Byte-level validation confirming exact data consistency

Serial output traces confirmed correct operation across all layers:

• Application layer (POSIX API)
• DosFS file system
• XBD middleware
• Block device driver

The platform demonstrated stable behavior under repeated read/write cycles, meeting requirements for reliability, data integrity, and sustained performance.

🚀 Key Engineering Outcomes

#

This implementation establishes a practical blueprint for embedded storage on domestic SoC platforms:

• Full storage stack built without reliance on imported controllers
• Strong modularity via VxBus and device tree configuration
• Compatibility with standard FAT-based ecosystems
• Deterministic behavior aligned with real-time system constraints

The design is directly applicable to systems requiring long lifecycle support and strict control over hardware and software dependencies.

🔭 Future Implications

#

As domestic SoC ecosystems continue to mature, reusable storage architectures such as this will play a critical role in accelerating adoption. The FMQL platform, combined with VxWorks, provides a stable foundation for:

• Aerospace data recorders
• Industrial control systems
• Safety-critical embedded platforms

The broader implication is clear: high-reliability embedded storage can now be fully realized within domestically controlled technology stacks, without sacrificing performance or determinism.

This work reinforces the viability of independent embedded ecosystems while preserving the engineering rigor expected in modern real-time systems.