UEFI开发探索01-起篇

2013年的时候,和联想的双网安全隔离计算机项目进入了平稳阶段。经过了前今年的合作开发,几代不同的产品的磨合,Q45、G41、H61等,整个方案已经成熟。再开案的话,我觉得大部分问题都会集中在硬件方面,软件问题不会太多。

不过,当时实际上软件还留下一个问题需要想办法解决,那就是Option ROM对UEFI的支持。在12年出货的产品中,因为时间比较紧,为了把Option ROM移植到UEFI下(联想2011年左右基本都转换为UEFI BIOS),我采用了一种比较省事的方法,用AMI的VBE来开发。主要是考虑到有问题可以去请教联想的BIOS工程师,让我这个虽然号称底层比较熟悉,但没有实操过BIOS开发的人,这是种比较保险的做法。

因此,即便我了解intel提供了UDK可以直接进行开发,我仍旧走了上述的路线。当时的开发很难,从VBE新手到开发出符合要求的UEFI driver(实际上就是个option rom),花了我三个礼拜,像打了鸡血一样不眠不休的完成了。在此要感谢当时还在Intel的Raymond,张银奎老师,帮我向intel bios部门咨询解决了显示的一个问题。以及我刚出生没多久的宝贝,因为她我才在北京待不住,用了最快的速度解决了这个项目问题,就为了早一刻回南京抱她。

所以,2013年的时候,摆在我面前的问题是,如何用intel UDK把Option ROM开发出来,一方面用在联想的合作项目上;另外一方面,把它用在公司的另外一个产品-隔离卡上。随着UEFI越来越普及,未来肯定会只支持UEFI,当时隔离卡上面的Legacy oprom会无法运行的。几年过去了,这个论断终于实现了。现在是2019年,公司就是因为当时的这个技术设计,今年3月还没过完,半个月的销量,超过了去年同期一个月的销量了。我甚是欣慰。

当时的时间比较充裕,毕竟和联想的案子已经有一个可用的软件版本了,而隔离卡这边的需求还没到时候。仿照之前学习底层开发的过程,我制定了一个小计划,从控制键盘、图形显示、鼠标显示、访问PCI端口、SMBUS通讯、USB访问、网络访问….这样的顺序开始尝试写代码。虽然因为各种原因,在完成了最初的目标(支持公司产品在UDK下的开发)后,有些工作没有继续了。但我觉得还是基本上把UEFI下的开发实现了,即便要开发其他的产品,现有的代码也能非常好的用上。

图1 robin’s Uefi 代码列表

在最早开始写博客的时,我就计划把这段历程写下来。今天终于如愿开始了,记录我挥汗编程的日日夜夜,也纪念我当时用来开发的华硕945主板的机器,跟了我那么多年,终于没有机会再使用它了。

是为开篇。

发表在 BIOS/UEFI | 留下评论

Foxdisk10-小字库显示汉字1

在以前的博客中曾经讨论过,设计的Foxdisk代码段和数据段总共只能128K。可是随便哪个汉字库轻轻松松都超过了100K,大的有近500K(我设计的时候只用了24×24以及16×16的字模),无论如何是不能包含在程序中的。唯一的办法,是将需要用的汉字字模提取出来,实现小字库的汉字显示。

当然,如果改变Foxdisk的设计方法,比如采用很久以前用过的一种技术:在硬盘的末端存一个裁剪的DOS或者linux,用OS来支持。现在遇到的存储空间不够啊、想实现的功能难以实现啊,都能解决。并且还能复用大量的DOS/Linux的软件,还是很不错的。不过,这就失去了我当时设计的初衷了,本来就是用来学习底层知识的一个小项目,用这种方法则屏蔽了大量的实现细节,所以我就放弃了。不过,在公司早期的一款产品中(卖了好几年,技术支持巨难,后来被我停掉了)是用了这种方法的,有机会也开个博客仔细探讨下。

文字显示主要包括文字的读取和显示两个步骤。西方文字显示完全可以集成在一个ROM内,但是中文字太多,通常都要用到字库。中文字库有两大类型:点阵式字库和矢量字库。

