结构体struct neigh_table是一个哈希表，用于描述物理上互相连接的机器的信息。ARP缓存myarp_tbl就是这样的一个结构。在分析ARP相关的初始化之前，我们先来看一下这个结构体：
    truct neigh_table
    {
        struct neigh_table  *next;
        int         family;
        int         entry_size;
        int         key_len;
        __u32       (*hash)(const void *pkey, const struct net_device *);
        int         (*constructor)(struct neighbour *);
        int         (*pconstructor)(struct pneigh_entry *);
        void        (*pdestructor)(struct pneigh_entry *);
        void        (*proxy_redo)(struct sk_buff *skb);
        char        *id;
        struct neigh_parms  parms;
        /* HACK. gc_* shoul follow parms without a gap! */
        int         gc_interval;
        int         gc_thresh1;
        int         gc_thresh2;
        int         gc_thresh3;
        unsigned long       last_flush;
        struct timer_list   gc_timer;
        struct timer_list   proxy_timer;
        struct sk_buff_head proxy_queue;
        atomic_t            entries;
        rwlock_t            lock;
        unsigned long       last_rand;
        kmem_cache_t        *kmem_cachep;         struct neigh_statistics *stats;         struct neighbour    **hash_buckets;         unsigned int        hash_mask;
        __u32               hash_rnd;
        unsigned int        hash_chain_gc;
        struct pneigh_entry **phash_buckets;
#ifdef CONFIG_PROC_FS
        struct proc_dir_entry   *pde;
#endif
    };
    entry_size是一个入口的长度，一个入口代表一个neighbour的信息,hash_buckets即为存放所有邻居的一个哈希数组，每一项对应一条neighbour链表。struct neighbour用于代表一个neighbour，包含了其信息，下面是其重要的一些成员：
    dev代表与这个邻居相连的网络设备；nud_state代表邻居的状态（未完成，无法访问，过时，失败）；ha表示邻居的mac地址；hh是以太网包的头部缓存；arp_queue是等待这个邻居的硬件地址的IP包队列；ops是对该neighbour节点操作的一套函数；primary_key是哈希表的主键，一般为IP地址。
    key_len是哈希表主键的长度，一般IP地址长度为4。
    几个函数分别为哈希函数，构造和析构函数。
    parms是ARP缓存的一些参数，包括ARP包传输时间，重发时间，队列长度和代理队列长度等等。
    ARP缓存有一个回收机制（garbage collection），上面以gc_开头的参数用来设置回收的频率和阀值等等。
    stats是一些关于邻居的统计信息。
    ARP初始化的第一个步是初始化ARP缓存myarp_tbl，并把它加到全局链表neigh_tables的表头，其实，系统中所有的neigh_table都放在这个表中。
    ptype_base是一个有16项的哈希数组，每种协议包类型都注册在这个数组中。arp包，其类型是ETH_P_ARP，其接收函数是 myarp_rcv。有了这个注册信息，当设备上收到一个网络包（packet）的时候，会分配一个sk_buff(skb)，将数据拷贝进这个缓冲区，然后调用netif_rx把skb放入等待队列（input_pkt_queue）中，并且产生一个软中断。当系统处理这个软中断的时候，会调用 net_rx_action，它根据网络包的类型，调用相应的接收函数来处理。如果是ARP包，则调用myarp_rcv。

    ARP缓存myarp_tbl是用于描述物理上相互连接的机器的信息的一个哈希表，关于这个缓存，我们前面作过分析。现在我们来看看，当主机收到一个需要本地接收的ARP请求时，如何向ARP缓存中更新一个ARP信息。
    当网络设备收到一个ARP数据包后，最终会调用到协议栈中的myarp_process处理函数，这个函数的处理会涉及到路由表的查询和更新。但我们现在的my_inet模块还没有真正完成路由表的初始化，所以略过其中很多细节，只关注ARP缓存的更新与查询。
    myarp_process通过调用__neigh_lookup函数更新ARP缓存，下面是该函数的定义：
    static inline struct neighbour * __neigh_lookup(struct neigh_table *tbl,
                                                    const void *pkey,
                                                    struct net_device *dev,
                                                    int creat)
    参数tbl是ARP缓存哈希表，传入全局变量myarp_tbl。pkey是哈希主键，传入发送端ip地址，在我们的实验环境中，是通过 172.16.48.1向172.16.48.11发送icmp回显请求包来触发myarp_process的执行，所以，pkey就是ip地址 172.16.48.1。dev是接收到该数据包的网络接口。create表示在缓存中不存在该机器的信息时，是否需要创建一个，我们现在的目的是更新，所以选择是，传入1。
    该函数首先调用neigh_lookup在ARP缓存中查找。neigh_lookup首先通过pkey,dev计算得到一个哈希值hash_val，再找到myarp_tbl中的一个链表myarp_tbl->hash_buckets[hash_val]，遍历该链表，如果能找到dev, pkey都相等的项，就是我们所要找的struct neighbour。在这里，还要更新myarp_tbl的成员stats中的一统计数据。
    显然，第一次收到ARP请求包，我们是找不到ARP缓存信息的，所以neigh_lookup返回NULL，__neigh_lookup判断 create值，如果不需要创建，就直接返回，如果需要，则调用neigh_create进行缓存信息的创建。
    neigh_create首先在内存中分配一个struct neighbour结构体。myarp_tbl的成员entries记录了该ARP缓存中已经存在了多少条缓存信息，如果数量超过了gc_thresh3 (1024)，或者数量超过了gc_thresh2(512)，并且距离上次缓存刷新时间还不到5秒，则需要先强制进行缓存垃圾回收，对于一些未使用的缓存信息进行清理。如果清理后，缓存数量还是超过gc_thresh3，则无法再进行创建，出错返回。对于新创建的neighbour，先给赋一些缺省值。
    然后调用myarp_tbl的构造函数，对新创建的 neighbour进一步初始化。具体的初始化步骤不再详述，我们可以从最后创建出来的neighbour的内容看到一些东西。
    接下来，由于新增加了缓存项，需要对myarp_tbl的大小进行调整，如果有需要，需要扩大其容量。
    最后，把新创建的neighbour添加到链表示，
    新创建的neighbour的内容应该是这样子的：
    struct neighbour
    {
        struct neighbour    *next       =原来的链表头;
        struct neigh_table  *tbl        =myarp_tbl;
        struct neigh_parms  *parms      =in_dev->arp_parms;
        struct net_device       *dev    =dev;
        unsigned long       used        =now;
        unsigned long       confirmed   =now - 60秒;
        unsigned long       updated     =now;
        __u8            flags;
        __u8            nud_state       =NUD_NONE;
        __u8            type            =RTN_LOCAL;
        __u8            dead            =1;
        atomic_t        probes;
        rwlock_t        lock;
        unsigned char       ha[(MAX_ADDR_LEN+sizeof(unsigned long)-1)&~(sizeof(unsigned long)-1)];
                                        //ha是mac地址，在后续的操作会给它赋上值。
        struct hh_cache     *hh         =NULL;
        atomic_t        refcnt          =1;
        int         (*output)(struct sk_buff *skb) = this->ops->connected_output;
        struct sk_buff_head arp_queue;
        struct timer_list   timer;
                            timer.function = neigh_timer_handler;
                            timer.data = this;
        struct neigh_ops    *ops        =&myarp_hh_ops;
        u8          primary_key[0]      =172.16.48.1（分配内存时，本身就加了4的);
    };

    协议栈在发送一个IP数据报之前，需要发送ARP请求是为了解析IP数据报的目的IP地址对应的硬件地址。ARP协议可以承载多种硬件类型和多种协议，这里我们只关注以太网上的IP协议，那ARP请求的目的就是为了解析邻居的以太网MAC地址。
    ARP请求/应答数据报总共有28字节，其具体格式如下所示(在以太网,IP协议的情况下)：
    字段含义：硬件类型 协议类型 硬件地址长度 协议地址长度 op
    字段长度：2              2             1                    1                    2
    字段含义：发送端以太网地址 发送端IP地址 目的以太网地址 目的IP地址
    字段长度：6                           4                      6                      4
    硬件类型，对于10Mbps以太网，其取值是ARPHRD_ETHER(值为1)，协议类型，对于IP协议来说，就是ETH_P_IP(0x0800),在上述条件限定下，硬件地址长度为6，协议地址长度为4，op的值为ARPOP_REQUEST(值为1，表示是ARP请求，或者ARPOP_REPLY(值为2，表示是ARP应答)。
    发送端以太网地址填发送接口的MAC地址，发送端IP地址填源IP地址(关于源IP地址的选取下文会有详细分析)，目的以太网地址，因为当前是ARP请求，所以填入以太网广播地址0xFF:0xFF:0xFF:0xFF:0xFF:0xFF，目的IP地址填入IP数据报的目的地址。
    这里，发送端IP地址的选取是一个可配置的选项，文件/proc/sys/net/ipv4/conf/设备名/arp_announce记录的是它的配置值，这是一个整型数值，取值范围为0-2，0表示只要待发送IP数据报的源地址为本地地址，就取该地址为发送端IP地址，这也是缺省配置；1表示若待发送IP数据报的源地址为本地地址，并且该IP地址与目的IP地址在同一子网内，则取该地址为发送端IP地址，否则从所有的本地地址中取一个与目的IP地址在同一子网内的地址；2表示完全忽略IP数据报中的地址，直接从所有本地输出网络接口中选取一个最为合适的发送端IP地址。配置级别越高，我们能够获得ARP回应的机率也就越大。
    构建好的ARP请求数据报通过函数dev_queue_xmit发送出去。

    在分析接收和处理ARP的回应数据之前，先复习一下协议栈接收网络数据的一个基本流程，网卡驱动程序会创建一个skb，并填入接收到的数据，并把这个skb传给协议栈的第一个接收函数netif_rx。softnet_data是一组全局变量，每个CPU拥有一个，它是一个结构体struct softnet_data，其定义如下：
    struct softnet_data
    {
        struct net_device   *output_queue;
        struct sk_buff_head input_pkt_queue;
        struct list_head    poll_list;
        struct sk_buff      *completion_queue;

        struct net_device   backlog_dev;
    };
    input_pkt_queue是一个接收队列，从网卡接收上来的skb一般会放在这里队列中待处理，这个队列的长度是有限制的，netdev_max_backlog就是该队列长度的上限，值为1000，如果队列中的skb数量已经达到1000，对于新收到的skb会直接丢弃。当新接收到一个skb，首先检查input_pkt_queue队列，如果队列长度未太到上限，且队列中已经存在skb，则直接把新收到的skb放在队列尾，返回成功。如果队列为空，则先调用函数netif_rx_schedule把接收工作启动起来，再把skb放入队列。
    netif_rx_schedule把softnet_data的成员backlog_dev连入poll_list，产生一个软中断NET_RX_SOFTIRQ。随后该中断处理函数net_rx_action被执行，net_rx_action检查softnet_data的poll_list队列，如果不空，则开始进行处理接收数据。
    net_rx_action的处理时间有一个限制，当该函数处理时间超过1个时钟滴嗒后，必须退出，重新产生一个NET_RX_SOFTIRQ，在下一个中断处理中继续处理。同时，net_rx_action的处理数据报的数量也有一个限制，netdev_budget是一个全局变量，值为300，net_rx_action每处理完300个数据报，也必须退出，在下一个中断处理中继续处理。
    softnet_data的成员backlog_dev在系统初始化时，被置了一些值，大体如下：
    set_bit( __LINK_STATE_START, &queue->backlog_dev.state );
    queue->backlog_dev.weight = weight_p;
    queue->backlog_dev.poll = process_backlog;
    atomic_set( &queue->backlog_dev.refcnt, 1 );
    weight_p是一个全局变量，值为64，process_backlog是net_rx_action调用，用于实际处理接收数据报的函数，变量queue->backlog_dev.quota在每次调用netif_rx_schedule时置为64(如果quota当前值小于0，则加上64)。process_backlog负责把数据报从input_pkt_queue中取出来，传给函数netif_receive_skb，函数处理时间不得超过一个时钟滴嗒，并且处理数据报数量存在限制，超过限制，返回-1，处理完所有数据报，返回0。
    netif_receive_skb对于每一个收到的skb，到已注册的协议类型中去匹配，先是匹配列表ptype_all，ptype_all中注册的struct packet_type表示要接收处理所有协议的数据报，struct packet_type是表示网络层协议类型(也即以太网首部中的帧类型字段)的一个数据结构，其定义如下：
    struct packet_type {
        __be16          type;       //协议类型
        struct net_device   *dev;   //指定的设备，为NULL表示接收所有设备上的数据报。
        int         (*func) (struct sk_buff *,
                        struct net_device *,
                        struct packet_type *,
                        struct net_device *); //接收处理函数
        void            *af_packet_priv;
        struct list_head    list;           //注册到ptype_all和ptype_base中用。
    };
    对于匹配到的struct packet_type结构(dev为NULL，或者dev等于skb的dev)，调用其func成员，把skb传递给它处理。
    匹配完ptype_all后，netif_receive_skb再匹配ptype_base数组中注册的协议类型，skb有一个成员protocol，其值即为以太网首部中的帧类型，在ptype_base中匹配到协议相同，并且dev符合要求的，调用其func成员即可。
    arp模块在初始化时，就往ptype_base中注册了一个协议类型ETH_P_ARP，其接收处理函数为arp_rcv，所以ARP应答最终到达函数arp_rcv。
    arp_rcv首先检查skb的长度是否到达一个ARP应答包的基本长度要求，再检查应答包中的硬件地址长度字段值是否跟设备的硬件地址长度一致，再检查数据报是否是本地接收，协议地址长度是否为4。检查无误后，克隆一个skb，交由arp_process处理。
    arp_process中处理所有收到的ARP数据报，这次，我们只关注收到的ARP回应包。ARP回应包中的发送端IP地址即为邻居的IP地址，我们以这个IP地址为主键到ARP缓存arp_tbl中去寻找这个邻居节点(hash_buckets成员)，因为在发送ARP请求之前，进行邻居绑定的时候，我们已经建立了一个未被解析的邻居，所以这次寻找肯定是成功的，如果没有找到，则直接放弃，不作处理。
    找到了这个邻居，我们就要用新的ARP回应包的内容刷新这个邻居的内容，但为了防止邻居被过度频繁刷新，引起抖动，只有距邻居上次刷新时间超过parms->locktime(缺省置为1秒)后才允许再次刷新，这是一个可配置的项，可通过修改文件/proc/sys/net/ipv4/neigh/设备名/locktime进行修改。
    实际的刷新工作在neigh_update函数中完成，新的邻居状态为NUD_REACHABLE，该函数中首先更新邻居的成员数据confirmed和updated为当前时间，然后删除邻居的定时器（定时器正在等待下一次重发ARP请求)，把定时器修改到距当前时间parms->reachable_time(初始设置为30秒，实际值在15-45秒之间随机变动)。并把新的MAC地址复制到邻居的成员ha中。
    邻居的成员hh是一个硬件头缓存，它是一个结构体struct hh_cache，其定义如下：
    struct hh_cache
    {
        struct hh_cache *hh_next;
        atomic_t    hh_refcnt;
        unsigned short  hh_type;
        int     hh_len;
        int     (*hh_output)(struct sk_buff *skb);
        rwlock_t    hh_lock;

#define HH_DATA_MOD 16
#define HH_DATA_OFF(__len) \
        (HH_DATA_MOD - (((__len - 1) & (HH_DATA_MOD - 1)) + 1))
#define HH_DATA_ALIGN(__len) \
        (((__len)+(HH_DATA_MOD-1))&~(HH_DATA_MOD - 1))
        unsigned long   hh_data[HH_DATA_ALIGN(LL_MAX_HEADER) / sizeof(long)];
    };
    邻居的成员hh是一个链表，每种协议对应一个节点，协议类型记录在hh_type中，我们现在只处理IP协议，所以这个链表中总是只有一项，hh_data是缓存的硬件头（对于以太网来说，就是以太网头)，hh_output是输出函数，有了hh，下次再发送数据报，就不需要重新构建以太网头了。当ARP解析完成后，需要更新hh缓冲。
    邻居的成员output用于输出IP数据报，目前它指向neigh_resolve_output，这里，需要把它改为neigh_connected_output，即下次发送数据报，不再需要解析邻居的MAC地址了。最后把邻居的arp_queue队列上等待发送的skb全部通过neigh_connect_output发送出去。到这里，ARP解析算是全部完成了。
    前面还留有一个问题，就是邻居的定时器被再次启动了，此时邻居是处于NUD_REACHABLE状态的，下面再来看邻居定时器的超时处理函数neigh_timer_handler，处于NUD_REACHABLE状态的邻居，如果距上次被证实(收到邻居的ARP回应包，确认这个邻居还是有效的)时间超过了parms->reachable_time，且距上次被使用时间不足parms->delay_probe_time(缺省设置为5秒)，则邻居进入NUD_DELAY(延迟)状态，如果距上次使用时间也超过了5秒，则进入NUD_STALE(过期)状态，进入延迟和过期状态的邻居，其成员output重新指向neigh_resolve_output。
    进入延迟状态的邻居，在下一个邻居超时处理中，如果发现邻居最近又被证实过了，且距上次证实时间不足5秒，则恢复为NUD_REACHABLE状态，否则进入NUD_PROBE(探测)状态，NUD_PROBE最多允许有3次尝试机会(ucast_probes)。具体流程同NUD_INCOMPLETE状态。而进入NUD_STALE状态的邻居，只有下次在向它发送数据报时，才会恢复到NUD_DELAY状态。
    当主机收到一个来自邻居的ARP请求数据报时，也会去搜索arp_tbl缓存，找不到则创建一个新的邻居。然后把来自请求数据报的邻居的mac地址填入，邻居被直接置成NUD_STALE(过期)状态。如果未被使用，则在60秒(parms->gc_staletime)后被定期回收的定时器处理函数回收掉。

假设源文件按如下目录存放，如图1所示，运用autoconf和automake生成makefile文件。

假设src是我们源文件目录，include目录存放其他库的头文件，lib目录存放用到的库文件，然后开始按模块存放，每个模块都有一个对应的目录，模块下再分子模块，如apple、orange。每个子目录下又分core，include，shell三个目录，其中core和shell目录存放.c文件，include的存放.h文件，其他类似。

样例程序功能：基于多线程的数据读写保护（联系作者获取整个autoconf和automake生成的Makefile工程和源码，E-mail：normalnotebook@126.com）。

回页首

工具简介

所必须的软件：autoconf/automake/m4/perl/libtool（其中libtool非必须）。

autoconf是一个用于生成可以自动地配置软件源码包，用以适应多种UNIX类系统的shell脚本工具，其中autoconf需要用到 m4，便于生成脚本。automake是一个从Makefile.am文件自动生成Makefile.in的工具。为了生成Makefile.in，automake还需用到perl，由于automake创建的发布完全遵循GNU标准，所以在创建中不需要perl。libtool是一款方便生成各种程序库的工具。

目前automake支持三种目录层次：flat、shallow和deep。

1) flat指的是所有文件都位于同一个目录中。

就是所有源文件、头文件以及其他库文件都位于当前目录中，且没有子目录。Termutils就是这一类。

2) shallow指的是主要的源代码都储存在顶层目录，其他各个部分则储存在子目录中。

就是主要源文件在当前目录中，而其它一些实现各部分功能的源文件位于各自不同的目录。automake本身就是这一类。

3) deep指的是所有源代码都被储存在子目录中；顶层目录主要包含配置信息。

就是所有源文件及自己写的头文件位于当前目录的一个子目录中，而当前目录里没有任何源文件。 GNU cpio和GNU tar就是这一类。

flat类型是最简单的，deep类型是最复杂的。不难看出，我们的模拟需求正是基于第三类deep型，也就是说我们要做挑战性的事情：)。注：我们的测试程序是基于多线程的简单程序。

回页首

生成 Makefile 的来龙去脉

首先进入 project 目录，在该目录下运行一系列命令，创建和修改几个文件，就可以生成符合该平台的Makefile文件，操作过程如下：

1) 运行autoscan命令

2) 将configure.scan 文件重命名为configure.in，并修改configure.in文件

3) 在project目录下新建Makefile.am文件，并在core和shell目录下也新建makefile.am文件

4) 在project目录下新建NEWS、 README、 ChangeLog 、AUTHORS文件

5) 将/usr/share/automake-1.X/目录下的depcomp和complie文件拷贝到本目录下

6) 运行aclocal命令

7) 运行autoconf命令

8) 运行automake -a命令

9) 运行./confiugre脚本

可以通过图2看出产生Makefile的流程，如图所示：

回页首

Configure.in的八股文

当我们利用autoscan工具生成confiugre.scan文件时，我们需要将confiugre.scan重命名为confiugre.in文件。confiugre.in调用一系列autoconf宏来测试程序需要的或用到的特性是否存在，以及这些特性的功能。

下面我们就来目睹一下confiugre.scan的庐山真面目：

# Process this file with autoconf to produce a configure script.AC_PREREQ(2.59)AC_INIT(FULL-PACKAGE-NAME, VERSION, BUG-REPORT-ADDRESS)AC_CONFIG_SRCDIR([config.h.in])AC_CONFIG_HEADER([config.h])# Checks for programs.AC_PROG_CC# Checks for libraries.# FIXME: Replace `main' with a function in `-lpthread':AC_CHECK_LIB([pthread], [main])# Checks for header files.# Checks for typedefs, structures, and compiler characteristics.# Checks for library functions.AC_OUTPUT

每个configure.scan文件都是以AC_INIT开头，以AC_OUTPUT结束。我们不难从文件中看出confiugre.in文件的一般布局：

AC_INIT 测试程序 测试函数库 测试头文件 测试类型定义 测试结构 测试编译器特性 测试库函数 测试系统调用AC_OUTPUT

上面的调用次序只是建议性质的，但我们还是强烈建议不要随意改变对宏调用的次序。

现在就开始修改该文件：

$mv configure.scan configure.in$vim configure.in

修改后的结果如下：

		#                                -*- Autoconf -*-# Process this file with autoconf to produce a configure script.AC_PREREQ(2.59)AC_INIT(test, 1.0, normalnotebook@126.com)AC_CONFIG_SRCDIR([src/ModuleA/apple/core/test.c])AM_CONFIG_HEADER(config.h)AM_INIT_AUTOMAKE(test,1.0)# Checks for programs.AC_PROG_CC# Checks for libraries.# FIXME: Replace `main' with a function in `-lpthread':AC_CHECK_LIB([pthread], [pthread_rwlock_init])AC_PROG_RANLIB# Checks for header files.# Checks for typedefs, structures, and compiler characteristics.# Checks for library functions.AC_OUTPUT([Makefile		src/lib/Makefile		src/ModuleA/apple/core/Makefile		src/ModuleA/apple/shell/Makefile		])		

其中要将AC_CONFIG_HEADER([config.h])修改为：AM_CONFIG_HEADER(config.h), 并加入AM_INIT_AUTOMAKE(test,1.0)。由于我们的测试程序是基于多线程的程序，所以要加入AC_PROG_RANLIB，不然运行automake命令时会出错。在AC_OUTPUT输入要创建的Makefile文件名。

由于我们在程序中使用了读写锁，所以需要对库文件进行检查，即AC_CHECK_LIB([pthread], [main])，该宏的含义如下：

其中，LIBS是link的一个选项，详细请参看后续的Makefile文件。由于我们在程序中使用了读写锁，所以我们测试pthread库中是否存在pthread_rwlock_init函数。

由于我们是基于deep类型来创建makefile文件，所以我们需要在四处创建Makefile文件。即：project目录下，lib目录下，core和shell目录下。

Autoconf提供了很多内置宏来做相关的检测，限于篇幅关系，我们在这里对其他宏不做详细的解释，具体请参看参考文献1和参考文献2，也可参看autoconf信息页。

回页首

实战Makefile.am

Makefile.am是一种比Makefile更高层次的规则。只需指定要生成什么目标，它由什么源文件生成，要安装到什么目录等构成。

表一列出了可执行文件、静态库、头文件和数据文件，四种书写Makefile.am文件个一般格式。

对于可执行文件和静态库类型，如果只想编译，不想安装到系统中，可以用noinst_PROGRAMS代替bin_PROGRAMS，noinst_LIBRARIES代替lib_LIBRARIES。

Makefile.am还提供了一些全局变量供所有的目标体使用：

在Makefile.am中尽量使用相对路径，系统预定义了两个基本路径：

在上文中我们提到过安装路径，automake设置了默认的安装路径：

1) 标准安装路径

默认安装路径为：$(prefix) = /usr/local，可以通过./configure --prefix=<new_path>的方法来覆盖。

