「干货」嵌入式Linux系统移植的四大步骤（上）

在学习系统移植的相关知识，在学习和调试过程中，发现了很多问题，也解决了很多问题，但总是对于我们的开发结果有一种莫名其妙的感觉，纠其原因，主要对于我们的开发环境没有一个深刻的认识，有时候几个简单的命令就可以完成非常复杂的功能，可是我们有没有想过，为什么会有这样的效果？

如果没有去追问，只是机械地完成，并且看到实验效果，这样做其实并没有真正的掌握系统移植的本质。

在做每一个步骤的时候， 首先问问自己，为什么要这样做，然后再问问自己正在做什么？ 搞明白这几个问题，我觉得就差不多了，以后不管更换什么平台，什么芯片，什么开发环境，你都不会迷糊，很快就会上手。对于嵌入式的学习方法，我个人方法就是：从宏观上把握(解决为什么的问题)，微观上研究(解决正在做什么的问题)，下面以自己学习的arm-cortex_a8开发板为目标，介绍下自己的学习方法和经验。

嵌入式Linux系统移植主要由四大部分组成：

一、搭建交叉开发环境

二、bootloader的选择和移植

三、kernel的配置、编译、和移植

四、根文件系统的制作

第一部分：搭建交叉开发环境

先介绍第一分部的内容：搭建交叉开发环境，首先必须得思考两个问题，什么是交叉环境? 为什么需要搭建交叉环境？

先回答第一个问题，在嵌入式开发中，交叉开发是很重要的一个概念，开发的第一个环节就是搭建环境，第一步不能完成，后面的步骤从无谈起，这里所说的交叉开发环境主要指的是：在开发主机上(通常是我的pc机)开发出能够在目标机(通常是我们的开发板)上运行的程序。嵌入式比较特殊的是不能在目标机上开发程序(狭义上来说)，因为对于一个原始的开发板，在没有任何程序的情况下它根本都跑不起来，为了让它能够跑起来，我们还必须要借助pc机进行烧录程序等相关工作，开发板才能跑起来，这里的pc机就是我们说的开发主机，想想如果没有开发主机，我们的目标机基本上就是无法开发，这也就是电子行业的一句名言：搞电子，说白了，就是玩电脑！

然后回答第二个问题，为什么需要交叉开发环境？主要原因有以下几点：

原因 1： 嵌入式系统的硬件资源有很多限制，比如cpu主频相对较低，内存容量较小等，想想让几百MHZ主频的MCU去编译一个Linux kernel会让我们等的不耐烦，相对来说，pc机的速度更快，硬件资源更加丰富，因此利用pc机进行开发会提高开发效率。

原因2： 嵌入式系统MCU体系结构和指令集不同，因此需要安装交叉编译工具进行编译，这样编译的目标程序才能够在相应的平台上比如：ARM、MIPS、 POWEPC上正常运行。

交叉开发环境的硬件组成主要由以下几大部分 ：

1.开发主机

2.目标机（开发板）

3.二者的链接介质，常用的主要有3种方式：(1)串口线 (2)USB线 (3)网线

对应的硬件介质，还必须要有相应的软件“介质”支持：

1.对于串口，通常用的有串口调试助手，putty工具等，工具很多，功能都差不多，会用一两款就可以；

2.对于USB线，当然必须要有USB的驱动才可以，一般芯片公司会提供，比如对于三星的芯片，USB下载主要由DNW软件来完成；

3.对于网线，则必须要有网络协议支持才可以， 常用的服务主要两个

第一：tftp服务：

主要用于实现文件的下载，比如开发调试的过程中，主要用tftp把要测试的bootloader、kernel和文件系统直接下载到内存中运行，而不需要预先烧录到Flash芯片中，一方面，在测试的过程中，往往需要频繁的下载，如果每次把这些要测试的文件都烧录到Flash中然后再运行也可以，但是缺点是：过程比较麻烦，而且Flash的擦写次数是有限的；另外一方面：测试的目的就是把这些目标文件加载到内存中直接运行就可以了，而tftp就刚好能够实现这样的功能，因此，更没有必要把这些文件都烧录到Flash中去。

