IMX51启动模式

相关链接：

http://blog.csdn.net/kickxxx/article/details/7236040

http://blog.csdn.net/evilcode/article/details/6079767

IM51有4种启动模式，通过GPIO管脚BOOT_MODE[1:0]来选择。在系统重启时，所有的启动引脚被采样并存储到SBMR(System reset controller Boot Mode Register，系统复位控制器启动模式寄存器)。连接BOOT_MODE到地对应逻辑0，对于逻辑1，飞思卡尔推荐连接到NVCC_PER3(为什么推荐此电平，是为了最大可能的避免启动时启动引脚电平处于unknown状态导致启动异常吗？)。

这4中启动模式分别是Internal BOOT、reserved、Internal BOOT-ROM Select和Serial Downloader，它们对应于BMOD[1:0](SMBR寄存器的14和15位)的值如下：

图1

其中BMOD[1:0]=01是飞思卡尔预留用来作为内部测试使用的。

1.      Internal Boot(BMODE = 00)

在此模式下设备上电时，处理器从Internal ROM(IMX51内部的ROM大小为36KB)启动，内部启动代码执行HW初始化，通过使用HAB库校验application image的有效性和跳转到application image(这里指uboot或是xldr)的地址并接着执行。如果在内部ROM执行过程出错，启动代码将跳转到serial downloader模式。

当设置为BMODE = 00模式，将由eFUSE设置或使用GPIO覆盖的fuse设置来控制启动流程，这两种选择是通过GPIO引导选择熔丝(GPIO_BT_SEL)来控制的：

⑴如果GPIO_BT_SEL(=1)熔丝被熔断(被烧录过)，所有的启动选项由eFUSEs来控制。内部的启动代码可以从SBMR中读取BMOD[1:0]的值，或是直接通过IIM(IC Identification Module，IC识别模块)模块读取eFUSEs。

⑵如果GPIO_BT_SEL(=0)熔丝是完整的(没有被动过)，启动选项由SBMR的设置来决定。此模式下一些熔丝选型可能被覆盖，具体哪些熔丝可以被覆盖，这是由GPIO那一列中写明了YES来决定的，比如：

图2

在此模式下之能通过SBMR来读取启动选项的值，比如图2的BT_MEM_CTL[1:0](也对应SBMR[1:0])，至于eFUSE中哪些驱动选项的值可以由哪些对应的GPIO口来覆盖的，见图3：

图3

由图3可知，DISP1_DAT[14:13](GPIO)的值会覆盖BT_MEM_CTL[1:0]的值，也就是说BT_MEM_CTL[1:0]的值由DISP1_DAT[14:13]来决定，由此可见此模式下这些GPIO的设计非常重要，否则很有可能导致启动无法正常启动。

2.      Internal Boot-ROM Select(BMODE= 10)

BMODE = 10模式相当于BMODE = 00模式，差别在于BMODE= 10模式忽略GPIO的启动覆盖，也不管BT_GPIO_SEL的设置。此模式只使用eFUSE的设置来启动，这样可允许用户在最终的产品上(完成开发，交付给客户的产品)熔断熔丝。没有了外部的BOOT_MODE引脚，没启动GPIO上拉和下拉，这样就不会出现在设备启动时，由于启动引脚(比如图3左边的GPIO)的不确定值导致了调用Serial Downloader。

此模式下，启动流程发现如果BT_BLANK=0没有被烧录过(ROM没有被烧录过)，启动流程被重新定向并跳转到Serial Downloader。如果BT_BLANK=1被烧写过，则是正常的启动流程，并且使用eFUSE来启动。

当板子第一次使用时，如果没有熔丝被熔断，连接到启动GPIO引脚上的pad可能产生一些值，这可能被ROM code错误使用而导致启动流程从不存在的设备上启动。这可能产生电气/逻辑上的破坏，但此模式解决了这个问题。

3.      Serial Downloader(BMODE = 11)

当外部Flash设备没有程序，或是在启动过程中遇到错误，或是遇到下面的一些情况，启动留出都会跳转到Serial Downloader：

⑴BMOD[1:0] = 11 (serial downloader mode)

⑵BMOD[1:0] = 10和eFUSE的BT_BLANK=0

⑶BMOD[1:0] = 10但熔丝没有被正确设置。

⑷BMOD[1:0] = 00或10，且没有有效的镜像文件在Flash中。

⑸ Security hardware failure

⑹运行时产生异常

⑺ Error returned by the HAB functions while in productionmode. Errors are ignored in engineering

mode)

为了检测有效的串行端口(UART或USB)，处理器的ROM程序定期间隔32s轮询UART和USB状态寄存器。如果在预定的轮询时间内没有发现有效的端口，ROM程序就通过看门狗对处理器断电。当serial downloader有效，看门狗定时服务，如果serial host和IM51之间的通讯在32s之外没有反应或是处理器进入死循环，看门狗就timeout并对设备下电。