其它的预定义目录还包括：bindir = $(prefix)/bin, libdir = $(prefix)/lib, datadir = $(prefix)/share, sysconfdir = $(prefix)/etc等等。

2) 定义一个新的安装路径

比如test, 可定义testdir = $(prefix)/test, 然后test_DATA =test1 test2，则test1，test2会作为数据文件安装到$(prefix)/ /test目录下。

我们首先需要在工程顶层目录下（即project/）创建一个Makefile.am来指明包含的子目录：

SUBDIRS=src/lib src/ModuleA/apple/shell src/ModuleA/apple/core CURRENTPATH=$(shell /bin/pwd)INCLUDES=-I$(CURRENTPATH)/src/include -I$(CURRENTPATH)/src/ModuleA/apple/include export INCLUDES

由于每个源文件都会用到相同的头文件，所以我们在最顶层的Makefile.am中包含了编译源文件时所用到的头文件，并导出，见蓝色部分代码。

我们将lib目录下的swap.c文件编译成libswap.a文件，被apple/shell/apple.c文件调用，那么lib目录下的Makefile.am如下所示：

noinst_LIBRARIES=libswap.alibswap_a_SOURCES=swap.cINCLUDES=-I$(top_srcdir)/src/includ

细心的读者可能就会问：怎么表1中给出的是bin_LIBRARIES，而这里是noinst_LIBRARIES？这是因为如果只想编译，而不想安装到系统中，就用noinst_LIBRARIES代替bin_LIBRARIES，对于可执行文件就用noinst_PROGRAMS代替bin_PROGRAMS。对于安装的情况，库将会安装到$(prefix)/lib目录下，可执行文件将会安装到${prefix}/bin。如果想安装该库，则Makefile.am示例如下：

bin_LIBRARIES=libswap.alibswap_a_SOURCES=swap.cINCLUDES=-I$(top_srcdir)/src/includeswapincludedir=$(includedir)/swapswapinclude_HEADERS=$(top_srcdir)/src/include/swap.h

最后两行的意思是将swap.h安装到${prefix}/include /swap目录下。

接下来，对于可执行文件类型的情况，我们将讨论如何写Makefile.am？对于编译apple/core目录下的文件，我们写成的Makefile.am如下所示：

noinst_PROGRAMS=testtest_SOURCES=test.c test_LDADD=$(top_srcdir)/src/ModuleA/apple/shell/apple.o $(top_srcdir)/src/lib/libswap.a test_LDFLAGS=-D_GNU_SOURCEDEFS+=-D_GNU_SOURCE#LIBS=-lpthread

由于我们的test.c文件在链接时，需要apple.o和libswap.a文件，所以我们需要在test_LDADD中包含这两个文件。对于Linux下的信号量/读写锁文件进行编译，需要在编译选项中指明-D_GNU_SOURCE。所以在test_LDFLAGS中指明。而test_LDFLAGS只是链接时的选项，编译时同样需要指明该选项，所以需要DEFS来指明编译选项，由于DEFS已经有初始值，所以这里用+=的形式指明。从这里可以看出，Makefile.am中的语法与Makefile的语法一致，也可以采用条件表达式。如果你的程序还包含其他的库，除了用AC_CHECK_LIB宏来指明外，还可以用LIBS来指明。

如果你只想编译某一个文件，那么Makefile.am如何写呢？这个文件也很简单，写法跟可执行文件的差不多，如下例所示：

noinst_PROGRAMS=appleapple_SOURCES=apple.cDEFS+=-D_GNU_SOURCE

我们这里只是欺骗automake，假装要生成apple文件，让它为我们生成依赖关系和执行命令。所以当你运行完automake命令后，然后修改apple/shell/下的Makefile.in文件，直接将LINK语句删除，即：

…….clean-noinstPROGRAMS:	-test -z "$(noinst_PROGRAMS)" || rm -f $(noinst_PROGRAMS)apple$(EXEEXT): $(apple_OBJECTS) $(apple_DEPENDENCIES) 	@rm -f apple$(EXEEXT)#$(LINK) $(apple_LDFLAGS) $(apple_OBJECTS) $(apple_LDADD) $(LIBS)…….

通过上述处理，就可以达到我们的目的。从图1中不难看出为什么要修改Makefile.in的原因，而不是修改其他的文件。

回页首

下载

让我们先从高级的视角来查看 Linux 引导过程，这样就可以看到整个过程的全貌了。然后将回顾一下在各个步骤到底发生了什么。在整个过程中，参考一下内核源代码可以帮助我们更好地了解内核源代码树，并在以后对其进行深入分析。

概述

图 1 是我们在 20,000 英尺的高度看到的视图。

当系统首次引导时，或系统被重置时，处理器会执行一个位于已知位置处的代码。在个人计算机（PC）中，这个位置在基本输入/输出系统（BIOS）中，它保存在主板上的闪存中。嵌入式系统中的中央处理单元（CPU）会调用这个重置向量来启动一个位于闪存/ROM 中的已知地址处的程序。在这两种情况下，结果都是相同的。因为 PC 提供了很多灵活性，BIOS 必须确定要使用哪个设备来引导系统。稍后我们将详细介绍这个过程。

当找到一个引导设备之后，第一阶段的引导加载程序就被装入 RAM 并执行。这个引导加载程序在大小上小于 512 字节（一个扇区），其作用是加载第二阶段的引导加载程序。

当第二阶段的引导加载程序被装入 RAM 并执行时，通常会显示一个动画屏幕，并将 Linux 和一个可选的初始 RAM 磁盘（临时根文件系统）加载到内存中。在加载映像时，第二阶段的引导加载程序就会将控制权交给内核映像，然后内核就可以进行解压和初始化了。在这个阶段中，第二阶段的引导加载程序会检测系统硬件、枚举系统链接的硬件设备、挂载根设备，然后加载必要的内核模块。完成这些操作之后启动第一个用户空间程序（init），并执行高级系统初始化工作。

这就是 Linux 引导的整个过程。现在让我们深入挖掘一下这个过程，并深入研究一下 Linux 引导过程的一些详细信息。

回页首

系统启动

系统启动阶段依赖于引导 Linux 系统上的硬件。在嵌入式平台中，当系统加电或重置时，会使用一个启动环境。这方面的例子包括 U-Boot、RedBoot 和 Lucent 的 MicroMonitor。嵌入式平台通常都是与引导监视器搭配销售的。这些程序位于目标硬件上的闪存中的某一段特殊区域，它们提供了将 Linux 内核映像下载到闪存并继续执行的方法。除了可以存储并引导 Linux 映像之外，这些引导监视器还执行一定级别的系统测试和硬件初始化过程。在嵌入式平台中，这些引导监视器通常会涉及第一阶段和第二阶段的引导加载程序。

提取 MBR 的信息 要查看 MBR 的内容，请使用下面的命令： # dd if=/dev/hda of=mbr.bin bs=512 count=1 # od -xa mbr.bin 这个 dd 命令需要以 root 用户的身份运行，它从 /dev/hda（第一个 IDE 盘） 上读取前 512 个字节的内容，并将其写入 mbr.bin 文件中。od 命令会以十六进制和 ASCII 码格式打印这个二进制文件的内容。

在 PC 中，引导 Linux 是从 BIOS 中的地址 0xFFFF0 处开始的。BIOS 的第一个步骤是加电自检（POST）。POST 的工作是对硬件进行检测。BIOS 的第二个步骤是进行本地设备的枚举和初始化。

给定 BIOS 功能的不同用法之后，BIOS 由两部分组成：POST 代码和运行时服务。当 POST 完成之后，它被从内存中清理了出来，但是 BIOS 运行时服务依然保留在内存中，目标操作系统可以使用这些服务。

要引导一个操作系统，BIOS 运行时会按照 CMOS 的设置定义的顺序来搜索处于活动状态并且可以引导的设备。引导设备可以是软盘、CD-ROM、硬盘上的某个分区、网络上的某个设备，甚至是 USB 闪存。

通常，Linux 都是从硬盘上引导的，其中主引导记录（MBR）中包含主引导加载程序。MBR 是一个 512 字节大小的扇区，位于磁盘上的第一个扇区中（0 道 0 柱面 1 扇区）。当 MBR 被加载到 RAM 中之后，BIOS 就会将控制权交给 MBR。

回页首

第一阶段引导加载程序

MBR 中的主引导加载程序是一个 512 字节大小的映像，其中包含程序代码和一个小分区表（参见图 2）。前 446 个字节是主引导加载程序，其中包含可执行代码和错误消息文本。接下来的 64 个字节是分区表，其中包含 4 个分区的记录（每个记录的大小是 16 个字节）。MBR 以两个特殊数字的字节（0xAA55）结束。这个数字会用来进行 MBR 的有效性检查。

主引导加载程序的工作是查找并加载次引导加载程序（第二阶段）。它是通过在分区表中查找一个活动分区来实现这种功能的。当找到一个活动分区时，它会扫描分区表中的其他分区，以确保它们都不是活动的。当这个过程验证完成之后，就将活动分区的引导记录从这个设备中读入 RAM 中并执行它。

回页首

第二阶段引导加载程序

次引导加载程序（第二阶段引导加载程序）可以更形象地称为内核加载程序。这个阶段的任务是加载 Linux 内核和可选的初始 RAM 磁盘。

GRUB 阶段引导加载程序 /boot/grub 目录中包含了 stage1、stage1.5 和 stage2 引导加载程序，以及很多其他加载程序（例如，CR-ROM 使用的是 iso9660_stage_1_5）。

在 x86 PC 环境中，第一阶段和第二阶段的引导加载程序一起称为 Linux Loader（LILO）或 GRand Unified Bootloader（GRUB）。由于 LILO 有一些缺点，而 GRUB 克服了这些缺点，因此下面让我们就来看一下 GRUB。（有关 GRUB、LILO 和相关主题的更多内容，请参阅本文后面的 参考资料 部分的内容。）

关于 GRUB，很好的一件事情是它包含了有关 Linux 文件系统的知识。GRUB 不像 LILO 一样使用裸扇区，而是可以从 ext2 或 ext3 文件系统中加载 Linux 内核。它是通过将两阶段的引导加载程序转换成三阶段的引导加载程序来实现这项功能的。阶段 1 （MBR）引导了一个阶段 1.5 的引导加载程序，它可以理解包含 Linux 内核映像的特殊文件系统。这方面的例子包括 reiserfs_stage1_5（要从 Reiser 日志文件系统上进行加载）或 e2fs_stage1_5（要从 ext2 或 ext3 文件系统上进行加载）。当阶段 1.5 的引导加载程序被加载并运行时，阶段 2 的引导加载程序就可以进行加载了。

当阶段 2 加载之后，GRUB 就可以在请求时显示可用内核列表（在 /etc/grub.conf 中进行定义，同时还有几个软符号链接 /etc/grub/menu.lst 和 /etc/grub.conf）。我们可以选择内核甚至修改附加内核参数。另外，我们也可以使用一个命令行的 shell 对引导过程进行高级手工控制。

将第二阶段的引导加载程序加载到内存中之后，就可以对文件系统进行查询了，并将默认的内核映像和 initrd 映像加载到内存中。当这些映像文件准备好之后，阶段 2 的引导加载程序就可以调用内核映像了。

回页首

内核

GRUB 中的手工引导 在 GRUB 命令行中，我们可以使用 initrd 映像引导一个特定的内核，方法如下： grub> kernel /bzImage-2.6.14.2 [Linux-bzImage, setup=0x1400, size=0x29672e]grub> initrd /initrd-2.6.14.2.img [Linux-initrd @ 0x5f13000, 0xcc199 bytes]grub> bootUncompressing Linux... Ok, booting the kernel. 如果您不知道要引导的内核的名称，只需使用斜线（/）然后按下 Tab 键即可。GRUB 会显示内核和 initrd 映像列表。

当内核映像被加载到内存中，并且阶段 2 的引导加载程序释放控制权之后，内核阶段就开始了。内核映像并不是一个可执行的内核，而是一个压缩过的内核映像。通常它是一个 zImage（压缩映像，小于 512KB）或一个 bzImage（较大的压缩映像，大于 512KB），它是提前使用 zlib 进行压缩过的。在这个内核映像前面是一个例程，它实现少量硬件设置，并对内核映像中包含的内核进行解压，然后将其放入高端内存中，如果有初始 RAM 磁盘映像，就会将它移动到内存中，并标明以后使用。然后该例程会调用内核，并开始启动内核引导的过程。

当 bzImage（用于 i386 映像）被调用时，我们从 ./arch/i386/boot/head.S 的 start 汇编例程开始执行（主要流程图请参看图 3）。这个例程会执行一些基本的硬件设置，并调用 ./arch/i386/boot/compressed/head.S 中的 startup_32 例程。此例程会设置一个基本的环境（堆栈等），并清除 Block Started by Symbol（BSS）。然后调用一个叫做 decompress_kernel 的 C 函数（在 ./arch/i386/boot/compressed/misc.c 中）来解压内核。当内核被解压到内存中之后，就可以调用它了。这是另外一个 startup_32 函数，但是这个函数在 ./arch/i386/kernel/head.S 中。

在这个新的 startup_32 函数（也称为清除程序或进程 0）中，会对页表进行初始化，并启用内存分页功能。然后会为任何可选的浮点单元（FPU）检测 CPU 的类型，并将其存储起来供以后使用。然后调用 start_kernel 函数（在 init/main.c 中），它会将您带入与体系结构无关的 Linux 内核部分。实际上，这就是 Linux 内核的 main 函数。

通过调用 start_kernel，会调用一系列初始化函数来设置中断，执行进一步的内存配置，并加载初始 RAM 磁盘。最后，要调用 kernel_thread（在 arch/i386/kernel/process.c 中）来启动 init 函数，这是第一个用户空间进程（user-space process）。最后，启动空任务，现在调度器就可以接管控制权了（在调用 cpu_idle 之后）。通过启用中断，抢占式的调度器就可以周期性地接管控制权，从而提供多任务处理能力。

在内核引导过程中，初始 RAM 磁盘（initrd）是由阶段 2 引导加载程序加载到内存中的，它会被复制到 RAM 中并挂载到系统上。这个 initrd 会作为 RAM 中的临时根文件系统使用，并允许内核在没有挂载任何物理磁盘的情况下完整地实现引导。由于与外围设备进行交互所需要的模块可能是 initrd 的一部分，因此内核可以非常小，但是仍然需要支持大量可能的硬件配置。在内核引导之后，就可以正式装备根文件系统了（通过 pivot_root）：此时会将 initrd 根文件系统卸载掉，并挂载真正的根文件系统。

decompress_kernel 输出 函数 decompress_kernel 就是显示我们通常看到的解压消息的地方： Uncompressing Linux... Ok, booting the kernel.

initrd 函数让我们可以创建一个小型的 Linux 内核，其中包括作为可加载模块编译的驱动程序。这些可加载的模块为内核提供了访问磁盘和磁盘上的文件系统的方法，并为其他硬件提供了驱动程序。由于根文件系统是磁盘上的一个文件系统，因此 initrd 函数会提供一种启动方法来获得对磁盘的访问，并挂载真正的根文件系统。在一个没有硬盘的嵌入式环境中，initrd 可以是最终的根文件系统，或者也可以通过网络文件系统（NFS）来挂载最终的根文件系统。

回页首

Init

当内核被引导并进行初始化之后，内核就可以启动自己的第一个用户空间应用程序了。这是第一个调用的使用标准 C 库编译的程序。在此之前，还没有执行任何标准的 C 应用程序。

在桌面 Linux 系统上，第一个启动的程序通常是 /sbin/init。但是这不是一定的。很少有嵌入式系统会需要使用 init 所提供的丰富初始化功能（这是通过 /etc/inittab 进行配置的）。在很多情况下，我们可以调用一个简单的 shell 脚本来启动必需的嵌入式应用程序。

回页首

结束语

