BCM55524驱动开发摘要

BCM55524驱动开发摘要

BCM55524芯片是博通合并TK3723的一款EPON OLT局端芯片，无驱动包，需要自研开发。以下是其驱动开发过程的一些要点备忘录。

驱动包的架构设计

驱动包的要点

1. R2.4适用于TK3723，开发文档包含概念解释及消息格式2部分；

2. R2.6适用于BCM55524，兼容TK3723；开发文档仅包含消息格式部分。

3. RPC对象：
   OLT对象，主机控制通道收发，应该每个OLT有一个RPC锁，来保证一个OLT同时只能处理一个调用；
   ONU对象，主机控制通道收发，应该每个ONU有一个RPC锁，来保证一个ONU同时只能处理一个调用；
   CMC对象，主机控制通道收发，应该每个CMC有一个RPC锁，来保证一个CMC同时只能处理一个调用；

4. TK3723的LocalBus是16位的总线；是小字节序；

5. PON的GPIO设置；光参数设置；光功率参数设置。

6. OLT和ONU的升级；

7. OLT和ONU的数据通道设置；

8. OLT和ONU的数据转管理通道设置；

9. PAS_SOFT的RM底层使用PAS_send_frame()走数据通道；CTC底层使用PAS_send_oam()走管理通道；GW的OAM底层使用PAS_send_frame()走数据通道。

10. TK3715是外部CPU管理模式，依靠3219来外部管理ONU自身。所以，3219上的TkOnuSDK，就是ONU的API实现；负责响应OLT的远程OAM调用；包括CTC的OAM调用。
    因此，对于CMC：3218、3219的管理，也是OAM通道。效率可能比ONU更高！！！即，OLT不与3715直接通信！！！

    域、目标的重新设计：一个TK3723核，只创建一个域；ONU目标和CNU目标共存一个域；
    下行域规则，可以根据SVID来针对性服务于CNU；
    OLT的QinQ，可以用端口级规则实现。
    这样，就没有了ONU域及CNU域的区分，只有ONU目标与CNU目标的区分。
    域里，自动添加2个CNI的Dest。
    为了兼容现有的PON上的广播抑制比，域里只创建一条Flood Path，方便设置其SLA。
    LLID现在默认150，最大扩展到256（msg:368,369）【Person默认255】
    LLID用户可配？？？【YES，从1开始】
    DEST的删除，要保证引用为0；
    一个DEST，增加新Link或新Path，需要删除再重建；
    一个DEST，增加新规则，则无需删除；

11. R260版本，不支持C-DOCSIS；表现为：CMC注册消息里CNU_NumMax为0；且其LLID都是一对一对分配的。
    R263版本，支持C-DOCSIS；表现为：CMC注册消息里CNU_NumMax为200; 且其LLID都是累加1分配的。

12. 注意：下行广播包，不会进入任何Dest对象，因此，Dest的下行规则，只需考虑下行单播包。

13. tftp最后一个发送包，有可能收不到ACK；则认为超时也是正确的。

14. 发现了TK的升级全过程的BUG：

    1. 每次收取512字节，全在内存暂存；并没有写Flash；立即回复ACK；

    2. 收取不足512字节，认为文件结束，整体写入Flash，之后，才回复ACK。
       在操作1K的Person和60K的boot这二个文件，因为写Flash很快，最后一个ACK在三秒内可以回复过来。即，ftp结束，则Flash操作结束。可以立刻开始下一个文件的升级。
       在操作700K的app，因为写Flash需花费20秒，最后一个ACK必定超时。则ftp超时结束后，Flash操作未结束，则对新的WRQ则返回无资源的响应。

       所以，应该先升级Person和boot，最后升级APP，且超时结束ftp后，应该定时查询其Flash状态，最后才能关闭ftp会话。

    3. 每升级完一个文件，需要重新TkCmdSetTftpSessionParameters一次之后，才能开始下一个新的文件升级。否则，第二个文件的WRQ虽然可以成功，但是后续第一个包的发送，就会被返回错误。

    4. 每升级完一个文件，TkCmdUpgradeDownloadOltFirmware消息直接继续下一个文件的WRQ即可，无需重新连接OLT。但是，对于app文件，必须等到其20多秒的Flash升级后的ACK响应后，才能继续下一个WRQ。

15. TkCmdSetLinkOamRateControl的文档说明，有严重错误。在E264上，此命令的参数为0:0，则OAM信道被彻底关闭。与文档的OAM不限速的说明，完全相反。

16. Tk芯片的上行带宽，需要设置2处SLA:DBA的SLA；上行接收队列的SLA（之前都漏掉了此处的设置，一直为1G设置即可）;
    下行带宽，只需设置1处SLA:下行接收队列的SLA。

17. Tk通信规范：
    发包原则：
    谁发命令，谁等待；发送流程只提供一个等待结构体，提供阻塞等待响应的服务。
    收包原则：
    收包处理3层次，应该至少3个优先级从高到低的任务来保证：【可见，层次化通信，较之扁平化的巨大优势。】
    1. OLT芯片与Host之间的信道，要保证接收响应帧的无阻塞快速处理；
    2. ONU芯片与Host之间的OAM信道，要保证接收通信事件帧的无阻塞快速处理；
    3. 事件、警告之类的事务处理，可阻塞的逻辑处理。

18. TkRule的规范：
    1. TkRule的Entry，是按优先级顺序依次生效的，冲突的Entry则被忽略；
    2. TkRule的Entry，Action里修改OutputField的，都不能独立生效，因为它们修改的OutputField，必须是AddVlanTag操作输出的新Tag;
    3. SetCos类的操作，都内含了AddVlanTag操作，所以可以增加OutputField的修改动作；其它凡是不含AddVlanTag的操作，均不能与OutputField配合。
    4. 一个Entry里，同一位置的OutputField，只能修改一次；可以在后续的Entry里，继续新的修改。
    5. Rule的64位条件值，从最小符号位开始生效匹配，LeftMask必须过滤掉无效位，RightMask一般都为0【注:64位操作数，C编译器不能移位或其他位操作】

19. 关于OLT的OAM默认速率消息：0和1的文档，关于最小速率的说明，是错误的；代码里的注释是正确的。与LinkOam的速率限制的最小、最大速率是一样的，除了单位差10倍。

20. 在B222上，测试验证已解决。证明之前OAM通道过于窄小：PMC的OAM通道只需打开ONU侧的OAM速率限制即可；而BCM的OAM通道，还需打开OLT侧的OAM速率限制。

21. Tk测试空闲光功率为1；PMC测试空闲光功率为2、3；
    发现2个PON，都有读到I2C的空闲光功率为0的情况，此时光功率转换值为-214748364.7；值本身没有问题，问题在于显示错误。
    发现TkSDK的log10函数，由于没有声明函数参数原型，导致输出为正数。PasSoft和产品代码，都有正确的原型声明，则无此问题。
    硬件测量发现：Tk单Link收集一次光功率后，此Trigger始终存在。需要软件消除。否则，空闲接收测量，可能会被Link的结果覆盖。

22. BCM55524注册Cortina的ONU时，需要至少50米的长光纤，否则下行丢包。

23. BCM55524在E264版本，光功率低于-20db，则上行打950MB则丢包；R264则低于-25db才丢包。