各种boot的区别

vivi、uboot、eboot的区别  

 

    简单的说它们都是bootloader，所完成的任务也大同小异。

    vivi是mizi开发的用于s3c241x/s3c244x 的linux bootloader， 友善之臂移植了USB 下载功能后就成了现在看到的supervivi
    u-boot是一个广泛用于ARM平台的bootloader, 目前也支持s3c241x/s3c244x，可以用来启动Linux
    Eboot是WinCE平台下的bootloader。

 

http://www.arm9home.com/bbs/read.php?tid-193.html

摘自论坛上好心人的回答

---

 

eboot,nboot,uboot

 

网友A：

nboot是samsung系列cpu为了能将前4KB程序复制到SRAM中运行，而在wince写的。
eboot其实应该是Ethernet Boot，因为起始时，都是通过网口更新的。当然现在大部分反而通过USB了。
uboot是linux下主要使用的，不过现在已经剥离开来，ce下已经可以移植了，只是用来debug的多，实际合入工程的少，毕竟与wince系统的契合度不高。

网友B:
基本就是这个样子，补充一下：
nboot很小（4k左右），一般用在从nandflash启动的情况，nandflash不支持xip，所以必须有一个可以执行的程序将烧写在其中的eboot搬到内存中，nboot就是干这个的。nboot烧写在片内的4ksram中。所以nboot一般配合eboot一起使用。

eboot就是ethernet boot，开始都是用网络下载的，现在大都加入了usb下载功能。eboot可以单独使用，就是把eboot烧写到norflash中，norflash支持xip，所以eboot可以自己把自己搬到内存中。

uboot以前常配合linux系统使用，不过现在已经在ce下用的很多了，我现在用的就是由uboot移植来的，只不过板商一般都不给源码，比较郁闷。uboot应该是比较强大的bootloader了，比eboot强大多了。

 

我的疑问：为什么天嵌的开发板，要先下载eboot,再下载uboot。他们的功能没有重复吗？还是在配合使用，使开发板既有eboot,又有uboot，既支持网络数据传输，又支持USB数据传输的功能。这个问题现在就放在这了，以后学习中，慢慢体会。

 

本文来自CSDN博客http://blog.csdn.net/joyzml/archive/2009/10/03/4630640.aspx

 

---

 

什么是bootloader?

 

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的分类。

这里的分类实际上是依据上面的bootloader的操作模式来进行划分的，根据一个系统是否支持上面的下载模式我们这里将bootloader划分为bootloader和monitor（这不是我划分的，恩，是从别人的文章中引述过来的，不过我觉得他说的很有道理）， 这里”bootloader”是指只是引导设备与执行主程序的固件，而”monitor”是指不仅拥有bootloader功能的，还能够进入下载模式的固件。

Bootloader

Monitor

描    述

x86

ARM

PowerPC

LILO

否

Linux磁盘引导程序

是

否

否

GRUB

否

GNU的LILO替代程序

是

否

否

Loadlin

否

从DOS引导Linux

是

否

否

ROLO

否

从ROM引导Linux而不需要BIOS

是

否

否

Etherboot

否

通过以太网卡启动Linux系统的固件

是

否

否

LinuxBIOS

否

完全替代BUIS的Linux引导程序

是

否

否

BLOB

是

LART等硬件平台的引导程序

否

是

否

U-boot

是

通用引导程序

是

是

是

RedBoot

是

基于eCos的引导程序

是

是

是

vivi

是

专为三星的arm cpu设计的引导程序

否

是

否

 

从上面的表可以看出，很多的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许可的开源软件工程。
现在由core eCos的开发人员维护，源码下载网站是http://www.ecoscentric.com/snapshots。
Redboot的文档也相当完善，有详细的使用手册《RedBoot User’s Guide》。

 

关于U-Boot的编程下面链接有详细说明：

http://xiongqiang2008.bokee.com/viewdiary.31933043.html

 

这个链接是电子书的~~

http://www.cnitblog.com/darkstax/articles/21776.html

 

 

---

 

Eboot代码流程

 

