這個星期的工作計劃主要是使linux2.6能在開發板上跑起來。這次就不加-u參數，而是用minicon觀察，結果是大大出乎我的意料，minicom只打印了一句Booting Linux......和一句亂碼就終止了。開始分析的時候以爲是波特率的問題，重新設定好波特率，結果一樣。後來，我就把內核的映射地址修改爲sdram的掛載地址0x60000000，並且不用-nosram的參數，結果還是一樣。我又懷疑是串口的問題，就編寫了一個簡單的程序測試，結果minicom表現正常。
最後，只有翻代碼了。後來從kernel/vmlinux.ld.S看到了這段代碼
SECTIONS
{
. = 0x10000 + SIZEOF_HEADERS;
.text 0xf0004000 :
{
很明顯內核把可執行代碼放在 從0xf0004000（當然是虛擬地址）開始的一段內存裏面。使用sparc-elf-objdump觀察一下，發現可執行代碼的確是從0xf0004000開始：
[root@localhost linux-2.6.21.1]# sparc-elf-objdump -S vmlinux
vmlinux： 文件格式 elf32-sparc
反彙編 .text 節：
f0004000 <__stext>:
f0004000: 10 80 24 0b b f000d02c <gokernel>
f0004004: 01 00 00 00 nop
f0004008: 01 00 00 00 nop
f000400c: 01 00 00 00 nop
f0004010 <t_tflt>:
f0004010: a1 48 00 00 rd %psr, %l0
f0004014: a7 50 00 00 rd %wim, %l3
f0004018: 10 80 00 00 b f0004018 <t_tflt+0x8>
f000401c: ae 10 20 01 mov 1, %l7
而內核每次出錯都是在0xf000dcb8退出，然而這些都是虛擬內存，目前無法得到它們對應的物理地址。不然就可以找出問題的根源。
根據這個情況，lby懷疑是地址映射可能有問題，因爲leon3的核把cache分爲指令、數據兩部分，但是linux2.6卻有可能不是如此實現的。
無論如何，似乎都應該搞清楚linux內核的mmu都是如何實現的。
這個星期還看了linux2.6對內存的管理，以後再做總結。