问题描述：
开发过程中碰到在BMC的硬盘背板sr中的改动没有加载上的问题，Connector_SEU_1的IdentifyMode=3，为天池标准组件的识别方式。
查看硬盘背板CSR版本发现为3.11：
判断因为EEPROM中的sr版本更高，所以加载了EEPROM中的sr。所以将BMC中以硬盘背板sr的FormatVersion和DataVersion都改为3.20，然后重启BMC，发现加载的还是EEPROM中的sr。
请问当Connector的IdentifyMode=3时，是选择加载BMC和EEPROM中高版本的sr，还是说固定加载EEPROM中的sr？
framework.log日志里面有日志提示是加在本地的还是eeprom里面的
加载原则就是谁版本大加载谁
经过测试发现 显示默认用的是eeprom中的版本号。但使用的是高版本的sr
BMC后台版本：
实际加载版本：
再往前几行呢，有说本地版本是多少么
改完直接killall skynet试试
你这像是本地CSR都没找到的样子
如果我将Connector_SEU_1配置为"IdentifyMode": 2,那就可以加载BMC的sr了，所以sr文件应该是没问题的
为什么在IdentifyMode": 3的时候没有找本地CSR呢？
试试把/data/opt/bmc/sr/backup/000001030302023936010102.bin这个删掉呢看看
我改成2之后，加载的是BMC的sr，版本是3.09.
然后我又改回3，再重启BMC，发现加载的还是3.09，又不去EEPROM里加载sr了，这时BMC后台/data/opt/bmc/sr/backup/00000001030302023936_010102.bin这个文件还是存在的
这种现象难以理解..
目前我对天池组件的 CSR 更新逻辑也有几点疑问，需要请教：
天池组件CSR 在 Eeprom、VPD 组件和 TaiShanServer2.10.0_CSR 组件中都有存在，是否可以理解为系统会比较三处的 CSR 版本号，然后选择版本号最高的进行加载？
Eeprom 中的 CSR 更新方式是否有两种：
在测试中遇到这样的问题：虽然部件的硬件自描述版本已经更新，但 CSR 中修改的值没有反映到资源树上。请问是否有方法可以确认 CSR 是否真正更新成功？或者这类问题通常该如何定位？
运行态CSR只有 /opt/bmc/sr的，和Eeprom的CSR，两者进行比较
eeprom的CSR只能通过hpm升级的方式烧录，打包到bmc的csr不会烧录到Eeprom里面
尝试把这个bin文件删除后再升级bingo出的CSR的hpm包升级，CSR中修改的值生效了，现在有个疑问，为什么在加载CSR的时候会去这个目录下加载bin文件，而不是去加载我升级的hpm包的内容
看起来你的问题和我一样的，就是没有加载BMC中高版本的sr而加载了EEPROM中的sr。
所以请问社区能否针对这种现象，提供csr具体加载逻辑上的解释。
想起来了，之前做了一个csr读取优化，把内置csr的版本放在了csr_version里面
如果是板子上直接改csr版本的话，还需要把/opt/sr/csr_version.json对应的版本更新了
看到了这个文件，里面sr的属性是：
对，这个是整包构建的时候生成的
FormatVersion是格式版本，只有大变动的时候才会变
DataVersion是数据版本，CSR版本发布的时候就会变更这个版本号
FormatVersion会和BMC版本有强绑定关系，便于后续升级演进使用
①假如硬盘背板接在扩展板上，如果硬盘背板的FormatVersion大于扩展板的FormatVersion，会不会影响加载？
②还有这里的”Merged“：true是什么意思
版本对比都是对比同一个CSR相比，不会CSR之间对比
Merged是内置CSR把soft合并了，减少运行态合并的负担
硬件自发现FAQ | openUBMC 这个FAQ文档可以解答部分问题
