本文详细介绍了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适配步骤。
目录
一、文档概述
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.git4. 开始编译
一般的编译流程为：
- 安装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的安装
- 准备环境
- 启动优盘
- secureCRT
- 串口线
- secureCRT设置
- 波特率为115200，8N1
- 设置显示模式：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 PRESENT4. 特定于平台的文件
所有关于特定平台的配置文件或诊断信息以及硬件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容器用，配置在启动过程中跳过那些守护进程。如果没有忽略项，这个文件可以没有。更多的细节见设计文档：
示例：
{
"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: YourPaSsWoRd2. 进入root用户
sudo -i3. 设置静态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
}测试/验证：build一个SONiC镜像，并检查Pmon容器的superviosrd 配置文件和start.sh。查看文件中是否已经排除了需要跳过的守护进程，并检查系统启动后是否和预期一致。
- 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
扫一扫
7135
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
