紫光CPLD升级-级联芯片问题

[l00012320 (kunlun_luzhanghui)]

目前社区最新代码升级紫光CPLD有很多不理解的地方，希望得到帮助。

1. 前置Chip是什么？升级的CPLD配置上没有LeftChip，是通过判断什么关联过来的？
   

   
   
   
   
   

2. 为什么有SMC的情况下，固件的写入需要有额外的Header？这个Header是提供给谁解析的？SMC命令发送的话，应该有BMC框架或者CPLD将i2c命令拼装成SMC，到芯片的时候数据报文不变吧。怎么会需要额外封装一层？
   这里有级联芯片的情况下，只写128字节，而且也是写入到升级的芯片，并没有调用l_chip，非常不理解。
   

   

3. 这个object_pool是什么个概念？调用i2c器件的Write/Read，cmd为什么是在input这里传入？按理说不应该是在Data内一起发送给Chip吗。object_pool这个在代码仓/社区doc仓搜不到相关说明。
   

   
   
   
   

4. 级联芯片的后128字节为什么是这么写入的？两次都是调用的同一个Chip对象的Write方法，前一次传输的Data内包含cmd和Offset，后一次把完整的Data直接剥离后128字节然后直接传输？感觉很奇怪啊。
   

   

[lisongwei]

1 这个是框架提供的对象机制，具体需要框架同事解答，请等待后续回答。
2/4 通常非级联场景下，通过smc执行一次写操作最多可以写入256字节。但是在级联场景下由于前一级smc发送的数据除了实际的data外还需要包含后一级smc的头，所以能写入的实际data少于256字节。与此同时，紫光厂商cpld的手册上说明，升级是必须每个写入动作都写入256字节，不能更少。所以这里采取这种处理方式，拆分256字节的数据，自行拼接成cpld所需的数据流，分两次写操作进行写入，此时cpld会把这两次写入当成一个写入动作处理，从而满足厂商的要求。
3 object_pool是sdk组件提供的接口，用于封装需要发送给smc的数据

[l00012320 (kunlun_luzhanghui)]

1. l_chip的判断依据是什么，明明没有SMC的路径（见话题截图，拓扑路径上不经过SMC），是怎么判断影响出来的？
2. 有没有object_pool的详细文档或者解析？还是想了解这部分是怎样作为参数和传递的。

[Heisenberg]

object_pool是一个硬件访问期间管理临时参数的对象池。这里的data还不是最终下发chip的data，write接口会对input的参数做其他处理。

[l00012320 (kunlun_luzhanghui)]

这个input参数做处理有明确的规则吗？想知道哪些参数会被下发到Chip上去，方便我们做控制。

另外

1. l_chip的判断依据是什么，明明没有SMC的路径（见话题截图，拓扑路径上不经过SMC），是怎么判断从SMC出来的？这个会影响我们新机型直通i2c的升级，要看下是SR配置的有问题，还是默认都走的smc，只能通过新增一个字段来进行区分？

[Heisenberg]

下发到chip的参数包含new方法第二位之后的入参

[l00012320 (kunlun_luzhanghui)]

l_chip的判断依据是什么，明明没有SMC的路径（见话题截图，拓扑路径上不经过SMC），是怎么判断从SMC出来的？这个会影响我们新机型直通i2c的升级，要看下是SR配置的有问题，还是默认都走的smc，只能通过新增一个字段来进行区分？

[chenshengfan]

input参数可以具体见：hwproxy/src/lualib/object_pool.lua这个文件-代码预览-hwproxy:基于用户态驱动的硬件访问代理项目 - AtomGit

[chenshengfan]

l_chip只在CSR中有配置Pca9545、I2cMux、JtagMux的情况下才会有

[l00012320 (kunlun_luzhanghui)]

紫光CPLD升级有个地方不太理解想确认一下。就是为什么升级CPLD完成以后会去触发休眠动作？标准规范里没有这个动作啊。