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：


#ifdefined(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处，那么启动显然死掉。通过上面描述的情况已经证明了这一点。

 

#ifdefined(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:
        movlr,ip
        movpc,lr

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