SONiC系统概要、使用及移植

Truman楚门

已于 2024-01-23 17:35:49 修改

阅读量8.5k

点赞数 9

文章标签： docker azure 通信系统架构 linux

于 2022-05-21 16:17:58 首次发布

本文链接：https://blog.csdn.net/qq_24993025/article/details/124897728

版权

本文详细介绍了SONiC（Software for Open Networking in the Cloud）操作系统，涵盖其系统架构、主要组件如Teamd、Pmon、Snmp、Dhcp-relay等容器的职责，以及编译、安装和移植过程。SONiC基于Linux，支持多种硬件平台，提供了一整套网络功能，包括BGP、LLDP、SNMP等。在移植过程中，需要关注平台驱动、硬件SKU配置、SONiC Platform API等，并验证光模块、PSU等硬件功能。文章还介绍了如何使用CLI配置和管理SONiC，以及BSP适配步骤。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

5. 编译broadcom的SONiC实例

2. SONiC Platform API

一、文档概述

1. 文档目的

本文档从多个方面介绍了SONiC及其移植、安装和使用等。旨在帮助没有接触过SONiC的工程师，快速入门、了解SONiC，并学会移植和简单的使用SONiC。

2. 文档背景

SONiC 是一个为网络设备开发的开源操作系统项目。与ONL一样，SONiC需要通过ONIE环境安装系统到磁盘或者flash分区中。

二、SONiC简介

SONiC是一个基于Linux的开源的网络操作系统，运行在多个供应商的交换机和ASIC上。SONiC提供一整套的网络功能，例如BGP和RDMA，这些功能已经在一些知名的云服务厂商的设备上得到运用。目前SONiC已支持的Accton、Dell、ingrasys等诸多厂商的设备。

三、SONiC系统架构

SONiC系统按功能将整个系统划分为多个模块，SONiC系统由多个模块组成。每个模块是一个独立的docker容器，一个docker由多个进程来共同完成这个模块的功能。在SONiC中使用“show services”命令查看每个docker及其进程状态。

截止目前，SONiC将其主要功能分为以下一个docker：

dhcp-relay
pmon
snmp
lldp
bgp
teamd
database
swss
syncd

SONiC架构框架图见下图，图中蓝色的箭头表示通过集中式redis-server进行数据交互，黑色箭头表示通过其他方式（netlink、/sys/文件系统，等等）进行数据交互。

1. Teamd容器

负责在设备中运行LAG功能。teamd进程是一个基于Linux通过LAG协议实现的开源程序。teamsyncd进程是与其他模块通信的进程，teamd进程与其他子模块进行通信需要通过teamsyncd进程。

2. Pmon容器

PSUd进程：监控PSUs状态并且上报给REDIS-DB，需要平台给PSUd提供API，来定期的轮询PSU状态和在位情况。使用show platform psustatus命令查看PSU状态。

Thermalctld进程：是监控温度，监控风扇转速，并运行策略控制风扇的进程。使用show platform temperature命令查看温度。

sensord进程：是Pmon容器的主要进程，负责定期记录硬件传感器的读数并上报告警。
fancontrol进程：从设备驱动获取风扇的状态。

3. Snmp容器

负责snmp功能。这个容器有两个进程：

snmpd：真正的snmp服务器，负责处理从外部网络传入的snmp。
snmpd-agent：这是SONiC实现的一个snmp子代理进程，负责从SONiC集中数据库（redis-engine）取数据传递给snmp进程。

4. Dhcp-relay容器

dhcp-relay进程将没有DHCP服务器的子网的DHCP请求中继到其他一个或多个子网的DHCP服务器。

5. Lldp容器

顾名思义，这个容器负责主机的lldp功能。以下是这个容器中包含的进程：

lldp：真正的具有lldp功能的守护进程。这个进程提供与外部建立lldp连接以实现接受/发送的系统功能。
lldp syncd：负责将lldp的状态上传到redis-engine， redis-engine将lldp的状态传给对该状态感兴趣的进程。
lldpmgr：为lldp进程提供可配置功能，它通过订阅redis-engine消息来实现这一功能。

6. BGP容器

BGP容器包含如下进程：

