PCIe插卡的I2C读写怎么调试

Hardware SIG
1

我在Riser卡接了一张PCIe卡，它的MCU地址为0x30(7bit)，在别的设备使用i2ctransfer验证读写是正常的
image
使用该卡的四元组信息配置了CSR：14140130_99994001_99994001.sr

image
image455×787 10.8 KB

可以加载Chip_MCU，但使用hwproxy组件提供的WriteRead方法读写报错：
image
image1209×112 8.71 KB

想问一下，bmc.kepler.Chip.BlockIO提供的ComboWriteRead和WriteRead应该怎么正确使用
image
image1003×789 49.5 KB

i2c读取数据，参数超出范围
Hisport性能上限咨询
bmc.kepler.Chip.BlockIO Read/Write接口疑问
2
  • 首先需要确保MCU的Chip对象配置正确，包括Address，AddrWidth，OffsetWidth等属性。
    从图中的配置来看，Address配置是错误的，应当为48（对应0x30）。AddrWidth和OffsetWidth需要根据实际地址和访问偏移地址的宽度配置不同的字节宽度（1到4字节）。
  • 对于bmc.kepler.Chip.BlockIO提供的接口，可以参考资源树接口定义，里面有详细的接口描述和参数说明，链接如下：
    GitCode - 全球开发者的开源社区,开源代码托管平台
    简单来说：
    • 相同点：WriteRead和ComboWriteRead都是在一次请求内完成先写入后读取的操作
    • 不同点：
      • WriteRead是先在特定偏移地址（0xffffffff）写入指定数据，再从特定偏移地址（0xffffffff）读取指定长度的数据；
      • ComboWriteRead先在指定的偏移地址写入指定数据后，再从指定偏移地址读取指定长度的数据。
3 
busctl的方式：
busctl --user call bmc.kepler.hwproxy <path> bmc.kepler.Chip.BlockIO ComboWriteRead a{ss}uayuu <a{ss}: ctx> <u: req_cmd> <ay: req_data> <u: rsp_cmd> <u: rsp_len>
mdbctl的方式：
mdbctl call <object> bmc.kepler.Chip.BlockIO ComboWriteRead <a{ss}: ctx> <u: req_cmd> <ay: req_data> <u: rsp_cmd> <u: rsp_len>
  • path：待访问Chip的资源树路径，一般为/bmc/kepler/Chip/Complex/<object>，object为环境中芯片的对象名
  • ctx：RPC的通用上下文，可直接填0
  • req_cmd：表示读/写请求，取值0x20
  • req_data：请求数据
  • rsp_cmd：表示读/写响应，取值0x21
  • rsp_len：响应长度。使用时，命令的实际长度小于响应长度时使用0xff填充，大于时进行截断
1 个赞
4

地址0x30是7bit地址，Address应该是写8bit地址吧，我从96改成48反而无法访问了

5

查看错误码含义
使用公式ret_code = (reg_value & 0xFA) | 0x100反算出寄存器值，从而确定错误类型。

  • 例如：错误码290对应的寄存器值为0x22（即二进制00100010），表示HiSPort总线读写操作未完成，确保访问地址正确的前提下，通常是硬件链路不通的问题。

    发送FIFO已满（位7）：值为0，表示I2C控制器的发送FIFO未满。
    时钟拉伸（位6）：值为0，表示读写期间未出现时钟拉伸。
    ACK校验错误（位5）：值为1，表示读写时ACK校验出现错误。
    总线异常拉低（位4）：值为0，表示读写启动时未检测到总线异常拉低。
    从fifo取数据超时（位3）：值为0，表示从fifo取数据时未出现超时错误。
    命令帧结束标志（位2）：值为0，表示命令帧未结束。
    读写出错（位1）：值为1，表示I2C读写出错，汇总了BIT[6:3]的错误。
    操作完成（位0）：值为0，表示此次I2C读写操作未完成。

6

对应的总线配置是否正确呢？可以通过一键收集，查看AppDump中hwproxy组件的拓扑信息topology.txt，确认对应的总线是否与i2ctransfer操作的总线id一致。

7

HisPort总线有直接调试的工具吗，类似i2ctools这种

8

正常发i2c命令就可以我理解，hisport是底层机制，应该是不感知的

9

暂时还没有

10

image
image713×233 25.1 KB

根据SMBus规范，Block Write - Block Read Process Call过程没有rsp_cmd，当前提供的接口无法实现，有什么解决办法吗

11

Block Write - Block Read Process Call过程没有rsp_cmd，当前提供的接口无法实现 ---- 这个问题可以补充描述一下吗，没有特别理解

12

当前提供的Read、WriteRead、ComboWriteRead读之前其实都是发了一个byte的offset再读，但是SMBus的Process Call是不发offset直接读

13

您好，请教一下，问题：不清楚以下查询功耗参数的具体含义。

busctl --user call bmc.kepler.hwproxy  
/bmc/kepler/Chip/Complex/Chip_Dmini_0101010109   
bmc.kepler.Chip.BlockIO ComboWriteRead  a{ss}uayuu 
0 0x20 0x0e 0x0c 0x80 0x00 0x04 0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x00 0x87 
0x21 32

根据带外管理文档：

image
image559×677 36.8 KB

尝试理解命令：0x20是读/写请求，0x0e应该是请求数据的第一个字节，0x0c 0x80是什么意思呢？0x00 0x04应该是opcode，0x00 0x00 0x00 0x00应该是offset，0x87又是什么意思呢？

14

@zybwh @caiyesheng_b48v3 @chenghaoyang 大佬们可以解答一下吗？

15

0x80对应LUNFlag，bit7=1，对应到80
0x0c是请求体长度， 0x80 0x00 0x04 0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x00 0x87 – 13个，对应0x0c
这个是smbus的报文发送格式，一般在前面章节会有写的

1 个赞
16

0x00 0x04应该是opcode

还有你说的opcode不太准确，一般smbus都是小端模式，所以应该是 0x04 0x00 才是opcode。就比如length对应的0x02 0x00 0x00 0x00，不是0x20000000，而是0x00000002

2 个赞
17

目前是1711做主机发的时钟，从机发应慢产生了时钟延展，在从机产生时钟延展后进一步产生NACK信号，通信自然终止，无错误码产生。

image
image1258×417 6.05 KB

f288474b25aed7c347612199acebdca3
f288474b25aed7c347612199acebdca31071×656 87.9 KB

19

1711的i2c驱动在从机产生时钟延展的情况下，未检测总线状态而继续发出时钟，之后的第9个时钟，从机认为是第8个时钟未回复ack，1711又认为自己没有收到ack正常结束了通信，请问驱动是否可以调整，1711在做主机发送时钟之前需要检测总线的状态，有调整驱动的渠道吗

20

image
image577×325 29.9 KB

这条指令总共有四个输入参数，0x20应该是写入的offset，那么0x0e 0x0c 0x80 0x00 0x04 0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x00 0x87应该是indata，0x87是PEC，请问这里的0x0e是什么意思？

image
image1450×819 110 KB

22

0x0c 0x80 0x00 0x04 0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x00 我理解0x0c是byte count，data byte1~N为0x80 0x00 0x04 0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x00，PEC为0x87，0x20为offset（command code）