OPX Porting Guide

NOTE: Preliminary and work-in-progress contents

OPX Base code is developed to be portable to various hardware platforms. Only a very small amount of code is platform-specific — most platform-specific capabilities are defined in configuration files located at system initialization time.

The switch abstraction interface (SAI) and system device interface (SDI) components contain network processing unit (NPU) and system device-specific codes. The existing components can be reused on platforms that share the same NPU and/or system devices.

The code for network adaptation services (NAS) and the platform adaptation service (PAS) components are hardware-independent. Porting the NAS and PAS components to a new platform involves creating new configuration and initialization script files for that specific platform.

The configuration for the temperature control (TC) component (architecturally) is in the software layer above the PAS — it also needs to be adapted to the thermal characteristics of new platforms.

All platform configuration files are stored in opx-platform-config. For each new platform, you must create two directories in the opx-platform-config repository:

• Directory for the hardware device-dependent configuration files (mainly SAI, SDI, system startup and shutdown), such as dell/s6000-hw. The directory name follows the convention: VENDOR_NAME/PLATFORM_NAME-hw (dell/s6000-hw).

• Directory for the hardware device-independent configuration files (NAS, PAS, temperature control), such as dell/s6000/etc/opx. The directory name follows the convention: VENDOR_NAME/PLATFORM_NAME/etc/opx.

Platform scripts

These scripts are called at platform initialization time and shutdown. The scripts can be adapted for new platforms and are optional depending on how developers decide to initialize or shutdown a given hardware platform.

Platform initialization script

The platform initialization script is executed once at startup — it must be included in the systemd startup configuration. It can perform various tasks, such as CPLD initialization or SMBus controller initialization (depending on the platform). See opx_platform_init.sh for a platform initialization script example. Add the platform initialization script to the systemd platform initialization service (such as opx-platform-init.service).

Platform shutdown script

See opx_platform_shutdown.sh for a platform shutdown script example.

SDI component portability information

Porting the SDI component to a new hardware platform includes:

• Creating SDI configuration files for the new platform
• Implementing new low-level device drivers (if the new hardware platform has previously unsupported hardware modules)

NPU porting information

OPX Base currently uses SAI API 0.9.4.

SAI portability — using a compatible Broadcom NPU

A Broadcom-compatible SAI binary (SAI API 0.9.4 compatible) is available in binary form. Its current version supports Trident-II, Maverick, and Tomahawk Broadcom chipsets.

You need to create an SAI initialization file (init.xml) which is required by the OPX SAI BCM implementation. This file contains parameter definitions including:

• Port LED information
• Logical port description
• Number of lanes per port (correspond to logical ports in breakout modes)
• NPU traffic scheduler configuration
• Number of physical and logical ports for the NPU (logical ports corresponding to breakout modes)

See init.xml for an SAI initialization file example.

Using a new NPU

You have these options when porting to a new NPU:

• Obtain a SAI implementation compatible with the current API version (0.9.4) for the particular NPU (alternatively, SAI API 0.9.6 and SAI API 1.0 will be supported in the future)
• Develop a separate implementation of the NDI API (part of the NAS) to adapt a SAI implementation not compatible with API version 0.9.4, or a completely different vendor SDK

NAS porting information

See dell/s6000/etc/opx for an NAS configuration example.

NAS configuration files

Configuration file	Description
base_port_physical_mapping_table.xml	Mapping of NPU ports to device front panel ports, and various characteristics of each front panel port including breakout mode, Linux interface name, and so on.
base_qos_init.xml	Quality of service (QoS) parameters for the platform including traffic class to queue mapping, QoS/TC scheduler configuration, WRR profiles, and so on.
mac_address_alloc.xml	MAC address allocation scheme for the Management interface and front panel ports (assuming a unique system MAC address is used as the base.
phy_media_default_npu_setting.xml	Transceivers supported including optical media.
switch.xml	Switch (NPU) configuration.

Platform supported statistics/counters configuration

NPU supported counters for a specific platform are defined in the nas_ndi_plat_stat.c file. Per platform functions defined in this file return the list of counters supported including VLAN interfaces and physical interfaces/ports.

PAS porting information

Create a per-platform config.xml file for each PAS configuration file. The PAS configuration file defines:

• PAS objects to register with the CPS framework
• LED groups
• Polling intervals
• Types of transceivers supported for a given platform

See config.xml for a PAS configuration file example.

Temperature control

The TC configuration file is located in the config.json file. The file contents are specific to a given platform — create a new file and modify the contents to the target platform.

1. Define the speed values (in RPMs) for the fans in the Fan Tray units, and fans in the PSUs (if any) at various system levels for both normal and reverse airflows. Normal refers to blowing air from the exterior towards the switch hardware, and reverse airflow refers to drawing hot air from the system and exhausting it towards the exterior. A system level defines the type of airflow and fan speeds for the various system fans.

2. Define the temperature thresholds of the various sensors in the system which trigger the activation of a given system level.

See env-tmpctl for a TC configuration file example.