bgpd：常规的BGP实现。通过常规的tcp/udp套接字接收来自外部的路由状态，并通过zebra、fpmsyncd这两个进程下发。
zebra：传统的IP路由管理器。也就是说，它提供跨协议的内核路由表更新、接口查找和路由重新分配服务。zebra还负责将计算出的FIB下发到内核（通过netlink接口）和转发过程中涉及到的其他容器（通过fpmsyncd进程）。
fpmsyncd：负责收集由zebra产生的FIB状态，并将其内容转存redis-engine的APPL_DB。

7. Database容器

Database容器是SONiC系统其他容器数据交互的核心。容器的数据传递基本上都要经过它。承载redis数据库引擎，

8. SWSS容器

SWSS全称Switch State Service，这个容器是一组工具的集合。负责所有SONiC模块直接进行有效的通信。如果说Database容器有比较强大的存储功能上，SWSS则侧重于提供建立不同模块之间的通信和仲裁功能。SWSS还承载了负责SONiC应用层北向交换的进程。

9. Syncd容器

简而言之，Syncd容器的目标就是提供一个种机制，根据交换机的硬件实际情况同步更新交换机的网络状态。这包括对交换芯片的初始化、配置和获取交换芯片状态。

以下是Syncd容器中的主要进程介绍：

Syncd: 是负责执行交换机的硬件同步逻辑的进程。在编译阶段，Syncd链接对应厂商提供的交换芯片的SDK库，通过调用相应的接口来获取状态。Syncd订阅数据库的ASIC_DB。编译时需要两个deb包：bfnsdk_20210423_sai_1.8.1_deb10.deb（SDK）和bfnplatform_1.0.0_amd64.deb（bf-bsp）。
SAI API
ASIC SDK

10. CLI/SONiC-cfggen

这个模块负责为SONiC提供CLI功能和系统配置功能。

CLI：CLI严重依赖于Python的Click库，为用户提供一个灵活且可定制的方法来构建命令行工具。
SONiC-cfggen：由SONiC的CLI调用，以执行配置更改或任何需要与SONiC其他模块进行配置交互的操作。

四、编译SONiC

1. 编译要求

对编译环境没有严格的要求，官方建议编译环境：

1T硬盘容量。
内核版本不要太老，要支持overlay，建议4.9以上内核版本。
装有docker，版本要求17.06.1及以上。

2. 编译准备工作

准备python环境

sudo apt-get install -y python-pip
sudo python2 -m pip install -U pip==9.0.3
sudo pip install --force-reinstall --upgrade jinja2>=2.10
sudo pip install j2cli

更改系统配置允许非root权限允许docker，增加当前用户名到docker group。

sudo gpasswd -a ${USER} docker

退出命令行窗口重新登录，配置生效。

3. 克隆代码到本地

要求git版本为1.9以上，使用命令：

git clone https://github.com/Azure/sonic-buildimage.git

4. 开始编译

一般的编译流程为：

安装overlay驱动
```
sudo modprobe overlay
```
进入源码目录
```
cd sonic-buildimage
```
make init在克隆完代码后执行一次即可。
```
make init
```
配置ASIC厂商，执行一次即可
```
make configure PLATFORM=[ASIC_VENDOR]
```
SONiC支持的SONiC厂商有：

- PLATFORM=broadcom

- PLATFORM=marvell

- PLATFORM=mellanox

- PLATFORM=cavium

- PLATFORM=centec

- PLATFORM=nephos

- PLATFORM=innovium

- PLATFORM=p4

- PLATFORM=vs
编译SONiC镜像
```
make all
```

5. 编译broadcom的SONiC实例

指定厂商
```
make configure PLATFORM=Broadcom
```
指定debian版本为stretch
```
BLDENV=stretch make stretch
```
编译用于ONIE安装镜像
```
    make target/sonic-broadcom.bin
```

五、安装SONiC

1. 安装ONIE

a. 启动U盘的制作

环境准备

Window环境，实验环境为win10
用于制作启动优盘的优盘，要求不要太烂，否则可能读写不正常
镜像制作软件：rufus-2.11p.exe
ONIE镜像onie-recovery-x86_64-accton-as7716-32x_ro.iso

操作步骤

优盘插入电脑
打开rufus-2.11p.exe
点击“执行”后，一路yes就行了。

b. ONIE的安装

准备环境
1. 启动优盘
2. secureCRT
3. 串口线
secureCRT设置
1. 波特率为115200，8N1
2. 设置显示模式：option -> session option

