万物生于一；面对纷繁，要看透它一的底色
请保留-> 【原文： https://blog.csdn.net/luobing4365 和 http://yiiyee.cn/blog/author/luobing/】
作为一个底层的支持系统，UEFI没有支持中断。如果想支持异步操作，只能通过事件(Event)来实现。
在开发Foxdisk的过程中，也遇到需要同时处理的事件。比如提示用户输入的闪烁光标、自动显示的系统时间等，我是采用了时钟中断(int 1Ch)的方式来实现的，是段很有意思的程序。
不过，我只是简单地将需要的功能堆砌在int 1Ch中实现，并没有完整地实现多任务间的互斥，是一种“伪多任务”的实现。那么，UEFI中是怎么来支持多个任务同时执行呢？
1 支持的服务函数
图1为相关的服务函数，总共10个：
10,841 total views, 1 views today
请保留 -> 【作者：张佩】【原文：www.yiiyee.cn/blog】
鸿蒙在HDC 2019上作为最重要的产品被隆重推出，现在已经为世人所知。它的三个重要特点是：
第一，它基于微内核的实现，可以很好地运行于IoT及安全相关的嵌入式场景中；
第二，它是分布式架构，使得它可以很好地运行于多端协作的场景；
第三，它面向的是全场景的应用，囊括了像智能穿戴这样的IoT设备、智慧大屏、智能终端以及PC机等。其中荣耀大屏（电视）是它第一个产品。
4,557 total views, 1 views today
【作者：张佩】【原始链接：www.yiiyee.cn/blog】
LK支持多任务，并且也支持多核。多任务和调度，是LK内核最复杂的功能。一般的嵌入是系统，为了实现简单和便利部署的考虑，会把多任务实现得比较简单，比如uos这样的rtos系统便是了。但LK其实有比较丰富而全面的多任务支持的基础。这使得一些功能更全面的微内核系统比如Zircon，会选择基于它进行开发。
每个内核实现都会为线程创建一个结构体，用来管理任务的执行和维护线程状态。由于无受限的多任务支持能力，所以系统中的线程数量和功能，是不受限的。所以要有一种管理设施，能够对所有的任务进行无区别的管理（某些时候是有区别的，比如idle线程、init线程等，但很少）。这个模块就是内核的任务管理器。而它管理这些任务的抓手，就是线程结构体。
下面是LK定义的线程结构体：
继续阅读“Little Kernel 代码走读（二）”8,584 total views, 2 views today
【作者：张佩】【原始链接：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内核部分的代码。因为代码很简单，所以走读一遍并不费事。和Linux内核相比，走读LK的内核如同在电视上看别人爬山一样，所费精力与实际爬山之人，实有天壤之别。但如鲁迅说的，我的双脚虽不能如愿地周游世界，但通过眼睛却能部分地实现它，观看风光纪录片便如部分地身临其境地领略了那些风光，也能增广见闻的。所以LK虽微，分析它亦不费事，但学习它也能达到增广见闻的目的，部分地达到学习内核实现的目的。
LK官方有一篇和小的文档介绍内核API，然太简。参考。下面我带领大家分别地看一下LK的内存管理、任务管理和同步机制，这三个主要部分的实现逻辑。
继续阅读“Little Kernel 代码走读（一）”18,381 total views, 2 views today
请保留-> 【原文： https://blog.csdn.net/luobing4365 和 http://yiiyee.cn/blog/author/luobing/】
前段时间在Linux下开发UEFI程序，发现以前写的AppPkg的32位程序没法编译，无法在模拟环境下测试执行程序。
我当时就想脱离AppPkg，自己构建Package。当然，StdLib的库不能使用了，也不能以main()函数为入口。我觉得这都不是什么大事，毕竟平常构建的Option ROM代码也不能使用这些。
说干就干，顺便把各种类型文件的知识点过一遍。
1 编译框架
EDKII的编译系统是基于Python和C的代码构建的，可以跨平台编译。也可运行在不同的CPU架构上，比如X86和ARM，最近我们在做针对龙芯MIPS的软件，乐见UEFI发展版图的扩大。
6,908 total views, no views today
请保留-> 【原文： https://blog.csdn.net/luobing4365 和 http://yiiyee.cn/blog/author/luobing/】
准确地说，应该是在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，搭建调试环境的方法可用来类比。
4,478 total views, no views today
请保留-> 【原文： https://blog.csdn.net/luobing4365 和 http://yiiyee.cn/blog/author/luobing/】
上一篇博客中，在编译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：
4,724 total views, 1 views today
请保留-> 【原文： https://blog.csdn.net/luobing4365 和 http://yiiyee.cn/blog/author/luobing/】
Windows下搭建环境、编译、运行等一系列工作，都已经比较熟练了。不过，鉴于Intel提供的调试工具（之前博客中讲述过）Linux版本的都比windows新:
我觉得还是有必要在Linux下把开发环境建立起来。何况，我平常用来开发UEFI的Windows虚拟机实在太大了，动辄50G，装完必要软件后，只剩下10多个G。
继续阅读“UEFI开发探索37 – Linux下环境搭建”7,838 total views, 1 views today
最近正在尝试在Unbutu16上搭建开发和调试环境，其中过程一言难尽，到现在也没完成到符合我要求的程度。
正是因为遇到障碍，我今天早上回到Win10+UDK2018的环境下，想重新编译下AppPkg，没想到遇到问题了，怎么编译都不通过。明明之前是没有问题的啊，看第26篇博客，当时我还非常雀跃于第一次编译通过。
我一直都在使用AppPkg编译我自己的UEFI app，肯定是哪里的配置被我自己修改，忘记了。一番折腾后，终于搞清楚了。
基于上面的事故，我觉得有必要专门做一个问题辑录的博客，把自己遇到的一些比较奇怪的问题以及解决方法记录下来。
这篇博客用来占坑，遇到问题就到这里记录，估计会很长……
继续阅读“UEFI开发探索Q&A – 问题辑录（持续更新）”2,682 total views, no views today
(请保留->发布地址： 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类似：
9,962 total views, 1 views today
(请保留->发布地址： http://yiiyee.cn/blog/author/luobing/ )
近期UEFI探索系列没有更新，忙着处理北京的案子以及帮忙朋友做一个IO驱动。开发完成后，我不知道怎么去测试稳定性了。问道于张佩，他建议用Verifier进行测试。
正好去上海有事，周末拉着张佩来教我如何测试和调试。过程就不赘述了，我把使用Verifier的过程记录下来，以备未来查看。
Driver Verifier不需要下载，它包含在大多数windows的发行版本中。在%WinDir%\system32\下可以找到，比如这是我工作的操作系统：
4,439 total views, 2 views today