U-boot应用于AT91RM9200重映射机制的修正

Ｕ—ｂｏｏｔ应用于ＡＴ９１ＲＭ９２００重映射机制的修正※■山东大学文ＩＪ庆敏田岚Ｕ—ｂｏｏｔ作为一款通用的ｂｏｏｔｌｏａｄｅｒ，在嵌入式系统领域是非常成功的。

但是在ＡＴ９１ＲＭ９２００的重映射…机制的使用上，存在不合理性，给移植带来了很多不便。

本文详细介绍ＡＴ９１ＲＭ９２００的重映射机制以及一一启动流程，提出一种检测易失性存储介质的算法；采用情景分析的方法给出Ｕ—ｂｏｏｔ三种模式启动无关性的修正方案，对Ｕ—ｂｏｏｔ移植和ｂｏｏｔｌｏａｄｅｒ的设计有一定的参考价值。

关键词Ｕ—ｂｏｏｔＡＴ９１ＲＭ９２００重映射，引言在嵌入式系统中，程序代码必须放在非易失性存储介质里，但嵌入式处理器的速度远远大于非易失性存储介质的读取速度。

为了缓解这种矛盾，提出高速缓存的技术方案，即利用高速的易失性存储介质（如ＳＲＡＭ），作为非易失性存储介质的高速缓存，由此形成了典型的“金字塔式”的存储体系架构。

但是，处理器体系结构的设计决定了上电或复位时从固定的位置取指，此时中断向量表仍然存放于低速非易失性介质里，所以不能有效提高处理器对异常处理的速度。

为了解决这个问题，同时更好地支持存储体系架构，提高系统性能，提出了“重映射”的解决方案。

１重映射的理论模型要理解重映射，必须首先理解映射。

在此给出映射的基本理论模型，如图１所示。

用公式表示为Ａ竺Ｂ。

务ｒ弗其中，Ａ表示输入域，Ｂ表示输出ＩＪ域，Ｆ（Ｘ）表示规则。

Ａ在规则Ｆ图１（重）映射理论模型（Ｘ）下能够与Ｂ对应，这种对应关系就是“映射”。

在嵌入式系统中，这个模型应用比较普遍，可以完全用硬件实现，也可以硬件和软件协同实现。

根据作用时间的不同，第１次称为“映射”，后面的就称之为“重映射”。

基本理论相同，实现方式也类似。

在不影响理解的情况下，以下不区分“映射”和“重映射”这两个术语。

嵌入式系统中，重映射对应的输入、输出都是地址数据。

下面举一个完全硬件实现重映射的简单实例：令Ａ＝（Ｏｘ００００００００—０ｘ０００ｆｆｆｆｆ），实现到Ｂ＝｛０ｘ００１０００００—０ｘ００１ｆｆｆｆｆ）的重映射。

可以看出，它们的不同在于Ａ２０一Ｂ２０这对地址线，所以硬件实现只需对此进行处理就可以了。

如图２所示，无论Ａ２０为高电平还是低电平，对应的Ｂ２０都是高电平。

ＣＰＵ访问｛Ｏｘ００００００００—０ｘ０００ｆｆｆｆｆ），或者｛０ｘ００１０００００—０ｘ００１ｆｆｆｆｆ），在映射关系下，实际都是访问到（Ｏｘ００１０００００—０ｘ００１ｆｆｆｆｆ）。

通过改变映射关系，可以把｛Ｏｘ００００００００—０ｘ０００ｆｆｆｆｆ）这个１ＭＢ的地址空间映射到任意位置。

这样就可以实现ＣＰＵ从固定位置取值，但是实际对应的物理存储介质可以不同了。

图２重映射硬件实现实例根据重映射的不同需求，Ｆ（Ｘ）对应的复杂度也不同。

为了分析方便，在ＡＴ９１ＲＭ９２００的重映射机制分析中，Ｆ（Ｘ）就作为一个黑匣子处理。

其内部实现的细节这里不作探讨。

２ＡＴ９１ＲＭ９２００的实现方案及启动流程ＡＴ９１ＲＭ９２００上电或复位之后的内存映射关系可以参考其数据手册的Ｆｉｇｕｒｅ８—１，这里不作重点分析。