第二： nfs服务：

主要用于实现网络文件的挂载，实际上是实现网络文件的共享，在开发的过程中，通常在系统移植的最后一步会制作文件系统，那么这是可以把制作好的文件系统放置在我们开发主机PC的相应位置，开发板通过nfs服务进行挂载，从而测试我们制作的文件系统是否正确，在整个过程中并不需要把文件系统烧录到Flash中去，而且挂载是自动进行挂载的，bootload启动后，kernel运行起来后会根据我们设置的启动参数进行自动挂载，因此，对于开发测试来讲，这种方式非常的方便，能够提高开发效率。

另外，还有一个名字叫 samba 的服务也比较重要，主要用于文件的共享，这里说的共享和nfs的文件共享不是同一个概念，nfs的共享是实现网络文件的共享，而samba实现的是开发主机上 Windows主机和Linux虚拟机之间的文件共享，是一种跨平台的文件共享 ，方便的实现文件的传输。

以上这几种开发的工具在嵌入式开发中是必备的工具，对于嵌入式开发的效率提高做出了伟大的贡献，因此，要对这几个工具熟练使用，这样你的开发效率会提高很多。等测试完成以后，就会把相应的目标文件烧录到Flash中去，也就是等发布产品的时候才做的事情，因此对于开发人员来说，所有的工作永远是测试。

通过前面的工作，我们已经准备好了交叉开发环境的硬件部分和一部分软件，最后还缺少交叉编译器，读者可能会有疑问，为什么要用交叉编译器？前面已经讲过，交叉开发环境必然会用到交叉编译工具，通俗地讲就是在一种平台上编译出能运行在体系结构不同的另一种平台上的程序，开发主机PC平台（X86 CPU）上编译出能运行在以ARM为内核的CPU平台上的程序，编译得到的程序在X86 CPU平台上是不能运行的，必须放到ARM CPU平台上才能运行，虽然两个平台用的都是Linux系统。相对于交叉编译，平常做的编译叫本地编译，也就是在当前平台编译，编译得到的程序也是在本地执行。用来编译这种跨平台程序的编译器就叫交叉编译器，相对来说，用来做本地编译的工具就叫本地编译器。所以要生成在目标机上运行的程序，必须要用交叉编译工具链来完成。

这里又有一个问题，不就是一个交叉编译工具吗？为什么又叫交叉工具链呢？原因很简单，程序不能光编译一下就可以运行，还得进行汇编和链接等过程，同时还需要进行调试，对于一个很大工程，还需要进行工程管理等等，所以，这里 说的交叉编译工具是一个由 编译器、连接器和解释器 组成的综合开发环境，交叉编译工具链主要由binutils(主要包括汇编程序as和链接程序ld)、gcc(为GNU系统提供C编译器)和glibc(一些基本的C函数和其他函数的定义) 3个部分组成。有时为了减小libc库的大小，也可以用别的 c 库来代替 glibc，例如 uClibc、dietlibc 和 newlib。

那么，如何得到一个交叉工具链呢？是从网上下载一个“程序”然后安装就可以使用了吗？回答这个问题之前先思考这样一个问题，我们的交叉工具链顾名思义就是在PC机上编译出能够在我们目标开发平台比如ARM上运行的程序，这里就又有一个问题了，我们的ARM处理器型号非常多，难道有专门针对我们某一款的交叉工具链吗？若果有的话，可以想一想，这么多处理器平台，每个平台专门定制一个交叉工具链放在网络上，然后供大家去下载，想想可能需要找很久才能找到适合你的编译器，显然这种做法不太合理，且浪费资源！因此，要得到一个交叉工具链，就像我们移植一个Linux内核一样，我们只关心我们需要的东西，编译我们需要的东西在我们的平台上运行，不需要的东西我们不选择不编译，所以，交叉工具链的制作方法和系统移植有着很多相似的地方，也就是说，交叉开发工具是一个支持很多平台的工具集的集合(类似于Linux源码)，然后我们只需从这些工具集中找出跟我们平台相关的工具就行了，那么如何才能找到跟我们的平台相关的工具，这就是涉及到一个如何制作交叉工具链的问题了。

