pcupid emac debug SOP

REVISION HISTOR

Revision No.
Description
 Date
1.0
  • Initial release
    		•  06/19/2024
    1.1
  • Update pcupid reset debug and iperf debug
    		•  12/05/2024

    前言: pcupid 只有rmii

    pcupid 只有 rmii, 没有mii。因此需要注意phy的读写, 可以参考pcupid的 Ethernet使用参考 中的 phytool使用 和 phyStatusWR phy读写 debug节点。

    问题一: 短网线网络ping不通

    流程 方法 出口条件 下一步 or 结论 需提供给SWRD的资料 备注 & 相关FAQ
    A 跟正常网络环境交换网线, 做交叉测试 出口条件1: 非网线问题
    出口条件2: 网线问题    		 出口条件1: ==> B
    出口条件2: 结束 ==> 网线问题
    B 在正常网络环境中介入该中转设备(交换机或路由器) 出口条件1: 介入中转设备后网络正常
    出口条件2: 介入中转设备后网络不通    		 出口条件1: ==> C
    出口条件2: 结束 ==> 中转设备问题
    C 执行ping后查看提示 "网络不可达" 还是 卡住 出口条件1: 卡住 ==> 表示网络可达
    出口条件2: 网络不可达 ==> 局域网配置有误, 如网关, IP网段, IP table等    		 出口条件1: ==> D
    出口条件2: 结束 ==> 网络配置问题
    D 方法1: 拔插网线, 查看link up或down的log
    方法2: 读phy寄存器的link状态位    		 出口条件1: link down 或没有link up的log
    出口条件2: link up    		 出口条件1: ==> E
    出口条件2: ==> F    		 通过phy寄存器可以看是否link up
    bank_phy0 offset1 bit2 :
    1: Link is up
    0: Link is down
    phy寄存器读取方法：phytool读取 或 debug节点
    E 用ethtool确认当前速率是否为force 10M
    如果是, 手动切换下MDI/MDIX, 寄存器: bank_phy0 offset 0x43 bit[12:11]
    若value != 2'b11, 则将value设为 2'b11
    否则将value设为 2'b10    		 出口条件1: 当前速率不是10M, 或者执行上述方法后不能link up
    出口条件2: 当前速率是force 10M, 且手动切换下MDI/MDIX后能正常link up上    		 出口条件1: ==> F
    出口条件2: 结束 ==> Auto MDI/MDIX问题    		 提供串口log
    执行以下脚本, 并提供相应log
    p3p-emac-dump-register.sh    		 命令: ./ethtool eth0
    P2 EMAC+internal ephy force 10M下link不上问题
    F mii(片内phy):无需检查
    rmii(片外phy):
    公板: 先检查padmux的对应dtsi, 对应的gpio引脚是否存在冲突 或 配置成其他gpio模式。 如果没有,再检查 eth_mode。
    非公版: 需要根据客户实际的引脚设计检查是否存在引脚被错误复用的问题    		 出口条件1: 流程E link down，且 mii or rmii引脚配置正常
    出口条件2: mii or rmii引脚配置正常
    出口条件3: rmii引脚配置异常    		 出口条件1: 结束 ==> 找SWRD
    出口条件2: ==> G
    出口条件3: 结束 ==> 引脚配置异常    		 提供串口log
    执行以下脚本, 并提供相应log
    p3p-emac-dump-register.sh    		 pcupid eth_mode:
    RIU bank 0x103c offset 0x6e
    eth0: bit[1:0] BGA: 3 QFN: 2
    eth1: bit[7:4] BGA: 2 QFN: 1
    G 敲击ifconfig后, ping一段时间后, 再使用ifconfig查看统计信息
    如果TX packets计数增长量为0, 则 TX 方向存在问题
    如果RX packets计数增长量为0, 或 errors增加, 则为 RX 方向存在问题    		 出口条件1: RX 问题
    出口条件2: TX 问题
    出口条件3: 上述都不符合(都有计数) ==> 可能是网络环境问题    		 出口条件1: ==> H
    出口条件2: ==> M
    出口条件3: 找SWRD分析环境问题    		 ifconfig前后的log
    辅测和板端的抓包信息
    两边的网络配置信息, 如ip地址、mac地址、arp表、路由表等    		 若都没有计数, 可以先排查RX问题, 再排查TX问题
    H 如果rx packets为0, 则为没有counter问题
    如果存在rx error计数, 则为error packet问题    		 出口条件1: 没有counter问题
    出口条件2: error packet问题    		 出口条件1: ==> J
    出口条件2: ==> I
    I rmii(片外phy): 一般不需要调整,有需要可联系phy厂商
    mii(片内phy): 调整driver的驱动能力, 尝试增强tx驱动能力以及调整rx的阻抗
    调整后再次尝试ping看能否ping通    		 出口条件1: 可以ping通
    出口条件2: 无errors计数增加,但仍然ping不通
    出口条件3: errors计数仍然增加    		 出口条件1: 结束 ==> driver能力问题
    出口条件2: ==> H
    出口条件3: 结束 ==> 需要找CAE查看硬件是否存在问题    		 提供测试的串口log pcupid没有MII , 可以先找CAE检查硬件是否存在问题
    MII的相关命令可参考: EMAC Driver Proc Command
    J 1、PC开启wireshark抓包,板子开启tcpdump抓包。
    2、板子pingPC, 观察报文交互, 查看板端是否有发出icmp请求, PC是否有响应的ICMP应答    		 出口条件1: 板子没有icmp报文发出
    出口条件2: pc没有icmp报文发出    		 出口条件1: ==> L
    出口条件2: ==> K
    K 确认 PC/辅测设备 是否有开启防火墙导致板端发送的icmp报文被过滤 出口条件1: 有开启防火墙
    出口条件2: 没有开启防火墙    		 出口条件1: 结束 ==> 关闭防火墙, 可能是防火墙拦截了板端的报文
    出口条件2: 结束 ==> 可能是网络环境问题, 有需要可联系SWRD分析    		 ifconfig前后的log
    辅测和板端的抓包信息
    两边的网络配置信息, 如ip地址、mac地址、arp表、路由表等
    L mii(片内phy): 一般不会有clk出错问题
    rmii(片外phy): 检查 SC_GP_CTRL 的 reg_ckg_emac 相关寄存器值
    如果寄存器值正确则使用示波器查看, 观察REF_CLK波形是否正常(如果有波形的话, 频率是否为50M)    		 出口条件1: phy clk寄存器配置错误或clk异常
    出口条件2: phy clk正常    		 出口条件1: 结束 ==> 找SWRD确认
    出口条件2: ==> M    		 提供测试的串口log pcupid emac0:
    RIU bank 0x1133 offset 0x2a = 0x0004
    RIU bank 0x1133 offset 0x2b = 0x0004
    pcupid emac1:
    RIU bank 0x1133 offset 0x33 = 0x0004
    RIU bank 0x1133 offset 0x34 = 0x0004
    N 找SWRD确认
    O 找SWRD确认
    Q 使用tool读取OTP/Efuse的disable emac bit(不知道方法找OTP owner协助) 出口条件1: 读取结果为00或11 ==> 没有被disable
    出口条件2: 读取结果为10或01 ==> 有被disable    		 出口条件1: 结束 ==> 找SWRD
    出口条件2: 结束 ==> 找SWPM    		 提供OTP读取结果截图

    问题二: 长网线网络ping不通或丢包

    流程 方法 出口条件 下一步 需提供给SWRD的资料 备注 & 相关FAQ
    A 更换一条正常网络环境下的短网线
    查看是否依然存在ping不通
    或者丢包现象有没有好转    		 出口条件1: 依然ping不通 或 丢包现象无好转
    出口条件2: 可以ping通 或 丢包现象好转    		 出口条件1: ==> B
    出口条件2: ==> D
    B 问题是 ping不通 还是 丢包 出口条件1: ping不通
    出口条件2: 丢包    		 出口条件1: ==> C
    出口条件2: ==> G
    C 参考 问题一: 短网线网络ping不通 进行排查
    D 更换正常网络环境下的长网线查看是否依然存在问题
    或者将该长网线接入其他正常的设备查看是否依然存在问题    		 出口条件1: 恢复正常
    出口条件2: 问题依然存在    		 出口条件1: ==> 结束流程, 网线问题
    出口条件2: ==> E
    E 确认网线的长度以及使用场景下的带宽 出口条件1: 符合使用场景
    出口条件2: 不符合使用场景    		 出口条件1: ==> F
    出口条件2: ==> 结束流程, 使用场景超出设计的能力    		 P3P支持
    100M带宽下100米的长网线
    以及10M带宽下250米的长网线
    F 更换设备及网线到直连环境中, 查看是否恢复正常 出口条件1: 恢复正常
    出口条件2: 问题依旧存在    		 出口条件1: ==> 结束流程, 网络环境问题
    出口条件2: ==> G
    G 使用ethtool关闭设备自协商
    将两端设备配置成相同的工作模式    		 出口条件1: 恢复正常
    出口条件2: 问题依旧存在    		 出口条件1: ==> 结束流程, 自协商没生效问题, 找对应SWRD
    出口条件2: ==> H    		 出口条件1: ==> 提供串口log ==> 执行以下脚本, 并提供相应log
    p3p-emac-dump-register.sh    		 ethtool工具使用介绍
    H 检查设备的cpu loading是否正常
    命令: top -d 1
    可以查看进程占用的CPU百分比, 第二行的CPU: 表示CPU的使用信息, 其中 idle 表示空闲资源。idle越少, cpu loading越大(cpu loading = 100% - idle)    		 出口条件1: cpu loading 没有满载
    出口条件2: cpu loading 满载    		 出口条件1: ==> I
    出口条件2: ==> 结束流程, 查看导致loading的程序, 找对应SWRD    		 top -d 1的信息
    在top后的UI界面, 按 1 后的信息    		 某些版本top和常用的不一样, 可以使用命令: busybox top -d 1
    -d 1 表示刷新间隔1s
    I mii(片内phy)可以尝试调整driver的驱动能力:
    增强tx驱动能力 以及 调整rx的阻抗
    调整后看能否ping通/丢包    		 出口条件1: 调整后好转
    出口条件2: rmii(片外phy) 或 片内phy调整后无好转    		 出口条件1: 结束 ==> 驱动能力问题
    出口条件2: 结束 ==> 找对应SWRD排查问题    		 1、提供串口log
    2、执行以下脚本, 并提供相应log
    p3p-emac-dump-register.sh    		 命令:
    echo swing_100 2 > /sys/devices/virtural/sstar/emac0/turndrv ==> 增加100M带宽下 tx驱动能力两个挡位
    echo swing_10 2 > /sys/devices/virtural/sstar/emac0/turndrv ==> 增加10M带宽下 tx驱动能力两个挡位
    echo rx_imp 7 > /sys/devices/virtual/mstar/emac0/turndrv ==> 将rx阻抗设置为7(范围-4~7)

    问题三: 网络带宽不足

    流程 方法 出口条件 下一步 需提供给SWRD的资料 备注 & 相关FAQ
    A 检查测速工具的命令是否正确, 常见问题如下:
    1、iperf 测量udp带宽时需要-b指定最大带宽
    2、iperf2 服务端和客户端都需要加 -u 才可以正常收发udp    		 出口条件1: 命令正确
    出口条件2: 命令错误    		 出口条件1: ==> B
    出口条件2: 结束 ==> 工具使用问题    		 iperf等测试工具执行的server端和client端log iperf3使用参考
    B 1、检查端口的速率和双工模式
    2、检查与对端端口配置的速率和双工模式是否匹配
    3、若对端端口的速率模式不方便查看, 也可通过ifconfig查看是否存在大量error、collision、drop报文确认    		 出口条件1: 一切正常
    出口条件2: 存在异常, 端口配置速率低、两端速率模式不匹配、存在大量错误报文统计等    		 出口条件1: ==> D
    出口条件2: ==> C    		 命令: ./ethtool eth0
    ethtool工具使用介绍
    C 1、 使用 ethtool 固定两端速率和双工模式重新测试 出口条件1: 带宽依然不足
    出口条件2: 带宽正常    		 出口条件1: ==> D
    出口条件2: 结束 ==> 自协商问题    		 1.提供测试过程中的相关日志
    2.现场的网络拓扑情况
    3.协助SWRD复现
    D 检查是否是中转设备(路由器, 交换机)做了影响带宽的qos策略或带宽限制策略导致的带宽不足
    方法: 使用直连方式测试设备带宽    		 出口条件1: 直连测试下带宽依然不足
    出口条件2: 直连测试下带宽正常    		 出口条件1: ==> E
    出口条件2: 结束 ==> 中转设备限速
    E 检查设备以及测试带宽所用的辅助设备(如pc)等是否开启了防火墙
    如果有, 则关闭防火墙重新测试    		 出口条件1: 没有开启防火墙 或 关闭防火墙情况下带宽依然不足
    出口条件2: 关闭防火墙情况下带宽恢复正常    		 出口条件1: ==> F
    出口条件2: 结束 ==> 防火墙原因
    F 在测试带宽过程中, 使用top命令观察系统资源的使用情况, 主要关注:
    1、是否还有空闲内存 (Mem: xxx free)
    2、是否还有空闲cpu (CPU: xx% idle)    		 出口条件1: 系统资源充足
    出口条件2: 系统资源不足    		 出口条件1: ==> G
    出口条件2: 结束 ==> 性能问题    		 1.提供测试过程中的相关日志
    2.执行以下脚本, 并提供相应log
    p3p-emac-dump-register.sh    		 idle 表示空闲资源。idle越少, cpu loading越大(cpu loading = 100% - idle)
    某些版本top和常用的不一样, 可以使用命令: busybox top -d 1
    -d 1 表示刷新间隔1s
    G 1、拔插网线后重新测试
    2、更换一条正常网络下的网线重新测试    		 出口条件1: 带宽恢复正常
    出口条件2: 带宽依然不足    		 出口条件1: 结束 ==> 物理连接问题
    出口条件2: 结束 ==> 反馈SWRD    		 1、提供测试过程中的相关日志
    2、执行以下脚本, 并提供相应log
    p3p-emac-dump-register.sh
    H 尝试更换打流方向或者打流设备
    1、iperf使用-R命令，改变打流方向
    2、更换同型号设备，使用同一个image    		 出口条件1: 带宽恢复正常
    出口条件2: 带宽依然不足    		 出口条件1: 结束 ==> 硬件问题，找CAE排查
    出口条件2: 结束 ==> 反馈SWRD    		 1、提供测试过程中的相关日志
    2、执行以下脚本, 并提供相应log
    p3p-emac-dump-register.sh    		 如果更换打流方向或更换设备后，带宽正常，可以换一个server端或client端设备，以此判断是 原来设备的tx端问题 还是 rx端问题（也可能都有问题）

    问题四: uboot下网络无法使用

    流程 方法 出口条件 下一步 需提供给SWRD的资料 备注 & 相关FAQ
    A 将原本连接设备的网线接入其他网络正常的设备, 测试网络是否正常 出口条件1: 网络正常
    出口条件2: 网络异常    		 出口条件1: ==> B
    出口条件2: 结束 ==> 检查网络环境
    B 1、查看启机log是否打印了"Net: MAC Address xxx"确认
    2、若启机log无相关打印, 则通过执行estart命令执行emac初始化
    3、检查网络是否可用    		 出口条件1: 网络可用
    出口条件2: 网络不可用    		 出口条件1: 结束 ==> 网卡未初始化问题
    出口条件2: ==> C    		 可通过设置环境变量autoestart=1启用启机自动初始化网卡
    C 检查环境变量的配置是否正确 出口条件1: 环境变量配置正确, 且是动态获取ip地址(dhcp)
    出口条件2: 环境变量配置正确, 且是静态ip
    出口条件3: 环境变量配置错误    		 出口条件1: ==> D
    出口条件2: ==> E
    出口条件3: 结束 ==> 正确配置后重新测试    		 Uboot ENV配置参考
    D 检查DHCP
    方法: 更换其他人的MAC地址, 尝试DHCP看是否能ping通PC    		 出口条件1: dhcp无法获取ip 或 依然无法ping通
    出口条件2: 网络正常    		 出口条件1: ==> E
    出口条件2: 结束 ==> 可能是由于ip地址冲突, 检查是否有其他相同MAC地址的设备, 或找 MIS    		 Uboot ENV配置参考
    E 片内phy:无需检查
    片外phy
    1、查看启机log中是否有"Can't get correct PHY Addr and reset to 0", 有该log说明mdio连接异常
    2、使用命令: phy_r 1 , 读取到的数值为全0或全F, 代表mdio连接异常    		 出口条件1: mdio连接异常
    出口条件2: mdio连接正常    		 出口条件1: ==> G
    出口条件2: ==> F    		 调试过程的相关log
    协助SWRD复现
    F 使用命令: phy_r 1 , 检查phy link状态 出口条件1: link up
    出口条件2: link down    		 出口条件1: 结束 ==> 找SWRD反馈
    出口条件2: 结束 ==> 可能是phy有问题, 尝试更换phy或者找CAE排查    		 调试过程log 通过phy寄存器可以看是否link up
    bank_phy0 offset1 bit2 :
    1: Link is up
    0: Link is down
    G 根据客户实际的引脚设计检查是否存在rmii引脚被错误复用的问题 出口条件1: pinmux无错误复用
    出口条件2: pinmux错误复用    		 出口条件1: ==> H
    出口条件2: 结束 ==> 引脚复用错误    		 调试过程log
    H 使用LA或示波器量信号/波形, 观察:
    1、高电平3.3V左右, 低电平0V
    2、波形是否正常无杂波    		 出口条件1: 信号/波形正常
    出口条件2: 信号/波形异常    		 出口条件1: 联系SWRD继续排查
    出口条件2: 结束 ==> 检查电压是否正常、芯片虚焊、引脚被phy端控制等    		 调试过程log 参考 问题五: 新型号 Ephy 或switch网卡适配失败 排查
    1、电压异常可能需要排查跳帽等, 需要联系CAE分析
    2、波形异常, 有杂波, 可能是芯片虚焊, 或者外挂phy在控制引脚。可以尝试phy reset。
    其他可参考wiki: EMAC phy reset

    问题五: 新型号 Ephy 或 switch网卡 适配失败

    流程 方法 出口条件 下一步 需提供给SWRD的资料 备注 & 相关FAQ
    A 检查phy或者switch的引脚与芯片是否物理连接上
    检查有无虚接情况    		 出口条件1: 物理连接正常
    出口条件2: 未正常连接    		 出口条件1: ==> B
    出口条件2: 结束 ==> 物理连接异常
    B 检查连接引脚的pinmux
    确保均已设置成正确mode, 且无占用情况    		 出口条件1: pinmux正常
    出口条件2: pinmux异常    		 出口条件1: ==> C
    出口条件2: 结束 ==> pinmux异常    		 pcupid eth_mode:
    RIU bank 0x103c offset 0x6e
    eth0: bit[1:0] BGA: 3 QFN: 2
    eth1: bit[7:4] BGA: 2 QFN: 1
    C 根据phy手册或switch手册上的reset时序要求, 检查实际配置的reset时序 出口条件1: 时序正常, reset引脚配置正确
    出口条件2: 时序错误, 或reset引脚被占用    		 出口条件1: ==> D
    出口条件2: 结束 ==> reset引脚错误    		 pcupid 的sw phy reset逻辑由于外接反向电路，因此代码内是先拉高再拉低
    pcupid 的reset引脚默认没有连接, 需要补焊电阻,芯片才能控reset引脚
    默认拉低reset引脚保持20ms, 再拉高reset引脚保持50ms
    客户可能会有修改, 需要去确认实际reset时序是否符合要求
    同时需要确认reset引脚选择是否正确, 是否存在pinmux错误复用问题
    pcupid reset引脚值参考
    D 确认是否开启fixed-link
    switch网卡适配 或 不关注phy状态(无mdio等) 需要启用fixed-link    		 出口条件1: 已开启 或 不需要fixed-link
    出口条件2: 未开启    		 出口条件1: ==> E
    出口条件2: 结束 ==> 未启用fixed-link    		 fixed-link phy方案
    E 检查phy/switch提供的clk是否为50Mhz 出口条件1: 是
    出口条件2: 不是    		 出口条件1: ==> F
    出口条件2: 结束 ==> 时钟不匹配导致适配失败    		 phy clock
    F 向phy厂商或者switch厂商确认是否需要更新驱动 出口条件1: 不需要
    出口条件2: 需要    		 出口条件1: 结束 ==> 联系SWRD进一步排查
    出口条件2: 结束 ==> 需要更新驱动    		 调试过程log 适配片外phy

    问题六: 网络频繁掉线

    流程 方法 出口条件 下一步 需提供给SWRD的资料 备注 & 相关FAQ
    A 检查是否由于网线质量导致的频繁掉线
    跟正常网络环境交换网线, 做交叉测试    		 出口条件1: 非网线问题
    出口条件2: 网线问题    		 出口条件1: ==> B
    出口条件2: 结束 ==> 网线问题
    B 检查是否因为网络环境导致
    改为直连测试是否会频繁掉线    		 出口条件1: 直连测试依然频繁掉线
    出口条件2: 网络正常    		 出口条件1: ==> C
    出口条件2: 结束 ==> 网络环境或中转设备问题
    C 检查phy状态寄存器, 查看是否频繁变化, 读取的link状态是否与当前一致 出口条件1: phy状态正常
    出口条件2: 片外phy 且 phy状态异常
    出口条件3: 片内phy 且 phy状态异常    		 出口条件1: ==> D
    出口条件2: ==> E
    出口条件3: 结束 ==> 反馈SWRD    		 调试过程log 通过phy寄存器可以看是否link up
    bank_phy0 offset1 bit2 :
    1: Link is up
    0: Link is down
    phy寄存器读取方法：phytool读取 或 debug节点
    D 检查设备的端口配置(双工模式/速率)是否与对端端口匹配 出口条件1: 不匹配
    出口条件2: 匹配    		 出口条件1: ==> 配置匹配的端口模式后重试
    出口条件2: 结束 ==> 反馈SWRD    		 调试过程log 命令: ./ethtool eth0
    ethtool工具使用介绍
    E 检查连接引脚的pinmux
    确保均已设置成正确mode, 且无占用情况    		 出口条件1: pinmux正常
    出口条件2: pinmux异常    		 出口条件1: ==> F
    出口条件2: 结束 ==> pinmux异常    		 pcupid eth_mode:
    RIU bank 0x103c offset 0x6e
    eth0: bit[1:0] BGA: 3 QFN: 2
    eth1: bit[7:4] BGA: 2 QFN: 1
    F 通过示波器检查phy晶振引脚的波形是否正常 出口条件1: 波形正常
    出口条件2: 波形异常    		 出口条件1: ==> G
    出口条件2: 结束 ==> phy晶振损坏
    G 根据phy手册或switch手册上的reset时序要求, 检查实际配置的reset时序 出口条件1: reset flow正确
    出口条件2: reset flow错误    		 出口条件1: 结束 ==> 反馈SWRD
    出口条件2: 结束 ==> 调整reset flow之后重新测试    		 调试过程log pcupid 的sw phy reset逻辑由于外接反向电路，因此代码内是先拉高再拉低
    pcupid 的reset引脚默认没有连接, 需要补焊电阻,芯片才能控reset引脚
    默认拉低reset引脚保持20ms, 再拉高reset引脚保持50ms
    客户可能会有修改, 需要去确认实际reset时序是否符合要求
    同时需要确认reset引脚选择是否正确, 是否存在pinmux错误复用问题
    pcupid reset引脚值参考