点阵式字库是通过将中文字看成一个个点组成的二维阵列来实现显示;矢量字库则通过对文字每个笔划的起始点和结束点的记录来完成文字显示。很明显,点阵字如果要放大文字将会出现明显的不平滑现象;而矢量字无论字的大小都可以保证字体圆滑。但是由于点阵字理解简单、便于编程等原因,在很多领域点阵字库成为了主流。

当前只针对点阵字库进行讨论研究,并针对研究的各字体库进行分析,阐述其在编程上的一些区别。在此基础上,提供了无字库方案的实现过程及代码。 点阵字的显示原理其实很简单。在规定大小的区域格内,如16×16、24×24等,将需要显示的字的对应格填充即可。字库内对应的格则以1表示,没有填充的以0表示。如图所示:

图1 英文字模图样

这是英文字模的图样,而中文字模的图样是这样的:

图2 中文字模的图样

图中的字模信息就存储在相应的字库中,而程序员就可以按照显示原理在显示器上以点位的方式显示字符。

每个英文字母都是由一个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的中汉字存储可以用公式表示如下:

  • 区码 = 文字左半边信息(扩展ASCII码) – 0xA0
  • 位码 = 文字右半边信息 – 0xA0
  • 在字库中的地址 = [(区码-1) *94 + (位码-1)] * 32

其中1、2步减去0xA0的原因是中文字符用到的扩展ASCII码是从0xA0之后开始计算的,94的来源是字库中每个区最多存放94个中文字点阵。另外,因为HZK16是16×16字体,每个字由32个字节组成(16位x16)。[1]

24×24字体库中文字库与 16×16字体库的组织有些不同。HZK24T中已经存放了汉字的全角字符,其余的各种字体的汉字库16区之前是独立在此的。也就是说,对HZK24S、HZK24H、HZK24F和HZK24K,公式如下:

  • 区码 = 文字左半边信息(扩展ASCII码) – 0xA0
  • 位码 = 文字右半边信息 – 0xA0
  • 在字库中的地址 = [(区码-1- 15) *94 + (位码-1)] * 72

注意在第三步要减去15,前15区的字符存放在HZK24T中了。72表示24×24字库中汉字是按72字节存储的(24位x24)。

对于更大的字体,如32×32、48×48等,也是按照这样的方式存储。只是在第3步的计算中,32×32字体库中汉字占用 128字节,48×48字体库中汉字占用288字节。

汉字的点阵结构介绍完了,后面就面临着怎么提取字模以及显示的问题。实际上,在工具篇中已经有所涉及提取的问题了,下面两篇博客中详细描述。

发表在 BIOS/UEFI | 留下评论

光伏云项目杂记01—modbus串口丢包了

和深圳某家公司合作光伏云的项目,我们主要做数据传输模块,对方负责开发云端,光伏逆变器外采。针对不同的应用场景,做了三款产品。来来回回用了一段时间,反响还不错,和其他同类产品相比还比较稳定。图一是其中一款用得较多的数据传输模块。

图1 物联网透传设备-gprs dtu

前一段时间现场的工程师报了一个问题,处理过程比较有趣,就记录了下来。

