介绍一个简单的倒计时关闭 Console 程序的方法，下面在 VS2015 下编译通过：
#include "stdafx.h"
#include <conio.h>
#include <windows.h>
int main()
{
int j = 0;
while ((!_kbhit())&&j<50) {
printf("\n no key pressed. %d", j);
Sleep(1000);
j++;
}
_getch();
return 0;
}
书接上回，下面的语句输出了第一条 Debug Log，它位于 SecMain.c 中：
DEBUG ((DEBUG_INFO,
"SecCoreStartupWithStack(0x%x, 0x%x)\n",
(UINT32)(UINTN)BootFv,
(UINT32)(UINTN)TopOfCurrentStack
));
接下来就使用下面的语句跳转到SecStartupPhase2中：
//
// Initialize Debug Agent to support source level debug in SEC/PEI phases before memory ready.
//
InitializeDebugAgent (DEBUG_AGENT_INIT_PREMEM_SEC, &amp;SecCoreData, SecStartupPhase2);
这个函数位于 \MdeModulePkg\Library\DebugAgentLibNull\DebugAgentLibNull.c，从代码上看到就是一个跳转而已：
/**
Initialize debug agent.
This function is used to set up debug environment to support source level debugging.
If certain Debug Agent Library instance has to save some private data in the stack,
this function must work on the mode that doesn't return to the caller, then
the caller needs to wrap up all rest of logic after InitializeDebugAgent() into one
function and pass it into InitializeDebugAgent(). InitializeDebugAgent() is
responsible to invoke the passing-in function at the end of InitializeDebugAgent().
If the parameter Function is not NULL, Debug Agent Library instance will invoke it by
passing in the Context to be its parameter.
If Function() is NULL, Debug Agent Library instance will return after setup debug
environment.
@param[in] InitFlag Init flag is used to decide the initialize process.
@param[in] Context Context needed according to InitFlag; it was optional.
@param[in] Function Continue function called by debug agent library; it was
optional.
**/
VOID
EFIAPI
InitializeDebugAgent (
IN UINT32 InitFlag,
IN VOID *Context, OPTIONAL
IN DEBUG_AGENT_CONTINUE Function OPTIONAL
)
{
if (Function != NULL) {
Function (Context);
}
}
继续在 SecMain.c中执行SecStartupPhase2() 函数，这个函数负责找到 PEI Core 的 Entry Point
/**
Caller provided function to be invoked at the end of InitializeDebugAgent().
Entry point to the C language phase of SEC. After the SEC assembly
code has initialized some temporary memory and set up the stack,
the control is transferred to this function.
@param[in] Context The first input parameter of InitializeDebugAgent().
**/
VOID
EFIAPI
SecStartupPhase2(
IN VOID *Context
)
其中的跳转代码如下：
//
// Transfer the control to the PEI core
//
(*PeiCoreEntryPoint) (SecCoreData, (EFI_PEI_PPI_DESCRIPTOR *)&mPrivateDispatchTable);
其中 PeiCoreEntryPoint 类型是 EFI_PEI_CORE_ENTRY_POINT ，定义可以在 \mdepkg\include\pi\PiPeiCis.h 看到：
/**
The entry point of PEI Foundation.
This function is the entry point for the PEI Foundation, which
allows the SEC phase to pass information about the stack,
temporary RAM and the Boot Firmware Volume. In addition, it also
allows the SEC phase to pass services and data forward for use
during the PEI phase in the form of one or more PPIs. These PPI's
will be installed and/or immediately signaled if they are
notification type. There is no limit to the number of additional
PPIs that can be passed from SEC into the PEI Foundation. As part
of its initialization phase, the PEI Foundation will add these
SEC-hosted PPIs to its PPI database such that both the PEI
Foundation and any modules can leverage the associated service
calls and/or code in these early PPIs.
@param SecCoreData Points to a data structure containing
information about the PEI core's
operating environment, such as the size
and location of temporary RAM, the stack
location and the BFV location.
@param PpiList Points to a list of one or more PPI
descriptors to be installed initially by
the PEI core. An empty PPI list consists
of a single descriptor with the end-tag
EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST.
As part of its initialization phase, the
PEI Foundation will add these SEC-hosted
PPIs to its PPI database such that both
the PEI Foundation and any modules can
leverage the associated service calls
and/or code in these early PPIs.
**/
typedef
VOID
(EFIAPI *EFI_PEI_CORE_ENTRY_POINT)(
IN CONST EFI_SEC_PEI_HAND_OFF *SecCoreData,
IN CONST EFI_PEI_PPI_DESCRIPTOR *PpiList
);
接下来的跳转进入\MdePkg\Library\PeiCoreEntryPoint\PeiCoreEntryPoint.c 中的ModuleEntryPoint()
/**
The entry point of PE/COFF Image for the PEI Core.
This function is the entry point for the PEI Foundation, which allows the SEC phase
to pass information about the stack, temporary RAM and the Boot Firmware Volume.
In addition, it also allows the SEC phase to pass services and data forward for use
during the PEI phase in the form of one or more PPIs.
There is no limit to the number of additional PPIs that can be passed from SEC into
the PEI Foundation. As part of its initialization phase, the PEI Foundation will add
these SEC-hosted PPIs to its PPI database such that both the PEI Foundation and any
modules can leverage the associated service calls and/or code in these early PPIs.
This function is required to call ProcessModuleEntryPointList() with the Context
parameter set to NULL. ProcessModuleEntryPoint() is never expected to return.
The PEI Core is responsible for calling ProcessLibraryConstructorList() as soon as
the PEI Services Table and the file handle for the PEI Core itself have been established.
If ProcessModuleEntryPointList() returns, then ASSERT() and halt the system.
@param SecCoreData Points to a data structure containing information about the
PEI core's operating environment, such as the size and
location of temporary RAM, the stack location and the BFV
location.
@param PpiList Points to a list of one or more PPI descriptors to be
installed initially by the PEI core. An empty PPI list
consists of a single descriptor with the end-tag
EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST.
As part of its initialization phase, the PEI Foundation will
add these SEC-hosted PPIs to its PPI database, such that both
the PEI Foundation and any modules can leverage the associated
service calls and/or code in these early PPIs.
**/
VOID
EFIAPI
_ModuleEntryPoint(
IN CONST EFI_SEC_PEI_HAND_OFF *SecCoreData,
IN CONST EFI_PEI_PPI_DESCRIPTOR *PpiList
)
{
ProcessModuleEntryPointList (SecCoreData, PpiList, NULL);
//
// Should never return
//
ASSERT(FALSE);
CpuDeadLoop ();
}
函数中会调用一个构造函数：
\Build\OvmfX64\NOOPT_VS2015x86\X64\MdeModulePkg\Core\Pei\PeiMain\DEBUG\AutoGen.c
VOID
EFIAPI
ProcessModuleEntryPointList (
IN CONST EFI_SEC_PEI_HAND_OFF *SecCoreData,
IN CONST EFI_PEI_PPI_DESCRIPTOR *PpiList,
IN VOID *Context
)
{
PeiCore (SecCoreData, PpiList, Context);
}
最终，跳入位于\MdeModulePkg\Core\Pei\PeiMain\PeiMain.c中的如下函数：
/**
This routine is invoked by main entry of PeiMain module during transition
from SEC to PEI. After switching stack in the PEI core, it will restart
with the old core data.
@param SecCoreDataPtr Points to a data structure containing information about the PEI core's operating
environment, such as the size and location of temporary RAM, the stack location and
the BFV location.
@param PpiList Points to a list of one or more PPI descriptors to be installed initially by the PEI core.
An empty PPI list consists of a single descriptor with the end-tag
EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST. As part of its initialization
phase, the PEI Foundation will add these SEC-hosted PPIs to its PPI database such
that both the PEI Foundation and any modules can leverage the associated service
calls and/or code in these early PPIs
@param Data Pointer to old core data that is used to initialize the
core's data areas.
If NULL, it is first PeiCore entering.
**/
VOID
EFIAPI
PeiCore (
IN CONST EFI_SEC_PEI_HAND_OFF *SecCoreDataPtr,
IN CONST EFI_PEI_PPI_DESCRIPTOR *PpiList,
IN VOID *Data
)
前面可以看到，这里是通过 ProcessModuleEntryPointList (SecCoreData, PpiList, NULL); 进行调用的，因此，这里Data==NULL，所以也是第一次运行：
//
// Retrieve context passed into PEI Core
//
OldCoreData = (PEI_CORE_INSTANCE *) Data;
SecCoreData = (EFI_SEC_PEI_HAND_OFF *) SecCoreDataPtr;
//
// Perform PEI Core phase specific actions.
//
if (OldCoreData == NULL) {
//
// If OldCoreData is NULL, means current is the first entry into the PEI Core before memory is available.
//
ZeroMem (&PrivateData, sizeof (PEI_CORE_INSTANCE));
PrivateData.Signature = PEI_CORE_HANDLE_SIGNATURE;
CopyMem (&PrivateData.ServiceTableShadow, &gPs, sizeof (gPs));
}
其中PrivateData 是 PEI_CORE_INSTANCE PrivateData; 其中 PEI_CORE_INSTANCE 定义在PeiMain.h 中报错了 Pei Core 的一些信息，比如：当前 Fv中的 FFS 个数等等。第一次进入PeiCore 的时候（OldCoreData == NULL），代码会准备PrivateData的内容。
ESP32-S2 带有一个集成了收发器的全速 USB OTG 外设，符合 USB 1.1 规范。意思是S2即支持 USB Device 又支持Host。于是，这次测试在 Arduino 环境下通过 ESP32 S2 直接支持读取 USB Keyboard 的按键信息。
准备工作有点复杂：
2.硬件上GPIO19 和 GPIO20 可以分别作为 USB 的 D- 和 D+，这里我直接飞线接到一个 USB 母头上：
3.安装库下面这两个库
准备完成后，即可编译测试 esp32-usb-host-demos-main 中的 usbhidboot 示例代码。
4.编译上传之后如果想看到结果，还需要将 Core Debug Level 设置为 Verbose ，默认的 None 不会有任何输出
比如，我这边看到的结果如下：
之前介绍过如何在UEFI 下显示 BMP【参考1】，PCX【参考2】，PNG【参考3】和 GIF【参考4】。这次介绍的是一个 DXE Driver, 使用之后会在系统中注册 EFI_JPEGDECODER_PROTOCOL，这样 UEFI Application 可以通过这个 Protocol 进行 JPEG 的解码显示。这个代码来自【参考5】，有兴趣的朋友可以到原文进行查看。
代码分为两个，一个是 DXE Driver，另外一个是用于测试的 UEFI Application
首先介绍 DXE Driver 的编译（这次使用的是EDK2 202108 【参考6】）：
1. MdeModulePkg\MdeModulePkg.dsc 修改如下：
[Components]
#LABZ_Debug_Start
MdeModulePkg/JpegDecoderDxe/JpegDecoderDxe.inf
MdeModulePkg/Application/JPGDecoderTest/JPGDecoderTest.inf
#LABZ_Debug_End
MdeModulePkg/Application/HelloWorld/HelloWorld.inf
MdeModulePkg/Application/DumpDynPcd/DumpDynPcd.inf
MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.inf
2. MdeModulePkg\MdeModulePkg.dec 修改如下：
[Protocols]
##LABZ_Debug_Start
gEfiJpegDecoderProtocolGuid = { 0xa9396a81, 0x6231, 0x4dd7, {0xbd, 0x9b, 0x2e, 0x6b, 0xf7, 0xec, 0x73, 0xc2} }
##LABZ_Debug_End
## Load File protocol provides capability to load and unload EFI image into memory and execute it.
# Include/Protocol/LoadPe32Image.h
# This protocol is deprecated. Native EDKII module should NOT use this protocol to load/unload image.
# If developer need implement such functionality, they should use BasePeCoffLib.
gEfiLoadPeImageProtocolGuid = { 0x5CB5C776, 0x60D5, 0x45EE, { 0x88, 0x3C, 0x45, 0x27, 0x08, 0xCD, 0x74, 0x3F }}
3. 在\MdeModulePkg\Include\Protocol\下面放置 ：JpegDecoder.h
4. 在 \MdeModulePkg\ 下面放置JpegDecoderDxe目录
接下来加入一个测试的 UEFI Application。为了简化代码，我首先使用工具将图片转化为C语言的 .h文件，代码直接引用对应内存：
#include <Uefi.h>
#include <Library/PcdLib.h>
#include <Library/UefiLib.h>
#include <Library/UefiApplicationEntryPoint.h>
#include <Library/MemoryAllocationLib.h>
#include <Protocol/GraphicsOutput.h>
#include <JpegDecoder.h>
#include "demo.h"
extern EFI_BOOT_SERVICES *gBS;
extern EFI_SYSTEM_TABLE *gST;
EFI_GUID GraphicsOutputProtocolGuid = EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID;
EFI_GRAPHICS_OUTPUT_PROTOCOL *GraphicsOutput = NULL;
EFI_STATUS
EFIAPI
UefiMain (
IN EFI_HANDLE ImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
)
{
EFI_STATUS Status;
EFI_JPEG_DECODER_PROTOCOL *JpegDecoderProtocol;
UINT8* RGB32;
UINTN DecodedDataSize;
UINTN Height,Width;
EFI_JPEG_DECODER_STATUS DecoderStatus;
Status = gBS->LocateProtocol(
&GraphicsOutputProtocolGuid,
NULL,
(VOID **) &GraphicsOutput);
if (EFI_ERROR(Status))
{
GraphicsOutput = NULL;
Print(L"Loading Graphics_Output_Protocol error!\n");
return EFI_SUCCESS;
}
Status = gBS->LocateProtocol(
&gEfiJpegDecoderProtocolGuid,
NULL,
(VOID **) &JpegDecoderProtocol);
if (EFI_ERROR(Status))
{
Print(L"Loading Efi_JpegDecoder_Protocol failed!\n");
return EFI_SUCCESS;
}
RGB32 = (UINT8*)AllocatePool(636*373*4);
JpegDecoderProtocol->DecodeImage(
JpegDecoderProtocol,
(UINT8 *)&demo_jpg,
demo_jpg_size,
&RGB32,
&DecodedDataSize,
&Height,
&Width,
&DecoderStatus
);
GraphicsOutput->Blt(
GraphicsOutput,
(EFI_GRAPHICS_OUTPUT_BLT_PIXEL *) RGB32,
EfiBltBufferToVideo,
0, 0,
0, 0,
Width, Height, 0);
Print(L"Height=[%d],Width=[%d]\n",Height,Width);
FreePool(RGB32);
return EFI_SUCCESS;
}
简单的说就是在系统中查找EFI_JPEG_DECODER_PROTOCOL ，然后调用之。需要注意的是在调用的时候需要分配一个内存用于存储解压后的图像，但是这个 PROTOCOL 没有提供获得 JPEG 图片长宽的函数，因此要么直接分配足够大的内存，要么使用者知道图片的尺寸（比如，用于显示的 Logo，在Build的时候一定是知道具体尺寸的）。这里我知道图片尺寸，所以使用下面的方法直接开辟一段内存用于存储：
RGB32 = (UINT8*)AllocatePool(636*373*4);
使用方法是，首先 load JpegDecoderDxe.efi, 之后运行 jpgt.efi 即可显示：
运行结果：
可以看到，这种方式能够方便的显示 JPEG 格式的图片。
完整的代码下载：
参考：
首先介绍一下CH567代码的编译，以自带的EXAMPLE为例：
如果没有这个窗口，可以在 Window -> Show View ->Project Explorer 中打开之
2.再选择Existing Projects into Workspace
3.这里选择 USB0_DevCH372 作为示例
4.之后可以用下面这个按钮进行编译，可以编译为 Debug 或者 Release版本
5.很快就能完成编译
在 Output 目录下的 GPIO.bin 就是最终的编译结果。
接下来介绍如何下载到开发板上：
1.CH567 上有2个 USB Port，分别是 USB0 和 USB1。对于CH567 来说，只支持从USB1下载。
对应PCB 中，上方是 USB1 下方是 USB0
2.下载方法是：首先按住DOWNLOAD按钮，然后将USB 线插入USB1中，插入之后松开按钮
3.在设备管理器中能看到新增加的设备（如果没有的话，可能的原因是板子没有上电或者板子有硬件问题）
4.打开下载工具。首先在1的位置切换到 CH56X 页面，然后在2的位置选择芯片型号为 CH567，接下来在3选择要下载的设备（如果没有的话，请检查硬件），最后，在4的位置选择刚才提到编译后生成的文件
5.很快就能完成下载：
之后将 USB线连接到 USB0 上，在设备管理器中可以看到如下设备：
最后多提一下关于串口调试信息的输出，示例代码使用的是 UART3在 PA5上，只需要用USB串口线的 RTX 连接到这个引脚，共地之后使用 115200 波特率。
我最初看到“CPU 上电后BIOS运行的第一条指令是什么？”这个问题后的第一反应是：一个跳转指令啊。但是实际上并非如此，下面是 Intel TigerLake 平台一个BIOS ROM 末尾处的机器码：
可以看到，上电后 CPU 运行的第一条指令是 0x90(NOP)。
查看 OVMF的代码，在 \OvmfPkg\ResetVector\Ia16\ResetVectorVtf0.asm 中：
;
; The VTF signature
;
; VTF-0 means that the VTF (Volume Top File) code does not require
; any fixups.
;
vtfSignature:
DB 'V', 'T', 'F', 0
ALIGN 16
resetVector:
;
; Reset Vector
;
; This is where the processor will begin execution
;
nop
nop
jmp EarlyBspInitReal16
ALIGN 16
fourGigabytes:
同样的，第一条指令也是 NOP。
根据公众号“泰山N思维 ”的说法：
当前BIOS的头两条NOP代码没有特殊的意义，只是为了替换 wbinvd指令（机器码：0f 09，用于flush内部的Cache，并把Cache line数据写回内存）。早期CPU 第一条指令使用wbinvd指令的原因，相对比较“靠谱”的说法是：在CPU开始执行时候，虽然Cache处于Disable状态（CR0.CD），但只代表CPU Core不使用Cache（no-fill-mode），不代表Cache中没有有效的数据，通过wbinvd指令可以invalid无效化Cache中的数据；而新的CPU Invalid的操作已经由硬件执行，不再需要额外操作。后来由于wbinvd指令在某些CPU上会导致hang机问题，并且Intel新的CPU并不需要执行wbinvd指令，所以Intel使用两条nop进行了替换。
就是说这两条指令没有特殊意义，只是因为历史原因需要用2条指令来填充这里。
有兴趣的朋友不妨订阅““泰山N思维 “这个公众号。
通常情况下，我们在通过串口进行 Debug Message 输出的时候通常直接对 0x3F8 Port进行编程，但是这种方式并不符合 UEFI 规范。正规的做法是通过 EFI_DEBUGPORT_PROTOCOL来实现。在 UEFI 规范中有如下定义：
针对这个 Protocol 编写的测试代码如下：
#include <Uefi.h>
#include <Library/UefiLib.h>
#include <Library/ShellCEntryLib.h>
#include <Protocol/DebugPort.h>
#include <Library/UefiBootServicesTableLib.h> //global gST gBS gImageHandle
EFI_GUID gEfiDebugPortProtocolGuid = EFI_DEBUGPORT_PROTOCOL_GUID;
int
EFIAPI
main (
IN int Argc,
IN char **Argv
)
{
EFI_STATUS Status;
EFI_DEBUGPORT_PROTOCOL *DebugPort = NULL;
CHAR8 *TestMessage="www.lab-z.com";
Status = gBS->LocateProtocol(
&gEfiDebugPortProtocolGuid,
NULL,
(VOID **) &DebugPort);
if (EFI_ERROR(Status))
{
Print(L"Can't load DebugPortProtocol error!\n");
return EFI_SUCCESS;
}
UINTN Length=AsciiStrLen(TestMessage);
DebugPort->Write(
DebugPort,
1000,
&Length,
(VOID *)TestMessage
);
gBS->CloseProtocol (
DebugPort,
&gEfiDebugPortProtocolGuid,
gImageHandle,
NULL );
return EFI_SUCCESS;
}
运行之后主机端的串口程序中可以看到有字符串的输出：
完整代码：
去年最火爆的就是芯片了，我在21年4月购买的 MAX3421芯片还只要16.6元
而今天再点进去查看报价已经达到了 130 （咨询下来预期50左右）：
于是萌发了制作一个能够多次复用模块的想法，简单的说设计足够小的 PCB 然后将芯片焊接在上面，将必要的引脚引出，使其成为一个“模块”。
电路图设计如下：
为了保证体积足够小，使用了贴片式晶振，这个晶振有4个引脚，分别是2个 GND ，1个XO 一个XI；尺寸是 3.2×2.5mm 厚度是 0.7mm，因此这种封装也被称作SMD3225-4P。
PCB 设计如下：
为了尽量缩减体积，上面只保留必要的5个电容，同时选用 0603封装的，不得不承认，0603封装能够极大方便布线。
| 名称 | 用途 | 用途 | 名称 | |
| INT | 用于MAX3421通知单片机有中断发生 | SPI的MOSI | MOSI | |
| GND | 地 | SPI的MOSI | MISO | |
| MD- | USB Host D- | SPI的片选 | SS | |
| MD+ | USB Host D+ | SPI的 CLOCK | SCLK | |
| VBCOMP | 检查USB 设备的 VBUS 是否存在 | 芯片的 RESET Pin, 正常情况下必须为高 | RESET | |
| GND | 地 | 芯片供电 | 3.3V |
焊接完成后，我们就可以在 FireBeetle 上进行测试了：
首先，FireBeetle VCC 给USB 母头供电，同时共地，其余引脚连接如下：
| 名称 | FireBeetle | FireBeetle | 名称 | |
| INT | D3 | IO23 | MOSI | |
| GND | GND | IO19 | MISO | |
| MD- | USB 母头 D- | D7 | SS | |
| MD+ | USB 母头 D+ | IO18 | SCLK | |
| VBCOMP | USB 母头 5v | 3.3V | RESET | |
| GND | GND | 3.3V | 3.3V |
之后就可以直接使用 USB Host Shield 2.0 的库了，比如运行 \USBHIDBootMouse.ino 这个示例：
#include <hidboot.h>
#include <usbhub.h>
// Satisfy the IDE, which needs to see the include statment in the ino too.
#ifdef dobogusinclude
#include <spi4teensy3.h>
#endif
#include <SPI.h>
class MouseRptParser : public MouseReportParser
{
protected:
void OnMouseMove (MOUSEINFO *mi);
void OnLeftButtonUp (MOUSEINFO *mi);
void OnLeftButtonDown (MOUSEINFO *mi);
void OnRightButtonUp (MOUSEINFO *mi);
void OnRightButtonDown (MOUSEINFO *mi);
void OnMiddleButtonUp (MOUSEINFO *mi);
void OnMiddleButtonDown (MOUSEINFO *mi);
};
void MouseRptParser::OnMouseMove(MOUSEINFO *mi)
{
Serial.print("dx=");
Serial.print(mi->dX, DEC);
Serial.print(" dy=");
Serial.println(mi->dY, DEC);
};
void MouseRptParser::OnLeftButtonUp (MOUSEINFO *mi)
{
Serial.println("L Butt Up");
};
void MouseRptParser::OnLeftButtonDown (MOUSEINFO *mi)
{
Serial.println("L Butt Dn");
};
void MouseRptParser::OnRightButtonUp (MOUSEINFO *mi)
{
Serial.println("R Butt Up");
};
void MouseRptParser::OnRightButtonDown (MOUSEINFO *mi)
{
Serial.println("R Butt Dn");
};
void MouseRptParser::OnMiddleButtonUp (MOUSEINFO *mi)
{
Serial.println("M Butt Up");
};
void MouseRptParser::OnMiddleButtonDown (MOUSEINFO *mi)
{
Serial.println("M Butt Dn");
};
USB Usb;
USBHub Hub(&Usb);
HIDBoot<USB_HID_PROTOCOL_MOUSE> HidMouse(&Usb);
MouseRptParser Prs;
void setup()
{
Serial.begin( 115200 );
#if !defined(__MIPSEL__)
while (!Serial); // Wait for serial port to connect - used on Leonardo, Teensy and other boards with built-in USB CDC serial connection
#endif
Serial.println("Start");
if (Usb.Init() == -1)
Serial.println("OSC did not start.");
delay( 200 );
HidMouse.SetReportParser(0, &Prs);
}
void loop()
{
Usb.Task();
}
本文提到的电路图和PCB 下载（立创 EDA）
最近在研究 ACPICA ，发现iasl.exe 的一个有趣的功能：生成当前ACPI Table Hardware Mapfile。这个功能可以生成当前 ACPI Table 中硬件资源的列表，例如：
Intel ACPI Component Architecture
ASL Optimizing Compiler version 20140828-32 [Sep 19 2014]
Copyright (c) 2000 - 2014 Intel Corporation
Compilation of "dsdt.dsl" - Fri Sep 19 09:43:52 2014
Resource Descriptor Connectivity Map
------------------------------------
GPIO Controller: INT33FC \_SB.GPO0 // Intel Baytrail GPIO Controller
Pin Type Direction Polarity Dest _HID Destination
0000 GpioInt -Interrupt- ActiveBoth INTCFD9 \_SB_.
0000 GpioInt -Interrupt- ActiveBoth INTCFD9 \_SB_.TBAD
0001 GpioInt -Interrupt- ActiveBoth INTCFD9 \_SB_.TBAD
0002 GpioIo OutputOnly -Field- \_SB_.GPO0.CCU2
0003 GpioIo OutputOnly -Field- \_SB_.GPO0.CCU3
0026 GpioIo InputOnly 80860F14 \_SB_.SDHC
0026 GpioInt -Interrupt- ActiveBoth 80860F14 \_SB_.SDHC
0028 GpioIo OutputOnly 80860F14 \_SB_.SDHC
0029 GpioIo OutputOnly 80860F14 \_SB_.SDHC
0036 GpioIo OutputOnly -No HID- \_SB_.PCI0.OTG1
0041 GpioIo OutputOnly 10EC5640 \_SB_.I2C2.RTEK
005F GpioIo OutputOnly -Field- \_SB_.GPO0.TCON
0060 GpioInt -Interrupt- ActiveBoth INTCFD9 \_SB_.TBAD
0064 GpioIo OutputOnly MCD0001 \MDM_
I2C Controller: 80860F41 \_SB.I2C2 // Intel Baytrail I2C Host Controller
Type Address Speed Dest _HID Destination
I2C 0010 00061A80 INT33BE \_SB_.I2C2.CAM1 // Camera Sensor OV5693
I2C 001C 00061A80 10EC5640 \_SB_.I2C2.RTEK // Realtek I2S Audio Codec
I2C 0048 00061A80 INT33F0 \_SB_.I2C2.CAMB // Camera Sensor MT9M114
SPI Controller: 80860F0E \_SB.SPI1 // Intel SPI Controller
Type Address Speed Dest _HID Destination
SPI 0001 007A1200 AUTH2750 \_SB_.SPI1.FPNT // AuthenTec AES2750
UART Controller: 80860F0A \_SB.URT1 // Intel Atom UART Controller
Type Address Speed Dest _HID Destination
UART 0000 0001C200 UTK0001 \_SB_.URT1.UART
UART 0000 0001C200 OBDA8723 \_SB_.URT1.BTH1
比如，从上面可以看到 Table中有一个名为SPI1的 SPI 控制器，ID 是 80860F0E，然后它下面有一个叫做 FPNT 的设备，HID为AUTH2750，速度是8Mhz（0x7a1200）。
使用方法是： iasl.exe -lm dsdt.asl
生成结果在同一个目录下的 dsdt.map 中。
本文来自 The Old New Thing专栏，作者是Raymond Chen，他是资深的微软工程师参与多个版本的Windows开发，在他的专栏中讲述了很多关于 Windows研发的趣事。本文链接在 https://devblogs.microsoft.com/oldnewthing/20030828-00/?p=42753 。原标题是 “Hardware backwards compatibility” 。
所谓兼容性不单单只存在于软件上，硬件上同样会面临同样的问题。更糟糕的是当硬件出现问题时，人们常常会责怪软件…….
HLT 是一条让 CPU 停机的指令，CPU 执行这条指令之后会进入休眠直到被硬件中断唤醒。这条指令对于笔记本电脑很有帮助，它能够帮助降低整体功耗，测试表明能引入这条指令让笔记本电脑降低3摄氏度。
我们（微软）曾经尝试在 Win95中引入这条指令，当系统不太忙时抽空让CPU“打盹”，但是很快发现很多笔记本电脑（一些时主流笔记本厂商的型号）执行HLT 指令的时候会死机。
最终，我们只得在 Windows 95中取消这条指令。
很快，HLT指令为大众所知，很多人写道“愚蠢的微软。他们为什么不在Windows中支持这个指令”。在这种情况下，我只能默默的坐着听闻人们对于微软的各种批评声音，诸如愚蠢、懒惰和自私。
如今，我终于可以在这里为 Windows 95 辩解一番（当然，我仍然不能披露前面提到的主流生产商的名字）。
比如，我最喜欢的一个硬件产品，有着一个非常糟糕的问题：如果你将显卡插入距离电源最远的扩展槽，运行之后系统就会崩溃。很明显这是由于硬件制造商压缩成本造成的。众所周知，硬件厂商追求的 Cost Down 总会导致稀奇古怪的问题。更加不幸的是，Windows95 就是运行在这样一批稀奇古怪的硬件上的操作系统。试想如下场景就能理解为什么我们竭尽全力来适配这些硬件呢：
这样的情况下你会认为是谁的责任。毫无疑问：你不会批评硬件厂商。
========================================
作为一个BIOS工程师，在遇到问题时，不应该轻易的下结论，特别是使用：“之前工作正常，但是现在忽然不正常”这样的断言。因为很可能之前能够工作是因为刚好处于临界状态（margin）运气稍微好一些没有碰到而已。作为从业人员应该用更专业更有逻辑的证据来证明。