Foxdisk12 – 图形显示1

请保留-> 【原文: http://yiiyee.cn/blog/author/luobing/】

最近在写UEFI博客的时候,遇到些阻碍。我想移植一款开源的GUI到UEFI下,目前还没有找到。不过,博客开天窗这么久,总是不像话,所以回来继续写Foxdisk的博客了。

Foxdisk的博客更新较慢,主要是觉得这些都是Legacy BIOS下的东西,可能想了解的人不多,我也是随性而写,并不制定计划。

使用Foxdisk3的代码,很难演示如何进行图形编程。因此,我还是使用平常调试用的程序框架来说明。所有的代码,都是在DOS下实验通过,然后再移植到Foxdisk3的代码中去的。

特别说明,Foxdisk3只针对Legacy BIOS,所有访问硬盘、图形显示、键盘访问以及时钟中断的构建,都是在Legacy BIOS的架构下进行的。如想了解UEFI BIOS下如何编写类似代码,请移步我的另一博客-《UFEI开发探索系列》

1 编译和运行环境

我以前都是在虚拟机下调试,使用的是VirtualPC2.5以及Bochs,偶尔也用过Virtual BOX和Vmware构建。每种环境都各有优缺点,比如Bochs的调试环境非常完备,不过显示的时候颜色有时候会很奇怪。

如果只是演示图形编程的话,我觉得DosBox比较好:启动快、DOS环境模拟得很好。我使用的是DosBox v0.74-2,到网上去找即可,免费的。

图1 DosBOX
继续阅读“Foxdisk12 – 图形显示1”

17 total views, 7 views today

Zephyr系统快评

请保留:【作者:张佩】 【原文:www.yiiyee.cn/blog】

Zephry是Linux基金会托管的一个嵌入式RTOS系统,主导开发的是Intel。我对这个系统进行了学习之后,得到了下面的5条总体认识。

  1. Zephyr的内核模式是宏内核,不是微内核;设备驱动都被集成在内核中;内核编译采用Kconfig脚本配置,资源配置也通过它在编译时指定
  2. Zephyr支持的平台:arm、x86、RISC-v、ARC、NIOS 2、POSIX等
  3. ARM平台支持不完全:只支持arm 32系列的m/r平台,a平台不支持;同时,也不支持arm64
  4. Zephyr支持100多种嵌入式开发平台,嵌入式友好;内核size可以小至8kB
  5. Zephyr只有mpu(内存保护单元)的支持,任务之间的内存是相互隔离的,但不支持虚拟内存;多个用户应用同时运行有一定的困难,目前仅支持单应用的形式

内核实现

Zephyr采用的是标准的宏内核的架构,这对于它面向MCU进行开发是有利的。如果采用微内核的话,需要有稳健的IPC机制,不仅执行效率上有所降低,并且需要更多的代码量。

继续阅读“Zephyr系统快评”

162 total views, 2 views today

UEFI开发探索44 – 龙芯下的UEFI App和Option ROM

请保留-> 【原文: http://yiiyee.cn/blog/author/luobing/】

年初的时候,不少客户都在问,国产的电脑上是不是能用隔离方案?

工程师做了一番调查,大部分客户用的都是龙芯的电脑(3A3000)。硬件上来说,主要是看PCI/PCIE的支持情况;软件上,BIOS需要支持我们的Option ROM,操作系统上的应用程序也得重写。

总的来说,工作量不算大,也不算小,由此开始了我们几个月的产品适配过程。

图1 调试用的机器
继续阅读“UEFI开发探索44 – 龙芯下的UEFI App和Option ROM”

118 total views, no views today

UEFI开发探索 – 间幕

嗯,最近把博客移动到了CSDN上了,主要是那边比较方便查看博客:十几篇文章的标题可以在一个页面上显示。

我们的博客网站就没那么方便啦,还是比较适合个人浏览。我们俩也没那么多时间去调整,就这么继续写下去吧。

预计中的50篇,马上就要接近尾声了。我正在搜肠刮肚地寻找课题,可是感觉每个课题都特别大,比如写个uefi下的磁盘管理工具、写个类似grub的多引导工具、移植个GUI库过来等等。

都很有趣,也都很…费时间。