数据传输模块(也即数据透传模块,简称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。

图2 用IDA反汇编modbus slave

问题出在SetCommTimeouts函数。定位到SetCommTimeouts函数的调用位置,其前三个参数分别为ReadIntervalTimeout=0xffffffff;ReadTotalTimeoutMultiplier=0x00; ReadTotalTimeoutConstant=0x00。也就是说,modbus slave读取一次缓冲区,读操作就完成了。

这样操作是有点问题的,对照我自己的代码,把三个参数分别改为:0x64,0x0A,0x3E8。这些修改是把exe当做文件编辑的,相当于在字节码上直接修改了。

Modbus slave的软件hack完了,重新搭建环境。4个小时后,测试结果显示,修改后的modbus slave没有出现拆包丢包现象。

发表在 IoT | 留下评论

Foxdisk09-工具篇

题外话,大概是2017年底,开始开发DTU,用来采集光伏逆变器的数据,通过GPRS发送给后端服务器。一个不大的物联网设备,针对客户的需求做了三种不同的形态。采用的是STM32F103C8T6+SIM800C的硬件架构,软件则用FreeRTOS,方便后续的扩展。2018年4月份,国家政策一变,原计划的50K的产品计划也逐渐泡汤。我写博客前,刚好看到文件夹中满满的资料,不禁有些惆怅。先定个小计划,Foxdisk的博客写完后,也针对这个项目写写历程吧,从前期找客户、定方案、打样到量产,甚至包括采购物料、包材、后期的款项等等,可以吐槽的地方太多了。

回到正题。发现之前提供的Foxdisk的下载链接没法用了,同时也发现小工具的代码没有放上去。什么时候有人需要,我再整整吧,这段时间有点忙,有点顾不上。

Foxdisk的编译过程中,有两个小工具需要使用,EHZ24.exe和ETRHZ.exe,名字有点怪,我随便取的。EHZ24.exe是用来提取汉字字模的工具,即将需要的汉字的点阵图提取出来,方便程序去打印到屏幕上。其主要功能如下:

  1. 可以针对多个源文件进行处理,提取C语言源代码中需要显示的汉字;
  2. 可指定提取的字模为楷体、黑体或者仿宋,字模为24×24点阵字;
  3. 提取出来的字模,自动生成一个.h的头文件,并在头文件中定义了字模的结构体。

源代码中HZK24K.h就是由这个工具自动生成的。 ETRHZ.exe提取的是16×16的点阵字,其功能与EHZ24.exe差不多,HZTABLE.H由其提取。理论上可以把这两个程序合成一个,只是因为这两个程序是我以前开发隔离卡产品时写的,当时就这么分开的,稍微改改就拿来用了,也没兴趣去合一了。如图,两个工具简陋的命令行帮助文档。

图1 汉字提取工具ETRHZ和EHZ24

这两个工具其实没什么可以说的,主要就是分析源文件,将程序中需要显示的汉字取出来,然后在相应的汉字库中,将对应的汉字字模提取,最后写入到生成的文件中。如图2,从生成的文件中,也能了解到其大致功能。

图2 ETRHZ提取的文件截图

这两个工具的源代码比较简单,有兴趣的可以看看,过段时间我上传到博客上。源代码不难看懂,主要是要了解汉字提取的原理。

为什么要提取汉字?那是因为汉字库比较大(一般200K左右,大的400多K,Foxdisk才100多K,没法放下),我们是在无操作系统的情况下工作,程序越小越好。具体的汉字显示原理,我在接下来的几篇中记录。

发表在 BIOS/UEFI | 留下评论

Foxdisk08-如何调试2

有段时间一直沉迷于裸机上跑程序,学习怎么让一个操作系统跑起来。使用过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的时候,颜色会不对,到现在我也没搞清楚怎么回事。

图3 Bochs安装Foxdisk-变色了

发表在 BIOS/UEFI | 留下评论

Foxdisk07-如何调试1

在开发过程中,我主要采用两种方式进行调试,一是使用Debug.exe,通过U盘或者光盘,启动DOS,用debug观察程序是否如想象中的写入硬盘指定区域。在早期的版本中,我也曾经去除了写硬盘以及替换MBR的功能,编译了可以在DOS下运行的Foxdisk,方便自己在DOS下对其进行调试。Debug是个很好的工具,当年开发隔离卡和双网隔离计算机的所有底层代码,均是依靠它来进行的,简单而强大。

另外一种调试方式则必须借助虚拟机了,我最常用的是使用bochs,它自带的调试功能,允许程序员看到所有的执行过程,当然也包括MBR的运行,以及如何把控制权转交给Foxdisk。因为Foxdisk是图形模式,进入图形模式之后,debug就没办法发挥作用了,后期所有的开发调试都是借助了bochs才得以进行下去。

当然,所有的调试环境使用的都是X86的汇编代码,intel指令集的参考书得常备手边。
Debug的命令不多,如图1所示,大概20几条,很容易记忆。
Foxdisk07-debuglist

图1 debug常用命令

以一个例子开始debug的使用,尝试用debug将MBR区(也即硬盘线性地址LBA0)的512字节读出,并存到文件mbr.bin中。在当年流行mbr病毒的时候,这是经常使用的方法。

如图2,使用命令’a’,编写一串汇编指令。
Foxdisk07-readmbr

图2 读取mbr

Debug中所有数据缺省都是16进制的,int 13实际上表示的是int 0x13(或者说int 13h)。使用int 0x13的02功能,读取mbr所在的位置(磁头0,磁柱0,扇区1)的数据,并拷贝到内存偏移0x200处(当前段)。

使用命令’d’查看读取到的数据。这是Foxdisk中Loader.asm编译后的二进制码,安装的时候写入到了mbr区域。
Foxdisk07-mbr2file

图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。

发表在 BIOS/UEFI | 留下评论

Foxdisk06-启动原理3

Loader.asm控制权转交给BootEntry后,开始启动Foxdisk的主体代码。BootEntry()函数中,只调用了Foxdisk()函数。BootEntry没有其他作用,只是用来定位的,方便Loader.asm去加载。

看代码前,首先熟悉一下将要用到的结构体,定义在Common.h中。
Foxdisk06-datastruct

图1 数据结构对应图

程序中允许安装四个不同的操作系统,每个系统的引导代码Foxdisk都会保存起来,理论上可以兼容所有类型的操作系统。如图1,准备了四个导航条与之对应。数据结构navBar定义了导航条的显示资料,包括字体、字符串、颜色等等;数据结构menuitem则定义了与导航条连接的菜单项的显示资料。数据结构_WallPaper是壁纸的数据结构,包含壁纸存放在硬盘中的位置及其是否有效。壁纸从1024×768的bmp中提取,没有压缩,直接存储在硬盘上,其大小为1024×768 bit。总共可以存7张不同的壁纸,在安装的时候指定。

数据结构OperationSystem对应每个导航条指定的系统,允许用户添加密码。数据结构FoxdiskPara定义了Foxdisk所用的必要信息,包括倒计时时间、默认进入的系统、foxdisk的存储位置等。

在以上数据结构的支持下,Foxdisk的启动才得以实现。在foxdisk()中,第一步启用磁盘访问的驱动,建立硬盘参数表,允许硬盘访问。第二步,获取FoxdiskPara等参数,这些参数在安装的时候已经存储在硬盘上了,接着调用bootMenu()。出现指定的壁纸及倒计时信息。如下图。
Foxdisk06-bootmenu

图2 启动界面

这是指定了壁纸的启动界面,如果没有指定,则启动缺省的foxdisk界面,如图3。
Foxdisk06-defbootmenu

图3 缺省启动界面

在启动界面上,如果按F2键,则进入Foxdisk的设置界面,类似图1。如果不按,倒计时结束将进入显示中正在进入的系统。当时为了设计右下角的显示信息,也费了一番功夫。最大的问题是,如何在不同的图片上,能够将倒计时的数据显示出来。固定颜色是不行的,很难保证图片颜色与倒计时颜色不同。最终用了些小技巧,用反色、倒影的方式进行显示,解决了这个问题。

读到现在,我也发现之前设计上的不足,很多地方过于繁复了,有些需要显示的信息,比如当前有哪些操作系统,在界面上却没有显示。

最后一步,调用SysRun()。也即在第二步中,如果按F2,将执行此处代码,进入Foxdisk的设置界面。
Foxdisk06-configmenu

图4 设置界面

设置界面的右下角提供了快捷选项。F1键唤出帮助界面;F2键为系统菜单,也即类似图1中显示的界面;F3键唤出参数设定,如图4显示;F4键还没有实现;F5键唤出关于菜单,打印关于Foxdisk的一些说明。

至此,所有启动相关的信息全部介绍完毕。Foxdisk在运行过程中,需要用到硬盘访问、分区设置、图形显示、汉字显示、时间中断等,最早曾经把扬声器也放进去了,觉得没有太大作用,后来把它去除了。

后续的博客中,将针对上述实现一一阐述,记下我在秦淮河畔曾经挥汗调试的日子。

发表在 BIOS/UEFI | 留下评论

Foxdisk05-启动原理2

观察Foxdisk3的makefile,可以看到使用的是bcc -ms的编译开关。这是要求编译器采用Samll内存模式进行编译,其特点是栈和数据都在64K以内,Code在另外一个64K内。为什么采用Small方式?主要是我当时设计的时候,没有考虑到后面的各种新的需求,以为代码可以控制在64K内完成;另外,这种模式比较便于汇编和C的混合编写,不用去考虑复杂的数据段、代码段的定位。

在整个代码编写过程中,除了引导部分(也即Loader.asm),其他的代码尽量用C编写。但是有两部分的代码仍旧无法避免使用汇编,一是时钟中断,为了让几个任务并行工作,使用了汇编;二是32位数的乘除计算。我们在平常使用C/C++及其他高级语言的时候,大数的计算很平常。那是因为编译器已经提供了库函数调用,方便程序员使用,操作系统已经提供了这样的机制进行支持。Foxdisk某种程度上相当于简单的操作系统,这些机制完全没有提供。因此,在进行大数计算时,只能自己来写这些函数了。

回到我们的启动话题。Loader.asm包含了所有启动的秘密,其承载了将Foxdisk的演出场景安排好的任务,相当于整个程序的导演,也是整个程序最难读的地方。我试着以自己的语言,将其原理解释清楚。

Loader.asm在编译后,将链接成一段512字节的二进制码。当然,它不是单独存在的,是与其他代码混杂着存在于Foxdisk.exe中。这段512字节码将由Setup.c中的main()函数拷贝到MBR区,起到引导的作用。

Bios在释放控制权的时候,将把MBR区的代码加载到0x7C00处,并跳转执行。也即从Loader.asm中的load_start处开始执行。

整个Loader.asm实现的功能可以概括为三个:1) 将存储在硬盘上的Foxdisk代码拷贝到指定的内存;2)将Foxdisk运行的数据拷贝到另外一段64K的内存中;3) 设定栈,并远程跳转(retf)至Foxdisk的BootEntry处,开始运行Foxdisk。Loader.asm中的几个变量,nCodeSect:Foxdisk代码段占用的硬盘扇区数;nDataSect:Foxdisk数据段占用的扇区数;iBegin: Foxdisk程序镜像所存储的硬盘起始位置;这些变量均由Setup.c中的函数进行初始化,也即安装的时候确定。另外一个变量iDisk,其值为0x80或者0x81,表示BIOS所认的第一个硬盘还是第二个硬盘,也是由Setup.c中函数对其进行初始化的。如果Foxdisk镜像存储在第二个硬盘上,则必须设置为0x81。现在想来,其作用不大,而且容易给调试带来麻烦。