首先通常都是汇编代码:启动时由系统复位导致PC为0为触发条件：以2440代码为例直接进入fw.s文件。主要执行的操作为设置处理器频率（PLL）,设置内存参数，须注意的是在该部分代码虽然在形式上实现了诸多中断向量，但是这些代码根本上不会得到执行。（参考“Eboot 编译编译器决定中断向量及其实现单一性的原因”）而在后面会有一些其他手段用于实现中断向量的功能。由于和hal复用该部分文件，所以调用的函数名称会与内核启动函数的相同（如：KernelStart），但是实现内容却是完全不同的。在该部分的最后还将保存一个OEMAddressTable的地址指针到下一格函数，进行应有的内存影射。下面还是以2440bsp为例说明。根据windowsCE系统的要求，需要把将会操作到的内存空间影射到0x8000 0000后的512M空间中，其中低256M为带缓冲的，高256M则是不带缓冲的。不带缓冲的区域通常是驱动访问设备必须的，这样可以保障对硬件的操作不受到缓冲的干扰。除了按照OEMAddressTable进行内存空间影射外，还可以要根据程序需求进行其他一系列影射，通常的做法都是将目前所有的设备/内存在原地址空间上再影射一次，以方便使用。另外就是在将0x0位置影射到内存，这样，就可以通过这个部分来进行中短向量的安装了，以实现中断服务程序。（以上内存影射并不是必须的，仅仅是为了方便程序的编写而已，使用和系统相同的影射表可以使得不必重新另外建一套头文件，同时如果需要的话可以一直在内存中保存eboot，这样内存空间的规划也会相对容易做一些）。

以上的这些工作做完，就进入windowsCE提供的eboot入口函数了。 也就是BootloaderMain。这个函数位于WINCE420/PUBLIC/COMMON/OAK/DRIVERS/ETHDBG/BLCOMMON/blcommon.c文件中。该目录的文件就是微软提供的eboot框架，尽管这不是实现的部分，也一并分析了吧。这部分的内容一开始就很有意思，第一个执行的语句如下
if (!KernelRelocate (pTOC)) { HALT (BLERR_KERNELRELOCATE); }
而这个传入的参数却这样定义：ROMHDR * volatile const pTOC = (ROMHDR *)-1; 按照程序的内容来说，这个函数到这里一定是死循环了，可是事实上这个死循环不会得到执行，也就是pTOC = (ROMHDR *)-1并没有真正的起到作用。:) 在pTOC第一次使用前检查了一下pTOC的值，结果如下：pTOC=0x8C04D694。也就是说pTOC在没有被改变之前就已经不再是-1了，而且pTOC是被定义成const的，也没有办法去改变，看样子就只能是编译器的过程中这个指针就已经被动了手脚。而查看eboot.map中该地址所对应的内容居然是bootpart.obj的内容。感觉是无从下手了，这样子让人太费解了。仔细比较eboot.exe和eboot.nb0后发现，eboot.exe通过romimage处理后长度增加了，而且结构上改变了许多，在原.eboot.exe后增加了一系列原来没有内容，pTOC的内容就是属于这部分内容中的一部分。由于牵涉到windowsCE的Image Chain结构，所以无法继续往下分析，这部分的内容就先跳过。以后再回头来看。

随后在 BootloaderMain中对调试界面进行初始化，由OEMDebugInit完成这个函数的实现是由具体的硬件决定的通常来说为串口的初始化，再次以后就通过该调试界面进行调试信息的发布。

 

然后在OEMPlatformInit()中对eboot所要用到的硬件资源进行初始化设备，通常这些会包含:存储设备（FLASH、硬盘等）、传输界面（以太网卡、USB-RNDIS、无线网卡、CF—LAN等等）、系统时钟，为下面将会进行的os镜像传输、os镜像存储、读取等等一系列动作做好准备。
做好准备以后就可以调用OEMPreDownload ()来进行传输OS的准备了，在这个函数中通常会实现一系列功能，诸如：设备的设置、存储设备的格式化、网卡IP的指定、等等。windowsCE所支持的标准操作则只是两个，一个是跳转、一个是下载、分别对应下载OS镜像和跳入OS的入口点，前面提到的那些功能都是自己的扩展实现。

下面我们分别来看这两个标准操作的分支：首先是下载的分支，在下载的分支中首先通过OEMReadData来获取在最先收到的标示位也就是被称为魔法数的数据，用以比较确认该传输的内容是否为windowsCE的镜像数据，随后继续进一步获取将接收的数据的效验和，待接收的镜像的数量，镜像起始地址、长度等信息，有了这些个信息，很自然地就是接收镜像了，

随后检查数据的效验和。下一个镜像的信息的接收，如此往复循环直至所有的镜像信息接收完毕。

 

转载出处：http://blog.csdn.net/wb_sxck/archive/2008/11/05/3221256.aspx

 

