BIOS排错十法之排雷法

                       序
    BIOS排错有否方法可循？有。但从哪学？不知道。自我从事BIOS研发以来，强烈的感觉就是，BIOS有如以前的中医，只能靠传帮带才能学的东西，而这还视乎做师傅的观念，看他愿否教于你。我也就想，或许过不了几天，他也会象中医一样，需要挽救。当然，因为我不在BIOS研发公司，只在外围，所以有此体会。为什么会这样，地球人都知道。
   内地的BIOS工程师，我一直以为，应该叫做BUG工程师。因为，BIOS一直是几家寡头公司在研发，而各厂商都是利用它的源码做一些修补。所以，我也只学到一些排错的方法，只能是一个BUG工程师。
    在公司，已好几年了，每年都要做BIOS方面的培训，而且听众还不只是BIOS工程师，包括那些主板调测维修人员和逻辑设计工程师。这个机会促使我对平时的工作进行总结，并努力着眼于“为什么有故障，怎样解决”。
    为此，始有此排错十法，趁着现在快到年关，起个头将它抛出来，以引得更多有价值的玉。也因为纯属个人总结，望大家不要笑话。

一、 排雷法
初做BIOS的人，首先遇到问题多是：BIOS停了，Debug Code是XX。象这种问题一般是一块主板刚做出来，接上CPU、内存条等必备设备，一开机，停了。或者，刚换了一个新的设备，如内存、显卡等等，开机，也停了，市场已经在卖的主板是不常见的。我将导致BIOS停滞的代码（段）称为“地雷”，踩到地雷了，自然无法往前走了。排雷法，就是设法找到地雷所在，排除它。这里“找”是关键。有人说了，不是有“Debug Code”，有什么好找的。说这话的，大多是我们的主管，他很纳闷，认为我们是在浪费时间。
要使用排雷法，有两件工具需要推荐。一是ROMTER+ROM卡，它的意义在于可以随时修改随时刷BIOS以看效果，一是有双端口监视的DEBUG卡，强调双端口是因为80Port已经被原厂BIOS用了，我们在排雷程中尽量使用另一端口。
现在要施法了，根据Debug Code的指引，我们能找到“丢”（这是AMIBIOS工程师常用的说法，我现在做AMIBIOS，自不能免）出该code的代码行位置，暂称之为A点，这个位置并不一定是“地雷”，但地雷一定在这个位置和下一个debug code丢出来的代码行之间。将下一个位置也找出来，称之为B点。怎么找？文件查找呀，什么FF之类，像VC都可以跨文件查找。AMIBIOS相对好些，在《BIOS研发技术》中公开了其流程，且该流程就是以debug code 为结点，虽说有点过时，但参考价值很大。有了A点和B点，这时大可以使用大学里学的《数据结构》中的“二分法”（谁说大学里学的没用来着？），在A点和B点代码之间均匀的间插一些（不要只局限于两处）你的代码。你的代码也不用做什么，只需要往DEBUG卡的另一端口丢一些你看得懂的数据――也是一种debug code就行。好了，重新编译，写入ROM卡，复位。什么？又停了。当然停了，你还没修改呢。没关系，你仔细看看你的代码所丢出的code，相应的代码行就是一个新的A点，同理也有一个新的B点，以此A、B点，重复前面的方法，如是几次，你就能找到造成BIOS停滞的地雷了。至于找到后如何排雷就没有通用的办法了，你要看此地雷形成的原因是什么，特殊情况特殊处理。
方法说起来很简单，但使用过程还是有几点要注意。
1、你的代码不能随意改变寄存器的值，以不影响原代码执行路径为原则。如果你的代码所在位置可以使用堆栈那就用堆栈保护你要用的寄存器，典型如下（以8位端口为例）：
push ax
push dx
mov al, debug_code
mov dx, port_address
out dx, al
pop dx
pop ax
如果你的端口地址小于100h,那dx都可以不用了，直接
 out 82h, al
如果你的代码还不能使用堆栈，如在bootblock段，那就使用sp（堆栈指针），因为堆栈不能用，该寄存器大多数情况下也就“没有用”。如：
xchg dx, sp
mov dx, port_address
mov al, debug_code
out dx, al
xchg dx, sp
al寄存器在很多代码行间隙是可以被改变而不影响程序执行的。你只要看后随的代码是不是先对它赋值再使用就知道了。
2、BIOS代码是分层结构的，上一层总是不断调用下一层的子过程。在排雷的过程中间插代码时，一次也尽量在同一层，判定地雷不在此层后再继续到下一层使用排雷法。对于文件也可以遵循此规则，先判定是否在同一文件中，如果不是再到另一文件中继续。
3、在找到地雷后千万别忘了抽去你插的“桩”。这一点很多高手都不在意，认为那样对代码没有影响，就让它了。但后来人看到这套源码，会不知所云，就象一条原来平直的高速公路，变成波浪形。

minisoft，阁下说的这些经验，对开发工程师来说，有很大价值。
但是，我个人的经验，真正找到程序停止的位置，才是“万里长征”的第一步。最重要的还是要确定halt的原因，做到这一点有些困难，需要对BIOS和外设有较深的理解。而这个过程恰恰需要经验的积累。

非常支持这种原创经验文章,从点滴做起,善于积累就一定会有提高.对技术壁垒深有同感,相较于美国那些进行Kernel级开发的BIOS厂商,我们是有不小的差距,但这并不是说我们的研发人员就比他们的智商低,实在是所能得到的技术保障有限啊.minsoft能接触源代码已经是很幸运了,象我们这些在后端做主板测试的,遇到板子不亮的时候,就只能靠个Debug Code到网上去查,碰到个运气不好的,查出来还是个Reserved.

我来说一下POST卡,就是可以察看Debug Code的东东,广义上就是能够对PORT80H进行译码的设备,从以前的ISA接口到现在的PCI接口,还有直接集成在了主板上的LED灯的形式,对于一些高端服务器主板,由于没有普通的PCI插槽,都是一些通过桥接的PCI-X,不进行端口的转发,因此又发展出了LPC接口卡和I2C POST卡.
其实有没有卡并不重要,弄一台带锁存的示波器直接抓取丢到总线上的数据,然后从里面慢慢找属于80端口的数据,这叫人工译码吧 :D