升级文件系统出现request_module: runaway loop modprobe binfmt-464c的问题

问题描述：
自己编译并烧写busybox后无法进入系统，系统挂在request_module: runaway loop modprobe binfmt-464c错误处。

----------具体情况如下-----------------------
环境：
ubuntu 12.04 LTS
arm-linux-gnueabi-gcc-4.6.3
uboot出厂自带
linux-2.6.30.4厂家修改版（光盘中的源码）
busybox-1.21.1
mkyaffs2image（厂家光盘自带）
dwn（厂家光盘自带源码）

现象：
1.
用arm-linux-gnueabi-gcc编译linux内核（以厂家config_EmbedSky_W35_256MB作为配置文件），成功生成zImage文件并烧写到NAND中；
用此内核可以成功启动厂家光盘自带root镜像（root_qtopia_2.2.0_2.6.30.4_256MB_20091216.bin）。
2.
自己编译busybox并配置相关文件系统内容，用mkyaffs2image制作镜像文件，烧写到开发板成功，但启动后无法进入系统。最后的输出信息如下：

yaffs_read_super: isCheckpointed 0
VFS: Mounted root (yaffs filesystem) on device 31:2.
Freeing init memory: 176K
request_module: runaway loop modprobe binfmt-464c
request_module: runaway loop modprobe binfmt-464c
request_module: runaway loop modprobe binfmt-464c
request_module: runaway loop modprobe binfmt-464c
request_module: runaway loop modprobe binfmt-464c

3.
从网上搜原因发现主要有以下几点可能：

• 编译内核时没有选中“Kernel support for ELF binaries”，事实上我已选中，且内核能够直接引导厂家的文件系统，故可以证明内核没有问题；
• 编译busybox时没有在makefile里改写corss_compile和arch变量，但是我都已经改了；
• 编译busybox时没有选中“Build BusyBox as a static binary (no shared libs)”，这个我也选了；
• 64位系统上运行32位程序的问题，在这里根本没有这个说法的；
• 没有生成/bin/sh文件，这个其实是生成了的；
• 怀疑busybox不是EXE格式或者ARCH不对，我用file和readelf都查过了，看不出问题；
• 怀疑权限问题，我的文件系统里的文件都是root用户root组，bin中、sbin中的文件，rcS和inittab文件有执行权限；
• 怀疑库不全，库是我从编译环境中拷贝出来的，“cp -rfd *** ****”。
  

单纯从这个错误上讲，以上所有解决方案皆不能生效。

4.
进一步分析，自己看了内核kmod.c文件源码，同时参考网上的说法，这个过程是内核希望支持ELF文件格式，所以需要加载一个模块来支持这种文件格式。郁闷的是，在加载这个文件格式的时候，内核是调用的/sbin/modprobe这个外部程序来实现的，而这个程序是指向/bin/busybox的符号链接，/bin/busybox本身就是个ELF文件，于是死循环了。
按照这样的原理分析，确实应该在内核中选中“Kernel support for ELF binaries”就可以内建支持ELF了，但是不知道为啥“不行”。如果真“不行”的话，为何又能把厂家的root_qtopia_2.2.0_2.6.30.4_256MB_20091216.bin驱动起来呢？此处甚是不解。


5.
进一步探索，就让系统加载厂家的镜像好了，然后在这个镜像里执行“tar -cjf root-tq.tar.bz2 /”，把文件系统整个打包，用u盘拷出来，到我的ubuntu上，然后解压，用这个文件系统做了一个nfs服务，最后将uboot设置为nfs启动。很顺利，系统以nfs模式启动成功了。
这样做的目的是方便对厂家的镜像进行手术。
所谓手术，就是直接尝试用我编译出来的/bin/busybox去替换nfs里边的，替换并重启后就“request_module: runaway loop modprobe binfmt-464c”，再把实现备份的busybox文件拷回来重启又好了。
这时开始怀疑我的busybox文件格式有问题，于是就有了上文中file和readelf检查，发现各个关键属性都与厂家版本一样的。


6.
补充一下，NAND我是整个重新格了的，然后烧写厂家的uboot，然后是自己的内核，然后是文件系统。
之所以要升级，是因为应用依赖的库版本较高，所以……
大体就是这样了，求大仙救命啊！我是新用户，只有40块，全悬赏了！

最终解决办法：执行“readelf -A devel/busybox”，发现
Tag_CPU_name:
7-A
Tag_CPU_arch: v7
可是2440是不支持这个架构的，应该是
Tag_CPU_name:
4T
Tag_CPU_arch: v4T
所以要在CFLAG上加上-march=armv4t -mfloat-abi=softfp -msoft-float
来指定架构（顺便指定一下使用软浮点，因为2440没有FPU）。
另外我的arm-linux-gcc 4.6.3不支持armv4t架构，下载源码重新编译了一个arm-linux-gcc后成功了。

对比TQ2440配套光盘中的busybox的配置单检查你的busybox的配置单，估计是配置单中的配置选项选错了引起的。

亲，问题解决了请修改帖子类型为“已解决”（请参考：http://www.armbbs.net/forum.php?mod=viewthread&tid=15200）。