2007/0903-2007/0907工作周记

    这个星期的工作计划主要是使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对内存的管理，以后再做总结。