通常构建交叉工具链有如下三种方法：

方法一 ： 分步编译和安装交叉编译工具链所需要的库和源代码，最终生成交叉编译工具链。该方法相对比较困难，适合想深入学习构建交叉工具链的读者。如果只是想使用交叉工具链，建议使用下列的方法二构建交叉工具链。

方法二： 通过Crosstool-ng脚本工具来实现一次编译，生成交叉编译工具链，该方法相对于方法一要简单许多，并且出错的机会也非常少，建议大多数情况下使用该方法构建交叉编译工具链。

方法三 ： 直接通过网上下载已经制作好的交叉编译工具链。该方法的优点不用多说，当然是简单省事，但与此同时该方法有一定的弊端就是局限性太大，因为毕竟是别人构建好的，也就是固定的，没有灵活性，所以构建所用的库以及编译器的版本也许并不适合你要编译的程序，同时也许会在使用时出现许多莫名其妙的错误，建议读者慎用此方法。

crosstool-ng是一个脚本工具，可以制作出适合不同平台的交叉编译工具链，在进行制作之前要安装一下软件：

$ sudo apt-get install g++ libncurses5-dev bison flex texinfo automake libtool patch gcj cvs cvsd gawk

crosstool脚本工具可以在http://ymorin.is-a-geek.org/projects/crosstool下载到本地，然后解压，接下来就是进行安装配置了，这个配置优点类似内核的配置。主要的过程有以下几点：

1. 设定源码包路径和交叉编译器的安装路径

2. 修改交叉编译器针对的构架

3. 增加编译时的并行进程数，以增加运行效率，加快编译，因为这个编译会比较慢。

4. 关闭JAVA编译器 ，减少编译时间

5. 编译

6. 添加环境变量

7. 刷新环境变量。

8. 测试交叉工具链

到此，嵌入式Linux系统移植四大部分的第一部分工作全部完成，接下来可以进行后续的开发了。

第二部分：bootloader的选择和移植

01 Boot Loader 概念

就是在 *** 作系统内核运行之前运行的一段小程序。通过这段小程序，我们可以初始化硬件设备、建立内存空间的映射图，从而将系统的软硬件环境带到一个合适的状态，以便为最终调用 *** 作系统内核准备好正确的环境，他就是所谓的引导加载程序（Boot Loader）。

02 为什么系统移植之前要先移植BootLoader？

BootLoader的任务是引导 *** 作系统，所谓引导 *** 作系统，就是启动内核，让内核运行就是把内核加载到内存RAM中去运行，那先问两个问题：第一个问题，是谁把内核搬到内存中去运行？第二个问题：我们说的内存是SDRAM，大家都知道，这种内存和SRAM不同，最大的不同就是SRAM只要系统上电就可以运行，而SDRAM需要软件进行初始化才能运行，那么在把内核搬运到内存运行之前必须要先初始化内存吧，那么内存是由谁来初始化的呢？其实这两件事情都是由bootloader来干的，目的是为内核的运行准备好软硬件环境，没有bootloadr我们的系统当然不能跑起来。

03 bootloader的分类

首先更正一个错误的说法，很多人说bootloader就是U-boot，这种说法是错误的，确切来说是u-boot是bootloader的一种。也就是说bootloader具有很多种类，

由上图可以看出，不同的bootloader具有不同的使用范围，其中最令人瞩目的就是有一个叫U-Boot的bootloader，是一个通用的引导程序，而且同时支持X86、ARM和PowerPC等多种处理器架构。U-Boot，全称 Universal Boot Loader，是遵循GPL条款的开放源码项目，是由德国DENX小组开发的用于多种嵌入式CPU的bootloader程序，对于Linux的开发，德国的u-boot做出了巨大的贡献，而且是开源的。

u-boot具有以下特点：

① 开放源码；