启动优盘插入设备，并设置bios。插上串口，启动设备，一直按“ESC”键，直至出现如下界面

按左右键，选择如下界面，并选择boot mode为legacy。

保存配置并重启

重启后，连续按“ESC”进入bios界面，并进入如下界面，选择从优盘启动：

进入ONIE启动方式界面：

进入Embed ONIE后，系统会自动安装ONIE并重启设备。至此ONIE安装完毕。

2. 安装SONiC ONIE镜像

连接设备串口。
卸载之前安装的NOS。
重启设备进入ONIE并且选择安装OS。

可通过nfs找到SONiC镜像，然后运行。

ONIE:/ # ifconfig eth0 192.168.4.148 netmask 255.255.252.0
ONIE:/ # mkdir nfs
ONIE:/ # mount 192.168.6.19:/tmpdir /nfs –o nolock
ONIE:/ # /nfs/ sonic-broadcom.bin

当SONiC安装完成，重启可以看到默认选择SONiC启动。

六、SONiC移植

要将SONiC移植到新设备上，你需要提供特定于设备的硬件驱动程序以及特定于设备的配置文件，来正确初始化你的设备。所有的设备特定的更改都在SONiC源码目录下进行。移植要完成三个部分，平台驱动程序、特定于设备的配置文件和SONiC platform API（其中包括PMON 2.0 API）。

1. 平台驱动程序

驱动程序需要通过创建sysfs文件，以便SONiC访问你的硬件。下面列出了你需要提供的驱动程序及其必须提供的功能：

光模块驱动

读写光模块EEPROM。
打开关闭LPMODE。
reset光模块。
在位查询。
光模块中断上报。

传感器

温度
风扇转速
电压等。

前面板状态灯

控制LED灯状态

驱动程序文件放置

SONiC是以ASIC厂商为单位编译的。一个SONiC镜像可以安装在任何使用该厂商ASIC的支持的设备上。该厂商的所有平台设备模块都被编译在一个镜像里。所有的驱动应该放在platform文件夹下对应的厂商板卡目录下。例如：

platform/broadcom/sonic-platform-modules-accton/as7716-32x/module/

文件放置好后要在文件platform/broadcom/platform-modules-${vendor}.mk下添加你驱动的版本号，和对应的ONIE platform string。

驱动的规范要求

在SONiC下添加平台特定驱动的注意事项：

驱动必须被打进一个或多个.deb包里。
驱动所有的依赖性都要在deb中指定。在编译SONiC时，依赖会自动下载并安装。
驱动在安装完成后，不允许reboot。
驱动必须提供init 和 deinit。

2. SONiC Platform API

SONiC需要一种方式和每个平台的硬件外设（风扇、LED、电源模块、光模块和传感器等）的独特配置进行交互，需要按SONiC要求的方式提供一套名为SONiC Platform API的接口。

文件位置：

应该放置在一个名为sonic_platform的文件夹，放在platform文件夹下对应的厂商板卡目录下。

最后将这些文件编译成一个名为sonic_platform-1.0-pyX-none-any.whl包。安装SONiC时会用pipX install sonic_platform-1.0-pyX-none-any.whl命令将这个包安装。这个包应该被copy在：

/usr/share/sonic/device/<VENDOR_NAME>/<ONIE_PLATFORM_STRING>/下。

文件夹结构如下：

sonic_platform/

|-- __init__.py

|-- chassis.py

|-- component.py

|-- eeprom.py

|-- fan.py

|-- fan_drawer.py

|-- led.py

|-- platform.py

|-- psu.py

|-- sfp.py

|-- thermal.py

|-- watchdog.py

3. 移植后验证

验证光模块

移植完成后，可以使用sfputil命令确认一下功能是正常的。sfputil show eeprom / sfputil show eeprom --dom : 校验所有光模块的诊断信息是否正确、显示是否正常。

sfputil show presence : 校验光模块在位状态显示是否正常
sfputil show lpmode : 校验所有光模块LPMODE是否可设
sfputil reset ... : 光模块能否重启
sfputil lpmode ... : 光模块能否配置lpmode。

验证PSU

使用show platform psustatus命令，向REDIS-DB查询，查看各PSU的在位情况。

