文档库 最新最全的文档下载
当前位置:文档库 › bootloader

bootloader

bootloader
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是最先被执行的程序,所以就必须包括加电初始化程序。

(2)BSP在嵌入式和桌面Windows中的区别

其实运行在PC机上的桌面Windows或Linux系统也是有BSP的,只是PC机均采用统一的X86体系架构,这样操作系统的BSP相对X86架构是单一确定的,不需要做任何修改就可以很容易支持OS在X86上正常运行,所以在PC机上谈论BSP这个概念也就没什么意义了。

而对嵌入式系统来说情况则完全不同,目前市场上有多种结构的嵌入式CPU(如

X86,ARM,MIPS等),而且为了性能的需要,外围设备也会有不同的选择和定义。因此,一个嵌入式操作系统针对不同的CPU会有不同的BSP,又即使同一种CPU,由于外设的差别其BSP 也会不一样。所以根据硬件设计编写和修改BSP,是保证嵌入式系统正常运行的一个重要环

节。

(3)嵌入式BSP与PC机主板BIOS的区别

PC机主板上的BIOS首先是负责在电脑开启时检测、初始化系统设备、装入操作系统并调度操作系统向硬件发出的指令。它的Firmware代码是在芯片生产过程中固化的,一般来说用户是无法修改。然后,为下载运行操作系统做准备,把操作系统由硬盘加载到内存,并传递一些硬件接口设置给系统。在OS正常运行后,BIOS的作用基本上也就完成了,这就是为什么

更改BIOS一定要重新关机开机。

从这个角度来说,PC机BIOS的作用就象嵌入式系统中的Bootloader,都是最底层的引导软件,初始化主板的基本设置,为接收外部程序做硬件上的准备。但与Bootloader不同的是,BIOS在装载OS系统的同时还传递一些参数设置,而Bootloader只是简单的装载系统。尽管BSP的开始部分和BIOS所做的工作类似,可是大部分又和BIOS不同,作用也完全不同。因为BSP还包含和系统有关的基本驱动,程序员可以编程修改BSP,在BSP中任意添加一些和系

统无关的驱动或程序,甚至可以把上层开发的统统放到BSP中。而BIOS程序是用户不能更改和编译编程的,只能对参数进行修改设置,当然更不会包含一些基本的硬件驱动。

3.Boot Loader的启动流程

大多数 BootLoader 都包含两种不同的操作模式:启动加载模式和下载模式。启动加载模式也称为自主模式,即 BootLoader 从目标机上的某个固态存储设备上将操作系统加载到RAM 中运行,整个过程并没有用户的介入。而下载模式则是目标机上的 BootLoader 将通过串口连接或网络连接等通信手段从主机(Host)下载文件。从主机下载的文件通常首先被Boot Loader 保存到目标机的 RAM 中,然后再被 BootLoader 写到目标机上的FLASH 类固态存储设备中。这种模式通常在第一次安装内核与根文件系统时被使用,或系统更新时使用。一般嵌入式系统的Boot Loader较为常用的是启动加载模式,它的加载流程也是我们要重点

讨论的内容。

(1)启动部分

启动部分主要是实现初始化硬件的功能。在参考板的BootLoader目录下,会发现一些.s 文件,可能会是init.s或者是reset.s等,这样的文件是CPU加电后最先执行的代码。接着Oal.exe通过Startup函数完成硬件的初始化,StartUp 函数是Boot Loader的入口函数。该函数一般是使用汇编语言编写,与CPU关系非常紧密,能完成初始化CPU、内存等核心硬

件。

Startup.s代码与硬件平台的Bootloader启动代码共用。如果是热启动,即在该函数调用之前已经启动了Bootloader程序,相当基本硬件初始化已经完成,则直接跳转到OALStartUp函数中;否则需要进行硬件中断屏蔽、内存、系统时钟频率、电源管理等硬件的基本初始化过程。在系统硬件初始化完毕之后,Startup调用OALStartUp函数,OALStartUp 函数主要完成将OEMAddressTable表传递给内核,然后调用KernelStart函数跳转到内核。

因此,这部分工作是BootLoader的一大重点。

(2)主控部分

StartUp 函数初始化CPU等核心硬件并跳转到Main函数后,系统就会转入C语言代码执行环境。这时函数分为3个模块:BLCOMMON、Download Function、FLASH Function。其中BLCOMMON 模块是由微软提供的,执行一些逻辑上的功能,因此建议开发人员不要对其进行修改。而Download Function、FLASH Function中的函数与硬件平台息息相关,因此对于每种硬件平