② 支持多种嵌入式 *** 作系统内核，如Linux、NetBSD, VxWorks, QNX, RTEMS, ARTOS, LynxOS；

③ 支持多个处理器系列，如PowerPC、ARM、x86、MIPS、XScale；

④ 较高的可靠性和稳定性；

⑤ 高度灵活的功能设置，适合U-Boot调试、 *** 作系统不同引导要求、产品发布等；

⑥ 丰富的设备驱动源码，如串口、以太网、SDRAM、FLASH、LCD、NVRAM、EEPROM、RTC、键盘等；

⑦ 较为丰富的开发调试文档与强大的网络技术支持；

其实，把u-boot可以理解为是一个小型的 *** 作系统。

04 u-boot的目录结构

* board 目标板相关文件，主要包含SDRAM、FLASH驱动；

* common 独立于处理器体系结构的通用代码，如内存大小探测与故障检测；

* cpu 与处理器相关的文件。如mpc8xx子目录下含串口、网口、LCD驱动及中断初始化等文件；

* driver 通用设备驱动，如CFI FLASH驱动(目前对INTEL FLASH支持较好)

* doc U-Boot的说明文档；

* examples可在U-Boot下运行的示例程序；如hello_world.c,timer.c；

* include U-Boot头文件；尤其configs子目录下与目标板相关的配置头文件是移植过程中经常要修改的文件；

* lib_xxx 处理器体系相关的文件，如lib_ppc, lib_arm目录分别包含与PowerPC、ARM体系结构相关的文件；

* net 与网络功能相关的文件目录，如bootp,nfs,tftp；

* post 上电自检文件目录。尚有待于进一步完善；

* rtc RTC驱动程序；

* tools 用于创建U-Boot S-RECORD和BIN镜像文件的工具；

05 u-boot的工作模式

U-Boot的工作模式有 启动加载模式和下载模式 。启动加载模式是Bootloader的正常工作模式，嵌入式产品发布时，Bootloader必须工作在这种模式下，Bootloader将嵌入式 *** 作系统从FLASH中加载到SDRAM中运行，整个过程是自动的。 下载模式 就是Bootloader通过某些通信手段将内核映像或根文件系统映像等从PC机中下载到目标板的SDRAM中运行，用户可以利用Bootloader提供的一些令接口来完成自己想要的 *** 作，这种模式主要用于测试和开发。

06 u-boot的启动过程

大多数BootLoader都分为stage1和stage2两大部分，U-boot也不例外。依赖于cpu体系结构的代码（如设备初始化代码等）通常都放在stage1且可以用汇编语言来实现，而stage2则通常用C语言来实现，这样可以实现复杂的功能，而且有更好的可读性和移植性。

1、 stage1(start.s代码结构)

U-boot的stage1代码通常放在start.s文件中，它用汇编语言写成，其主要代码部分如下：

（1） 定义入口。由于一个可执行的image必须有一个入口点，并且只能有一个全局入口，通常这个入口放在rom(Flash)的0x0地址，因此，必须通知编译器以使其知道这个入口，该工作可通过修改连接器脚本来完成。

（2）设置异常向量(exception vector)。

（3）设置CPU的速度、时钟频率及中断控制寄存器。

（4）初始化内存控制器 。

（5）将rom中的程序复制到ram中。

（6）初始化堆栈 。

（7）转到ram中执行，该工作可使用指令ldrpc来完成。

2、 stage2（C语言代码部分）

lib_arm/board.c中的start armboot是C语言开始的函数，也是整个启动代码中C语言的主函数，同时还是整个u-boot（armboot）的主函数，该函数主要完成如下 *** 作：

（1）调用一系列的初始化函数。

（2）初始化flash设备。

（3）初始化系统内存分配函数。

（4）如果目标系统拥有nand设备，则初始化nand设备。

（5）如果目标系统有显示设备，则初始化该类设备。

（6）初始化相关网络设备，填写ip,c地址等。

（7）进入命令循环（即整个boot的工作循环），接受用户从串口输入的命令，然后进行相应的工作。

