万物生于一；面对纷繁，要看透它一的底色
(请保留->发布地址： http://yiiyee.cn/blog/author/luobing/ )
前几天有人问起我，对UEFI的格式文件的理解。
嗯，我基本上快把PE格式忘光光了，那是很多年前，搞反汇编，混看雪学院时搞的事情。当时花了几个月，专门学习软件加密、加壳、扰乱反汇编等等。然后，又花了几周，破解了几个dll，扔给工程师去用，就再也没有接触过了。
闲言少叙。既然忘记了，就花点时间去回忆一下吧。上午的会议开完，下午有两个小时空档，找找以前的日志和资料。
继续阅读“UEFI开发探索08 – PE/COFF”3,634 total views, no views today
(请保留->发布地址： http://yiiyee.cn/blog/author/luobing/ )
这篇博客曾经发表在高端调试的论坛上，我把它转移到这里来了。UEFI访问SMBUS设备，是我计划中要写的，这篇就作为其前言吧，其中没有任何与UEFI相关的内容。
当时我已经开发完了C850F320上的smbus访问代码（作为smbus device）、Legacy BIOS下的smbus访问代码（在dos下调试，运行于OptionRom上），期望在windows上开发一个驱动，能通过smbus直接访问C850F320。这能让目前产品的价格降低20元，以当时的出货量，一年的成本可以节省40w，很可观的。
我把这篇博客拷贝过来了，绝不是因为今天上午要开会，没时间写了。说不是就不是！
以下为原文：
继续阅读“UEFI开发探索07 – 关于SMBUS的开发故事”6,634 total views, 2 views today
在做这个项目的时候，遇到一个问题。我们使用的STMF103C8T6，资源很可怜，看看：
72M的频率，内存只有20K。而这个芯片需要做的事情：
1 3个串口的收发；
2 3个灯的控制，让用户通过灯的闪烁判断处于什么状态，方便维护；
3 GPRS模块的协议管理；
4 与逆变器端的协议管理；
5 看门狗的任务处理；
6 服务器端协议的处理，包含应用端口和配置端口；
以FreeRTOS为架构，估计用了近20个任务来完成这些工作。每个任务给的堆栈是0.5K，加上串口需要的缓冲区，一番操作下来，内存基本用光光。一起开发的兄弟，暂且称为烟枪吧（抽烟很快，1分钟一根，当得起这个称呼）。每天嚷嚷，说内存严重不够用，不能让客户再提新的需求了。虽然通过map文件计算了每个任务所用的栈空间，尽可能不浪费。不过再改的话，程序就直接溢出了，问题出在哪都不知道。
我很同意他的看法，也很同情我们的处境。可是，客户又不是我家的，他想提要求，我又控制不住。何况有些要求还是很中肯的，咱们都是讲道理的，对吧？
那怎么办？
分析源代码，我盯上了串口处理的这段代码。三个串口，除去串口接收发送所需要建立的任务外，每个串口还用了256字节的缓冲区。另外，程序写得耦合性比较差，估计换个芯片，所有代码都得重写。
程序逻辑是这样的：
也就是说，当监听任务在处理数据的时候，DMA接收中断使用了另外一段缓冲区，大家互不干涉（当然程序中也利用了FreeRTOS的互斥量来实现）。
这样实现其实没有太大问题，因为精心计算了串口和DMA的处理时间。接收串口的数据越长，越不会出现问题。
问题就出在小数据上。如果串口接收大量的小数据，频繁的触发中断，CPU就有可能丢失数据了。（实际运行中没有出现过，连续发送1个字节的情况，在客户环境中可认为概率是0）
烟枪和我商量了一段时间，我们决定使用ringbuffer（环形缓冲）来实现。他把这个任务轻飘飘的交给我了，调他的板子去了。
没办法，开始干活吧。 Ringbuffer的基本原理，我大概了解。维基百科中也有说明：https://en.wikipedia.org/wiki/Circular_buffer。
我能用的资源有限。必须实现原有的串口接收，不能丢数据；同时还有提供尽可能简单的接口，供应用层的函数调用。
因此，我选择使用Contiki中的代码，用它的核心思想来构建这个架构。当时估计错误，我不觉得能有多难，本以为一周左右能搞定。没想到对芯片的DMA以及串口不那么熟悉，整整花了我三周时间。
这是一段痛并快乐的回忆。
3,696 total views, no views today
(请保留->发布地址： http://yiiyee.cn/blog/author/luobing/ )
到了我最喜欢的环节了，图形显示！
我曾经写过不少关于图形显示的博客和论文，特别是在Legacy BIOS以及嵌入式设备中的显示。PC的显示一直都遵循着VESA的标准，在底层的访问还是比较一致。虽然在多年的开发中，也在一些主板上出现过奇怪的现象（一次而已。Award某款主板，设置显示模式的时候，花屏。在调用设置显示模式的函数前，多压几次堆栈，问题又消失了。）。但当年写的核心显示代码，运行了近10年了，也没出现过显示的问题。
这是我曾翻烂过的参考书：
还有这些…
以及《最新VESA SVGA图形图像编程秘技》 李军著、《C语言游戏编程从入门到精通》，还有图像格式，主要是BMP、PCX和jpeg。哦，还有一本雷军（没错，我就是当年用过这本书，才成为米粉的）和求伯君的《深入DOS编程》。
写得最扎实的是《IBM PC的原理及应用》以及《PC技术内幕》，想了解底层显示原理的可以参考一下。虽然我觉得这些知识有点过时了，但对理解还是有帮助的。
继续阅读“UEFI开发探索06 – 图形显示01”3,387 total views, no views today
(请保留->发布地址： http://yiiyee.cn/blog/author/luobing/ )
这两天妻子去阜宁，孩子没有带过去。我只能在陪孩子之外，腾出一点点时间，来搭建UDK2017/UDK2018的编译环境。
大部分的时间都在装VS，试了两个版本，VS2013和VS2015。我不知道是不是我的版本有问题，总是不成功。Ubuntu16.04的也没有安装成功，让人颇为恼火。总计来回折腾了12个虚拟机，真是不甘心。
下周开始又没有太多时间了，几个案子都在催着完成，有大量的工作要去做。两个专利也还没写，前期的资料都还没收集完。思来想去，我仍旧以UDK2010来编译这些代码吧。主要的目的是熟悉这些API和UEFI的架构，我目前没有开发BIOS，太细节的暂时不必理会。
插一句，为了方便调试，我请同事做了一些带有PCI-E扩展ROM的卡，主芯片是CH366，下周应该可以到我手上了。对于进入操作系统之前，可以跑自己的程序，我一直很热衷：总想脱离操作系统做点什么坏事。→_→
比如针对操作系统核心的几个文件ntldr.dll，gdi32.dll等，使用Oprom对其认证，防止篡改。或者和杀毒软件配合，进入OS前做些事情。整个硬盘都可以控制，可以预先做很多动作。
又扯远了，回到搭建编译环境的事情吧。
我主要使用Vmware搭建虚拟机，开发用的操作系统为win10。中间的各种小问题就不说了，基本上都解决了。主要是两个问题，没有找到解决办法。
1. VS2013+UDK2017，VS2013全部安装，WDK8.0和WDK8.1的目录都有。编译Nt32Pkg无法通过。如图1。
2. VS2015+UDK2018，Nt32Pkg编译通过，AppPkg编译不通过。本系列Blog中的“UEFI开发探索03-环境搭建2”曾经描述过安装过程。编译AppPkg的报错如下：
这段时间以把程序编译运行为主，就用UDK2010，尽快把博客写完。和张佩去年就约定要把Foxdisk和UEFI的开发记录下来，一直到现在还没搞定，甚是惭愧。
搭建环境的问题，留待日后吧，看是否能凑些边角料的时间来找找原因。O__O
如果哪位朋友知道怎么回事，也望不吝赐教，感激不尽。:)
2,075 total views, 1 views today
(请保留->发布地址： http://yiiyee.cn/blog/author/luobing/ )
我当年学习UEFI的最终目标是实现UEFI Oprom，写入PCI-E ROM，作为隔离卡的底层软件运行。中间的一个目标是编写UEFI driver/application，与bios一起编译，同样是作为底层软件，与另外一款卡通讯。当时是与联想共同开发了一款安全隔离计算机，中间目标就是为这款产品而设的。
最后两个目标都实现了，当年刚做的时候还是比较辛苦的。第一个面临的问题就是使用哪种程序入口。有三种可选：UefiMain,main,ShellAppMain。
参照当时能找到的资料，《Beyond BIOS》、《Harnessing the UEFI Shell》以及UEFI spec（当年看的是2.3，现在都到2.9了），还有bios之家、网友的博客，终于摸到了一些门径。
当年的我并不了解这些程序入口的区别，是最近写博客的时候看《UEFI原理与编程》时才有所了解（终于有本中文版的参考资料了！感谢作者戴正华，有机会真想拜见）。
我的理解，main和ShellAppMain肯定是不能用在Option ROM上的。那么多的链接库，一是没法放进去，二是即便可以放进去，工作量也太大了。简单来说，就如同我之前开发的Legacy Option ROM一样，只能调用int 10h,int 13h,int 16h等这些bios中断，想调用int 33h这些DOS中断，你只能把整个DOS弄进去（更别提那个时候可能BIOS都还没准备好，放进去也运行不了）。
不过，使用main的程序入口，可以很方便的进行Shell下的测试。所以在实现这第一个程序的时候，我选择了这种编译方式。
如图，使用的是以下的API(UEFI spec 2.8 Page431):
API还是很好理解的，看EFI_KEY_DATA的数据结构，与int 16h 0号功能返回的是一样的。我不知道UEFI是怎么处理硬件中断9的，估计也是封装在了这些API中。
程序编写相对比较容易，gBS和gST是预置的，直接使用就可以了。（代码在文末提供下载地址）根据API的说明，我编写了一个获取键盘输入的函数GetKeyEx，将用户输入的键盘信息保存下来。
上述的工作相对比较简单，有点麻烦的是准备编译。使用main函数的工程模块需要在AppPkg环境下才能成功编译。
为方便后续的开发，我在根目录下建立了一个\_LuoApp的文件夹。在\AppPkg\AppPkg.dsc中添加相应的inf文件，指明要编译的代码，如图所示。
（20190512 20:13 Robin: 这次的编译仍旧使用了UDK2010的环境。我试图搭建UDK2017或UDK2018，都不成功。有的NT32Pkg可以编译，但是AppPkg无法编译通过;有的则连Nt32Pkg都编译不通过。VS2013和VS2015都试过了，怀疑是我VS版本有些问题。）
修改target.txt，设置为如下参数：
ACTIVE_PLATFORM = AppPkg/AppPkg.dsc
TARGET_ARCH = IA32
TOOL_CHAIN_TAG = VS2008
打开Visual Studio 2008 command，编译：
C:\MyEorkSPace>edksetup.bat
C:\MyEorkSPace>build
或者build -p AppPkg\AppPkg.dsc -a IA32 -t VS2008 （不需要修改target.txt了）。
生成的文件为c:\myWorkSpace\Build\AppPkg\DEBUG_VS2008\IA32\_LuoApp\Luo2\Luo2\OUTPUT\Luo2.efi
将其拷贝至之前编译好的NT32下（主要是可以使用SecMain.exe）:
c:\myWorkSpace\Build\NT32\DEBUG_VS2008\IA32\
运行SecMain.exe，测试Luo2.exe：
代码放在百度云上，对照看下，逻辑还是比较简单的，将用户的按键信息打印出来。这个程序是以main入口函数来编写的，另外也编写了一个UefiMain入口函数的程序，功能一样，也在云端。
至此，实现了键盘的访问。如需要在实际机器上运行，只要修改编译参数即可。
百度云链接：https://pan.baidu.com/s/1gccSosw8_UAGTI5gZPnLCA
提取码：dx23
键盘访问的代码在 01 ReadKeyEx下。
2,989 total views, 1 views today
(请保留->发布地址： http://yiiyee.cn/blog/author/luobing/ )
从上次写完博客，过去了一个多月。中间到深圳出差，解决一个硬盘加密的项目，时间就这么过去了。等回过神来，发现写博客的计划又往后拖了。
下定决心，我想在这周搞定编译环境。
以前我是在XP下，使用UDK2010来编译的，比如这个：
我原本的计划是用Ubuntu 16来搭建环境。最近正习惯在上面用vim和vscode编程，戒掉用了多年的UE和sublime。尝试了一天，总是遇到各种问题，特别是到现在也没有也没搞明白，GCC在安装过程中不知怎么变为了7.x。
这么下去，这周的计划又完成不了。我回到了用windows安装的老路，预备安装UDK2018。
还是折腾了一天，搞定了。把安装步骤和中途遇到的问题记录下来吧。
这是参考用的几个网址：
https://github.com/tianocore/edk2/releases
先吐槽一下，文档写得并不友好，我的时间全花在了编译Base Toosls上。实际上可以不用自己去编译Base Tools，直接下载就可以了。地址如下：
https://github.com/tianocore/edk2-BaseTools-win32
我是在读UDK2017的文档UDK2017 How to Build时发现的。
安装步骤(Win10下安装)：
1. 安装 VS2015。我安装了图中所示的项，Python Tools for Visual Studio我觉得应该是不需要的，当时顺手选上了。
2. 安装Python 2.7.16，同时选择将Python加入Path(安装的时候需要选择)；
3. 安装Nasm 2.12.01，注意选择安装路径为C:\Nasm。在我的电脑-属性-高级系统设置-高级-环境变量…-系统变量-Path中添加此路径；
4. 安装Openssl工具和ASL工具（应该不需要，这是用来生成Base Tools用的）；
5. 解压edk2-vUDK2018.zip到C:\MyWorkspace；
6. 添加系统变量PYTHON_HOME=c:\Python27；（补充一句，添加编译工具路径以及系统变量，可以在edksetup.bat中添加，比如：
Path = c:\nasm;%path%
Set PYTHON_HOME=c:\python27
这样就不需要像步骤3和6一样操作了，对我这种强迫症比较合适）；
7. 打开“VS2015 x64 Native Tools Command Prompt”，运行edksetup.bat –nt32，会生成/Conf下所需的一些文件； 8. 执行build -p NT32Pkg\Nt32Pkg.dsc -a IA32 -t VS2015x86 run，启动SecMain.exe。
8. 执行build -p NT32Pkg\Nt32Pkg.dsc -a IA32 -t VS2015x86 run，启动SecMain.exe。
我的安装过程并不顺利，遇到了两个问题，记录如下：
问题1：python编译中找不到cxFreeze的module，无法通过编译。
解决：cmd打开，输入pip install cx_freeze。（注意Path中要包含Python的路径，否则无法执行）。
问题2：提示 File “GenFds\GenFds.py”, line 24, in <module>
ValueError: Attempted relative import in non-package
解决：将路径BaseTools\Bin\Win32下GenFds.exe更名为GenFds.LABZ，并将BaseTools\BinWrappers\WindowsLike;添加到Path路径中。
（此问题的解决参照http://www.lab-z.com/udk2018coming/和https://github.com/tzz1996/Blog/blob/master/compile_udk2018_in_windows.md，感谢！）
至此，终于可以继续探索UEFI了。明天开始将之前写过的例子一个个编译运行，加深理解。至于Ubuntu的开发环境，找时间再做吧。毕竟ubuntu更轻量级点，windows上光VS2015就占了12G。我都是在虚拟机下开发，这么多开发环境，空间严重不足了。
(20190512 20:40 Robin: Nt32Pkg是可以编译，可是AppPkg没有编译成功，目前没有找到原因，编译的问题在 UEFI开发探索05中列出，后面找时间再解决。暂时还是以我之前的UDK2010来编译吧)
5,452 total views, 1 views today
(请保留->发布地址： http://yiiyee.cn/blog/author/luobing/ )
开发初期的目的就是做出可以在pci rom上跑的Oprom，当然是在uefi bios下。我的计划大致如下：
1 搭建完整的编译环境，了解使用哪些库进行编译；
2 我的设备最常用的几种总线通讯方式：PCI总线、smbus总线和usb总线，如何通过这些总线访问设备，必须要解决；
3 图形显示，我最感兴趣的，首要解决的是如何画点。PC的架构还是一样的，硬件原理差不多，还是有页、显示模式等概念，不过uefi api把很多细节屏蔽了；
4 键盘输入，必不可少。鼠标的功能，试试看吧；
5 uefi下可以使用网络的功能，这很吸引人。以前为了加快产品测试，在dos下开发网络通信功能，最头疼的是要去找各种网卡的dos驱动，新的网卡基本都不怎么提供了。写这篇博客的时候，我还没去实现过，后面尝试一下；
6 硬盘访问；
7 编译一个可以放在pci rom上的oprom。以前的还原卡、硬盘加密等，都可以用这种方式来实现了。
计划大概就是如此，主线是做Oprom，支线是如何访问各种设备，以应用为目的，对uefi进行探索。
先看下我常用的两款设备，用来运行实际代码的。
刚从大学毕业那会，对操作系统极其入迷，总想搞清楚底层是怎么运行的。其中最感兴趣的是图形的显示，BIOS对硬件的控制等。找了很多资料看，正好公司的一些项目上也需要用到，就这么磕磕碰碰的实现了各种显示的代码。
Foxdisk的代码中，Vesa.c和Vesa.h就包含了显示的所有信息。主要是遵循了vesa的标准进行显示，采用C嵌汇编的方式来编写。目前，几乎所有的机器都支持VESA标准，而在X86平台下编程就是基于此标准的。VESA标准在原有BIOS提供的API的基础上，提供了一组扩展BIOS功能调用。对于标准VGA下的模式，仍然可以使用基本BIOS调用，但对于扩展模式，其许多操作如模式设置及视频缓冲读写等，则只能通过VESA标准提供的扩展BIOS来实现。
在VESA标准下，视频缓冲是以分页映射的方式进行操作。其基窗口一般为在0xA0000处，每页为64K。整个视频缓冲都通过映射到此窗口而得以直接存取。一般的图形编程步骤如下：
过多的细节不用纠结，Vesa.c中提供了画点函数putpixel256()。把屏幕当做一个大画布，设置模式的时候知道这块画布多大，用画点函数绘制即可。Foxdisk使用的是模式0x105，也即1024×768，256色。想像一下，有张宽1024像素点，长768像素点的画布，有支可在画布任何坐标处画点的笔，应该是什么画都可以画出来了，包括汉字。
Foxdisk中显示汉字，大致可以分为两步：
Vesa.c和Font.c中屏蔽了很多显示的细节，特别是对各种字体及字体大小的处理。在设计之初，考虑去兼容各种不同的字体，比如黑体、楷体、宋体等等。代码中针对不同的字体，提供了各种编译用的开关。实际程序中，主要用了16×16宋体和24×24楷体，从提取汉字库的批处理命令可以看出来。
在博客“Foxdisk09-工具篇”中，已经初略的介绍了提取汉字库的工具了。我是为了能自动针对所有用到汉字的代码，自动提取汉字字模，开发的这些小工具。下面具体介绍下如何提取字库。
所谓无字库技术，就是在程序中建立一个类似字库的字库数组来代替字库。程序中建立的字库某种意义上独立于程序中显示程序。也就是存在这样的可能：单独对字库数组进行压缩，在使用的时候重新解压。这个特性在嵌入式的应用中非常有用，可以节约不少的程序空间。
一般说来，提取汉字字库的步骤应该是这样的：
1) 对包含需要提取汉字的源文件进行文法分析，析取出需要提取字模的汉字
2) 对提取出的汉字再次分析，并去除重复的汉字打开相应的汉字库，提取需要的字模，并按规则形成新的字库数组
3) 对照上一篇博客的说明，设计16×16及24×24的汉字字模结构体。
struct hzk16_typ{ /* 汉字字模结构体 */
unsigned int code;
unsigned int array[16];
};
struct hzk24_typ{ /* 汉字字模结构体 */
unsigned int code;
unsigned char array[3*24];
};
最终会将字模以上述数据结构的方式存储，Foxdisk中存储生成的文件为HZTABLE.H和HZK24.H。
具体的提取代码可以参照ehz24.c和etrhz.c，这两个文件的代码量都在400行左右。核心工作在于分析指定的文件，从中提取出需要转换字模的汉字。
为了便于分析，也为了程序编写简单，对指定的文件是有要求的。必须保证在提取的文件中字符串中没有//和/* 字符,否则可能会提取错误。提取程序并没有去进行字符串内部的语义分析，否则要处理的情况太多了。 代码就不贴出来了，放不下。对照编程的想法，以及代码，还是比较容易看明白运作的机制的。
2013年的时候，和联想的双网安全隔离计算机项目进入了平稳阶段。经过了前几年的合作开发，几代不同的产品的磨合，Q45、G41、H61等，整个方案已经成熟。再开案的话，我觉得大部分问题都会集中在硬件方面，软件问题不会太多。
不过，实际上软件还留下一个问题需要想办法解决，那就是Option ROM对UEFI的支持。在2012年出货的产品中，因为时间比较紧，为了把Option ROM移植到UEFI下（联想2011年左右基本都转换为UEFI BIOS），我采用了一种比较省事的方法，用AMI的VBE来开发。主要是考虑到有问题可以去请教联想的BIOS工程师，这是种比较保险的做法。
因此，即便我了解intel提供了UDK可以直接进行开发，我仍旧走了上述的路线。当时的开发很难，从VBE新手到开发出符合要求的UEFI driver（实际上就是个option rom），花了我三个礼拜，像打了鸡血一样不眠不休的完成了。
在此要感谢当时还在Intel的Raymond，张银奎老师，帮我向intel bios部门咨询解决了显示的一个问题。以及我刚出生没多久的宝贝，因为她我才在北京待不住，用了最快的速度解决了这个项目问题，就为了早一刻回南京抱她。
所以，2013年的时候，摆在我面前的问题是，如何用intel UDK把Option ROM开发出来。一方面用在联想的合作项目上；另外一方面，把它用在公司的另外一个产品-隔离卡上。
随着UEFI越来越普及，未来肯定会只支持UEFI，当时隔离卡上面的Legacy oprom会无法运行的。几年过去了，这个论断终于实现了。现在是2019年，公司就是因为当时的这个技术设计，今年3月还没过完，半个月的销量，超过了去年同期一个月的销量了。我甚是欣慰。
完成这个目标的时间就比较充裕了，毕竟和联想的案子已经有一个可用的软件版本了（用VBE开发的），而隔离卡这边的需求还没到时候。
仿照之前学习底层开发的过程，我制定了一个小计划，从控制键盘、图形显示、鼠标显示、访问PCI端口、SMBUS通讯、USB访问、网络访问….这样的顺序开始尝试写代码。
虽然因为各种原因，在完成了最初的目标（支持公司产品在UDK下的开发）后，有些工作没有继续了。但我觉得还是基本上把UEFI下的开发摸了个遍，即便要开发其他的产品，现有的代码也能用得很好。
我写的博客虽然是从Foxdisk开始的，但在计划中，UEFI的开发就已经位列其中了。
今天终于如愿开始了，记录我挥汗编程的日日夜夜，也纪念我当时用来在家开发，如今已经退役的老朋友，它使用了“很古老” 的华硕945主板，跟了我那么多年，终于没有机会再使用它了。
是为开篇。
(原文地址:
http://yiiyee.cn/blog/2019/03/20/uefi%e5%bc%80%e5%8f%91%e6%8e%a2%e7%b4%a201-%e8%b5%b7%e7%af%87/ )
在以前的博客中曾经讨论过，设计的Foxdisk代码段和数据段总共只能128K。可是随便哪个汉字库轻轻松松都超过了100K，大的有近500K（我设计的时候只用了24×24以及16×16的字模），无论如何是不能包含在程序中的。唯一的办法，是将需要用的汉字字模提取出来，实现小字库的汉字显示。
当然，如果改变Foxdisk的设计方法，比如采用很久以前用过的一种技术：在硬盘的末端存一个裁剪的DOS或者linux，用OS来支持。现在遇到的存储空间不够啊、想实现的功能难以实现啊，都能解决。并且还能复用大量的DOS/Linux的软件，还是很不错的。不过，这就失去了我当时设计的初衷了，本来就是用来学习底层知识的一个小项目，用这种方法则屏蔽了大量的实现细节，所以我就放弃了。不过，在公司早期的一款产品中（卖了好几年，技术支持巨难，后来被我停掉了）是用了这种方法的，有机会也开个博客仔细探讨下。
文字显示主要包括文字的读取和显示两个步骤。西方文字显示完全可以集成在一个ROM内，但是中文字太多，通常都要用到字库。中文字库有两大类型：点阵式字库和矢量字库。
点阵式字库是通过将中文字看成一个个点组成的二维阵列来实现显示；矢量字库则通过对文字每个笔划的起始点和结束点的记录来完成文字显示。很明显，点阵字如果要放大文字将会出现明显的不平滑现象；而矢量字无论字的大小都可以保证字体圆滑。但是由于点阵字理解简单、便于编程等原因，在很多领域点阵字库成为了主流。
当前只针对点阵字库进行讨论研究，并针对研究的各字体库进行分析，阐述其在编程上的一些区别。在此基础上，提供了无字库方案的实现过程及代码。 点阵字的显示原理其实很简单。在规定大小的区域格内，如16×16、24×24等，将需要显示的字的对应格填充即可。字库内对应的格则以1表示，没有填充的以0表示。如图所示：
这是英文字模的图样，而中文字模的图样是这样的：
图中的字模信息就存储在相应的字库中，而程序员就可以按照显示原理在显示器上以点位的方式显示字符。
每个英文字母都是由一个ASCII码组成的，而中文字是扩展ASCII码组成的。也就是说一个中文字是由左半边和右半边两部分的信息组成的。字库中的文字一般是按区位码的形式存放的，大体原理相同，但是在实际组织的时候有些细微的差别。[1]
本文所讨论的字库有HZK16（16×16汉字库）、HZK24S（24×24宋体）、HZK24H（24×24黑体）、HZK24F（24×24仿宋）、HZK24K（24×24楷体）、HZK24T（24×24汉字全角字符）。
对于24×24以上的汉字字库，比如48×48汉字字库，其存储方式与24×24 的相同，只是大小不同，简单修改就可适用，以下将作详细说明。
HZK16的中汉字存储可以用公式表示如下：
其中1、2步减去0xA0的原因是中文字符用到的扩展ASCII码是从0xA0之后开始计算的，94的来源是字库中每个区最多存放94个中文字点阵。另外，因为HZK16是16×16字体，每个字由32个字节组成(16位x16)。[1]
24×24字体库中文字库与 16×16字体库的组织有些不同。HZK24T中已经存放了汉字的全角字符，其余的各种字体的汉字库16区之前是独立在此的。也就是说，对HZK24S、HZK24H、HZK24F和HZK24K，公式如下：
注意在第三步要减去15，前15区的字符存放在HZK24T中了。72表示24×24字库中汉字是按72字节存储的(24位x24)。
对于更大的字体，如32×32、48×48等，也是按照这样的方式存储。只是在第3步的计算中，32×32字体库中汉字占用 128字节，48×48字体库中汉字占用288字节。
汉字的点阵结构介绍完了，后面就面临着怎么提取字模以及显示的问题。实际上，在工具篇中已经有所涉及提取的问题了，下面两篇博客中详细描述。
和深圳某家公司合作光伏云的项目，我们主要做数据传输模块，对方负责开发云端，光伏逆变器外采。针对不同的应用场景，做了三款产品。来来回回用了一段时间，反响还不错，和其他同类产品相比还比较稳定。图一是其中一款用得较多的数据传输模块。
前一段时间现场的工程师报了一个问题，处理过程比较有趣，就记录了下来。
数据传输模块（也即数据透传模块，简称DTU）安装在逆变器上，通过串口把逆变器的数据接收过来，DTU通过GPRS(2.5G)转发给服务器。DTU最重要的是不能断网，任何情况下导致断网都必须重新连接后台，保证数据的连续性。
工程师报告，使用组态软件连接DTU（串口连接），把数据发送到服务器。数据是按包的方式定时发送的，每过5分钟会有一个包丢失。有多个设备通过组态软件连接DTU，也就是说有很多包丢失了。
接到报告后，我开始着手搭建环境，模拟现场。工程师使用的是modbus slave，我找他要来相应的版本软件。DTU与一台小的Mini台式机相连，在我自己的阿里云上运行自己写的网络调试工具。
数据包一个个发出去，几个小时下来，没有出现丢包的现象。把modbus slave换成串口调试助手，也没有出现丢包现象。我把数据包调大，大概200字节一次发送，这次出现了。
联系后台软件工程师，用他的云平台配合modslave以及DTU配合测试。其中DTU与台式机通过USB转串的设备连接，后面也尝试直接用串口线连接。经过20小时的测试，现象不大一致。使用USB转串设备进行测试的，仍旧有拆包现象；使用原生串口的，没有发现拆包现象。不过，对比了服务器的后台记录，基本没有拆包，也有命令包直接就丢失了。
百思不得其解。要后台的工程师配合我，协调起来很麻烦。我回到阿里云，用自己的网络软件模拟后台。同时把modbus slave撤了，用自己以前的代码写了个串口调试的工具，继续测试。这回，不管是usb转串的还是原生串口连接，都没有出现丢包拆包。光伏云项目中，数据获取是有后端服务器软件发起的，由其发送命令包，通过DTU传送给设备，设备再通过DTU发给服务器。在测试中还发现一个现象，如果服务器发送命令包向设备要求数据，时间频率如果设为每5秒发一次，丢包现象还会出现；设置为30秒一次，则机会没有出现丢包过。
看起来有好几个问题混杂在一起，产生了这样奇怪的现象。首先，排除DTU本身固件的问题，DTU中采用了DMA机制，以单片机的处理速度，这点串口数据不应该会处理不了。最大的问题应该有两个：
1 modbus slave和串口调试助手在串口读写的编程中，有哪个地方没有处理好，导致了拆包的现象；
2 至于丢包现象，和服务器端的软件有关。工程师可能习惯了平常的internet，没有考虑到GPRS的网络稳定性远低于有线或者wifi网络。不能过于频繁的去塞数据。
分析完了，寻找证据。第二个问题好解决，请后端工程师改下通讯频率就行了，回头一起测试。 至于第一个问题，只能反汇编modbus slave了。很幸运，用IDA反汇编后，我读了半小时代码，找到了问题所在，如图2。
问题出在SetCommTimeouts函数。定位到SetCommTimeouts函数的调用位置，其前三个参数分别为ReadIntervalTimeout=0xffffffff;ReadTotalTimeoutMultiplier=0x00; ReadTotalTimeoutConstant=0x00。也就是说，modbus slave读取一次缓冲区，读操作就完成了。
这样操作是有点问题的，对照我自己的代码，把三个参数分别改为：0x64,0x0A,0x3E8。这些修改是把exe当做文件编辑的，相当于在字节码上直接修改了。
Modbus slave的软件hack完了，重新搭建环境。4个小时后，测试结果显示，修改后的modbus slave没有出现拆包丢包现象。
题外话，大概是2017年底，开始开发DTU，用来采集光伏逆变器的数据，通过GPRS发送给后端服务器。一个不大的物联网设备，针对客户的需求做了三种不同的形态。采用的是STM32F103C8T6+SIM800C的硬件架构，软件则用FreeRTOS，方便后续的扩展。2018年4月份，国家政策一变，原计划的50K的产品计划也逐渐泡汤。我写博客前，刚好看到文件夹中满满的资料，不禁有些惆怅。先定个小计划，Foxdisk的博客写完后，也针对这个项目写写历程吧，从前期找客户、定方案、打样到量产，甚至包括采购物料、包材、后期的款项等等，可以吐槽的地方太多了。
回到正题。发现之前提供的Foxdisk的下载链接没法用了，同时也发现小工具的代码没有放上去。什么时候有人需要，我再整整吧，这段时间有点忙，有点顾不上。
Foxdisk的编译过程中，有两个小工具需要使用，EHZ24.exe和ETRHZ.exe，名字有点怪，我随便取的。EHZ24.exe是用来提取汉字字模的工具，即将需要的汉字的点阵图提取出来，方便程序去打印到屏幕上。其主要功能如下：
源代码中HZK24K.h就是由这个工具自动生成的。 ETRHZ.exe提取的是16×16的点阵字，其功能与EHZ24.exe差不多，HZTABLE.H由其提取。理论上可以把这两个程序合成一个，只是因为这两个程序是我以前开发隔离卡产品时写的，当时就这么分开的，稍微改改就拿来用了，也没兴趣去合一了。如图，两个工具简陋的命令行帮助文档。
这两个工具其实没什么可以说的，主要就是分析源文件，将程序中需要显示的汉字取出来，然后在相应的汉字库中，将对应的汉字字模提取，最后写入到生成的文件中。如图2，从生成的文件中，也能了解到其大致功能。
这两个工具的源代码比较简单，有兴趣的可以看看，过段时间我上传到博客上。源代码不难看懂，主要是要了解汉字提取的原理。
为什么要提取汉字？那是因为汉字库比较大（一般200K左右，大的400多K，Foxdisk才100多K，没法放下），我们是在无操作系统的情况下工作，程序越小越好。具体的汉字显示原理，我在接下来的几篇中记录。
有段时间一直沉迷于裸机上跑程序，学习怎么让一个操作系统跑起来。使用过VirtualPC(现在被微软收购了)，VMware，VirtualBOX，Bochs，最终还是觉得Bochs比较好用。它的最大好处是集合了完整的调试环境，对指令是软件解析的，速度虽然慢，但对程序员来说，一步步看代码是如何执行的，非常契合需求。
Bochs的文档非常的完整，使用起来也比较方便。我只针对如何调试Foxdisk，以及如何下断点进行记录，其他的可以查其自带的帮助文档。我使用的是Bochs2.2.6，帮助文档在Bochs-2.2.6\docs目录下，目前已经到了版本2.6.9，估计也差不多。
第一步是制作磁盘镜像。Bochs本身提供了镜像制作工具bximage，使用起来也比较简单。当然，也可以使用其他工具制作，比如windows下的winimage或者Linux下直接用dd命令。以制作一个4G虚拟硬盘文件为例，命令如下：
..\bximage.exe -hd -size=4096 -mode=growing -q myhd.img
Bochs的菜单栏中（我使用的是windows）提供了Disk Image Creation Tool的快捷菜单，其实就是bximage。
具体还可以参考帮助文档中Bochs User Manual-8.1 How to make a simple disk image。
第二步是编辑bochsrc.bxrc文件，指定需要启动的设备。可以启动虚拟软盘、虚拟光盘或者虚拟硬盘。找个例子看一下，修改为自己想启动的设备即可。比如虚拟硬盘，boot: c即可启动。需要提醒的是，在Foxdisk中，为了尽可能的模拟真实硬件，磁盘的参数要注意修改，一般spt=63,heads=16即可。很早以前的版本中，我的代码中没有主要到这些参数是可变的，虚拟机调试就出问题。现在的版本中，硬盘驱动的代码已经修补了这个问题，如果不去调试硬盘驱动，不必理会这些参数。双击bochsrc.bxrc即可启动，如图1，启动了一个DOS环境下的软件，当年和联想开发的一款安全计算机的界面。
图1 Bochs调试DOS程序
另外，还有一个问题，如何把需要使用的文件拷贝到虚拟硬盘中呢？我的方法比较简单，我做了一个虚拟软盘，使用winimage将需要的文件拷贝到虚拟软盘中。启动虚拟硬盘的时候，虚拟软盘作为一个挂接设备存在（注意修改bochsrc.bxrc，比如 floppya: 1_44=LBDEBUG.IMG, status=inserted ），从软盘中将文件拷贝过去即可。
一切准备就绪后，就可调试了。最后一步，启动bochsdbg.exe，命令行如下：
…\Bochs-2.2.6\bochsdbg.exe -q -f bochsrc.bxrc。断在了bios最早的位置f000:fff0上，这时就可以进入调试了。如图2所示。
图2 bochsdbg界面
如何在bochs中对Foxdisk进行调试呢？最常用的是定位在mbr区，跟踪Foxdisk的运行。即利用bochs可以对内存下断点，定位想调试的位置，进行跟踪。典型的代码运行位置，一个是mbr的0x7c00，以及Foxdisk的Code_Seg(也即0x7000处)。以mbr定位为例：
<bochs:1> lb 0x7c00 //下断点
<bochs:2>c //继续执行直到遇到断点
参考Foxdisk的代码，对照跟踪，很容易理解系统的运作原理。
总觉得bochs的调试工具和linux下gdb很类似，为便于查询，将常用的一些命令记录下来，详细的仍可参考其官方文档。
执行控制命令
c 继续执行，遇到断点将停止
step [count] 执行count条指令, 默认为1条
s [count] step的缩写
Ctrl-C 停止执行，返回命令行
Ctrl-D 执行完所有命令后，退出
q(quit) 退出调试器
设置断点
vb(vbreak) seg:off 在指定的虚拟地址（段+偏移）设置断点，在保护模式下也可以使用
lb(lbreak) addr 在一个线性地址设置断点
pb(pbreak) [*] addr 在一个物理地址设置断点
info break 显示所有断点状态
d(delete) n 删除一个断点
查看内存
x /nuf addr 查看一个线性地址的内存
xp /nuf addr 查看一个物理地址的内存
n 显示多少个单位的内存
u 内存单位大小，可以是
b: 字节; h: 字（2个字节）; w: 双字（4个字节）; g : 4字(8字节)
f 打印格式，可以是
x: 16进制格式打印; d: 10进制格式打印; u: 无符号10进制格式打印;
o: 8进制格式打印; t: 2进制格式打印
寄存器操作
Info registers 列举CPU整型寄存器内容
dump_cpu 查看所有与CPU相关的寄存器状态
where 打印当前call stack
set $reg=val 改变寄存器的内容，如set $edx=25
最奇怪的是，在安装Foxdisk的时候，颜色会不对，到现在我也没搞清楚怎么回事。
在开发过程中，我主要采用两种方式进行调试，一是使用Debug.exe，通过U盘或者光盘，启动DOS，用debug观察程序是否如想象中的写入硬盘指定区域。在早期的版本中，我也曾经去除了写硬盘以及替换MBR的功能，编译了可以在DOS下运行的Foxdisk，方便自己在DOS下对其进行调试。Debug是个很好的工具，当年开发隔离卡和双网隔离计算机的所有底层代码，均是依靠它来进行的，简单而强大。
另外一种调试方式则必须借助虚拟机了，我最常用的是使用bochs，它自带的调试功能，允许程序员看到所有的执行过程，当然也包括MBR的运行，以及如何把控制权转交给Foxdisk。因为Foxdisk是图形模式，进入图形模式之后，debug就没办法发挥作用了，后期所有的开发调试都是借助了bochs才得以进行下去。
当然，所有的调试环境使用的都是X86的汇编代码，intel指令集的参考书得常备手边。
Debug的命令不多，如图1所示，大概20几条，很容易记忆。
图1 debug常用命令
以一个例子开始debug的使用，尝试用debug将MBR区（也即硬盘线性地址LBA0）的512字节读出，并存到文件mbr.bin中。在当年流行mbr病毒的时候，这是经常使用的方法。
如图2，使用命令’a’，编写一串汇编指令。
图2 读取mbr
Debug中所有数据缺省都是16进制的，int 13实际上表示的是int 0x13（或者说int 13h）。使用int 0x13的02功能，读取mbr所在的位置（磁头0，磁柱0，扇区1）的数据，并拷贝到内存偏移0x200处（当前段）。
使用命令’d’查看读取到的数据。这是Foxdisk中Loader.asm编译后的二进制码，安装的时候写入到了mbr区域。
图3 写数据到文件
如图3，命令’w’将把BX:CX寄存器中指定字节数的内容写磁盘文件。因此，首先用命令’r’修改寄存器bx和cx。示例中需要保存的字节数为512个，因此，bx=0,cx=0x200。
‘w 200’的含义是将ds:0x200处的开始的数据，保存指定的字节数到文件中。
为了便于调试，Foxdisk中有些地方插入了标志字符串，比如Loader.asm开始的“LUOB”，这其实也是为了便于debug定位问题。
特将debug常用的命令记录在此，方便之后查看。
-? 显示 Debug 命令列表
-a [address] 指定键入汇编语言指令的位置。对 address 使用十六进制值，并键入不以
“h”字符结尾的每个值。如果不指定地址，a 将在它上次停止处开始汇编。
-d [range] 指定要显示其内容的内存区域的起始和结束地址，或起始地址和长度。有如
果不指定 range，Debug 程序将从以前 d 命令中所指定的地址范围的末尾
开始显示 128 个字节的内容。
-t [=address] 从指定地址起执行一条指令后停下来，显示所有寄存器内容及标志位的
值。如未指定地址则从当前的CS：IP开始执行。
-p [=address] 从指定地址起执行指令，直到遇到断点，如未指定地址则从当前的CS：
IP开始执行。
-g [=address] 从指定内存地址运行当前在内存中的程序。
-u [range] 对指定范围内的存储单元进行反汇编。
-r [register] ‘r’显示CPU内所有寄存器内容和标志位状态，‘r register name’则修改
某个寄存器内容。比如-r ax 修改寄存器ax的内容。
-q 退出debug。
1,940 total views, 1 views today
Loader.asm控制权转交给BootEntry后，开始启动Foxdisk的主体代码。BootEntry()函数中，只调用了Foxdisk()函数。BootEntry没有其他作用，只是用来定位的，方便Loader.asm去加载。
看代码前，首先熟悉一下将要用到的结构体，定义在Common.h中。
图1 数据结构对应图
程序中允许安装四个不同的操作系统，每个系统的引导代码Foxdisk都会保存起来，理论上可以兼容所有类型的操作系统。如图1，准备了四个导航条与之对应。数据结构navBar定义了导航条的显示资料，包括字体、字符串、颜色等等；数据结构menuitem则定义了与导航条连接的菜单项的显示资料。数据结构_WallPaper是壁纸的数据结构，包含壁纸存放在硬盘中的位置及其是否有效。壁纸从1024×768的bmp中提取，没有压缩，直接存储在硬盘上，其大小为1024×768 bit。总共可以存7张不同的壁纸，在安装的时候指定。
数据结构OperationSystem对应每个导航条指定的系统，允许用户添加密码。数据结构FoxdiskPara定义了Foxdisk所用的必要信息，包括倒计时时间、默认进入的系统、foxdisk的存储位置等。
在以上数据结构的支持下，Foxdisk的启动才得以实现。在foxdisk()中，第一步启用磁盘访问的驱动，建立硬盘参数表，允许硬盘访问。第二步，获取FoxdiskPara等参数，这些参数在安装的时候已经存储在硬盘上了，接着调用bootMenu()。出现指定的壁纸及倒计时信息。如下图。
图2 启动界面
这是指定了壁纸的启动界面，如果没有指定，则启动缺省的foxdisk界面，如图3。
图3 缺省启动界面
在启动界面上，如果按F2键，则进入Foxdisk的设置界面，类似图1。如果不按，倒计时结束将进入显示中正在进入的系统。当时为了设计右下角的显示信息，也费了一番功夫。最大的问题是，如何在不同的图片上，能够将倒计时的数据显示出来。固定颜色是不行的，很难保证图片颜色与倒计时颜色不同。最终用了些小技巧，用反色、倒影的方式进行显示，解决了这个问题。
读到现在，我也发现之前设计上的不足，很多地方过于繁复了，有些需要显示的信息，比如当前有哪些操作系统，在界面上却没有显示。
最后一步，调用SysRun()。也即在第二步中，如果按F2，将执行此处代码，进入Foxdisk的设置界面。
图4 设置界面
设置界面的右下角提供了快捷选项。F1键唤出帮助界面；F2键为系统菜单，也即类似图1中显示的界面；F3键唤出参数设定，如图4显示；F4键还没有实现；F5键唤出关于菜单，打印关于Foxdisk的一些说明。
至此，所有启动相关的信息全部介绍完毕。Foxdisk在运行过程中，需要用到硬盘访问、分区设置、图形显示、汉字显示、时间中断等，最早曾经把扬声器也放进去了，觉得没有太大作用，后来把它去除了。
后续的博客中，将针对上述实现一一阐述，记下我在秦淮河畔曾经挥汗调试的日子。
1,475 total views, 2 views today