与 Linux 本身非常类似，Linux 的引导过程也非常灵活，可以支持众多的处理器和硬件平台。最初，加载引导加载程序提供了一种简单的方法，不用任何花架子就可以引导 Linux。LILO 引导加载程序对引导能力进行了扩充，但是它却缺少文件系统的感知能力。最新一代的引导加载程序，例如 GRUB，允许 Linux 从一些文件系统（从 Minix 到 Reise）上进行引导。

    如果USB通信不再需要，那么设备的内核模块便调用sa1100_usb_stop()，然后是 sa1100_usb_close()，关闭SA1100的USB控制器。

   StrongARM USB控制器支持数据传输作业的bulk-in 和bulk-out。在从USB主机接收数据包时，内核模块调用sa1100_usb_recv()，把数据缓冲区和回调函数地址传递给它。然后内核的底层USB设备控制代码对来自主机的bulk-out包进行检索，把内容放于缓冲区中，并调用回调函数。

   回调函数必须从接收缓冲区提取数据并保存于其它位置或者把缓冲区空间加到一个队列中，为下一个数据包的接收分配新的缓冲区。而后回调函数二次调用sa1100_usb_recv()，在需要时进行下一个数据包的接收。过程与对USB主机的数据传输相类似。在聚集起一帧的数据量后，内核模块将数据的地址、长度和回调地址传递给 sa1100_usb_send()。传输完成时，内核调用回调函数。

   主机

   主机端USB驱动的几个例子在主流的Linux版本以及 Linux内核档案组织分配的原始内核源中都有提供。用于Handspring Visor(drivers/usb/serial/visor.c)的模块是编写较为简洁易懂的模块之一，作为USB主机端模块的模板 (drivers/usb/usb-skeleton.c)使用。

   高速串行

   对于大多数实际应用来说， 可以把USB总线当作一种高速串行端口考虑。如此在某些类型的嵌入式设备和应用中对它进行原型模拟是有意义的。StrongARM处理器的Linux内核提供现成的USB设备驱动专工于此，称作usb-char。

   在希望与USB主机通信时，Linux USB设备应用程序只是打开对其usb-char设备节点(字符型，最大10，最小240)的连接，然后开始读写数据即可。read()和 write()操作将一直返回错误值直到USB主机连上为止。一旦连接建立和枚举完成，便开始通信，就像USB是一种点对点串行端口一样。

   由于这种USB数据传递方法十分直接且实用，因此usb-char设备得到高效使用。它还为其它USB通信方法的实现提供了重要的参照基准。

   usb-char的实际动作从usbc_open()功能开始，部分内容示于列表1中。

   列表1：打开USB上的串行连接

   static int usbc_open(struct inode *pInode, struct file *pFile)

   {

   int retval = 0;

   /* start usb core */

   sa1100_usb_open(_sb-char?;

   /* allocate memory for in-transit USB packets */

   tx_buf = (char*) kmalloc(TX_PACKET_SIZE, GFP_KERNEL | GFP_DMA);

   packet_buffer = (char*) kmalloc(RX_PACKET_SIZE, GFP_KERNEL | GFP_DMA);

   /* allocate memory for the receive buffer; the contents of this

   buffer are provided during read() */

   rx_ring.buf = (char*) kmalloc(RBUF_SIZE, GFP_KERNEL);

   /* set up USB descriptors */

   twiddle_descriptors();

   /* enable USB i/o */

   sa1100_usb_start();

   /* set up to receive a packet */

   kick_start_rx();

   return 0;

   twiddle_descriptors ()功能建立起设备的USB描述符。在描述符全部建起后，准备从USB主机枚举并接收一个数据帧。kick_start_rx()所需的代码大多数情况下只是一种对sa1100_usb_recv() 的调用以建立回调而已。当USB主机发送数据包时，设备的内核通过回调调用rx_done_callback_packet_buffer()函数，把数据包的内容移入usb-char 设备点上由read()返回的FIFO队列。

   主机

   对于运行Linux的USB主机，usb-char相应的USB主机模块称为usbserial模块。大多数Linux版本都包括Usbserial模块，尽管通常不是自动装入。在USB与设备的连接建立之前，usbserial 由modprobe 或 insmod载入。

   一旦USB设备开始枚举，主机上的应用程序便用usbserial设备点(字符型，最大188，最小0以上)之一与设备进行通信。这些节点通常命名为/dev/ttyUSBn。Usbserial模块在内核报文日志记录中报告它把哪个节点指定给USB设备使用：

   usbserial.c: 通用转换器删除

   usbserial.c: 通用转换器当前连到ttyUSB0上。连接建立后，USB主机上的应用程序便通过读写指定的节点与USB设备进行通信。

   Linux 主机上usbserial模块的一种替代选择是一种称作libusb(libusb.sourceforge.net)的库。这种库使用低层内核系统调用进行USB数据传输，而不是通过usbserial模块，在某种程度上跨Linux内核版本建立和使用时更方便。Libusb库还提供大量有用的调试功能，这一点在对运行在USB链路上的复杂通信协议进行除错时有帮助。用libusb与采用usb-char的USB设备进行通信时，Linux主机应用程序使用usb_open()函数建立与该设备的连接。然后应用程序使用usb_bulk_read()和usb_bulk_write()与设备交换数据。

   USB上的以太网

   另一种选择是把USB作为一种以太网络来对待。Linux具有在主机和设备端均可实现这种功能的模块。由于iPAQ硬件既没有可接入的串行端口也没有一种专用的网络接口，因此，iPAQ 的Linux内核专门采用这种通信策略，在StrongARM的Linux内核中，usb-eth模块(arch/arm/mach- sa1100/usb-eth.c)对用USB作物理媒介的虚构以太网设备进行仿真。一旦创建后，这一网络界面便被指定一个IP地址，否则作为通常的以太网硬件对待。一旦USB主机连上后，usb-eth模块便能使USB设备“看到” Internet(如果存在Internet的话)，ping测其它IP地址，甚至“谈论”DHCP, HTTP, NFS, telnet, 和e-mail。简言之，任何在实际的以太网界面上运行的应用将不折不扣地在usb-eth接口上得到实现，因为它们不能分辨出其正在使用的不是实在的以太网硬件。

   主机

   在Linux主机上，相应的Ethernet-over-USB内核模块称为usbnet。当usbnet模块得到安装且设备的USB连接建立完成时，usbnet模块便针对主机端内核及用户应用创建一个与实际硬件酷似的虚构以太网界面，主机端应用程序通过运行设备IP地址 ping测，可以检查USB设备的存在。如果ping测成功，设备便加上了。

   结语

   Linux不再只是USB主机使用，当今它也是USB设备的合适选择，Linux 下的USB通信是非常灵活和易用的。

1. 系统结构定义

以下定义的结构，要保证长度是32bit的整数，也就是4bytes对齐，在自己添加成员的时候尤其小心。

struct cb 字面理解为control block；

struct nic 网卡的基本信息，该结构是针对单个网卡的，而不是针对网卡驱动整个系统；
 

2. 子例程分析

staticinlinevoid e100_enable_irq(struct nic *nic)

{

    unsignedlong flags;

    spin_lock_irqsave(&nic->cmd_lock, flags);

    writeb(irq_mask_none, &nic->csr->scb.cmd_hi);

    spin_unlock_irqrestore(&nic->cmd_lock, flags);

    e100_write_flush(nic);

}

staticinlinevoid e100_disable_irq(struct nic *nic)

{

    unsignedlong flags;

    spin_lock_irqsave(&nic->cmd_lock, flags);

    writeb(irq_mask_all, &nic->csr->scb.cmd_hi);

    spin_unlock_irqrestore(&nic->cmd_lock, flags);

    e100_write_flush(nic);

}

这两个函数看意思就是把nic指向的网卡的irq打开于关闭，在写寄存器的时候要spin_lock_irq；

e100_write_flush是把内容立即刷新，这里的做法比较简单，就是把pci的总线读一下，这样write的过程就被迫完成了。

3. 总体分析

初始化过程：

staticint e100_hw_init(struct nic *nic)

{

    int err;

    e100_hw_reset(nic); // 作芯片的复位

    DPRINTK(HW, ERR, "e100_hw_init\n");

// 如果是中断期间，返回错误

    if(!in_interrupt() && (err = e100_self_test(nic)))

    return err;

    if((err = e100_phy_init(nic))) // 芯片的初始化，以及后面执行了各种命令

        return err;

    if((err = e100_exec_cmd(nic, cuc_load_base, 0)))

        return err;

    if((err = e100_exec_cmd(nic, ruc_load_base, 0)))

        return err;

    if((err = e100_exec_cb(nic, NULL, e100_load_ucode)))

        return err;

    if((err = e100_exec_cb(nic, NULL, e100_configure)))

        return err;

    if((err = e100_exec_cb(nic, NULL, e100_setup_iaaddr)))

        return err;

    if((err = e100_exec_cmd(nic, cuc_dump_addr,

                nic->dma_addr + offsetof(struct mem, stats))))

        return err;

    if((err = e100_exec_cmd(nic, cuc_dump_reset, 0)))

        return err;

    e100_disable_irq(nic); // 关闭中断

}

staticvoid e100_watchdog(unsignedlong data)

{

…

// 根据MII的监测工具进行监测，如果发现有网卡动作，则调整统计信息，把网卡设置成up/down状态

    mii_ethtool_gset(&nic->mii, &cmd);

    if(mii_link_ok(&nic->mii) && !netif_carrier_ok(nic->netdev)) {

        DPRINTK(LINK, INFO, "link up, %sMbps, %s-duplex\n",

                cmd.speed == SPEED_100 ? "100" : "10",

                cmd.duplex == DUPLEX_FULL ? "full" : "half");

    } elseif(!mii_l    ink_ok(&nic->mii) && netif_carrier_ok(nic->netdev)) {

        DPRINTK(LINK, INFO, "link down\n");

}

    mii_check_link(&nic->mii);

…

// 最后，watch_dog不是做一次，所以做完了这次，要用mod_timer启动下一次检查

    mod_timer(&nic->watchdog, jiffies + E100_WATCHDOG_PERIOD);

}

发包过程：

staticinlineint e100_tx_clean(struct nic *nic) // 对发包队列进行清理

{

    struct cb *cb;

    int tx_cleaned = 0;

    spin_lock(&nic->cb_lock); // 要上锁，其实我觉得这里会影响速度；但是100M网卡，影响也不大，对1000M网卡，这样肯定不行

    DPRINTK(TX_DONE, DEBUG, "cb->status = 0x%04X\n",

    nic->cb_to_clean->status);

/* Clean CBs marked complete */

    for(cb = nic->cb_to_clean;

            cb->status & cpu_to_le16(cb_complete); // 把CPU字节转成机器字节

            cb = nic->cb_to_clean = cb->next) {

        if(likely(cb->skb != NULL)) {

            nic->net_stats.tx_packets++;

            nic->net_stats.tx_bytes += cb->skb->len;

            pci_unmap_single( nic->pdev, // 解除PCI通道的DMA映射

                    le32_to_cpu(cb->u.tcb.tbd.buf_addr),

                    le16_to_cpu(cb->u.tcb.tbd.size),

                    PCI_DMA_TODEVICE);

            dev_kfree_skb_any(cb->skb); // 才可以释放skb

            cb->skb = NULL; // 把指针设置为空，要用这个作判断，所以还是C++好

            tx_cleaned = 1;

        }

        cb->status = 0;

        nic->cbs_avail++;

    }

    spin_unlock(&nic->cb_lock);
 

/* Recover from running out of Tx resources in xmit_frame */

    if(unlikely(tx_cleaned && netif_queue_stopped(nic->netdev)))

        netif_wake_queue(nic->netdev); // 唤醒该网卡的等待队列
 

    return tx_cleaned;

}

控制队列的操作，原理和上面一样：

staticvoid e100_clean_cbs(struct nic *nic)

staticint e100_alloc_cbs(struct nic *nic)

启动接收过程

staticinlinevoid e100_start_receiver(struct nic *nic, struct rx *rx)

给收包过程分配skb，这个是非常重要的过程，主要完成skb的分配工作，如果rx队列没有skb，则new一个，否则把状态同步一下，然后直接使用旧的skb，用于提高效率。分配好的skb要作pci_map动作，就是把内存挂在网卡的DMA通道，等有中断发生，内存就是网络数据包了，效验的动作在后面会作。

staticinlineint e100_rx_alloc_skb(struct nic *nic, struct rx *rx)

{

// 分配skb

    if(!(rx->skb = dev_alloc_skb(RFD_BUF_LEN + NET_IP_ALIGN)))

    return -ENOMEM;

/* Align, init, and map the RFD. */

    rx->skb->dev = nic->netdev;

    skb_reserve(rx->skb, NET_IP_ALIGN); // 保留IP对齐，用于VLAN的偏移，一般是2个字节

    memcpy(rx->skb->data, &nic->blank_rfd, sizeof(struct rfd));

// 在skb->data保留了一段内存作RFD，应该是状态寄存器，e100网卡的DMA通道前面的内存是用于做状态标志的，实际测试是16个字节

    rx->dma_addr = pci_map_single(nic->pdev, rx->skb->data,

                RFD_BUF_LEN, PCI_DMA_BIDIRECTIONAL);

// 映射到PCI的DMA通道，这样有中断发生就可以直接送到内存(skb->data)

    if(pci_dma_mapping_error(rx->dma_addr)) {

        dev_kfree_skb_any(rx->skb);

        rx->skb = 0;

        rx->dma_addr = 0;

        return -ENOMEM;

    }

/* Link the RFD to end of RFA by linking previous RFD to

* this one, and clearing EL bit of previous. */

    if(rx->prev->skb) { // 如果prev队列没有给释放，太好了，直接把状态清除就可以了

        struct rfd *prev_rfd = (struct rfd *)rx->prev->skb->data;

        put_unaligned(cpu_to_le32(rx->dma_addr),

                (u32 *)&prev_rfd->link);

        wmb();

        prev_rfd->command &= ~cpu_to_le16(cb_el);

       pci_dma_sync_single_for_device(nic->pdev, rx->prev->dma_addr,

       sizeof(struct rfd), PCI_DMA_TODEVICE);

// DMA通道同步，把状态寄存器与外面的内存同步一下

    }

    return 0;

}

// 主要的收包过程，有中断发生后，这个函数把接收的包首先解除PCI_DMA映射，然后纠错，最后要把包送到协议栈

staticinlineint e100_rx_indicate(struct nic *nic, struct rx *rx,

unsignedint *work_done, unsignedint work_to_do)

{

    struct sk_buff *skb = rx->skb;

    struct rfd *rfd = (struct rfd *)skb->data;

    u16 rfd_status, actual_size;

    if(unlikely(work_done && *work_done >= work_to_do))

        return -EAGAIN;

/* Need to sync before taking a peek at cb_complete bit */

// 同步一下状态，也就是skb前16字节的内存，后面根据rdf_status判断包是否收全了

    pci_dma_sync_single_for_cpu(nic->pdev, rx->dma_addr,

                sizeof(struct rfd), PCI_DMA_FROMDEVICE);

    rfd_status = le16_to_cpu(rfd->status);

    DPRINTK(RX_STATUS, DEBUG, "status=0x%04X\n", rfd_status);

/* If data isn't ready, nothing to indicate */

    if(unlikely(!(rfd_status & cb_complete)))

        return -ENODATA;
 

/* Get actual data size */

    actual_size = le16_to_cpu(rfd->actual_size) & 0x3FFF;

// 判断包是否收全

    if(unlikely(actual_size > RFD_BUF_LEN - sizeof(struct rfd)))

        actual_size = RFD_BUF_LEN - sizeof(struct rfd);

/* Get data */

// 解除DMA映射，这样skb->data就可以自由了

    pci_unmap_single(nic->pdev, rx->dma_addr,

                RFD_BUF_LEN, PCI_DMA_FROMDEVICE);

/* this allows for a fast restart without re-enabling interrupts */

    if(le16_to_cpu(rfd->command) & cb_el)

        nic->ru_running = RU_SUSPENDED;

/* Pull off the RFD and put the actual data (minus eth hdr) */

    skb_reserve(skb, sizeof(struct rfd)); // 如果是VLAN，把指针调整一下

    skb_put(skb, actual_size);

    skb->protocol = eth_type_trans(skb, nic->netdev);

// 作错包乱包检查

    if(unlikely(!(rfd_status & cb_ok))) {

/* Don't indicate if hardware indicates errors */

        nic->net_stats.rx_dropped++;

        dev_kfree_skb_any(skb);

    } elseif(actual_size > ETH_DATA_LEN + VLAN_ETH_HLEN) {

/* Don't indicate oversized frames */

        nic->rx_over_length_errors++;

        nic->net_stats.rx_dropped++;

        dev_kfree_skb_any(skb);

    } else {

// 终于正确收到了，统计数据都要作下增加

    nic->net_stats.rx_packets++;

    nic->net_stats.rx_bytes += actual_size;

    nic->netdev->last_rx = jiffies;

// 送到协议栈

    #ifdef CONFIG_E100_NAPI

        netif_receive_skb(skb); // NAPI的poll方式，使用软中断

   #else

       netif_rx(skb); // 普通的中断方式，使用硬中断

   #endif

        if(work_done)

            (*work_done)++;

   }

    rx->skb = NULL;

    return 0;

}

// 收报skb的清除

staticinlinevoid e100_rx_clean(struct nic *nic, unsignedint *work_done,

            unsignedint work_to_do)

// 下面这两个函数针对收报队列的管理，也就是调用e100_rx_clean, e100_rx_alloc_skb，用户状态的链表，实际上比较简单，如果哪个给送走了，就检查，再分配一个；

// 因为e100是百兆网卡，所以只有一个用户太的skb管理队列，e1000系列的则硬件中维护另外一个队列，一次可以map 1024个skb

staticvoid e100_rx_clean_list(struct nic *nic)

staticint e100_rx_alloc_list(struct nic *nic)

// 初始化中断

static irqreturn_t e100_intr(int irq, void *dev_id, struct pt_regs *regs)

设置POLL的函数：

staticint e100_poll(struct net_device *netdev, int *budget)

staticvoid e100_netpoll(struct net_device *netdev)

网卡启动：

对应ifconfig eth0 up这样的命令

staticint e100_up(struct nic *nic)

{

    int err;

    if((err = e100_rx_alloc_list(nic))) // 分配收包队列

        return err;

    if((err = e100_alloc_cbs(nic))) // 分配控制队列

        goto err_rx_clean_list;

    if((err = e100_hw_init(nic))) // 硬件初始化

        goto err_clean_cbs;

    e100_set_multicast_list(nic->netdev); // 多播？

    e100_start_receiver(nic, 0); // 准备工作

    mod_timer(&nic->watchdog, jiffies); // 时间狗，自动检查网卡状态

    if((err = request_irq(nic->pdev->irq, e100_intr, SA_SHIRQ,

                nic->netdev->name, nic->netdev))) // 请求IRQ分配

        goto err_no_irq;

        netif_wake_queue(nic->netdev); // 唤醒网络队列，通知核心，这个网卡启动了

        #ifdef CONFIG_E100_NAPI

            netif_poll_enable(nic->netdev); // NAPI方式，把pool使能

/* enable ints _after_ enabling poll, preventing a race between

* disable ints+schedule */

        #endif

        e100_enable_irq(nic); // 使能中断，NAPI方式也需要，普通方式更需要

        return 0;

err_no_irq:

        del_timer_sync(&nic->watchdog);

err_clean_cbs:

        e100_clean_cbs(nic);

err_rx_clean_list:

        e100_rx_clean_list(nic);

    return err;

}

Ifconfig eth0 down

staticvoid e100_down(struct nic *nic) // 对应e100_up的逆向操作，比较简单

{

    #ifdef CONFIG_E100_NAPI

/* wait here for poll to complete */

        netif_poll_disable(nic->netdev);

    #endif

    netif_stop_queue(nic->netdev);

    e100_hw_reset(nic);

    free_irq(nic->pdev->irq, nic->netdev);

    del_timer_sync(&nic->watchdog);

    netif_carrier_off(nic->netdev);

    e100_clean_cbs(nic);  

    e100_rx_clean_list(nic);

}
 

Ethtools对应的函数，这里都列出来了

staticstruct ethtool_ops e100_ethtool_ops = {

    .get_settings = e100_get_settings,

    .set_settings = e100_set_settings,

    .get_drvinfo = e100_get_drvinfo,

    .get_regs_len = e100_get_regs_len,

    .get_regs = e100_get_regs,

    .get_wol = e100_get_wol,

    .set_wol = e100_set_wol,

    .get_msglevel = e100_get_msglevel,

    .set_msglevel = e100_set_msglevel,  

    .nway_reset = e100_nway_reset,

    .get_link = e100_get_link,

    .get_eeprom_len = e100_get_eeprom_len,

    .get_eeprom = e100_get_eeprom,

    .set_eeprom = e100_set_eeprom,

    .get_ringparam = e100_get_ringparam,

    .set_ringparam = e100_set_ringparam,

    .self_test_count = e100_diag_test_count,

    .self_test = e100_diag_test,

    .get_strings = e100_get_strings,

    .phys_id = e100_phys_id,

    .get_stats_count = e100_get_stats_count,

    .get_ethtool_stats = e100_get_ethtool_stats,

};

// 对应标准网卡驱动程序的一些封装函数

staticint e100_open(struct net_device *netdev)

staticint e100_close(struct net_device *netdev)

staticint __devinit e100_probe(struct pci_dev *pdev,

conststruct pci_device_id *ent)

staticvoid __devexit e100_remove(struct pci_dev *pdev)

staticint e100_suspend(struct pci_dev *pdev, u32 state)

staticint e100_resume(struct pci_dev *pdev)

staticvoid e100_shutdown(struct device *dev)

// 这个是网卡驱动的函数表，每个网卡都有的

staticstruct pci_driver e100_driver = {

    .name = DRV_NAME,

    .id_table = e100_id_table,

    .probe = e100_probe,

    .remove = __devexit_p(e100_remove),

    #ifdef CONFIG_PM

        .suspend = e100_suspend,

        .resume = e100_resume,

    #endif

    #if ( LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0) )

        .driver = {

        .shutdown = e100_shutdown,

    }

    #endif

};

staticint __init e100_init_module(void)

{

    if(((1 << debug) - 1) & NETIF_MSG_DRV) {

        printk(KERN_INFO PFX "%s, %s\n", DRV_DESCRIPTION, DRV_VERSION);

        printk(KERN_INFO PFX "%s\n", DRV_COPYRIGHT);

    }

    return pci_module_init(&e100_driver);

}

staticvoid __exit e100_cleanup_module(void)

{

    pci_unregister_driver(&e100_driver);

}

// 模块标准函数

module_init(e100_init_module);

module_exit(e100_cleanup_module);

Linux 内核分别在2.2 和 2.4内核中实现了网桥。但是2.2 内核和 2.4内核的实现有很大的区别，2.4中的实现几乎是全部重写了所有的实现代码。本文以2.4.0内核版本为例进行分析。

在分析具体的实现之前，先描述几个概念，有助于对网桥的功能及实现有更深的理解。

1. 冲突域

   一个冲突域由所有能够看到同一个冲突或者被该冲突涉及到的设备组成。以太网使用C S M A / C D（Carrier Sense Multiple Access with Collision Detection，带有冲突监测的载波侦听多址访问）技术来保证同一时刻，只有一个节点能够在冲突域内传送数据。网桥或者交换机，构成了一个冲突域的边界。缺省情况下，网桥中的每个端口实际上就是一个冲突域的结束点。

2. 广播域

   一个广播域由所有能够看到一个广播数据包的设备组成。一个路由器，构成一个广播域的边界。网桥能够延伸到的最大范围就是一个广播域。缺省的情况下，一个网桥或交换机的所有端口在同一个广播域中。VLAN技术可以把交换机或者网桥的不同端口分割成不同的广播域。一般情况下， 一个广播域代表一个逻辑网段。

3. 网桥中的CAM表

   网桥和交换机一样，为了能够实现对数据包的转发，网桥保存着许多（MAC，端口）项。所有的这些项组成一个表，叫做CAM表。每个项有超时机制，如果一定时间内未接收到以这个MAC为源MAC地址的数据包，这个项就会被删除。

在Linux内核网桥的实现中，一个逻辑网段用net_bridge结构体表示。一个逻辑网段需要保留的信息有：

1. 本逻辑网段中所有的端口(port_list)

   每个端口用net_bridge_port结构体来表示，从net_bridge_port结构体中可以看出，它主要有:

   1. 逻辑网段中的下一个端口(next)
   2. 本端口所属的逻辑网段(br)
   3. 本端口所指向的物理网卡（dev）
   4. 本端口在网桥中的编号(port_no)
   5. 用于生成树管理的信息

2. 一个逻辑网段中可以具有很多个端口，所有的端口都挂在以port_list为链表头的链表上。

   本网段中CAM表（hash[BR_HASH_SIZE]）

   CAM表中的每个项用net_bridge_fdb_entry结构体代表，每项中有：

   1. 用于CAM表连接的链表指针（next_hash，pprev_hash）
   2. 此项当前的引用计数（use_count）
   3. MAC地址（addr）
   4. 此项所对应的端口（dst）
   5. 处理MAC超时（ageing_timer）
   6. 是否是本机的MAC地址（is_local）
   7. 是否是静态MAC地址（is_static）

3. 一个逻辑网段中的所有表项形成一个CAM表，他们之间的组织关系是一个HASH链表。HASH链的个数为BR_HASH_SIZE（256）。

   本逻辑网段用于和外部通信的虚拟网络设备（dev）

   Linux网桥可以在网桥上为每个逻辑网段配置一个IP，用于和外部通信。实际上这个IP不是配置在一个特定的物理网卡上面， 而是建立一个虚拟的网卡，虚拟网卡可以附在每个同一逻辑网段的物理网卡上，让这个网卡可以象所有的物理网卡一样工作。从而使网桥可以和外部通信。

4. 本逻辑网段虚拟网卡的统计数据（statistics）

   按照Linux网卡驱动的接口，一个网卡的统计信息是由每个网卡的私有数据处理的。一般的写法是用dev->priv来指向每个网卡的统计数据。网卡的get_stats方法就是用来读取统计数据。

5. 用户一个网段的生成树(STP)信息

以上对几个结构体的描述和分析可以通过下图来表示：

描述了网桥的数据结构后，就可以开始数据包处理流程的分析。

网桥处理包遵循着以下几条原则：

1. 在一个接口上接收到的包不会再在那个接口上发送这个数据包。
2. 每个接收到的数据包都要学习其源MAC地址。
3. 如果数据包是多播包或广播包，则要在同一个网段中除了接收端口外的其他所有端口发送这个数据包，如果上层协议栈对多播包感兴趣，则需要把数据包提交给上层协议栈。
4. 如果数据包的目的MAC地址不能在CAM表中找到，则要在同一个网段中除了接收端口外的其他所有端口发送这个数据包。
5. 如果能够在CAM表中查询到目的MAC地址，则在特定的端口上发送这个数据包，如果发送端口和接收端口是同一端口，则不发送。

在网络软中断处理函数net_rx_action中，嵌入了handle_bridge用于把数据包skb送入网桥模块处理。

												
														#if defined(CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE)			if (skb->dev->br_port != NULL &&			    br_handle_frame_hook != NULL) {				handle_bridge(skb, pt_prev);				dev_put(rx_dev);				continue;			}#endif
												
										

br_handle_frame_hook是网桥处理接收到数据包的中入口，网桥初始化（br_init）的时候，把br_handle_frame_hook赋值为br_handle_frame。skb->dev->br_port用于判断接收到这个数据包的接口是否是网桥中的一个端口，如果是，skb->dev->br_port不为NULL，那么数据包应该由网桥处理。反之，数据包由上层协议栈处理。网桥中虚拟网卡对应的数据包就是在这个判断点时不再进入网桥。（实际上虚拟网卡并不会自己主动接收数据包，而是在网桥处理中把数据包向本地上层协议栈提交，并且修改了skb->dev，使得数据包不会多次进入桥处理代码）。

前面提到，网桥处理接收包的入口是br_handle_frame(net/bridge/br_input.c)函数。

br_handle_frame函数首先从skb中获得这个包属于的逻辑网段。然后调用__br_handle_frame进行转发处理。 br_handle_frame函数里有一个值得了解的地方，里面有一个加读锁。因为在转发中需要读CAM表，所以必须加读锁，避免在这个过程中另外的内核控制路径(如多处理机上另外一个CPU上的系统调用)修改CAM表。

对输入包的转发决策都是在__br_handle_frame函数中。这个函数的处理可以分为以下几个部分：

1. 如果网桥的虚拟网卡处于混杂模式，那么每个接收到的数据包都需要克隆一份送到AF_PACKET协议处理体(网络软中断函数net_rx_action中ptype_all链的处理)。
   
   

   if (br->dev.flags & IFF_PROMISC) { struct sk_buff *skb2; skb2 = skb_clone(skb, GFP_ATOMIC); if (skb2) { passedup = 1; br_pass_frame_up(br, skb2); } }

   
   
   
   
2. 如果源MAC地址是多播或者是广播地址，那么这个包格式是错误的，简单的丢弃。
   
   

   if (skb->mac.ethernet->h_source[0] & 1) goto freeandout;

   
   
   
   
3. 如果是一个多播包，则需要向本机的上层协议栈传送这个数据包（如果在之前没有向上提交的话，即passedup为0。如果为1，则前面已经发送了，现在就不需要提交了，在后面中的处理都是一样的）。
   
   

   if (!passedup && (dest[0] & 1) && (br->dev.flags & IFF_ALLMULTI || br->dev.mc_list != NULL)) { struct sk_buff *skb2; skb2 = skb_clone(skb, GFP_ATOMIC); if (skb2) { passedup = 1; br_pass_frame_up(br, skb2); } }

   
   
   
   
4. 如果启动了生成树协议，一个生成树包需要由生成树协议处理模块单独处理。如果不支持，则这个包的目的MAC肯定在CAM中查询不到，所以是向所有的端口发送（除接收口）。这样才不会影响整个网络的生成树协议运行。
   
   

   if (br->stp_enabled && !memcmp(dest, bridge_ula, 5) && !(dest[5] & 0xF0)) goto handle_special_frame;

   
   
   
   
5. 如果接收端口不是处于LEARNING或者FORWARDING，那么就学习这个包的源MAC地址，或者更新CAM表中相应项的定时器。
   
   

   if (p->state == BR_STATE_LEARNING || p->state == BR_STATE_FORWARDING) br_fdb_insert(br, p, skb->mac.ethernet->h_source, 0);

   
   
   
   
6. 如果是一个多播包或广播包，则调用br_flood函数向每个口发送（除接收口）这个数据包。如果之前没有提交上层协议，则需要克隆一个包提交上层协议。
   
   

   if (dest[0] & 1) { br_flood(br, skb, 1); if (!passedup) br_pass_frame_up(br, skb); else kfree_skb(skb); return; }

   
   
   
   
7. 用接收到数据包的目的MAC地址查询CAM表。
   
   

   dst = br_fdb_get(br, dest);

   
   
   
   
8. 查询CAM表后，如果能够找到表项，并且目的MAC是到本机的虚拟网卡的，那么就需要把这个包提交给上层协议。网桥就是通过这个地方的处理和外部通信，实现远程管理的目的。
   
   

   if (dst != NULL && dst->is_local) { if (!passedup) br_pass_frame_up(br, skb); else kfree_skb(skb); br_fdb_put(dst); return; }

   
   
   
   
9. 如果查询CAM表有结果，并且目的MAC不是到本地的，那么就通过调用br_forward发送到特定的端口。
   
   

   if (dst != NULL) { br_forward(dst->dst, skb); br_fdb_put(dst); return; }

   
   
   
   
10. 如果在CAM表中查询不到数据包的目的MAC地址，那么就需要向别的每个端口发送这个数据包。调用br_flood来进行这个处理。
    
    

    br_flood(br, skb, 0); return;

    
    
    
    

在br_forward和br_flood函数中都必须判断源接口和目的接口是否是同一个，如果是同一端口，就不发送这个数据包。数据包的最后发送都是通过统一的发送接口dev_queue_xmit函数来完成的。

以下就是数据包的处理流程：

前面多次提到网桥的虚拟网卡，实际上在网桥中，这个网卡存在着一个net_device结构（在net_bridge里），但是不存在着实际的物理设备，而是附在网桥中每个物理网卡上面。这个虚拟网卡的支持函数在（br_device.c）。因为是虚拟的网卡，所以没有物理中断产生，每个需要发送到这个设备的数据包都是靠判断数据包的目的MAC地址来决定是否需要提交到本地上层协议栈（在__br_handle_frame判断）。

如果数据包需要向上层协议提交，都调用br_pass_frame_up函数来处理。在这个函数中，首先把skb->dev设置成br->dev。然后再模拟在中断中处理数据包一样，进行相应的处理， 然后调用netif_rx放入接收队列。这里有一个要十分注意的地方，这个数据包的skb->dev已经变成br->dev。所以在网络接收软中断处理函数net_rx_action中不会再次进入handle_bridge了。

												
														static void br_pass_frame_up(struct net_bridge *br, struct sk_buff *skb){	br->statistics.rx_packets++;	br->statistics.rx_bytes += skb->len;	skb->dev = &br->dev;	skb->pkt_type = PACKET_HOST;	skb_pull(skb, skb->mac.raw - skb->data);	skb->protocol = eth_type_trans(skb, &br->dev);	netif_rx(skb);}
												
										

回页首

二、配置内核 2.4 Linux 网桥

要配置网桥，首先需要网桥的配置工具bridge-utils。这个配置程序的源代码可以在 http://bridge.sourceforge.net/bridge-utils/ 下载。编译成功之后，就可以生成网桥配置的主要工具brctl。

下面，我们将用brctl对以下网络拓扑配置网桥，使Linux能够对数据包进行交换。

上图中，有五台主机。其中中间那台主机装有linux ，安装了网桥模块，而且有四块物理网卡，分别连接同一网段的其他主机。我们希望其成为一个网桥，为其他四台主机(IP分别为192.168.1.2 ，192.168.1.3，192.168.1.4，192.168.1.5) 之间转发数据包。同时，为了方便管理，希望网桥能够有一个IP（192.168.1.1），那样管理员就可以在192.168.1.0/24网段内的主机上telnet到网桥，对其进行配置，实现远程管理。

前一节中提到，网桥在同一个逻辑网段转发数据包。针对上面的拓扑，这个逻辑网段就是192.168.1.0/24网段。我们为这个逻辑网段一个名称，br_192。首先需要配置这样一个逻辑网段。

												
														# brctl addbr br_192			(建立一个逻辑网段，名称为br_192)
												
										

实际上，我们可以把逻辑网段192.168.1.0/24看作使一个VLAN ，而br_192则是这个VLAN的名称。

建立一个逻辑网段之后，我们还需要为这个网段分配特定的端口。在Linux中，一个端口实际上就是一个物理网卡。而每个物理网卡的名称则分别为eth0，eth1，eth2，eth3。我们需要把每个网卡一一和br_192这个网段联系起来，作为br_192中的一个端口。

												
														# brctl addif br_192 eth0			(让eth0成为br_192的一个端口)# brctl addif br_192 eth1			(让eth1成为br_192的一个端口)# brctl addif br_192 eth0			(让eth2成为br_192的一个端口)# brctl addif br_192 eth3			(让eth3成为br_192的一个端口)
												
										

网桥的每个物理网卡作为一个端口，运行于混杂模式，而且是在链路层工作，所以就不需要IP了。

												
														# ifconfig eth0 0.0.0.0# ifconfig eth1 0.0.0.0# ifconfig eth2 0.0.0.0# ifconfig eth3 0.0.0.0
												
										

然后给br_192的虚拟网卡配置IP：192.168.1.1。那样就能远程管理网桥。

												
														# ifconfig br_192 192.168.1.1
												
										

给br_192配置了IP之后，网桥就能够工作了。192.168.1.0/24网段内的主机都可以telnet到网桥上对其进行配置。

以上配置的是一个逻辑网段，实际上Linux网桥也能配置成多个逻辑网段(相当于交换机中划分多个VLAN)。具体的方法可以参考bridge-util中的HOWTO。

回页首

三、总结

本文分析了Linux网桥的实现，并且举例说明如何配置网桥。 通过学习网桥的实现，就能够了解网络中二层交换的原理。

网桥和交换机的功能非常相似，所以在分析网桥的时候，绝大多数情况下可以用交换机的处理方法来分析网桥的动作。

在专用的嵌入式板子运行 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。

回页首

2. Boot Loader 的概念

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

通常，Boot Loader 是严重地依赖于硬件而实现的，特别是在嵌入式世界。因此，在嵌入式世界里建立一个通用的 Boot Loader 几乎是不可能的。尽管如此，我们仍然可以对 Boot Loader 归纳出一些通用的概念来，以指导用户特定的 Boot Loader 设计与实现。

1. Boot Loader 所支持的 CPU 和嵌入式板

每种不同的 CPU 体系结构都有不同的 Boot Loader。有些 Boot Loader 也支持多种体系结构的 CPU，比如 U-Boot 就同时支持 ARM 体系结构和MIPS 体系结构。除了依赖于 CPU 的体系结构外，Boot Loader 实际上也依赖于具体的嵌入式板级设备的配置。这也就是说，对于两块不同的嵌入式板而言，即使它们是基于同一种 CPU 而构建的，要想让运行在一块板子上的 Boot Loader 程序也能运行在另一块板子上，通常也都需要修改 Boot Loader 的源程序。

2. Boot Loader 的安装媒介（Installation Medium）

系统加电或复位后，所有的 CPU 通常都从某个由 CPU 制造商预先安排的地址上取指令。比如，基于 ARM7TDMI core 的 CPU 在复位时通常都从地址 0x00000000 取它的第一条指令。而基于 CPU 构建的嵌入式系统通常都有某种类型的固态存储设备(比如：ROM、EEPROM 或 FLASH 等)被映射到这个预先安排的地址上。因此在系统加电后，CPU 将首先执行 Boot Loader 程序。

下图1就是一个同时装有 Boot Loader、内核的启动参数、内核映像和根文件系统映像的固态存储设备的典型空间分配结构图。

3. 用来控制 Boot Loader 的设备或机制

主机和目标机之间一般通过串口建立连接，Boot Loader 软件在执行时通常会通过串口来进行 I/O，比如：输出打印信息到串口，从串口读取用户控制字符等。

4. Boot Loader 的启动过程是单阶段（Single Stage）还是多阶段（Multi-Stage）

通常多阶段的 Boot Loader 能提供更为复杂的功能，以及更好的可移植性。从固态存储设备上启动的 Boot Loader 大多都是 2 阶段的启动过程，也即启动过程可以分为 stage 1 和 stage 2 两部分。而至于在 stage 1 和 stage 2 具体完成哪些任务将在下面讨论。

5. Boot Loader 的操作模式 (Operation Mode)

大多数 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 内核。

6. BootLoader 与主机之间进行文件传输所用的通信设备及协议

最常见的情况就是，目标机上的 Boot Loader 通过串口与主机之间进行文件传输，传输协议通常是 xmodem／ymodem／zmodem 协议中的一种。但是，串口传输的速度是有限的，因此通过以太网连接并借助 TFTP 协议来下载文件是个更好的选择。

此外，在论及这个话题时，主机方所用的软件也要考虑。比如，在通过以太网连接和 TFTP 协议来下载文件时，主机方必须有一个软件用来的提供 TFTP 服务。

在讨论了 BootLoader 的上述概念后，下面我们来具体看看 BootLoader 的应该完成哪些任务。

回页首

3. Boot Loader 的主要任务与典型结构框架

在继续本节的讨论之前，首先我们做一个假定，那就是：假定内核映像与根文件系统映像都被加载到 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 Boot Loader 的 stage1

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 寄存器为合适的地址来实现。

3.2 Boot Loader 的 stage2

正如前面所说，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()函数调用应该永远不返回的。如果这个调用返回，则说明出错。

回页首

4. 关于串口终端

在 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 处去执行，那么内核映像当然不能正确地执行了。

回页首

5. 结束语

Boot Loader 的设计与实现是一个非常复杂的过程。如果不能从串口收到那激动人心的"uncompressing linux.................. done, booting the kernel……"内核启动信息，恐怕谁也不能说："嗨，我的 boot loader 已经成功地转起来了！"。

基于Atmel at91rm9200的armlinux的bootloader启动代码分析
日期： 5月 05 @ 23:45:26 CST
文章主题： 编程开发

前阶段做了一次基于at91rm9200引导部分的技术分析，主要采用了u-boot，这里只面向使用at91rm9200板子的的朋友做个简单的推敲，希望起到抛砖引玉的作用

Author : balancesli
mail : balancesli@thizlinux.com.cn

前阶段做了一次基于at91rm9200引导部分的技术分析，主要采用了u-boot，这里只面向使用at91rm9200板子的
的朋友做个简单的推敲，希望起到抛砖引玉的作用.

关键词 :
u-boot: 一个开源的面向多个目标平台(ppc, mips, arm, x86)的bootloader.
at91rm9200 : Atmel 公司生产的基于arm9核的Soc处理器.

以下先给出at91rm9200引导流程图

Boot program Flow Diagram

Device Setup
|
|
Boot SPI DataFlash Boot --> Download from DataFlash --> run
|
|
TWI EEPROM Boot --> Download from EEPROM --> run
|
|
Parallel Boot --> Download from 8-bit Device -->
|
| Xmodem protocol
| |---DBGU Serial Download ---------------------> run
|____|
| DFU protocol
|-----USB download -----------------------> run

在这里我主要介绍通过片内引导和片外引导, 片内引导主要采用串口下载并引导u-boot，并完成程序被烧写到Flash上,
然后就可以通过跳线的方式从片外引导执行已经烧写到片外Flash上的引导程序(bootloader).

这里要提及的是at91rm9200内部本身有128k的片内rom,其固化了一个bootloader和uploader, 用来支持程序的
下载和引导,而且其内部固化的程序提供了很多内部服务接口(Internel Service)供我们来使用，例如Xmodem，Tempo
DataFlash, CRC, Sine服务接口，这样我们就可以利用它所提供的Service interface API完成程序的下载。
这里主要介绍Xmodem接口服务。

at91rm9200内部固化的代码在设计上采用了面向对象的设计方法，如下:


typedef struct _AT91S_Service
{
char data;
char (*MainMethod)();
char (*ChildMethod)();
}AT91S_Service, *AT91PS_Service;

char AT91F_MainMethod()
{

}
char AT91F_ChildMethod()
{

}

/*init the Service */
AT91PS_Service AT91F_OpenDevice(AT91PS_Service pService)
{
pService->data = 0;
pService->MainMethod = AT91F_MainMethod;
pService->ChildMethod = AT91F_ChildMethod;
}

//使用方法如下
AT91S_Service service;
AT91PS_Service pService = AT91F_OpenDevice(&service);
pService->AT91F_MainMethmod();
.....

通过如上代码片断可以看出它采用了类似面向对象的设计方法。
其实如果各位朋友接触过的话或者看过这本书的话，应该很容易便接受它。
下面以Xmodem服务为例子介绍:


at91rm9200内部提供的服务包含了几个服务对象, 这些对象在片内启动xmodem协议Host端和Targe端通讯时会用到.


typedef struct _AT91S_RomBoot
{
const unsigned int version;
// Peripheral descriptors
const AT91S_MEMCDesc MEMC_DESC;
const AT91S_STDesc SYSTIMER_DESC;
const AT91S_Pio2Desc PIOA_DESC;
const AT91S_Pio2Desc PIOB_DESC;
const AT91S_USART2Desc DBGU_DESC;
const AT91S_USART2Desc USART0_DESC;
const AT91S_USART2Desc USART1_DESC;
const AT91S_USART2Desc USART2_DESC;
const AT91S_USART2Desc USART3_DESC;
const AT91S_TWIDesc TWI_DESC;
const AT91S_SPIDesc SPI_DESC;

// Objects entry
const AT91PF_OpenPipe OpenPipe;
const AT91PF_OpenSBuffer OpenSBuffer;
const AT91PF_OpenSvcUdp OpenSvcUdp;
const AT91PF_OpenSvcXmodem OpenSvcXmodem;
const AT91PF_OpenCtlTempo OpenCtlTempo;
const AT91PF_OpenDfuDesc OpenDfuDesc;
const AT91PF_OpenUsbDesc OpenUsbDesc;
const AT91PF_OpenSvcDataFlash OpenSvcDataFlash;
const AT91PF_SVC_CRC16 CRC16;
const AT91PF_SVC_CRCCCITT CRCCCITT;
const AT91PF_SVC_CRCHDLC CRCHDLC;
const AT91PF_SVC_CRC32 CRC32;
// Array
const AT91PS_SVC_CRC_BIT_REV Bit_Reverse_Array;
const AT91PS_SINE_TAB SineTab;
const AT91PF_Sinus Sine;
} AT91S_RomBoot;

//AT91S_Pipe
typedef struct _AT91S_Pipe
{
// A pipe is linked with a peripheral and a buffer
AT91PS_SvcComm pSvcComm;
AT91PS_Buffer pBuffer;

// Callback functions with their arguments
void (*WriteCallback) (AT91S_PipeStatus, void *);
void (*ReadCallback) (AT91S_PipeStatus, void *);
void *pPrivateReadData;
void *pPrivateWriteData;

// Pipe methods
AT91S_PipeStatus (*Write) (
struct _AT91S_Pipe *pPipe,
char const * pData,
unsigned int size,
void (*callback) (AT91S_PipeStatus, void *),
void *privateData
);

AT91S_PipeStatus (*Read) (
struct _AT91S_Pipe *pPipe,
char *pData,
unsigned int size,
void (*callback) (AT91S_PipeStatus, void *),
void *privateData
);

AT91S_PipeStatus (*AbortWrite)(struct _AT91S_Pipe *pPipe);
AT91S_PipeStatus (*AbortRead)(struct _AT91S_Pipe *pPipe);
AT91S_PipeStatus (*AbortRead)(struct _AT91S_Pipe *pPipe);
AT91S_PipeStatus (*Reset)(struct _AT91S_Pipe *pPipe);
char (*IsWritten)(struct _AT91S_Pipe *pPipe, char const *pVoid);
char (*IsReceived) (struct _AT91S_Pipe *pPipe, char const *pVoid);
} AT91S_Pipe;

//AT91S_Buff
typedef struct _AT91S_SBuffer
{
AT91S_Buffer parent;
char *pRdBuffer;
char const *pWrBuffer;
unsigned int szRdBuffer;
unsigned int szWrBuffer;
unsigned int stRdBuffer;
unsigned int stWrBuffer;
} AT91S_SBuffer;

// AT91S_SvcTempo
typedef struct _AT91S_SvcTempo
{

// Methods:
AT91S_TempoStatus (*Start) (
struct _AT91S_SvcTempo *pSvc,
unsigned int timeout,
unsigned int reload,
void (*callback) (AT91S_TempoStatus, void *),
void *pData);
AT91S_TempoStatus (*Stop) (struct _AT91S_SvcTempo *pSvc);

struct _AT91S_SvcTempo *pPreviousTempo;
struct _AT91S_SvcTempo *pNextTempo;

// Data
unsigned int TickTempo; //* timeout value
unsigned int ReloadTempo;//* Reload value for periodic execution
void (*TempoCallback)(AT91S_TempoStatus, void *);
void *pPrivateData;
AT91E_SvcTempo flag;
} AT91S_SvcTempo;

// AT91S_CtrlTempo
typedef struct _AT91S_CtlTempo
{
// Members:

// Start and stop for Timer hardware
AT91S_TempoStatus (*CtlTempoStart) (void *pTimer);
AT91S_TempoStatus (*CtlTempoStop) (void *pTimer);

// Start and stop for Tempo service
AT91S_TempoStatus (*SvcTempoStart) (
struct _AT91S_SvcTempo *pSvc,
unsigned int timeout,
unsigned int reload,
void (*callback) (AT91S_TempoStatus, void *),
void *pData);
AT91S_TempoStatus (*SvcTempoStop) (struct _AT91S_SvcTempo *pSvc);
AT91S_TempoStatus (*CtlTempoSetTime)(struct _AT91S_CtlTempo *pCtrl, unsigned int NewTime);
AT91S_TempoStatus (*CtlTempoGetTime)(struct _AT91S_CtlTempo *pCtrl);
AT91S_TempoStatus (*CtlTempoIsStart)(struct _AT91S_CtlTempo *pCtrl);
AT91S_TempoStatus (*CtlTempoCreate) (struct _AT91S_CtlTempo *pCtrl,struct _AT91S_SvcTempo *pTempo);
AT91S_TempoStatus (*CtlTempoRemove) (struct _AT91S_CtlTempo *pCtrl,struct _AT91S_SvcTempo *pTempo);
AT91S_TempoStatus (*CtlTempoTick) (struct _AT91S_CtlTempo *pCtrl);

// Data:

void *pPrivateData; // Pointer to devived class
void const *pTimer; // hardware
AT91PS_SvcTempo pFirstTempo;
AT91PS_SvcTempo pNewTempo;
} AT91S_CtlTempo;



//以下代码是上面几个对象的使用范例，通过这样就可以完成Host端和Targe端之间的xmodem通讯,并可以下载代码了。

AT91S_RomBoot const *pAT91;
AT91S_SBuffer sXmBuffer;
AT91S_SvcXmodem svcXmodem;
AT91S_Pipe xmodemPipe;
AT91S_CtlTempo ctlTempo;

AT91PS_Buffer pXmBuffer;
AT91PS_SvcComm pSvcXmodem;
unsigned int SizeDownloaded;

/* Init of ROM services structure */
pAT91 = AT91C_ROM_BOOT_ADDRESS;//这里取得内部ROM服务的入口地址

/* Tempo Initialization */
pAT91->OpenCtlTempo(&ctlTempo, (void *) &(pAT91->SYSTIMER_DESC));
ctlTempo.CtlTempoStart((void *) &(pAT91->SYSTIMER_DESC));

/* Xmodem Initialization */
pXmBuffer = pAT91->OpenSBuffer(&sXmBuffer);
pSvcXmodem = pAT91->OpenSvcXmodem(&svcXmodem, (AT91PS_USART)AT91C_BASE_DBGU, &ctlTempo);
pAT91->OpenPipe(&xmodemPipe, pSvcXmodem, pXmBuffer);
xmodemPipe.Read(&xmodemPipe, (char *)AT91C_UBOOT_BASE_ADDRESS, AT91C_UBOOT_MAXSIZE,
AT91F_XmodemProtocol, 0);
while(XmodemComplete !=1);



//上面部分主要针对at91rm9200片内启动时我们可以使用的片内接口服务介绍，玩H9200的朋友可以参考一下便知道缘由。

下面主要介绍at91rm9200片外启动时所使用的bootloader-->u-boot.

一. bootloader
BootLoader(引导装载程序)是嵌入式系统软件开发的非常重要的环节，它把操作系统和硬件平台衔接在一起，
是跟硬件体系密切相关的。



1.1 典型的嵌入式系统软件部分Image memory layout : bootloader , bootloader param, kernel, rootfs.

1.2 引导模式 : 1. bootstrap或download
2. autoboot
1.3 u-boot简介 :
u-boot是由Wolfgang Denk开发，它支持(mips, ppc, arm, x86)等目标体系，
可以在http://sourceforge.net 上下载获得源码，

1.4 u-boot源代码目录结构

board：开发板相关的源码，不同的板子对应一个子目录，内部放着主板相关代码。

at91rm9200dk/at91rm9200.c, config.mk, Makefile, flash.c ,u-boot.lds等都和具体开发板的硬件和地址分配有关。

common：与体系结构无关的代码文件，实现了u-boot所有命令，
其中内置了一个shell脚本解释器(hush.c, a prototype Bourne shell grammar parser), busybox中也使用了它.


cpu：与cpu相关代码文件，其中的所有子目录都是以u-boot所支持的cpu命名.

at91rm9200/at45.c, at91rm9200_ether.c, cpu.c, interrupts.c serial.c, start.S, config.mk, Makefile等.
其中cpu.c负责初始化CPU、设置指令Cache和数据Cache等；

interrupt.c负责设置系统的各种中断和异常，比如快速中断、开关中断、时钟中断、软件中断、
预取中止和未定义指令等；

start.S负责u-boot启动时执行的第一个文件，它主要是设置系统堆栈和工作方式，为跳转到C程序入口点.

disk：设备分区处理代码。

doc：u-boot相关文档。


drivers：u-boot所支持的设备驱动代码, 网卡、支持CFI的Flash、串口和USB总线等。

fs: u-boot所支持支持文件系统访问存取代码， 如jffs2.

include：u-boot head文件，主要是与各种硬件平台相关的头文件，
如include/asm-arm/arch-at91rm9200/, include/asm-arm/proc-armv

net：与网络有关的代码，BOOTP协议、TFTP协议、RARP协议代码实现.

lib_arm：与arm体系相关的代码。(这里我们主要面向的是ARM体系，所以该目录是我们主要研究对象)

tools：编译后会生成mkimage工具，用来对生成的raw bin文件加入u-boot特定的image_header.


1.5 u-boot的功能介绍


　u-boot支持SCC/FEC以太网、OOTP/TFTP引导、IP和MAC的功能.

读写Flash、DOC、IDE、IIC、EEROM、RTC

支持串行口kermit和S-record下载代码, 并直接从串口下载并执行。

在我们生成的内核镜像时，要做如下处理.
1. arm-linux-objcopy -O binary -R.note -R.comment -S vmlinux linux.bin
2. gzip -9 linux.bin
3. mkimage -A arm -O linux -T kernel -C gzip -a 0xc0008000 -e 0xc0008000 -n
"Linux-2.4.19-rmk7” -d linux.bin.gz uImage

即在Linux内核镜像vmLinux前添加了一个特殊的头，这个头在include/image.h中定义，
typedef struct image_header
{
uint32_t ih_magic; /* Image Header Magic Number */
uint32_t ih_hcrc; /* Image Header CRC Checksum */
uint32_t ih_time; /* Image Creation Timestamp */
uint32_t ih_size; /* Image Data Size */
uint32_t ih_load; /* Data Load Address */
uint32_t ih_ep; /* Entry Point Address */
uint32_t ih_dcrc; /* Image Data CRC Checksum */
uint8_t ih_os; /* Operating System */
uint8_t ih_arch; /* CPU architecture */
uint8_t ih_type; /* Image Type */
uint8_t ih_comp; /* Compression Type */
uint8_t ih_name[IH_NMLEN]; /* Image Name */
} image_header_t;

当u-boot引导时会对这个文件头进行CRC校验，如果正确，才会跳到内核执行.

如果u-boot启动以后会出现
u-boot>
敲入help, 会出现大量的命令提示，Monitor command
go - start application at address 'addr'
run - run commands in an environment variable
bootm - boot application image from memory
bootp - boot image via network using BootP/TFTP protocol
tftpboot- boot image via network using TFTP protocol
and env variables "ipaddr" and "serverip"
(and eventually "gatewayip")
rarpboot- boot image via network using RARP/TFTP protocol
diskboot- boot from IDE devicebootd - boot default, i.e., run 'bootcmd'
loads - load S-Record file over serial line
loadb - load binary file over serial line (kermit mode)
md - memory display
mm - memory modify (auto-incrementing)
nm - memory modify (constant address)
mw - memory write (fill)
cp - memory copy
cmp - memory compare
crc32 - checksum calculation
imd - i2c memory display
imm - i2c memory modify (auto-incrementing)
inm - i2c memory modify (constant address)
imw - i2c memory write (fill)
icrc32 - i2c checksum calculation
iprobe - probe to discover valid I2C chip addresses
iloop - infinite loop on address range
isdram - print SDRAM configuration information
sspi - SPI utility commands
base - print or set address offset
printenv- print environment variables
setenv - set environment variables
saveenv - save environment variables to persistent storage
protect - enable or disable FLASH write protection
erase - erase FLASH memory
flinfo - print FLASH memory information
bdinfo - print Board Info structure
iminfo - print header information for application image
coninfo - print console devices and informations
ide - IDE sub-system
loop - infinite loop on address range
mtest - simple RAM test
icache - enable or disable instruction cache
dcache - enable or disable data cache
reset - Perform RESET of the CPU
echo - echo args to console
version - print monitor version
help - print online help
? - alias for 'help'

u-boot支持大量的命令可用, 这里就不作介绍，大家有兴趣可以看看u-boot 的README文档
3.3 对u-boot-1.0.0的修改和移植

1.6 关于u-boot的移植如下，由于u-boot的软件设计体系非常清晰，它的移植工作并不复杂，
相信各位的代码阅读功力不错的话，参照如下就可以完成。

If the system board that you have is not listed, then you will need
to port U-Boot to your hardware platform. To do this, follow these
steps:

1. Add a new configuration option for your board to the toplevel
"Makefile" and to the "MAKEALL" script, using the existing
entries as examples. Note that here and at many other places
boards and other names are listed in alphabetical sort order. Please
keep this order.

2. Create a new directory to hold your board specific code. Add any
files you need. In your board directory, you will need at least
the "Makefile", a ".c", "flash.c" and "u-boot.lds".

3. Create a new configuration file "include/configs/.h" for
your board

4. If you're porting U-Boot to a new CPU, then also create a new
directory to hold your CPU specific code. Add any files you need.

5. Run "make _config" with your new name.

6. Type "make", and you should get a working "u-boot.srec" file

7. Debug and solve any problems that might arise.
[Of course, this last step is much harder than it sounds.]

为了使u-boot-1.0.0支持新的开发板，一种简便的做法是在u-boot已经支持的开发板中参考选择一种较接近板的进行修改,
幸运的是在u-boot-1.0.0中已经有了at91rm9200的支持。

1.7 与at91rm9200相关的u-boot代码

在include/configs/at91rm9200dk.h 它包括开发板的CPU、系统时钟、RAM、Flash系统及其它相关的配置信息。
在include/asm-arm/AT91RM9200.h, 该文件描述了H9200寄存器的结构及若干宏定义。
具体内容要参考相关处理器手册。
在cpu/at91rm9200/目录下别为cpu.c、interrupts.c和serial.c等文件.
在board/at91rm9200dk/目录下分别为flash.c、at91rm9200dk.c, config.mk, Makefile,u-boot.lds

flash.c : u-boot读、写和删除Flash设备的源代码文件。由于不同开发板中Flash存储器的种类各不相同，
所以，修改flash.c时需参考相应的Flash芯片手册。它包括如下几个函数：
unsigned long flash_init (void )，Flash初始化；
void flash_print_info (flash_info_t *info)，打印Flash信息；
int flash_erase (flash_info_t *info， int s_first， int s_last)，Flash擦除；
volatile static int write_dword (flash_info_t *info， ulong dest， ulong data)，Flash写入；
int write_buff (flash_info_t *info， uchar *src， ulong addr， ulong cnt)，从内存复制数据。

u-boot.lds :linker scripte, 设置u-boot中各个目标文件的连接地址.

网口设备控制程序

　　在drivers/目录中网口设备控制程序cs8900, bcm570x等, 还可以添加其他网卡驱动
int eth_init (bd_t *bd) : 初始化网络设备；
void eth_halt (void) : 关闭网络设备；
int eth_send (volatile void *packet，int len) : 发送数据包；
int eth_rx (void) : 接收数据包。


Makefile

　　在u-boot-1.0.0/Makefile中
at91rm9200dk_config : unconfig
./mkconfig $(@:_config=) arm at91rm9200 at91rm9200dk

1.8 编译u-boot

　 make at91rm9200_config
Configuring for at91rm9200 board...
make all
生成三个文件：u-boot.bin, u-boot, u-boot.srec

u-boot.bin is a raw binary image
u-boot is an image in ELF binary format
u-boot.srec is in Motorola S-Record format (objcopy -O srec -R.note -R.comment -S [inputfile] [outfile]


以上工作完成我们可以通过串口将u-boot.bin下载到主板的SDRAM中，它会自动执行， 并出现uboot>
这里我们可以通过串口把boot.bin, u-boot.bin.gz下载到主板，再用u-boot的提供的写flash功能分别
把boot.bin, u-boot.bin.gz写入到flash中，完成以上工作后，对主板跳线选择片外启动，
板子复位后会自动启动u-boot.




二.loader.bin, boot.bin, u-boot.bin代码执行流分析.

以上三个文件时at91rm9200启动所需要的三个bin,他们的实现代码并不难。
如果是你是采用at91rm9200的评估版，应该能得到其源码。

2.1 loader.bin 执行流程,这个文件主要在片内启动从串口下载代码时会用到
loader/entry.S init cpu
b main ---> crt0.S
--> copydata --> clearbss --> b boot
main.c --> boot -->
/*Get internel rom service address*/
/* Init of ROM services structure */
pAT91 = AT91C_ROM_BOOT_ADDRESS;

/* Xmodem Initialization */
--> pAT91->OpenSBuffer
--> pAT91->OpenSvcXmodem
/* System Timer initialization */
---> AT91F_AIC_ConfigureIt
/* Enable ST interrupt */
AT91F_AIC_EnableIt
AT91F_DBGU_Printk("XMODEM: Download U-BOOT ");

Jump.S
// Jump to Uboot BaseAddr exec
Jump((unsigned int)AT91C_UBOOT_BASE_ADDRESS)



2.2 boot.bin执行流程 该文件会在从片内启动时被下载到板子上，以后还会被烧写到片外Flash中，以便在片外启动时
用它来引导并解压u-boot.gz，并跳转到u-boot来执行。
boot/entry.S
b main --> crt0.S --> copydata --> clearbss --> b boot

T91F_DBGU_Printk(" ");
AT91F_DBGU_Printk("************************************** ");
AT91F_DBGU_Printk("** Welcome to at91rm9200 ** ");
AT91F_DBGU_Printk("************************************** ");

boot/misc.s /* unzip uboot.bin.gz */
----> decompress_image(SRC,DST,LEN) --> gunzip

//jump to ubootBaseAddr exec 这里跳转到解压u-boot.gz的地址处直接开始执行u-boot
asm("mov pc,%0" : : "r" (DST));

2.3 uboot.bin执行流程
u-boot/cpu/at91rm9200/start.S
start --->reset
---> copyex ---> cpu_init_crit
---> /* set up the stack */ --> start_armboot
u-boot/lib_arm/board.c

init_fnc_t *init_sequence[] = {
cpu_init, /* basic cpu dependent setup */
board_init, /* basic board dependent setup */
interrupt_init, /* set up exceptions */
env_init, /* initialize environment */
init_baudrate, /* initialze baudrate settings */
serial_init, /* serial communications setup */
console_init_f, /* stage 1 init of console */
display_banner, /* say that we are here */
dram_init, /* configure available RAM banks */
display_dram_config,
checkboard,
NULL,
};

---> start_armboot ---> call init_sequence
---> flash_init --> display_flash_config
---> nand_init ---> AT91F_DataflashInit
---> dataflash_print_info --> env_relocate
---> drv_vfd_init --> devices_init --> jumptable_init
---> console_init_r --> misc_init_r --> enable_interrupts
---> cs8900_get_enetaddr --> board_post_init -->

u-boot/common/main.c
for (;;)
{ /* shell parser */
main_loop () --> u_boot_hush_start --> readline
--> abortboot
-->printf("Hit any key to stop autoboot: %2d ", bootdelay);
}


以上是at91rm9200启动并进入u-boot的执行流分析。后面u-boot还会将uImage解压到特定的位置并开始执行内核代码。


三. 综述
总之, 不同厂商的出的Soc片子在启动方式大都提供片内和片外启动两种方式，一般都是在片内固化一段小程序
方便于程序开发而已，在其DataSheet文档中有详尽的描述。若是对at92rm9200有兴趣或玩过的朋友，可以与我共同探讨相互学习。

• Makefile学习教程: 跟我一起写 Makefile
  • 0 Makefile概述
    • 0.1 关于程序的编译和链接
  • 1 Makefile 介绍
    • 1.1 Makefile的规则
    • 1.2 一个示例
    • 1.3 make是如何工作的
    • 1.4 makefile中使用变量
    • 1.5 让make自动推导
    • 1.6 另类风格的makefile
    • 1.7 清空目标文件的规则
  • 2 Makefile 总述
    • 2.1 Makefile里有什么？
    • 2.2Makefile的文件名
    • 2.3 引用其它的Makefile
    • 2.4 环境变量 MAKEFILES
    • 2.5 make的工作方式
  • 3 Makefile书写规则
    • 3.1 规则举例
    • 3.2 规则的语法
    • 3.3 在规则中使用通配符
    • 3.4 文件搜寻
    • 3.5 伪目标
    • 3.6 多目标
    • 3.7 静态模式
    • 3.8 自动生成依赖性
  • 4 Makefile 书写命令
    • 4.1 显示命令
    • 4.2 命令执行
    • 4.3 命令出错
    • 4.4 嵌套执行make
    • 4.5 定义命令包

0 Makefile概述

因为，makefile关系到了整个工程的编译规则。一个工程中的源文件不计数，其按类型、功能、模块分别放在若干个目录中，makefile定义了一系列的规则来指定，哪些文件需要先编译，哪些文件需要后编译，哪些文件需要重新编译，甚至于进行更复杂的功能操作，因为makefile就像一个Shell脚本一样，其中也可以执行操作系统的命令。

makefile带来的好处就是——“自动化编译”，一旦写好，只需要一个make命令，整个工程完全自动编译，极大的提高了软件开发的效率。make是一个命令工具，是一个解释makefile中指令的命令工具，一般来说，大多数的IDE都有这个命令，比如：Delphi的make，Visual C++的nmake，Linux下GNU的make。可见，makefile都成为了一种在工程方面的编译方法。

现在讲述如何写makefile的文章比较少，这是我想写这篇文章的原因。当然，不同产商的make各不相同，也有不同的语法，但其本质都是在“文件依赖性”上做文章，这里，我仅对GNU的make进行讲述，我的环境是RedHat Linux 8.0，make的版本是3.80。必竟，这个make是应用最为广泛的，也是用得最多的。而且其还是最遵循于IEEE 1003.2-1992 标准的（POSIX.2）。

在这篇文档中，将以C/C++的源码作为我们基础，所以必然涉及一些关于C/C++的编译的知识，相关于这方面的内容，还请各位查看相关的编译器的文档。这里所默认的编译器是UNIX下的GCC和CC。

0.1 关于程序的编译和链接

编译时，编译器需要的是语法的正确，函数与变量的声明的正确。对于后者，通常是你需要告诉编译器头文件的所在位置（头文件中应该只是声明，而定义应该放在C/C++文件中），只要所有的语法正确，编译器就可以编译出中间目标文件。一般来说，每个源文件都应该对应于一个中间目标文件（O文件或是OBJ文件）。

链接时，主要是链接函数和全局变量，所以，我们可以使用这些中间目标文件（O文件或是OBJ文件）来链接我们的应用程序。链接器并不管函数所在的源文件，只管函数的中间目标文件（Object File），在大多数时候，由于源文件太多，编译生成的中间目标文件太多，而在链接时需要明显地指出中间目标文件名，这对于编译很不方便，所以，我们要给中间目标文件打个包，在Windows下这种包叫“库文件”（Library File)，也就是 .lib 文件，在UNIX下，是Archive File，也就是 .a 文件。

总结一下，源文件首先会生成中间目标文件，再由中间目标文件生成执行文件。在编译时，编译器只检测程序语法，和函数、变量是否被声明。如果函数未被声明，编译器会给出一个警告，但可以生成Object File。而在链接程序时，链接器会在所有的Object File中找寻函数的实现，如果找不到，那到就会报链接错误码（Linker Error），在VC下，这种错误一般是：Link 2001错误，意思说是说，链接器未能找到函数的实现。你需要指定函数的Object File.

好，言归正传，GNU的make有许多的内容，闲言少叙，还是让我们开始吧。

1 Makefile 介绍

首先，我们用一个示例来说明Makefile的书写规则。以便给大家一个感兴认识。这个示例来源于GNU的make使用手册，在这个示例中，我们的工程有8个C文件，和3个头文件，我们要写一个Makefile来告诉make命令如何编译和链接这几个文件。我们的规则是：

1. 如果这个工程没有编译过，那么我们的所有C文件都要编译并被链接。
2. 如果这个工程的某几个C文件被修改，那么我们只编译被修改的C文件，并链接目标程序。
3. 如果这个工程的头文件被改变了，那么我们需要编译引用了这几个头文件的C文件，并链接目标程序。

只要我们的Makefile写得够好，所有的这一切，我们只用一个make命令就可以完成，make命令会自动智能地根据当前的文件修改的情况来确定哪些文件需要重编译，从而自己编译所需要的文件和链接目标程序。

1.1 Makefile的规则

target ... : prerequisites ...   command   ...   ...

prerequisites就是，要生成那个target所需要的文件或是目标。

command也就是make需要执行的命令。（任意的Shell命令）

这是一个文件的依赖关系，也就是说，target这一个或多个的目标文件依赖于prerequisites中的文件，其生成规则定义在command中。说白一点就是说，prerequisites中如果有一个以上的文件比target文件要新的话，command所定义的命令就会被执行。这就是Makefile的规则。也就是Makefile中最核心的内容。

说到底，Makefile的东西就是这样一点，好像我的这篇文档也该结束了。呵呵。还不尽然，这是Makefile的主线和核心，但要写好一个Makefile还不够，我会以后面一点一点地结合我的工作经验给你慢慢到来。内容还多着呢。：）

1.2 一个示例

    edit : main.o kbd.o command.o display.o            insert.o search.o files.o utils.o            cc -o edit main.o kbd.o command.o display.o                        insert.o search.o files.o utils.o    main.o : main.c defs.h            cc -c main.c    kbd.o : kbd.c defs.h command.h            cc -c kbd.c    command.o : command.c defs.h command.h            cc -c command.c    display.o : display.c defs.h buffer.h            cc -c display.c    insert.o : insert.c defs.h buffer.h            cc -c insert.c    search.o : search.c defs.h buffer.h            cc -c search.c    files.o : files.c defs.h buffer.h command.h            cc -c files.c    utils.o : utils.c defs.h            cc -c utils.c    clean :            rm edit main.o kbd.o command.o display.o                insert.o search.o files.o utils.o

在这个makefile中，目标文件（target）包含：执行文件edit和中间目标文件（*.o），依赖文件（prerequisites）就是冒号后面的那些 .c 文件和 .h文件。每一个 .o 文件都有一组依赖文件，而这些 .o 文件又是执行文件 edit 的依赖文件。依赖关系的实质上就是说明了目标文件是由哪些文件生成的，换言之，目标文件是哪些文件更新的。

在定义好依赖关系后，后续的那一行定义了如何生成目标文件的操作系统命令，一定要以一个Tab键作为开头。记住，make并不管命令是怎么工作的，他只管执行所定义的命令。make会比较targets文件和prerequisites文件的修改日期，如果prerequisites文件的日期要比targets文件的日期要新，或者target不存在的话，那么，make就会执行后续定义的命令。

这里要说明一点的是，clean不是一个文件，它只不过是一个动作名字，有点像C语言中的lable一样，其冒号后什么也没有，那么，make就不会自动去找文件的依赖性，也就不会自动执行其后所定义的命令。要执行其后的命令，就要在make命令后明显得指出这个lable的名字。这样的方法非常有用，我们可以在一个makefile中定义不用的编译或是和编译无关的命令，比如程序的打包，程序的备份，等等。

1.3 make是如何工作的

1. make会在当前目录下找名字叫“Makefile”或“makefile”的文件。
2. 如果找到，它会找文件中的第一个目标文件（target），在上面的例子中，他会找到“edit”这个文件，并把这个文件作为最终的目标文件。
3. 如果edit文件不存在，或是edit所依赖的后面的 .o 文件的文件修改时间要比edit这个文件新，那么，他就会执行后面所定义的命令来生成edit这个文件。
4. 如果edit所依赖的.o文件也存在，那么make会在当前文件中找目标为.o文件的依赖性，如果找到则再根据那一个规则生成.o文件。（这有点像一个堆栈的过程）
5. 当然，你的C文件和H文件是存在的啦，于是make会生成 .o 文件，然后再用 .o 文件生命make的终极任务，也就是执行文件edit了。

这就是整个make的依赖性，make会一层又一层地去找文件的依赖关系，直到最终编译出第一个目标文件。在找寻的过程中，如果出现错误，比如最后被依赖的文件找不到，那么make就会直接退出，并报错，而对于所定义的命令的错误，或是编译不成功，make根本不理。make只管文件的依赖性，即，如果在我找了依赖关系之后，冒号后面的文件还是不在，那么对不起，我就不工作啦。

通过上述分析，我们知道，像clean这种，没有被第一个目标文件直接或间接关联，那么它后面所定义的命令将不会被自动执行，不过，我们可以显示要make执行。即命令——“make clean”，以此来清除所有的目标文件，以便重编译。

于是在我们编程中，如果这个工程已被编译过了，当我们修改了其中一个源文件，比如file.c，那么根据我们的依赖性，我们的目标file.o会被重编译（也就是在这个依性关系后面所定义的命令），于是file.o的文件也是最新的啦，于是file.o的文件修改时间要比edit要新，所以edit也会被重新链接了（详见edit目标文件后定义的命令）。

而如果我们改变了“command.h”，那么，kdb.o、command.o和files.o都会被重编译，并且，edit会被重链接。

1.4 makefile中使用变量

      edit : main.o kbd.o command.o display.o                   insert.o search.o files.o utils.o            cc -o edit main.o kbd.o command.o display.o                        insert.o search.o files.o utils.o

比如，我们声明一个变量，叫objects, OBJECTS, objs, OBJS, obj, 或是 OBJ，反正不管什么啦，只要能够表示obj文件就行了。我们在makefile一开始就这样定义：

     objects = main.o kbd.o command.o display.o               insert.o search.o files.o utils.o

    objects = main.o kbd.o command.o display.o               insert.o search.o files.o utils.o    edit : $(objects)            cc -o edit $(objects)    main.o : main.c defs.h            cc -c main.c    kbd.o : kbd.c defs.h command.h            cc -c kbd.c    command.o : command.c defs.h command.h            cc -c command.c    display.o : display.c defs.h buffer.h            cc -c display.c    insert.o : insert.c defs.h buffer.h            cc -c insert.c    search.o : search.c defs.h buffer.h            cc -c search.c    files.o : files.c defs.h buffer.h command.h            cc -c files.c    utils.o : utils.c defs.h            cc -c utils.c    clean :            rm edit $(objects)

于是如果有新的 .o 文件加入，我们只需简单地修改一下 objects 变量就可以了。

关于变量更多的话题，我会在后续给你一一道来。

1.5 让make自动推导

只要make看到一个[.o]文件，它就会自动的把[.c]文件加在依赖关系中，如果make找到一个whatever.o，那么whatever.c，就会是whatever.o的依赖文件。并且 cc -c whatever.c 也会被推导出来，于是，我们的makefile再也不用写得这么复杂。我们的是新的makefile又出炉了。

    objects = main.o kbd.o command.o display.o               insert.o search.o files.o utils.o    edit : $(objects)            cc -o edit $(objects)    main.o : defs.h    kbd.o : defs.h command.h    command.o : defs.h command.h    display.o : defs.h buffer.h    insert.o : defs.h buffer.h    search.o : defs.h buffer.h    files.o : defs.h buffer.h command.h    utils.o : defs.h    .PHONY : clean    clean :            rm edit $(objects)

关于更为详细的“隐晦规则”和“伪目标文件”，我会在后续给你一一道来。

1.6 另类风格的makefile

    objects = main.o kbd.o command.o display.o               insert.o search.o files.o utils.o    edit : $(objects)            cc -o edit $(objects)    $(objects) : defs.h    kbd.o command.o files.o : command.h    display.o insert.o search.o files.o : buffer.h    .PHONY : clean    clean :            rm edit $(objects)

1.7 清空目标文件的规则

        clean:            rm edit $(objects)

        .PHONY : clean        clean :                -rm edit $(objects)

上面就是一个makefile的概貌，也是makefile的基础，下面还有很多makefile的相关细节，准备好了吗？准备好了就来。

2 Makefile 总述

2.1 Makefile里有什么？

1. 显式规则。显式规则说明了，如何生成一个或多的的目标文件。这是由Makefile的书写者明显指出，要生成的文件，文件的依赖文件，生成的命令。
2. 隐晦规则。由于我们的make有自动推导的功能，所以隐晦的规则可以让我们比较粗糙地简略地书写Makefile，这是由make所支持的。
3. 变量的定义。在Makefile中我们要定义一系列的变量，变量一般都是字符串，这个有点你C语言中的宏，当Makefile被执行时，其中的变量都会被扩展到相应的引用位置上。
4. 文件指示。其包括了三个部分，一个是在一个Makefile中引用另一个Makefile，就像C语言中的include一样；另一个是指根据某些情况指定Makefile中的有效部分，就像C语言中的预编译#if一样；还有就是定义一个多行的命令。有关这一部分的内容，我会在后续的部分中讲述。
5. 注释。Makefile中只有行注释，和UNIX的Shell脚本一样，其注释是用“#”字符，这个就像C/C++中的“//”一样。如果你要在你的Makefile中使用“#”字符，可以用反斜框进行转义，如：“\#”。

最后，还值得一提的是，在Makefile中的命令，必须要以[Tab]键开始。

2.2Makefile的文件名

当然，你可以使用别的文件名来书写Makefile，比如：“Make.Linux”，“Make.Solaris”，“Make.AIX”等，如果要指定特定的Makefile，你可以使用make的“-f”和“--file”参数，如：make -f Make.Linux或make --file Make.AIX。

2.3 引用其它的Makefile

include <filename>

在include前面可以有一些空字符，但是绝不能是[Tab]键开始。include和可以用一个或多个空格隔开。举个例子，你有这样几个Makefile：a.mk、b.mk、c.mk，还有一个文件叫foo.make，以及一个变量$(bar)，其包含了e.mk和f.mk，那么，下面的语句：

    include foo.make *.mk $(bar)

    include foo.make a.mk b.mk c.mk e.mk f.mk

1. 如果make执行时，有“-I”或“--include-dir”参数，那么make就会在这个参数所指定的目录下去寻找。
2. 如果目录 /include（一般是：/usr/local/bin或/usr/include）存在的话，make也会去找。

如果有文件没有找到的话，make会生成一条警告信息，但不会马上出现致命错误。它会继续载入其它的文件，一旦完成makefile的读取，make会再重试这些没有找到，或是不能读取的文件，如果还是不行，make才会出现一条致命信息。如果你想让make不理那些无法读取的文件，而继续执行，你可以在include前加一个减号“-”。如：

-include <filename>

2.4 环境变量 MAKEFILES

但是在这里我还是建议不要使用这个环境变量，因为只要这个变量一被定义，那么当你使用make时，所有的Makefile都会受到它的影响，这绝不是你想看到的。在这里提这个事，只是为了告诉大家，也许有时候你的Makefile出现了怪事，那么你可以看看当前环境中有没有定义这个变量。

2.5 make的工作方式

1. 读入所有的Makefile。
2. 读入被include的其它Makefile。
3. 初始化文件中的变量。
4. 推导隐晦规则，并分析所有规则。
5. 为所有的目标文件创建依赖关系链。
6. 根据依赖关系，决定哪些目标要重新生成。
7. 执行生成命令。

1-5步为第一个阶段，6-7为第二个阶段。第一个阶段中，如果定义的变量被使用了，那么，make会把其展开在使用的位置。但make并不会完全马上展开，make使用的是拖延战术，如果变量出现在依赖关系的规则中，那么仅当这条依赖被决定要使用了，变量才会在其内部展开。

当然，这个工作方式你不一定要清楚，但是知道这个方式你也会对make更为熟悉。有了这个基础，后续部分也就容易看懂了。

3 Makefile书写规则

在Makefile中，规则的顺序是很重要的，因为，Makefile中只应该有一个最终目标，其它的目标都是被这个目标所连带出来的，所以一定要让make知道你的最终目标是什么。一般来说，定义在Makefile中的目标可能会有很多，但是第一条规则中的目标将被确立为最终的目标。如果第一条规则中的目标有很多个，那么，第一个目标会成为最终的目标。make所完成的也就是这个目标。

好了，还是让我们来看一看如何书写规则。

3.1 规则举例

 foo.o : foo.c defs.h       # foo模块            cc -c -g foo.c

1. 文件的依赖关系，foo.o依赖于foo.c和defs.h的文件，如果foo.c和defs.h的文件日期要比foo.o文件日期要新，或是foo.o不存在，那么依赖关系发生。
2. 如果生成（或更新）foo.o文件。也就是那个cc命令，其说明了，如何生成foo.o这个文件。（当然foo.c文件include了defs.h文件）

3.2 规则的语法

      targets : prerequisites        command        ...

      targets : prerequisites ; command            command            ...

command是命令行，如果其不与“target:prerequisites”在一行，那么，必须以[Tab键]开头，如果和prerequisites在一行，那么可以用分号做为分隔。（见上）

prerequisites也就是目标所依赖的文件（或依赖目标）。如果其中的某个文件要比目标文件要新，那么，目标就被认为是“过时的”，被认为是需要重生成的。这个在前面已经讲过了。

如果命令太长，你可以使用反斜框（‘\’）作为换行符。make对一行上有多少个字符没有限制。规则告诉make两件事，文件的依赖关系和如何成成目标文件。

一般来说，make会以UNIX的标准Shell，也就是/bin/sh来执行命令。

3.3 在规则中使用通配符

如果我们想定义一系列比较类似的文件，我们很自然地就想起使用通配符。make支持三各通配符：“*”，“?”和“[...]”。这是和Unix的B-Shell是相同的。

波浪号（“~”）字符在文件名中也有比较特殊的用途。如果是“~/test”，这就表示当前用户的$HOME目录下的test目录。而“~hchen/test”则表示用户hchen的宿主目录下的test目录。（这些都是Unix下的小知识了，make也支持）而在Windows或是MS-DOS下，用户没有宿主目录，那么波浪号所指的目录则根据环境变量“HOME”而定。

通配符代替了你一系列的文件，如“*.c”表示所以后缀为c的文件。一个需要我们注意的是，如果我们的文件名中有通配符，如：“*”，那么可以用转义字符“\”，如“\*”来表示真实的“*”字符，而不是任意长度的字符串。

好吧，还是先来看几个例子吧：

    clean:         rm -f *.o

    print: *.c         lpr -p $?         touch print

    objects = *.o

    objects := $(wildcard *.o)

3.4 文件搜寻

在一些大的工程中，有大量的源文件，我们通常的做法是把这许多的源文件分类，并存放在不同的目录中。所以，当make需要去找寻文件的依赖关系时，你可以在文件前加上路径，但最好的方法是把一个路径告诉make，让make在自动去找。

Makefile文件中的特殊变量“VPATH”就是完成这个功能的，如果没有指明这个变量，make只会在当前的目录中去找寻依赖文件和目标文件。如果定义了这个变量，那么，make就会在当当前目录找不到的情况下，到所指定的目录中去找寻文件了。

    VPATH = src:../headers

另一个设置文件搜索路径的方法是使用make的“vpath”关键字（注意，它是全小写的），这不是变量，这是一个make的关键字，这和上面提到的那个VPATH变量很类似，但是它更为灵活。它可以指定不同的文件在不同的搜索目录中。这是一个很灵活的功能。它的使用方法有三种：

1. vpath < pattern> < directories>
   为符合模式< pattern>的文件指定搜索目录< directories>。
2. vpath < pattern>
   清除符合模式< pattern>的文件的搜索目录。
3. vpath
   清除所有已被设置好了的文件搜索目录。

vapth使用方法中的< pattern>需要包含“%”字符。“%”的意思是匹配零或若干字符，例如，“%.h”表示所有以“.h”结尾的文件。< pattern>指定了要搜索的文件集，而< directories>则指定了 的文件集的搜索的目录。例如：

    vpath %.h ../headers

我们可以连续地使用vpath语句，以指定不同搜索策略。如果连续的vpath语句中出现了相同的< pattern>，或是被重复了的< pattern>，那么，make会按照vpath语句的先后顺序来执行搜索。如：

    vpath %.c foo    vpath %   blish    vpath %.c bar

    vpath %.c foo:bar    vpath %   blish

3.5 伪目标

最早先的一个例子中，我们提到过一个“clean”的目标，这是一个“伪目标”，

    clean:            rm *.o temp

因为，我们并不生成“clean”这个文件。“伪目标”并不是一个文件，只是一个标签，由于“伪目标”不是文件，所以make无法生成它的依赖关系和决定它是否要执行。我们只有通过显示地指明这个“目标”才能让其生效。当然，“伪目标”的取名不能和文件名重名，不然其就失去了“伪目标”的意义了。

当然，为了避免和文件重名的这种情况，我们可以使用一个特殊的标记“.PHONY”来显示地指明一个目标是“伪目标”，向make说明，不管是否有这个文件，这个目标就是“伪目标”。

    .PHONY : clean

     .PHONY: clean    clean:            rm *.o temp

    all : prog1 prog2 prog3    .PHONY : all    prog1 : prog1.o utils.o            cc -o prog1 prog1.o utils.o    prog2 : prog2.o            cc -o prog2 prog2.o    prog3 : prog3.o sort.o utils.o            cc -o prog3 prog3.o sort.o utils.o

随便提一句，从上面的例子我们可以看出，目标也可以成为依赖。所以，伪目标同样也可成为依赖。看下面的例子：

    .PHONY: cleanall cleanobj cleandiff    cleanall : cleanobj cleandiff            rm program    cleanobj :            rm *.o    cleandiff :            rm *.diff

3.6 多目标

Makefile的规则中的目标可以不止一个，其支持多目标，有可能我们的多个目标同时依赖于一个文件，并且其生成的命令大体类似。于是我们就能把其合并起来。当然，多个目标的生成规则的执行命令是同一个，这可能会可我们带来麻烦，不过好在我们的可以使用一个自动化变量“$@”（关于自动化变量，将在后面讲述），这个变量表示着目前规则中所有的目标的集合，这样说可能很抽象，还是看一个例子吧。

    bigoutput littleoutput : text.g            generate text.g -$(subst output,,$@) > $@
    上述规则等价于：
    bigoutput : text.g    generate text.g -big > bigoutput    littleoutput : text.g    generate text.g -little > littleoutput    

3.7 静态模式

静态模式可以更加容易地定义多目标的规则，可以让我们的规则变得更加的有弹性和灵活。我们还是先来看一下语法：

<targets ...>: <target-pattern>: <prereq-patterns ...>　　　<commands>...

targets定义了一系列的目标文件，可以有通配符。是目标的一个集合。

target-parrtern是指明了targets的模式，也就是的目标集模式。

prereq-parrterns是目标的依赖模式，它对target-parrtern形成的模式再进行一次依赖目标的定义。

这样描述这三个东西，可能还是没有说清楚，还是举个例子来说明一下吧。如果我们的定义成“%.o”，意思是我们的集合中都是以“.o”结尾的，而如果我们的 定义成“%.c”，意思是对所形成的目标集进行二次定义，其计算方法是，取模式中的“%”（也就是去掉了[.o]这个结尾），并为其加上[.c]这个结尾，形成的新集合。

所以，我们的“目标模式”或是“依赖模式”中都应该有“%”这个字符，如果你的文件名中有“%”那么你可以使用反斜杠“\”进行转义，来标明真实的“%”字符。

看一个例子：

    objects = foo.o bar.o    all: $(objects)    $(objects): %.o: %.c            $(CC) -c $(CFLAGS) ___FCKpd___34lt; -o $@

    foo.o : foo.c            $(CC) -c $(CFLAGS) foo.c -o foo.o    bar.o : bar.c            $(CC) -c $(CFLAGS) bar.c -o bar.o

    files = foo.elc bar.o lose.o    $(filter %.o,$(files)): %.o: %.c            $(CC) -c $(CFLAGS) ___FCKpd___36lt; -o $@    $(filter %.elc,$(files)): %.elc: %.el            emacs -f batch-byte-compile ___FCKpd___36lt;

$(filter %.o,$(files))表示调用Makefile的filter函数，过滤“$filter”集，只要其中模式为“%.o”的内容。其的它内容，我就不用多说了吧。这个例字展示了Makefile中更大的弹性。

3.8 自动生成依赖性

在Makefile中，我们的依赖关系可能会需要包含一系列的头文件，比如，如果我们的main.c中有一句“#include "defs.h"”，那么我们的依赖关系应该是：

    main.o : main.c defs.h

    cc -M main.c

    main.o : main.c defs.h

gcc -M main.c的输出是：

    main.o: main.c defs.h /usr/include/stdio.h /usr/include/features.h          /usr/include/sys/cdefs.h /usr/include/gnu/stubs.h          /usr/lib/gcc-lib/i486-suse-linux/2.95.3/include/stddef.h          /usr/include/bits/types.h /usr/include/bits/pthreadtypes.h          /usr/include/bits/sched.h /usr/include/libio.h          /usr/include/_G_config.h /usr/include/wchar.h          /usr/include/bits/wchar.h /usr/include/gconv.h          /usr/lib/gcc-lib/i486-suse-linux/2.95.3/include/stdarg.h          /usr/include/bits/stdio_lim.h

    main.o: main.c defs.h

于是，我们可以写出[.c]文件和[.d]文件的依赖关系，并让make自动更新或自成[.d]文件，并把其包含在我们的主Makefile中，这样，我们就可以自动化地生成每个文件的依赖关系了。

这里，我们给出了一个模式规则来产生[.d]文件：

    %.d: %.c            @set -e; rm -f $@;              $(CC) -M $(CPPFLAGS) ___FCKpd___42lt; > $@.$$;              sed 's,\($*\)\.o[ :]*,\1.o $@ : ,g' < $@.$$ > $@;              rm -f $@.$$

这个规则的意思是，所有的[.d]文件依赖于[.c]文件，“rm -f $@”的意思是删除所有的目标，也就是[.d]文件，第二行的意思是，为每个依赖文件“$<”，也就是[.c]文件生成依赖文件，“$@”表示模式“%.d”文件，如果有一个C文件是name.c，那么“%”就是“name”，“$$$$”意为一个随机编号，第二行生成的文件有可能是“name.d.12345”，第三行使用sed命令做了一个替换，关于sed命令的用法请参看相关的使用文档。第四行就是删除临时文件。

总而言之，这个模式要做的事就是在编译器生成的依赖关系中加入[.d]文件的依赖，即把依赖关系：

    main.o : main.c defs.h

    main.o main.d : main.c defs.h

    sources = foo.c bar.c    include $(sources:.c=.d)

4 Makefile 书写命令

每条规则中的命令和操作系统Shell的命令行是一致的。make会一按顺序一条一条的执行命令，每条命令的开头必须以[Tab]键开头，除非，命令是紧跟在依赖规则后面的分号后的。在命令行之间中的空格或是空行会被忽略，但是如果该空格或空行是以Tab键开头的，那么make会认为其是一个空命令。

我们在UNIX下可能会使用不同的Shell，但是make的命令默认是被“/bin/sh”——UNIX的标准Shell解释执行的。除非你特别指定一个其它的Shell。Makefile中，“#”是注释符，很像C/C++中的“//”，其后的本行字符都被注释。

4.1 显示命令

通常，make会把其要执行的命令行在命令执行前输出到屏幕上。当我们用“@”字符在命令行前，那么，这个命令将不被make显示出来，最具代表性的例子是，我们用这个功能来像屏幕显示一些信息。如：

    @echo 正在编译XXX模块......

    echo 正在编译XXX模块......    正在编译XXX模块......

而make参数“-s”或“--slient”则是全面禁止命令的显示。

4.2 命令执行

当依赖目标新于目标时，也就是当规则的目标需要被更新时，make会一条一条的执行其后的命令。需要注意的是，如果你要让上一条命令的结果应用在下一条命令时，你应该使用分号分隔这两条命令。比如你的第一条命令是cd命令，你希望第二条命令得在cd之后的基础上运行，那么你就不能把这两条命令写在两行上，而应该把这两条命令写在一行上，用分号分隔。如：

    示例一：        exec:                cd /home/hchen                pwd    示例二：        exec:                cd /home/hchen; pwd

当我们执行“make exec”时，第一个例子中的cd没有作用，pwd会打印出当前的Makefile目录，而第二个例子中，cd就起作用了，pwd会打印出“/home/hchen”。

make一般是使用环境变量SHELL中所定义的系统Shell来执行命令，默认情况下使用UNIX的标准Shell——/bin/sh来执行命令。但在MS-DOS下有点特殊，因为MS-DOS下没有SHELL环境变量，当然你也可以指定。如果你指定了UNIX风格的目录形式，首先，make会在SHELL所指定的路径中找寻命令解释器，如果找不到，其会在当前盘符中的当前目录中寻找，如果再找不到，其会在PATH环境变量中所定义的所有路径中寻找。MS-DOS中，如果你定义的命令解释器没有找到，其会给你的命令解释器加上诸如“.exe”、“.com”、“.bat”、“.sh”等后缀。

4.3 命令出错

每当命令运行完后，make会检测每个命令的返回码，如果命令返回成功，那么make会执行下一条命令，当规则中所有的命令成功返回后，这个规则就算是成功完成了。如果一个规则中的某个命令出错了（命令退出码非零），那么make就会终止执行当前规则，这将有可能终止所有规则的执行。

有些时候，命令的出错并不表示就是错误的。例如mkdir命令，我们一定需要建立一个目录，如果目录不存在，那么mkdir就成功执行，万事大吉，如果目录存在，那么就出错了。我们之所以使用mkdir的意思就是一定要有这样的一个目录，于是我们就不希望mkdir出错而终止规则的运行。

为了做到这一点，忽略命令的出错，我们可以在Makefile的命令行前加一个减号“-”（在Tab键之后），标记为不管命令出不出错都认为是成功的。如：

   clean:            -rm -f *.o

还有一个要提一下的make的参数的是“-k”或是“--keep-going”，这个参数的意思是，如果某规则中的命令出错了，那么就终目该规则的执行，但继续执行其它规则。

4.4 嵌套执行make

在一些大的工程中，我们会把我们不同模块或是不同功能的源文件放在不同的目录中，我们可以在每个目录中都书写一个该目录的Makefile，这有利于让我们的Makefile变得更加地简洁，而不至于把所有的东西全部写在一个Makefile中，这样会很难维护我们的Makefile，这个技术对于我们模块编译和分段编译有着非常大的好处。

例如，我们有一个子目录叫subdir，这个目录下有个Makefile文件，来指明了这个目录下文件的编译规则。那么我们总控的Makefile可以这样书写：

    subsystem:            cd subdir && $(MAKE)其等价于：    subsystem:            $(MAKE) -C subdir
定义$(MAKE)宏变量的意思是，也许我们的make需要一些参数，所以定义成一个变量比较利于维护。这两个例子的意思都是先进入“subdir”目录，然后执行make命令。我们把这个Makefile叫做“总控Makefile”，总控Makefile的变量可以传递到下级的Makefile中（如果你显示的声明），但是不会覆盖下层的Makefile中所定义的变量，除非指定了“-e”参数。如果你要传递变量到下级Makefile中，那么你可以使用这样的声明：
export <variable ...>

unexport <variable ...>

        示例一：        export variable = value        其等价于：        variable = value        export variable        其等价于：        export variable := value        其等价于：        variable := value        export variable    示例二：        export variable += value        其等价于：        variable += value        export variable

需要注意的是，有两个变量，一个是SHELL，一个是MAKEFLAGS，这两个变量不管你是否export，其总是要传递到下层Makefile中，特别是MAKEFILES变量，其中包含了make的参数信息，如果我们执行“总控Makefile”时有make参数或是在上层Makefile中定义了这个变量，那么MAKEFILES变量将会是这些参数，并会传递到下层Makefile中，这是一个系统级的环境变量。

但是make命令中的有几个参数并不往下传递，它们是“-C”,“-f”,“-h”“-o”和“-W”（有关Makefile参数的细节将在后面说明），如果你不想往下层传递参数，那么，你可以这样来：

        subsystem:            cd subdir && $(MAKE) MAKEFLAGS=

还有一个在“嵌套执行”中比较有用的参数，“-w”或是“--print-directory”会在make的过程中输出一些信息，让你看到目前的工作目录。比如，如果我们的下级make目录是“/home/hchen/gnu/make”，如果我们使用“make -w”来执行，那么当进入该目录时，我们会看到：

        make: Entering directory `/home/hchen/gnu/make'.

        make: Leaving directory `/home/hchen/gnu/make'

4.5 定义命令包

如果Makefile中出现一些相同命令序列，那么我们可以为这些相同的命令序列定义一个变量。定义这种命令序列的语法以“define”开始，以“endef”结束，如：

    define run-yacc    yacc $(firstword $^)    mv y.tab.c $@    endef

    foo.c : foo.y            $(run-yacc)

COMPRESSED KERNEL and DECOMPRESSED KERNEL

压缩后的KERNEL,按照文档资料,现在不提倡使用DECOMPRESSED KERNEL,而要使用COMPRESSED KERNEL,它包括了解压器.因此要在ram分配时给压缩和解压的KERNEL提供足够空间,这样它们不会相互覆盖.

当执行指令跳转到COMPRESSED KERNEL后,解压器就开始工作,如果解压器探测到解压的代码会覆盖掉COMPRESSED KERNEL,那它会直接跳到COMPRESSED KERNEL后存放数据,并且重新定位KERNEL,所以如果没有足够空间,就会出错.

Jffs2 File System

可以使armlinux应用中产生的数据保存在FLASH上,我的板子还没用到这个.

RAMDISK

使用RAMDISK可以使ROOT FILE SYSTEM在没有其他设备的情况下启动.一般有两种加载方式,我就介绍最常用的吧,把COMPRESSED RAMDISK IMAGE放到指定地址,然后由BOOTLOADER把这个地址通过启动参数的方式ATAG_INITRD2传递给KERNEL.具体看代码分析.

启动参数(摘自IBM developer)

在调用内核之前，应该作一步准备工作，即：设置 Linux 内核的启动参数。Linux 2.4.x 以后的内核都期望以标记列表(tagged list)的形式来传递启动参数。启动参数标记列表以标记 ATAG_CORE 开始，以标记 ATAG_NONE 结束。每个标记由标识被传递参数的 tag_header 结构以及随后的参数值数据结构来组成。数据结构 tag 和 tag_header 定义在 Linux 内核源码的include/asm/setup.h 头文件中.

在嵌入式 Linux 系统中，通常需要由 BOOTLOADER 设置的常见启动参数有：ATAG_CORE、ATAG_MEM、ATAG_CMDLINE、ATAG_RAMDISK、ATAG_INITRD等。

(注)参数也可以用COMMANDLINE来设定,在我的BOOTLOADER里,我两种都用了.

2.开发环境和开发板配置:

CPU:S3C2410,BANK6上有64M的SDRAM(两块),BANK0上有32M NOR FLASH,串口当然是逃不掉的.这样,按照数据手册,地址分配如下:

0x4000_0000开始是4k的片内DRAM.

0x0000_0000开始是32M FLASH 16bit宽度

0x3000_0000开始是64M SDRAM 32bit宽度

注意:控制寄存器中的BANK6和BANK7部分必须相同.

0x4000_0000(片内DRAM)存放4k以内的BOOTLOADER IMAGE

0x3000_0100开始存放启动参数

0x3120_0000 存放COMPRESSED KERNEL IMAGE

0x3200_0000 存放COMPRESSED RAMDISK

0x3000_8000 指定为DECOMPRESSED KERNEL IMAGE ADDRESS

0x3040_0000 指定为DECOMPRESSED RAMDISK IMAGE ADDRESS

开发环境:Redhat Linux,armgcc toolchain, armlinux KERNEL

如何建立armgcc的编译环境:建议使用toolchain,而不要自己去编译armgcc,偶试过好多次,都以失败告终.

先下载arm-gcc 3.3.2 toolchain

将arm-linux-gcc-3.3.2.tar.bz2 解压到 /toolchain

# tar jxvf arm-linux-gcc-3.3.2.tar.bz2

# mv /usr/local/arm/3.3.2 /toolchain

在makefile 中在把arch=arm CROSS_COMPILE设置成toolchain的路径

还有就是INCLUDE = -I ../include -I /root/my/usr/local/arm/3.3.2/include.,否则库函数就不能用了

3.启动方式:

可以放在FLASH里启动,或者用Jtag仿真器.由于使用NOR FLASH,根据2410的手册,片内的4K DRAM在不需要设置便可以直接使用,而其他存储器必须先初始化,比如告诉memory controller,BANK6里有两块SDRAM,数据宽度是32bit,= =.否则memory control会按照复位后的默认值来处理存储器.这样读写就会产生错误.

所以第一步,通过仿真器把执行代码放到0x4000_0000,(在编译的时候,设定TEXT_BAS

E=0x40000000)

第二步,通过 AxD把linux KERNEL IMAGE放到目标地址(SDRAM)中,等待调用

第三步,执行BOOTLOADER代码,从串口得到调试数据,引导armlinux

4.代码分析

讲了那么多执行的步骤,是想让大家对启动有个大概印象,接着就是BOOTLOADER内部的代码分析了,BOOTLOADER文章内容网上很多,我这里精简了下,删除了不必要的功能.

BOOTLOADER一般分为2部分,汇编部分和c语言部分,汇编部分执行简单的硬件初始化,C部分负责复制数据,设置启动参数,串口通信等功能.

BOOTLOADER的生命周期:

1. 初始化硬件,比如设置UART(至少设置一个),检测存储器= =.

2. 设置启动参数,这是为了告诉内核硬件的信息,比如用哪个启动界面,波特率 = =.

3. 跳转到Linux KERNEL的首地址.

4. 消亡

当然,在引导阶段,象vivi等,都用虚地址,如果你嫌烦的话,就用实地址,都一样.

我们来看代码:

2410init.s

.global _start//开始执行处

_start:

//下面是中断向量

b reset @ Supervisor Mode//重新启动后的跳转

……

……

reset:

ldr r0,=WTCON /WTCON地址为53000000,watchdog的控制寄存器 */

ldr r1,=0x0 /*关watchdog*/

str r1,[r0]

ldr r0,=INTMSK

ldr r1,=0xffffffff /*屏蔽所有中断*/

str r1,[r0]

ldr r0,=INTSUBMSK

ldr r1,=0x3ff /*子中断也一样*/

str r1,[r0]

/*Initialize Ports...for display LED.*/

ldr r0, =GPFCON

ldr r1, =0x55aa

str r1, [r0]

ldr r0, =GPFUP

ldr r1, =0xff

str r1, [r0]

ldr r0,=GPFDAT

ldr r1,=POWEROFFLED1

str r1,[r0]

/* Setup clock Divider control register

* you must configure CLKDIVN before LOCKTIME or MPLL UPLL

* because default CLKDIVN 1,1,1 set the SDMRAM Timing Conflict

nop

* FCLK:HCLK:PCLK = 1:2:4 in this case

*/

ldr r0,=CLKDIVN

ldr r1,=0x3

str r1,[r0]

/*To reduce PLL lock time, adjust the LOCKTIME register. */

ldr r0,=LOCKTIME

ldr r1,=0xffffff

str r1,[r0]

/*Configure MPLL */

ldr r0,=MPLLCON

ldr r1,=((M_MDIV<<12)+(M_PDIV<<4)+M_SDIV) //Fin=12MHz,Fout=203MHz

str r1,[r0]

ldr r1,=GSTATUS2

ldr r10,[r1]

tst r10,#OFFRST

bne 1000f

//以上这段,我没动,就用三星写的了,下面是主要要改的地方

/* MEMORY C0NTROLLER(MC)设置*/

add r0,pc,#MCDATA - (.+8)// r0指向MCDATA地址,那里存放着MC初始化要用到的数据

ldr r1,=BWSCON // r1指向MC控制器寄存器的首地址

add r2,r0,#52 // 复制次数,偏移52字

1: //按照偏移量进行循环复制

ldr r3,[r0],#4

str r3,[r1],#4

cmp r2,r0

bne 1b

.align 2

MCDATA:

.word (0+(B1_BWSCON<<4)+(B2_BWSCON<<8)+(B3_BWSCON<<12)+(B4_BWSCON<<16)+(B5_BWSCON<<20)+(B6_BWSCON<<24)+(B7_BWSCON<<28))

上面这行就是BWSCON的数据,具体参数意义如下:

需要更改设置DW6 和DW7都设置成10,即32bit,DW0 设置成01,即16bit

下面都是每个BANK的控制器数据,大都是时钟相关,可以用默认值,设置完MC后,就跳到调用main函数的部分

.word ((B0_Tacs<<13)+(B0_Tcos<<11)+(B0_Tacc<<8)+(B0_Tcoh<<6)+(B0_Tah<<4)+(B0_Tacp<<2)+(B0_PMC))

.word ((B1_Tacs<<13)+(B1_Tcos<<11)+(B1_Tacc<<8)+(B1_Tcoh<<6)+(B1_Tah<<4)+(B1_Tacp<<2)+(B1_PMC))

.word ((B2_Tacs<<13)+(B2_Tcos<<11)+(B2_Tacc<<8)+(B2_Tcoh<<6)+(B2_Tah<<4)+(B2_Tacp<<2)+(B2_PMC))

.word ((B3_Tacs<<13)+(B3_Tcos<<11)+(B3_Tacc<<8)+(B3_Tcoh<<6)+(B3_Tah<<4)+(B3_Tacp<<2)+(B3_PMC))

.word ((B4_Tacs<<13)+(B4_Tcos<<11)+(B4_Tacc<<8)+(B4_Tcoh<<6)+(B4_Tah<<4)+(B4_Tacp<<2)+(B4_PMC))

.word ((B5_Tacs<<13)+(B5_Tcos<<11)+(B5_Tacc<<8)+(B5_Tcoh<<6)+(B5_Tah<<4)+(B5_Tacp<<2)+(B5_PMC))

.word ((B6_MT<<15)+(B6_Trcd<<2)+(B6_SCAN))

.word ((B7_MT<<15)+(B7_Trcd<<2)+(B7_SCAN))

.word ((REFEN<<23)+(TREFMD<<22)+(Trp<<20)+(Trc<<18)+(Tchr<<16)+REFCNT)

.word 0xB2 /* REFRESH Control Register */

.word 0x30 /* BANKSIZE Register : Burst Mode */

.word 0x30 /* SDRAM Mode Register */

.align 2

.global call_main //调用main函数,函数参数都为0

call_main:

ldr sp,STACK_START

mov fp,#0 /* no previous frame, so fp=0*/

mov a1, #0 /* set argc to 0*/

mov a2, #0 /* set argv to NUL*/

bl main /* call main*/

STACK_START:

.word STACK_BASE

undefined_instruction:

software_interrupt:

prefetch_abort:

data_abort:

not_used:

irq:

fiq:

/*以上是主要的汇编部分,实现了时钟设置,串口设置watchdog关闭,中断关闭功能(如果有需要还可以降频使用),然后转入main*/

2410init.c file

int main(int argc,char **argv)

{

u32 test = 0;

void (*theKERNEL)(int zero, int arch, unsigned long params_addr) = (void (*)(int, int, unsigned long))RAM_COMPRESSED_KERNEL_BASE; //压缩后的IMAGE地址

int i,k=0;

// downPt=(RAM_COMPRESSED_KERNEL_BASE);

chkBs=(_RAM_STARTADDRESS);//SDRAM开始的地方

// fromPt=(FLASH_LINUXKERNEL);

MMU_EnableICache();

ChangeClockDivider(1,1); // 1:2:4

ChangeMPllvalue(M_MDIV,M_PDIV,M_SDIV); //Fin=12MHz FCLK=200MHz

Port_Init();//设置I/O端口,在使用com口前,必须调用这个函数,否则通信芯片根本得不到数据

Uart_Init(PCLK, 115200);//PCLK使用默认的200000,拨特率115200

/*******************(检查ram空间)*******************/

Uart_SendString("\n\tLinux S3C2410 Nor BOOTLOADER\n");

Uart_SendString("\n\tChecking SDRAM 2410loader.c...\n");

for(;chkBs<0x33FA0140;chkBs=chkBs+0x4,test++)//

//根据我的经验,最好以一个字节为递增,我们的板子,在256byte递增检测的时候是没问题的,但是

//以1byte递增就出错了,第13跟数据线随几的会冒”1”,检测出来是硬件问题,现象如下

//用仿真器下代码测试SDRAM，开始没贴28F128A3J FLASH片子，测试结果很好，但在上了FLASH片子//之后，测试数据（data）为0x00000400连续成批写入读出时，操作大约1k左右内存空间就会出错，//而且随机。那个出错数据总是变为0x00002400，数据总线10位和13位又没短路发生。用其他数据//测试比如0x00000200；0x00000800没这问题。dx帮忙。

//至今没有解决,所以我用不了Flash.

{

chkPt1 = chkBs;

*(u32 *)chkPt1 = test;//写数据

if(*(u32 *)chkPt1==1024))//读数据和写入的是否一样?

{

chkPt1 += 4;

Led_Display(1);

Led_Display(2);

Led_Display(3);

Led_Display(4);

}

else

goto error;

}

Uart_SendString("\n\tSDRAM Check Successful!\n\tMemory Maping...");

get_memory_map();

//获得可用memory 信息,做成列表,后面会作为启动参数传给KERNEL

//所谓内存映射就是指在4GB 物理地址空间中有哪些地址范围被分配用来寻址系统的 RAM 单元。

Uart_SendString("\n\tMemory Map Successful!\n");

//我用仿真器把KERNEL,RAMDISK直接放在SDRAM上,所以下面这段是不需要的,但是如果KERNEL,RAMDISK在FLASH里,那就需要.

/*******************(copy linux KERNEL)*******************/

Uart_SendString("\tLoading KERNEL IMAGE from FLASH... \n ");

Uart_SendString("\tand copy KERNEL IMAGE to SDRAM at 0x31000000\n");

Uart_SendString("\t\tby LEIJUN DONG dongleijun4000@hotmail.com \n");

for(k = 0;k < 196608;k++,downPt += 1,fromPt += 1)//3*1024*1024/32linux KERNEL des,src,length=3M

* (u32 *)downPt = * (u32 *)fromPt;

/*******************(load RAMDISK)*******************/

Uart_SendString("\t\tloading COMPRESSED RAMDISK...\n");

downPt=(RAM_COMPRESSED_RAMDISK_BASE);

fromPt=(FLASH_RAMDISK_BASE);

for(k = 0;k < 196608;k++,downPt += 1,fromPt += 1)//3*1024*1024/32linux KERNEL des,src,length=3M

* (u32 *)downPt = * (u32 *)fromPt;

/******jffs2文件系统,在开发中如果用不到FLASH,这段也可以不要********/

Uart_SendString("\t\tloading jffs2...\n");

downPt=(RAM_JFFS2);

fromPt=(FLASH_JFFS2);

for(k = 0;k < (1024*1024/32);k++,downPt += 1,fromPt += 1)

* (u32 *)downPt = * (u32 *)fromPt;

Uart_SendString( "Load Success...Run...\n ");

/*******************(setup param)*******************/

setup_start_tag();//开始设置启动参数

setup_memory_tags();//内存印象

setup_commandline_tag("console=ttyS0,115200n8");//启动命令行

setup_initrd2_tag();//root device

setup_RAMDISK_tag();//ramdisk image

setup_end_tag();

/*关I-cache */

asm ("mrc p15, 0, %0, c1, c0, 0": "=r" (i));

i &= ~0x1000;

asm ("mcr p15, 0, %0, c1, c0, 0": : "r" (i));

/* flush I-cache */

asm ("mcr p15, 0, %0, c7, c5, 0": : "r" (i));

//下面这行就跳到了COMPRESSED KERNEL的首地址

theKERNEL(0, ARCH_NUMBER, (unsigned long *)(RAM_BOOT_PARAMS));

//启动kernel时候,I-cache可以开也可以关,r0必须是0,r1必须是CPU型号

(可以从linux/arch/arm/tools/mach-types中找到),r2必须是参数的物理开始地址

/*******************END*******************/

error:

Uart_SendString("\n\nPanic SDRAM check error!\n");

return 0;

}

static void setup_start_tag(void)

{

params = (struct tag *)RAM_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);

}