内存映射完成后，ｍｅｍｏｒｙｃｏｎｔｒｏｌｌｅｒ控制硬件实现重映射（要注意，这是不提供给用户的，也就是说用户无法改变这种映射规则）。

下面用伪代码描述：ｉｆＢＭＳ为高电平Ｆ（Ｘ）：ｂｏｏｔｍｅｍｏｒｙ－－’ＲＯＭｅｌｓｅＦ（Ｘ）：ｂｏｏｔｍｅｍｏｒｙ－－－ＮＯＲＦｌａｓｈ其中，ＢＭＳ是启动模式选择引脚。

它决定了两种不同的映射关系，因而也决定了Ｕ—ｂｏｏｔ至少可以有与之对２８《羊旁机ｊ嵌入式牵＇ｉ．应用》ａｄｖ＠ｍｅｓｎｅｔ．ｏＤｍ．ｏｎ（广告专用）万方数据应的两种启动模式。

ＡＴ９１ＲＭ９２００通过寄存器ＭＣ—ＲＣＲ为用户提供了接口，可以控制重映射。

不过这种控制规则仍然是有限的。

内存映射完成后，映射规则按照上述伪代码执行。

如果执行重映射，不管ＢＭＳ状态如何，规则变为“Ｆ（Ｘ）：ｂｏｏｔｍｅｍｏｒｙ－－ＳＲＡＭ”。

再次执行重映射，Ｆ（Ｘ）将恢复到伪代码描述状态。

这个重映射的具体执行手段，就是往ＭＣＬＲＣＲ写入１。

明确了ＡＴ９１ＲＭ９２００的映射机制，就可以对启动流程进行深入分析了。

ＡＴ９１ＲＭ９２００数据手册在“１３ｂｏｏｔｐｒｏｇｒａｍ”一节中对内部启动流程讲解得比较清晰，所以对这部分简略描述。

对复杂机制．，如果采用情景分析的方法，则会清晰许多。

根据ＡＴ９ｌＲＭ９２００的特点，提出了３种情景。

这３种情景分别对应Ｕ—ｂｏｏｔ启动的３种不同模式。

情景１：令ＢＭＳ为高电平，系统上电或复位之后从片内启动。

通过Ｘｍｏｄｅｍ协议上传ｌｏａｄｅｒ．ｂｉｎ，其执行成功后，再次通过Ｘｍｏｄｅｍ协议上传Ｕ－ｂｏｏｔ．ｂｉｎ，实现Ｕ—ｂｏｏｔ的正常启动。

情景２：令ＢＭＳ为低电平，系统上电或复位之后从片外ＮＯＲＦｌａｓｈ启动。

此处在０ｘ１０００００００固化ｂｏｏｔ．ｂｉｎ，在０ｘ１００１００００处固化Ｕ－ｂｏｏｔ．ｂｉｎ．ｇｚ，实现Ｕ—ｂｏｏｔ压缩方式的正常启动。

情景３：令ＢＭＳ为低电平，系统上电或复位之后从片外ＮＯＲＦｌａｓｈ启动。

此处在Ｏｘｌ０００００００固化Ｕ—ｂｏｏｔ．ｂｉｎ，实现Ｕ—ｂｏｏｔ的非压缩方式的正常启动。

这３种情景各具特点。

其中情景１适用于测试阶段，Ｕ—ｂｏｏｔ还没有固化到Ｆｌａｓｈ中；如果Ｕ—ｂｏｏｔ比较大，考虑代码空间，则可以采用情景２；如果对启动时间要求非常短，则可以考虑精简Ｕ—ｂｏｏｔ的代码，采用情景３实现快速引导启动。

下面通过．Ｕ—ｂｏｏｔ的生命周期和ｂｏｏｔｍｅｍｏｒｙ映射规则变化来对３种情景进行对比分析。

情景１：片内启动，ｌｏａｄｅｒ．ｂｉｎ＋Ｕ—ｂｏｏｔ．ｂｉｎ硬件上电，检测到ＢＭＳ为高电平，Ｆ（Ｘ）：ｂｏｏｔｍｅｍｏ－ｒｙ－－－ＳＲＯＭ。

