多功能PCIE交换机之二:EEPROM恢复与故障排除

  1. 云栖社区>
  2. 博客>
  3. 正文

多功能PCIE交换机之二:EEPROM恢复与故障排除

技术小甜 2017-11-15 15:34:00 浏览711
展开阅读全文
作为实现failover的重要器件,8717PCIE switch既支持virtual switch mode, 也支持basic mode,此外它的DMA、地址窗口也有不同的配置方式。而多块8717卡既可组合成单NT的Active-Passive模式,也可以组合成双NT的Active-Active模式,而这些都依赖于 8717 switch上的EEPROM的正确设置。因此,在调试阶段,工程师常常需要修改它的设置,一有不慎,就可能烧入错误的EEPROM设置,导致PCIE switch无法正常工作,严重的甚至导致BIOS 都无法启动。那么出现这种严重的情况,该如何恢复呢?

首先,我们可以咨询板卡的技术支持,一般来说他们会根据板卡的型号和BIOS的版本号,提供一个recover的BIOS版本。如果实在无法恢复,他们可能会建议需要更换或者维修板卡了。如果已经不在保修期,可能还需要收费。除此之外,我们还可以咨询PLX8717的技术支持,他们通常会碰到多种8717启动或者设置的问题,能提供非常有参考价值的建议。总结这些恢复的方法,不外乎下面几种:
1、通过recover BIOS image进行恢复,这种方法适用于bios image被损坏或者误烧写的情况。以超威的某些主板为例,可以把一个命名为super.rom的BIOS映像放到usb flash盘的根目录下,重启机器后同时输入ctrl+Home键,直至BIOS在屏幕上打印出“enter recover mode...”,然后释放ctrl和 home按键;
2、如果确定是EEPROM烧写错误导致的无法启动,有I2C/SPI烧写器且确认EEPROM芯片能重新焊上去的情况下,可以找到主板上出问题的EEPROM,把它吹下来,放在烧写器里,然后连接SDK或者直接烧写EEPROM芯片;
3、如果上面的条件都不具备,可以找到出问题的EEPROM芯片,根据芯片型号或者板卡原理图确定芯片的SO和GND引脚,利用飞线,在BIOS枚举阶段把它短接,然后等到OS起来,进入操作系统,断开SO和 GND引脚, 利用SDK重新烧写EEPROM。

理论上来讲,这些方法都可以恢复EEPROM,使得系统能够重新启动,但无论是吹下EEPROM芯片还是利用飞线短接SO和GND,硬件上都是比较麻烦的改动,都需要使用烙铁,那么有没有比较简便的方法呢?下面分享下本人针对EEPROM错误设置导致BIOS无法启动的两次经历。

我们使用的是超威最新的服务器,一套服务器上有两个节点,每个节点都有一个8717,我们配置成单NT的模式。第一次发生在把8717 Link Port节点的 Bar2/3 窗口大小从2M到128M之后,发现重启机器后BIOS停留在”Enumearete PCI bus …... 91”这个地方,无法继续往下走。我们尝试了reboot机器、power reset机器都不管用,link port这一端的节点始终无法通过PCI 枚举这一阶段。辛苦尝试了一天没有任何进展,在下班的时候人已精疲力尽,正在快要放弃的时候,突然想起8717 databook里讲到的:对link port节点而言,8717就是一个PCIE设备。也就是说对link port端 的节点,8717可以当作一张卡,那么我就可以通过关掉 virtual port端的节点来“拔”掉这个卡,这样link port端节点理论上可以起来。根据这个推断,马上进行了实验,关掉virtual port端节点,然后重启link port端节点,果不其然,link port端节点顺利启动!接着重启virtual port端节点,通过virtual port端节点的SDK软件更新Link port端bar2/3 size的设置到默认值,再重启link port端机器,发现它和预期的一样成功启动!