static void setup_memory_tags(void)

{

int i;

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].len;

params = tag_next(params);

}

}

}

static void setup_commandline_tag(char *commandline)

{

int i = 0;

/* skip non-existent command lines so the kernel will still

* use its default command line.

*/

params->hdr.tag = ATAG_CMDLINE;

params->hdr.size = 8;

//console=ttyS0,115200n8

strcpy(params->u.cmdline.cmdline, p);

params = tag_next(params);

}

static void setup_initrd2_tag(void)

{

/* an ATAG_INITRD node tells the kernel where the compressed

* ramdisk can be found. ATAG_RDIMG is a better name, actually.

*/

params->hdr.tag = ATAG_INITRD2;

params->hdr.size = tag_size(tag_initrd);

params->u.initrd.start = RAM_COMPRESSED_RAMDISK_BASE;

params->u.initrd.size = 2047;//k byte

params = tag_next(params);

}

static void setup_ramdisk_tag(void)

{

/* an ATAG_RAMDISK node tells the kernel how large the

* decompressed ramdisk will become.

*/

params->hdr.tag = ATAG_RAMDISK;

params->hdr.size = tag_size(tag_ramdisk);

params->u.ramdisk.start = RAM_DECOMPRESSED_RAMDISK_BASE;

params->u.ramdisk.size = 7.8*1024; //k byte

params->u.ramdisk.flags = 1; // automatically load ramdisk

params = tag_next(params);

}

