以太网PHY寄存器分析

以太网PHY寄存器分析    1

1、以太网PHY标准寄存器分析    2

1.1 Control Register    2

1.2 Status register    5

1.3 PHY Identifier Register    8

1.4 Auto-Negotiation Advertisement Register    8

1.5 Auto-Negotiation Link Partner Base Page Ability Register    9

1.6 Auto-Negotiation Expansion Register    10

1.7 AN next page Register/AN Link Partner Received Next Page    10

1.8 MASTER-SLAVE Control Register    10

1.9 MASTER-SLAVE Status Register    12

1.10 Extended Status Register    13

2、PHY扩展寄存器分析    13

2.1 工作模式控制器    14

2.2端口驱动模式    15

2.3 预加重配置    15

2.4自动协商降格    16

2.5 Auto-Crossover配置    17

2.6 MDI信号边沿速率调整    18

2.7 错误指示寄存器    18



1、以太网PHY标准寄存器分析

PHY是IEEE802.3中定义的一个标准模块,STA(station management entity,管理实体,一般为MAC或CPU)通过SMI(Serial Manage Interface)对PHY的行为、状态进行管理和控制,而具体管理和控制动作是通过读写PHY内部的寄存器实现的。PHY寄存器的地址空间为5位,从0到31最多可以定义32个寄存器(随着芯片功能不断增加,很多PHY芯片采用分页技术来扩展地址空间以定义更多的寄存器,在此不作讨论),IEEE802.3定义了地址为0-15这16个寄存器的功能,地址16-31的寄存器留给芯片制造商自由定义,如表1所示。以下结合实际应用,对IEEE802.3定义的寄存器各项功能进行分析。


1.1 Control Register

寄存器0是PHY控制寄存器,通过Control Register可以对PHY的主要工作状态进行设置。Control Register的每一位完成的功能见表2。


Reset:Bit15控制的是PHY复位功能,在该位置写入1实现对PHY的复位操作。复位后该端口PHY的其他控制、状态寄存器将恢复到默认值,每次PHY复位应该在0.5s的时间内完成,复位过程中Bit15保持为1,复位完成之后该位应该自动清零。一般要改变端口的工作模式(如速率、双工、流控或协商信息等)时,在设置完相应位置的寄存器之后,需要通过Reset位复位PHY来使配置生效。

Loopback:Loopback是一个调试以及故障诊断中常用的功能,Bit14置1之后,PHY和外部MDI的连接在逻辑上将被断开,从MAC经过MII/GMII(也可能是其他的MAC/PHY接口)发送过来的数据将不会被发送到MDI上,而是在PHY内部(一般在PCS)回环到本端口的MII/GMII接收通道上,通过Loopback功能可以检查MII/GMII以及PHY接口部分是否工作正常,对于端口不通的情况可用于故障定位。需要注意的是,很多时候PHY设置Loopback后端口可能就Link down了,MAC无法向该端口发帧,这时就需要通过设置端口Force Link up才能使用Loopback功能。

案例:在S3760-12SFP/GT开发过程中,我们曾经出现过一个故障,其中有一片PHY(88E1145)对应的端口发送的帧出现CRC错误,当时这个问题的排查过程经历和很长的时间,最后得出的结论是RGMII的接口电平配置电阻焊接混料导致故障。我们姑且不去考虑这个案例实际的解决过程,在这里讨论一下如何通过Loopback功能对该问题进行定位。

首先介绍一下S3760交换部分的架构,MAC芯片为98EX126,通过RGMII接口连接到PHY芯片88E1145,MAC通过PCI管理总线连接到CPU。在这个案例中,查看88E1145的资料,其Loopback操作在PCS子层完成,两个方向的Loopback,如下图所示。第一种模式,从MAC经过RGMII发送的帧到达PCS后被Loopback到RGMII的接收通道再送回给MAC(这种模式就是上面所描述的寄存器0 Loopback位控制的Loopback模式),另一种模式,从MDI接收上来的帧到达PCS后被Loopback到MDI的发送通道,这种Loopback模式在IEEE802.3中并没有要求,但是目前常见的PHY都支持该功能。分别做这两种Loopback操作,可以发现第一种Loopback操作之后可以在MAC上检测到CRC错误,而第二种Loopback模式,用SMB从端口砸帧再Loopback回来没有检测到CRC错误,这样我们就可以判断故障应该在PCS以上的部分,并且,两种Loopback模式下PHY的PCS都有再工作,基本上也可以排除PCS的故障。因此可以进一步定位到故障在PHY的RGMII或者MAC上。我们就可以去检查这些部分的相关设计来解决问题了。


要进一步更精确的定位问题,我们还可以去查询MAC芯片是否有类似的端口Loopback功能,如果有则在MAC内部也做一下Loopback观察是否有CRC;如果没有,可以将MAC和PHY的RGMII接口断开,将MAC的RGMII发送和接收通道自己连接起来,将PHY的RGMII发送和接收通道自己连接起来,分别做砸帧测试观察有没有CRC,这样就可以进一步的缩小范围。不过这个S3760的案例有其特殊性,98EX126没有端口的Loopback功能,而MAC的RGMII发送信号直接连接到PHY,中间没有电阻,而且两者都是BGA封装,这两个实验都没办法进行。因此故障排查中需要检查的范围就比较广一点了。但是从中我们我们可以看出,Loopback操作在故障定位中可以起到将各个功能模块隔离定位的作用,虽然这些模块在物理上是集成在一个芯片中的。这种分割隔离的思想在故障定位中是非常重要的。