大约过了一周之后,由于在更新8717 EEPROM过程中的一次鲁莽大意,系统BIOS又停留在“Enumerate PCI bus … 91”就再没法往下走了,但这次我们没有上次那么幸运,因为这次出问题的设置在virtual port一侧的节点,virtual port所在的NTB就一直在这侧节点上,根本无法通过link port端节点的shut down来“拔”掉virtual port。我们先根据技术支持提供的recover BIOS image 进行恢复,反复尝试了好几次,没有任何效果,这个应该是因为recover BIOS也无法skip掉对NTB virtual port的pci 扫描和枚举。接着尝试bypass 8717 EEPROM芯片的办法,但找了几圈,没有找到芯片所在的位置,所以通过短接EEPROM SO和GND引脚的办法一时也行不通。加之手头上也没有EEPROM/SPI编程器,也不敢冒险把EEPROM吹下来。只好尝试软件的办法。结合之前的工作经验,想到一个可以尝试的办法就是BIOS里禁止掉对8717所在的PCIE root complex的枚举,先确保BIOS能成功启动到OS,再在OS里对PCIE rescan重新扫描出所有的PCIE 设备,这样一定能够检测出virtual port,然后加载相应驱动用SDK更新EEPROM。为此,我在link port端的BIOS的setup menu里寻找disable 8717所在的IIO端口的选项,非常遗憾没有找到,只是看到了一些修改link width/speed设置的选项,虽然感觉希望不大,我还是把它的Link speed从8GT/s修改成2.5GT/s,同时把它16个pcie lan的设置从auto变成4个pciex4,希望这样的修改设会让8717和IIO的link traning 失败。很快做了实验,发现8717所在的IIO port的Link speed果然变成了2.5GT/s,但是NT link port依然存在,这就意味着在virtual port一侧,我也无法在bios里bypass 对8717NT virtual port的PCI枚举了,这样“Enumerate PCI bus ….”的问题势必继续存在。最后没有办法,只好依据8717 support的建议,买来电烙铁,打开主板,寻找8717 EEPROM的位置,开始准备短接EEPROM的SO和GND引脚。非常不巧 的是,我们恁是没找到那块 EEPROM,但柳暗花明又一村,我们意外在8717芯片附近找到了一个disable/enable PLX的手册上根本就没提到的跳线!根据板卡上的说明,我们在跳线pin上插上了延长的导线,引到主机外,先disable PLX,使得系统能够通过BIOS的PCI自检和枚举,顺利进入OS,然后通过延长的导线使能PLX,接着让8717所在的IIO 重新扫描所有下面的pcie设备,顺利找到了8717下面的upstream port,但是没有扫描出virtual port,虽然这时SDK可以发现8717的EEPROM,但我用它烧写的时候发现失败了。分析了原因,可能是因为手动rescan有些设置不太对,为此我重新做了上面的实验,不同的是,这次在BISO启动之后、内核加载之前就重新enable EEPROM,让内核自己去枚举所有的设备。操作系统起来之后,依然可以看到8717的upsteram,但是无法找到virtual port,高兴的是这时候SDK能够重新烧录virtual port端的EEPROM了。我们把他恢复到默认的正确设置,重启机器,再没有看到那个讨厌的“Enumearte PCI bus …..” hang 了。


总结两次恢复8717的经验和教训,第一条教训就是烧写桥片的EEPROM 必须慎之又慎,千万不能冒进、马虎,否则恢复过程相当痛苦和麻烦,第二条就是如果碰到EEPROM导致系统无法启动的问题,首先需要定位出问题的端口:到底是在virtual port还是link port,如果只是在link port,可以通过shutdown virtual port端来让link port端顺利启动,也可以通过仅仅修改virtual port端的EEPROM设置重启后来恢复。当然如果问题在virtual port一侧,需要先找到bypass/skip PLX桥片或者EEPROM的方法,确保系统能够再次进入系统之后,再使能PLX或EEPROM,接着尝试通过软件恢复EEPROM到正确的设置。


















本文转自存储之厨51CTO博客,原文链接:http://blog.51cto.com/xiamachao/1719003 ,如需转载请自行联系原作者


网友评论

登录后评论
0/500
评论
技术小甜
+ 关注