static void setup_end_tag(void)

{

params->hdr.tag = ATAG_NONE;

params->hdr.size = 0;

} void Uart_Init(int pclk,int baud)//串口是很重要的

{

int i;

if(pclk == 0)

pclk = PCLK;

rUFCON0 = 0x0; //UART channel 0 FIFO control register, FIFO disable

rUMCON0 = 0x0; //UART chaneel 0 MODEM control register, AFC disable

//UART0

rULCON0 = 0x3; //Line control register : Normal,No parity,1 stop,8 bits

下面这段samsung好象写的不太对,但是我按照Normal,No parity,1 stop,8 bits算出来的确是0x245

// [10] [9] [8] [7] [6] [5] [4] [3:2] [1:0]

// Clock Sel, Tx Int, Rx Int, Rx Time Out, Rx err, Loop-back, Send break, Transmit Mode, Receive Mode

// 0 1 0 , 0 1 0 0 , 01 01

// PCLK Level Pulse Disable Generate Normal Normal Interrupt or Polling

rUCON0 = 0x245; // Control register

rUBRDIV0=( (int)(PCLK/16./ baud) -1 ); //Baud rate divisior register 0

delay(10);

}

经过以上的折腾,接下来就是kernel的活了.能不能启动kernel,得看你编译kernel的水平了.

