嵌入式linux開發中如果沒有在掛載根文件系統時碰到“Kernel panic - not syncing”的問題，我想他肯定還沒有開始動手入門。
這個問題可能由兩種原因造成的，一個是ABI接口，一個是ECC。
關於ABI（application binary interface）接口的原因跟gcc編譯器版本和kernel的配置選項都有關。這篇博文《ABI/EABI/OABI詳解及ARM-linux 浮點運算解析與配置》（http://www.cnblogs.com/andrew-wang/archive/2012/12/15/2819819.html）詳解了ABI接口的知識，給出了一些重要文檔的鏈接，這在嵌入式底層OS開發中非常重要。一般來說需要選用版本較高的Gcc編譯器（比如4.3 、4.4 、4.5各版本），在內核編譯時選擇“EABI優先&OSBI兼容”，這樣在ABI接口方面一般問題不大。
即在配置內核時，在KernelFeatures下選上兩項內容，即
Kernel Features --->
[*]Use the ARM EABI to compile the kernel
[*]Allow old ABI binaries to run with this kernel (EXPERIMENTAL)
關於ECC（Error Correcting Code 錯誤檢查和糾正）方面的一些問題，這主要是內核的ecc機制與文件系統ecc機制的不兼容導致的，一般來說嵌入式領域常用在nand存儲器上的yaffs等文件系統的驅動，其本身就有ecc方法，則往往內核不需要開啟ecc。推薦看一下這篇博文 http://blog.csdn.net/hongjiujing/article/details/1820601，這里稍作引用：
“
1、"mount_devfs_fs(): unable to mount devfs, err: -2"一個困擾了我很久的問題，主要是ecc的問題。在此我把我的理解說一下好了：
搞清楚你在driver/mtd/nand/s3c2410.c文件中有沒有把NAND_ECC_SOFT改成NAND_ECC_NONE，這個網上不少的人都會做（聽說會與yaffs文件系統有沖突，但我發現反而和cramfs文件系統有沖突）。
假設你把NAND_ECC_SOFT改成NAND_ECC_NONE，那[*] Lets Yaffs do its own ECC 這一步是必需的。
如果你把NAND_ECC_SOFT改成NAND_ECC_NONE的話，那你下載yaffs文件系統的時候就不應該加上-e的參數了。
最后給點建議：先讓內核掛載cramfs試試看（記得把NAND_ECC_SOFT改成NAND_ECC_NONE哦），因為這個文件系統只要用下載內核的命令下載就行。
2 確保devfs修改正確.由於linux 2.6.12后取消了devfs,因此你自己在fs/kconfig里面添加devfs的支持。
”
注意用uboot燒寫yaffs到nand上的命令是“ nand write.yaffs xxxxx ”，而像cramfs這樣的只讀的簡單系統只需要普通的“ nand write ”方法就行了，內核也一樣。這是因為yaffs文件系統利用的nand中的oob校驗區，因為nand相比nor雖然價廉物美，但卻可能發生位反轉。
http://blog.csdn.net/lanmanck/article/details/4355412 這篇博文也從yaffs源代碼層面講解了一些ecc機制。
=======================================================================
另外一個在底層調試中，內核啟動常遇到的問題是驅動加載崩潰出可愛的Oops信息，比如故意修改錯誤一下網卡驅動，內核啟動時Oops如下：
“... ...
Cirrus Logic CS8900A driver for Linux (Modified for SMDK2410)
Unable to handle kernel paging request at virtual address e000030a
pgd = c0004000
[e000030a] *pgd=00000000
Internal error: Oops: 805 [#1]
Modules linked in:
CPU: 0
PC is at cs8900_probe+0x11c/0x344
LR is at 0xe0000300
pc : [<c00183f0>] lr : [<e0000300>] Not tainted
sp : c02f1f44 ip : c3cf6bf4 fp : c02f1f64
r10: 00000000 r9 : 00000000 r8 : 00000000
r7 : 00000000 r6 : 00000002 r5 : c01f3a84 r4 : 00000000
r3 : e000030a r2 : 00000000 r1 : c3d09600 r0 : e000030a
Flags: NzCv IRQs on FIQs on Mode SVC_32 Segment kernel
Control: 717F Table: 30004000 DAC: 00000017
Process swapper (pid: 1, stack limit = 0xc02f0198)
Stack: (0xc02f1f44 to 0xc02f2000)
1f40: c0152b48 00000000 c01f3a84 c02f0000 00000000 c02f1f80 c02f1f68
1f60: c0152c58 c00182e4 00000000 c01f3a84 c02f0000 c02f1f98 c02f1f84 c0152f7c
1f80: c0152bd8 c01f3a84 c001c394 c02f1fac c02f1f9c c00182c8 c0152f24 c001c8c4
1fa0: c02f1ff4 c02f1fb0 c001f0b4 c00182b4 00000000 00000000 c001f02c c00381ec
1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1fe0: 00000000 00000000 00000000 c02f1ff8 c00381ec c001f03c 64342520 6c616320
Backtrace:
[<c00182d4>] (cs8900_probe+0x0/0x344) from [<c0152c58>] (register_netdevice+0x9) r7 = 00000000 r6
= C02F0000 r5 = C01F3A84 r4 = 00000000
[<c0152bc8>] (register_netdevice+0x0/0x34c) from [<c0152f7c>] (register_netdev+) r6 = C02F0000 r5
= C01F3A84 r4 = 00000000
[<c0152f14>] (register_netdev+0x0/0x7c) from [<c00182c8>] (cs8900_init+0x24/0x3) r5 = C001C394 r4
= C01F3A84
[<c00182a4>] (cs8900_init+0x0/0x30) from [<c001f0b4>] (init+0x88/0x260)
r4 = C001C8C4
[<c001f02c>] (init+0x0/0x260) from [<c00381ec>] (do_exit+0x0/0x724)
r7 = 00000000 r6 = 00000000 r5 = 00000000 r4 = 00000000
Code: e28e000a e3500201 e1a03000 328334f2 (e1c340b0)
<0>Kernel panic - not syncing: Attempted to kill init!”
雖然最后也是打印Kernel panic - not syncing信息，但是這種情況很明顯是內核驅動錯誤，與上面講的掛載文件系統接口錯誤是不同的。