Speed Selection:Bit13和Bit6两位联合实现对端口的速率控制功能,具体的对应关系祥见表2。需要注意的是Speed Selection只有在自动协商关闭的情况下才起作用,如果自动协商设置为Enable状态,则该设置不起作用;并且,对Speed Selection的修改设置,往往需要复位端口才能配置生效。因此在设置该位置的时候需要检查自动协商的设置并通过Bit15复位端口。

Auto-Negotiation Enable:自动协商(AN)开关。设置为1表示打开AN功能,端口的工作模式通过和连接对端进行AN来确定。如果设置为0则AN功能关系,端口的工作模式通过Control Register相应位置的配置决定。必须注意的是,对于1000BASE-T接口,自动协商必须打开。

Power Down:端口工作开关。设置为1将使端口进入Power Down模式,正常情况下PHY在Power Down模式其MII和MDI均不会对外发送数据。Power Down模式一般在软件shut down端口的时候使用,需要注意的是端口从Power Down模式恢复,需要复位端口以保证端口可靠的连接。

Isolate:隔离状态开关。改位置1将导致PHY和MII接口之间处于电气隔离状态,除了MDC/MDIO接口的信号外,其他MII引脚处于高阻态。IEEE802.3没有对Isolate 时MDI接口的状态进行规范,此时MDI端可能还在正常运行。Isolate在实际应用中并没有用到。并且,值得注意的是,由于目前很多百兆的PHY芯片其MAC接口主流的都是SMII/S3MII,8个端口的接口是相互关联的,一个端口设置Isolate可能会影响其他端口的正常使用,因此在使用中注意不要随意更改bit10的状态。

Restart Auto-Negotiation :重新启动自动协商开关。Bit9置1将重新启动端口的自动协商进程,当然前提是Auto-Negotiation Enable是使能的。一般在修改端口的自动协商能力信息之后通过Bit9置1重新启动自动协商来使端口按照新的配置建立link。

Duplex Mode:双工模式设置。Bit8置1端口设置为全双工,置0则端设置为半双工,和Speed Selection的设置一样,Duplex Mode的设置只有在自动协商关闭的情况下才起作用,如果自动协商设置为Enable状态,则该设置不起作用,端口的双工模式根据AN结果来定。对Duplex Mode的修改配置也需要复位端口才能生效。

Collision Test:冲突信号(COL)测试开关。在需要对COL信号进行测试时,可以通过Bit7置1,这时PHY将输出一个COL脉冲以供测试。实际测试操作中也可以将端口配置为半双工状态,通过发帧冲突来测试COL信号,因此该配置实用价值不大。

1.2 Status register

寄存器1是PHY状态寄存器,主要包含PHY的状态信息,大多数bit的值都是由芯片厂家确定的,每一个bit的功能在表3种已有详细说明。其中指示PHY所具有的工作模式能力的寄存器不再多讲,值得注意的有以下几位。

表3 Status register


Auto-Negotiation Complete:AN完成状态指示位。Bit5指示的是端口AN进程是否完成的状态位。在AN Enable的情况下,Bit5=1表示自动协商进程已经成功结束,此时PHY的其他和Link状态相关的寄存器才是正确可靠的。如果AN进程没有完成,则这些状态信息可能是错误的。在调试以及异常故障处理时,可以通过该位寄存器的状态判断AN是否成功,从而进一步的检查AN相关的设置是否正确,或者芯片的AN功能是否正常等。

Remote Fault:远端错误指示位。Bit4=1代表连接对端(Link Partner)出错,至于出错的具体类型以及错误检测机制在规范中并没有定义,由PHY的制造商自由发挥,一般的厂商都会在其他的寄存器(Register16-31由厂商自行定义)指示比较详细的错误类型。在与端口相关的故障查证中,Remote Fault是一个重要的指示信息,通过互联双方的Remote Fault信息(可能要加上其他的具体错误指示),可以帮助定位故障原因。

Link Status:Link状态指示位。Bit2=1代表端口Link up,0则代表端口Link down。实际应用中一般都是通过Bit2来判断端口的状态。而且,一般的MAC芯片也是通过轮询PHY的这个寄存器值来判断端口的Link状态的(这个过程可能有不同的名称,比如BCM叫做Link Scan,而Marvell叫做PHY Polling。)如前所述,在AN Enable的情况下,Link Status的信息只有在Auto-Negotiation Complete指示已经完成的情况下才是正确可靠的,否则有可能出错。