07 基于cortex-a8的s5pc100bootloader启动过程分析

s5pc100支持两种启动方式，分别为USB启动方式和NandFlash启动方式：

1. S5PC100 USB启动过程

[1] A8 reset, 执行iROM中的程序

[2] iROM中的程序根据S5PC100的配置管脚(SW1开关4，拨到4对面)，判断从哪里启动(USB)

[3] iROM中的程序会初始化USB，然后等待PC机下载程序

[4] 利用DNW程序，从PC机下载SDRAM的初始化程序到iRAM中运行，初始化SDRAM

[5] SDRAM初始化完毕，iROM中的程序继续接管A8, 然后等待PC下载程序(BootLoader)

[6] PC利用DNW下载BootLoader到SDRAM

[7] 在SDRAM中运行BootLoader

2. S5PC100 Nandflash启动过程

[1] A8 reset, 执行IROM中的程序

[2] iROM中的程序根据S5PC100的配置管脚(SW1开关4，拨到靠4那边)，判断从哪里启动(Nandflash)

[3] iROM中的程序驱动Nandflash

[4] iROM中的程序会拷贝Nandflash前16k到iRAM

[5] 前16k的程序(BootLoader前半部分)初始化SDRAM，然后拷贝完整的BootLoader到SDRAM并运行

[6] BootLoader拷贝内核到SDRAM，并运行它

[7] 内核运行起来后，挂载rootfs，并且运行系统初始化脚本

08 u-boot移植(基于cortex_a8的s5pc100为例)

1.建立自己的平台

(1).下载源码包2010.03版本，比较稳定

(2).解压后添加我们自己的平台信息，以smdkc100为参考版，移植自己s5pc100的开发板

(3).修改相应目录的文件名，和相应目录的Makefile，指定交叉工具链。

(4).编译

(5).针对我们的平台进行相应的移植，主要包括修改SDRAM的运行地址，从0x20000000

(6).“开关”相应的宏定义

(7).添加Nand和网卡的驱动代码

(8).优化go命令

(9).重新编译 make distclean(彻底删除中间文件和配置文件) make s5pc100_config(配置我们的开发板) make(编译出我们的u-boot.bin镜像文件)

(10).设置环境变量，即启动参数，把编译好的u-boot下载到内存中运行，过程如下：

1. 配置开发板网络

ip地址配置:

$setenv ipaddr 192.168.0.6 配置ip地址到内存的环境变量

$saveenv 保存环境变量的值到nandflash的参数区

网络测试:

在开发开发板上ping虚拟机：

$ ping 192.168.0.157(虚拟机的ip地址)

如果网络测试失败,从下面几个方面检查网络：

1. 网线连接好

2. 开发板和虚拟机的ip地址是否配置在同一个网段

3. 虚拟机网络一定要采用桥接(VM--Setting-->option)

4. 连接开发板时，虚拟机需要设置成 静态ip地址

2. 在开发板上，配置tftp服务器(虚拟机)的ip地址

$setenv serverip 192.168.0.157(虚拟机的ip地址)

$saveenv

3. 拷贝u-boot.bin到/tftpboot(虚拟机上的目录)

4. 通过tftp下载u-boot.bin到开发板内存

$ tftp 20008000(内存地址即可) u-boot.bin(要下载的文件名)

如果上面的命令无法正常下载:

1. serverip配置是否正确

2. tftp服务启动失败，重启tftp服务

#sudo service tftpd-hpa restart

5. 烧写u-boot.bin到nandflash的0地址

$nand erase 0(起始地址) 40000(大小) 擦出nandflash 0 - 256k的区域