load_start到load_chs,尝试使用扩展中断0x13(ah=0x40以上的int 0x13)访问磁盘中的数据,加载Foxdisk的代码段至0x7000:0起始的64K内存,数据段加载至0x8000:0开始的64K内存。

如果磁盘不支持磁盘的扩展中断(这种情况基本不可能),则回到原始的硬盘访问中断,尝试将Foxdisk的代码段和数据段加载到指定的内存中。从load_chs到load_ok间做的就是这件事,其功能与上一段其实是相同的,大部分情况下也不会执行。

从标志load_ok开始,进行设置栈以及跳转的工作。Retf是条远跳转指令,它将栈中的4个字节当成CS:IP,跳转过去执行。以上工作均在实模式下进行,不用考虑复杂的权限问题。注意,在retf执行前,bx中已经包含了BootEntry的地址,执行前的push bx就是将地址压栈,准备远程跳转。

至此,我们可以暂时抛去晦涩难懂的汇编,进入了C的世界。

下一篇博客是启动原理的最后一篇,介绍Foxdisk的整体逻辑框架,从逻辑层面介绍我是如何编排实现Foxdisk的功能。

发表在 BIOS/UEFI | 留下评论

用“忙碌度”来度量设备虚拟化的性能

本文讨论设备性能的一般度量方法,并根据性能判断的基准点是否确定唯一,将设备性能分为外部性能内部性能 两类。