中年程序员大叔的时间可是很宝贵的,能压缩的时间只剩下睡觉了。再这么下去,仿佛去世多年的爷爷在河的那边正向我招手呢,模模糊糊的能看见…

总之,有兴趣的话,可以去CSDN上关注下:

https://me.csdn.net/luobing4365

当然,这里一直都会是我的主战场,不定期地更新自己的技术点滴或者感想。

最后,上一张老家的风景图。国庆的时候带娃去明月山了,温泉泡得很舒服,爬山很好玩。明月山和羊狮慕的栈道,挂在山腰,走完要两个多小时,非常有意思。

当然,不愧是AAAAA级景区,价格也不便宜,虽然大部分都是老哥付的钱^^

68 total views, 2 views today

UEFI开发探索43 – Protocol的使用2

(请保留->发布地址: http://yiiyee.cn/blog/author/luobing/ )

今天来探索上次提出的第三个问题:如何产生Protocol?

在常看的书《UEFI原理与编程》中,实际上已经介绍了如何开发UEFI服务了。他以视频解码为例,提供了一个完整的解码库。

目前对视频解码没有什么兴趣,因此,这篇内容对我来说,多余的枝节太多了。我准备构建一个比较简单的框架型代码,可以用来在屏幕上画几何图形,以熟悉如何开发Protocol。

1 UEFI Driver

相比于Windows driver,UEFI driver简单很多,大致可以分为两类:符合UEFI驱动模型的驱动和不遵循UEFI驱动模型的驱动,如图:

图1 UEFI Images – EDKII Driver Writer’s Guide section3.7
继续阅读“UEFI开发探索43 – Protocol的使用2”

60 total views, no views today

UEFI开发探索42 – Protocol的使用1

(请保留->发布地址: http://yiiyee.cn/blog/author/luobing/ )

虽然一直使用各种Protocol来实现需要的程序功能,但对其背后的原理、实现方法,一直都比较模糊。我奉行的是“先用再说”的实用主义,正好周末有点闲暇,探究一下对Protocol理解模糊的地方。

图1 Protocol的构成

如图为Protocol的结构图,摘自于UEFI Spec 2.8 page 45。

我想弄清楚的问题如下:

1) 如何使用Protocol服务?
2) Protocol这种机制在UEFI中是如何实现的?
3) 如何实现一个Protocol?

继续阅读“UEFI开发探索42 – Protocol的使用1”

115 total views, no views today

UEFI开发探索41 – Event、Timer和任务优先级

