基于MC9S12XS128 的BootLoader设计
基于MC9S12XS128 的BootLoader 设计
前言
接触飞思卡尔芯片大概有4个月的时间了，对这款16位寄存器有了一定的了解，但是因为飞思卡尔单片机的资料特别少，bootloader相关资料几乎没有，为此写下这篇设计书，方便大家学习参考交流，其中有不对的地方还请大家批评指正。本设计书主要讲解bootloader的实现过程，需对飞思卡尔16位单片机有一定的基础，了解该系列芯片的开发环境CodeWarrior5.1。
一、BootLoader的基石Prm 文件
我们在用CodeWarrior创建一个工程后会产生很多文件，其中有一个连接用的Prm文件，他的位置如图1.1所示。
图1.1
Codewarrior的Prm文件是用来划分代码段、数据段的，这类似于liunx中的连接脚本文件。程序一开始是进行初始化，然后跳转到main函数执行的，这段代码全部放在了ROM_C000处，而ROM_C000对应的地址是0xC000 到0xFEFF，具体实现代码如图1.2所示。第一部分是指明ROM_C000对的地址，第二部分是指明代码所存放的位置是ROM_C000。
我们知道bootloader和app必须在不同的ROM区域，bootloader接收到上位机发送的程序，先将其存储，后再跳转到app位置执行，所以prm文件可以帮我们实现bootloader与app程序的分离。
具体实现方法如下：
1、将原来的ROM_C000分成两个部分，ROM_BootLoader和ROM_App，因为bootloader代码较小需要保护，所以将其地址设置成0xf000-0xfeff，App的地址设置成0xc000-0xefff，这样这两块的总地址大小正好是原ROM_C000的大小。
图1.2
2、改写bootloader的代码映射地址到ROM_BootLoader；当然应用程序可以不用改，因为本身就是映射到C000的开始地方。
具体修改后的PRM如下图1.3所示，至此PRM文件修改结束。
图1.3
二、BootLoader服务对象S19文件
一般情况下，工程经过编译连接后，在“工程文件夹\bin\”下生成对应的二进制文件，可执行文件后缀主要有.s19.sx和.abs。其中以.s19和.sx为后缀的文件是文本格式的，它们是飞思卡尔推荐使用的标准文件传送格式.s文件格式将程序和数据用可打印的ASCII形式表示，包含了所需的基本协议，还包括了出错校验功能，一保证传输的正确性。下面对S格式的文件进行简单介绍。
S19文件中的每一行被称为一条记录，记录总是以字母S开头，后面跟一位数字表示此记录的类型，数字若是1代表此记录包含了程序数据，若是9则表示记录为整个文件的最末一条记录。
S记录的类型见表2.1。
我们对此结构进行说明，细节如表2.2
表2.2 S记录结构
三、实验：BootLoader原理实现
实验目的：加深对bootloader加载app的过程的理解
实验方法：创建一个bootloader工程，手动添加app工程代码，使其正常运行。
实验步骤：
1、创建一个App工程，修改prm文件，进行app和bootloader分区，修改地方与内容如图3.1所示。其他不需要改变。
图3.1 APP Prm文件修改
2、修改main函数，实现一个简单的小灯闪烁程序，程序清单如图3.2所示。
图3.2 App程序清单
3、编译生成.S19文件，选取S1开头的部分，这部分为程序的机器码。如图3.3所示。
图3.3 app 程序机器码
4、创建bootloader工程并对Prm文件作如下修改：
①修改分区，划分bootloader和app两个区域
②修改程序存放区域到ROM_BOOTLOADER区域
③定义APP程序存放区域APP_ROM
具体修改结果如下图3.4所示。
图3.4 bootloader prm 文件
5、修改bootloader的main函数，实现到app的跳转
①定义一全局数组，将机器码提取出来，并依次放入数组中。此数组必须在APP_ROM段中。
6、实现程序的跳转，其代码如下：
分别将APP工程程序和Bootloader程序烧进开发板，可以发现其运行效果一样，至此实验结束。
实验总结：
Bootloader的主要任务是将程序代码存放到相应的存储位置，然后主程序在跳转到相应的位置去执行APP代码，本次实验省略了下载存储的步骤，直接将APP代码放入了相应的存储位置，进行跳转执行；下面我们将通过串口刷写和CAN总线两种不同的方式实现程序的下载。
四、BootLoader的搬运工——串口
BootLoader引导程序
BootLoader引导程序 一、实验目的 1.学会配置linux下的minicom和windows下的超级终端 2.了解bootloader的基本概念和框架结构 3.了解bootloader引导操作系统的过程 4.掌握bootloader程序的编译方法 5.掌握bootloader程序的使用方法 二、实验内容 1. 学习x-loader 作用和编译过程 2.学习uboot作用和编译过程 3.学习bootloader的操作 三、实验设备 PentiumII以上的PC机， LINUX操作系统 四、BOOTLOADER程序说明 完整的系统由x-loader、u-boot、kernel（内核）、rootfs（根文件系统）组成，x-loader 是一级引导程序，其作用是初始化CPU，拷贝u-boot到内存，然后把控制权交给u-boot。当OMAP3530上电时，memory controller(内存控制器)还未初始化，这个任务便由完成的x-loader。初始化外部RAM控制器，把u-boot读到外部RAM，之后把控制入口交给。u-boot 是二级引导程序，其作用主要是引导内核，提供映像更新，同用户进行交互。系统结构图如 下： 1. BootLoader的作用 在嵌入式系统中，BootLoader的作用与PC机上的BIOS类似，其主要作用：（1）初始化硬件设备；（2）建立内存空间的映射图；（3）完成内核的加载，为内核设置启动参数。通过BootLoader可以完成对系统板上的主要部件如CPU、SDRAM、Flash、串行口等进行初始化，也可以下载文件到系统板上，对Flash进行擦除与编程。当运行操作系统时，它会在操作系统内核运行之前运行，通过它，可以分配内存空间的映射，从而将系统的软硬件环境带到一个合适的状态，以便为最终调用操作系统准备好正确的环境。 通常，BootLoader 是依赖于硬件而实现的，特别是在嵌入式系统中。因此，在嵌入式系统里建立一个通用的 BootLoader 几乎是不可能的，不同的处理器架构都有不同的
详解bootloader的执行流程与ARM Linux启动过程分析
详解bootloader的执行流程与ARM Linux启动过程分析 ARM Linux启动过程分析是本文要介绍的内容，嵌入式Linux 的可移植性使得我们可以在各种电子产品上看到它的身影。对于不同体系结构的处理器来说Linux的启动过程也有所不同。 本文以S3C2410 ARM处理器为例，详细分析了系统上电后bootloader的执行流程及ARM Linux的启动过程。 1、引言 Linux 最初是由瑞典赫尔辛基大学的学生Linus Torvalds在1991 年开发出来的，之后在GNU的支持下，Linux 获得了巨大的发展。虽然Linux 在桌面PC 机上的普及程度远不及微软的Windows 操作系统，但它的发展速度之快、用户数量的日益增多，也是微软所不能轻视的。而近些年来Linux 在嵌入式领域的迅猛发展，更是给Linux 注入了新的活力。 一个嵌入式Linux 系统从软件角度看可以分为四个部分：引导加载程序（bootloader），Linux 内核，文件系统，应用程序。 其中bootloader是系统启动或复位以后执行的第一段代码，它主要用来初始化处理器及外设，然后调用Linux 内核。 Linux 内核在完成系统的初始化之后需要挂载某个文件系统做为根文件系统（Root Filesystem）。 根文件系统是Linux 系统的核心组成部分，它可以做为Linux 系统中文件和数据的存储区域，通常它还包括系统配置文件和运行应用软件所需要的库。 应用程序可以说是嵌入式系统的“灵魂”，它所实现的功能通常就是设计该嵌入式系统所要达到的目标。如果没有应用程序的支持，任何硬件上设计精良的嵌入式系统都没有实用意义。 从以上分析我们可以看出bootloader 和Linux 内核在嵌入式系统中的关系和作用。Bootloader在运行过程中虽然具有初始化系统和执行用户输入的命令等作用，但它最根本
Stm8s_IAP_Bootloader设计
项目实践2：Bootloader 1.项目介绍 在之前的例程和实践中，我们都是使用st-link调试下载的方式进行程序烧录。大家可能已经认识到这种烧录方式的弊端了。因为这种烧录方式首先必须要有以下几个工具或者软件： 1.烧录工具（不能芯片支持的工具不一样，有ST-Link，JTAG等） 2.已经安装了IDE（IAR或者SVD或者CCS等）或者与烧录工具匹配的烧录软件的电脑 3.烧录前后需要物理上电掉电（不建议ST-Link进行热插拔），即开/关电源. 也许大家会觉得，对于学习而言，这些都能忍受。但是如果真正做成产品，如果还是用这种方式进行升级，那代价就太大。举个例子吧，我之前的工作是开发和维护大功率的UPS（不间断电源），主要客户是一些大型企业，例如银行的数据中心，中国移动网络中心。UPS内 部有许多ARM芯片，DSP芯片。这类应用场合，即便给程序升级，客户也不会让你断电的，而且因为安全性要求，一般MCU，DSP都是在产品内部，根本无法对外开放烧录盒的烧录 接口。所以绝大部分嵌入式产品，都会开发Bootloader程序。 那么什么是Boot Loader呢？一般来说，嵌入式产品的软件都会分为两部分，第一部分 为Bootloader，第二部分为主程序（Main APP），它们存放在flash的不同区域。Bootloader 是上电或者复位以后先执行的，通过它，我们可以初始化硬件设备、建立内存空间的映射图，检测程序的完整性，判断是否需要从Bootloader跳转到APP或者更新APP。而主程序呢，则是真正用来实现产品面向客户的功能的。 通常呢，在Bootloader会实现一种或者一种以上的IAP方式，可能是UART，SPI，CAN 或者Ethernet等。本次例程呢，就是设计一个Bootloader，允许用户用电脑的串口+超级终 端实现烧录功能
单片机自编程及Bootloader设计
单片机自编程及Bootloader设计 Bootloader是在单片机上电启动时执行的一小段程序。也称作固件，通过这段程序，可以初始化硬件设备、建立内存空间的映射图，从而将系统的软硬件环境带到一个合适的状态，以便为最终调用应用程序准备好正确的环境。 Boot代码由MCU启动时执行的指令组成。这里的loader指向MCU的Flash中写入新的应用程序。因此，Bootloader是依赖于特定的硬件而实现的，因此，在众多嵌入式产品中目前还不可能实现通用Bootloader。 Bootloader的最大优点是：在不需要外部编程器的情况下，对嵌入式产品的应用代码进行更新升级。它使得通过局域网或者Intemet远程更新程序成为可能。例如，如果有5 000个基于MCU的电能表应用程序需要更新，电能表制造商的技术人员就可以避免从事对每一个电能表重新编程的巨大工作量，通过使用Bootloader的功能，由控制中心通过电能表抄表系统网络，远程对5 000个电表重新编程。可见，Bootloader功能对于嵌入式系统的广泛应用具有十分重要的意义。 1 78K0/Fx2系列单片机简介 78K0/Fx2系列是带CAN控制器的8位单片机，该系列单片机广泛应用于汽车电子，智能仪表等领域。其内置POC（可编程上电清零电路）/LVI（可编程低电压指示器），单电压自编程闪存，引导交换功能（闪存安全保护），具有低功耗、宽电压范围、超高抗干扰等性能。 78K0系列单片机支持自编程（Self-programming）。所谓自编程，是指用Flash存储器中的驻留的软件或程序对Flash存储器进行擦除/编程的方法。通过单片机的自编程功能，可以设计Bootloader程序，通过串口等通信接口实现对产品重新编程、在线升级的功能。 以μPD78F0881为例。μPD78F0881为78KO/Fx2系列中的一款44管脚单片机，内置32 KB Flash ROM，2 KB RAM，自带2个串行通信接口。其内部Flash结构。为了方便实现擦除和编程，人为地将整个Flash分成若干个block，每个block大小为1 KB。block为自编程库函数中空白检测、擦除、校验的最小单位。blockO从地址0000H开始，程序都从0000H 开始执行。block0～block3共4 KB存储空间为Bootloader程序存储区域。block4～block31为应用程序存储区域。 为了防止Bootloader自身的升级失败，设计了引导交换功能。该功能定义2个簇，即Boot cluster0和Boot cluster1。Boot clustee0为block0～block3的4 KB存储空间，Boot cluster1为block4～block7的4 KB存储空间。因此，实际运用过程中，一般把应用程序的开始定义在2000H，也就是从block8开始。 Flash地址为0000H～FFFFH。7FFFFH～FFFFH存储空间为保留区域以及特殊功能寄存器区域等，用户无法对其进行编程。 2 自编程 2.1 自编程环境 2.1.1 硬件环境 FLMDO引脚是78KO/Fx2系列单片机为Flash编程模式设置的，用于控制MCU进入编程模式。在通常操作情况下，FLMDO引脚下拉到地。要进入自编程模式，必须使FLMDO引脚置成高电平。因此，通过一个普通I/O接口控制FLMD0引脚的电平。。 2.1.2 软件环境 1）使用通用寄存器bank3，自编程库函数，需要调用通用寄存器bank3。因此，在自编程时，不能对通用寄存器bank3操作。
bootloader
Boot Loader的启动流程和开发经验总结 Windows CE最大程度继承了桌面版Windows的丰富功能，但是Windows CE并不是一个通用的安装版操作系统。在形形色色的嵌入式设备世界里，一款CE系统通常只会针对某一种硬 件平台生成。 一般来说，Windows CE的开发过程可以分为：0AL(OEM Abstraction Layer)、驱动、应用程序开发三个步骤。其中，0AL开发最基本的一步是板级支持包（BSP），而BootLoader 设计则在BSP开发中具有极为关键的地位。 1．什么是BootLoader 嵌入式系统的启动代码一般由两部分构成：引导代码和操作系统执行环境的初始化代码。其中引导代码一般也由两部分构成：第一部分是板级、片级初始化代码，主要功能是通过设置寄存器初始化硬件的工作方式，如设置时钟、中断控制寄存器等，完成内存映射、初始化MMU等。第二部分是装载程序，将操作系统和应用程序的映像从只读存储器装载或者拷贝到系统的RAM中并执行。 （1）什么是板级BSP? BSP(Board Support Package)是板级支持包,是介于主板硬件和操作系统之间的一层,主要是为了支持操作系统，使之能够更好的运行于硬件主板。不同的操作系统对应于不同形式的BSP,例如WinCE的BSP和Linux的BSP相对于某CPU来说尽管实现的功能一样,可是写法和接口定义是完全不同的。所以，BSP一定要按照该系统BSP的定义形式来写，这样才能与上 层OS保持正确的接口,良好的支持上层OS。 （2）什么是Boot Loader
在BSP中有一个重要的组成部分就是BootLoader,它是在操作系统内核运行之前运行的一段小程序。通过这段小程序，可以初始化硬件设备、建立内存空间的映射图，从而将系统的软硬件环境带到一个合适的状态，为调用操作系统内核准备好环境。 一般来说，在嵌入式世界里BootLoader 是严重地依赖于硬件的，因此想建立一个通用的 BootLoader 几乎是不可能的。不同的 CPU 体系结构有不同的BootLoader，而且除了依赖于 CPU的体系结构外，BootLoader还依赖于具体的嵌入式板级设备的配置。这也就是说，对于两块不同的嵌入式板而言，即使它们是基于同一种 CPU 结构而构建的，要想让运行在一块板子上的 BootLoader 程序也能运行在另一块板子上，通常也都需要修改 BootLoader 的源程序。 2．BootLoader在PC机与嵌入式的区别比较 （1）引导程序在PC机和嵌入式上的区别 一般来说，在PC的硬件平台上，由于硬件启动根本就不是通过BootLoader（而是通过BIOS），所以BootLoader就不需要对CPU加电后的初始化做任何工作。在桌面系统中，有以下几种设备可以作为启动设备使用：硬盘、USB盘、光盘驱动器、还有网卡的Boot ROM 等。但无论选择了哪一种启动设备，操作系统都会去将该设备起始地址的内容读入内存，BIOS 将控制移交给引导装载程序。如果启动设备是IDE硬盘，这时通常将引导装载程序装入第一个扇区(通常被称做主引导扇区，MBR），然后将内容读入内存再运行。 在嵌入式平台上，引导装载程序是在硬件上执行的第一段代码，通常将引导程序放置在不易丢失的存储器的开始地址或者是系统冷启动时PC寄存器的初始值。在嵌入式系统中，通常并没有像BIOS那样的固件程序，因此整个系统的加载启动任务就完全由BootLoader来完
bootloader分析
Bootloader分析
?熟悉BootLoader的实现原理?认识Bootloader的主要任务?熟悉BootLoader的结构框架?U-boot使用
引言本章详细地介绍了基于嵌入式系统中的OS启动加载程序――Boot Loader的概念、软件设计的主要任务以及结构框架等内容。 一个嵌入式Linux系统从软件的角度看通常可以分为四个层次： ?1.引导加载程序。包括固化在固件(firmware)中的boot代码(可 选)，和Boot Loader两大部分。 ?2.Linux内核。特定于嵌入式板子的定制内核以及内核的启动参数。 ?3.文件系统。包括根文件系统和建立于Flash内存设备之上文件 系统。通常用ram disk来作为root fs。 ?4.用户应用程序。特定于用户的应用程序。有时在用户应用程序和 内核层之间可能还会包括一个嵌入式图形用户界面。常用的嵌入式GUI有：MicroWindows和MiniGUI。
?引导加载程序是系统加电后运行的第一段软件代码。回忆一下PC 的体系结构我们可以知道，PC机中的引导加载程序由BIOS(其本质就是一段固件程序)和位于硬盘MBR中的OS Boot Loader（比如，LILO和GRUB等）一起组成。 ?BIOS在完成硬件检测和资源分配后，将硬盘MBR中的Boot Loader读到系统的RAM中，然后将控制权交给OS Boot Loader。 Boot Loader的主要运行任务就是将内核映象从硬盘上读到RAM 中，然后跳转到内核的入口点去运行，也即开始启动操作系统。 而在嵌入式系统中，通常并没有像BIOS那样的固件程序（注，有的嵌入式CPU也会内嵌一段短小的启动程序），因此整个系统的加载启动任务就完全由Boot Loader来完成。 ?比如在一个基于ARM7TDMI core的嵌入式系统中，系统在上电 或复位时通常都从地址0x00000000处开始执行，而在这个地址 处安排的通常就是系统的Boot Loader程序。
tms320c6000系列二次bootloader的设计与实精)
TMS320C6000系列二次Bootloader的设计与实 (精) TMS320C6000系列二次Bootloader的 设计与实现,DSP,二次 Bootloader,Flash存储器,中断向 引言随着DSP(数字信号处理器)系统的广泛应用，其程序规模也随之不断扩大，使用芯片本身自带的Boot-loader通过Flash存储器来引导DSP程序，往往受到程序大小和结构的制约，比如程序很大超过厂商固化boot的范围，再如中断向量表的不同位置对程序boot跳转的影响，等等，因此越来越需要更加灵活的引导方式。系统上电后，由引导程序将DSP的应用程序从该存储器引导到DSP应用板上的高速存储器(如内部SRAM、SDRAM等)中。由于Flash存储器具有 引言 随着DSP(数字信号处理器)系统的广泛应用，其程序规模也随之不断扩大，使用芯片本身自带的Boot-loader通过Flash存储器来引导DSP程序，往往受到程序大小和结构的制约，比如程序很大超过厂商固化boot的范围，再如中断向量表的不同位置对程序boot跳转的影响，等等，因此越来越需要更加灵活的引导方式。 系统上电后，由引导程序将DSP的应用程序从该存储器引导到DSP应用板上的高速存储器(如内部SRAM、SDRAM等)中。由于Flash存储器具有电信号删除功能，且删除速度快，集成度高，因此已成为此种存储器的首选。由于Flash存储器的存取
速度较慢，写入Flash存储器的程序将在系统上电时被DSP装载到快速的存储器中运行，这个过程称为Boot loader。不同的DSP有不同的引导方式。以TI公司TMS320C6000系列芯片为例，自举方式有3种：无自举(No Boot)，CPU直接开始执行地址0处的指令；主机自举(Host Boot)，系统复位后主机通过CPU的HPI(主程序设计接口)初始化DSP的存储空间；ROM自举(ROM Boot)，DMA控制器从CEl 空间复制固定长度程序的地址0处，然后从地址0处开始执行。对于620x／670x DMA，复制64 kB数据从CEl到地址0；而对于621x／671x EDMA，复制1 kB数据从CEl地址开始到地址0。 关于TI公司的C6000芯片二次Bootloader在许多文献都介绍过，包括二次Bootloader的PLL、EMIF的设置和搬移表的设置和Flash存储器的烧写过程，但是对于有中断向量表的二次Bootloader实现的文献很少。本文以TI公司高性能DSP的代表作TMS320C6000系列芯片为例，介绍了一种带中断向量表的二次Bootloader 的新途径，从而为TMS320C6000系列DSP的开发提供了一种新的思路。该方法在实际中得到具体应用，系统运行稳定可靠。 1 二次Bootload的过程 TMS320C6713是TI公司推出的TMS320C67xx系列浮点DSP中最新的一种芯片。TMS320C6713每周期可以执行8条32位指令；支持32／64位数据；具有最高225MHz的运行速度和1800 MIPs(百万次运算每秒)或1350 MFLOPS(百万次浮点运算每秒)的处理能力；同时是有强大的外设支持能力；EMIP(外部存储器接口)可以很方便地与SDRAM、SBSRAM、Flash存储器、SRAM等同步和异步存储器相连，16位EHPI接口可以与各种处理器接口；另外，还有优化的多通道缓存串口和多通道音频串口，这些外部接口使设计人员可以很容易实现自己的应用系统。 在选择ROMBoot方式时，RESET由低变高后，C6713的CPU内核处于复位状态，而C6713的其他部分则开始工作，此时EMIF的CEl空间根据ROM Boot的方式
单片机自编程及Bootloader设计
?Bootloader是在单片机上电启动时执行的一小段程序。也称作固件，通过这段程序，可以初始化硬件设备、建立内存空间的映射图，从而将系统的软硬件环境带到一个合适的状态，以便为最终调用应用程序准备好正确的环境。 Boot代码由MCU启动时执行的指令组成。这里的loader指向MCU的Flash中写入新的应用程序。因此，Bootloader是依赖于特定的硬件而实现的，因此，在众多嵌入式产品中目前还不可能实现通用Bootloader。 Bootloader的最大优点是：在不需要外部编程器的情况下，对嵌入式产品的应用代码进行更新升级。它使得通过局域网或者Intemet远程更新程序成为可能。例如，如果有5 000个基于MCU的电能表应用程序需要更新，电能表制造商的技术人员就可以避免从事对每一个电能表重新编程的巨大工作量，通过使用Bootloader的功能，由控制中心通过电能表抄表系统网络，远程对5 000个电表重新编程。可见，Bootloader功能对于嵌入式系统的广泛应用具有十分重要的意义。 1 78K0/Fx2系列单片机简介 78K0/Fx2系列是带CAN控制器的8位单片机，该系列单片机广泛应用于汽车电子，智能仪表等领域。其内置POC（可编程上电清零电路）/LVI（可编程低电压指示器），单电压自编程闪存，引导交换功能（闪存安全保护），具有低功耗、宽电压范围、超高抗干扰等性能。 78K0系列单片机支持自编程（Self-programming）。所谓自编程，是指用Flash存储器中的驻留的软件或程序对Flash存储器进行擦除/编程的方法。通过单片机的自编程功能，可以设计Bootloader程序，通过串口等通信接口实现对产品重新编程、在线升级的功能。 以μPD78F0881为例。μPD78F0881为78KO/Fx2系列中的一款44管脚单片机，内置32 KB Flash ROM，2 KB RAM，自带2个串行通信接口。其内部Flash结构如图1所示。为了方便实现擦除和编程，人为地将整个Flash分成若干个block，每个block 大小为1 KB。block为自编程库函数中空白检测、擦除、校验的最小单位。blockO从地址0000H开始，程序都从0000H开始执行。block0～block3共4 KB存储空间为 Bootloader程序存储区域。block4～block31为应用程序存储区域。
Linux启动全过程-由bootloader到fs
Linux启动过程 许多人对Linux的启动过程感到很神秘，因为所有的启动信息都在屏幕上一闪而过。其实Linux的启动过程并不象启动信息所显示的那样复杂，它主要分成两个阶段： 1.启动内核。在这个阶段，内核装入内存并在初始化每个设备驱动器时打印信息。 2.执行程序init。装入内核并初始化设备后，运行init程序。init程序处理所有程序的启动， 包括重要系统精灵程序和其它指定在启动时装入的软件。 下面以Red Hat为例简单介绍一下Linux的启动过程。 一、启动内核 首先介绍启动内核部分。电脑启动时，BIOS装载MBR，然后从当前活动分区启动，LILO获得引导过程的控制权后，会显示LILO提示符。此时如果用户不进行任何操作，LILO将在等待制定时间后自动引导默认的操作系统，而如果在此期间按下TAB键，则可以看到一个可引导的操作系统列表，选择相应的操作系统名称就能进入相应的操作系统。当用户选择启动LINUX操作系统时，LILO就会根据事先设置好的信息从ROOT文件系统所在的分区读取LINUX映象，然后装入内核映象并将控制权交给LINUX内核。LINUX内核获得控制权后，以如下步骤继续引导系统： 1. LINUX内核一般是压缩保存的，因此，它首先要进行自身的解压缩。内核映象前面的一些代码完成解压缩。 2. 如果系统中安装有可支持特殊文本模式的、且LINUX可识别的SVGA卡，LINUX会提示用户选择适当的文本显示模式。但如果在内核的编译过程中预先设置了文本模式，则不会提示选择显示模式。该显示模式可通过LILO或RDEV工具程序设置。 3. 内核接下来检测其他的硬件设备，例如硬盘、软盘和网卡等，并对相应的设备驱动程序进行配置。这时，显示器上出现内核运行输出的一些硬件信息。 4. 接下来，内核装载ROOT文件系统。ROOT文件系统的位置可在编译内核时指定，也可通过LILO 或RDEV指定。文件系统的类型可自动检测。如果由于某些原因装载失败，则内核启动失败，最终会终止系统。 二、执行init程序 其次介绍init程序，利用init程序可以方便地定制启动其间装入哪些程序。init的任务是启动新进程和退出时重新启动其它进程。例如，在大多数Linux系统中，启动时最初装入六个虚拟的控制台进程，退出控制台窗口时，进程死亡，然后init启动新的虚拟登录控制台，因而总是提供六个虚拟登陆控控制台进程。控制init程序操作的规则存放在文件/etc/inittab中。Red Hat Linux缺省的inittab文件如下：# #inittab This file describes how the INIT process should set up the system in a certain #run-level. # # #Default runlevel.The runlevels used by RHS are: #0-halt(Do NOT set initdefault to this) #1-Single user mode #2-Multiuser,without NFS(the same as 3,if you do not have networking) #3-Full multiuser mode #4-unused #5-X11 #6-reboot(Do NOT set initdefault to this)
Boot_Loader介绍
Boot Loader Windows CE最大程度继承了桌面版Windows的丰富功能，但是Windows CE并不是一个通用的安装版操作系统。在形形色色的嵌入式设备世界里，一款CE系统通常只会针对某一种硬件平台生成。 一般来说，Windows CE的开发过程可以分为：0AL(OEM Abstraction Layer)、驱动、应用程序开发三个步骤。其中，0AL开发最基本的一步是板级支持包（BSP），而BootLoader 设计则在BSP开发中具有极为关键的地位。 1．什么是BootLoader 嵌入式系统的启动代码一般由两部分构成：引导代码和操作系统执行环境的初始化代码。其中引导代码一般也由两部分构成：第一部分是板级、片级初始化代码，主要功能是通过设置寄存器初始化硬件的工作方式，如设置时钟、中断控制寄存器等，完成内存映射、初始化MMU等。第二部分是装载程序，将操作系统和应用程序的映像从只读存储器装载或者拷贝到系统的RAM中并执行。 （1）什么是板级BSP? BSP(Board Support Package)是板级支持包,是介于主板硬件和操作系统之间的一层,主要是为了支持操作系统，使之能够更好的运行于硬件主板。不同的操作系统对应于不同形式的BSP,例如WinCE的BSP和Linux的BSP相对于某CPU来说尽管实现的功能一样,可是写法和接口定义是完全不同的。所以，BSP一定要按照该系统BSP的定义形式来写，这样才能与上层OS保持正确的接口,良好的支持上层OS。 （2）什么是Boot Loader 在BSP中有一个重要的组成部分就是BootLoader,它是在操作系统内核运行之前运行的一段小程序。通过这段小程序，可以初始化硬件设备、建立内存空间的映射图，从而将系统的软硬件环境带到一个合适的状态，为调用操作系统内核准备好环境。
stm32f103rb的bootloader软件安全设计方案
STM32F103RB的Bootloader软件安全设计 方案 时间：2009-10-19 12:31:50 来源：单片机与嵌入式系统作者：深圳大学林郭安黄强许文焕 引言 随着嵌入式系统产品的发展，其功能趋向系统化、复杂化，不同场合和具体应用对产品的升级维护提出了更多的需求。厂商针对这一问题普遍采用。Bootloader引导应用程序结构的嵌入式软件，在产品升级和维护过程中只需提供升级程序包由Bootloader在升级模式下更新产品的应用程序，即可快捷地实现产品升级。 一直以来，嵌入式软件的安全和知识产权保护是厂商面对市场竞争着重关心的焦点。嵌入式系统处理器的有限硬件资源和高效率要求使得其难以应用复杂和大运算量的加密算法，对代码的保护更多依赖于硬件，这往往具有很多潜在的安全隐患。本文就．Bootloader引导应用程序结构的软件在STM32F103RB芯片上应用时，遭到篡改攻击后所面临的代码泄漏风险进行研究和验证，并提出了改进Bootloader的安全设计方案，加强代码的安全性。 1 篡改攻击风险研究 1．1 研究的意义 嵌入式系统产品的开发往往成本高、开发周期长，一旦产品中的嵌入式软件被抄袭或盗窃都将给厂商带来巨大的损失。随着嵌入式处理器设计技术的发展，对片内Flash 中的代码保护也日渐完善。芯片在保护状态下，可以完全禁止通过调试接口或SRAM中运行的程序读取Flash内容，但产品阶段保存在Flash中的代码运行时对自身的读取是允许的，如果非法使用者通过特殊手段篡改了Flash中的部分代码为非法读取程序，并使之在Flash 中成功运行，将使产品代码发生部分泄漏，这就是产品面临的篡改攻击风险。针对这一风险的研究在实际应用中显得十分重要。 ST公司推出的STM32系列微处理器采用ARM新一代Cortex-M3内核，其中增强型的STM32F103RB具有72 MHz主频、20 KB片内SRAM、128 KB片内Flash以及丰富的接口资源，可以很好地满足广泛的嵌入式产品的应用需求。较低的芯片价格和简单的开发方式使之应用前景非常广阔，对该芯片上代码的安全研究也具有深远意义。 1．2 风险研究 Bootloader引导应用程序结构的嵌入式软件可以满足产品功能升级和维护的需求，在实际应用中被厂商普遍采用。Bootloader程序是在系统上电复位后在Flash中首先执行的一小段代码，其基本功能模块如图1所示。
基于MC9S12XS128 的BootLoader设计
基于MC9S12XS128 的BootLoader 设计 前言 接触飞思卡尔芯片大概有4个月的时间了，对这款16位寄存器有了一定的了解，但是因为飞思卡尔单片机的资料特别少，bootloader相关资料几乎没有，为此写下这篇设计书，方便大家学习参考交流，其中有不对的地方还请大家批评指正。本设计书主要讲解bootloader的实现过程，需对飞思卡尔16位单片机有一定的基础，了解该系列芯片的开发环境CodeWarrior5.1。 一、BootLoader的基石Prm 文件 我们在用CodeWarrior创建一个工程后会产生很多文件，其中有一个连接用的Prm文件，他的位置如图1.1所示。 图1.1 Codewarrior的Prm文件是用来划分代码段、数据段的，这类似于liunx中的连接脚本文件。程序一开始是进行初始化，然后跳转到main函数执行的，这段代码全部放在了ROM_C000处，而ROM_C000对应的地址是0xC000 到0xFEFF，具体实现代码如图1.2所示。第一部分是指明ROM_C000对的地址，第二部分是指明代码所存放的位置是ROM_C000。 我们知道bootloader和app必须在不同的ROM区域，bootloader接收到上位机发送的程序，先将其存储，后再跳转到app位置执行，所以prm文件可以帮我们实现bootloader与app程序的分离。 具体实现方法如下： 1、将原来的ROM_C000分成两个部分，ROM_BootLoader和ROM_App，因为bootloader代码较小需要保护，所以将其地址设置成0xf000-0xfeff，App的地址设置成0xc000-0xefff，这样这两块的总地址大小正好是原ROM_C000的大小。
bootloader流程
Bootloader 设计分析 3.1 Bootloader 的操作模式 (Operation Mode) 大多数 Bootloader 都包含两种不同的操作模式[2]： (1). 启动加载（Boot loading）模式：也称为“自主”模式。即Bootloader 从目标机上的某个固态存储设备上将操作系统加载到 RAM 中运行，整个过程并没有用户的介入。 (2).下载（Downloading）模式：在这种模式下，目标机上的Bootloader将通过串口或网络连接等通信手段从主机（Host）下载内核映像和根文件系统映像等，然后保存到目标机上的FLASH 类固态存储设备中。Bootloader的这种模式通常在系统初次安装和更新时被使用，工作于这种模式下的Bootloader通常都会向它的终端用户提供一个简单的命令行接口。 在我们的Bootloader设计中我们同时支持这两种工作模式，采用的方法是：一开始启动时处于正常的启动加载模式，但并不立即启动进入uClinux内核，而是提示延时5秒，等待终端用户如果按下某一特定按键，则切换到下载模式，否则继续启动uCLinux 内核。 3.2 Bootloader 的启动及初始化 基于ARM的芯片多数为复杂的片上系统（SoC），这类复杂系统里的多数硬件模块都是可配置的[3]。因此大多数 Bootloader 都分为 stage1 和 stage2 两大部分。依赖于 CPU 体系结构的代码，通常都放在 stage1 中，而且在这一部分，我们直接对处理器内核和硬件控制器进行编程，因此常常都用汇编语言来实现。而stage2则通常用C语言来实现，这样可以实现更复杂的功能，而且代码会具有更好的可读性和可移植性。 3.2.1 Bootloader的stage1 这部分代码必须首先完成一些基本的硬件初始化，为stage2的执行以及随后的kernel 的执行准备好一些基本的硬件环境[2]。Bootloader的stage1一般通用的内容包括： * 定义程序入口点 * 设置异常向量表 * 初始化存储系统（包括地址重映射） * 初始化有特殊要求的端口，设备 * 初始化用户程序的执行环境
飞思卡尔关于Bootloader的设计
Implement UART Boot-loader On Coldfire V1 Products Paul Zhang, Freescale Shanghai. (paul.zhang@https://www.360docs.net/doc/ad9288264.html,) Boot-loader is commonly needed when designing such an embedded system which requires frequent firmware upgrade in the field or via remote. Most of Freescale’s flash based microcontrollers are capable to do flash-programming in the application and on-the-fly. The newly released Coldfire V1 core 32-bit MCU is no exception. This article is aimed at revealing some implementation details to design a boot-loader via conventional UART data port. We’ll use the 1st released V1 part MCF51QE128 and its accompanied evaluation board DEMOQE128 (Figure-1) as hardware platform to test and demonstrate the application. This demo board is easily orderable via 3rd party P&E Microcomputer System (https://www.360docs.net/doc/ad9288264.html,/). We use Freescale’s own software IDE CodeWarrior as the software development platform. The latest version who supports CF V1 parts is CW V6.1. You can download a special edition free of charge after logged or registered in Freescale’s web site: https://www.360docs.net/doc/ad9288264.html,/ 1. Simple theory of Boot-loader Boot-loader by any means is just a section of specially designed executable code which resides in a carefully allocated memory area in a chosen MCU. It’ll be largely, if not absolutely, transparent to normal user application code flow. However, once activated by some pre-set conditions, it can take over the full control of all MCU resources, receive new code data via any possible communication channels, re-program the partial or even entire Flash code memory and finally kick off a brand new application code to run with the same hardware system. 2. Introduction of V1 memory map Before designing a boot-loader on a specific MCU, it’s essential to fully understand its memory map. We need to put the boot-loader at a specific memory area where it has least intrusion to normal user application code. We must well understand how the reset & interrupt vector scheme works on this particular MCU so that the boot-loader can manipulate some or all vectors behind the scene to give the highest efficiency and flexibility for user applications. Figure-2 shows the entire memory map on MCF51QE128. In overall it has 128K bytes on-chip Flash memory and 8K DEMOQE128 Figure-1 Memory map on MCF51QE128 Figure-2
移植Bootloader过程总结
一．linux系统上电后启动过程： ---→启动引导加载程序bootloader（一些CPU在运行bootloader之前，会先运行一段固化的程序）。 --->启动内核 --->挂载根文件系统 其中，Boot paramoters分区中放置一些可设置的参数，比如，IP地址、串口波特率、要传递给内核的命令行参数等。 二．为什么要进行bootloader移植？ ---→bootloader的实现依赖于具体的硬件，而在嵌入式产品中硬件的配置千差万别，即使相同的CPU，它的外设也有可能不同，所以不可能有一个bootloader支持所有的CPU，即使是支持CPU架构比较多的U-Boot，也不是拿来就能用的，也需要做一些简单的移植。 三.Bootlader的启动过程分为两个阶段： 第一阶段： --->硬件设备的初始化（进入svc模式、关闭watchdog、禁中断、设置系统时钟频率、初始化存储控制器、初始化堆栈）。 --->uboot的代码重定位，从nand中拷贝至sdram中，默认是从norflash拷贝至sdram --->跳转到第二阶段c代码继续执行 第二阶段： --->初始化本阶段要使用的硬件设备（如串口）。 --->检测系统内存的映射（memory map）。 --->从flash读取内核镜像和文件系统到sdram中。
--->为内核设置启动参数。 --->启动内核。 注意：1、所谓检测内存映射，就是确定板子上使用了多少内存，它们的地址空间如何 2、存储在flash上的内核镜像可能是压缩的（如.cramfs 格式），在读到内存中就需要解压，但是对于带有自解压功能的内核来说，是不需要boorloader来解压。 3、将根文件系统拷贝到sdram中，这个不是必须的，具体看内核访问它的方式。
BOOTLOADER启动程序分析
BOOTLOADER启动程序分析 ——基于工程D003_Malata35P_63509_chinese 桂洁 2007.12.3 .eboot.nb0是第一次被JTAG烧到NOR。以后，bootloader负责对：xip.bin：先写到RAM，再烧到nand flash； nk.bin：直接写到RAM； eboot.bin：由eboot.nb0下载，先写到RAM，再烧到nor flash。 上电后：eboot本身会将自己写到RAM。也会把nand中的镜像写到RAM中再执行。 程序一上电，自动执行0x00000000处的指令。所以，只要把这条指令设定好，下面就可以按我们自己的思想进行设计。 一．f wxsc1.s 位于：D:\WINCE420\PLA TFORM\SEUICBSP\KERNEL\HAL\ARM 这是startup。他是一个汇编程序。 1.入口为：LEAF_ENTRY StartUp，第一条语句是：B Reset_Handler， 放在0x00000000处。所以上电后首先执行这条指令。 2.Reset_Handler，是StartUp的主体。根据复位类型进行硬件的初始 化。具体步骤为（可能不是很准确）：串口初始化，CPU进入特殊指令模式，关MMU，关中断，检查复位原因，初始化硬件（GPIO，
内存，中断控制器，时钟，PowerManager），通过串口打印信息，查SDRAM，bootloader将自己写到RAM，检查正确性，跳到RAM，设置并使能MMU，Cache，设堆。 3.最后一条语句是bl main。跳到main函数。 二main 1．main 位置：D:\WINCE420\PLA TFORM\SEUICBSP\EBOOT\main.c。 作用：调用BootloaderMain()。 2．BootloaderMain 位置： D:\WINCE420\PUBLIC\COMMON\OAK\DRIVERS\ETHDBG\BLCOMMON\blco mmon.c 作用：这是bootloader的框架。
BootLoader 的概念与功能
U-Boot之一：BootLoader 的概念与功能 一般情况下嵌入式Linux 系统中的软件主要分为以下几部分： 1) 引导加载程序：其中包括内部ROM 中的固化启动代码和BootLoader 两部分。内部固化ROM 是厂家在芯片生产时候固化的，作用基本上是引导BootLoader。有的芯片比较复杂，比如Omap3 在flash 中没有代码的时候有许多启动方式：USB、UART 或以太网等等。而S3C24x0 则很简单，只有Norboot 和Nandboot。 2) Linux kernel 和drivers。 3) 文件系统。包括根文件系统和建立于Flash 内存设备之上的文件系统（EXT4、UBI、CRAMFS 等等）。它是提供管理系统的各种配置文件以及系统执行用户应用程序的良好运行环境及载体。 4) 应用程序。用户自定义的应用程序，存放于文件系统之中。 在Flash 存储器中，他们的分布一般如下： 但是以上只是大部分情况下的分布，也有一些可能根文件系统是initramfs，被一起压缩到了内核映像里，或者没有Bootloader 参数区，等等。 1.2 在嵌入式Linux 中BootLoader 的必要性 Linux 内核的启动除了内核映像必须在主存的适当位置，CPU 还必须具备一定的条件：
但是在CPU 刚上电启动的时候，一般连内存控制器都没有初始化过，根本无法在主存中运行程序，更不可能处在Linux 内核启动环境中。为了初始化CPU 及其他外设，使得Linux 内核可以在系统主存中运行，并让系统符合Linux 内核启动的必备条件，必须要有一个先于内核运行的程序，他就是所谓的引导加载程序（Boot Loader）。 而BootLoader 并不是Linux 才需要，而是几乎所有运行操作系统的设备都需要。我们的PC 的BOIS 就是Boot Loader 的一部分（只是前期引导，后面一般还有外存中的各种BootLoader），对于Linux PC 来说，Boot Loader = BIOS + GRUB/LILO。 1.3 Boot Loader 的功能和选择 综上所述：BootLoader 是在操作系统内核启动之前运行的一段小程序。通过这段程序，我们可以初始化硬件设备，从而将系统的软硬件环境带到一个合适的状态，以便为最终调用操作系统内核准备好正确的环境，最后从别处（Flash、以太网、UART）载入内核映像到主存并跳到入口地址。 由于BootLoader 需要直接操作硬件，所以它严重依赖于硬件，而且依据所引导的操作系统的不同，也有不同的选择。对于嵌入式世界中更是如此。就S3C24x0 而言，如果是引导Linux，一般选用韩国的mizi 公司设计的vivi 或者DENX 软件工程中心的Das U-boot，如果是引导Win CE，就选用Eboot。如果是开发StrongARM 构架下的LART，就可选用由Jan-Derk Bakker 和Erik Mouw 发布的Blob(Boot Loader Object)。如果是要引导eCos 系统，可 以选用同是RedHat公司开发的Redboot。 所以在嵌入式世界中建立一个通用的BootLoader 几乎是不可能的，而可能的是让一个Boot Loader 代码支持多种不同的构架和操作系统，并让她有很好的可移植性。U-boot 就是支持多平台多操作系统的一个杰出代表。这也是U-boot 的优势所在，因为如果在开发 S3C2440 时熟悉了U-boot，再转到别的平台的时候，就可以很快地完成这个平台下U-boot 的移植。而且U-boot 的代码结构越来越合理，对于新功能的添加也十分容易。