外部性能

我们采用很多方法来量化一个设备的性能,一般是横向比较,也就是运行一些基准测试软件来获得针对指定设备的测试成绩,作为度量设备性能的量化数据。但是,如果只有单个设备的量化成绩,其实作用不大。100分的成绩,对应的性能到底为高、中或低,需要和更多的设备进行横向比较,才能体现出来。业界会针对某类设备,设立若干个性能相关的标杆基准点,来判别不同的量化分数所对应的性能级别。值得注意的是,这个所谓的标杆基准点,可能是有形的数字,但更可能是无形的,由一些评测实验室在他们的评测报告中体现,当一款新的旗舰设备隆重上市后,旧标杆将随之被修正。

换句话说,通过横向比较为来判断性能时,在不同的时间,比较和判断的标杆基准点很可能是不同的。如果你淘了一块心仪已久的两年前的旗舰显卡,欣欣然准备要大显身手的时候,重新评估一下这块显卡在今天的性能地位,发现已经掉档到入门级别了,你可能会大失所望吧。设备本身的性能并未改变,变化的是评判的标准。

硬件生产工艺的进步,会带来设备性能的大幅提升,特别是摩尔定律还在发生作用的年代,这个提升的幅度是指数级别的,非常惊人。影响性能成绩的另一个因素,是测试软件自身的代码演进和优化程度。一个并不罕见的情况是,使用不同的基准测试软件,对不同的设备进行测试,如果这些设备在市场上的目标定位相同,最后的测试成绩很可能互有参差,而不是一边倒地断定出孰优孰劣。在某个测试软件中,A产品领先一些,另一个测试软件中,B产品则略胜一筹。还有一种情况是,将某个基准测试软件版本升级之后,重新测试某产品,可能会发现结果大不相同。再比如,同一块显卡上,使用不同的3D编程接口(如OpenGL、DX或其它),在渲染相同的内容时,性能也可能不同。这是3D编程接口需要不断迭代升级的一个原因,如何通过优化自身的结构,来更好地发挥硬件的有限性能。

