BootLoader 一. BootLoader简介 在专用的嵌入式板子运行GNU/Linux系统已经变得越来越流行。一个嵌入式Linux系统从软件的角度看通常可以分为四个层次: 1、 引导加载程序。包括固化在固件(firmware)中的boot代码(可选),和BootLoader两大部分。 2、 Linux内核。特定于嵌入式板子的定制内核以及内核的启动参数。 3、 文件系统。包括根文件系统和建立于Flash内存设备之上文件系统。通常用ramdisk来作为rootfs。 4、 用户应用程序。特定于用户的应用程序。有时在用户应用程序和内核层之间可能还会包括一个嵌入式图形用户界面。常用的嵌入式GUI有:MicroWindows和MiniGUI懂。 引导加载程序是系统加电后运行的第一段软件代码。PC机中的引导加载程序由BIOS(其本质就是一段固件程序)和位于硬盘MBR中的OS BootLoader(比如,LILO和GRUB等)一起组成。BIOS在完成硬件检测和资源分配后,将硬盘MBR中的BootLoader读到系统的RAM中,然后将控制权交给OS BootLoader。BootLoader的主要运行任务就是将内核映象从硬盘上读到 RAM 中,然后跳转到内核的入口点去运行,也即开始启动操作系统。 而在嵌入式系统中,通常并没有像BIOS那样的固件程序(注,有的嵌入式CPU也会内嵌一段短小的启动程序),因此整个系统的加载启动任务就完全由BootLoader来完成。比如在一个基于ARM7TDMI core的嵌入式系统中,系统在上电或复位时通常都从地址0x00000000处开始执行,而在这个地址处安排的通常就是系统的BootLoader程序。 简单地说,BootLoader就是在操作系统内核运行之前运行的一段小程序。通过这段小程序,我们可以初始化硬件设备、建立内存空间的映射图,从而将系统的软硬件环境带到一个合适的状态,以便为最终调用操作系统内核准备好正确的环境。 通常,BootLoader是严重地依赖于硬件而实现的,特别是在嵌入式世界。因此,在嵌入式世界里建立一个通用的BootLoader几乎是不可能的。尽管如此,我们仍然可以对BootLoader归纳出一些通用的概念来,以指导用户特定的BootLoader设计与实现。 二、常见bootloader介绍 1.U-BOOT介绍 uboot是一个庞大的公开源码的软件。他支持一些系列的arm体系,包含常见的外设的驱动,是一个功能强大的板极支持包。其代码可以从http://sourceforge.net/projects/u-boot下载 U-BOOT是由PPCBOOT发展起来的,是PowerPC、ARM9、Xscale、X86等系统通用的Boot方案,从官方版本 0.3.2开始全面支持SC系列单板机。u-boot是一个open source的bootloader,目前版本是0.4.0。u-boot是在ppcboot以及armboot的基础上发展而来,虽然宣称是0.4.0版本,却相当的成熟和稳定,已经在许多嵌入式系统开发过程中被采用。由于其开发源代码,其支持的开发板众多。唯一遗憾的是并不支持我们现在学习所用samsung 44B0X的开发板。 为什么我们需要u-boot?显然可以将ucLinux直接烧入flash,从而不需要额外的引导装载程序(bootloader)。但是从软件升级的角度以及程序修补的来说,软件的自动更新非常重要。事实上,引导装载程序(bootloader)的用途不仅如此,但仅从软件的自动更新的需要就说明我们的开发是必要的。 同时,u-boot移植的过程也是一个对嵌入式系统包括软硬件以及操作系统加深理解的一个过程。 2。vivi介绍(下载地址http://www.mizi.com/developer) vivi是韩国mizi 公司开发的bootloader, 适用于ARM9处理器。 Vivi有两种工作模式:启动加载模式和下载模式。启动加载模式可以在一段时间后(这个时间可更改)自行启动linux内核,这时vivi的默认模式。在下载模式下,vivi为用户提供一个命令行接口,通过接口可以使用vivi提供的一些命令,如下: 命令 功能 Load 把二进制文件载入Flash或RAM Part 操作MTD分区信息。显示、增加、删除、复位、保存MTD分区 Param 设置参数 Boot 启动系统 Flash 管理Flash,如删除Flash的数据 vivi代码分析 vivi的代码包括arch,init,lib,drivers和include等几个目录,共200多条文件。 Vivi主要包括下面几个目录: arch:此目录包括了所有vivi支持的目标板的子目录,例如s3c2410目录。 drivers:其中包括了引导内核需要的设备的驱动程序(MTD和串口)。MTD目录下分map、nand和nor三个目录。 init:这个目录只有main.c和version.c两个文件。和普通的C程序一样,vivi将从main函数开始执行。 lib:一些平台公共的接口代码,比如time.c里的udelay()和mdelay()。 include:头文件的公共目录,其中的s3c2410.h定义了这块处理器的一些寄存器。Platform/smdk2410.h定义了与开发板相关的资源配置参数,我们往往只需要修改这个文件就可以配置目标板的参数,如波特率、引导参数、物理内存映射等。
BSP BSP板级支持包(board support package),是介于主板硬件和操作系统中驱动层程序之间的一层,一般认为它属于操作系统一部分,主要是实现对操作系统的支持,为上层的驱动程序提供访问硬件设备寄存器的函数包,使之能够更好的运行与硬件主板。在嵌入式系统软件的组成中,就有BSP。BSP是相对于操作系统而言的,不同的操作系统对应于不同定义形式的BSP,例如VxWorks的BSP和Linux的BSP相对于某一CPU来说尽管实现的功能一样,可是写法和接口定义是完全不同的,所以写BSP一定要按照该系统BSP的定义形式来写(BSP的编程过程大多数是在某一个成型的BSP模板上进行修改)。这样才能与上层OS保持正确的接口,良好的支持上层OS。
SDK 百科名片 SDK(Software Development Kit, 即软件开发工具包 )一般是一些被软件工程师用于为特定的软件包、软件框架、硬件平台、操作系统等建立应用软件的开发工具的集合。
基本信息 SDK,Software Development Kit 的缩写,中文即“软件开发工具包”。广义上指辅助开发某一类软件的相关文档、范例和工具的集合。一般而言,SDK即开发 Windows 平台下的应用程序所使用的SDK。
相关背景
API API”,也就是 Application Programming Interface,其实就是操作系统留给应用程序的一个调用接口,应用程序通过调用操作系统的 API 而使操作系统去执行应用程序的命令(动作)。其实早在 DOS 时代就有 API 的概念,只不过那个时候的 API 是以中断调用的形式(INT 21h)提供的,在 DOS 下跑的应用程序都直接或间接的通过中断调用来使用操作系统功能,比如将 AH 置为 30h 后调用 INT 21h 就可以得到 DOS 操作系统的版本号。而在 Windows 中,系统 API 是以函数调用的方式提供的。同样是取得操作系统的版本号,在 Windows 中你所要做的就是调用 GetVersionEx() 函数。 可以这么说,DOS API 是“Thinking in 汇编语言”的,而 Windows API 则是“Thinking in 高级语言”的。 DOS API 是系统程序的一部分,他们与系统一同被载入内存并且可以通过中断矢量表找到他们的入口,那么 Windows API 呢?要说明白这个问题就不得不引入我们下面要介绍得这个概念——DLL。
DLL DLL,即 Dynamic Link Library(动态链接库)。在windows环境下含有大量 .dll 格式的文件,这些文件就是动态链接库文件,其实也是一种可执行文件格式。跟 .exe 文件不同的是,.dll 文件不能直接执行,他们通常由 .exe 在执行时装入,内含有一些资源以及可执行代码等。其实 Windows 的三大模块就是以 DLL 的形式提供的(Kernel32.dll,User32.dll,GDI32.dll),里面就含有了 API 函数的执行代码。为了使用 DLL 中的 API 函数, 必须要有 API 函数的声明(.H)和其导入库(.LIB),导入库可以先这样理解:导入库是为了在 DLL 中找到 API 的入口点而使用的。 为了使用 API 函数,我们就要有跟 API 所对应的 .H 和 .LIB 文件,而 SDK 正是提供了一整套开发 Windows 应用程序所需的相关文件、范例和工具的“工具包”。。 SDK 包含了使用 API 的必需资料,所以人们也常把仅使用 API 来编写 Windows 应用程序的开发方式叫做“SDK 编程”。而 API 和 SDK 是开发 Windows 应用程序所必需的东西,所以其它编程框架和类库都是建立在它们之上的,比如 VCL 和 MFC,虽然他们比起“SDK 编程”来有着更高的抽象度,但这丝毫不妨碍它们在需要的时候随时直接调用 API 函数 。 为了更好的支持我,如果要转载请注明出处:
fengmm521.blog.163.com 欢迎大家去我的个人网站和论坛留下脚印,网站:
http://www.k557.com,论坛:
http://www.k557.com/bbs