$nand write 20008000((缓存u-boot.bin的内存地址) 0(nandflash上u-boot的位置) 40000(烧写大小)

6. 切换开发板的启动方式到nandflash

1. 关闭开发板

2. 把SW1的开关4拨到4的那边

3. 启动开发板，它就从nandflash启动

与其它 *** 作系统相比，Linux最大的特点：它是一款遵循GPL的 *** 作系统，我们可以自由

地使用、修改、和扩展它。正是由于这一特色，Linux受到越来越多人士的青睐。于是，

一个经常会被探讨的问题出现了，即关于Linux系统的移植。对于 *** 作系统而言，这种移

植通常是跨平台的、与硬件相关的，即硬件系统结构、甚至CPU不同。下面就让我们来看

看在Linux系统移植方面，我们都需要做些什么。

一、Linux系统移植的两大部分

对于系统移植而言，Linux系统实际上由两个比较独立的部分组成，即内核部分和系

统部分。通常启动一个Linux系统的过程是这样的：一个不隶属于任何 *** 作系统的加载程

序将Linux部分内核调入内存，并将控制权交给内存中Linux内核的第一行代码。加载程

序的工作就完了，此后Linux要将自己的剩余部分全部加载到内存（如果有的话，视硬件

平台的不同而不同），初始化所有的设备，在内存中建立好所需的数据结构（有关进程

、设备、内存等）。到此为止Linux内核的工作告一段落，内核已经控制了所有硬件设备

。至于 *** 作和使用这些硬件设备，则轮到系统部分上场了。内核加载根设备并启动init

守护进程，init守护进程会根据配置文件加载文件系统、配置网络、服务进程、终端等

。一旦终端初始化完毕，我们就会看到系统的欢迎界面了。小结一下：

(1)内核部分初始化和控制所有硬件设备（严格说不是所有，而是绝大部分），为内存

管理、进程管理、设备读写等工作做好一切准备。

(2)系统部分加载必需的设备，配置各种环境以便用户可以使用整个系统。

二、系统移植所必需的环境

在进一步叙述之前，我们有必要提一下做系统移植所必需的环境。

首先，需要一个新版本的gcc。对于一个准备系统移植的程序员而言，“新”到什么

程度应该心里有数。做跨平台编译，gcc也许是最好的选择。另外，Linux内核依赖许多

gcc特有的特性，非它不可。如果你已经会使用gcc并实地 *** 练过多回，那你只需要再进

一步巩固一下跨平台编译的 *** 作即可。两种编译环境是可用的：非目标平台上的Linux或

目标平台上的非Linux系统，除非你的开发平台过于特殊，否则你一定能够找到你能用的

gcc。

其次，编译链接库是必需的，而且必须是目标平台的编译链接库。通常这是一个枯

燥、繁琐、又丝毫没有成就感的过程。幸运的话，会有现成的链接库可以用。否则，你

需要自己用gcc建立它。

最后，需要目标平台的所有文档，越多越好。如果有一定的开发支持/仿真环境，L

oader（加载程序）则最好，这些可以帮助你减少移植过程中浪费在琐事上的时间。

三、Linux系统移植

接下来我们从内核和系统两个方面描述一下移植中的关键。

(1) 内存移植

Linux系统采用了相对来说并不是很灵活的单一内核机制，但这丝毫没有影响Linux

系统的平台无关性和可扩展性。Linux使用了两种途径分别解决这些问题，很干净利落，

丝毫不拖泥带水，而且十分清晰易懂。分离硬件相关代码和硬件无关代码，使上层代码

永远不必关心低层换用了什么代码，如何完成了 *** 作。不论对x86上还是在Alpha平台上

分配一块内存，对上层代码而言没什么不同。硬件相关部分的代码不多，占总代码量的

很少一部分。所以对更换硬件平台来说，没有什么真正的负担。另一方面，Linux使用内

核机制很好地解决了扩展的问题，一堆代码可以在需要的时候轻松地加载或卸下，象随

身听，需要的时候带上，不需要时则锁在抽屉里。

Linux内核可以视为由五个功能部分组成：进程管理（包括调度和通信）、内存管理

、设备管理、虚拟文件系统、网络。它们之间有着复杂的调用关系，但幸运的是，在移

植中不会触及到太多，因为Linux内核良好的分层结构将硬件相关的代码独立出来。何谓

硬件相关，何谓无关？以进程管理为例，对进程的时间片轮转调度算法在所有平台的Li

nux中都是一样的，它是与平台无关的；而用来在进程中切换的实现在不同的CPU上是不

同的，因此需要针对该平台编写代码，这就是平台相关的。上面所讲的五个部分的顺序

不是随便排的，从前到后分别代表着它们与硬件设备的相关程度。越靠前越高，后面的

两个虚拟文件系统和网络则几乎与平台无关，它们由设备管理中所支持的驱动程序提供

底层支持。因此，在做系统移植的时候，需要改动的就是进程管理、内存管理和设备管

理中被独立出来的那部分即硬件相关部分的代码。在Linux代码树下，这部分代码全部在

arch目录下。

如果你的目标平台已经被Linux核心所支持的话，那么你是幸运的，因为已经没有太

多的工作让你去做。只要你的交叉编译环境是正确的，你只需要简单的配置、编译就可

以得到目标代码。否则，需要你去编写，或修改一些代码。只需修改平台相关部分的代

码即可。但需要对目标平台，主要是对CPU的透彻理解。在Linux的代码树下，可以看到

，这部分的典型代码量为：2万行左右C代码和2千行左右的汇编（C代码中通常包含许多

伪汇编指令，因此实际上纯C代码要少很多），这部分工作量是不可小看的。它包含了对

绝大多数硬件的底层 *** 作，涉及IRQ、内存页表、快表、浮点处理、时钟、多处理器同步

等问题，频繁的端口编程意味着需要你将目标平台的文档用C语言重写一遍。这就是为什

么说目标平台的文档极其重要。

代码量最大的部分是被核心直接调用的底层支持部分，这部分代码在arch/xxx/ker

nel下(xxx是平台名称)。这些代码重写了内核所需调用的所有函数。因为接口函数是固

定的，所以这里更象是为硬件平台编写API。不同的系统平台，主要有以下几方面的不同

：

进程管理底层代码：从硬件系统的角度来看，进程管理就是CPU的管理。在不同的硬

件平台上，这有很大的不同。CPU中用的寄存器结构不同，上下文切换的方式、现场的保

存和恢复、栈的处理都不同，这些内容主要由CPU开发手册所描述。通常来说，CPU的所

有功能和状态对于Linux不一定有意义。实现时，需要在最小的开发代价和最好的系统性

能之间加以权衡。

* BIOS接口代码：这一名称似乎并不太准确，因为它沿用了PC一贯的叫法。但在不致引

起混淆的情况下我们还是这么叫它。在通用平台上，通常有基本输入输出系统供 *** 作系

统使用，在PC上是BIOS，在SPARC上是PROM，在很多非通用系统上甚至并没有这样的东西

。多数情况下，Linux不依赖基本输入输出系统，但在某些系统里，Linux需要通过基本

输入输出系统中得到重要的设备参数。移植中，这部分代码通常需要完全改写。

* 时钟、中断等板上设备支持代码：即使在同一种CPU的平台上，也会存在不同的板上外

设，异种CPU平台上更是如此。不同的系统组态需要不同的初始化代码。很典型的例子就

是MIPS平台，看看arc/mips/的代码，与其它系统比较一下就知道。因为MIPS平台被OEM

得最广，在嵌入式领域应用最多（相对其它几种CPU而言）。甚至同一种MIPS芯片被不同

厂家封装再配上不同的芯片组。因此要为这些不同的MIPS平台分别编写不同的代码。

* 特殊结构代码：如多处理器支持等。其实每一种CPU都是十分特殊的，熟悉x86平台的

人都知道x86系列CPU著名的实模式与虚模式的区别，而在SPARC平台上根本就没有这个概

念。这就导致了很大的不同：PC机上的Linux在获得控制权后不久就开始切换到虚模式，

SPARC机器上则没有这段代码。又如电源管理的支持更是多种多样，不同的CPU有着不同

的实现方式（特殊的电源管理方式甚至被厂商标榜）。在这种情况下，除非放弃对电源

管理的支持，否则必须重写代码。

还有一部分代码量不多，但不能忽视的部分是在arch/xxx/mm/下的内存管理部分。

所有与平台相关的内存管理代码全部在这里。这部分代码完成内存的初始化和各种与内

存管理相关的数据结构的建立。Linux使用了基于页式管理的虚拟存储技术，而CPU发展

的趋势是：为了提高性能，实现内存管理的功能单元统统被集成到CPU中。因此内存管理

成为一个与CPU十分相关的工作。同时内存管理的效率也是最影响系统性能的因素之一。

内存可以说是计算机系统中最频繁访问的设备，如果每次内存访问时多占用一个时钟周

期，那就有可能将系统性能降低到不可忍受。在Linux系统里，不同平台上的内存管理代

码的差异程度是令人吃惊的，可以说是差异最大的。不同的CPU有不同的内存管理方式，

同一种CPU还会有不同的内存管理模式。Linux是从32位硬件平台上发展起来的 *** 作系统

，但是现在已经有数种64位平台出现。在64位平台上，可用内存范围增大到原来的232倍

，其间差异可略窥一斑了。鉴于这部分代码的重要性和复杂性，移植工作在这里变得相

当谨慎。有些平台上甚至只是用最保守的内存管理模式。如在SPARC平台上的页面大小可

以是多种尺寸，为了简单和可靠起见，SPARC版的Linux只是用了8K页面这一种模式。这

一状况直到2.4版才得以改善。

除了上面所讲的之外，还有一些代码需要考虑，但相对来说次要一些。如浮点运算

的支持。较完美的做法是对FPU编程，由硬件完成浮点运算。但在某些时候，浮点并不重

要，甚至CPU根本就不支持浮点。这时候就可以根据需求来取舍。

对于内核移植的讨论到此为止。实际上，还有一些移植工作需要同时考虑，但很难

说这是属于内核范畴还是属于驱动程序范畴，比如说显示设备的支持，和内核十分相关

，但在逻辑上又不属于内核，并且在移植上也更像是驱动程序的开发。因此不在这里讨

论。

(2)系统移植

当内核移植完毕后，可以说所有的移植工作就已经完成大半了。就是说，当内核在

交叉编译成功后，加载到目标平台上正常启动，并出现类似VFS: Can抰 mount root fi

le system的提示时，则表示可以开始系统移植方面的工作了。系统移植实际上是一个最

小系统的重建过程。许多Linux爱好者有过建立Linux系统应急盘的经验，与其不同的是

，你需要使用目标平台上的二进制代码生成这个最小系统。包括：init、libc库、驱动

模块、必需的应用程序和系统配置脚本。一旦这些工作完成，移植工作就进入联调阶段

了。

一个比较容易的系统部分移植办法是：先着手建立开发平台上的最小系统，保证这

套最小系统在开发平台上正确运行。这样可以避免由于最小系统本身的逻辑错误而带来

的麻烦。由于最小系统中是多个应用程序相互配合工作，有时出现的问题不在代码本身

而在系统的逻辑结构上。

Linux系统移植工作至少要包括上述的内容，除此之外，有一些看不见的开发工作也

是不可忽视的，如某个特殊设备的驱动程序，为调试内核而做的远程调试工作等。另外

，同样的一次移植工作，显然符合最小功能集的移植和完美移植是不一样的；向16位移

植和向64位移植也是不一样的。

在移植中通常会遇见的问题是试运行时锁死或崩溃，在系统部分移植时要好办些，

因为可以容易地定位错误根源，而在核心移植时确实很让人头疼。虽然可以通过串口对

运行着的内核进行调试，但是在多任务情况下，有很多现象是不可重现的。又如，在初

始化的开始，很多设备还没法确定状态，甚至串口还没有初始化。对于这种情况没有什

么很好的解决办法，好的开发/仿真平台很重要，另外要多增加反映系统运行状态的调试

代码；再者要吃透硬件平台的文档。硬件平台厂商的专业支持也是很重要的。

还有一点很重要：Linux本身是基于GPL的 *** 作系统，移植时，可以充分发挥GPL的优

势，让更多的爱好者参与进来，向共同的目标前进。

---