IPMI BOOt OPTION 简介 最近在调试ipmi 相关的boot option功能，大体的功能已经可以支持了。但是还离商业正是版本的功能还差很远。这里之前不了解是怎么个实现原理，现在清楚了，所以还是记下来吧。这个功能主要实现的就是bios和bmc可以联动的管理bios的启动项。服务器里面bmc上电启动后可以通过web界面设置bios的启动项，比如从硬盘，pxe，或者CDRom等方式启动，这样bios在启动过程中，会通过ipmi 命令的方式来获取bmc设置的启动方式，然后根据bootorder中的顺序来调整启动顺序，达到可以通过指定的启动方式来启动。同样bios起来后，可以通过setup界面来调整启动顺序，调整后的结果也要通知给bmc，bmc可以获取到bios一次性或者永久性的启动方式，大体原理就是如此。 下面我们先看看ipmi 规范中关于boot option的介绍：

ipmi boot option 相关的命令 这里面其实就是两个命：

（1）Set System Boot Options Command

这个命令主要是bios 去通知bmc bios设置的启动项。也就是bios端修改boot order后同步给bmc时所使用的命令。在ipmi规范中，这个命令对应的netfc Lun cmd分别为 00,00 08,Request Data部分包含了很多内容，也就是我们要去写的内容。详细的见下图：

上图列出了param 0-5分别代表的内容和含义，这里不做详细的介绍了。需要了解的人可以自己去看，这里我们修改了bios的启动项后主要是要给bmc 发送param 5 boot flags的数据内容。这里需要注意：发送set boot option 命令时，要写数据给bmc，其中request Data中的 param valid bit必须要置0,表示unlock，bios端要去写。

（2）Get System Boot Options Command 命令数据的详细格式如下：

如上图所示，可以通过这个命令来获取对应param 中的数据。

实现代码及原理 （1）bios启动过程中，读取bmc 设置的boot option，并根据boot option 调整boot order 在bios启动过程中，到Bds阶段，会遍历所有的BootOption，并创建BootOrder variable，然后会根据BootOrder中的顺序，来获取第一启动项，并通过variable Boot000#（# 代码启动顺序的id，数值0-N），下面详细的看一下遍历系统启动项，已经注册Boot000#的过程。 首先从BdsEntry为入口： BdsEntry–>PlatformBootManagerAfterConsole–>EfiBootManagerConnectAll/EfiBootManagerRefreshAllBootOption 首先函数EfiBootManagerConnectAll会遍历所有的handle，并根据handle遍历所有的controller，然后依次调用ConnectController函数，将没有执行的驱动执行一次，这样防止遗漏可以作为启动项的设备驱动没有加载。EfiBootManagerConnectAll执行完之后，调用函数EfiBootManagerRefreshAllBootOption，会创建Boot000#每一个启动项的variable。下面详细的看看这个函数的代码：

函数内首先调用BmEnumerateBootOptions获取系统可以作为启动项的设备个数，这个函数很关键，通过这个函数我们可以知道，是如何把uefi下面的启动项都找出来的。下面看看详细的地代码： （如何寻找启动项的代码）

从上面的代码可知，如何判断一个设备可不可以作为启动设备主要分为4中情况： （可以作为boot option设备的条件） 1：支持热插拔的设备，作为启动媒介其安装了blockio，如usb，cdrom等 2：正常的支持blockio的固定的设备作为启动设备，如硬盘等。 3：不支持blockio 但是支持SimpleFileSystem的设备，也可以作为一种启动设备。 4：就是仅仅支持LoadFile protocol的设备，也可以作为启动设备。

根据上面的条件，后代码逻辑就是先找到install blockio的handle，有了handle之后，如果能成功的locate 到blockio那么这个hangle就是正确的，然后通过函数 DevicePathFromHandle (Handles[Index])拿到对应设备的DevicePatch。DevicePath每个设备驱动在创建的时候，都会建立。可以通过DevicePath来区分是什么设备。最后通过DevicePatch拿到对应的启动类型BootType（DeviceType），也可以叫DeviceType。（通过这个BootType就可以区分出是硬盘，还是U盘，还是pxe等启动类型。）这里面关键的函数就是DevicePathFromHandle和BdsGetBootTypeFromDevicePathEx详细的代码实现如下：

从上面的代码可知，将BootOption中的Attributes，Description，FilePath，OptionalData，BootType保存到了Variable中。这里BootType原本是没有的，是我自己加的。通过这个BootType为key去修改BootOrder的。 当EfiBootManagerRefreshAllBootOption函数执行完之后，系统下有几个启动项，以及顺序如何就存在了BootOrder和Boot000#中。这个时候我们就调用我们自己实现的修改BootOrder的函数，来将启动顺序修改成指定的Order。

读取bmc的Boot Option 并根据BootType修改BootOrder 下面是我们自己实现的代码：

由上面的代码可知，主要的函数就是通过函数IpmiGetBootFlags拿到bmc要设置的启动项类型，然后根据启动项类型，去修改BootOrder。 IpmiForceChangeBootOrder函数就是实现修改BootOrder的主要函数，详细的实现如下：

代码逻辑很简单，首先遍历一下当前的BootOrder中的BootOption，找出第一个属性为LOAD_OPTION_ACTIVE的BootType，也就是第一启动项。找到之后判断一下如果这个BootType和之前的不一样，那就调用通知的函数，也就是给bmc发送命令的函数IpmiSetBootFlags，如果发送成功，更新一下对应的variable。至此，bmc和bios联动修改BootOption的功能就完成了。 懂的人知道，这里只是一个初级的功能，还有很多高级功能，boot groups内还能调整优先级的功能等等，还没有实现。服务器功能我们还欠缺很多，我们在补课。。。

注意：系统的启动是根据BootOrder中的数字顺序来决定的。BootOrder variable中存的每一项是一个UINT16的数字，假设BootOrder存的数字为0001000000020003,这一串数字表示有4个启动项，分别为0001/0000/0002/0003,第一启动项为vairbale Boot0001为名字的启动项，第二启动项Boot0000为名字的variable 对应的启动项。而BootNext内保存的也就是000#这个数字，表示下一次系统从哪个启动项启动，如果BootNext存在且数值为0003 那么系统就会从Boot0003的启动项启动。