(请保留->发布地址: http://yiiyee.cn/blog/author/luobing/ )

作为一个底层的支持系统,UEFI没有支持中断。如果想支持异步操作,只能通过事件(Event)来实现。

在开发Foxdisk的过程中,也遇到需要同时处理的事件。比如提示用户输入的闪烁光标、自动显示的系统时间等,我是采用了时钟中断(int 1Ch)的方式来实现的,是段很有意思的程序。

不过,我只是简单地将需要的功能堆砌在int 1Ch中实现,并没有完整地实现多任务间的互斥,是一种“伪多任务”的实现。那么,UEFI中是怎么来支持多个任务同时执行呢?

1 支持的服务函数

图1为相关的服务函数,总共10个:

图1 事件相关服务函数
继续阅读“UEFI开发探索41 – Event、Timer和任务优先级”

437 total views, no views today

鸿蒙OS速览

请保留 -> 【作者:张佩】【原文:www.yiiyee.cn/blog

鸿蒙在HDC 2019上作为最重要的产品被隆重推出,现在已经为世人所知。它的三个重要特点是:

第一,它基于微内核的实现,可以很好地运行于IoT及安全相关的嵌入式场景中;

第二,它是分布式架构,使得它可以很好地运行于多端协作的场景;

第三,它面向的是全场景的应用,囊括了像智能穿戴这样的IoT设备、智慧大屏、智能终端以及PC机等。其中荣耀大屏(电视)是它第一个产品。

鸿蒙OS主要特性速览和解析

preview
继续阅读“鸿蒙OS速览”

316 total views, no views today

Little Kernel 代码走读(二)

作者:张佩】【原始链接:www.yiiyee.cn/blog

任务管理

LK支持多任务,并且也支持多核。多任务和调度,是LK内核最复杂的功能。一般的嵌入是系统,为了实现简单和便利部署的考虑,会把多任务实现得比较简单,比如uos这样的rtos系统便是了。但LK其实有比较丰富而全面的多任务支持的基础。这使得一些功能更全面的微内核系统比如Zircon,会选择基于它进行开发。

线程结构体

每个内核实现都会为线程创建一个结构体,用来管理任务的执行和维护线程状态。由于无受限的多任务支持能力,所以系统中的线程数量和功能,是不受限的。所以要有一种管理设施,能够对所有的任务进行无区别的管理(某些时候是有区别的,比如idle线程、init线程等,但很少)。这个模块就是内核的任务管理器。而它管理这些任务的抓手,就是线程结构体。

下面是LK定义的线程结构体:

继续阅读“Little Kernel 代码走读(二)”

222 total views, 1 views today

Little Kernel 代码走读(一)

作者:张佩】【原始链接www.yiiyee.cn/blog

Little Kernel是一个微型内核,某种意义上,可以被定义为微内核。当下声势大张的谷歌Fuchsia OS的微内核系统就是从它演进而来的。它更为一般的作用,是在安卓设备中,作为一个典型的boot loader并启动安卓OS。相较于更通用的arm平台上的u-boot,它当然更加地简单。所以如果不需要boot loader中实现复杂的功能,特别是不需要驱动复杂的IO设备的话,little kernel是非常合适的。

当然,并不是说Little Kernel(简称LK)没有IO支持。它对于基本的IO设备还是有接口层面的支持的。比如串口、GPIO、基于frame buffer的图形显示设备,以及更高级的设备比如磁盘设备、USB、网络等,甚至virtio设备。但仅限于接口定义,却缺少具体的设备支持。所以新平台的设备驱动开发是一个巨大任务。

在这个文档中,我带领大家一起走读一下LK的核心代码。

LK内核代码走读

这部分我带领大家走读一下LK内核部分的代码。因为代码很简单,所以走读一遍并不费事。和Linux内核相比,走读LK的内核如同在电视上看别人爬山一样,所费精力与实际爬山之人,实有天壤之别。但如鲁迅说的,我的双脚虽不能如愿地周游世界,但通过眼睛却能部分地实现它,观看风光纪录片便如部分地身临其境地领略了那些风光,也能增广见闻的。所以LK虽微,分析它亦不费事,但学习它也能达到增广见闻的目的,部分地达到学习内核实现的目的。

LK官方有一篇和小的文档介绍内核API,然太简。参考。下面我带领大家分别地看一下LK的内存管理、任务管理和同步机制,这三个主要部分的实现逻辑。

继续阅读“Little Kernel 代码走读(一)”

292 total views, 3 views today

UEFI开发探索40 – 构建自己的Package

前段时间在Linux下开发UEFI程序,发现以前写的AppPkg的32位程序没法编译,无法在模拟环境下测试执行程序。

我当时就想脱离AppPkg,自己构建Package。当然,StdLib的库不能使用了,也不能以main()函数为入口。我觉得这都不是什么大事,毕竟平常构建的Option ROM代码也不能使用这些。

说干就干,顺便把各种类型文件的知识点过一遍。

1 编译框架

EDKII的编译系统是基于Python和C的代码构建的,可以跨平台编译。也可运行在不同的CPU架构上,比如X86和ARM,最近我们在做针对龙芯MIPS的软件,乐见UEFI发展版图的扩大。

图1 EDKII 工作流程
继续阅读“UEFI开发探索40 – 构建自己的Package”

234 total views, 1 views today

UEFI开发探索39 – Ubuntu 16.04下用gdb建立UEFI调试环境

准确地说,应该是在Ubuntu 16.04下,使用Qemu模拟UEFI启动环境,同时配合Intel UDK Debugger tool和gdb建立的X64调试环境。

使用的是Qemu和OvmfPkg,类似于之前使用windbg在Windows下搭建调试环境,这次换为在Linux下搭建了。正是上一篇博客留下的题目。

1 参考资料

如何在Linux下搭建调试环境,网上的资料不多,特别是如何让gdb挂上UEFI启动环境,我摸索了几天。

可供参考的资料有《UDK_Debugger_Tool_User_Manual_V1.11.pdf》,在网站https://firmware.intel.com/develop/intel-uefi-tools-and-utilities/intel-uefi-development-kit-debugger-tool上下载,其中第六章开始介绍如何在Linux下搭建调试环境。

以及开源项目Slim Bootloader: https://slimbootloader.github.io/index.html。它在调试的时候使用了UDK Debugger Tool,搭建调试环境的方法可用来类比。

图1 Slim Bootloader’s LOGO
继续阅读“UEFI开发探索39 – Ubuntu 16.04下用gdb建立UEFI调试环境”

295 total views, no views today

UEFI开发探索38 – Ubuntu下编译AppPkg杂谈

上一篇博客中,在编译AppPkg的时候,遇到了问题,编译的时候出错。错误的提示在上一篇博客中贴出来了,这里不再贴出。针对此问题,我查找了一些资料,做了若干实验,姑且以杂谈的形式记录下来。

1 EADK

为了方便使用标准的C库,EDKII中提供了开发包:EDK II Application Development Kit,简称为EADK。它最早脱胎于EFI_ToolKit,是Intel推广EFI的范例程序包。

随着UEFI的法发展,原来的架构无法统一,EFI_ToolKit的代码被分别整合到各个Package中了。其中的python和Application Development Kit就由EADK接替,并维护着。不过,从github上的日期来看,最后维护的时间也是2015了,是不是后面放弃了?

不管如何,它能很方便的用来构建Uefi程序,也能直接使用熟悉的C库函数,之前博客中的大量代码都使用了它。 它包含了三个Package:

图1 EADK
继续阅读“UEFI开发探索38 – Ubuntu下编译AppPkg杂谈”

201 total views, no views today

UEFI开发探索37 – Linux下环境搭建

Windows下搭建环境、编译、运行等一系列工作,都已经比较熟练了。不过,鉴于Intel提供的调试工具(之前博客中讲述过)Linux版本的都比windows新:

图1 已经两年没更新的调试工具

我觉得还是有必要在Linux下把开发环境建立起来。何况,我平常用来开发UEFI的Windows虚拟机实在太大了,动辄50G,装完必要软件后,只剩下10多个G。

继续阅读“UEFI开发探索37 – Linux下环境搭建”

218 total views, 2 views today

UEFI开发探索Q&A – 问题辑录(持续更新)

最近正在尝试在Unbutu16上搭建开发和调试环境,其中过程一言难尽,到现在也没完成到符合我要求的程度。

正是因为遇到障碍,我今天早上回到Win10+UDK2018的环境下,想重新编译下AppPkg,没想到遇到问题了,怎么编译都不通过。明明之前是没有问题的啊,看第26篇博客,当时我还非常雀跃于第一次编译通过。

我一直都在使用AppPkg编译我自己的UEFI app,肯定是哪里的配置被我自己修改,忘记了。一番折腾后,终于搞清楚了。

基于上面的事故,我觉得有必要专门做一个问题辑录的博客,把自己遇到的一些比较奇怪的问题以及解决方法记录下来。

这篇博客用来占坑,遇到问题就到这里记录,估计会很长……

继续阅读“UEFI开发探索Q&A – 问题辑录(持续更新)”

139 total views, no views today

UEFI开发探索36 – UEFI Option ROM

(请保留->发布地址: http://yiiyee.cn/blog/author/luobing/ )

Option ROM的开发不是一门显学,相关的资料也少得可怜。如果是在ODM厂商工作,或者做BIOS相关的工作,可以接触到很多相关的材料。不过,对我这种必须开发Option ROM,公司又不是相关行业的,非常少见。这也导致在开发Legacy BIOS的Oprom时,只能一点点摸索,遇到的问题如山之多。

UEFI下开发Option ROM相对好多了,一方面资料比较全面,EDK的文档组织还是比较明晰的;另一方面,它也提供了标准的工具,非常便利。我自己的测试卡是PCIE接口的,接下来讨论的Option ROM是针对PCI扩展ROM的(ISA ROM在UEFI spec中好像不支持了)。

UEFI的Option ROM结构与之前介绍的Legacy BIOS Oprom类似:

图1 UEFI Option ROM结构(From UEFI Spec 2.8 page 723)
继续阅读“UEFI开发探索36 – UEFI Option ROM”

489 total views, 4 views today