NANDFLASH启动与标准库问题
把u-boot的start.S移植到我的程序上，这样程序可以用supervivi的D功能下载到内存中运行了，但是还不够。因为程序在内存里，如果掉电程序就没有了，所以我们得将程序固化在flash里面。这里我们要固化在NandFlash里，这就要求程序可以能够NandFlash启动。这里我参考了mini2440的nandlfash读写程序nand.c，里面有一个函数CopyProgramFromNand就是将Nandflash里的程序复制到内存里。在这之前我一直用u-boot默认的下载地址0x33f80000，这个是为了u-boot引导内核方便而定的，因为内核要下载到前面的内存中，既然我的程序没有这个功能，那下载到0x30000000里就可以了。把start.S中的TEXT_BASE改成0x30000000就可以了。还有在start.S里，复制完程序判断r0是否为零，如果不是那么程序就会进入死循环。根据AAPCS，C程序返回的值就保存在r0里，这里是判断程序是否返回了0，在CopyProgramFromNand里默认没有返回值，所以要在最后加上返回值。接下来就是消除编译错误。将nand.c链接到我们的程序里，注意一定要保证在程序的前4k的位置范围内，因为Nandflash启动的时候，S3C2440将Nandflsh的前4K的内容复制到芯片内部的SRAM里，如果NandFlash的读写程序不在这4k的代码里就无法完成程序的拷贝。
编译好的程序在我的下载资源里：http://download.csdn.net/detail/yaozhenguo2006/3752515
Nandflash启动进行的还算顺利，修改之后下到nandflash里，然后开发板切到nandflash启动，程序正常运行。这里我注意到流水灯不像下载到内存中运行的那样立即就运行，而是等了一段时间，说明拷贝代码用了一些时间。接下来就是要移植mini2440自带库函数了，对应的文件是2440lib.c，我本来以为简单的加到Makefile里就会成功。可是事情不是想象的那样简单，当编译的时候出现了一大堆错误。这些错误刚看起来都莫名奇妙，而且不是编译的错误，都是链接的错误。编译的时候没错说明不是语法错误，链接错误说明是库出了问题。主要提示的错误信息如下：第一类：
2440lib.o: In function `Uart_Init': 2440lib.c:(.text+0x370): undefined reference to `__aeabi_i2d' 2440lib.c:(.text+0x390): undefined reference to `__aeabi_ddiv' 2440lib.c:(.text+0x3a8): undefined reference to `__aeabi_i2d' 2440lib.c:(.text+0x3c4): undefined reference to `__aeabi_ddiv'在Uart_Init这个函数中，主要用了一些浮点数的运算和除法的运算，我们知道armv4指令集是没有除法和浮点运算指令的，所以必须软件模拟。编译的时候模拟除法与浮点运算需要的库，在链接的时候链接器没有找到，所以出现了这个问题。为了验证我的猜测，我把浮点数运算以及除法运算都注释掉，错误提示就没有了。说明就是没有找到浮点运算以及除法运算的库。
第二类：
2440lib.o: In function `Uart_GetIntNum': 2440lib.c:(.text+0x994): undefined reference to `strlen' 2440lib.c:(.text+0xa20): undefined reference to `atoi' 2440lib.c:(.text+0xa5c): undefined reference to `__ctype_b_loc' 2440lib.c:(.text+0xa90): undefined reference to `__ctype_b_loc' 2440lib.o: In function `Uart_Printf': 2440lib.c:(.text+0xd90): undefined reference to `vsprintf'在Uart_GetIntNum这个函数中主要调用了标准C库中的strlen和atio函数，找不到符号，说明链接的时候没有找到标准C库。Uart_Printf也应该是同样的错误。
对于以上两种问题都是库的问题。既然链接器找不到相关的库。我们就加上一定的链接选项让他找到。在做这个之前我们先了解一下，gcc开发环境下程序链接的两种方式。第一种使用gcc自带的链接功能。以arm-linux-gcc来说明，这种链接方式命令基本形式如下
$(CC) -static -Wl,-Tboot.lds,-Map,system.map -nostartfiles -o boot.elf $(objs)
CC 这里就是arm-linux-gcc
-Wl,-Tboot.lds,-Map,system.map -Wl表示后面的参数是传递给链接器的，参数以逗号分割。-Tboot.lds 是指定的链接脚本，规划了程序在内存中的位置 -Map,system.map 这是链接后生成的符号表
-nostartfile 不让链接器加入默认启动代码，如果不加这个选项，链接器就会默认加入一个启动代码，因为我们要链接自己的启动代码，当然不需要它默认的了。
-o boot.elf 最后生成的elf格式的文件。
$(objs) 我们编译的.o文件
用以上形式链接程序，arm-linux-gcc会调用collect2链接器，这个链接器有一定的默认选项，比如默认寻找库的路径，默认链接的库。通过给arm-linux-gcc 加上-v 选项，我们可以查看他的默认行为。现在以我的开发环境为例，链接的时候会有如下的输出：
/home/sun/study/crosstools/4.4.3/bin/../libexec/gcc/arm-none-linux-gnueabi/4.4.3/collect2
从这个输出中，我们可以发现，arm-linux-gcc调用了collect2。
--sysroot=/home/sun/study/crosstools/4.4.3/bin/../arm-none-linux-gnueabi//sys-root
-Bstatic -dynamic-linker /lib/ld-linux.so.3 -X -m armelf_linux_eabi -o boot.elf
sysroot暂时没有发现是做什么的，-Bstatic 很显然是静态链接
-L/home/sun/study/crosstools/4.4.3/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.3
-L/home/sun/study/crosstools/4.4.3/bin/../lib/gcc
-L/home/sun/study/crosstools/4.4.3/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.3/../../../../arm-none-linux-gnueabi/lib
-L/home/sun/study/crosstools/4.4.3/bin/../arm-none-linux-gnueabi//sys-root/lib
-L/home/sun/study/crosstools/4.4.3/bin/../arm-none-linux-gnueabi//sys-root/usr/lib
以上就是collect2默认寻找的库路径
-Tboot.lds -Map system.map
传递过来的链接器参数
start.o lowlevel_init.o nand.o interrupt.o main.o 2440lib.o print.o
要链接的.o文件
--start-group -lgcc -lgcc_eh -lc --end-group
这个选项很重要，链接器链接的静态库。-lc 代表链接标准c库， -lgcc 代表要链接libgcc.a，这个库应该是gcc扩展的库。 下面说一下另外一种链接方式，就是用ld命令来链接，这里就是arm-linux-ld，这种方式也就是我链接出错的链接方式。这种链接方式，没有默认的参数，寻找库的路径以及链接库都要自己添加。之所以链接出错就是因为我没有指定链接的库以及寻找库的路径。既然如此，那么使用第一种链接方式链接我的程序就应该是没错的。我将Makefile修改了一下再make，还是有错，令人欣喜的就是错误减少了，就只剩下如下的这一种错误：
/home/sun/study/crosstools/4.4.3/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.3/libgcc_eh.a(unwind-arm.o): In function `get_eit_entry': /opt/FriendlyARM/mini2440/build-toolschain/working/src/gcc-4.4.3/libgcc/../gcc/config/arm/unwind-arm.c:673: undefined reference to `__exidx_end' /opt/FriendlyARM/mini2440/build-toolschain/working/src/gcc-4.4.3/libgcc/../gcc/config/arm/unwind-arm.c:673: undefined reference to `__exidx_start'经过分析我认为是Uart_Printf函数里调用vsprintf的缘故，将Uart_Printf注释掉，然后再make。链接就通过了,说明就是这个vsprintf的问题。放下这个问题先不管，我试一下ld这种链接方式，在加上寻找库的路径以及要链接的库名的情况下是否可以成功make。修改Makefile如下:
CC = arm-linux-gcc
LD = arm-linux-ld
OBJCOPY = arm-linux-objcopy
objs := start.o lowlevel_init.o main.o nand.o 2440lib.o
boot.bin: $(objs)
$(LD) -Bstatic -Tboot.lds -Ttext 0x33F80000 $(objs) \
-L/home/sun/study/crosstools/4.4.3/lib/gcc/arm-none-linux-gnueabi/4.4.3 \
-L/home/sun/study/crosstools/4.4.3/arm-none-linux-gnueabi/sys-root/usr/lib \
-Map boot.map -o boot.elf --start-group -lgcc -lgcc_eh -lgcov -lc --end-group
$(OBJCOPY) -O binary boot.elf boot.bin
%.o:%.c
$(CC) -Wall -c -o $@ {1}lt;
%.o:%.S
$(CC) -Wall -c -o $@ {1}lt;
clean:
rm -f *.bin *elf *.o 用以上的Makefile，make通过了。程序下载到板子上现象也是正确的。这说明ld链接器正确链接了程序。现在两种链接方式都可以正确的链接程序了。那么就剩下一个问题，就是Uart_Printf函数里vsprintf。这个函数是一个格式化字符串转换函数，应该是标准C库里的函数，在链接器能够找到c库的情况下，两种链接方式都提示同样的错误。我猜测vsprintf这里面还调用了其他库的函数，我找了很久也没有找到到底调用了什么库。打印函数对于程序调试是必须的。既然vsprintf不能使用，那么就自己实现一个。参考u-boot的printf的实现，我自己编写一了一个vsprintf，然后结合Uart_SendString实现了串口打印功能。
简单的说一下实现printf的方法，首先要解决函数可变参数的问题，printf（char *fmt,...）显然是一个可变参数函数，第一个参数为字符串，后面是格式化输出参数列表。c语言中函数的参数都是压进栈里的，可变参数函数必须有一个参数表示参数的个数，才能让编译器知道要压进栈多少参数，以及函数返回时弹出多少参数，printf（char *fmt,...）实现这个功能的就是fmt字符串，里面有多少'%'，就代表后面有多少个参数，所以我们必须提取出fmt字符串中'%'的个数，以及针对'%'后面不同的字符来处理参数。printf实现类似如下：
void myprintf(char *fmt,...)
{
va_list ap;
char string[256];
va_start(ap,fmt);
myvsprintf(string,fmt,ap);
Uart_SendString(string);
va_end(ap);
} va_list 其实就是*char类型，va_list ap 也就是开始定义了一个char类型的指针变量ap。 va_start是一个宏，作用就是取得fmt指针地址，并跳过这个地址赋值给ap，这样ap就指向了除了fmt指针的第一个可变参数在内存中的地址，然后通过myvsprintf(string,fmt,ap)对fmt字符串结合可变参数进行转化，并把转化的结果赋值给string，最后通过Uart_SendString()函数将字符串发送给串口。具体实现可以看我的源代码。在我的资源里
http://download.csdn.net/detail/yaozhenguo2006/3774535
标准C库的问题就算暂时解决了，不过还是给我提了一个醒，在arm-linux-gcc上开发裸机程序，如果用到标准C库一定要注意，不是所有的函数都可以使用，比如vsnprintf就不能使用。其他还有什么函数不能使用还是个未知数，所以尽量不用标准C库的函数才是保证程序安全的办法。典型的例子就是u-boot，它就没有使用标准c库，所用的相关函数都是自己实现的，这样就保证u-boot很强的可移植性。也许arm-elf-gcc会没有这个问题，毕竟链接的是ulibc库，专门针对嵌入式的，以后有机会一定要验证一下。