FSI and Safety Services Package (FSISSP) Changes#

Merger of FSI and Safety Services#

DRIVE OS 6.x delivered the components FSI-SW and Safety Services separately. For efficiency and ease of integration, these two components are combined and delivered as a single module named FSI SSP (Functional Safety Island - Safety Services Package) in DriveOS 7.0.

The FSI SSP component consists of two main parts: - Building blocks required for AUTOSAR-based software to run on Functional Safety Island (FSI). - Safety services framework for error reporting and communication to MCU. - FSI-CCPLEX communication over shared DRAM carveout.

The following diagram is of the FSISSP combined architecture:

image1

Hardware and Platform Software Details#

DRIVE OS Release Platform

SoC

FSI SSP

DRIVE OS 6.5.x

Orin

FSI Software : AUTOSAR MCALs and CDDs on FSI, open box source code and closed box binary. Extended DRAM for code and data on FSI (including Customer calibration data).

Safety Services : Error reporting framework. FSI-CCPLEX communication over shared RAM. DRAM ECC Error handling. Early boot failure detection and logging via MB1.

DRIVE OS 7.0.x

Thor

FSISSP : Features of FSI and Safety Services combined.

New features:

  • Ethernet MCAL support

  • DRAM Patrol scrub via FSI

  • NvLog Support for FSI

  • Supports ELMOS device for USS sensor, via generic SPI driver.

  • Additional GPIO ports, GPT channels (4 to 16), DMA channels on FSI when compared to Orin SoC

  • UTC : combined UART used for FSI Shell is replaced by a new CDD : UART – Trace - Controller

Limitations:

  • Closed box binary is not supported

  • LIS is disabled

  • WGD timer supports 255ms instead of 512ms on Orin.

  • Customer calibration data not supported

DriveOS 7.2.x

Thor

  • Release 7.2.4.0 adds an API for FSI-CCPLEX-COM. This does not affect backward compatibility of existing APIs. Rationale: The total number processes are limited, and there is a limitation of NvFsiCom support to manage multiple channels within a process. FsiCom APIs allow the current usage with multiple threads within a single process. That performance can be offloaded to individual threads instead of managing everything within the same thread of a process.

  • Robust handling of EC register access from FSI

  • Reference implementation of LCM client on FSI

Planned:

  • Separate DTB for FSI

  • Support for dual Thor board designs

  • Support for VM-restart, multi-VM configurations

In the combined FSI SSP software architecture, the names of the software components on FSI/CCPLEX and interfaces are retained as is from DRIVE OS 6.x.

MCU_FoH module running on Safety MCU is re-designed to support multiple MCU vendors and dual SoC board designs.

Tools and Utilities Changes#

  • The ARM FUSA Compiler is upgraded from version 6.16.2 to 6.22.2 to build FSI binaries, with the latest minor version from ARM Ltd., including all relevant bug fixes. The upgrade is required for DriveOS 7.2 Safety and production releases. The latest version provides improved security hardening features and defect fixes. FSI openbox customers should upgrade the ARM FUSA Compiler version to 6.22.2.

  • The ARM FUSA LibC is upgraded from version 6.6.A to 6.16.A to build FSI binaries. The upgrade is required for DriveOS 7.2 Safety and production releases. FSI openbox customers should upgrade the ARM FUSA LibC version to 6.16.A.

API Changes for FSI-CCPLEX Communication#

Target Changes

Backward Compatible

Platform

OS

The datatype NvFsiComGrpHandle_t is updated to reuse members from the QNX version. Starting from version 7.2.4.0, the following members will no longer be available: IpcEpNotify, IpcEpMsg, and IpcInitFlag. Instead, Linux will use IpcCoID, IpcChID, and IvcInitFlag. These members are used internally for library-to-daemon communication. Do not directly access or modify these members. If using these members in code, update the implementation accordingly.

No

NSR, SR

Linux

Migration Path

  • Orin to Thor

Migration Rationale

This refactoring unifies the core FsiCom architecture and segregates platform-dependent implementations.

Steps to Migrate

Avoid direct access to NvFsiComGrpHandle_t internal members (IpcEpNotify, IpcEpMsg, IpcInitFlag). If unavoidable, then use IpcCoID, IpcChID, and IvcInitFlag instead.