Linux内核移植到ARM.doc

在Linux内核移植到ARM处理器时，有一个问题不能忽视，那就是移植Boot－loader，Linux内核启动部分的代码需要判断从Boot－loader传递过来的寄存器值。
　　为什么需要Boot－loader呢？这与硬件本身的启动方式有关，有了Boot－loader可以方便系统的开发。通过这段Boot－loader小程序，可以初始化硬件设备、建立内存空间的映射图，从而将系统的软硬件环境带到一个合适的状态，以便为最终调用操作系统内核准备好正确的环境。
　　（1）Boot－loader所支持的CPU和嵌入式板
　　每种不同的CPU体系结构都有不同的Boot－loader，有些Boot－loader也支持多 种体系结构的CPU，如U－Boot。除了依赖于CPU的体系结构外，Boot－loader实际上也依赖于具体的嵌入式板级设备的配置。这也就是说，对 于两块不同的嵌入式板而言，即使它们是基于同一种CPU而构建的，要想让运行在一块板子上的Boot-loader程序也能运行在另一块板子上，通常也都 需要修改Boot－loader的源程序。
　　（2）Boot－loader的安装媒介
　　系统加电或复位后，所有的CPU通常都从某个预先安排的地址上取指令。比如，基于ARM内核的CPU在复位时通常都从地址Ox00000000取它的第一条指令。而基于CPU构建的嵌入式系统通常都有某种类型的固态存储设备（比如：ROM、EEPROM或Hash等）被映射到这个预先安排的地址上。因此在系统加电后，CPU将首先执行Boot－loader程序。如图所示就是一个同时装有Boot－loader、内核的启动参数、内核映像和根文件系统映像的固态存储设备的典型空间分配结构图。