案例:曾经有发现过一个故障,我司S3760的SFP端口和Cisco设备互联,发现端口Link指示灯已经点亮,但是软件显示的端口状态却是Link down,并且端口也不能转发帧。读取S3760的PHY寄存器,发现Link Status=1,而读MAC的状态寄存器,发现其Link状态位为0,软件就是据此判断端口为Link down的。可以看出,故障的直接原因是MAC和PHY的Link状态不一致。但是为什么MAC和PHY状态不一致呢?读取Auto-Negotiation Complete状态指示寄存器,发现Auto-Negotiation Complete=0,显然自动协商没有完成。检查互联双方的端口配置,我司S3760的配置为AN Enable,而Cisco设备AN是Disable的。这样的配置显然自动协商不可能完成,将我司S3760的端口也配置为AN Disable的强制状态,端口即可以正常Link Up和转发帧了。同时据此信息向芯片制造商方面咨询,对方的答复是,PHY Polling查询PHY状态时,如果端口为AN Enable,则一定要等待Auto-Negotiation Complete=1,才认为PHY的Link status有效。这就可以解释为什么MAC和PHY的Link状态不一样了。

但是,为什么PHY的在AN尚未完成的时候Link status就已经置1了呢?原来3760的PHY有一个配置,1000BASE-X AN Bypass功能,PHY如果在AN过程中没有收到对方的AN信息,则可以跳过AN进程,通过检测Serdes接口上的信号来建立Link。这本来是一个很好的特色功能,可是由于PHY通过1000BASE-X AN Bypass功能来建立Link之后却没有将Auto-Negotiation Complete位置1,和MAC的PHY Polling进程矛盾了,导致MAC和PHY的Link状态不一致。(大家可以实际尝试一下,电口的自动协商同时还定义了一个Parallel Detect功能,可以让一个AN Enable的端口和一个AN Disable的端口建立Link,但是PHY通过Parallel Detect建立Link其Auto-Negotiation Complete位是置1的。)至此,解决的办法就是关闭PHY的1000BASE-X AN Bypass功能,故障就解决了。


Jabber Detect:Jabber 检测指示位。IEEE802.3对Jabber的解释是"A condition wherein a station transmits for a period of time longer than the maximum permissible packet length, usually due to a fault condition"。这一位指示的是Link Partner发送的时间超过了规定的最大长度。值得注意的是,Jabber Detect只有在10BASE-T模式下才有意义,100和1000M模式是没有定义Jabber这一功能的。

1.3 PHY Identifier Register

寄存器2和3存放PHY芯片的型号代码,由芯片制造商自行定义,实际应用中软件通过读取这两个寄存器的内容可以识别PHY的型号和版本,这些内容都是只读寄存器,对PHY的功能没有影响,也不反映PHY的工作状态,实用价值不大。

1.4 Auto-Negotiation Advertisement Register

寄存器4是自动协商的能力通告寄存器,在AN Enable的前提下(见寄存器0),端口根据该寄存器的相关配置将自动协商信息通过FLP在MDI上进行通告。当AN配置为Disable状态的时候,寄存器4的配置将不起作用,端口的工作模式由控制寄存器中的配置决定。寄存器4的详细定义对电口和光口PHY上有不同的定义,其中电口PHY的具体说明如表4A。每个bit的功能已有详细描述,无需赘述。


表4A Auto-Negotiation Advertisement Register(Copper)

Bit12:5对应自动协商广播能力域(Technology Ability Field),每一位分别对应为A[7:0],每一位配置一种工作模式的能力。在实际应用中,如果PHY要支持该种工作模式则对应位置1,若不支持则对应位置0。注意到在这8位能力指示域中,并没有1000BASE-T能力的对应配置位,1000BASE-T的相关配置在寄存器9,MASTER-SLAVE Control Register来完成。

Bit4:0配置自动协商的类型,规范正在发送的自动协商信息遵从何种规范,我们所接触的以太网PHY遵从IEEE802.3规范,Selector Field=0001,该区域不可随意更改(很多PHY将此区域设计为只读寄存器,以免被修改)。

Technology Ability Field

思考:在一个交换机端口上配置Speed 100;Duplex Full;Floecontrol Auto,请问这时候Register 0和Regiter 4的值应该分别是多少?

光口PHY在这里特指千兆光口(1000BASE-X)的PHY,其自动协商通告寄存器如表4B所述。需要注意的是,1000BASE-X的AN除了双工和流控信息之外,并不能协商速率信息,也就是说端口只能工作在1000M模式下。并且,端口的媒介类型(LX/SX)也不能通过自动协商来解决,因此在应用上必须人工保证互联双方的速率、媒介类型的一致性,否则结果将是连接失败,AN对此无能为力。

表4B Auto-Negotiation Advertisement Register(1000BASE-X)


1.5 Auto-Negotiation Link Partner Base Page Ability Register

寄存器5保存的是本端PHY接收到的对端PHY所通告的端口能力,寄存器5的结构和寄存器4基本一致。应用上,寄存器5可以用于检测Link partner的自动协商配置,在端口Link 故障的定位排查中可以发挥重要作用。特别是当Link Partner不是我司设备的时候,其内部寄存器信息我们是无法获取的,这是侯就只能通过寄存器5来获取对方的自动协商信息了。不单单是AN信息,端口的状态信息中所有关于Link Partner状态的指示信息在我们进行故障处理的时候都是很珍贵的第一手资料,通过分析这些信息对我们进行故障定位将有很大的帮助。

1.6 Auto-Negotiation Expansion Register