那么ＣＰＵ从０ｘ０处取指执行，实际上执行的就是ＳＲＯＭ中的代码。

当无法发现有效序列的代码后，自动执行ｕｐｌｏａｄｅｒ程序，将ｌｏａｄｅｒ．ｂｉｎ放到ＳＲＡＭ中，完成后执行重映射，将ＰＣ置为０，这样实际上就开始执行上载到ＳＲＡＭ中的ｌｏａｄｅｒ．ｂｉｎ程序。

此时，Ｆ（Ｘ）：ｂｏＯｔｍｅｍｏｒｙ－－・ＳＲＡＭ。

ｌｏａｄｅｒ．ｂｉｎ将用户上传的Ｕ－ｂｏｏｔ．ｂｉｎ下载到ＳＤＲＡＭ中，然后跳转到Ｕ—ｂｏｏｔ的起始位置开始执行。

在这种情景中，Ｕ—ｂｏｏｔ．ｂｉｎ的生命之初就在ＳＤＲＡＭ中，而且此时Ｆ（Ｘ）：ｂｏｏｔｍｅｍｏｒｙ－－－ＳＲＡＭ。

情景２：片外启动，ｂｏｏｔ．ｂｉｎ＋Ｕ—ｂｏｏｔ。

ｂｉｎ．ｇｚ上电或复位后，Ｆ（Ｘ）：ｂｏｏｔｍｅｍｏｒｙ－，ＮｏｒＦｌａｓｈ。

首先执行ｂｏｏｔ．ｂｉｎ，它的作用就是初始化ＳＤＲＡＭ，然后解压Ｕ—ｂｏｏｔ．ｂｉｎ．ｇｚ，放到ＳＤＲＡＭ中。

然后调转到相应位置，执行Ｕ—ｂｏｏｔ。

在这种情景中，Ｕｂｏｏｔ．ｂｉｎ的生命之初也是在ＳＤＲＡＭ中，不过此时Ｆ（Ｘ）：ｂｏｏｔｍｅｍｏｒｙ－＋ＮＯＲＦｌａｓｈ。

情景３：片外启动，Ｕ—ｂｏｏｔ．ｂｉｎ上电或复位后，Ｆ（Ｘ）：ｂｏｏｔｍｅｍｏｒｙ－－－ＮＯＲＦｌａｓｈ。

开始执行Ｕ—ｂｏｏｔ，这样Ｕ—ｂｏｏｔ将自身下载到ＳＤＲＡＭ中，然后跳转至相应位置执行。

在这种情景中，Ｕ—ｂｏｏｔ．ｂｉｎ的生命之初在ＮＯＲＦｌａｓｈ中，然后到ＳＤＲＡＭ。

不过在这整个过程中，Ｆ（Ｘ）：ｂｏｏｔｍｅｍｏｒｙ－，ＮＯＲＦｌａｓｈ。

通过上述分析和表１，就可以对３种情景Ｕ—ｂｏｏｔ的执行初始状态非常清晰了。

表１Ｕ—ｂｏｏｔ开始时刻的执行位置与Ｆ（Ｘ）规则对比Ｕ—ｂｏｏｔ开始执行时的位置ｂｏｏｔｍｅｍｏｒｙ指向情景１ＳＤＲＡＭＦ（Ｘ）：ｂｏｏｔｍｅｍｏｒｙ－－，－ＳＲＡＭ情景２ＳＤＲＡＭＦ（Ｘ）：ｂｏｏｔｍｅｍｏｒｙ－－．＇ＮＯＲＦｌａｓｈ情景３ＮＯＲＦｌａｓｈＦ（Ｘ）：ｂｏｏｔｍｅｍｏｒｙ－－．．ＮＯＲＦｌａｓｈ３Ｕ—ｂｏｏｔ的不合理性分析从ｆｔｐ：／／ｆｔｐ．ｄｅｎ】【．ｄｅ下载最新的Ｕ—ｂｏｏｔ一１．３．０。