admin@sonic:~$ show platform psustatus
PSU    Status
-----  -----------
PSU 1  OK
PSU 2  OK
PSU 3  OK
PSU 4  NOT PRESENT
PSU 5  NOT PRESENT
PSU 6  NOT PRESENT

4. 特定于平台的文件

所有关于特定平台的配置文件或诊断信息以及硬件SKU都在包含在/usr/share/sonic/device/这个目录下。

关于SKU

SONiC通过platform和硬件SKU两个层确定一个特定设备，有的设备可能硬件基本都一致，这是前面板端口数量或者配置不一致，为了避免大量重复代码。

就提炼了硬件SKU这一层，一个platform下可能包含多个硬件SKU。每个SKU是一个文件夹，名字要独一无二放在device目录下。

文件夹里是该SKU不同于其他SKU的特殊配置。所有SKU共享的文件直接放在device目录下。最后通过一个配置文件default_sku，决定用的是这个设备哪个SKU。

目录结构

device/

|-- <VENDOR_NAME>/

|   |-- <ONIE_PLATFORM_STRING>/

|   |   |-- <HARDWARE_SKU>/

|   |   |   |-- port_config.ini

|   |   |   |-- hwsku.json

|   |   |   |-- sai.profile

|   |   |   |-- xxx.config.bcm

|   |   |   |-- buffer_defaults_t0/t1.j2

|   |   |   |-- pg_profile_lookup.ini

|   |   |   |-- Qos.json

|   |   |-- plugins/ [DEPRECATED]

|   |   |   |-- led_control.py

|   |   |-- default_sku

|   |   |-- fancontrol [DEPRECATED in favor of utilizing thermalctld]

|   |   |-- installer.conf

|   |   |-- led_proc_init.soc

|   |   |-- pcie.yaml

|   |   |-- platform_env.conf

|   |   |-- platform.json

|   |   |-- platform_reboot

|   |   |-- pmon_daemon_control.json

|   |   |-- sensors.conf

|   |   |-- system_health_monitoring_config.json

|   |   |-- thermal_policy.json

在device/目录下创建<VENDOR_NAME>/ <ONIE_PLATFORM_STRING>/目录，平台设备文件应该放置在这个路径下。VENDOR_NAME是ASIC厂商的名字，ONIE_PLATFORM_STRING是ONIE识别设备的字符串。

其中每个platform中每个硬件SKU特殊的文件应该在：

device/<VENDOR_NAME>/<ONIE_PLATFORM_STRING>/

目录下建立一个<HARDWARE_SKU>/文件夹，放在该文件夹下。这个名字应该是独一无二的。

除了硬件SKU特殊的文件，其他平台共享的文件应该直接放在：

device/<VENDOR_NAME>/<ONIE_PLATFORM_STRING>/

目录下。

文件说明

default_sku

配置默认的<HARDWARE_SKU>和topology的配置文件。比如：

Force10-S6000 t1

Force10-S6000是默认的硬件SKU，t1为默认的topology。

buffer_defaults_t0/t1.j2

特定于硬件SKU的文件，用于设置入口、出口缓冲池和缓冲区配置文件。这个文件是ASIC供应商提供的，并且会随着不同的ASIC类型而变化。

pg_profile_lookup.ini

特定于硬件SKU的文件，用于配置端口在不同速率下的连接的线缆长度、xon, xoff, size, threshold等。

fancontrol（此文件已被弃用）

给fancontrol守护进程使用的系统风扇的配置文件。

installer.conf

ONIE安装程序的配置文件。配置console设备，端口、波特率等。

实例：

CONSOLE_PORT=0x2f8

CONSOLE_DEV=1

CONSOLE_SPEED=9600

ONIE_PLATFORM_EXTRA_CMDLINE_LINUX="acpi_enforce_resources=lax acpi=noirq"

VAR_LOG_SIZE=100

platform_env.conf

为指定platform模块配置环境参数的配置文件。

格式：每一行遵守<key>=<value>的格式。

示例：

dmasize=128M

usemsi=1

led_proc_init.soc

初始化Broadcom LED处理器芯片的配置文件。

platform.json

一个定义了设备硬件真实情况的文件，将设备的硬件特性组织成一个chassis。按照层次将硬件外设的属性都表示出来。提供给sonic-mgmt repository在恢复出厂设置时使用。具体应该参考文件：

