我是BIOS工程师，我不是解Bug工程师……

近来，一直在思考这样一个问题：何为BIOS工程师？或者说BIOS工程师的工作职责和工作范围究竟如何界定？因为实际工作中，作为BIOS工程师的我们经常会发现自己会作出一些越界的事情——这些事情严格来说根本不属于BIOS工程师的工作范畴。

 

还记得最初做BIOS那时给我的感觉就是整天解bug，一旦发现什么bug，不论是谁发现的bug，我周围那些人都喜欢先去判断是不是BIOS问题，如果他们得出结论：是BIOS问题。好，这个bug就归BIOS工程师了。所以那个时候我拿到一个案子都很紧张，怕有bug，因为发现了bug我也不知道怎么办，只能硬着头皮上。那段时间我工作的时候打交道最多的就是RU，还有芯片组的datasheet，PCI，ACPI spec.

 

因为刚开始都是做Intel的案子，后来要做nVdia，VIA的案子了，我甚至感到害怕，我那时的想法是：一定要对芯片组熟悉才能做好BIOS，而我都没有这些芯片组的datasheet，对这些芯片组也不了解，怎么做啊。

 

现在想想：真觉得自己那时太胆小了。对于新手，多做案子其实对自己帮助很大。

 

 

曾经也在网上看到类似的话，不过那句话还提到了硬件工程师，大意是：其实内地的BIOS工程师，到还不如说是解bug工程师；而所谓的硬件工程师，倒不如说是PCB板工程师。

 

这句话提到了内地，显然，整体来看，台湾的BIOS工程师和大陆的BIOS工程师不是一个级别的。台湾的BIOS工程师大致分为三个层次：Kernel，chipset Porting，OEM，再加上一部分做Tools，各层都有明确的分工，层层之间的接口也比较清晰。

 

在内地，大部分BIOS工程师其实都属于OEM BIOS Engineer，这是一个新的职业，很多从业人员一开始并不清楚究竟如何做OEM BIOS Engineer，大部分情况是拿到代码直接编译，烧到主板上，然后就开始忙起来了，先是测试，发现bug，到处问人（要看别人脸色），跟踪代码（这一步最辛苦，不过倒是加深对BIOS code了解的好途径），然后改code，再烧BIOS，再测试，陷入一个无止尽的循环之中。

 

我不禁想问：这种开发OEM BIOS的模式真的合理么？

 

我们的开发模式其实很简单，是一种基于上游CRB的开发模式。

 

从这个角度讲，如果我要开发一块Board，我首先要搞清楚我这块Board和CRB相比有什么不同，然后，再基于这些不同，考虑如何修改BIOS source code，以得出和我开发的Board相对应的BIOS.

 

说起来简单，实际在做的过程中就会发现困难重重：

 

首先，需要知道我们要开发的board和CRB有哪些不同，这一步一般情况下不难，实在不行自己看电路图；

 

然后是修改code，这一点其实最能检验一个BIOS工程师经验和能力的地方。有经验的BIOS工程师会知道如何改code最省力，最巧妙，而不会造成别的问题。然而即使是有经验的BIOS工程师，也会碰到不知道如何去修改代码的情况，这时，BIOS工程师的能力就显得非常重要了。

 

一个bug的出现，都有它的原因，我把原因分为两类：1.直接原因；2.根本原因

 

直接原因，往往我们从技术上分析就可以得出结论。

 

而根本原因很多，我总结了一下，大致有如下几点：

 

1.对技术了解不深导致；

2.工作不认真导致；

3.上游设计的问题

4.人的问题，或者说是团队配合的问题（BIOS工程师和硬件工程师需要非常密切的配合）

 

以上1，3点其实还是说的是技术问题，2，4点其实是管理问题。

 

文章写到这里，我突然觉得可以用一句话概括：我们开发的时候要用上工程开发的理念。要对得起工程师的称号！