寄存器6保存了PHY自动协商过程的异常信息,每一位的作用在表5中一目了然。从这个寄存其中我们可以获取到Link Partner子否支持自动协商以及自动协商下一页有没有收到的信息。其中Parallel Detection Fault表示,端口在并行检测进程中出现了错误,这包含了两层意义:首先PHY已经启动并行检测,则Linkpartner不支持AN,再则并行检测不能成功的探测到Linkpartner的连接速率信息。

另外,光口(1000BASE-X)PHY的这个寄存器只定义了bit1和bit2两位,含义和电口相同,见下表。

表5 Auto-Negotiation Expansion Register


1.7 AN next page Register/AN Link Partner Received Next Page

寄存器7和8分别保存了Local PHY和Linkpartner的自动协商下一页信息,AN的下一页功能通常在1000M模式的自动协商下使用,详细地寄存器信息要结合PHY芯片的资料进行分析,本文不作详细讨论。


1.8 MASTER-SLAVE Control Register

寄存器9保存的是1000BASE-T模式的配置信息,控制PHY的AN信息中与1000BASE-T相关的协商信息,以及PHY在1000BASE-T模式下的工作模式。详细信息见表6。


表6 MASTER-SLAVE Control Register


Test mode bits:测试模式控制器。默认配置为000,代表PHY处于正常工作模式。写入其他数值则PHY进入Test模式,在不同的Test模式下PHY在MDI上发送不同类型的信号,以供我们对PHY的发送信号进行评估测试。关于测试模式的详细描述见IEEE802.3 Clause 40.6.1.1.2。

MASTER-SLAVE Manual Config Enable:MASTER-SLAVE强制配置使能位。1000BASE-T运行模式下,互连双方的工作模式必须是一端Master另一端Slave,一般情况下在AN进程中互联双方会自动协商出一端Master另一端Slave。强制的配置则在AN的时候不对MASTER-SLAVE信息进行协商,PHY根据强制的MASTER-SLAVE配置进行工作。这样带来的问题是如果互联双方的配置一样(都是MASTER或者SLAVE)则不能Link up,或者Link up之后也不能正常进行数据收发操作。因此实际应用中最好不要使用强制配置。关于MASTER和SLAVE模式的差异,详见IEEE802.3 Clause 40的相关描述。

MASTER-SLAVE Config Value:MASTER-SLAVE强制配置信息位,在bit11=1的情况下,bit12=1则PHY只能工作于Master模式,bit12=0则PHY只能工作于SLAVE模式。

Port type:端口模式控制位。Bit10控制端口在AN进程中的MASTER-SLAVE优先级,1代表MASTER优先,1代表SLAVE优先。Bit10和bit11的区别是,bit11的配置在强制情况下生效,PHY只能工做与bit11指定的工作模式,而bit10的配置在非强制配置情况下生效,仅仅控制PHY在AN时候的优先级,偏向于Maser或者Slave,但是最终的工作模式看协商的结果,不一定和优先级配置的结果一致。

1000BASE-T Full Duplex/ Half Duplex:1000BASE-T自动协商配置信息。在1.4节中曾经说明,寄存器4的自动协商通告信息寄存器没有关于1000BASE-T的信息,1000BASE-T的自动协商通告信息由这两位进行配置,分别对应全双工和半双工两种工作模式。需要注意的是,1000BASE-T工作模式的自动协商是强制的,也就是要想端口1000BASE-T模式工作正常,自动协商是必须Enable的。否则端口可能出现异常。

思考:一个千兆端口,其寄存器0读到的值为0x0140,请问该配置是正确的还是错误的?为什么?

1.9 MASTER-SLAVE Status Register

寄存器10是1000BASE-T模式的状态寄存器,指示PHY及其Linkpartner的状态信息。详细的状态描述见表7,表格中各个状态位的具体含义说明的相当清楚了,无需赘述。需要注意的是,关于Linkpartner的信息是通过自动协商完成的,而1000BASE-T的协商信息是通过Next Page交互的,因此只有在寄存器6中确认Next Page已经收到,寄存器10的Linkpartner信息才是有效的。否则有可能是错误信息。


表7 MASTER-SLAVE Status Register


Local/ Remote Receiver Status:互连双方的PHY收发器状态信息。在1000BASE-T互联问题的故障诊断中,这是一个比较重要的定位信息,通过这个指示位,可以分别察看本地PHY和对端的PHY收发器是否正常,从而判断出问题出在哪一方身上。

Idle Error Count:Idle错误计数器。1000BASE-T Link up之后,其MDI信号不会有空闲状态。在没有数据帧发送的时候PHY会发送Idle信号。理论上说Idle信号的传输和数据信号的传输是一样的,如果Idle出错则数据往往也会出错,导致收发数据帧中出现CRC。而在出现CRC的时候我们可以通过Idle计数器是否有错来初步判断出错的原因是,如果Idle也有错误,则说明原因可能与MDI相关,如果Idle没有错误,则原因可能在PCS以上的部分,或者是MAC的问题(当然这个判断不是绝对的)。不过需要注意的是,这个计数器是相当"脆弱"的,插拔网线都有可能导致Idle错误,因此在使用该计数器进行判断之前要先保证连接稳定,事先读一次寄存器10让PHY把计数器自动清零。