软件的编程方式和优化特性的选择,对不同的设备会产生不同的性能表现。

这种通过外部横向比较而产生的性能数据和判断依据,称为外部性能。其典型特征是:性能的判断依据不断变化——主要地,其性能基准点不断地被提高。

内部性能

继续阅读

发表在 虚拟化 | 标签为 | 留下评论

随笔-放慢心态1

按照现在的工作状态,实在无法保证之前的技术博客按计划进行。在罪恶感的驱使下,我拿了自己无聊时写的随笔,用来充数。看看一个仍旧奋战在一线的程序员,如何在万恶的房价经济社会中,如何苦苦挣扎。

连续两周出差,身体严重透支。正好有一个小时的时间,在等一位朋友过来。用来整理技术文章是不够,正好把这一小段时间的感想记录下来。

人生过了三十岁,时间的齿轮好像突然加快,仿佛总是处在一个“时间不够”的状态。要学习新的东西、要照顾家庭、各种朋友应酬…忙来忙去,最后都忘记了自己为了什么在忙碌。

龙应台有本书《孩子你慢慢来》,我曾经在出差途中看完。有段话,这么写的,对比得很有意境:“淡水的街头,阳光斜照着窄巷里这间零乱的花铺。 回教徒和犹太人在彼此屠杀,衣索匹亚的老弱妇孺在一个接一个地饿死,纽约华尔街的证券市场挤满了表情紧张的人——我,坐在斜阳浅照的石阶上,愿意等上一辈子的时间,让这个孩子从从容容地把那个蝴蝶结扎好,用他五岁的手指。”

我很喜欢这段话。生活从来就不美好,世界残酷而真实,美好只存在于我们的内心,那些你所珍惜的事物,导引了我们生活的方向。

大学的第一年,元旦第一天,我一个人坐在三工教学楼的某个教室里面,努力准备马上要考试的科目。第一场雪就在那个时候下起来了,我看着窗外,就这么呆呆的看着雪坐了一个上午。

那时的自己,仿佛青春永远都会在,未来的日子总感觉非常遥远。除了不时会冒出来的考试,踢球、泡图书馆、看漫画,无聊时可以花两个礼拜画一张图,从容天真。

离开学校后,画风变了。如果每个人的生活都是一场电影,那么,在离开学校的这十几年,每一帧都充满了急躁,对未来的恐惧。 继续阅读

发表在 论学谈文 | 3条评论