---

关于bootloader

http://www.cnblogs.com/yashi88/archive/2010/02/11/1667548.html

 

    （最近在论坛上，很多朋友提到关于bootlaoder的问题，所以把自己的一些理解整理一下，做一个说明，希望对大家有帮助，如果你觉得有问题的，可以用任何方式，任何语气提出，本人绝对不会象0bug大师那样，呵呵。）

     一.bootloader的作用

       其实bootloader主要的必须的作用只有一个:就是把操作系统映像文件拷贝到RAM中去，然后跳转到它的入口处去执行。而操作系统文件的来源，可以是flash,sd card,PC(可以通过网络，USB，甚至串口传输）等等，所谓的EBOOT,UBOOT，其实就是表明了系统文件是通过Ethernet或者USB从PC传输过去的。当然，为了实现这个功能（以及其它附加功能），我们必须对硬件做一些必要的初始化，这个也是必须的（废话！）。除了这个必须的，现在的bootloader还常常会加入以下功能：

      1.将操作系统映像文件写入FLASH/硬盘等：读取过来的操作系统文件，除了可以拷贝到RAM中直接运行，还可以烧录到FLASH，或者写入硬盘永久保存，这样下次就可以直接从本机来读取操作系统映像。

     2.硬件诊断：如同PC的BIOS一样，检测硬件是否正常功能。

     3.显示一个LOGO，因为拷贝操作系统文件和启动操作系统需要时间，所以产品化的设备，一般需要在这段时间显示一个LOGO。

 

    二.bootloader是不是必须的

      bootloader并不是必须的，如果我们的硬件有足够大的norflash，并且实现了XIP技术，那么WinCE 操作系统可以直接在norflash里面运行起来，不需要将它复制到RAM中去，所以bootloader就失去了作用。

       但是考虑到成本因素，现在的硬件一般都不会配置这么大的norflash，image文件都存储在nand flash里面，所以都会用到bootloader。

 

    三.关于nboot和eboot

    国内很多人做WinCE都是使用Samsung的2410或者2440入门的，所以对nboot和eboot是最熟悉的。eboot是微软在WinCE里面提供的开放源代码的一个bootloader的框架，因为它默认的是使用ethernet从PC下载image而得名，使用该框架，根据自己的硬件做一些修改就可以直接拿来用了，那么nboot又是怎么回事呢？

    之所以需要nboot（注：三星的后续产品中，nboot已经改名为stepldr，ldr是looder的缩写，step是stepstone的意思，这是三星系列CPU为解决nand启动而内置的一小块RAM），是和硬件紧密相关的。我们在设计硬件的时候，ROM部分可以只使用norflash，也可以使用1片小容量的norflash+大容量的nandflash，还可以只使用nandflash。第一种方案，可以不用bootloader，也可以只使用eboot；第二种方案，把eboot放到norflash中，image放在nandflash中，并将硬件设置为norflash启动模式，也不用nboot。只有第3种方案，才需要使用nboot，这是为什么呢？

     我们知道nandflash本身不能运行程序，它里面的内容必须拷贝到RAM中才能运行，但是CPU上电后，RAM中是空的，谁来执行这个拷贝的工作呢？三星的解决方案，就是内置了一小块RAM(stepstone)，然后从硬件上实现CPU上电后先读取nand flash最开始的一段代码到stepstone中去（当然，要设置硬件为nandflash启动方式），然后从stepstone起始处（被设置为RAM的0地址）去执行。这个stepstone一般很小（2410，2440是4K），所以它没办法放下一个功能复杂的bootloader（比如eboot），只能放一个功能很简单的，这就是需要nboot的原因了。nboot的功能十分单一，就是从nandflash复制image到RAM中去，然后跳转执行。这里的image可以是eboot的（一般开发阶段这样做），也可以是OS的。

     优龙的开发板提供了一种叫做BIOS的bootloader，它远远超出了4K的限制，但是还可以在nandflash启动方式下正常运行，这是为什么呢？原来，它实现了2次加载，也就是说CPU上电后自动加载了4K代码，这4K代码又将整个bootloader重新拷贝到RAM中再执行，要实现这样的功能要对链接器做一些设置，使“拷贝”功能的代码必须放到前4K里面去。

 

   总之，bootloader是需要直接和硬件打交道，不同的硬件设计，就会影响到它的实现，所以了解硬件的设计是理解bootloaer的第一步。