/usr/share/sonic/device/x86_64-cel_seastone-r0/platform.json。

platform_reboot

一个可执行脚本，脚本的功能是通过操作硬件对设备进行硬重启。脚本用Python或Shell都行，必须能够直接执行（./ platform_reboot）

PS:脚本还要让SONiC知道这是用户操作的硬重启，否则SONiC就会探测为这是硬件问题引起的重启。

pmon_daemon_control.json

给PMon容器用，配置在启动过程中跳过那些守护进程。如果没有忽略项，这个文件可以没有。更多的细节见设计文档：

https://github.com/Azure/SONiC/blob/master/doc/pmon/pmon-enhancement-design.md#4-pmon-daemons-dynamically-loading

示例：

{
     "skip_ledd": true,
     "skip_xcvrd": false,
     "skip_psud": false
}

测试/验证：build一个SONiC镜像，并检查Pmon容器的superviosrd 配置文件和start.sh。查看文件中是否已经排除了需要跳过的守护进程，并检查系统启动后是否和预期一致。

sensors.conf

用于配置sensord 守护进程的sensor输出的配置文件。

要求：

为每个传感器提供清晰易懂的lable。
定义每个传感器的临界值。可以在这个文件中定义，也可以在硬件中定义，只要告警产生。

示例：

# libsensors configuration file 
# ----------------------------------------------
#   
    
bus "i2c-2" "SCD SMBus master 0 bus 0"
bus "i2c-3" "SCD SMBus master 0 bus 1"

chip "lm73-i2c-3-48"
    label temp1 "Rear Temp Sensor"
    set temp1_max 65

pcie.yaml

描述了设备上应该有的PCIe设备列表。该文件被sonic-platform-daemons使用，定期检查监控PCIE设备的状态。pcie-check.service会检查列表内PCIe设备的初始化状态。这个文件可以用‘pcieutil generate’命令自动生成。

示例：

bus: '00'
dev: '14'
fn: '2'
id: 1f41
 	name: 'Ethernet controller: Intel Corporation Ethernet Connection I354'

hwsku.json

端口默认breakout模式，和platform.json配合使用，就可以不用port_config.ini文件。

port_config.ini

端口映射表。

Note：不赞成使用platform.json和hwsku.json文件。

示例：

# name     lanes        alias      speed  autoneg     fec  index

Ethernet0   0,1,2,3      Ethernet0   100000   0       none   0

Ethernet4   4,5,6,7      Ethernet4   100000   0       none   1

Ethernet8   8,9,10,11    Ethernet8   100000   0       none   2

Ethernet12  12,13,14,15  Ethernet12  100000   0       none   3

Ethernet16  16,17,18,19  Ethernet16  100000   0       none   4

Ethernet20  20,21,22,23  Ethernet20  100000   0       none   5

sai.profile / Broadcom config file

用来初始化SAI / Broadcom ASIC的配置文件。

led_control.py（可选）

给SONiC LED控制进程提供API，来控制前面板端口LED

system_health_monitoring_config.json（可选）

对系统运行状态监视进程进行的特殊配置的文件

示例：

{
    "services_to_ignore": [],

    "devices_to_ignore": ["psu","asic","fan"],

    "user_defined_checkers": [],

    "polling_interval": 60,

    "led_color": {

        "fault": "orange",

        "normal": "green",

        "booting": "orange_blink"

    }
}

thermal_policy.json

为设备上定制特殊thermal策略的配置文件。

八、SONiC使用及命令说明

1. 默认登录方式

sonic login: admin

Password: YourPaSsWoRd

2. 进入root用户

sudo -i

3. 设置静态IP

管理口是eth0，一般是DHCP获取的。

设置：

sudo config interface ip add eth0 192.168.7.138/22

查看：

show management_interface address  or
/sbin/ifconfig eth0

config hostname <new_hostname>

4. show命令集

show version



show clock //等价于date



show boot //显示当前OS镜像，和下一次reboot后将要load的OS，并列出设备上所有可用的image



show environment //显示设备环境，电压温度和风扇转速等等



show reboot-cause //查看上一次reboot的原因



show reboot-cause history



show uptime //查看当前系统已经启动了多长时间



show logging // 查看系统日志



show logging | more



show logging sensord