对ＡＴ９１ＲＭ９２００而言，入口位于ｅｐｕ／ａｒｍ９２０ｔ／ｓｔａｒｔ．Ｓ。

此段代码为：／＊重定位中断向量表＊／ｌｄｒｒ０，＝一ｓｔａｒｔｌｄｒｒ１．＝０ｘ０ｒｌｌｏｖｒ２，＃１６ｃｏｐｙｅｘ：ｓｕｂｓｒ２，ｒ２，＃１ｌｄｒｒ３，［ｒｏ］，＃４ｓｔｒｒ３，［ｒ１］，＃４ｂｎｅｃｏｐｙｅｘ代码的作用就是把Ｕ—ｂｏｏｔ开始的０ｘ４０个字节复制到０ｘ０开始的位置，也就是实现了中断向量表的搬移。

结合表１，对情景是没有问题的，这样实际就复制到了ＳＲＡＭ中；但是，对于情景２和３，就是不合理的了。

因为此时０ｘ０位置是ＮＯＲＦｌａｓｈ，它们都是不可以直接以字节写入的。

也就是说，对情景２和情景３，这段代码不足以完成将中断向量表复制到ＳＲＡＭ中，并将ＳＲＡＭ映射到０ｘ０开始的１ＭＢ地址空间内这个任务。

为了验证此结论，提出一个检测算法１：向０ｘ０位置写入０ｘ５５，然后读取０ｘ０的数值，看看是否为０ｘ５５。

如果是，说明此处为ＳＲＡＭ；如果不是，说明ｐａｐｅｒ＠ｍｅｓｎｅｔ．ｃｏｎＬｃｎ（投稿专用）Ｍｉｃｒｏｃｏｎ仃０ｌｌｅｒｓ＆ＥｍｂｅｄｄｅｄＳｙｓｔｅｍｓ２９万方数据此处为非易失性存储介质。

利用这个算法，可以在ｌｉｂ—ａｒｍ／ｂｏａｒｄ．ｅ中插入测试代码，验证表１结论的正确性。

经实验分析，表１是正确的。

这样也就间接证明了上述代码的不合理性。

如果想要直接测试，也可以提供一个简单算法２：在ｌｉｂ－ａｒｍ／ｂｏａｒｄ．ｃ中插入测试代码，读取从０ｘ０开始的０ｘ４０个字节，然后与Ｕ＿ｂｏｏｔ．ｂｉｎ起始位置的０ｘ４０个字节对比，看看是否一致。

４解决方案为了对三种情景都支持，就需要根据３种情景的特点来进行区分，如表２所列，这样才可以实现３种启动方式的无关性。

这里需要解决的问题是，通过检测算法１可以判断出情景１；然后判断此时Ｕ—ｂｏｏｔ是在ＳＤＲＡＭ还是在ＮＯＲＦｌａｓｈ，可以区分情景２和情景３。

表２３种情景复制内容对比复制起始复制到达是否情景复制的长度位置位置重映射情景１＿ｓｔａｒｔ０ｘ０１６×４否情景２ｓｔａｒｔ０ｘ２０００００１６×４是（一ｓｔａｒｔ＿ａｒｍｂｏｏｔ－．．ｓｔａｒｔ）情景３Ｏｘｌ０００００００Ｏｘ２０００００是》２＋１对情景１和情景２，因为此时Ｕ—ｂｏｏｔ已经在ＳＤＲＡＭ中，所以是否执行重映射对Ｕ—ｂｏｏｔ本身的执行并无影响。

但是对情景３，此时Ｕ—ｂｏｏｔ仍在ＮＯＲＦｌａｓｈ中，ｂｏｏｔｍｅｍｏｒｙ仍然指向ＮＯＲＦｌａｓｈ。

一旦执行重映射，ｂｏｏｔｍｅｍｏｒｙ会立即指向ＳＲＡＭ，那么ＰＣ下一条指令就无法正常获取了。

为了保证其正常获取，必须把跳转到ＳＤＲＡＭ之前的代码复制到ＳＲＡＭ中，这样重映射前后就会实现无缝转换。