　　图 固态存储设备的典型空间分配结构
　　（3）用来控制Boot-loader的设备或机制
　　主机和目标机之间一般通过串口建立连接，Boot－loader软件在执行时通常会通过串口来进行I／O，比如：输出打印信息到串口，从串口读取用户控制字符等。
　　（4）Boot-loader的启动过程是单阶段还是多阶段
　　通常多阶段的Boot-loader能提供更为复杂的功能，以及更好的可移植性。从固态存储设备上启动的Boot-loader大多都是2阶段的启动过程，即启动过程可以分为stage 1和stage2两部分。
　　（5）Boot-loader的操作模式
　　大多数Boot-loader都包含两种不同的操作模式：“启动加载”模式和“下载”模式，这两种区别不是很大。从最终用户的角度看，Boot-loader的作用就是用来加载操作系统，而并不存在所谓的启动加载模式与下载工作模式的区别。
　　启动加载模式：这种模式也称为“自主”模式。即Boot－loader从目标机上的某个固态存储设备上将操作系统加载到SDRAM中运行，整个过程并没有用户的介入。这种模式是Boot－loader的正常工作模式，因此在嵌入式产品发布时，Boot-loader必须工作在这种模式下。
　　下载模式：在这种模式下，目标机上的Boot－loader将通过串口连接或网络连接等通信手段从 主机（Host）下载文件，比如：下载内核映像和根文件系统映像等。从主机下载的文件通常首先被Boot－loader保存到目标板的SDRAM中，然后 再被Boot-loader写到目标板上的Hash类固态存储设备中。Boot－loader的这种模式通常在第一次安装内核与根文件系统时被使用；此 外，以后的系统更新也会使用Boot－loader的这种工作模式。工作于这种模式下的Boot－loader通常都会向它的终端用户提供一个简单的命令 行接口。
　　（6）Boot－loader与主机之间进行文件传输所用的通信设备及协议
　　最常见的情况就是，目标机上的Boot－loader通过串口与主机之间进行文件传输，传输协议通 常是xmodem ／ ymodem ／ zmodem协议中的一种。但是，串口传输的速度是有限的，因此通过以太网连接并借助TFTP协议来下载文件是个更好的选择。此外，主机方所用的软件也要 考虑。比如，在通过以太网连接和TFTP协议来下载文件时，主机方必须有一个软件用来提供TFTP服务。
　　（7）Boot－loader的主要任务与典型结构框架
　　首先做一个假定：假定内核映像与根文件系统映像都被加载到SDRAM中运行。因为，在嵌入式系统中 内核映像与根文件系统映像也可以直接在ROM或∏ash这样的固态存储设备中直接运行，但这种做法无疑是以运行速度的牺牲为代价的。从操作系统的角度 看，Boot－loader的总目标就是正确地调用内核来执行。
　　另外，由于Boot－loader依赖于CPU的体系结构，因此大多数Boot－loader都分 为stage 1和stage 2两大部分。依赖于CPU体系结构的代码，比如设各初始化代码等，通常都放在stage1中，而且通常都用ARM汇编语言来实现，以达到短小精悍的目的。 而stage 2则通常用C语言来实现，这样可以实现更复杂的功能，而且代码会具有更好的可读性和可移植性。
　　Boot－loader的stage 1和stage 2通常包括如表所示的5个步骤（以执行的先后顺序列出）。
　　（8）串口终端
　　Boot－loader程序设计与实现后，串口终端就能正确地收到打印信息了。此外，向串口终端打印信息也是一个非常重要而又有效的调试手段。
　　但是，经常会碰到串口终端显示乱码或根本没有显示的问题。发生这样的问题主要有两种原因：
　　·Boot－loader对串口的初始化设置不正确。
　　·运行在Host端的终端仿真程序对串口的设置不正确，这包括波特率、奇偶校验、数据位和停止位等方面的设置。
　　此外，有时也会碰到这样的问题，那就是：在Boot－loader的运行过程中可以正确地向串口终端输出信息，但当Boot－loader启动内核后却无法看到内核的启动输出信息。对发生这一问题的原因可以从以下几个方面来考虑。
　　·首先确认内核编译时配置了对串口终端的支持，并配置了正确的串口驱动程序。
　　·Boot－loader对串口的初始化设置可能会和内核对串口的初始化设置不一致，例如，
　　Boot－loader和内核对其CPU时钟频率的设置不一致。
　　·最后，还要确认Boot－loader所用的内核基地址必须和内核映像在编译时所用的运行基地址 一致，尤其是对于ARM Linux而言。假设内核映像在编译时用的基地址是0xc0028000，但Boot－loader却将它加载到0xc0010000处去执行，那么内核 映像就不能正确地执行。
在Linux内核移植到ARM处理器时，有一个问题不能忽视，那就是移植Boot－loader，Linux内核启动部分的代码需要判断从Boot－loader传递过来的寄存器值。
　　为什么需要Boot－loader呢？这与硬件本身的启动方式有关，有了Boot－loader可以方便系统的开发。通过这段Boot－loader小程序，可以初始化硬件设备、建立内存空间的映射图，从而将系统的软硬件环境带到一个合适的状态，以便为最终调用操作系统内核准备好正确的环境。
　　（1）Boot－loader所支持的CPU和嵌入式板
　　每种不同的CPU体系结构都有不同的Boot－loader，有些Boot－loader也支持多 种体系结构的CPU，如U－Boot。除了依赖于CPU的体系结构外，Boot－loader实际上也依赖于具体的嵌入式板级设备的配置。这也就是说，对 于两块不同的嵌入式板而言，即使它们是基于同一种CPU而构建的，要想让运行在一块板子上的Boot-loader程序也能运行在另一块板子上，通常也都 需要修改Boot－loader的源程序。
　　（2）Boot－loader的安装媒介
　　系统加电或复位后，所有的CPU通常都从某个预先安排的地址上取指令。比如，基于ARM内核的CPU在复位时通常都从地址Ox00000000取它的第一条指令。而基于CPU构建的嵌入式系统通常都有某种类型的固态存储设备（比如：ROM、EEPROM或Hash等）被映射到这个预先安排的地址上。因此在系统加电后，CPU将首先执行Boot－loader程序。如图所示就是一个同时装有Boot－loader、内核的启动参数、内核映像和根文件系统映像的固态存储设备的典型空间分配结构图。