这个BOOTLOADER不象blob那样需要交互信息,使用虚拟地址,总的来说非常简洁明了.

图1 固态存储设备的典型空间分配结构

      3. 用来控制 Boot Loader 的设备或机制

      主机和目标机之间一般通过串口建立连接，Boot Loader 软件在执行时通常会通过串口来进行 I/O，比如：输出打印信息到串口，从串口读取用户控制字符等。

      4. Boot Loader 的启动过程是单阶段（Single Stage）还是多阶段（Multi-Stage）

      通常多阶段的 Boot Loader 能提供更为复杂的功能，以及更好的可移植性。从固态存储设备上启动的 Boot Loader 大多都是 2 阶段的启动过程，也即启动过程可以分为 stage 1和 stage 2 两部分。而至于在 stage 1 和 stage 2 具体完成哪些任务将在下面几篇讨论。

      5. Boot Loader 的操作模式 (Operation Mode)

      大多数 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 内核。

      6. BootLoader 与主机之间进行文件传输所用的通信设备及协议

      最常见的情况就是，目标机上的 Boot Loader 通过串口与主机之间进行文件传输，传输协议通常是 xmodem／ymodem／zmodem 协议中的一种。但是，串口传输的速度是有限的，因此通过以太网连接并借助 TFTP 协议来下载文件是个更好的选择。

      此外，在论及这个话题时，主机方所用的软件也要考虑。比如，在通过以太网连接和 TFTP 协议来下载文件时，主机方必须有一个软件用来的提供 TFTP 服务。在讨论了 BootLoader 的上述概念后，下面我们来具体看看 BootLoader 的应该完成哪些任务。

