以往2440和6410的启动方式，只要我们把裸板代码烧写到NAND FLASH的开始位置，当开发板上点启动时，处理器会自动从NAND FLASH上拷贝前面一段的代码到内部的RAM中执行。按照以前的方法，我写了一段汇编代码，如下：
1_ARM/1_start/start.S 1 #define WTCON 0xE2700000 2 3 .text 4 .align 2 5 .global _start 6 7 _start: 8 //close the watchdog 9 ldr r1, =WTCON 10 mov r0, #0 11 str r0, [r1] 12 13 loop: 14 b loop
代码没做什么具体的操作，大致如下：
1.只是将0写入看门狗寄存器0xE2700000，关闭看门狗，如果不关闭看门狗，芯片启动一段时间后就会自己复位。
2.进入死循环loop。
按我们所想，这段程序烧进我们的开发板后，我们也不会看到任何实际的现象，因为他什么都没做，仅仅陷入了死循环。
1_ARM/1_start/Makefile
all: /usr/local/arm/arm-2009q3/bin/arm-none-linux-gnueabi-gcc -c start.S -o start.o /usr/local/arm/arm-2009q3/bin/arm-none-linux-gnueabi-ld start.o -o start /usr/local/arm/arm-2009q3/bin/arm-none-linux-gnueabi-objcopy -O binary start start.bin cp start.bin /fastboot/test.bin clean: rm start start.o start.bin
有兴趣学习Makefile的可以上网查看关于Makefile的规则，我这里只是简单带过，用到哪个介绍哪个，具体的命令使用可以百度。
1.arm-none-linux-gnueabi-gcc：将汇编文件编译成.o文件，该命令同样可以将.c文件编译成.o文件，-o参数是指定输出文件的名字。
2.arm-none-linux-gnueabi-ld：将命令参数所带的.o文件链接成elf格式的文件，-o参数是指定输出参数的名字。
3.arm-none-linux-gnueabi-objcopy：将elf格式转化成.bin格式，这个格式可以放在开发板上运行。
当使用命令”make”的时候，就会执行Makefile中all文段的命令，当使用命令”make clean”，就会执行clean文段的命令，删除相关文件
至于烧写的方法，不同的开发板有不同的方法，我开发板的烧写办法是：
1.将一个能正常启动的uboot烧写倒SD卡上。
2.通过SD卡启动，在uboot中，通过fastboot将我自己的镜像烧写到NAND FLSAH的bootloader分区上。
3.选择通过NAND启动，开发板就会加载并且运行我的代码。
但是，我将编译出来的start.bin文件烧写到开发板后，并没有出现我预期的现象，而且会发现，如果我没有将SD卡拔出的情况下，它居然会跑到了SD卡上的uboot，而明明我选择的是从NAND启动。
这段代码我曾在2440和6410上都是可以正常运行的。
这是问什么呢？接下来一一解答。
这是我从《s5pv210_irom_applicationnote_preliminary_20091126.pdf》中拿出来的，它描述了一个系统起来的步骤。一个系统的起来会经过3个步骤：
1.BL0，上图显示IROM的框图。一个芯片上电能够运行起来必须要有两个设备：存放启动代码器件和让代码运行的内存，这分别就是S5PV210自带64K的IROM和 96K的IRAM 。当开发板上电时，芯片就会从IROM中将固化的启动代码放到IROM上运行，而我们将IROM上的代码称为BL0。它主要做一些加载我们自己代码前的一些初始化工作，按上面的描述介绍：
1）关闭看门狗和使能I Cache。
2）初始化堆栈。
3）初始化PLL和系统时钟。
4）通过读取OM几个GPIO管教的高低电平，判断从那个块设备读取代码到IRAM中，接着还需要进行一个校验，如果校验通过就往下走，否则就会从另一个块设备读取代码，直到校验通过，才会做下一个步骤。
5）如果启用了安全模式，还要检查BL1的完整性。
完成以上步骤，BL0就会转跳到BL1的代码处继续运行。
2.BL1，我们的裸板代码就是烧写到这个位置上，但是BL1的大小是有限制的，最大才16KB，这比我们的bootloader的大小要小。在实际的嵌入式开发中，BL1会做一些基本的硬件初始化，初始化内存，并把整个bootloader加载到开发板的内存上，并跳转到新加载代码的位置。
3.BL2，这才是真正bootloader运行的代码，实现了一下bootloader应有的功能。
我们这次的重点是BL0部分，其中步骤5的安全模式我们是没有启动的，而步骤1.2.3是不会影响代码跑不起来的，值得怀疑出问题的地方就在步骤4。
通过检查，OM的6个GPIO管脚是正确的（关于OM管脚的介绍可以查看芯片手册的《BOOTING SEQUENCE 》章节）。而上面也描述了另一个现象：在插有SD卡的情况下，开发板启动了SD卡上的Uboot。
所以，我的代码不能启动的原因大致已经清楚了：在步骤4中，我的代码校验失败，而同时开发板上的SD卡存在，处理器重新在SD卡上读取代码，并通过了校验成功运行起来。
有文档的介绍看出
IRAM的地址是从0xD0020000开始，总大小有96KB，但文档介绍存放BL1代码的位置最大之后16KB，包括BL1的前4个字节。
IRAM的前4个字节是定义用于存放BL1的header info。主要的是0xD0020000地址处存放的BL1大小和0xD00200008地址处的校验和。当BL0加载BL1时，会根据”BL1 size”加载BL1到IRAM上，最大只能加载16KB。加载BL1后，BL0会计算BL1的校验和并且与header info中的”Checksum”比较，如果两个相等才会开始运行BL1的代码。而所谓的校验和，就是计算代码中“1”的个数。
而我的代码，并没有header info那部分，所以启动时就会出错。改正的方法很简单，将编译后的start.bin在处理一下就可以了。
在原来的Makefile基础上再多加两句话：
gcc mkv210_image.c -o mk210
./mk210 start.bin 210.bin
mkv210_image.c是网上的代码，主要的内容就是求出镜像的校验和并放在header info的位置，并将herder info和原来的镜像合并在一起生成一个新的镜像。至于 BL1 size的位置，这个代码的并没有存放BL1的大小进去，但并不影响，因为“BL1 size”处的值已经远远超出了16KB的大小，BL0加载BL1时就只会加载16KB的代码到IRAM上。
上面新加的两条命令先通过gcc将mkv210_image.c编译成可执行文件，接着通过mk210将start.bin和求出的header info整合成新的210.bin。
将新的镜像下载到开发板上，同样没有任何的现象——因为我的代码什么都没做，但在不会发现说启动SD卡上的uboot这种情况。
根据上面BL0的介绍，代码里面的关闭看门狗操作也是多余的。
源码下载到文章原创作者http://blog.chinaunix.net/uid-25014876-id-3544728.html