台都要将函数的实现进行修改。

其中,BLCOMMON库是与BootLoader程序链接在一起的,BLCOMMON库的入口点为BootloaderMain函数,它是Startup汇编函数完成后跳转至该入口的。Main函数的主要任务时调用BLCommon中的 BootloaderMain()函数,这是BootLoader的主控函数,它控制了BootLoader的完整执行流程。这部分代码由C语言实现,是BLCOMMON代码的一部分,它可以用来执行比较复杂的操作。比如检测内存和Flash的有效性、检测外部设备接口、检测串口并且向已经连接的主机发送调试信息、通过串口等待命令、启动网络接口、建立内存映射

等汇编无法完成的工作。

(3)下载部分

一般在平台调试完毕后,可以在不用人工干预的情况下自动加载CE,这也是BootLoader 的功能之一。而在调试阶段时,这需要通过Loader所支持的命令来进行操作的,借助于这些命令不仅可以完成硬件平台的部分测试,还能完成CE的BootLoader程序最为重要的一个功能--下载CE映像。如果说硬件调试功能可以由其它的程序代替而不放入BootLoader中,但是下载映像文件却是BootLoader必需的功能。

CE映像文件通常叫做nk.bin,它是Windows CE二进制数据格式文件,不仅包含了有效的程序代码,还有按照一定规则加入的控制信息。当然,也可以选择生成.sre格式的代码文件,但是相于对前一种格式,它的代码要长很多,所需要的下载时间也更长。

(4)支持DOC部份

对于WinCE操作系统而言,丰富的多媒体功能是其一大特点。但是随之而来的问题是,如果选择了图形界面和中文支持,系统很容易大大超出嵌入式系统上百KB的数量级。而DOC(Disk On Chip)则提供了一种相对廉价的大存储容量的解决方案。

DOC本质上是一种加以软件控制的NAND格式的Flash,通过TFFS这一软件层提供对WinCE 的支持。由于DOC不能像内存一样被直接访问,所以其加载WinCE的过程有些特殊,必须要在BootLoader中加入专门的代码,才能使用DOC来存放WinCE映像文件。

4.Boot Loader的开发经验总结

(1)嵌入式系统中,Bootloader的意义与作用与PC上的BIOS有点类似,它对开发板上的主要部件如CPU、SDRAM、FLASH、串口等进行了初始化,也可以使用Bootloader下载文件到开发板和启动系统等。因此,一个功能比较强大的Bootloader已经相当于一个微型的

操作系统了。

(2)从CE的BootLoader开发流程可以看出,BootLoader在完成下载CE映像和加载映像的主要功能外,还具有一些调试硬件的功能。当然,这些功能不是必需的,随不同的用户有不同的定义,但这是在开发CE系统中不可跳过的一环。

(3)嵌入式系统应用开发不同于PC机,其开发过程同时涉及软硬件以及上层应用开发综合考虑;而PC机应用开发是建立在已经定制好的硬件和操作系统平台上,开发者只需调用系统提供的接口和服务完成相应的功能。考虑到成本约束,嵌入式系统的硬件平台通常是根据应用量身定制,通常所用的MPU、存储器、外围设备等有多种选择余地,使平台的引导设计变得十分复杂。因此,从零实现的话会需要相当长的过程,通常的做法是利用微软为每种类型CPU提供的标准开发板的BootLoader例程,从这些例程中寻找与硬件平台最接近的作为标本程序,然后根据硬件平台作相应的改动。

阐述对BootLoader的理解和分析

