这部分介绍下ADS下如何生成可以运行的ROM镜像文件，我们知道当程序下载到flash中运行的时候，对于RW、ZI数据就存在着两个环境，一个load环境，一个是exec环境，有时候由于速度的需要RO数据也要重新加载，那么对RO数据也是有两个环境。编译器产生ROM镜像文件时候，这三块数据的存放依次为RO、RW、ZI，并且地址空间时连续的。但是到了运行的时候，RW数据必须被拷贝到SDRAM（SRAM）中以支持读写，这就是我们所谓的运行环境。那么就要有一段代码去完成这个任务，在本章中我们介绍如何生成这段代码。
玩过2410的朋友都知道2410初始化代码中有一段搬运RW和ZI初始化的代码，没错，它确实能够在一定程度上完成上面所说的任务，只要我们在生成二进制可执行代码的时候在编译器链接项的地方填写正确的RO＆RW地址，（比如RO = 0, RW = 0x30000000), 那么将程序下到 NOR flash的零地址并从nor flash启动，启动代码会将RW＆ZI数据弄到0x30000000，程序就能跑起来了。
但是各位有没有想过，怎么把RO代码弄到SDRAM中（有时候这是必须的，比方后面我将提到用nor flash的bootloader烧写nor flash）？如果直接设RO＝0x30000000，那么这段代码下载到0地址肯定跑不起来，除非是ROPI，这个要求就高了。这里我们有必要从介绍ADS中规定的C语言入口开始，ADS中从初始化汇编代码跳到main函数有两种方式，main和__main：
1，在__main入口的模式下，汇编代码的指令为 b __main, 编译器在跳转到main之前还要作一系列的工作，这其中就包括对运行环境的初始化，在<ADS COMPILE GUIDE>中提到： copies nonroot(RO&RW) execution regions from load addr to exec addr, and Zeros ZI region. 借助编译器，我们就可以定义更为复杂的运行环境，这里要用到scatter文件(.scf)，比如我们要的目标运行环境是：将启动代码以外的所有代码都 拷贝到SDRAM的初始地址中运行，比且把RW段设在0x30800000，那么对应的scf文件如下：
FLASH 0x0 0x200000
{
EXEC1 0x0 0x200000
{
2410init.o(Init, +First)
__main.o(+RO) ; copy code
* (Region$$Table) ; RO/RW addresses to copy
* (ZISection$$Table) ; ZI addresses to zero
}
EXEC2 0x30000000 0x00800000
{
*(+RO)
}
SDRAM 0x30800000 0x00800000
{
*(+RW,+ZI)
}
}
;Sections named Region$$Table and ZISection$$Table which contain the addresses of the code/data to be copied.
当然，在这种模式下，有些入口函数必须自己重定义，比如__user_initial_stackheap,具体参见ADS文档。
2, main入口模式即简单的跳转，这里起始不用“main”这个名字也无所谓。那么编译器不会作任何的初始化，所有运行环境的建立都要靠 我们自己，这就是大家看到的那段搬运代码存在的理由。但是它实现一些简单的运行环境是可取的，如果用scf定义的复杂环境，虽然我 相信是可以做到的，但是可能会比较麻烦。我还没深究。
另外，这里提一下semihost，因为我们在看ADS的东西的时候经常出现这个词，我也一直受其困扰。这里我简单说一下自己的见解，semihost 仅仅是一种调试手段，它的机理就是利用MULTI_IDE等工具捕捉目标环境运行过程中产生的值为0x123456的SWI中断，然后向上位机的ADS 软件发送对应的调试信息。对于我们最后的应用代码来说，都是nonsemihost类型的。如果我们在调试中使用semihost，那么只要在最后重定义 ADS中的一些使用到的库函数（比如fputc），代码就可以从semihost向nonsemihost的类型转变。不过到目前为止，我还没体会到semihost的威力。
2410启动代码分析
这一章主要对目前广泛流行的2410启动代码进行分析：S3C2410的初始化代码主要涉及到对系统主要模块的配置、运行环境的建立、系统时钟、MMU等模块的配置，下面按执行顺序依次都各个部分进行分析：
程序入口：（ResetHandler）
在程序一开始，首先进行的一些操作主要保证初始化程序能够顺利的运行， 因此主要包括关闭WDT、中断，配置锁相环等。
配置memory接口
memory接口是确保数据访问正确的基本保障，此处主要配置SFR寄存器中0x48000000开始的memory接口寄存器组， 确保每个bank的位宽、访问类型（waitable）以及时序参数正确。如果没有特别的要求，一般来说时序参数使用默认值即可。
初始化堆栈
ARM有6种运行模式，必须为每一种模式提供独立的堆栈空间，在堆栈设置之前是不能进行C函数的调用的。ARM的堆栈模式 是从高地址递减的，我的所有代码统一将堆栈的首地址设在0x33ff8000处，往低依次为FIQ、IRQ、Abort、Undef、SVC，其中
SVC和User模式不予区分。堆栈大小一般可在头文件或者当前文件中修改。
运行空间的初始化
这段代码主要完成两个功能，一是将RW数据搬运到RW空间（我们生成ROM镜像时，RW数据是跟在RO数据之后的），二是 初始化ZI数据段。当然，这段代码存在的前提是代码的运行环境只是标准的两段式：一段RO空间和一段RW空间；并且在C程序
入口时没有调用编译器的链接库（__main）。后者已经提供相应的功能，并且支持更加复杂的运行环境定义（使用SCF文件），
（关于这一点，我在介绍ADS中C代码的启动模式时已经详细介绍）。
__rt_lib_init
在ADS1.2的环境中，如果在C入口没有调用编译器的链接库（__main），那么在C程序一开始要调用该函数以初始化运行时的函数库，以保证对ADS提供的某些库函数能够正常调用。从这个函数开始，我们已经在C语言环境下了。
MMU初始化
2410的MMU支持1级＆2级地址映射，在我们目前大部分应用中均采用1级section模式的地址映射，一个section的大小为1M，也就是说从逻辑地址到物理地址的转变是这样的一个过程：
一个32位的地址，高12位决定了该地址在页表中的index，这个index的内容决定了该逻辑section对应的物理section； 低20位决定了该地址在section中的偏移（index）。
因此从0x0～0xffffffff的地址空间总共可以分成0x1000（4K）个section，页表中每项的大小为32个bit，因此页表的大小为0x4000（16K）。在我的代码中所有程序的页表统一存放在地址0x33ff8000。
每个页表项的内容如下:
bit: 31 20 19 12 11 10 9 8 5 4 3 2 1 0
content: Section对应的物理地址 NULL AP 0 Domain 1 C B 1 0
最低两位（10）是section分页的标识。
AP：Access Permission，区分只读、读写、SVC＆其它模式。
Domain：每个section都属于某个Domain，一个有16个Domain，每个Domain的属性由CP15的R3寄存器控制。 在我得所有程序中，都只包含两个Domain，一个是SFR地址以下（包括SFR）的空间，可访问； 另一个是SFR以上的空间，不可访问。
C、B：这两位决定了该section的cache＆write buffer属性，这与该段的用途(RO or RW)有密切关系。不同的用途要做不同的设置。
C B 具体含义
0 0 无cache，无写缓冲，任何对memory的读写都反映到ASB总线上。
对 memory 的操作过程中CPU需要等待。
0 1 无cache，有写缓冲，读操作直接反映到ASB总线上。写操作CPU将数据写
入 到写缓冲后继续运行，由写缓冲进行ASB操作。
1 0 有cache，写通模式，读操作首先考虑cache hit；写操作时直接将数据写入
写缓冲，如果同时出现cache hit，那么也更新cache。
1 1 有cache，写回模式，读操作首先考虑cache hit；写操作也首先考虑cache，
如果hit，则只修改cache，并将cache对应半行的dirty比特置位；如果miss，
则写入写缓冲，触发ASB总线操作。
在我的程序中内存空间的分配统一采用了文末的MEMORY图。虽然MMU只是使用了逻辑地址到物理地址的linear transfer（值不改变），但是由于MMU能够引入cache＆write buffer，因此系统性能有很大的提高！
配置时钟比、重新设置PLL
2410内部有三个时钟：FCLK、HCLK、PCLK，分别供CPU、AHB总线和APB总线使用，为了降低功耗，一般都选择周期比为1：2：4的合理配置。 同时将PLL配置为运行环境时钟，一般都达到最高202M。
IO初始化
将IO口配置为对应的功能选项，同时一般会点亮相应的LED灯。
中断初始化
2410的内存空间没有remap的机制，应该中断入口时钟位于零地址。因此中断服务机制可以描述如下：
首先，不管使用那种启动方式，必须确保一下代码段位于内存的0x0地址：
b ResetHandler
b HandlerUndef ;handler for Undefined mode
b HandlerSWI ;handler for SWI interrupt
b HandlerPabort ;handler for PAbort
b HandlerDabort ;handler for DAbort
b . ;reserved
b HandlerIRQ ;handler for IRQ interrupt
b HandlerFIQ ;handler for FIQ interrupt
除ResetHandler外，其余各项都是由如下的宏定义的一段代码：
HandlerFIQ HANDLER HandleFIQ
MACRO
$HandlerLabel HANDLER $HandleLabel
$HandlerLabel
sub sp,sp,#4 ;decrement sp(to store jump address)
stmfd sp!,{r0} ;PUSH the work register to stack
ldr r0,=$HandleLabel ;load the address of HandleXXX to r0
ldr r0,[r0] ;load the contents
str r0,[sp,#4] ;store the contents(ISR) of HandleXXX to stack
ldmfd sp!,{r0,pc} ;POP the work register and pc(jump to ISR)
MEND
这段代码的含义是通过堆栈将中断向量表中的内容赋给PC指针（如HandleFIQ是存放着FIQ服务程序入口地址的地址），自然程序就跳到相应的入口地址。
可见，中断向量表存放的是各个中断服务程序的入口地址，它是用来被加载的，而并不是可执行代码。为了统一，所有示例程序都将中断向量表放在0x33ffff00开始的地址，并根据入口地址依次排列。
需要注意的是如果各种模式的服务程序用C语言定义，那么类型必须用__irq定义，以保证能够正确返回。
初始化串口
串口统一选用UART0，模式采用115200、1bit STOP、No Parity。
最后跳转到我们自己的应用程序！
附：我得程序所使用的地址空间结构以及MMU中C、B的设置：
Blank Area: RW_FAULT 0x5b000000 ～ 0xffffffff
Sram & SFR: NCNB 0x40000000 ～ 0x4affffff
Blank Area: RW_FAULT 0x34000000 ～ 0x3fffffff
Int_Vec, Stack, MTT: CNB 0x33f00000 ～ 0x33ffffff
SDRAM Download: NCNB 0x31000000 ～ 0x33efffff
SDRAM Exec RW: CB 0x30800000 ～ 0x30ffffff
SDRAM Exec R CNB 0x30000000 ～ 0x307fffff
Bank5, FPGA: NCNB 0x28000000 ～ 0x2fffffff
Bank4, FPGA: NCNB 0x20000000 ～ 0x27ffffff
Bank3, Bottom NIC: NCNB 0x18000000 ～ 0x1fffffff
Bank2, Bottom Flash: CNB 0x10000000 ～ 0x17ffffff
Bank1, Bottom Sram: CNB 0x08000000 ～ 0x0fffffff
Bank0, Flash or Sram: CNB 0x00000000 ～ 0x07ffffff
Nor Flash Bootloader
这是我着手写的第一个程序，我的想*是让这个程序同时支持通过串口对Nand 和 Nor FLASH的烧写，如果不进行任何烧写，那么就跳到Nor Flash的第二个section启动应用程序，这样一来，即使脱离JTGA，我也可以使用串口进行盲调。
由于有现成的初始化文件和flash烧写的示例程序，开发起来还比较快。当然也遇到了一些问题，一开始连flash的device ID都读不出来，后来发现我指针没有定义成volatile类型，flash的操作时序被编译器优化了；再者，在对Nor Flash进行操作时，bank0在MMU中的类型一定要设为NCNB，这样比较保险。
遇到最大的问题就是下面的了，一开始我用jtag把程序下载到0x30000000的地方运行，对Nor Flash的烧写完全正常，但是当把程序下载到Nor Flash中启动运行后，再对Nor Flash的section 2进行烧写时，就出现了问题。所幸没多久我就意识到了问题，将程序放在Nor Flash中运行，同时有对同一片flash进行操作，那么操作时序势必会被CPU的指令读取时序所破坏，因此程序必须搬运到SDRAM中运行。
但是启动地址有必须是零地址，所以我采用了前文提到的scatter文件的方*，将非必要的代码全部搬到sdram中运行，scf文件格式就是前文中的那个。当然采用了__main的入口，调用了ADS的链接库，让它帮忙建立程序的运行环境。
至此，Nor Flash Bootloader可以顺畅无忧的实现其功能了。
Nand Flash Bootloader
因为Nor flash bootloader已经实现了对Nand Flash的烧写，因此在Nand Flash Bootloader中实现flash烧写并不是我的目的，况且，S3C2410运行在NAND BOOT模式下的时候，4K的SRAM位于0地址，上电时刻Nand Flash中block 0的前8个page的数据自动加载到SRAM后开始运行，Nor flash这个时候是不可见的。 因此，我做Nand Flash Bootloader的目的简单而又直接，就是把block1开始的若干个block数据加载到sdram首地址，然后PC跳到那里运行应用程序就可以了。比方说我把编译好的ucos－ii代码放在block1，那么ucos－ii就可以跑起来了。
因此制作Nand Flash一个最重要的问题就是真个程序必须小于4K。应用程序应该是一个完整的应用代码，只是在编译时RO的起始地址应该定位成0x30000000，如果直接用JTAG将其下载到对应地址，程序照样能够跑起来（当然零地址要有中断向量入口程序）。这里我偷懒了一下，将应用程序的中断向量表地址和Nand Flash Bootloader设得完全相同，那样应用程序就可以借用bootloader的中断跳转程序以实现中断的正确跳转，当然应用程序也有自己相应的跳转代码，但是这段代码位于SDRAM起始地址，是不会被执行的；至于堆栈，应用程序在自己得初始化代码中可以重新设置堆栈。
在Nand Flash的硬件方面，我开发板使用的是K9F5608（32M），相对于K9S208（64M），后者的地址需要写四次才能全部送出，而前者只要三次就够了，2410的引脚中专门有nCON控制地址送出的次数。因此当硬件在这两者之间变化时，既要注意外部电路图的接*，又要注意软件代码的正确性。
RTL8019调试心得
一开始接触8019真的是让我头晕，首先我没有一点网络基础，另外，8019的datasheet称不上最烂也算是极品了。当初作PCB的时候选用8019主要是因为价格便宜以及lbbbb做过，能够提供源代码＆技术支持。最后能搞定，我觉得还是很有成就感的。
8109AS的运行模式包括跳线模式、非跳线模式和PnP模式，PnP模式是在电脑上使用的即插即用模式，因此这里我们可以不予考虑。8109AS的IO寄存器符合NE2000标准，分为4个page，其中page3是8109AS自己定义的寄存器。所谓跳线模式，是指8019AS I/O寄存器page3中的大部分配置寄存器（CONFIGn）的值是在上电复位时刻确定的，来源是在RESET上升沿时捕捉到的一些外部引脚的电平值。在非跳线模式下，这些寄存器值的配置由外部EEPROM 93C46完成。配置寄存器在运行过程中大部分值时不能改变的。
目前驱动程序目前只实现了最基本的收发功能。片内16K的SRAM划分如下：40～46：发送缓冲区1；46～4c：发送缓冲区2；4c～80：接收缓冲区。
另外我在调试中发现片内的SRAM是不可按地址读的，虽然我在原理图上也象CS8900A那样连了mem_wr＆mem_rd，但是似乎不能访问，希望哪位高人能够给我一个明确的回答。
起初作硬件了时候我加了93C46，想使用非跳线模式，JP脚就悬空在那里。后来93C46买不到，就一直空着，虽然8019的初始化没有出问题，但是对这种不洋不土的模式，我还是心有余悸，因此将JP脚接到了5V电源，板上唯一的飞线就是这么来礟OSThttps://bbs.edw.com.cn/S**ePost.asp?A 现在还有一个郁闷的问题就是linux 2.4.18是不支持8019的。天下的2410开发板都采用8900a也就是这个道理。所以，我还要完成驱动！！！
S3c2410 DMA介绍
之所以要介绍DMA，因为它对性能太重要了！只有活用了DMA，CPU的性能才能上去！S3c2410有四个DMA，每个DMA支持工作方式基本相同，但支持的source Dest可能略有不同，具体见Datasheet。
这里具体DMA CONTROL寄存器（DCON）的配置说明，进而引出DMA的各种工作方式。
Atomic transfer：指的是DMA的单次原子操作，它可以是Unit模式（传输1个data size），也可以是burst模式（传输4个data size），具体对应DCON[28]。
Data Size：指的是单次原子操作的数据位宽，8、16、32，具体对应DCON[21:20]。
Request Source：DMA请求的来源有两种，软件＆硬件模块，由DCON[23]控制；当为前者时，由软件对DMASKTRIG寄存器的位0置位触发一次DMA 操作。当为后者时，具体来源由DCON[26:24]控制，不同硬件模块的某时间触发一次DMA操作，具体要见不同的硬件模块。
DMA service mode：DMA的工作模式有两种，单一服务模式＆整体服务模式。前一模式下，一次DMA请求完成一项原子操作，并且transfer count的值减1。后一模式下，一次DMA请求完成一批原子操作，直到transfer count等于0表示完成一次整体服务。具体对应DCON[27]。
RELOAD：在reload模式下，当transfer count的值变为零时，将自动加src、dst、TC的值加载到CURR_DST、CURR_SRC、CURR_TC，并开始一次新的DMA传输。该模式一般和整体服务模式一起使用，也就是说当一次整体服务开始后，src、dst、TC的值都已经被加载，因此可以更改为下一次
服务的地址，2410说明文档中建议加入以下语句来判断当前的服务开始，src、dst、TC的值可以被更改了：while((rDSTATn & 0xfffff) == 0) ;
Req&Ack：DMA请求和应答的协议有两种，Demard mode 和 Handshake mode。两者对Request和Ack的时序定义有所不同：在Demard模式下，如果
DMA完成一次请求如果Request仍然有效，那么DMA就认为这是下一次DMA请求；在Handshake模式下，DMA完成一次请求后等待Request信号无效，然后把ACK也置无效，再等待下一次Request。这个设计外部DMA请求时可能要用到。
传输总长度：DMA一次整体服务传输的总长度为：
Data Size × Atomic transfer size × TC（字节）。
1.在板子上电的一开始,首先自动判断是否是autoboot模式(这是由硬件设计阶段,由硬件工程师对mcu的引脚连线决定的),我所使用的s3c2410是带有nandflash的,并切被设置成autoboot,从nandflash开始启动.
2.在判断是autoboot模式后,mcu内置的nandflash控制器自动将nandflash的最前面的4k区域(这4k区域存放着 bootloader的最前面4k代码)拷贝到samsung所谓的"steppingstone"里面(实际上是一块4k大小的SRAM).这一过程完全由硬件自动实现，不需软件控制.
3.在拷贝完前4k代码后,nandflash控制器自动将"steppingstone"映射到arm地址空间0x00000000开始的前4k区域.
4.在映射过程完成后.nandflash控制器将pc指针直接指向arm地址空间的0x00000000位置,准备开始执行"steppingstone"上的代码.
5.而"steppingstone"上从nandflash拷贝过来的4k代码,是程序员写的bootloader的前4k代码.这个 bootloader在之前写好,并已经被烧写到nandflash的0x00000000开始的最前面区域..而这"steppingstone"上的 4k代码就是bootloader的前4k代码.
6.在pc指向arm地址空间的0x00000000后,系统就开始执行指令代码.这4k代码的任务是:初始化硬件,设置中断向量表,设置堆栈,然后一个很重要的任务是,将nandflash的最前面区域的bootloader(包含4k启动代码)拷贝到SDRAM中去,bootloader代码的大小是写好bootloader就确定的.然后只需要确定bootloader想映射到SDRAM的起始位置就ok.
7.在完成对nandflash上的bootloader搬移后,找到4k代码的搬移代码最后一个指令的下一个指令在SDRAM的bootloader的地址,然后跳转到该位置,继续执行bootloader的剩余代码(引导系统).
现在有这么几个问题：
在启动启动完成后，steppingstone会被映射到其他地方，可以作为一般存储使用；
为加快终端响应，需要将sdram开始的代码重新映射到0x00000000开始的一段区域，这样两个虚拟地址空间映射到一个物理内存区域；
nandflash控制器的工作原理是什么？需要查一下
本文来自CSDN博客，转载请标明出处：https://blog.csdn.net/martree/archive/2008/11/17/3321639.aspx
本文详细地介绍了基于嵌入式系统中的 OS 启动加载程序 ―― Boot Loader 的概念、软件设计的主要任务以及结构框架等内容。
在专用的嵌入式板子运行 GNU/Linux 系统已经变得越来越流行。一个嵌入式 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 程序。
本文将从 Boot Loader 的概念、Boot Loader 的主要任务、Boot Loader 的框架结构以及 Boot Loader 的安装等四个方面来讨论嵌入式系统的 Boot Loader。
简单地说，Boot Loader 就是在操作系统内核运行之前运行的一段小程序。通过这段小程序，我们可以初始化硬件设备、建立内存空间的映射图，从而将系统的软硬件环境带到一个合适的状态，以便为最终调用操作系统内核准备好正确的环境。
通常，Boot Loader 是严重地依赖于硬件而实现的，特别是在嵌入式世界。因此，在嵌入式世界里建立一个通用的 Boot Loader 几乎是不可能的。尽管如此，我们仍然可以对 Boot Loader 归纳出一些通用的概念来，以指导用户特定的 Boot Loader 设计与实现。
每种不同的 CPU 体系结构都有不同的 Boot Loader。有些 Boot Loader 也支持多种体系结构的 CPU，比如 U-Boot 就同时支持 ARM 体系结构和MIPS 体系结构。除了依赖于 CPU 的体系结构外，Boot Loader 实际上也依赖于具体的嵌入式板级设备的配置。这也就是说，对于两块不同的嵌入式板而言，即使它们是基于同一种 CPU 而构建的，要想让运行在一块板子上的 Boot Loader 程序也能运行在另一块板子上，通常也都需要修改 Boot Loader 的源程序。
系统加电或复位后，所有的 CPU 通常都从某个由 CPU 制造商预先安排的地址上取指令。比如，基于 ARM7TDMI core 的 CPU 在复位时通常都从地址 0x00000000 取它的第一条指令。而基于 CPU 构建的嵌入式系统通常都有某种类型的固态存储设备(比如：ROM、EEPROM 或 FLASH 等)被映射到这个预先安排的地址上。因此在系统加电后，CPU 将首先执行 Boot Loader 程序。
下图1就是一个同时装有 Boot Loader、内核的启动参数、内核映像和根文件系统映像的固态存储设备的典型空间分配结构图。
主机和目标机之间一般通过串口建立连接，Boot Loader 软件在执行时通常会通过串口来进行 I/O，比如：输出打印信息到串口，从串口读取用户控制字符等。
通常多阶段的 Boot Loader 能提供更为复杂的功能，以及更好的可移植性。从固态存储设备上启动的 Boot Loader 大多都是 2 阶段的启动过程，也即启动过程可以分为 stage 1 和 stage 2 两部分。而至于在 stage 1 和 stage 2 具体完成哪些任务将在下面讨论。
大多数 Boot Loader 都包含两种不同的操作模式："启动加载"模式和"下载"模式，这种区别仅对于开发人员才有意义。但从最终用户的角度看，Boot Loader 的作用就是用来加载操作系统，而并不存在所谓的启动加载模式与下载工作模式的区别。
启动加载（Boot loading）模式：这种模式也称为"自主"（Autonomous）模式。也即 Boot Loader 从目标机上的某个固态存储设备上将操作系统加载到 RAM 中运行，整个过程并没有用户的介入。这种模式是 Boot Loader 的正常工作模式，因此在嵌入式产品发布的时侯，Boot Loader 显然必须工作在这种模式下。
下载（Downloading）模式：在这种模式下，目标机上的 Boot Loader 将通过串口连接或网络连接等通信手段从主机（Host）下载文件，比如：下载内核映像和根文件系统映像等。从主机下载的文件通常首先被 Boot Loader 保存到目标机的 RAM 中，然后再被 Boot Loader 写到目标机上的FLASH 类固态存储设备中。Boot Loader 的这种模式通常在第一次安装内核与根文件系统时被使用；此外，以后的系统更新也会使用 Boot Loader 的这种工作模式。工作于这种模式下的 Boot Loader 通常都会向它的终端用户提供一个简单的命令行接口。
像 Blob 或 U-Boot 等这样功能强大的 Boot Loader 通常同时支持这两种工作模式，而且允许用户在这两种工作模式之间进行切换。比如，Blob 在启动时处于正常的启动加载模式，但是它会延时 10 秒等待终端用户按下任意键而将 blob 切换到下载模式。如果在 10 秒内没有用户按键，则 blob 继续启动 Linux 内核。
最常见的情况就是，目标机上的 Boot Loader 通过串口与主机之间进行文件传输，传输协议通常是 xmodem／ymodem／zmodem 协议中的一种。但是，串口传输的速度是有限的，因此通过以太网连接并借助 TFTP 协议来下载文件是个更好的选择。
此外，在论及这个话题时，主机方所用的软件也要考虑。比如，在通过以太网连接和 TFTP 协议来下载文件时，主机方必须有一个软件用来的提供 TFTP 服务。
在讨论了 BootLoader 的上述概念后，下面我们来具体看看 BootLoader 的应该完成哪些任务。
在继续本节的讨论之前，首先我们做一个假定，那就是：假定内核映像与根文件系统映像都被加载到 RAM 中运行。之所以提出这样一个假设前提是因为，在嵌入式系统中内核映像与根文件系统映像也可以直接在 ROM 或 Flash 这样的固态存储设备中直接运行。但这种做法无疑是以运行速度的牺牲为代价的。
从操作系统的角度看，Boot Loader 的总目标就是正确地调用内核来执行。
另外，由于 Boot Loader 的实现依赖于 CPU 的体系结构，因此大多数 Boot Loader 都分为 stage1 和 stage2 两大部分。依赖于 CPU 体系结构的代码，比如设备初始化代码等，通常都放在 stage1 中，而且通常都用汇编语言来实现，以达到短小精悍的目的。而 stage2 则通常用C语言来实现，这样可以实现给复杂的功能，而且代码会具有更好的可读性和可移植性。
Boot Loader 的 stage1 通常包括以下步骤(以执行的先后顺序)：
硬件设备初始化。
为加载 Boot Loader 的 stage2 准备 RAM 空间。
拷贝 Boot Loader 的 stage2 到 RAM 空间中。
设置好堆栈。
跳转到 stage2 的 C 入口点。
Boot Loader 的 stage2 通常包括以下步骤(以执行的先后顺序)：
初始化本阶段要使用到的硬件设备。
检测系统内存映射(memory map)。
将 kernel 映像和根文件系统映像从 flash 上读到 RAM 空间中。
为内核设置启动参数。
调用内核。
3.1.1 基本的硬件初始化
这是 Boot Loader 一开始就执行的操作，其目的是为 stage2 的执行以及随后的 kernel 的执行准备好一些基本的硬件环境。它通常包括以下步骤（以执行的先后顺序）：
1． 屏蔽所有的中断。为中断提供服务通常是 OS 设备驱动程序的责任，因此在 Boot Loader 的执行全过程中可以不必响应任何中断。中断屏蔽可以通过写 CPU 的中断屏蔽寄存器或状态寄存器（比如 ARM 的 CPSR 寄存器）来完成。
2． 设置 CPU 的速度和时钟频率。
3． RAM 初始化。包括正确地设置系统的内存控制器的功能寄存器以及各内存库控制寄存器等。
4． 初始化 LED。典型地，通过 GPIO 来驱动 LED，其目的是表明系统的状态是 OK 还是 Error。如果板子上没有 LED，那么也可以通过初始化 UART 向串口打印 Boot Loader 的 Logo 字符信息来完成这一点。
5． 关闭 CPU 内部指令／数据 cache。
3.1.2 为加载 stage2 准备 RAM 空间
为了获得更快的执行速度，通常把 stage2 加载到 RAM 空间中来执行，因此必须为加载 Boot Loader 的 stage2 准备好一段可用的 RAM 空间范围。
由于 stage2 通常是 C 语言执行代码，因此在考虑空间大小时，除了 stage2 可执行映象的大小外，还必须把堆栈空间也考虑进来。此外，空间大小最好是 memory page 大小(通常是 4KB)的倍数。一般而言，1M 的 RAM 空间已经足够了。具体的地址范围可以任意安排，比如 blob 就将它的 stage2 可执行映像安排到从系统 RAM 起始地址 0xc0200000 开始的 1M 空间内执行。但是，将 stage2 安排到整个 RAM 空间的最顶 1MB(也即(RamEnd-1MB) - RamEnd)是一种值得推荐的方法。
为了后面的叙述方便，这里把所安排的 RAM 空间范围的大小记为：stage2_size(字节)，把起始地址和终止地址分别记为：stage2_start 和 stage2_end(这两个地址均以 4 字节边界对齐)。因此：
stage2_end＝stage2_start＋stage2_size
另外，还必须确保所安排的地址范围的的确确是可读写的 RAM 空间，因此，必须对你所安排的地址范围进行测试。具体的测试方法可以采用类似于 blob 的方法，也即：以 memory page 为被测试单位，测试每个 memory page 开始的两个字是否是可读写的。为了后面叙述的方便，我们记这个检测算法为：test_mempage，其具体步骤如下：
1． 先保存 memory page 一开始两个字的内容。
2． 向这两个字中写入任意的数字。比如：向第一个字写入 0x55，第 2 个字写入 0xaa。
3． 然后，立即将这两个字的内容读回。显然，我们读到的内容应该分别是 0x55 和 0xaa。如果不是，则说明这个 memory page 所占据的地址范围不是一段有效的 RAM 空间。
4． 再向这两个字中写入任意的数字。比如：向第一个字写入 0xaa，第 2 个字中写入 0x55。
5． 然后，立即将这两个字的内容立即读回。显然，我们读到的内容应该分别是 0xaa 和 0x55。如果不是，则说明这个 memory page 所占据的地址范围不是一段有效的 RAM 空间。
6． 恢复这两个字的原始内容。测试完毕。
为了得到一段干净的 RAM 空间范围，我们也可以将所安排的 RAM 空间范围进行清零操作。
3.1.3 拷贝 stage2 到 RAM 中
拷贝时要确定两点：(1) stage2 的可执行映象在固态存储设备的存放起始地址和终止地址；(2) RAM 空间的起始地址。
3.1.4 设置堆栈指针sp
堆栈指针的设置是为了执行 C 语言代码作好准备。通常我们可以把 sp 的值设置为(stage2_end-4)，也即在 3.1.2 节所安排的那个 1MB 的 RAM 空间的最顶端(堆栈向下生长)。
此外，在设置堆栈指针 sp 之前，也可以关闭 led灯，以提示用户我们准备跳转到 stage2。
经过上述这些执行步骤后，系统的物理内存布局应该如下图2所示。
3.1.5 跳转到 stage2 的 C 入口点
在上述一切都就绪后，就可以跳转到 Boot Loader 的 stage2 去执行了。比如，在 ARM 系统中，这可以通过修改 PC 寄存器为合适的地址来实现。
正如前面所说，stage2 的代码通常用 C 语言来实现，以便于实现更复杂的功能和取得更好的代码可读性和可移植性。但是与普通 C 语言应用程序不同的是，在编译和链接 boot loader 这样的程序时，我们不能使用 glibc 库中的任何支持函数。其原因是显而易见的。这就给我们带来一个问题，那就是从那里跳转进 main() 函数呢？直接把 main() 函数的起始地址作为整个 stage2 执行映像的入口点或许是最直接的想法。但是这样做有两个缺点：1)无法通过main() 函数传递函数参数；2)无法处理 main() 函数返回的情况。一种更为巧妙的方法是利用 trampoline(弹簧床)的概念。也即，用汇编语言写一段trampoline 小程序，并将这段 trampoline 小程序来作为 stage2 可执行映象的执行入口点。然后我们可以在 trampoline 汇编小程序中用 CPU 跳转指令跳入 main() 函数中去执行；而当 main() 函数返回时，CPU 执行路径显然再次回到我们的 trampoline 程序。简而言之，这种方法的思想就是：用这段 trampoline 小程序来作为 main() 函数的外部包裹(external wrapper)。
下面给出一个简单的 trampoline 程序示例(来自blob)：
.text.globl _trampoline_trampoline: bl main /* if main ever returns we just call it again */ b _trampoline
可以看出，当 main() 函数返回后，我们又用一条跳转指令重新执行 trampoline 程序――当然也就重新执行 main() 函数，这也就是 trampoline(弹簧床)一词的意思所在。
3.2.1初始化本阶段要使用到的硬件设备
这通常包括：（1）初始化至少一个串口，以便和终端用户进行 I/O 输出信息；（2）初始化计时器等。
在初始化这些设备之前，也可以重新把 LED 灯点亮，以表明我们已经进入 main() 函数执行。
设备初始化完成后，可以输出一些打印信息，程序名字字符串、版本号等。
3.2.2 检测系统的内存映射（memory map）
所谓内存映射就是指在整个 4GB 物理地址空间中有哪些地址范围被分配用来寻址系统的 RAM 单元。比如，在 SA-1100 CPU 中，从 0xC000,0000 开始的 512M 地址空间被用作系统的 RAM 地址空间，而在 Samsung S3C44B0X CPU 中，从 0x0c00,0000 到 0x1000,0000 之间的 64M 地址空间被用作系统的 RAM 地址空间。虽然 CPU 通常预留出一大段足够的地址空间给系统 RAM，但是在搭建具体的嵌入式系统时却不一定会实现 CPU 预留的全部 RAM 地址空间。也就是说，具体的嵌入式系统往往只把 CPU 预留的全部 RAM 地址空间中的一部分映射到 RAM 单元上，而让剩下的那部分预留 RAM 地址空间处于未使用状态。 由于上述这个事实，因此 Boot Loader 的 stage2 必须在它想干点什么 (比如，将存储在 flash 上的内核映像读到 RAM 空间中) 之前检测整个系统的内存映射情况，也即它必须知道 CPU 预留的全部 RAM 地址空间中的哪些被真正映射到 RAM 地址单元，哪些是处于 "unused" 状态的。
(1) 内存映射的描述
可以用如下数据结构来描述 RAM 地址空间中的一段连续(continuous)的地址范围：
typedef struct memory_area_struct { u32 start; /* the base address of the memory region */ u32 size; /* the byte number of the memory region */ int used;} memory_area_t;
这段 RAM 地址空间中的连续地址范围可以处于两种状态之一：(1)used=1，则说明这段连续的地址范围已被实现，也即真正地被映射到 RAM 单元上。(2)used=0，则说明这段连续的地址范围并未被系统所实现，而是处于未使用状态。
基于上述 memory_area_t 数据结构，整个 CPU 预留的 RAM 地址空间可以用一个 memory_area_t 类型的数组来表示，如下所示：
memory_area_t memory_map[NUM_MEM_AREAS] = { [0 ... (NUM_MEM_AREAS - 1)] = { .start = 0, .size = 0, .used = 0 },};
(2) 内存映射的检测
下面我们给出一个可用来检测整个 RAM 地址空间内存映射情况的简单而有效的算法：
/* 数组初始化 */for(i = 0; i < NUM_MEM_AREAS; i++) memory_map[i].used = 0;/* first write a 0 to all memory locations */for(addr = MEM_START; addr < MEM_END; addr += PAGE_SIZE) * (u32 *)addr = 0;for(i = 0, addr = MEM_START; addr < MEM_END; addr += PAGE_SIZE) { /* * 检测从基地址 MEM_START+i*PAGE_SIZE 开始,大小为* PAGE_SIZE 的地址空间是否是有效的RAM地址空间。 */ 调用3.1.2节中的算法test_mempage()； if ( current memory page isnot a valid ram page) { /* no RAM here */ if(memory_map[i].used ) i++; continue; } /* * 当前页已经是一个被映射到 RAM 的有效地址范围 * 但是还要看看当前页是否只是 4GB 地址空间中某个地址页的别名？ */ if(* (u32 *)addr != 0) { /* alias? */ /* 这个内存页是 4GB 地址空间中某个地址页的别名 */ if ( memory_map[i].used ) i++; continue; } /* * 当前页已经是一个被映射到 RAM 的有效地址范围 * 而且它也不是 4GB 地址空间中某个地址页的别名。 */ if (memory_map[i].used == 0) { memory_map[i].start = addr; memory_map[i].size = PAGE_SIZE; memory_map[i].used = 1; } else { memory_map[i].size += PAGE_SIZE; }} /* end of for (…) */
在用上述算法检测完系统的内存映射情况后，Boot Loader 也可以将内存映射的详细信息打印到串口。
3.2.3 加载内核映像和根文件系统映像
(1) 规划内存占用的布局
这里包括两个方面：(1)内核映像所占用的内存范围；（2）根文件系统所占用的内存范围。在规划内存占用的布局时，主要考虑基地址和映像的大小两个方面。
对于内核映像，一般将其拷贝到从(MEM_START＋0x8000) 这个基地址开始的大约1MB大小的内存范围内(嵌入式 Linux 的内核一般都不操过 1MB)。为什么要把从 MEM_START 到 MEM_START＋0x8000 这段 32KB 大小的内存空出来呢？这是因为 Linux 内核要在这段内存中放置一些全局数据结构，如：启动参数和内核页表等信息。
而对于根文件系统映像，则一般将其拷贝到 MEM_START+0x0010,0000 开始的地方。如果用 Ramdisk 作为根文件系统映像，则其解压后的大小一般是1MB。
（2）从 Flash 上拷贝
由于像 ARM 这样的嵌入式 CPU 通常都是在统一的内存地址空间中寻址 Flash 等固态存储设备的，因此从 Flash 上读取数据与从 RAM 单元中读取数据并没有什么不同。用一个简单的循环就可以完成从 Flash 设备上拷贝映像的工作：
while(count) { *dest++ = *src++; /* they are all aligned with word boundary */ count -= 4; /* byte number */};
3.2.4 设置内核的启动参数
应该说，在将内核映像和根文件系统映像拷贝到 RAM 空间中后，就可以准备启动 Linux 内核了。但是在调用内核之前，应该作一步准备工作，即：设置 Linux 内核的启动参数。
Linux 2.4.x 以后的内核都期望以标记列表(tagged list)的形式来传递启动参数。启动参数标记列表以标记 ATAG_CORE 开始，以标记 ATAG_NONE 结束。每个标记由标识被传递参数的 tag_header 结构以及随后的参数值数据结构来组成。数据结构 tag 和 tag_header 定义在 Linux 内核源码的include/asm/setup.h 头文件中：
/* The list ends with an ATAG_NONE node. */#define ATAG_NONE 0x00000000struct tag_header { u32 size; /* 注意，这里size是字数为单位的 */ u32 tag;};……struct tag { struct tag_header hdr; union { struct tag_core core; struct tag_mem32 mem; struct tag_videotext videotext; struct tag_ramdisk ramdisk; struct tag_initrd initrd; struct tag_serialnr serialnr; struct tag_revision revision; struct tag_videolfb videolfb; struct tag_cmdline cmdline; /* * Acorn specific */ struct tag_acorn acorn; /* * DC21285 specific */ struct tag_memclk memclk; } u;};
在嵌入式 Linux 系统中，通常需要由 Boot Loader 设置的常见启动参数有：ATAG_CORE、ATAG_MEM、ATAG_CMDLINE、ATAG_RAMDISK、ATAG_INITRD等。
比如，设置 ATAG_CORE 的代码如下：
params = (struct tag *)BOOT_PARAMS; params->hdr.tag = ATAG_CORE; params->hdr.size = tag_size(tag_core); params->u.core.flags = 0; params->u.core.pagesize = 0; params->u.core.rootdev = 0; params = tag_next(params);
其中，BOOT_PARAMS 表示内核启动参数在内存中的起始基地址，指针 params 是一个 struct tag 类型的指针。宏 tag_next() 将以指向当前标记的指针为参数，计算紧临当前标记的下一个标记的起始地址。注意，内核的根文件系统所在的设备ID就是在这里设置的。
下面是设置内存映射情况的示例代码：
for(i = 0; i < NUM_MEM_AREAS; i++) { if(memory_map[i].used) { params->hdr.tag = ATAG_MEM; params->hdr.size = tag_size(tag_mem32); params->u.mem.start = memory_map[i].start; params->u.mem.size = memory_map[i].size; params = tag_next(params); }}
可以看出，在 memory_map［］数组中，每一个有效的内存段都对应一个 ATAG_MEM 参数标记。
Linux 内核在启动时可以以命令行参数的形式来接收信息，利用这一点我们可以向内核提供那些内核不能自己检测的硬件参数信息，或者重载(override)内核自己检测到的信息。比如，我们用这样一个命令行参数字符串"console=ttyS0,115200n8"来通知内核以 ttyS0 作为控制台，且串口采用 "115200bps、无奇偶校验、8位数据位"这样的设置。下面是一段设置调用内核命令行参数字符串的示例代码：
char *p; /* eat leading white space */ for(p = commandline; *p == ' '; p++) ; /* skip non-existent command lines so the kernel will still * use its default command line. */ if(*p == '\0') return; params->hdr.tag = ATAG_CMDLINE; params->hdr.size = (sizeof(struct tag_header) + strlen(p) + 1 + 4) >> 2; strcpy(params->u.cmdline.cmdline, p); params = tag_next(params);
请注意在上述代码中，设置 tag_header 的大小时，必须包括字符串的终止符'\0'，此外还要将字节数向上圆整4个字节，因为 tag_header 结构中的size 成员表示的是字数。
下面是设置 ATAG_INITRD 的示例代码，它告诉内核在 RAM 中的什么地方可以找到 initrd 映象(压缩格式)以及它的大小：
params->hdr.tag = ATAG_INITRD2; params->hdr.size = tag_size(tag_initrd); params->u.initrd.start = RAMDISK_RAM_BASE; params->u.initrd.size = INITRD_LEN; params = tag_next(params);
下面是设置 ATAG_RAMDISK 的示例代码，它告诉内核解压后的 Ramdisk 有多大（单位是KB）：
params->hdr.tag = ATAG_RAMDISK;params->hdr.size = tag_size(tag_ramdisk); params->u.ramdisk.start = 0;params->u.ramdisk.size = RAMDISK_SIZE; /* 请注意，单位是KB */params->u.ramdisk.flags = 1; /* automatically load ramdisk */ params = tag_next(params);
最后，设置 ATAG_NONE 标记，结束整个启动参数列表：
static void setup_end_tag(void){ params->hdr.tag = ATAG_NONE; params->hdr.size = 0;}
3.2.5 调用内核
Boot Loader 调用 Linux 内核的方法是直接跳转到内核的第一条指令处，也即直接跳转到 MEM_START＋0x8000 地址处。在跳转时，下列条件要满足：
1． CPU 寄存器的设置：
R0＝0；
R1＝机器类型 ID；关于 Machine Type Number，可以参见 linux/arch/arm/tools/mach-types。
R2＝启动参数标记列表在 RAM 中起始基地址；
2． CPU 模式：
必须禁止中断（IRQs和FIQs）；
CPU 必须 SVC 模式；
3． Cache 和 MMU 的设置：
MMU 必须关闭；
指令 Cache 可以打开也可以关闭；
数据 Cache 必须关闭；
如果用 C 语言，可以像下列示例代码这样来调用内核：
void (*theKernel)(int zero, int arch, u32 params_addr) = (void (*)(int, int, u32))KERNEL_RAM_BASE;……theKernel(0, ARCH_NUMBER, (u32) kernel_params_start);
注意，theKernel()函数调用应该永远不返回的。如果这个调用返回，则说明出错。
在 boot loader 程序的设计与实现中，没有什么能够比从串口终端正确地收到打印信息能更令人激动了。此外，向串口终端打印信息也是一个非常重要而又有效的调试手段。但是，我们经常会碰到串口终端显示乱码或根本没有显示的问题。造成这个问题主要有两种原因：(1) boot loader 对串口的初始化设置不正确。(2) 运行在 host 端的终端仿真程序对串口的设置不正确，这包括：波特率、奇偶校验、数据位和停止位等方面的设置。
此外，有时也会碰到这样的问题，那就是：在 boot loader 的运行过程中我们可以正确地向串口终端输出信息，但当 boot loader 启动内核后却无法看到内核的启动输出信息。对这一问题的原因可以从以下几个方面来考虑：
(1) 首先请确认你的内核在编译时配置了对串口终端的支持，并配置了正确的串口驱动程序。
(2) 你的 boot loader 对串口的初始化设置可能会和内核对串口的初始化设置不一致。此外，对于诸如 s3c44b0x 这样的 CPU，CPU 时钟频率的设置也会影响串口，因此如果 boot loader 和内核对其 CPU 时钟频率的设置不一致，也会使串口终端无法正确显示信息。
(3) 最后，还要确认 boot loader 所用的内核基地址必须和内核映像在编译时所用的运行基地址一致，尤其是对于 uClinux 而言。假设你的内核映像在编译时用的基地址是 0xc0008000，但你的 boot loader 却将它加载到 0xc0010000 处去执行，那么内核映像当然不能正确地执行了。
Boot Loader 的设计与实现是一个非常复杂的过程。如果不能从串口收到那激动人心的"uncompressing linux.................. done, booting the kernel……"内核启动信息，恐怕谁也不能说："嗨，我的 boot loader 已经成功地转起来了！"。
原文链接：https://www.eeworld.com.cn/mcu/article_2016080328109.html
还没有评论，来说两句吧...