1.10 Extended Status Register

寄存器15是由PHY厂商在PHY中写入的指示PHY功能的状态寄存器,标明PHY是否具有1000BASE-X或者1000BASE-T的能力,实际应用和调试中实用价值不大。


2、PHY扩展寄存器分析

除了IEEE802.3定义的Register0-15外,Register16-31由PHY制造商自行定义,还有制造商通过分页存储技术扩展的更多寄存器空间,在这些寄存器中制造商定义了很多PHY的功能的控制以及状态指示信息,这些信息对我们在PHY的应用以及故障诊断中有时候可以起到决定性的作用,但是由于这写寄存器不是IEEE802.3标准定义的,因此寄存器的地址以及功能名称在不同厂家的资料中有很大的差异,甚至在同一厂家的不用芯片中也不尽相同,因此下面的讨论只能就某一类的功能应用或者状态指示进行说明,但是其详细的名称和寄存器的地址要结合具体芯片具体分析,这里不能给出一个确切的答案。

目前主流的PHY都通过分页技术对PHY寄存器空间进行扩展,提供更多的寄存器空间来控制PHY更多的功能行为和提供更多的PHY状态指示信息。下面针对我司惯常使用的BCM和Marvell的PHY寄存器分页存储技术进行简单描述,至于分页扩展出来的寄存器空间其具体作用千变万化,在此不作详细讨论。

BCM的PHY绝大多数的寄存器地址空间都是单页地址,通过分页扩展的寄存器集中在0x18和0x1C两个地址上,0x18和0x1C这两个寄存器专门定义了几个bit作为页地址(Shadow Value),其他的bit则是功能位,在不同的Shadow Value这些功能位将代表不同的功能。对0x18和0x1C的读写操作需要先修改Shadow Value,然后才能访问到正确的寄存器空间。以下以以BCM5488S为例,分别说明寄存器0x18和0x1C的访问方法。

寄存器0x18寄存器的bit2:0定义为Shadow Value,在需要读寄存器0x18的某个Shadow时,先要做一个写操作来切换Shadow,这个写操作必须指定bit15=0,bit14:12等于需要访问的Shadow Value,bit2:0=111,其它bit忽略,这时候Shadow切换成功;然后再对寄存器0x18进行读操作即可读到对应Shadow的寄存器值。在进行写操作的时候,则可以直接将bit15:3等于需要写入的数据,bit2:0等于需要写入的Shadow Value即可完成需要的写操作(对Shadow 111的寄存器写操作有例外要求就是bit15=1)。

寄存器0x1C的bit14:10定义为Shadow Value,bit15定义为写使能位。在需要读寄存器0x1C的某个Shadow时,先要做一个写操作来切换Shadow,这个写操作必须指定bit15=0,bit14:10等于需要访问的Shadow Value,其他bit忽略,即可切换Shadow成功,然后再对寄存器0x1C进行读操作即可读到对应Shadow的寄存器值。而如果需要写某个Shadow寄存器,则指定bit15=1,bit14:10等于需要写的Shadow Value,其他bit也置需要写的值,写入寄存器0x1C即可完成。

Marvell的分页方式和BCM有很大的不同,Marvell一般指定寄存器0x16(寄存器0x0-0x1c的页地址)和寄存器0x1D(寄存器0x1E和0x1F的页地址)作为页寄存器,几乎针对每个寄存器都有分页空间,因此在访问每个寄存器之前都必须弄清楚该寄存器的页地址,需要将页地址写入页寄存器中,然后再访问对应地址的寄存器即可。

注意:值得注意的是,软件的定期Linkscan操作常常会"暗中"修改Shadow Value,因此在实际操作中如果发现切换Shadow Value不成功,要关闭Linkscan再尝试一下。在端口异常问题调试的时候,我们经常通过寄存器比较来查找问题的线索,然而正常的软件读命令只会读取默认Shadow的寄存器值,而很多隐藏在其他Shadow中的信息经常被我们忽略了,这个小小的忽略有时候会让你的调试查证工作走很大的弯路,切记!

2.1 工作模式控制器

现在的PHY芯片对外接口形式越来越丰富,在MII端可能有GMII/RGMII/SGMII等,在MDI端则可能有电口、光口等;这些不同的接口使得PHY可以支持各种不同的工作模式。但是在具体的应用中环境,PHY只有设置为设计需要的工作模式才能够正常工作。因此,当遭遇端口不能Link之类的问题的时候,如果外围的电源时钟复位没有检查出什么异常的话,查看一下工作模式配置有没有正确,这是PHY能够正常工作的一个必要条件。

2.2端口驱动模式