show logging --lines 50



show users //who



show platform summary



show platform syseeprom



show platform ssdhealth //显示SSD的状态



show platform psustatus //显示PSU的状态



show platform fan



show platform temperature



show interfaces transceiver (eeprom [-d|--dom] | lpmode | presence)

[<interface_name>] //查看光模块信息



show interfaces status



show techsupport //收集设备信息，用于故障排查

九、SONiC bsp适配步骤方案

移植大体分为两个部分platform和device。

platform包括驱动、sonic_platform Python API、应用程序及脚本和服务配置文件等部分，最后该部分会被打成一个名为sonic-platform-ebpioneer-swans_1.0.0_amd64.deb的包。

device包括各种配置文件，最后该部分会被打成一个名为sonic-device-data_1.0-1_all.deb的包。

1. platform

目录结构：

├── debian

│   ├── changelog

│   ├── compat

│   ├── control

│   ├── rules

│   ├── sonic-platform-ebpioneer-swans.install

│   └── sonic-platform-ebpioneer-swans.postinst

└── swans

    ├── firmware

    ├── modules

    │   ├── fpga_cp

    │   ├── pca9665

    │   ├── Makefile

    ├── README.md

    ├── scripts

    │   ├── pddf_pre_driver_install.sh

    │   ├── pddf_pre_device_install.sh

    │   ├── pddf_post_device_create.sh

    │   ├── pddf_post_driver_install.sh

    ├── setup.py

    ├── sonic_platform

    │   ├── chassis.py

    │   ├── ...

    ├── sonic_platform_setup.py

    └── systemd

        └── pddf-platform-init.service

第一步：添加驱动

方法一：将驱动源码添加在swans/modules目录下，随生成deb包时编译并打包。
方法二：将编译好的驱动（*.ko）,直接放在swans/modules/extra文件下并打包。

第二步：写sonic_platform。

SONiC需要一种方式和每个平台的硬件外设（风扇、LED、电源模块、光模块和传感器等）的独特配置进行交互，需要按SONiC要求的方式提供一套名为SONiC Platform API的接口。这些接口可以自己写，也可使用pddf提供的线程接口，我们选用pddf提供的API。

使用pddf通过的API模板，直接将sonic-buildimage/platform/pddf/platform-api-pddf-base/sonic_platform_ref路径下的内容全部copy到sonic_platform

下。
如果有一些接口需要自定义，直接在对应的py文件中自定义对应接口的实现，编译时会自动覆盖pddf中该接口的实现。比如sfp的获取光模块reset状态接口get_reset_status()：

最后将这些文件编译成一个名为sonic_platform-1.0-pyX-none-any.whl包。安装SONiC时会用pipX install sonic_platform-1.0-pyX-none-any.whl命令将这个包安装。这个包应该被copy在：
/usr/share/sonic/device/<VENDOR_NAME>/<ONIE_PLATFORM_STRING>/下。

第三步：添加应用程序和启动脚本。

将一些特定的应用程序和脚本放在swans/scripts文件夹下，在安装时，该目录的文件将被安装至/usr/local/bin目录下。
填充BSP初始化脚本。

pddf_pre_driver_install.sh
pddf在初始化安装driver之前会运行此脚本。
pddf_post_driver_install.sh
pddf在初始化安装driver之后会运行此脚本。
pddf_pre_device_install.sh
pddf在初始化创建设备节点之前会运行此脚本。
pddf_post_device_create.sh
pddf在初始化创建设备节点之后会运行此脚本。

第四步：编写deb包配置文件

changelog

deb包的changelog，必须按照debian包的规范编辑此文件。

compat

描述deb包的debhelper版本兼容性。

control

描述deb包的信息必须的文件，这个文件主要描述软件包的名称（Package），版本（Version），Installed-Size（大小），Maintainer（打包人和联系方式）以及描述（Description）等，是deb包必须具备的描述性文件，以便于软件的安装管理和索引。

