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并对设备下电。

 

原文地址:https://www.cnblogs.com/liang123/p/6325611.html