　　图 固态存储设备的典型空间分配结构
　　（3）用来控制Boot-loader的设备或机制
　　主机和目标机之间一般通过串口建立连接，Boot－loader软件在执行时通常会通过串口来进行I／O，比如：输出打印信息到串口，从串口读取用户控制字符等。
　　（4）Boot-loader的启动过程是单阶段还是多阶段
　　通常多阶段的Boot-loader能提供更为复杂的功能，以及更好的可移植性。从固态存储设备上启动的Boot-loader大多都是2阶段的启动过程，即启动过程可以分为stage 1和stage2两部分。
　　（5）Boot-loader的操作模式
　　大多数Boot-loader都包含两种不同的操作模式：“启动加载”模式和“下载”模式，这两种区别不是很大。从最终用户的角度看，Boot-loader的作用就是用来加载操作系统，而并不存在所谓的启动加载模式与下载工作模式的区别。
　　启动加载模式：这种模式也称为“自主”模式。即Boot－loader从目标机上的某个固态存储设备上将操作系统加载到SDRAM中运行，整个过程并没有用户的介入。这种模式是Boot－loader的正常工作模式，因此在嵌入式产品发布时，Boot-loader必须工作在这种模式下。
　　下载模式：在这种模式下，目标机上的Boot－loader将通过串口连接或网络连接等通信手段从 主机（Host）下载文件，比如：下载内核映像和根文件系统映像等。从主机下载的文件通常首先被Boot－loader保存到目标板的SDRAM中，然后 再被Boot-loader写到目标板上的Hash类固态存储设备中。Boot－loader的这种模式通常在第一次安装内核与根文件系统时被使用；此 外，以后的系统更新也会使用Boot－loader的这种工作模式。工作于这种模式下的Boot－loader通常都会向它的终端用户提供一个简单的命令 行接口。
　　（6）Boot－loader与主机之间进行文件传输所用的通信设备及协议
　　最常见的情况就是，目标机上的Boot－loader通过串口与主机之间进行文件传输，传输协议通 常是xmodem ／ ymodem ／ zmodem协议中的一种。但是，串口传输的速度是有限的，因此通过以太网连接并借助TFTP协议来下载文件是个更好的选择。此外，主机方所用的软件也要 考虑。比如，在通过以太网连接和TFTP协议来下载文件时，主机方必须有一个软件用来提供TFTP服务。
　　（7）Boot－loader的主要任务与典型结构框架
　　首先做一个假定：假定内核映像与根文件系统映像都被加载到SDRAM中运行。因为，在嵌入式系统中 内核映像与根文件系统映像也可以直接在ROM或∏ash这样的固态存储设备中直接运行，但这种做法无疑是以运行速度的牺牲为代价的。从操作系统的角度 看，Boot－loader的总目标就是正确地调用内核来执行。
　　另外，由于Boot－loader依赖于CPU的体系结构，因此大多数Boot－loader都分 为stage 1和stage 2两大部分。依赖于CPU体系结构的代码，比如设各初始化代码等，通常都放在stage1中，而且通常都用ARM汇编语言来实现，以达到短小精悍的目的。 而stage 2则通常用C语言来实现，这样可以实现更复杂的功能，而且代码会具有更好的可读性和可移植性。
　　Boot－loader的stage 1和stage 2通常包括如表所示的5个步骤（以执行的先后顺序列出）。
　　（8）串口终端
　　Boot－loader程序设计与实现后，串口终端就能正确地收到打印信息了。此外，向串口终端打印信息也是一个非常重要而又有效的调试手段。
　　但是，经常会碰到串口终端显示乱码或根本没有显示的问题。发生这样的问题主要有两种原因：
　　·Boot－loader对串口的初始化设置不正确。
　　·运行在Host端的终端仿真程序对串口的设置不正确，这包括波特率、奇偶校验、数据位和停止位等方面的设置。
　　此外，有时也会碰到这样的问题，那就是：在Boot－loader的运行过程中可以正确地向串口终端输出信息，但当Boot－loader启动内核后却无法看到内核的启动输出信息。对发生这一问题的原因可以从以下几个方面来考虑。
　　·首先确认内核编译时配置了对串口终端的支持，并配置了正确的串口驱动程序。
　　·Boot－loader对串口的初始化设置可能会和内核对串口的初始化设置不一致，例如，
　　Boot－loader和内核对其CPU时钟频率的设置不一致。
　　·最后，还要确认Boot－loader所用的内核基地址必须和内核映像在编译时所用的运行基地址 一致，尤其是对于ARM Linux而言。假设内核映像在编译时用的基地址是0xc0028000，但Boot－loader却将它加载到0xc0010000处去执行，那么内核 映像就不能正确地执行。