字段	用途	例子/其他
Package	程序名称	中间不能有空格
Version	软件版本
Description	程序说明
Section	软件类别	utils, net, mail, text, x11
Priority	软件对于系统的重要程度	required, standard, optional, extra等
Essential	是否是系统最基本的软件包	yes/no，若为yes,则不允许卸载（除非强制性卸载）
Architecture	软件所支持的平台架构	i386, amd64, m68k, sparc, alpha, powerpc等
Source	软件包的源代码名称
Depends	软件所依赖的其他软件包和库文件	若依赖多个软件包和库文件，采用逗号隔开
Pre-Depends	软件安装前必须安装、配置依赖性的软件包和库文件	常用于必须的预运行脚本需求
Recommends	推荐安装的其他软件包和库文件

rules

deb包的打包文件（很关键），类似于Makefile。

sonic-platform-xxx-yyy.install
sonic-platform-xxx-yyy.postinst
inst是install（安装）的缩写。

pre是表示XX之前的前缀。

post是表示XX之后的前缀。

rm是remove（移除）的缩写。

preinst文件在Deb包文件解包之前（即软件安装前），将会运行该脚本。可以停止作用于待升级软件包的服务，直到软件包安装或升级完成。

postinst文件负责完成安装包时的配置工作。如新安装或升级的软件重启服务。软件安装完后，执行该Shell脚本，一般用来配置软件执行环境，必须以“#!/bin/sh”为首行。

2. device

目录结构：

device/

|-- <VENDOR_NAME>/

|   |-- <ONIE_PLATFORM_STRING>/

|   |   |-- <HARDWARE_SKU>/

|   |   |   |-- port_config.ini

|   |   |   |-- hwsku.json

|   |   |   |-- sai.profile

|   |   |   |-- xxx.config.bcm

|   |   |   |-- buffer_defaults_t0/t1.j2

|   |   |   |-- pg_profile_lookup.ini

|   |   |   |-- Qos.json

|   |   |-- plugins/ [DEPRECATED]

|   |   |   |-- led_control.py

|   |   |-- default_sku

|   |   |-- fancontrol [DEPRECATED in favor of utilizing thermalctld]

|   |   |-- installer.conf

|   |   |-- led_proc_init.soc

|   |   |-- pcie.yaml

|   |   |-- platform_env.conf

|   |   |-- platform.json

|   |   |-- platform_reboot

|   |   |-- pmon_daemon_control.json

|   |   |-- sensors.conf

|   |   |-- system_health_monitoring_config.json

|   |   |-- thermal_policy.json

|   |   |-- pddf

|   |   |   |-- pddf-device.json

|   |   |   |-- pd-plugin.json

|   |   |-- pddf_support

default_sku

配置默认的<HARDWARE_SKU>和topology的配置文件。比如：

Ebpioneer-Swans t1

Ebpioneer-Swans是默认的硬件SKU，t1为默认的topology。

buffer_defaults_t0/t1.j2

特定于硬件SKU的文件，用于设置入口、出口缓冲池和缓冲区配置文件。这个文件是ASIC供应商提供的，并且会随着不同的ASIC类型而变化。

fancontrol（此文件已被弃用）

给fancontrol守护进程使用的系统风扇的配置文件。

installer.conf

ONIE安装程序的配置文件。配置console设备，端口、波特率等。
实例：

CONSOLE_PORT=0x2f8
CONSOLE_DEV=1
CONSOLE_SPEED=9600
ONIE_PLATFORM_EXTRA_CMDLINE_LINUX="acpi_enforce_resources=lax acpi=noirq"
VAR_LOG_SIZE=100

platform_env.conf

为指定platform模块配置环境参数的配置文件。
格式：每一行遵守<key>=<value>的格式。
示例：

dmasize=128M
usemsi=1

led_proc_init.soc

初始化Broadcom LED处理器芯片的配置文件。

platform_reboot

一个可执行脚本，脚本的功能是通过操作硬件对设备进行硬重启。脚本用Python或Shell都行，必须能够直接执行（./ platform_reboot）

PS:脚本还要让SONiC知道这是用户操作的硬重启，否则SONiC就会探测为这是硬件问题引起的重启。

pmon_daemon_control.json

给PMon容器用，配置在启动过程中跳过那些守护进程。如果没有忽略项，这个文件可以没有。更多的细节见设计文档：https://github.com/Azure/SONiC/blob/master/doc/pmon/pmon-enhancement-design.md#4-pmon-daemons-dynamically-loading。

示例：

{
        "skip_ledd": true,
        "skip_xcvrd": false,
        "skip_psud": false
}

sensors.conf

用于配置sensord 守护进程的sensor输出的配置文件。

