驱动程序是在bootloader里还是os里面,为什么
推荐于2017-12-15
展开全部
Bootloader 即引导加载程序,是系统加电后运行的第一段软件代码。简单的说它们都是bootloader,所完成的任务也大同小异。
vivi是mizi开发的用于s3c241x/s3c244x 的linux bootloader,友善之臂移植了USB 下载功能后就成了现在看到的supervivi;u-boot是一个广泛用于ARM平台的bootloader, 目前也支持s3c241x/s3c244x,可以用来启动Linux;Eboot是WinCE平台下的bootloader。uboot就是通过usb来下载os image文件的bootloader; eboot就是通过ethernet下载os image的bootloader
熟悉x86体系结构的朋友肯定知道,x86平台上bootloader 是由 BIOS和位于硬盘MBR中的OS Bootloader(比如Lilo 和 Grub)组成的。BIOS完成硬件的检测和资源的分配后,将硬盘MBR中的bootloader读到系统RAM中,之后此bootloader 就会开始进行主导,将内核搬到内存中以及进行一些必要的初始化工作,之后跳到内核的入口地址来执行,这样内核就开始启动,也就是系统就启动起来了。
而嵌入式平台上就跟x86不一样了,但是很类似,而且因为不同的平台架构本身的特点,每种平台对应的bootloader做得事情会有所不同,相对x86平台,一般不会有bios(但是这些都不是绝对的,有一些平台也会有内嵌类似bios的启动程序),整个系统的引导加载都由存放在flash,rom等存储设备特定位置的bootloader来完成。如arm平台中的2410,2440,bootloader存在在flash中的0x0的地方,板子加电后,系统会将bootloader的最前面的4k代码通过硬件逻辑自动的装载到SRAM中,之后从SRAM中的0开始执行,在这4k的程序中会完成基本的硬件的初始化,将完整的bootloader搬到内存中,并跳转到ram中的bootloader来进行继续执行。
这里不得不插入一个话题,通过上面的介绍,细心的朋友就会产生一个疑问:为什么要有bootloader?既然bootloader只是作硬件的初始化并将内核引导起来,那为什么不直接将这段代码加到内核中,直接启动内核就完成所有的工作?实际上要将bootloader与内核整合在一起是完全可以做到的,但是如果这样作的话,内核就会失去他的通用性和灵活性,并且将bootloader与内核分开会更有利于开发和管理,将启动过程中与平台硬件相关的代码集合成bootloader,内核就可以集中处理那些平台通用的部分了(当然实际上并没有这么严格的划分,内核中还是会有一些平台相关的代码,不过已经算是比较通用的了)。
回到之前所说的,bootloader启动起来之后,通常会有两种操作模式:
启动加载模式就是一上电,bootloader进行相关的初始化之后就马上把内核启动起来,注意关键的地方在整个过程中没有用户的参与,这种其实也就是bootloader的默认处理,一般的产品设计ok进行最后的发布时,就会处于此种状态。
下载模这种模式,大家肯定非常熟悉,就是大家在进行开发的时候所处的环境,我们经常使用的tftp, erase, cp.b 等命令将相关的bin,img文件烧到板子上,这种情况下其实就是处于bootloader的执行环境下,所以一定意义来说,大多的bootloader其实就是一个嵌入式操作系统,只是它的功能不强,不像linux的结构那么复杂,而且也不会支持多进程多线程处理。
bootloader 种类和分类
这里的分类实际上是依据上面的bootloader的操作模式来进行划分的,根据一个系统是否支持上面的下载模式我们这里将bootloader划分为bootloader和monitor(这不是我划分的,恩,是从别人的文章中引述过来的,不过我觉得他说的很有道理), 这里”bootloader”是指只是引导设备与执行主程序的固件,而”monitor”是指不仅拥有bootloader功能的,还能够进入下载模式的固件。
从上面的表可以看出,很多的bootloader都不是monitor。现在国内进行开发大部分还是使用u-boot的,因此下面我们所说的bootloader都是指的u-boot。
对于每种体系结构,都有一系列开放源码Bootloader可以选用。
(1)X86
X86的工作站和服务器上一般使用LILO和GRUB。LILO是Linux发行版主流的Bootloader。不过Redhat Linux发行版已经使用了GRUB,GRUB比LILO有更有好的显示界面,使用配置也更加灵活方便。
在某些X86嵌入式单板机或者特殊设备上,会采用其他Bootloader,例如:ROLO。这些Bootloader可以取代BIOS的功能,能够从FLASH中直接引导Linux启动。现在ROLO支持的开发板已经并入U-Boot,所以U-Boot也可以支持X86平台。
(2)ARM
ARM处理器的芯片商很多,所以每种芯片的开发板都有自己的Bootloader。结果ARM bootloader也变得多种多样。最早有为ARM720处理器的开发板的固件,又有了armboot,StrongARM平台的blob,还有S3C2410处理器开发板上的vivi等。现在armboot已经并入了U-Boot,所以U-Boot也支持ARM/XSCALE平台。U-Boot已经成为ARM平台事实上的标准Bootloader。
(3)PowerPC
PowerPC平台的处理器有标准的Bootloader,就是ppcboot。PPCBOOT在合并armboot等之后,创建了U-Boot,成为各种体系结构开发板的通用引导程序。U-Boot仍然是PowerPC平台的主要Bootloader。
(4)MIPS
MIPS公司开发的YAMON是标准的Bootloader,也有许多MIPS芯片商为自己的开发板写了Bootloader。现在,U-Boot也已经支持MIPS平台。
(5)SH
SH平台的标准Bootloader是sh-boot。Redboot在这种平台上也很好用。
(6)M68K
M68K平台没有标准的Bootloader。Redboot能够支持m68k系列的系统。
值得说明的是Redboot,它几乎能够支持所有的体系结构,包括MIPS、SH、M68K等体系结构。
Redboot是以eCos为基础,采用GPL许可的开源软件工程。
vivi是mizi开发的用于s3c241x/s3c244x 的linux bootloader,友善之臂移植了USB 下载功能后就成了现在看到的supervivi;u-boot是一个广泛用于ARM平台的bootloader, 目前也支持s3c241x/s3c244x,可以用来启动Linux;Eboot是WinCE平台下的bootloader。uboot就是通过usb来下载os image文件的bootloader; eboot就是通过ethernet下载os image的bootloader
熟悉x86体系结构的朋友肯定知道,x86平台上bootloader 是由 BIOS和位于硬盘MBR中的OS Bootloader(比如Lilo 和 Grub)组成的。BIOS完成硬件的检测和资源的分配后,将硬盘MBR中的bootloader读到系统RAM中,之后此bootloader 就会开始进行主导,将内核搬到内存中以及进行一些必要的初始化工作,之后跳到内核的入口地址来执行,这样内核就开始启动,也就是系统就启动起来了。
而嵌入式平台上就跟x86不一样了,但是很类似,而且因为不同的平台架构本身的特点,每种平台对应的bootloader做得事情会有所不同,相对x86平台,一般不会有bios(但是这些都不是绝对的,有一些平台也会有内嵌类似bios的启动程序),整个系统的引导加载都由存放在flash,rom等存储设备特定位置的bootloader来完成。如arm平台中的2410,2440,bootloader存在在flash中的0x0的地方,板子加电后,系统会将bootloader的最前面的4k代码通过硬件逻辑自动的装载到SRAM中,之后从SRAM中的0开始执行,在这4k的程序中会完成基本的硬件的初始化,将完整的bootloader搬到内存中,并跳转到ram中的bootloader来进行继续执行。
这里不得不插入一个话题,通过上面的介绍,细心的朋友就会产生一个疑问:为什么要有bootloader?既然bootloader只是作硬件的初始化并将内核引导起来,那为什么不直接将这段代码加到内核中,直接启动内核就完成所有的工作?实际上要将bootloader与内核整合在一起是完全可以做到的,但是如果这样作的话,内核就会失去他的通用性和灵活性,并且将bootloader与内核分开会更有利于开发和管理,将启动过程中与平台硬件相关的代码集合成bootloader,内核就可以集中处理那些平台通用的部分了(当然实际上并没有这么严格的划分,内核中还是会有一些平台相关的代码,不过已经算是比较通用的了)。
回到之前所说的,bootloader启动起来之后,通常会有两种操作模式:
启动加载模式就是一上电,bootloader进行相关的初始化之后就马上把内核启动起来,注意关键的地方在整个过程中没有用户的参与,这种其实也就是bootloader的默认处理,一般的产品设计ok进行最后的发布时,就会处于此种状态。
下载模这种模式,大家肯定非常熟悉,就是大家在进行开发的时候所处的环境,我们经常使用的tftp, erase, cp.b 等命令将相关的bin,img文件烧到板子上,这种情况下其实就是处于bootloader的执行环境下,所以一定意义来说,大多的bootloader其实就是一个嵌入式操作系统,只是它的功能不强,不像linux的结构那么复杂,而且也不会支持多进程多线程处理。
bootloader 种类和分类
这里的分类实际上是依据上面的bootloader的操作模式来进行划分的,根据一个系统是否支持上面的下载模式我们这里将bootloader划分为bootloader和monitor(这不是我划分的,恩,是从别人的文章中引述过来的,不过我觉得他说的很有道理), 这里”bootloader”是指只是引导设备与执行主程序的固件,而”monitor”是指不仅拥有bootloader功能的,还能够进入下载模式的固件。
从上面的表可以看出,很多的bootloader都不是monitor。现在国内进行开发大部分还是使用u-boot的,因此下面我们所说的bootloader都是指的u-boot。
对于每种体系结构,都有一系列开放源码Bootloader可以选用。
(1)X86
X86的工作站和服务器上一般使用LILO和GRUB。LILO是Linux发行版主流的Bootloader。不过Redhat Linux发行版已经使用了GRUB,GRUB比LILO有更有好的显示界面,使用配置也更加灵活方便。
在某些X86嵌入式单板机或者特殊设备上,会采用其他Bootloader,例如:ROLO。这些Bootloader可以取代BIOS的功能,能够从FLASH中直接引导Linux启动。现在ROLO支持的开发板已经并入U-Boot,所以U-Boot也可以支持X86平台。
(2)ARM
ARM处理器的芯片商很多,所以每种芯片的开发板都有自己的Bootloader。结果ARM bootloader也变得多种多样。最早有为ARM720处理器的开发板的固件,又有了armboot,StrongARM平台的blob,还有S3C2410处理器开发板上的vivi等。现在armboot已经并入了U-Boot,所以U-Boot也支持ARM/XSCALE平台。U-Boot已经成为ARM平台事实上的标准Bootloader。
(3)PowerPC
PowerPC平台的处理器有标准的Bootloader,就是ppcboot。PPCBOOT在合并armboot等之后,创建了U-Boot,成为各种体系结构开发板的通用引导程序。U-Boot仍然是PowerPC平台的主要Bootloader。
(4)MIPS
MIPS公司开发的YAMON是标准的Bootloader,也有许多MIPS芯片商为自己的开发板写了Bootloader。现在,U-Boot也已经支持MIPS平台。
(5)SH
SH平台的标准Bootloader是sh-boot。Redboot在这种平台上也很好用。
(6)M68K
M68K平台没有标准的Bootloader。Redboot能够支持m68k系列的系统。
值得说明的是Redboot,它几乎能够支持所有的体系结构,包括MIPS、SH、M68K等体系结构。
Redboot是以eCos为基础,采用GPL许可的开源软件工程。
本回答被网友采纳
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询