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成功启动！