又怎么了呢？想吧。一时间真的搞不懂了。后来看了一些关于ads编译的资料，发现原来RO、RW和ZI还有文章。主要是没有技术支持，这些东西都要自己摸索，唉。。。。。。

   
   
 
 
        ARM编译生成的代码中会分成两部分，RO和RW。同时编译会产生以下几个重要的地址空间分配变量：（如果想知道编译结束后，这些变量到底被赋了什么样的值，可以按照FIGURE-5配置ARM Linker。编译完成之后，你就可以看到很多编译细节，包括函数定位之类的信息。）
|Image$$RO$$Base| ：Read Only 代码部分的起始地址。FIGURE – 3的RO BASE。
|Image$$RO$$Limit| ：Read Only 代码部分的结束地址。
|Image$$RW$$Base| ： Read Write 代码可读写部分的起始地址。FIGURE – 3的RWBASE。
|Image$$ZI$$Base|  ：这里是程序中用到的一些变量使用的空间。
|Image$$ZI$$Limit| ：变量结束的地址。

再看一段程序，BIOS中的初始化RAM的一部分程序：

      ResetEntry是FIGURE-4中的 Image Entry Point。即程序入口地址。可以看出，上面程序的主要功能是将RO中的数据搬移至RW，同时将ZI中的数据清零。

      这就对了，我最初的RO和ResetEntry都设至成了0，这样的话，数据搬移的时候就把已经被我擦除的Flash空间中的数据（一连串的0xff ）搬到了RW段，所以导致程序无法正常运行了。我把RO和ResetEntry都设至成了0x1f0000，RW设成0xc700000。编译。然后再烧录到FLASH的0x1f0000。重启，OK啦！板子跑起来了，用rdpc命令，读出pc值是0x1f41c4（FIGURE - 6）。完全正确。不过还是BIOS程序，只不过换了个地址跑而已。不过这下明白了，前面提到的直接copy到0xc000000不能运行的问题也解开了。

       重新设置了R0和ResetEntry都设至成了0xc000000，RW不变。然后编译成bin。从串口下载到板子的0xc000000处，然后run 0xc000000 。哈哈，跑起来了。rdpc返回值是0xc0041c4。正确。

    下一步，是把uClinux的image下载到0xc000000处。在整个调试过程中，我的TCP/IP网络部分不知道什么时候坏掉了，看来还得抽时间去买个8019了。所以只好用串口下载了。串口下载了好几次，数据都不够，通讯会丢数据。最后不得不用FLUTED了，虽说慢点儿，但还是很好用啊（700多K，烧了50分钟吧）。image文件被烧到了0x100000处。然后重启进入0x1f0000处的BIOS程序，运行move 100000 c000000 100000 。然后run c000000。
 
 
    呵呵，启来了。不过后面报错了，看来我要装linux然后做修改了，到这里也算一个段落了，所以做个总结吧。

    我的一点点心得，里面可能很多漏洞的地方，我也是个初学者，希望高手能够指点。

           Robertchain@163.com