最近在调试各类GPU卡，例如获取板卡温度和功耗信息在bmc上做监控散热，或者序列号获取，发现不是所有厂商板卡信息获取过程都严格遵循某一个特定的读写/读指令，基本都是几种合成的，大都经过要么校验，要么通过中断读取获取的，大致快速调试方式如下：
1.OS获取四元组信息
2.适配GPU的csr
sr文件四元组适配好之后(包括chip)，做到板卡已适配好，在busctl下看到添加的chip信息，eg：busctl tree --user bmc.kepler.hwproxy可看见配置的chip信息
busctl introspect --user bmc.kepler.hwproxy /bmc/kepler/Chip/Complex/Chip_xxx 系统获取硬件代理服务的详细接口信息，查看硬件对象提供了块设备I/O操作相关的功能：
1.稍简单的读写：一般情况下例如带Command Code操作码的读写就可直接用ComboWriteRead接口
eg:busctl --user call bmc.kepler.hwproxy /bmc/kepler/Chip/Complex/Chip_xxx bmc.kepler.Chip.BlockIO ComboWriteRead “a{ss}uayuu” 0 3 2 0x2 0x40 4 5（需严格按照a{ss}uayuu格式来写）
其中a{ss}：0 ， u：3(Command Code)，ay:2 0x2 0x40(2个数据0x2 0x40) u：4(readlen) u：5(return len)
2.有的可能涉及到中断读写（涉及对其他寄存器的读，然后查看其状态，再进行写和数据转换，由于过程稍长一般4-5步，可能中间或许有那一步状态判断不对导致数据读不到，直接用busctl 命令就可快速定位）
就可根据以上 bmc.kepler.Chip.BlockIO的方法进行分步读写，之后再在lua中封装成一个整体的函数
1）给其他寄存器写数据
eg:busctl --user call bmc.kepler.hwproxy /bmc/kepler/Chip/Complex/Chip_xxx bmc.kepler.Chip.BlockIO .Write a{ss}uay 0 1 1 0x40
其中a{ss}：0 ， u：1(Command Code)，ay:1 0x40(1个address值)
busctl --user call bmc.kepler.hwproxy /bmc/kepler/Chip/Complex/Chip_xxx bmc.kepler.Chip.BlockIO .Write a{ss}uay 0 2 4 0x12 0x34 0x56 0x78
其中a{ss}：0 ， u：2(Command Code)，ay:4 0x12 0x34 0x56 0x78(4位要写入的data)
以上两个也可以合成一个命令busctl --user call bmc.kepler.hwproxy /bmc/kepler/Chip/Complex/Chip_xxx bmc.kepler.Chip.BlockIO BatchWrite a{ss}a(uay) 0 2 1 1 0x40 2 0x12 0x34 0x56 0x78(具体依据数据手册)
2）读其他寄存器值
busctl --user call bmc.kepler.hwproxy /bmc/kepler/Chip/Complex/Chip_xxx bmc.kepler.Chip.BlockIO Read a{ss}uu 0 2 0x30
其中a{ss}：0 ， u：2(Command Code)，u：0x30(address值)
然后判断寄存器读值的某一位是否是固定的值，是的话才进行下一步，不是的话要么是上一步数据写错误，一般在板卡状态正常的情况下，单独运行busctl命令大都是上一步错误导致的，封装后运行可考虑为还在读取另一相同板卡的数据（根据数据手册判断状态位）
3）读响应数据值，与2）读法类似，此时读出来的数据才是我们想要的数据
以上步骤较繁琐，所以我们可以根据数据手册用D-Bus接口来一步步读取并查看返回值是否正确，而不是直接在general_hardware仓中写然后再根据打印判断信息是否正确
3.确认厂商信息已在gpu_service.lua中描述并建立了板卡的lua文件且已关联
可根据第二步的步骤在lua中进行write read封装（可加打印信息验证），最后出包验证查看打印信息，效率会高很多
扩展：也有板卡涉及crc校验，或许会有写data的拼接，但对于也只多了一步crc校验认证，其核心还是根据数据手册的步骤来一步步写busctl 命令然后对返回的数据进行处理
以上就是处理的大致过程，欢迎各位大佬指正