UEFI开发探索02 – 环境搭建1

开发初期的目的就是做出可以在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进行探索。

先看下我常用的两款设备,用来运行实际代码的。

图1 带有smbus与usb hid通讯功能的切换卡
图2 带PCI-E扩展ROM的切换卡

图1的卡带有smbus通讯和usb hid通讯功能,是在与联想、方正合作项目中,开发双网安全隔离计算机所用的卡。图2 是公司目前在销售的产品,带有PCI-E扩展ROM,是一种用来隔离硬盘和网络的产品。

第一款设备没有扩展ROM,我是以uefi driver的方式提供oprom,bios工程师将oprom编译在bios一起,访问设备的。第二款是将oprom代码直接写入rom中,不需要bios工程师的配合,做起实验来比较方便。

两个设备上有大量与我们实验无关的元器件,大部分是用来切换网络、硬盘、USB的,以及供电电路。最近正在考虑把这两种设备合在一起,做一个实验板,不知道有没有人有需求。

啰啰嗦嗦交待了一大堆的前言,回到搭建软件的编译环境。

使用intel提供的UDK来搭建即可。以前是在sourceforge.net上下载UDK,地址:https://sourceforge.net/projects/edk2/files/。我当时用的是UDK2010,刚才查看了一下,sourceforge上已经有了UDK2015,而在github上已经有了UDK2017了。

嗯,周末我再研究一下,看看选择哪个环境比较合适。

Foxdisk11-无字库显示汉字2

刚从大学毕业那会,对操作系统极其入迷,总想搞清楚底层是怎么运行的。其中最感兴趣的是图形的显示,BIOS对硬件的控制等。找了很多资料看,正好公司的一些项目上也需要用到,就这么磕磕碰碰的实现了各种显示的代码。

Foxdisk的代码中,Vesa.c和Vesa.h就包含了显示的所有信息。主要是遵循了vesa的标准进行显示,采用C嵌汇编的方式来编写。目前,几乎所有的机器都支持VESA标准,而在X86平台下编程就是基于此标准的。VESA标准在原有BIOS提供的API的基础上,提供了一组扩展BIOS功能调用。对于标准VGA下的模式,仍然可以使用基本BIOS调用,但对于扩展模式,其许多操作如模式设置及视频缓冲读写等,则只能通过VESA标准提供的扩展BIOS来实现。

在VESA标准下,视频缓冲是以分页映射的方式进行操作。其基窗口一般为在0xA0000处,每页为64K。整个视频缓冲都通过映射到此窗口而得以直接存取。一般的图形编程步骤如下:

  • 设置显示模式(如0x103为 800×600 256色的配置)
  • 设置颜色寄存器
  • 按照图形显示的原理编写画点、画线、画圆等基本函数。

过多的细节不用纠结,Vesa.c中提供了画点函数putpixel256()。把屏幕当做一个大画布,设置模式的时候知道这块画布多大,用画点函数绘制即可。Foxdisk使用的是模式0x105,也即1024×768,256色。想像一下,有张宽1024像素点,长768像素点的画布,有支可在画布任何坐标处画点的笔,应该是什么画都可以画出来了,包括汉字。

Foxdisk中显示汉字,大致可以分为两步:

  1. 提取需要的汉字字模,保存到程序内部;
  2. 调用Font.c中显示汉字的函数,将需要的汉字显示在屏幕上。

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行左右。核心工作在于分析指定的文件,从中提取出需要转换字模的汉字。

为了便于分析,也为了程序编写简单,对指定的文件是有要求的。必须保证在提取的文件中字符串中没有//和/* 字符,否则可能会提取错误。提取程序并没有去进行字符串内部的语义分析,否则要处理的情况太多了。 代码就不贴出来了,放不下。对照编程的想法,以及代码,还是比较容易看明白运作的机制的。

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主板的机器,跟了我那么多年,终于没有机会再使用它了。

是为开篇。

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字节。

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

光伏云项目杂记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没有出现拆包丢包现象。

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,没法放下),我们是在无操作系统的情况下工作,程序越小越好。具体的汉字显示原理,我在接下来的几篇中记录。