三、Boot Loader 的主要任务与典型结构框架

    在继续本节的讨论之前，首先我们做一个假定，那就是：假定内核映像与根文件系统映像都被加载到 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 Boot Loader 的 stage1

    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 寄存器为合适的地址来实现。

 

    3.2 Boot Loader 的 stage2

    正如前面所说，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 的设计与实现是一个非常复杂的过程。如果不能从串口收到那激动人心的内核启动信息，恐怕谁也不能说："嗨，我的 boot loader 已经成功地转起来了！"。 
 

　　指令Cache的容量从16KB增加到32KB；

　　微小数据Cache的容量从512B增加到2KB；

　　为了提高指令的执行速度，超级流水线结构由5级增至7级；

　　新增乘/加法器MAC和特定的DSP型协处理器CP0，以提高对多媒体技术的支持；

　　动态电源管理，使XScale处理器的时钟可达1GHz、功耗1.6W，并能达到1200MIPS。 
　　
　　XScale微处理器架构经过专门设计，核心采用了英特尔先进的0.18μm工艺技术制造；具备低功耗特性，适用范围从0.1mW～1.6W。同时，它的时钟工作频率将接近1GHz。 XScale与StrongARM相比，可大幅降低工作电压并且获得更高的性能。具体来讲，在目前的StrongARM中，在1.55V下可以获得133MHz的工作频率，在2.0V下可以获得206MHz的工作频率；而采用XScale后，在0.75V时工作频率达到150MHz，在1.0V时工作频率可以达到400MHz，在1.65V下工作频率则可高达800MHz。超低功率与高性能的组合使Intel XScale适用于广泛的互联网接入设备，在因特网的各个环节中，从手持互联网设备到互联网基础设施产品，Intel XScale都表现出了令人满意的处理性能。

　　2 PXA250的结构及特点

　　Intel XScale PXA250结构框图如图1所示。 

　　2.1 PXA250处理器的主要特点

　　(1)高性能

　　低功耗，高性能的32位Intel XScale处理器内核，工作频率高达400MHz；

　　兼容ARMv5TE架构；

　　采用7级超级流水线结构；

　　支持多媒体处理技术，采用40位累加器和16位乘法器,以增强对音频和视频的解码能力；

　　提供支持同步Intel StrataFlash存储器的高性能分帧和分页模式接口。 

　　(2)低功耗

　　多电源管理模式；

　　32KB数据和32KB指令Cache；

　　2KB的微小数据Cache；

　　支持2.5V和3.3V的存储器。 

　　(3)I/O扩展

　　100MHz存储器总线，6个静态存储空间(16或32位ROM(SMROM)/Flash/SRAM)，4个动态存储分区(16或32位SDRAM)；

　　支持2个PCMCIA 或 Compact Flash槽。 

　　(4)外围控制模块

　　16通道可配置DMA控制器；

　　LCD控制器，独有的支持对快变彩屏的DMA方式；

　　920kbps Bluetooth接口；

　　串行端口(IrDA、I2C、I2S、AC97、3个UARTs、SPI 和SSP)；

　　USB接口；

　　支持MMC/SD卡。 

　　(5)时钟控制

　　五种时钟源：

　　32.768kHz振荡器；

　　3.6864MHz振荡器；

　　可编程的内核锁相环；

　　95.85MHz外围固定频率锁相环；

　　147.46MHz固定频率锁相环。 

　　(6)电源管理

　　运行模式(正常处理模式)、Turbo模式(运行于400MHZ)、空闲模式(下电)、睡眠模式(下电)。

　　(7)封装形式

　　17mm×17 mm 256脚PBGA封装。

　　2.2 Intel XScale内核

　　Intel XScale CPU内核采用带有一个增强型存储器管道的超级流水线RISC处理器架构的体系结构。这款新型高性能、低功耗的微构架兼容ARMv5TE ISA指令集(不支持浮点指令集)。这种微构架在ARM核的周围提供了指令与数据存储器管理单元，指令、数据和微小数据Cache，写缓冲、全缓冲、挂起缓冲和分支目标缓冲器，电源管理，性能监控、调试和JTAG单元以及协处理器接口，MAC协处理器和内核存储总线。

　　超级流水线结构是由整型管道、存储器管道和MAC管道构成。整型管道包括7级流水线结构，取指令1(分支目标缓冲器)→取指令2→译码→寄存/移位→ALU实现→状态执行→回复；存储器管道除包括整型管道的前5级外，后接3个高速缓存，数据Cache1、数据Cache2和数据回复Cache，共8级流水线结构；MAC管道是6~9级的流水线结构，包括整型管道的前4级和4级MAC段，以及一个数据回复Cache，其中MAC2-4的选通由数据决定。流水线结构级数越多越能提高指令的执行速度，使用分支目标缓冲器的目的在于成功的预知分支指令的 结果。128个入口的分支目标缓冲器的每个入口都包含了分支指令的地址、与分支指令相联系的目标地址以及该分支的执行情况，它由协处理器15使能。分支目标缓冲器的使用旨在避免超级流水线结构中的分支延迟。

　　PXA250 CPU的MM(IMMU和DMMU)均提供了一个32项的转换旁路缓存器(ITLB和DTLB)，它们的每一项均可映射存储器中的段、大页和小页。为了保证内核周期的存取指令和数据，PXA250包含了1个32KB的指令Cache和1个32KB的数据Cache。另外，为了避免数据Cache内数据流存取的频繁变化，还提供了1个2KB的微小数据Cache。指令和数据Cache都是具有32个入口和32路相联的Cache，每路均包含1个标志地址，32字节的高速缓存队列和1个有效位，采用循环方式进行刷新存储。微小数据Cache是1个具有32个入口和2路相联的Cache，同样采用循环方式进行刷新存储。

　　PXA250内核还提供了4个入口的全缓冲和挂起缓冲，用于提升内核性能，与数据Cache和微小数据Cache协同工作。此外，1个8入口的写缓冲，每个入口可保存16字节，它从内核、数据Cache或微小数据Cache中得到数据，在系统总线选通前，暂存数据。

　　2.3 系统控制功能

　　PXA250的系统控制模块提供了实时时钟、看门狗及间隔定时器、功率管理控制器、中断控制器、复位控制器和2个片上振荡器。该系统定时器支持源自SA-11x0处理器的定时器单元，OS定时器使用3.6864MHz振荡器，包含了4个定时匹配寄存器(OSMR)、1个定时状态寄存器(OSSR)和1个定时中断使能寄存器(OIER)。看门狗定时中断可以通过激活OS定时看门狗使能寄存器(OWER)来实现。
中断控制器处理的所有中断源，有两个中断类型：中断请求(IRQ)和快速中断请求(FIQ)。中断控制器可以根据掩码寄存器的值，允许CPU被中断或保持预中断。中断控制器中的每一个寄存器都是1比特映射，并且每一比特均被预先分配给不同的中断源。

　　2.4 时钟和电源管理

　　为了达到处理性能和能量消耗之间比例的最优化，用时钟和电源管理器来控制不同模块的时钟频率并处理不同能量管理操作模式之间的转化。时钟和电源管理器为每一个外设提供了固定的时钟，并且为LCD控制器、存储器控制器和CPU提供了可编程的频率时钟，这些时钟均来自内部锁相环时钟源。时钟管理器还可通过关闭不用设备的时钟来减少功率损耗。

　　电源管理提供了四种工作模式：Turbo模式、运行模式、空闲模式和睡眠模式。Turbo模式下，CPU核运行在峰值频率，为避免内核对外部存储器的等待时间，在该模式下，很少对外部存储器进行存取；运行模式下，CPU核运行于正常标准频率，可以假定内核不断地对外部存储器进行存取，运行速率的减慢对于性能与功耗的最佳平衡是有利的；在空闲模式下，暂停到CPU的时钟，但是使能到外围器件的时钟；睡眠模式下，整个系统将处于最低功耗状态，要唤醒睡眠状态必须重新启动系统。

　　2.5 存储器和PCMCIA/Compact Flash控制模块

　　PXA250处理器的外部存储器总线接口支持同步动态存储器(SDRAM)、同步和异步分页模式段、页模式闪存、同步掩码只读存储器(SMROM)、页模式ROM、SRAM、静态段支持可变等待时间的I/O设备(VLIO)、16位的PC卡扩展存储器和Compact Flash。存储器的类型可通过存储器接口配置寄存器决定。

　　2.6 外围控制模块

　　PXA250处理器定义了16个通道的DMA控制器。它可响应内部和外部设备的请求，完成数据从主存储器中读出与写入。DMAC用于外围设备与存储系统之间的数据传输。

　　LCD控制器提供了支持双扫描无源阵列彩显(DSTN，俗称伪彩)或有源阵列彩显(TFT，俗称真彩)屏的接口，并支持单色和多色素格式。它拥有自己独立的双通道DMA控制器，两路通道分别用于单面板和双面板显示。最大支持显示分辨率为1024×1024像素，推荐最高分辨率为800×600像素。在无源单色模式下，最高支持256级灰度。对于彩色显示，不管有源还是无源模式，最高均支持65536种颜色。LCD控制器将帧缓存中的像素编码值，对应于16位宽的256个入口的调色板RAM，根据数据宽度决定彩色的数量。

　　PXA250处理器支持的串口包括：基于通用串行总线1.1版本的USB客户服务模块接口，它最高支持16个端点外挂，并提供了1个48MHz的内部时钟；3个通用异步收发口(UART)，最高速率230Kbps的全功能UART(完备的握手信号)，最高速率921Kbps蓝牙UART和标准UART；高速红外通信口(FICP)半双工，速率4Mbps，执行4PPM标准；AC97控制器支持AC97 2.0修订版本的多媒体数字信号编解码器，AC97控制器对于立体PCM输入输出，Modem输入输出和单一的麦克风输入都提供了单独的16位通道；I2S控制器为数字立体声标准I2S多媒体数字信号编解码器提供了串行连接，复用AC97控制器引脚；I2C总线接口提供了2个引脚的通用串行通信端口，2个引脚分别用于数据地址和时钟；另外，提供了2个支持MMC或SPI协议，高达20Mbps串行数据传输的MMC卡接口和一个SSP接口。SSP逻辑接口支持National Microwire协议、Texas Instruments协议、同步串行协议(SSP)和Motorola SPI协议，所有这些协议都用于A/D转换、音频和电信多媒体数字信号编解码器和其它满足串行数据传输协议的设备。

　　3 研华最新推出的XScale单板计算机PCM-7210

　　PCM-7210是一款集成Intel XScale低功耗RISC处理器PXA250的单板计算机。它由一块支撑板和一块CPU板构成，在CPU板上集成了处理器PXA250、64MB的SDRAM和32MB的Flash存储器，其它的外围器件均置于支撑板之上，包括10Mbps以太网接口，4个全功能RS-232和1个RS-485串行接口，AC97音频接口，2个USB主机端和1个客户端，数字I/O引脚和CF/PCMCIA扩展插槽。此外，还有支持LCD/CRT显示的接口以及智能电源接口。PCM-7210功能框图如图2所示。

http://www.gentoo.org/doc/zh_tw/handbook/2005.0/handbook-x86.xml?style=printable&full=1

Introduction

This article will demonstrate how to create a custom stage4 archive. A stage4 archive is an image of your entire root partition. The primary reason to create a stage4 archive is to provide for quick recovery in the event of disk failure. A stage4 archive is the same as a stage3, only you can select the CFLAGS you want to use and what other software you want installed. You can adapt this method to suit your personal uses.

If you want a generic stage4 that you can install on multiple systems, use genkernel to set up your kernel. This will ensure that on boot, the kernel will work like the one on the livecd. You may also want to use less restrictive CFLAGS (i.e., MCPU instead of MARCH). You may still have to modify /etc/fstab and the USE flags after extracting the stage4, to suit the user.

Step1

Install Gentoo .

Step2

Configure all drivers (i.e. sound, video and USB) and install any software you want to be included on your stage4. For example, I would install X, Xfce4, Sun's JDK, CVS, Emacs, Thunderbird, and Firefox.

Step3

Make a copy of your /boot partition:

root# mount /bootroot# cp -R /boot /bootcpyroot# umount /boot

Alternatively, you can just mount /boot before you tar everything up. However, there may be problems with this alternate method if you use the stage4 on systems with different hardware configurations.

Step4

Clear out temporary files in /usr/portage/distfiles and /var/tmp to save space.

I would use caution in clearing /var/tmp. On my system, config information was stored in there for sound and portage. This caused problems later, when I restored my system and realized that I was missing some important information. It may be better to have a slightly larger tarball than to find that the restored system is incomplete.

Step5

After everything is set up correctly from the previous sections, we will create the archive:

root# tar cjpf /path/to/save/at/stage4.tar.bz2 / --exclude=stage4.tar.bz2 --exclude=/proctar options we used: c - create archive j - use bzip2 compression p - preserve file attributes (don't leave this out!!) f - specify file name

Be sure to look at the tar manpage

It will probably take a long time to create the archive depending on how much you have installed. I usually save the archive on a spare disk I have in my system that I use for backups. You can also burn it to a cd or dvd.

If it is too large to fit on a cd you will have to split it up. Large tar files can be split up with 'split'. The parts can be joined later with 'cat'. ('man split', and 'man cat' for more info).

fdavid suggested:

• Large tar files can be split with a small utility called split. The parts can be joined later with cat.
• The exclude option of tar must be heavily utilized, because there are many directories which must be excluded when backing up your root. Exclude can also go for /usr/portage, if you want a smaller archive. Excluding this might be prudent, since the contents of /usr/portage will be outdated when you restore the archive.

The directories I exclude when backing up my root:

• /mnt
• /proc
• /sys
• /tmp
• + any directory, which is backed up separately.

Small script, which I use for making backup of my /home. (The /dev/hdX corresponds to the /mnt/tarbackup directory in /etc/fstab.)

#! /bin/bash# Backup script for Gentoo Linux# Author: fdavid# Date: 2003.11.29.# Making backup of home partition to cds# options for the archivetarOptions="--create --absolute-names --preserve-permissions --gzip --file"# name of the archivearchive=/mnt/tarbackup/$(date +%Y%m%d)home.tar.gz# mount the backup partitionmount /dev/hdaXsleep 5# create the archivetar ${tarOptions} ${archive} /home/;echo archive is done# split the archive to cd size (use: "cat ${archive}.* >> ${archive}" to join the parts)split --bytes=700000000 ${archive} ${archive}.echo splitting is done# unmountsleep 5umount /dev/hdaX

BrianW added:

