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

作为实现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到正确的设置。

本文出自 “存储之厨” 博客，转载请与作者联系！