[TOC]
本文主要介绍自发现如何根据版本选择加载的CSR
背景：CSR，全称Component Self-description Record，以软件的角度来定义硬件，用于描述硬件“是什么，有什么，能做什么”，其体现的主要是硬件内部的器件信息、器件互联关系、器件的能力等。目前V3大多数组件依赖CSR文件，又时常疑惑最终使用的是哪份CSR，因此本文将详细讲解自发现选择CSR的逻辑。
一、CSR的来源
目前CSR来源分为BMC内置或从Eeprom读取两种，其中非天池组件不存在Eeprom来源的CSR，仅能通过内置CSR加载解析。判断是否为天池组件主要看Connector对象的IdentifyMode是否为3，为3则是天池组件。
天池标准组件
"Connector_Exu_1": {
"Bom": "14100513",
"Slot": 1,
"Position": 1,
"Presence": "<=/Scanner_Presence_1.Value",
"Id": "",
"AuxId": "",
"Buses": [
"I2c_2"
],
"SystemId": 1,
"SilkText": "exu",
"IdentifyMode": 3,
"Type": ""
}二、目前自发现比较选择逻辑
前置动作
/opt/bmc/sr/csr_version.json中存放环境上（/opt/bmc/sr内）所有内置CSR的格式版本、数据版本和是否合并标志，加载时优先使用csr_version.json内的版本进行比较。自发现在开始发现CSR前，会读取文件里的内容并保存。 注：目前构建时会将软硬件sr完成合并，合并到.sr文件中，并将合并标志置为true。如果加载时选择内置的，则会直接加载.sr文件，而不执行合并动作。因此，如果在这种场景下在环境上直接修改soft.sr是无效的，需要同步修改csr_version.json文件对应sr的Merge字段，或者直接删除该文件。
1. 获取Eeprom CSR版本
注：非天池组件不存在Eeprom的CSR 自发现会根据对应的Eeprom对象读出Eeprom Header数据，读取uid、天池版本、数据版本、校验码、CSR域偏移等信息，然后对Eeprom Header数据进行完整性校验，校验通过则保存Eeprom版本信息。
2. 获取内置 CSR版本
自发现会根据 Bom_Id_AuxId 三段式命名从csr_version.json中读取对应CSR文件的格式版本和数据版本，csr_version.json文件不存在或文件内不存在对应csr的版本信息，会根据三段式命名从/opt/bmc/sr中全量解析CSR获取对应的版本信息。
3. 比较选择CSR
3.1 格式版本预校验
目前CSR的格式版本仅演进到3.00，超过3.00的CSR会被认为是非法CSR，因此在开始比较前会先校验Eeprom的CSR和内置的CSR格式版本是否≥4.00，校验失败的CSR将不会使用。
3.2 选择加载CSR
比较Eeprom的天池版本和内置CSR的格式版本(内置的格式版本仅在比较时默认为3.00)，选择版本较高的，版本一致则比较数据版本DataVersion，选择版本较高的，若数据版本也一致则选择加载内置的CSR。 PS：目前发布BMC时，都内置了当前最高版本的CSR，内置CSR默认3.00是为了兼容内部使用时可能存在的非最高格式版本的CSR，即格式版本1.00的内置CSR，为了兼容1.00的CSR使用，默认内置的格式版本为3.00。（暂时可以认为只比较数据版本）
三、选择后的加载动作
1. Eeprom CSR
1.1 Eeprom CSR加载流程
1）通过Eeprom头的签名区域偏移信息读取签名数据并对签名区域自校验 2）根据UID和GroupPosition获取备份数据 3）检测签名区域数据是否一致，如果一致，直接使用备份的数据 4）签名区域数据不一致，根据签名信息对Eeprom数据进行验签 5）验签通过或验签失败但uid处于白名单内，根据CSR域偏移信息读取全量CSR数据 6）验签通过的将读取的CSR数据进行备份处理 7）CSR加载完成，返回数据 8）若CSR域读取出的格式版本为3.00，即软硬件拆分过渡版本，则执行软硬件数据合并操作
1.2 Eeprom选择及加载过程中可能的失败以及对应的日志信息
1）Eeprom数据读取失败 对应日志关键字：failed to read eeprom 2）Eeprom数据unpack失败 对应日志关键字：failed to unpack eeprom 3）Eeprom的uid为0 对应日志关键字：invalid component unique id 4）Eeprom签名区域偏移为0 对应日志关键字：invalid signature offset 5）Eeprom头数据完整校验失败 对应日志关键字：failed to verify Eeprom header integrity 6）签名区域自校验失败 对应日志关键字：invalid signature 7）计算出的验签的区域长度和实际读取出的验签的区域长度不一致 对应日志关键字：invalid eeprom signature area 8）验签失败且uid不在白名单内 对应日志关键字：failed to verify signature 9）计算出的CSR域数据长度和实际读取的CSR域数据长度不一致 对应日志关键字：failed to read eeprom description record data 10）CSR域头数据内自描述版本数量不为1 对应日志关键字：multi-version description record is unsupported 11）CSR数据域偏移为0 对应日志关键字：description record missing 12）CSR数据域数据格式非json数据格式和gzip压缩 对应日志关键字：invalid description record 13）CSR数据解码失败 对应日志关键字：failed to decode eeprom description record data
2. 内置CSR
2.1 内置CSR加载流程
注：如果在比较的时候进行过全量加载内置CSR，则不会再次加载。 1）根据Bom_Id_AuxId三段式命名从/opt/bmc/sr加载CSR数据，如果是天池组件会将数据版本替换为Eeprom的数据版本 2）CSR加载完成，返回数据 3）csr_version.json中对应CSR的Merged字段不为true及CSR的格式版本为3.00，执行软硬件数据合并操作
2.2 内置选择及加载过程中可能的失败以及对应的日志信息
1）文件不存在 对应日志关键字：failed to open file 2）文件读取失败 对应日志关键字：failed to read file 3）文件解码失败 对应日志关键字：failed to decode file
注：如果来源为Local，且为天池组件，那么对外显示的数据版本将会被Eeprom的数据版本替换，但实际生效的是内置CSR的数据。
3. 软硬件合并
软硬件sr合并的前提是sr的格式版本大于等于3.00且小于5.00（5.00是设备树CSR版本），且环境存在soft.sr文件。软硬件sr合并主要目的是把软件sr和硬件sr里的Objects合并，合并逻辑为不同名的对象直接合并到Objects里，同名对象会将不同名属性合并到对象内，同名对象同名属性优先使用硬件sr的配置。
四、从一键收集的日志信息中知道CSR加载的来源
在dump_info/LogDump/framework.log中搜索关键字start to process sr data, source，可以看到CSR来源哪份文件 其中文件后缀为.sr的表示来源为内置CSR，后缀为.bin的表示来自Eeprom的备份文件，来源为某个Eeprom器件对象的表示来自于Eeprom读取出的CSR数据。
从dump_info/AppDump/hwdiscovery/connectors.txt中，可以看到所有CSR来源、路径、以及Eeprom CSR和内置CSR的版本信息 来源为内置CSR且为天池组件，对外显示的数据版本会被Eeprom的数据版本替换，如上图，内置CSR的格式版本和数据版本均为3.00，但是对外显示的数据版本为Eeprom的1.03。实际使用的数据为内置CSR的。
SourcePath：选择解析的CSR的来源路径 DataSource：CSR来源为内置（LOCAL）还是EEPROM EffectiveFormatVersion： 对外显示的格式版本 EffectiveDataVersion：对外显示的数据版本 EepromFormatVersion：Eeprom CSR的格式版本，不存在或解析失败为NA EepromDataVersion：Eeprom CSR的数据版本，不存在或解析失败为NA LocalFormatVersion：内置CSR的格式版本，不存在或解析失败为NA LocalDataVersion：内置CSR的数据版本，不存在或解析失败为NA 若连接器不在位，即Presence属性为0，则不存在这些信息