要求：

1. 为每个传感器提供清晰易懂的lable。
2. 定义每个传感器的临界值。可以在这个文件中定义，也可以在硬件中定义，只要告警产生。
示例：

# libsensors configuration file 
# ----------------------------------------------
#   
    
bus "i2c-2" "SCD SMBus master 0 bus 0"
bus "i2c-3" "SCD SMBus master 0 bus 1"

chip "lm73-i2c-3-48"
    label temp1 "Rear Temp Sensor"
    set temp1_max 65

pcie.yaml

描述了设备上应该有的PCIe设备列表。该文件被sonic-platform-daemons使用，定期检查监控PCIE设备的状态。pcie-check.service会检查列表内PCIe设备的初始化状态。这个文件可以用‘pcieutil generate’命令自动生成。

示例：

bus: '00'
dev: '14'
fn: '2'
id: 1f41
name: 'Ethernet controller: Intel Corporation Ethernet Connection I354'

hwsku.json

端口默认breakout模式，和platform.json配合使用，就可以不用port_config.ini文件。

port_config.ini

端口映射表。

Note：不赞成使用platform.json和hwsku.json文件。

示例：

# name     lanes        alias      speed  autoneg     fec  index
Ethernet0   0,1,2,3      Ethernet0   100000   0       none   0
Ethernet4   4,5,6,7      Ethernet4   100000   0       none   1
Ethernet8   8,9,10,11    Ethernet8   100000   0       none   2
Ethernet12  12,13,14,15  Ethernet12  100000   0       none   3
Ethernet16  16,17,18,19  Ethernet16  100000   0       none   4
Ethernet20  20,21,22,23  Ethernet20  100000   0       none   5

sai.profile / Broadcom config file

用来初始化SAI / Broadcom ASIC的配置文件。

led_control.py（可选）

给SONiC LED控制进程提供API，来控制前面板端口LED。

system_health_monitoring_config.json（可选）

对系统运行状态监视进程进行的特殊配置的文件

示例：

{
    "services_to_ignore": [],
    "devices_to_ignore": ["psu","asic","fan"],
    "user_defined_checkers": [],
    "polling_interval": 60,
    "led_color": {
        "fault": "orange",
        "normal": "green",
        "booting": "orange_blink"
    }
}

pddf-device.json

pddf的驱动和设备节点配置文件。

pddf_support

有这个文件时，代表该设备支持pddf

编译步骤

在sonic根目录下运行。
1、platform部分编译：
编译：

make target/debs/buster/sonic-platform-ebpioneer-swans_1.0.0_amd64.deb

clean：

make target/debs/buster/sonic-platform-ebpioneer-swans_1.0.0_amd64.deb-clean

2、device部分编译：
编译：

make target/debs/buster/sonic-device-data_1.0-1_all.deb

clean：

make target/debs/buster/sonic-device-data_1.0-1_all.deb-clean

SONiC系统概要、使用及移植

一、文档概述

1. 文档目的

2. 文档背景

二、SONiC简介

三、SONiC系统架构

1. Teamd容器

2. Pmon容器

3. Snmp容器

4. Dhcp-relay容器

5. Lldp容器

6. BGP容器

7. Database容器

8. SWSS容器

9. Syncd容器

10. CLI/SONiC-cfggen

四、编译SONiC

1. 编译要求

2. 编译准备工作

3. 克隆代码到本地

4. 开始编译

5. 编译broadcom的SONiC实例

五、安装SONiC

1. 安装ONIE

a. 启动U盘的制作

b. ONIE的安装

2. 安装SONiC ONIE镜像

六、SONiC移植

1. 平台驱动程序

光模块驱动

传感器

前面板状态灯

驱动程序文件放置

驱动的规范要求

2. SONiC Platform API

文件位置：

3. 移植后验证

验证光模块

验证PSU

4. 特定于平台的文件

关于SKU

目录结构

文件说明

八、SONiC使用及命令说明

1. 默认登录方式

2. 进入root用户

3. 设置静态IP

4. show命令集

九、SONiC bsp适配步骤方案

1. platform

第一步：添加驱动

第二步：写sonic_platform。

第三步：添加应用程序和启动脚本。

第四步：编写deb包配置文件

2. device

目录结构：

​​​​​​​

编译步骤