这是一个在1000BASE-T模式下需要关心的问题,1000BASE-T需要在Cat5 UTP上传输1000Mbbs的数据,其信道编码采用了PAM-5编码格式,MDI上的信号为5阶电平格式,而其信号幅度和100M模式下一样是+1V,相应的其噪声容限就降低了,尤其在在百米长线连接的时候容易出现Link不稳定、CRC错误等问题。1000BASE-T PHY的MDI信号一般有Class A和Class B两种驱动模式,Class A的驱动能力比Class B要强,因此在百米长线连接时候会表现出更好的性能。但是由于Class A的功耗比Class B要大,因此PHY的默认配置一般都是Class B模式。1000BASE-T端口如果短线连接ok而长线连接有问题的时候可以尝试调整其端口驱动模式为Class A看看性能是否有改善。需要注意的是,有些PHY的这个控制位是隐藏的,在DS中可能差不到对应的配置位,因此就需要仔细阅读勘误表等资料或者向制造商咨询,以获得相应的配置方法。

案例:S5750-48GT/4SFP农行生产所使用的PULSE2×6RJ-45,长线大约只能支持到80米。S5750-48GT/4SFP使用的是BCM5488 PHY,后换到Marvel的PHY88E1145上故障依旧。当时由此判断是PULSE2×6RJ-45品质变异,于是更换成Bel的三合一,生产没多久又出同样的长线问题!看来并不是简单的更换部品就能了事。

在88E1145上做实验的是后注意到一个现象,出长线故障的88E1145端口配置一下Super-link命令,马上就可以解决问题。这个命令的具体操作就是将88E1145的端口驱动模式由Class B改为Class A(以前88E1145也有出过长线故障问题,这样可以解决)。可惜察看BCM5488S的数据手册并没看到关于Class B和Class A的描述,向BCM方面咨询,他们给了一个勘误表,根据说明修改了一下寄存器,问题也解决了。这个寄存器是BCM的保留寄存器,BCM的解释也是修改端口驱动模式的。

2.3 预加重配置

在高速的接口信号传输的时候,由于集肤效应以及电磁辐射的影响,信号的各个分量受到不同程度的衰减(一般是越高频的分量受到的衰减越大),信号经过传输线到达接收端的波形和输出端输出的信号波形并不是"相似的",因此在发送端需要预先对信号的高频分量进行加重,特别是在万兆口应用中,需要通过接插件或背板传输的XAUI/HIGIGA等接口一般都需要对芯片的发送预加重(pre-emphasis)的调整,根据不同的应用环境进行不同的预加重配置,使得接收端获得比较良好的接收眼图。除了PHY芯片,提供XAUI/HIGIGA接口的MAC芯片也有对应的内置PHY,每个端口一般都有对应的预加重配置寄存器,在调试中需要根据眼图的测试结果进行配置。

案例:福建工程学院两台S8606通过万兆线路互联,Ping对端存在约1%的丢包,更换万兆板、线卡槽位无法解决,CLI上显示接口不存在CRC错误。针对这个问题,派黄赞到现场分析,通过分析端口的报文计数器,分析应该是在CM板和线卡之间发生了丢包,在进一步的检查万兆口的配置,发现BCM5676的HG端口发送信号预加重没有按照芯片要求进行配置,导致CM板和线卡之间传输出错。修正预加重配置后问题解决。需要注意的是,BCM5676是一个MAC芯片,提供4个XAUI/HIGIGA端口。但是这些端口都有内置的PHY单元,需要进行正确的配置来确保信号的可靠连接。

思考:有些芯片除了发送预加重(pre-emphasis)的配置外,还有端口的接收均衡控制器(Receive Equalization Control)(如BCM56700芯片),这两个配置有什么区别?分别起到了什么作用?

2.4自动协商降格

由于1000BASE-T连接对UTP线缆的要求是比较苛刻的,而100M连接对线缆的要求就相对宽松,因此目前很多千兆电口的PHY芯片(BCM和Marvell都有,典型代表BCM5488S和88E1240,不过BCM5488S这个功能名叫Ethernet@WireSpeed mode。)提供了一个自动协商降格(Downshift)机制,就是在AN阶段如果协商双方都支持1000BASE-T,但是协商完成后却不能建立1000BASE-T Link,PHY经过一定次数的尝试之后将自动降格到100M协商来建立Link。这本来是个挺好用的功能,但是由于不是IEEE802.3的标准,因此芯片在实现上多少有些不够严谨。而且在实际应用中如果一个千兆口无端被协商成了100M,也容易对客户造成误解。因此该功能最好不要打开(对应的寄存器Downshift Enable位置0)。

案例:还是S5750-48GT/4SFP,BCM5488S,调试中发现,用20厘米短线将端口互联可以正常Link,不过调试中偶然发现将网线频繁的插拔几次,最后接上以后发现端口居然Link状态为100M,当时百思不得其解。于是去测试端口的FLP信号,发现正常时候和故障时候的FLP有差异如波形图所示。很显然PHY的自动协商发送信息自己没有通告1000BASE-T的能力,自然不能Link到千兆。



再去仔细学习了一遍BCM5488S的相关资料,发现了一个Ethernet@WireSpeed功能,这个功能的描述为:When bit 4 = 1, Ethernet@WireSpeed mode is enabled. If the link cannot be established within two to nine attempts (the number of attempts is set by bits[4:2] in register 1Ch, shadow value 00100), the BCM5488S downgrades its advertised abilities and again tries to establish a link. When bit 4 is cleared, the BCM5488S advertises its abilities according to registers 04h and 09h.。也就是说,当两个端口协商的努力失败后(协商次数取决于5488S的0x1C寄存器的bit[4:2],可在2~9次之间调整),5488S会对其工作能力进行降级,即从千兆降到百兆。查到这里问题就比较清楚了,配置一下寄存器,关闭Ethernet@WireSpeed功能问题就解决了。