` 物理与电子工程学院 《嵌入式系统设计》 设计性实验报告 题目阐述对BootLoader的理解和分析 系别 年级专业 班级学号 学生姓名 指导教师 实验时间

目录 课题要求 ................................................................ 错误!未定义书签。 1.本课题的目的.............................. 错误!未定义书签。 2.运行环境.................................. 错误!未定义书签。正文 . (2) 一.BootLoad简介 (2) 二.系统设计 (5) 三.技术实现问题 (7) 四.总结与体会 (8) 设计性实验报告成绩:指导教师签名: (10)

摘要 在嵌入式系统中,由于不具有自举开发的能力,其BootLoader除了引导操作系统之外,还要担负辅助开发的责任,如与主机通信、与用户交互、更新系统等功能。 虽然嵌入式系统不可能实现通用的BootLoader,但是各系统的BootLoader依然具有一定的相同性,因此,嵌入式系统中常用的BootLoader也都具有可移植性,可以在大部分代码不更改的情况下,根据本系统的情况,通过修改具体硬件相关的代码并进行相应的配置来使用。 关键字:概述,作用,操作模式,分类,基本原理。 正文 一.BootLoad简介 1.1 BootLoader的概述 BootLoader是操作系统和硬件的纽带,它负责初始化硬件,引导操作系统内核,检测各种参数给操作系统内核使用。事实上,一个功能完备的大型BootLoader,就相当于一个小型的操作系统。在嵌入式领域中,操作系统移植的关键在于BootLoader的移植以及操作系统内核与硬件相关部分的移植。Bootloader是在操作系统运行之前执行的一段小程序。通过这段小程序,我们可以初始化硬件设备、建立内存空间的映射表,从而将系统软硬件环境带到一个合适的状态,以便为最终调用操作系统内核准备好正确的环境。通常,Bootloader是严重依赖于硬件而实现的,特别是在嵌入式世界里,嵌入式产品型号众多,硬件环境复杂,建立一个通用的Bootloader几乎是不可能的。尽管如此,仍然可以对Bootloader归纳出一些通用的概念来,以指导特定的Bootloader设计与实现。因此,正确进行Linux移植的条件是具备一个与Linux配套、易于使用的Bootloader,它能够正确完成硬件系统的初始化和Linux的引导。 Bootloader不但依赖于CPU的体系结构,而且依赖于嵌入式系统板级设备的配置。对于两块不同的嵌入式板而言,即使它们使用同一种处理器,要想让运行在一块板子上的Bootloader程序也能运行在另一块板子上,一般也都需要修改Bootloader的源程序。反过来,大部分Bootloader仍然具有很多共性,某些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,允许用户用电脑的串口+超级终 端实现烧录功能

F BOOTROM引导模式和程序

28335使用串口烧写程序 串口烧写是一种相对较方便的烧写方式,相对于仿真器或是CAN烧写,相对于仿真器或是USB转CAN的设备,串口是一种非常廉价的烧写方式,而且也不需要安装专业的集成开发环境CCS等,但是不能实现在线调试,因此也只适用于程序基本不用再调整或大批量的场合。 F28335的存储器映射图如下:

BOOTROM 是一块8K X 16的只读存储器,位于地址空间0x3FE000~0x3FFFFF,片内BOOTROM在出厂时固化了引导加载程序以及定点和浮点数据表,片上BOOTROM的存储映射如下图所示: 1.内BOOT ROM数学表: 在BOOT ROM中保留了4K X 16位空间,用以存放浮点和IQ数据公式表,这些数据 公式表有助于改善性能和节省SARAM空间。 向量表: CPU向量表位于ROM存储器0x3FE000~0x3FFFFF段内,如下图所示。复位后,当VMAP=1,ENPIE=0(PIE向量表禁止)时,该向量表激活。

在内部BOOT ROM引导区中能够调用的唯一向量就是位于0x3FFFC0的复位向量。复位向量在出厂时被烧录为直接指向存储在BOOT ROM空间中的InitBoot函数,该函数用于开启引导过程。然后通过通用I/O引脚上的检验判断,决定具体引导模式。引导模式与控制引脚之间的关系如下图所示: Bootloader特性: Bootloader是位于片上引导ROM中的在复位后执行的程序,用于在上电复位后,将程序代码从外部源转移到内部存储器。这允许代码暂时存储在掉电不丢失数据的外部存储器内,然后被转移到高速存储器中执行。 引导ROM中的复位向量将程序执行重定向至InitBoot函数。执行器件初始化之后,bootloader将检查GPIO引脚的状态以确定您需要执行哪种引导模式。这些选项包括:跳转至闪存、跳转至SARAM、跳转至OTP或调用其中一个片上引导加载例程。

单片机自编程及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操作。

STM32的BOOT概述

STM32的BOOT概述 STM32 三种启动模式对应的存储介质均是芯片内置的,它们是:1)用户 闪存= 芯片内置的Flash。2)SRAM = 芯片内置的RAM 区,就是内存啦。3)系统存储器= 芯片内部一块特定的区域,芯片出厂时在这个区域预置了一段Bootloader,就是通常说的ISP 程序。这个区域的内容在芯片出厂后没有人 能够修改或擦除,即它是一个ROM 区。 在每个STM32 的芯片上都有两个管脚BOOT0 和BOOT1,这两个管脚在芯 片复位时的电平状态决定了芯片复位后从哪个区域开始执行程序,见下表:BOOT1=x BOOT0=0 从用户闪存启动,这是正常的工作模式。 BOOT1=0 BOOT0=1 从系统存储器启动,这种模式启动的程序功能由厂家设置。BOOT1=1 BOOT0=1 从内置SRAM 启动,这种模式可以用于调试。 在系统上电的时候,cpu 首先根据这两个脚来确定是哪种模式的启动,然后 就是把相应模式的起始地址映射到0 地址处,并从0 地址处开始执行。在芯片 出厂时,st 烧写了一个bootloader 到rom 中,也就是system memory。这个bootloader 的主要任务就是通过uart1 下载程序到内置flash 中去。工作流程如下:system memory boot 模式,在执行完成它的任务之后是必须要退出的。这个退出方式是通过一次硬件reset 来实现的。在reset 的时候,必须要配置BOOT[1:0]这两个脚以使cpu 在重启之后进入适当的模式。 要注意的是,一般不使用内置SRAM 启动(BOOT1=1 BOOT0=1),因为SRAM 掉电后数据就丢失。多数情况下SRAM 只是在调试时使用,也可以做其他一些用途。如做故障的局部诊断,写一段小程序加载到SRAM 中诊断板上的 其他电路,或用此方法读写板上的Flash 或EEPROM 等。还可以通过这种方法解除内部Flash 的读写保护,当然解除读写保护的同时Flash 的内容也被自动清

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的方式

AN945 EFM8 Factory Bootloader用户指南中文版

AN945:EFM8 Factory Bootloader用户指南 本文档介绍了工厂编程的引导加载程序可用于EFM8设备。除了描述引导程序的功能,本文档还详细介绍了如何使用引导加载程序并更新Bootloader固件源代码或python主机软件,如果需要定制。 关键点 EFM8工厂编程的引导加载程序提供基本的生产编程或现场更新支持。?主机端都提供源代码python工具和bootloader 件来启用自定义。

1介绍 EFM8设备在工厂中使用引导加载程序进行编程。此引导程序启用: 1. 生产编程- 可以在生产环境中对设备进行编程,而无需使用调试接口需要PCB上的接入点和调试适配器。 2. 2.现场更新- 可以在现场的设备上发布更新,无需最终用户访问调试引脚或使用调试适配器硬件。 引导加载程序主要用于具有最小功能集的生产编程,但也可用于现场更新。因为几个EFM8变体可以有2 KB的闪存,引导程序的设计尽可能小。例如,UART和SMBus版本消耗单个512闪存页面,USB版本消耗1.5 KB闪存。另外,bootloader通常位于代码安全页面中,以使引导程序能够写入和擦除锁定的应用程序空间。更多信息在每个设备上的引导加载程序放置位置可以在设备数据手册或参考手册中找到。 22. USB或UART引导加载程序入门 这些步骤假定使用入门套件。使用自定义硬件时,步骤相同。 这些步骤还假设应用笔记zip文件已经下载到PC,或者使用Simplicity访问文件 工作室。应用程序zip文件可以在Silicon Labs网站(https://www.wendangku.net/doc/2815324936.html,/8bit-appnotes)上找到。 ?将Bootloader下载到设备 如果引导加载程序尚未在设备上,请使用Simplicity Studio将Bootloader下载到设备,并按以下步骤操作。 日期代码在设备勘误表中列出的日期之后的顶部标记的设备可以支持引导加载程序并可能具有 bootloader预装。在此之前的日期代码的设备将不能与引导程序一起使用。 ?打开Simplicity Studio。 ?将入门工具包连接到PC。 ?将套件开关移动到[AEM]位置。 ?单击Simplicity Studio左窗格中的[Refresh detected hardware]按钮。该套件应显示在[Detected Hardware] 区。 ?单击工具包,然后单击Simplicity Studio的[tool]区域中的[Flash Programmer]图块。 ?单击[Erase]按钮。 ?单击[Browse]按钮,导航到套件设备的预编译引导加载程序十六进制文件,单击[Open],然后单击[Program]。

单片机自编程及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为应用程序存储区域。

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程序。

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的设计

Implement UART Boot-loader On Coldfire V1 Products Paul Zhang, Freescale Shanghai. (paul.zhang@https://www.wendangku.net/doc/2815324936.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.wendangku.net/doc/2815324936.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.wendangku.net/doc/2815324936.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

ARM7的Bootloader和分散加载文件笔记

Boot Loader概述 简单地说,在操作系统内核运行之前,通过一小程序,可以初始化硬件设备、建立内存空间的映射图等,从而将系统的软硬件环境带到一个合适的状态,以便为最终调用操作系统内核配置好相应的环境,也可以下载文件到系统板上的SDRAM,对Flash进行擦除与编程,这个小程序一般称为Boot Loader。可以说,一个功能完善的Boot Loader已经相当于一个微型的操作系统了。 Boot Loader作为系统复位或上电后首先运行的代码,一般应写入Flash存储器并从起始物理地址0x0开始。Boot Loader是非常依赖于硬件而实现的,而且根据实现的功能不同,其复杂程度也各不相同。一个简单的Boot Loader可以只完成USB口的初始化,而功能完善的Boot Loader可以支持比较复杂的命令集,对系统的软硬件资源进行合理的配置与管理。因此,建立一个通用的Boot Loader 几乎是不可能的。 系统初始化代码直接对ARM微处理器内核及硬件控制器编程,多采用汇编语言编程,初始化代码一般应包括如下典型任务: 1.定义程序入口点; 2.设置异常和中断向量表; 3.初始化存储设备; 4.初始化堆栈指针寄存器; 5.初始化用户执行环境; 6.呼叫主应用程序。 1.1 定义程序入口 初始化代码必须定义整个程序的入口点。通过伪指令Entry指定编译器保留该段代码,同时配合链接器的设置,确定整个程序的入口点。 1.2 设置异常和中断向量表 1.3初始化存储设备 1. 存储器类型和时序的配置 2.存储器的地址分配与地址重映射 一种典型的存储器地址重映射过程描述如下:当系统上电或复位以后,PC指针指向0x0,程序从0x0地址开始执行,因此,为了能正确读取代码,要求此时Flash (或其它类型的ROM)的起始地址为0x0。但Flash(或其它类型的ROM)的访问速度大大低于RAM,每次产生异常后,都要从Flash(或其它类型的ROM)的异常向量表调转到相应的处理程序,会影响异常的响应速度,因此,系统便提供一种灵活的地址重映射方法,在系统完成必要地初始化以后,将RAM安排到0x0 地址处,而将原来位于0x0处的Flash(或其它类型的ROM)安排到其他的地方上去,加快异常的响应速度。

bootloader概述

对于嵌入式系统工作过一段时间的人来说,Bootloader应该是一个不算陌生的概念。 对于linux的系统来说,从软件角度通常分成4层: ●Bootloader ●Linux内核 ●文件系统 ●用户应用程序 1. Bootloader概念 Bootloader是处理从系统开机初始化硬件开始直到启动操作系统内核这段过程的一段程序,是系统中最早运行的程序,和硬件有很大的相关性。 从CPU的角度来说,上电后并非立刻就可以运行操作系统的,系统的相关硬件必须初始化(CPU工作模式的设置,内存初始化,关中断,关闭MMU/Cache等等等等),根据当前硬件条件判定当前是启动模式还是下载模式,然后走相应的功能分支。 所以一句话概括bootloader的工作——初始化系统的软硬件环境,使之满足操作系统的运行条件。当把一切软硬件环境都配置好之后,系统的

控制权才会交给OS的内核,这个时候Bootloader就功成身退了。 由于涉及到针对底层硬件的操作,所以很多代码会用汇编语言编写,也需要对系统硬件的工作有一个正确的完整的认识,这样对工程师的要求自然就高了。同时,Bootloader的可移植性就不会太好。 Bootloader有单阶段的也有多阶段的,目前比较多的是采用2个阶段,stage1和stage2。stage1一般都由汇编码编写,stage2一般由C语言编写. 大多数Bootloader都包含两种不同的操作模式: ●启动加载模式:这种模式也称自主模式,在这个模式下bootloader 从某个存储设备上加载操作系统到RAM,用户不需要介入这个过程 ●下载模式:这种模式下bootloader将通过串口/USB/网络等等手段从主机下载文件,写入存储设备。 现在的Android智能机就是一个很典型的例子,平时开机用户不需要介入,属于正常的启动加载模式,当用户刷机时显然就变成了下载模式。 2. 常见的Bootloader ●U-boot 这是现在使用最多的bootloader之一,是sourceforge上的一个开源项

bootloader启动流程

MSM8909+Android5.1.1启动流程概述 PBL:APPS PBL(ApplicationPrimary Boot Loader),主引导加载程序 RPM:ResourcePower Manager,资源电源管理器 RPM(ResourcePower Manager)是高通MSM平台另外加的一块芯片,虽然与AP芯片打包在一起,但其是一个独立的ARM Core。之所以加这个东西,就是要控制整个电源相关的shared resources,比如ldo,clock。负责与SMP,MPM交互进入睡眠或者唤醒整个系统。 L2 TCM:Tightly-CoupledMemory,紧耦合内存 Some ARM SoC:s have a so-called TCM(Tightly-Coupled Memory). This is usually just a few (4-64) KiB of RAM insidethe ARM processor. Due to being embedded inside the CPU TheTCM has a Harvard-architecture, so there is an ITCM (instruction TCM) and aDTCM (data TCM). The DTCM can not contain any instructions, but the ITCM canactually contain data. CDT: Configuration Data Table,包含CDB0: platform info信息和CDB1: DDR配置参数。TZ: PIL:Peripheralimage loader MBA:Modem Boot Authenticator,调制解调器引导认证 HLOS:High-leveloperation system,高级操作系统 Pronto image: SMEM : shared memory RPC : remote procedure call QCSBL : qualcomm second bootloader OEMSBL : oem second bootloader AMSS : Advanced Mobile Subscriber Software SDI : System Debug Image QSEE : Qualcomm Secure Execution Environment TZBSP : TrustZone BSP SBL1:ScondaryBoot Loader Stage1 MSS:MobileSubscriber Software移动用户软件 在ARM的集成开发环境中,只读的代码段和常量被称作RO段(ReadOnly);可读写的全局变量和静态变量被称作RW段(ReadWrite);RW段中要被初始化为零的变量被称为ZI段(ZeroInit)

Linux内核启动过程和Bootloader(总述)

Linux内核启动过程和Bootloader(总述) 1.Linux内核启动过程概述 一个嵌入式 Linux 系统从软件角度看可以分为四个部分:引导加载程序(Bootloader),Linux 内核,文件系统,应用程序。其中 Bootloader是系统启动或复位以后执行的第一段代码,它主要用来初始化处理器及外设,然后调用 Linux 内核。Linux 内核在完成系统的初始化之后需要挂载某个文件系统做为根文件系统(Root Filesystem)。根文件系统是Linux 系统的核心组成部分,它可以做为Linux 系统中文件和数据的存储区域,通常它还包括系统配置文件和运行应用软件所需要的库。应用程序可以说是嵌入式系统的“灵魂”,它所实现的功能通常就是设计该嵌入式系统所要达到的目标。如果没有应用程序的支持,任何硬件上设计精良的嵌入式系统都没有实用意义。 2. Bootloader启动过程 Bootloader在运行过程中虽然具有初始化系统和执行用户输入的命令等作用,但它最根本的功能就是为了启动 Linux 内核。 2.1 Bootloader的概念和作用 Bootloader是嵌入式系统的引导加载程序,它是系统上电后运行的第一段程序,其作用类似于 PC 机上的 BIOS。在完成对系统的初始化任务之后,它会将非易失性存储器(通常是Flash或DOC等)中的Linux 内核拷贝到 RAM 中去,然后跳转到内核的第一条指令处继续执行,从而启动 Linux 内核。由此可见,Bootloader 和 Linux 内核有着密不可分的联系,要想清楚的了解 Linux内核的启动过程,我们必须先得认识 Bootloader的执行过程,这样才能对嵌入式系统的整个启动过程有清晰的掌握 2.2 Bootloader的执行过程 不同的处理器上电或复位后执行的第一条指令地址并不相同,对于 ARM 处理器来说,该地址为 0x00000000。对于一般的嵌入式系统,通常把 Flash 等非易失性存储器映射到这个地址处,而 Bootloader就位于该存储器的最前端,所以系统上电或复位后执行的第一段程序便是Bootloader。而因为存储 Bootloader的存储器不同,Bootloader的执行过程也并不相同,下面将具体分 嵌入式系统中广泛采用的非易失性存储器通常是 Flash,而 Flash 又分为 Nor Flash 和Nand Flash 两种。它们之间的不同在于:Nor Flash 支持芯片内执行(XIP, eXecute In Place),这样代码可以在Flash上直接执行而不必拷贝到RAM中去执行。而Nand Flash 并不支持XIP,所以要想执行 Nand Flash 上的代码,必须先将其拷贝到 RAM中去,然后跳到 RAM 中去执行 2.3 Bootloader的功能 (1)初始化 RAM

相关文档