• Cleaned up the script a bit.
• Made it so the --exclude= for the archive doesn't have to be edited if you modify $stage4Location
• Added --exclude=/var/tmp/*
• Added --verbose to the tar options
• Added code to remove /bootcpy
• Moved the --exclude directories/files out of $tarOptions into their own variable's (thanks kamilian )

#! /bin/bash##  Backup script for Gentoo Linux##  Author: BrianW##  Date: 2004.10.26.##  Adapted from backupHome.sh by fdavid##  Adapted from mkstage4.sh by nianderson##  This is a script to create a custom stage 4 tarball (System and boot backup)##  I use this script to make a snapshot of my system. Meant to be done weekly in my case##  Please check the options and adjust to your specifics.echo -=- Starting the Backup Script...echo -=-echo -=- Setting the variables...##  The location of the stage 4 tarball.##  Be sure to include a trailing /stage4Location=/##  The name of the stage 4 tarball.archive=$stage4Location$(hostname)-stage4.tar.bz2##  Directories/files that will be exluded from the stage 4 tarball.####  Add directories that will be recursively excluded, delimited by a space.##  Be sure to omit the trailing /dir_excludes="/dev /proc /sys /tmp /usr/portage /var/tmp"####  Add files that will be excluded, delimited by a space.##  You can use the * wildcard for multiple matches.##  There should always be $archive listed or bad things will happen.file_excludes="$archive"####  Combine the two *-excludes variables into the $excludes variableexcludes="$(for i in $dir_excludes; do if [ -d $i ]; then \    echo -n " --exclude=$i/*"; fi; done) $(for i in $file_excludes; do \    echo -n " --exclude=$i"; done)"##  The options for the stage 4 tarball.tarOptions="$excludes --create --absolute-names --preserve-permissions --bzip2 --verbose --totals --file"echo -=- Done!echo -=-##  Mounting the boot partitionecho -=- Mounting boot partition, then sleeping for 5 seconds...mount /bootsleep 5echo -=- Done!echo -=-##  Creating a copy of the boot partition (copy /boot to /bootcpy).##  This will allow the archiving of /boot without /boot needing to be mounted.##  This will aid in restoring the system.echo -=- Copying /boot to /bootcpy ...cp -R /boot /bootcpyecho -=- Done!echo -=-##  Unmounting /bootecho -=- Unmounting /boot then sleeping for 5 seconds...umount /bootsleep 5echo -=- Done!echo -=-##  Creating the stage 4 tarball.echo -=- Creating custom stage 4 tarball \=\=\> $archiveecho -=-echo -=- Running the following command:echo -=- tar ${tarOptions} ${archive} /tar ${tarOptions} ${archive} /;echo -=- Done!##  Split the stage 4 tarball in cd size tar files.##  To combine the tar files after copying them to your##  chroot do the following: "cat *.tar.bz2 >> stage4.tar.bz2".##  Uncomment the following lines to enable this feature.#echo -=- Splitting the stage 4 tarball into CD size tar files...#split --bytes=700000000 ${archive} ${archive}.#echo -=- Done!##  Removing the directory /bootcpy.##  You may safely uncomment this if you wish to keep /bootcpy.echo -=- Removing the directory /bootcpy ...rm -rf /bootcpyecho -=- Done!echo -=-##  This is the end of the line.echo -=- The Backup Script has completed!

Here is a little script to install from a stage4 created by either of the above two scripts. (Limited testing reported by rpcyan thanks please continue testing) should work though. A few changes were made by rpcyan to get the install script working correctly Please contact me with comments or improvements. nianderson

#! /bin/bash# Backup script for Gentoo Linux# Author: nianderson# Date: 2004.09.15.##Used to install a stage4 created with mkstage4.sh#assumes you have already partitioned and formated your drive#assumes your booted from gentoo live cd#Define Disk layout#if using ide disks use hdax if using scsi use sdaxrootPartition=/dev/sda3bootPartition=/dev/sda1#where to mount the disk partitionsmntRootPartition=/mnt/gentoomntBootPartition=/mnt/gentoo/boot#URL of stage4#I put a copy of the tar on a webserver so i can#easily get it when a reinstall is neededurlToStage4=http://domain.com/stage4=hostname-stage4.tar.bz2#mount root partitionecho mounting root partition $rootPartition to $mntRootPartitionmount $rootPartition $mntRootPartitionsleep 5echo#not sure about this part yet#wget the stage4 to the mounted root partitioncd $mntRootPartitionecho wget $urlToStage4$stage4 to $mntRootPartitionwget $urlToStage4$stage4sleep 5#untar the stage4echo extract stage4tar xjpf $stage4sleep 5echo#mount boot partitonecho mounting $bootPartition to $mntBootPartitionmkdir $mntbootPartitionmount $bootPartition $mntBootPartitionsleep 5echo#copy boot copy back to bootecho copy bootcpy back to bootcp -R $mntRootPartition/bootcpy $mntBootPartitionsleep 5#remove stage4 filerm -rf $mntRootPartition/$stage4echo you need to check your fstab and install grub or lilo thenecho all should be wellecho Removing bootcpyrm -rf /bootcpyecho Enjoy

For explanation and further infos refer to the Gentoo Post. A howto (Wiki) of the script can be found here.

#!/bin/bash# Backup script for Gentoo Linux# Author: Reto Glauser aka blinkeye# Homepage: http://blinkeye.ch# Mailto: stage4 at blinkeye dot ch# Date: 23.03.2005# If you need further infos check out this post: http://forums.gentoo.org/viewtopic.php?p=1751698#1751698version=v1.2# these are the commands we actually need for the backupcommand_list="echo tar hostname date split"# verify that each command we use existsfor command in $command_list; do	path=`which $command | grep "no $command in"`		if [ ! -x `which $command` -a "$path" ]; then		echo -e "\n\nERROR: $command not found! Check your commands and/or your \$PATH"		exit -1	fidone# options for the tar commandtarOptions="--create --absolute-names --preserve-permissions --totals --bzip2 --ignore-failed-read --verbose --file"# where to put the stage4stage4Location=/mnt/backups/stage4# name prefixstage4prefix=$(hostname)-stage4-`date +\%d.\%m.\%Y`# these files/directories are always excludeddefault_exclude_list="--exclude=/tmp/*--exclude=/var/tmp/*--exclude=/lost+found/*--exclude=/dev/*--exclude=/proc/*--exclude=/mnt/*--exclude=/sys/*--exclude=/usr/portage/*--exclude=/var/log/*--exclude=$stage4Location"# depending on your choice these files or directories will additionally be excludedcustom_exclude_list="--exclude=/usr/src/*--exclude=/opt/mathematica--exclude=/usr/share/smssend--exclude=/home/*"# check the folder/files stored in $default_exclude_list existfor exclude in $default_exclude_list; do	if [ ! -e "`echo "$exclude" | cut -d'=' -f2 | cut -d'*' -f1`"  ]; then		echo -e "\n\nERROR: `echo "$exclude" | cut -d'=' -f2` not found! Check your \$default_exclude_list"	fidone# check the folder/files stored in $custom_exclude_list existfor exclude in $custom_exclude_list; do	if [ ! -e "`echo "$exclude" | cut -d'=' -f2 | cut -d'*' -f1`"  ]; then		echo -e "\n\nERROR: `echo "$exclude" | cut -d'=' -f2` not found! Check your \$custom_exclude_list"	fidone# print out the version echo -e "\nBackup script $version" echo -e "==================="# how do you want to backup?echo -e "\nWhat do you want to do? (Use CONTROL-C to abort)\n(1) Minimal backup(2) Interactive backup"while [ "$option" != '1' -a "$option" != '2'  ]; do	echo -en "\nPlease enter your option: "	read optiondonecase $option in1)	stage4Name=$stage4Location/$stage4prefix-minimal	final_command="tar $default_exclude_list $custom_exclude_list $tarOptions $stage4Name.tar.bz2 / /var/log/emerge.log"	;;2)	for folder in $custom_exclude_list; do		echo -en "Do you want to backup" `echo "$folder" | cut -d'=' -f2`"? (y/n) "		read answer		while [ "$answer" != 'y' -a "$answer" != 'n' ]; do			echo "please enter y or n"			read answer		done		if [ "$answer" == 'n' ]; then			default_exclude_list="$default_exclude_list $folder"		fi	done		stage4Name=$stage4Location/$stage4prefix-custom	final_command="tar $default_exclude_list $tarOptions $stage4Name.tar.bz2 /  /var/log/emerge.log"	;;esac# show what will be doneecho -e "\n* creating the stage4 at $stage4Location with the following options:\n\n"$final_command# everything is set, are you sure to continue?echo -ne "\nDo you want to continue? (y/n) "read answerwhile [ "$answer" != 'y' ] && [ "$answer" != 'n' ]; do			echo "please enter y or n"			read answerdoneif [ "$answer" == 'y' ]; then	# mount boot	echo -e "\n* mount boot"	mount /boot >/dev/null 2>&1			# if necessary, create the stage4Location	if [ ! -d "$stage4Location" ] ; then		echo "* creating directory $stage4Location"		mkdir -p $stage4Location	fi		# check whether the file already exists	if [ -a "$stage4Name.tar.bz2" ]; then		echo -en "\nDo you want to overwrite $stage4Name.tar.bz2? (y/n) "		read answer		while [ "$answer" != 'y' ] && [ "$answer" != 'n' ]; do			echo "please enter y or n"			read answer		done		if [ "$answer" == 'n' ]; then			echo -e "\n* There's nothing to do ... Exiting"			exit 0;		fi	fi		# do the backup	time $final_command	# copy the current world file to the stage4 location	echo -e "\n* creating stage4 overview $stage4Name.txt"	cp /var/lib/portage/world $stage4Name.txt >/dev/null 2>&1		# we finished, clean up	echo "* stage4 is done"	echo "* umounting boot"	umount /bootelse	echo -e "\n* There's nothing to do ... Exiting"fi#Uncomment the following command if you want to split the archive in cd size chunks:#split --suffix-length=1 --bytes=670m $stage4Name.tar.bz2 "$stage4Name".tar.bz2_ && echo "* splitting is done"

Install from a stage4

1. Boot live CD
2. Create partitions, make filesystems and mount filesystems

   root# cd /mnt/gentoo

3. Copy your stage4 archive(s) to disk (if it is on another CD type "gentoo docache" at the boot prompt. Then you'll be able to umount/mount other CDs.)

   tar -xvjpf stage4.tar.bz2

4. root# cp -R bootcpy /mnt/gentoo/boot

   (Double check the boot dir after you copy the files over!)

5. root# rm -rf bootcpy

6. Check /etc/fstab
7. You must "link" /dev to /mnt/gentoo/dev with following command (given outside chroot):

   mount -o bind /dev /mnt/gentoo/dev

8. Chroot into /mnt/gentoo:

   chroot /mnt/gentoo /bin/bash

9. grub or lilo

Partition table tip

dd if=/dev/(your_disk) of=mbr.save count=1 bs=512sfdisk -d /dev/(your_disk) > partitions.save

The first of those saves the mbr and the second will store all partition info (including logical partitions, which aren't part of the mbr).

dd if=mbr.save of=/dev/(your_disk)sfdisk /dev/(your_disk) < partitions.save

LILO tip

To install LILO in the MBR after untaring stage, mount it as:

mount -o bind /dev /mnt/gentoo/dev

GRUB tip

After chrooting:

root# grubgrub> root (hd0,0)grub> setup (hd0)grub> quit

(hd may need to be changed depending on your setup)

Privacy tip

I recommend deleting every "~/.bash_history" before executing the stage4 commands/scripts. This can be done by simply typing:

Singleuser (root) environments:
root@gentoo# rm ~/.bash_history && tar cpjf ...
or
root@gentoo# rm ~/.bash_history && sh <your-script>.sh

Multiuser (>root) environments:
Just add ".bash_history" to the excluded files list in your stage4 scripts or "--exclude='.bash_history'" to command line.

文档选项 将此页作为电子邮件发送 对此页的评价 帮助我们改进这些内容

2005 年 12 月 18 日

本文将首先介绍 Linux 内核上的一些内核代码监视和错误跟踪技术，这些调试和跟踪方法因所要求的使用环境和使用方法而各有不同，然后重点介绍三种 Linux 内核的源代码级的调试方法。

调试是软件开发过程中一个必不可少的环节，在 Linux 内核开发的过程中也不可避免地会面对如何调试内核的问题。但是，Linux 系统的开发者出于保证内核代码正确性的考虑，不愿意在 Linux 内核源代码树中加入一个调试器。他们认为内核中的调试器会误导开发者，从而引入不良的修正[1]。所以对 Linux 内核进行调试一直是个令内核程序员感到棘手的问题，调试工作的艰苦性是内核级的开发区别于用户级开发的一个显著特点。

尽管缺乏一种内置的调试内核的有效方法，但是 Linux 系统在内核发展的过程中也逐渐形成了一些监视内核代码和错误跟踪的技术。同时，许多的补丁程序应运而生，它们为标准内核附加了内核调试的支持。尽管这些补丁有些并不被 Linux 官方组织认可，但他们确实功能完善，十分强大。调试内核问题时，利用这些工具与方法跟踪内核执行情况，并查看其内存和数据结构将是非常有用的。

本文将首先介绍 Linux 内核上的一些内核代码监视和错误跟踪技术，这些调试和跟踪方法因所要求的使用环境和使用方法而各有不同，然后重点介绍三种 Linux 内核的源代码级的调试方法。

1. Linux 系统内核级软件的调试技术

printk() 是调试内核代码时最常用的一种技术。在内核代码中的特定位置加入printk() 调试调用，可以直接把所关心的信息打打印到屏幕上，从而可以观察程序的执行路径和所关心的变量、指针等信息。 Linux 内核调试器（Linux kernel debugger，kdb）是 Linux 内核的补丁，它提供了一种在系统能运行时对内核内存和数据结构进行检查的办法。Oops、KDB在文章掌握 Linux 调试技术有详细介绍，大家可以参考。 Kprobes 提供了一个强行进入任何内核例程，并从中断处理器无干扰地收集信息的接口。使用 Kprobes 可以轻松地收集处理器寄存器和全局数据结构等调试信息，而无需对Linux内核频繁编译和启动，具体使用方法，请参考使用 Kprobes 调试内核。

以上介绍了进行Linux内核调试和跟踪时的常用技术和方法。当然，内核调试与跟踪的方法还不止以上提到的这些。这些调试技术的一个共同的特点在于，他们都不能提供源代码级的有效的内核调试手段，有些只能称之为错误跟踪技术，因此这些方法都只能提供有限的调试能力。下面将介绍三种实用的源代码级的内核调试方法。

回页首

2. 使用KGDB构建Linux内核调试环境

kgdb提供了一种使用 gdb调试 Linux 内核的机制。使用KGDB可以象调试普通的应用程序那样，在内核中进行设置断点、检查变量值、单步跟踪程序运行等操作。使用KGDB调试时需要两台机器，一台作为开发机（Development Machine）,另一台作为目标机（Target Machine），两台机器之间通过串口或者以太网口相连。串口连接线是一根RS-232接口的电缆，在其内部两端的第2脚（TXD）与第3脚（RXD）交叉相连，第7脚（接地脚）直接相连。调试过程中，被调试的内核运行在目标机上，gdb调试器运行在开发机上。

目前，kgdb发布支持i386、x86_64、32-bit PPC、SPARC等几种体系结构的调试器。有关kgdb补丁的下载地址见参考资料[4]。

2．1 kgdb的调试原理

安装kgdb调试环境需要为Linux内核应用kgdb补丁，补丁实现的gdb远程调试所需要的功能包括命令处理、陷阱处理及串口通讯3个主要的部分。kgdb补丁的主要作用是在Linux内核中添加了一个调试Stub。调试Stub是Linux内核中的一小段代码，提供了运行gdb的开发机和所调试内核之间的一个媒介。gdb和调试stub之间通过gdb串行协议进行通讯。gdb串行协议是一种基于消息的ASCII码协议，包含了各种调试命令。当设置断点时，kgdb负责在设置断点的指令前增加一条trap指令，当执行到断点时控制权就转移到调试stub中去。此时，调试stub的任务就是使用远程串行通信协议将当前环境传送给gdb，然后从gdb处接受命令。gdb命令告诉stub下一步该做什么，当stub收到继续执行的命令时，将恢复程序的运行环境，把对CPU的控制权重新交还给内核。

2．2 Kgdb的安装与设置

下面我们将以Linux 2.6.7内核为例详细介绍kgdb调试环境的建立过程。

2.2.1软硬件准备

以下软硬件配置取自笔者进行试验的系统配置情况：

kgdb补丁的版本遵循如下命名模式：Linux-A-kgdb-B，其中A表示Linux的内核版本号，B为kgdb的版本号。以试验使用的kgdb补丁为例，linux内核的版本为linux-2.6.7，补丁版本为kgdb-2.2。

物理连接好串口线后，使用以下命令来测试两台机器之间串口连接情况，stty命令可以对串口参数进行设置：

在development机上执行：

																				
																						stty ispeed 115200 ospeed 115200 -F /dev/ttyS0
																				
																		

在target机上执行：

																				
																						stty ispeed 115200 ospeed 115200 -F /dev/ttyS0
																				
																		

在developement机上执行：

																				
																						echo hello > /dev/ttyS0
																				
																		

在target机上执行：

																				
																						cat /dev/ttyS0
																				
																		

如果串口连接没问题的话在将在target机的屏幕上显示"hello"。

2．2．2 安装与配置

下面我们需要应用kgdb补丁到Linux内核，设置内核选项并编译内核。这方面的资料相对较少，笔者这里给出详细的介绍。下面的工作在开发机（developement）上进行，以上面介绍的试验环境为例，某些具体步骤在实际的环境中可能要做适当的改动：

I、内核的配置与编译

																				
																						[root@lisl tmp]# tar -jxvf linux-2.6.7.tar.bz2[root@lisl tmp]#tar -jxvf linux-2.6.7-kgdb-2.2.tar.tar[root@lisl tmp]#cd inux-2.6.7
																				
																		

请参照目录补丁包中文件README给出的说明，执行对应体系结构的补丁程序。由于试验在i386体系结构上完成，所以只需要安装一下补丁：core-lite.patch、i386-lite.patch、8250.patch、eth.patch、core.patch、i386.patch。应用补丁文件时，请遵循kgdb软件包内series文件所指定的顺序，否则可能会带来预想不到的问题。eth.patch文件是选择以太网口作为调试的连接端口时需要运用的补丁

应用补丁的命令如下所示：

[root@lisl tmp]#patch -p1 <../linux-2.6.7-kgdb-2.2/core-lite.patch 

如果内核正确，那么应用补丁时应该不会出现任何问题（不会产生*.rej文件）。为Linux内核添加了补丁之后，需要进行内核的配置。内核的配置可以按照你的习惯选择配置Linux内核的任意一种方式。

[root@lisl tmp]#make menuconfig

在内核配置菜单的Kernel hacking选项中选择kgdb调试项，例如：

  [*] KGDB: kernel debugging with remote gdb                                                                    Method for KGDB communication (KGDB: On generic serial port (8250))  --->    [*] KGDB: Thread analysis                                                                              [*] KGDB: Console messages through gdb[root@lisl tmp]#make  

编译内核之前请注意Linux目录下Makefile中的优化选项，默认的Linux内核的编译都以-O2的优化级别进行。在这个优化级别之下，编译器要对内核中的某些代码的执行顺序进行改动，所以在调试时会出现程序运行与代码顺序不一致的情况。可以把Makefile中的-O2选项改为-O,但不可去掉-O，否则编译会出问题。为了使编译后的内核带有调试信息，注意在编译内核的时候需要加上-g选项。

不过，当选择"Kernel debugging->Compile the kernel with debug info"选项后配置系统将自动打开调试选项。另外，选择"kernel debugging with remote gdb"后，配置系统将自动打开"Compile the kernel with debug info"选项。

内核编译完成后，使用scp命令进行将相关文件拷贝到target机上(当然也可以使用其它的网络工具，如rcp)。

[root@lisl tmp]#scp arch/i386/boot/bzImage root@192.168.6.13:/boot/vmlinuz-2.6.7-kgdb[root@lisl tmp]#scp System.map root@192.168.6.13:/boot/System.map-2.6.7-kgdb

如果系统启动使所需要的某些设备驱动没有编译进内核的情况下，那么还需要执行如下操作：

[root@lisl tmp]#mkinitrd /boot/initrd-2.6.7-kgdb 2.6.7[root@lisl tmp]#scp initrd-2.6.7-kgdb root@192.168.6.13:/boot/ initrd-2.6.7-kgdb

II、kgdb的启动

在将编译出的内核拷贝的到target机器之后，需要配置系统引导程序，加入内核的启动选项。以下是kgdb内核引导参数的说明：

如表中所述，在kgdb 2.0版本之后内核的引导参数已经与以前的版本有所不同。使用grub引导程序时，直接将kgdb参数作为内核vmlinuz的引导参数。下面给出引导器的配置示例。

title 2.6.7 kgdbroot (hd0,0)kernel /boot/vmlinuz-2.6.7-kgdb ro root=/dev/hda1 kgdbwait kgdb8250=1,115200

在使用lilo作为引导程序时，需要把kgdb参放在由append修饰的语句中。下面给出使用lilo作为引导器时的配置示例。

image=/boot/vmlinuz-2.6.7-kgdblabel=kgdb    read-only    root=/dev/hda3append="gdb gdbttyS=1 gdbbaud=115200"

保存好以上配置后重新启动计算机，选择启动带调试信息的内核，内核将在短暂的运行后在创建init内核线程之前停下来，打印出以下信息，并等待开发机的连接。

Waiting for connection from remote gdb...

在开发机上执行：

gdbfile vmlinuxset remotebaud 115200target remote /dev/ttyS0

其中vmlinux是指向源代码目录下编译出来的Linux内核文件的链接，它是没有经过压缩的内核文件，gdb程序从该文件中得到各种符号地址信息。

这样，就与目标机上的kgdb调试接口建立了联系。一旦建立联接之后，对Linux内的调试工作与对普通的运用程序的调试就没有什么区别了。任何时候都可以通过键入ctrl+c打断目标机的执行，进行具体的调试工作。

在kgdb 2.0之前的版本中，编译内核后在arch/i386/kernel目录下还会生成可执行文件gdbstart。将该文件拷贝到target机器的/boot目录下，此时无需更改内核的启动配置文件，直接使用命令：

[root@lisl boot]#gdbstart -s 115200 -t /dev/ttyS0

可以在KGDB内核引导启动完成后建立开发机与目标机之间的调试联系。

2．2．3 通过网络接口进行调试

kgdb也支持使用以太网接口作为调试器的连接端口。在对Linux内核应用补丁包时，需应用eth.patch补丁文件。配置内核时在Kernel hacking中选择kgdb调试项，配置kgdb调试端口为以太网接口，例如：

[*]KGDB: kernel debugging with remote gdbMethod for KGDB communication (KGDB: On ethernet)  ---> ( ) KGDB: On generic serial port (8250)(X) KGDB: On ethernet

另外使用eth0网口作为调试端口时，grub.list的配置如下：

title 2.6.7 kgdbroot (hd0,0)kernel /boot/vmlinuz-2.6.7-kgdb ro root=/dev/hda1 kgdbwait kgdboe=@192.168.5.13/,@192.168. 6.13/ 

其他的过程与使用串口作为连接端口时的设置过程相同。

注意：尽管可以使用以太网口作为kgdb的调试端口，使用串口作为连接端口更加简单易行，kgdb项目组推荐使用串口作为调试端口。

2．2．4 模块的调试方法

内核可加载模块的调试具有其特殊性。由于内核模块中各段的地址是在模块加载进内核的时候才最终确定的，所以develop机的gdb无法得到各种符号地址信息。所以，使用kgdb调试模块所需要解决的一个问题是，需要通过某种方法获得可加载模块的最终加载地址信息，并把这些信息加入到gdb环境中。

I、在Linux 2.4内核中的内核模块调试方法

在Linux2.4.x内核中，可以使用insmod -m命令输出模块的加载信息，例如：

[root@lisl tmp]# insmod -m hello.ko >modaddr

查看模块加载信息文件modaddr如下：

.this           00000060  c88d8000  2**2.text           00000035  c88d8060  2**2.rodata         00000069  c88d80a0  2**5…….data           00000000  c88d833c  2**2.bss            00000000  c88d833c  2**2……

在这些信息中，我们关心的只有4个段的地址:.text、.rodata、.data、.bss。在development机上将以上地址信息加入到gdb中,这样就可以进行模块功能的测试了。