思考:在这个案例,发现自动协商信息和正常状态不一致是通过测试FLP看出来的,能不能通过分析寄存器来得到这些信息,需要看哪个寄存器,哪一端的寄存器?

2.5 Auto-Crossover配置

所周知,两个以太网端口要正确地建立Link,必须将一个端口的发送信号连接到另一个端口的接收端上(1000BASE-T为同线双向,但是也要考虑线对顺序),否则的话会Link失败。以太网端口的UTP对外接口有两种模式,分别叫MDI和MDIX,对应的,连接用网线也有直连线和交叉线之分。由于一个端口到底是MDI还是MDIX从外观上是看不出来的,为了免除人们调线连接的麻烦,IEEE802.3后来定义了一个Auto-Crossover功能(还有个别名叫Auto-MDIX),PHY可以自动改变其pin脚为MDI或MDIX模式来建立正确的Link。可是这个功能是要依赖FLP信号来实现的,因此在端口关闭AN的情况下Auto-Crossover功能也随之不起作用了。这是一个经常被忽略的问题,大家往往都认为可以Auto-Crossover的PHY可以随意的进行连接,在端口Link不上的时候潜意识中就没有想过线连的对不对!

随着技术的进步,现在很多PHY开发出了不依赖FLP的Auto-crossover功能,可以在关闭AN的情况下依然有效,但是可惜的是这个功能一般有个控制寄存器,更可恶的是默认情况下是不打开的,因此在调试以及应用中要万分注意,看看PHY关于Auto-crossover when AN is disable(当然也有可能是以其他词汇来描述的)的配置是不是配对了。要不然就相当于给自己留了一个陷阱。

案例:内蒙农行,我司M8600-48GT线卡和cisco 7507以太网口卡PA-1FE-TX互联,只能协商出百兆半双工速率,若强制成百兆全双工则不能link。而使用Cisco 2950强制百兆全双工可以link。从现象看,cisco 7507以太网口卡PA-1FE-TX应该是不具备自动协商能力,强制100M Full配置Link不上,有两种可能,一则M8600-48GT的强制配置没有关闭自协商,另一种可能就是MDI连接错误。和软件确认,M8600-48GT强制配置中肯定已经关闭自协商,核对BCM5488S的寄存器配置,发现Force Auto-MDIX Mode这个配置位被设置成0 = Auto-MDIX is disabled when auto-negotiation is disabled,导致不能Link。

思考:

1、这个案例中我们为什么可以推论cisco 7507以太网口卡PA-1FE-TX不具备AN能力?

2、如果不知道寄存器配置,如何方便的验证两个端口不能Link是不是因为没有Auto-crossover功能导致的?

2.6 MDI信号边沿速率调整

PHY的MDI接口信号是直接连接线缆和其他设备互联的信号,信号的好坏直接影响连接的正确性和兼容性,因此此MDI信号需要根据IEEE802.3的指标进行测试。在实际应用中,受实际设计应用环境以及外围器件的影响,MDI信号有可能信号的上升下降时间变差,有些PHY提供了调整信号边沿速率的寄存七,可以根据需要和测试结果对MDI信号的边沿速率(Edge Rate)进行调整,以达到满足测试指标的要求。

案例:S2928G进行100BASE-T的测试,发现信号的上升下降时间超出测试指标要求,最大值达到了5.138ns(指标为3~5ns)。一般来说遇上这种情况我们都会一筹莫展,因为信号是芯片输出来的,而外围的阻容设计MDI接口也是相当经典成熟的设计,没有多少可以调整的余地。可是仔细的去学习PHY芯片BCM5498的相关芯片,发现其Errata中有关于100BASE-T信号测试超标的描述,按照资料的解决方法,修改芯片的寄存器配置信号就达标了。通过这一案例我想我们至少可以得到两点教训,其一是做设计一定要仔细学习芯片的勘误表,否则很多厂家已经发现并提供解决方案的问题我们可能由于无知而投入很大的时间和精力去查,吃力不讨好;其二就是,对于芯片输出的信号,我们并不是无可奈何的!芯片的输出信号受到很多因素的影响,芯片的工作电源、时钟还有内部的寄存器配置都可以改变芯片输出信号的指标,在这一点上我们应该放开思路,而不要因为是芯片内部的事情就望而生畏。

2.7 错误指示寄存器

在前面章节中我们有讨论过,PHY的标准寄存器集有一些错误状态指示信息,比如MASTER-SLAVE Status Register(寄存器10)中有Local Receiver Status,Remote Receiver Status,Idle Error Count等错误信息,充分利用这些信息对我们在调试以及故障处理中定位问题原因将有很大的帮助。除了标准寄存器集定义的这些错误指示信息之外,PHY厂商往往还定义了一些其他的错误指示信息,方便实用者对链路状态进行监测和分析,下面对一些常见的错误信息及其应用进行分析。

