u-boot-1.3.2 run in flash for at91rm9200

主要目的:移植u-boot-1.3.2到K9开发板,使其直接从FLASH 启 动,而不是通过boot.bin和u-boot 压 缩文件 启动。实现u- boot的非压缩式的从FLASH的0x10000000地址处直接启动。

硬件资源:K9开发 板                                                                                                                                                                   

    MCU      : ATMEL AT91RM9200 QU
    SDRAM    : HY57V281620HCT-H 2片(4banks*2M*16bits=16MB,2片组成32M内存空间
    Nor Flash: JS28F128,类似于28F128J3A,不过速度快点。位宽是16bits,容量为16M。
    PHY      : DM9161E
 
u-boot版本:u-boot-1.3.2
   
    FLASH驱动、SDRAM、FLASH大小等修改在此不再多说,主要是修改nor FLASH驱动(board/atmel/flash.c)、开发板配置文件(include/conifgs/at91rm9200dk.h)、加载地址 等几个文件。本文的 主要目的介如何使u-boot直接从FLASH的0x10000000处启动的办法。
    之前成功的将u-boot-1.3.2移植到该硬件平台,不过u-boot是通过load.bin将u-boot解压到SDRAM中运行的!后来直接将 u-boot.bin烧入FALSH后,重新上电后u-boot并没有启动,终端也没有任何反应。因为之前在SDRAM中能成功运行,并且测试过 FLASH的读写都是正常的,所以可以排除FLASH读取错误的可能。后来经过几番查找,终于发现问题就出在cpu_init_crit中 lowlevel_init:


#if defined( CONFIG_AT91RM9200DK) | | defined( CONFIG_AT91RM9200EK) | | defined( CONFIG_AT91RM9200DF)

#else
        bl    lowlevel_init
#endif

此 段代码中直接将lowlevel_init屏蔽,导致u-boot只能在SDRAM中运行。可以有两种方法实现:(1)片内启 动,loader.bin+u-boot.bin。(2)利用片内启动,把boot.bin和u-boot.bin.gz固化在相应位置,即实现压缩方式 的uboot启动。
因为boot在初始化完成后,会把uboot.bin解压到sdram中。所以上述两种方式下,本质上 uboot的生命周期都在sdram当中。
    但是考虑,如果采用非压缩方式,直接把u-boot.bin放在0x10000000处,那么启动显然死掉。通过上面描述的情况已经证明了这一点。
 

#if defined( CONFIG_AT91RM9200DK) | | defined( CONFIG_AT91RM9200EK) | | defined( CONFIG_AT91RM9200DF)
        adr  r0, _start
        ldr   r1, _TEXT_BASE
        cmp   r0, r1
        beq  1f
#endif
        bl     lowlevel_init
1:
        mov lr, ip
        mov pc, lr

重新编译后将u-boot.bin下载到FLASH中,重新上电后u-boot成功启动!

阅读更多
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