CRC Error Count:PHY的CRC错帧统计计数器。本来CRC校验是MAC的功能,但是现在很多PHY也实现了CRC校验的功能,不过这个计数器一般只有8bit,也就是只能统计最多256个错帧。在查证CRC错帧问题的时候,除了察看MAC的MIB以外,还可以辅以PHY的CRC错帧统计计数器,通过综合这些信息来初步判断,出错的位置在PHY以上或者PHY以下。而且,结合Idle Error Count也可以进行判断,一般如果是MDI信号问题导致的CRC会伴随有Idle错误,如果是对方MAC发过来的帧内容有误,则应该不会出现Idle错误。这些信息在故障诊断中可以发挥相当重要的作用。

案例:S2951XG常温烤机测试发现,将端口两两短接起来,从外面引入一个包发现跑不起来,起初以为是软件配置有广播风暴抑制的原因,检查软件配置却没有发现异常,后来读取端口MIB发现有大量的CRC错包。于是判断跑不起来的原因是引入的帧转发后全错掉丢完了,可是为什么出CRC呢?除了MIB信息,读取88E1145的Idle Error Count和CRC error count发现PHY也检测到了CRC错误,同时伴随有大量的Idle Error记录,因此判断故障原因应该和PHY底层信号有关。于是详细核对88E1145底层有关的配置,发现软件对MDI接口的输出信号幅度(VOD)进行了调整,将VOD提高了14%,这个配置是之前为了解决88E1145 D0版本芯片长线性能不过而做的调整,可能已经不适用于S2951XG上的88E1145E1版芯片。将VOD配置修改到默认配置,故障解决。

Transmit Error:发送错误指示。Transmit Error是IEEE802.3描述的一个错误状态,MAC芯片在发送的时候如果出现了某种错误,则通过MII(GMII)的TX_ER信号通知PHY,这时候PHY将在MDI上发送一个特殊的码组代表Transmit Error状态。因此PHY的Transmit Error指示寄存器一般来说并不是指本端错误,而是指PHY接收到了Linkpartner的Transmit Error信息,这时候说明,出错的位置应该是在Linkpartner的MAC上。

案例:我司RSR50主板固化的千兆口和M7600-24GT模块互连的时候,M76的端口会收到一些CRC错包,在客户现场更换H3C的交换机和RSR50互连也一样发现H3C的交换机端口有收到CRC错包。该现象在我们本地实验室重现不出来,给查证工作带来很大的难度。

在初期一度怀疑是RSR50兼容性问题,因此在我们这边按照规范重新进行了一轮全面的兼容性测试,没有发现任何异常问题。然后对RSR50CPU连接PHY的GMII接口进行测试,各信号指标均达标,基本上排除时序临界导致出错的怀疑。在分析M76的端口计数没有什么发现的情况下,从现场读取M76的PHY寄存器回来分析,发现其中一个疑点是PHY的状态寄存器中有指示端口检测到Transmit Error。注意,这里的Transmit Error并不是意味着端口自己发送发现错误,而是LinkPartner通过特殊的编码(如4B5B编码中的/H/码组)发送过来的地表示其发送操作出错的指示。这个操作应该是MAC发现错误以后主动通报的,因此故障怀疑的重点应该从PHY、接口、链路等这些模块转移到MAC层,重点查RSR50的CPU(集成端口MAC模块)设计和配置,最终通过修改CPU的FIFO配置解决了问题。

在这个故障的解决过程中,还走了一些弯路。其实由于对Transmit Error的含义理解不够透彻,当时我们看到这个错误只是以后并没有明确的就开始把重点集中在CPU BCM1250上,当时的想法是为了弄清到底什么样的包出了CRC,于是寄了一台S2924G过去作为抓包之用(S2924G有个功能可以配置端口不进行CRC校验从而将CRC包原样转发出来而不过滤),但是却发现将S2924G连接到RSR50之后没有再出CRC错包了,经分析怀疑S2924G的MAC对Transmit Error的处理可能和M76-24GT不一样,于是将RSR50上GMII接口的TX_ER信号断开,再和S2924G连接,再观察也出现CRC错包了。到此才确定,出错的原因肯定是BCM1250内部出了问题。

这个案例给我们的启示是,对于芯片的错误指示信息,我们一定要弄清楚各项错误只是代表的含义和产生的原因,才能顺藤摸瓜,找到故障的本源。

除了以上列举出来的错误指示,PHY其实还有很多错误指示寄存器可以为我们的故障定位分析提供帮助,比如AN Error,Parallel Detect Error等这些错误信息含义都一目了然,但是在端口故障的时候确实非常重要的证据信息。还有新的芯片可能还提供了其他的错误指示,其含义的作用需要结合芯片的相关资料和标准规范学习研究,在实际工作中加以应用。

来自 <https://blog.csdn.net/Firefly_cjd/article/details/79825869#_Toc199836820>

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 206,482评论 6 481
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,377评论 2 382
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 152,762评论 0 342
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,273评论 1 279
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,289评论 5 373
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,046评论 1 285
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,351评论 3 400
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,988评论 0 259
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,476评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,948评论 2 324
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,064评论 1 333
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,712评论 4 323
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,261评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,264评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,486评论 1 262
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,511评论 2 354
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,802评论 2 345