本
笔记零散写于2009 年2 月~5 月，最初基于2009 年1 月20 日

dev.lemote.com 上的pmon 版本。后期使用的是更新版本，部分代

码和当前版本有误差，不过应该影响不大。

2

目录

扯3

配置空间的访问10

start.S 之内存15

start.S 之cache 20

从汇编到c 25

Init_net 之tgt_devconfig 53

tgt_devconfig 之显卡55

tgt_devconfig 之config_init 58

tgt_devconfig()之configure 61

回到init_net 80

open 函数88

load 内核98

printf 和write 108

键盘和键盘事件的响应114

环境变量和flash 125

你怎么出来了－－ 图片显示137

3

扯

一开始大家都不认识，先胡乱抛出几句话扯扯，熟悉熟悉。就是开场白，也有人

说叫序。

pmon 是cpu 上电后执行的代码，相当于x86PC 机中的BIOS，兼有bootloader

的功能，代码来源于早期BSD 的内核，到如今已旧貌换新颜，糟蹋得差不多了。

pmon 的二进制代码存放于主板上的一块512KB 的flash 芯片上，选择这个容量

是因为够用了，龙芯2F 允许的最大boot rom 容量是1MB。

这块flash 芯片的地址是确定的，虚拟地址0xbfc00000，物理地址0x1fc00000。

cpu 上电后，会在第一时刻从虚拟地址为0xbfc00000 的读取指令执行，这个和

x86 的cpu 是一样的，差别的只是地址。

地址差别的一方面是地址值，另一方面是地址类型。

x86 有实模式和保护模式的区别，上电初期为实模式，地址就是物理地址。MIPS

没有这两种模式的区别，而且一开始就是虚拟地址。虚拟地址是虚的，所以必定

需要映射到物理地址。

下面介绍一下pmon 文件相关的地址问题。

cpu 眼中的地址是虚拟地址，cpu 取指和取数据的地址是物理地址，经过北桥解

释后的地址是总线地址，编译器产生的地址（包括解析了所有引用和重定位的符

号后）为程序地址，也就是程序它自己理解的地址。不同的地址概念间需要有映

射函数来关联。

mips 的虚拟地址到物理地址的映射比x86 要复杂一些（也更有用些），既有可供

页表之类动态建立映射函数的机制，也有unmapped cacheed/uncached 这种固

定映射关系的转换方式。bios 代码由于其执行时机的限制，开始阶段只能使用

unmapped uncached 这个段。地址范围是0xa0000000~0xc0000000，也就是

2.5G 到3G 的512MB 空间。这个范围的映射函数为物理地址＝程序地址-2.5G。

所有的32 位mips 架构的cpu 都遵循这个约定。

pmon的代码绝大部分是用C写的，只有个别的体系结构相关的代码使用了汇编。

好，先到这儿吧。

如果你对pmon 感兴趣，想了解它的框架，

如果你对pmon 感兴趣，想了解各个设备在bios 中是如何工作的，

如果你对pmon 感兴趣，想找一个理解pmon 的N 天搞定法。

以及不满足上述条件的其他人

就不要在这浪费时间了。本
笔记只讲述流程。

好，想看流程或者愿意浪费时间的，Let‘s go。

start.S 在pmon 中的作用？

核心是把pmon 的二进制文件复制到内存。并初始化cache，内存控制器，内

存和南桥的部分信号。这个代码执行之后会执行c 代码，解压在二进制中压缩

的bin 文件，跳到解压后的代码继续执行。

由于一上电的时候，内存和内存控制器都处于不确定的状态,所以cpu 一开始执

行的代码不能在内存中存放，只能把bios 的代码放在非易失性的介质中（实际

都是nor 型的flash）。由于在这类介质中的执行速度比较慢，所以尽可能的，要

把其中的bios 代码载入到内存执行，这需要先初始化内存控制器。要初始化内

存控制器必须获得内存的spd 信息，而内存的spd 信息需要通过i2c 总线读取,

而i2c 模块在南桥上，访问要在初始化smbus 之后，要访问南桥又必须先初始

化北桥，要访问北桥又需要先初始化cpu本身。这是个一环扣一环的过程。start.S

基本就是围绕这个流程展开的。当然在初始化南桥的SMB 总线以外，顺便把南

桥相关的其他一些信号也初始了，这些具体的可能要看电路图了。

start.S 是在cpu 上电之后立即执行的代码。

为什么？就因为它叫start.S？

MIPS cpu 约定cpu 执行的第一条指令位于虚拟地址0xbfc00000，而pmon 的二

进制代码是以load -r -f bfc00000 gzrom.bin这个命令烧入bfc00000这个地址开

始的flash，硬件布线会使得虚拟地址0xbfc00000映射到这块flash上。而start.S

就占据了gzrom.bin 的开头部分。

为什么gzrom.bin 的开头就是start.S？

是./zloader/Makefine.inc 中的L29：

mips-elf-ld -T ld.script -e start -o gzrom ${START} zloader.o 决定的。

start.S 文件是用汇编语言写的，关于龙芯汇编语言的内容请参阅mips 指令手册

cpu 上电后，内部的寄存器一些可写的寄存器的值是不可预知的，所以代码先设

定cpu 的部分内部寄存器。在第一条汇编指令前有一行注释如下：

就是说这里已经是16 条指令了，不能再多了云云。如果你实在想不明白这怎么

有16 条指令，那么反汇编一把，看到的确是16 条。

如果你没想明白，还要问那么为什么不能超过16 条呢？。。。。。。。。。。

我也不知道了。呵呵。

如果你非要铤而走险，在中间多加些指令非让它超过16 条，那么哥们你太聪明

了，你将发现这只是个玩笑而已。是吧，这帮写代码的有时没正经。

好，言归正传，这个start.S 共有2656 行，的确不算太短。

现在我们按照cpu 的执行顺序对start.S 代码进行逐一分析。

cpu 执行的第一条指令在L 213，

zero 就是寄存器0($0)，和下面的t0($8)之类相似，都由asm.h 中incldue 的

refdef.h 定义的，由预处理去解析。

一开始将状态寄存器和原因寄存器清零主要是禁用所有的中断和异常检测，并使

当前处于内核模式。之后执行：

以上两句只是设定当前的异常处理模式处于启动模式，启动模式(BEV=1)和正常

模式(BEV=0)的区别是异常处理的入口地址不同，具体如下：

此表来自龙芯2F 的用户手册,更详细的status 位描述见手册第五章。

sp 的赋值就是初始化栈，栈是函数（或过程）调用的基础设施，也是使用c 语

言的前提。

可见栈的大小为16KB，不算小了。

_gp 在ld.script 中定义，gp 的作用主要是加快数据的访问，这里不予关注。

先说说bal 这条指令，这条指令是一个pc 相对跳转指令(这一点很重要)，跳转的

目的是把ra 寄存器和0xa0000000 相或，将cpu 的执行地址映射到unmapped

uncached 段(对于一般的情形，这是多此一举，想想当前pc 寄存器的值)。

由于地址问题是一个核心问题。下面解释一下龙芯2F 地址转化过程。

CPU 获得的地址是虚拟地址，在获得这个地址之后，CPU 的内部逻辑首先判断

这个地址落在哪个段，有的段虚拟地址到物理地址的转换公式是固定的，比如在

32 位模式下，kseg0，kseg1 就是直接映射的。无论如何，在获得转换后的地址

也就是物理地址后，cpu 并不知道这个地址是发往哪里，是内存，pci，还是内

部的cpu 的io地址。这个发送方向也就是地址路由是由地址窗口寄存器决定的。

在2F 中，这些地址寄存器的地址是从0x3ff0_0000 开始的48 个寄存器。注意，

这个地址是物理地址。

以32 位的为例（这个比较简单），我们要关心的就只有3 个地址窗口。

从http://www.loongson.cn/company/下载的龙芯2F 用户手册中介绍了这3个地

址窗口。3 个地址窗口分别是：

cpu 窗口0，负责物理地址到内存地址的转换。

cpu 窗口1，负责物理地址到pci 或者cpu localio 的转换

pcidma 窗口0，负责把收到的DMA 请求进行pci 总线地址到内存地址的转换。

比如0xbfc00000 这个虚拟地址，cpu 首先判断这个地址落在kseg1 段，直接转

换且不经过cache，转换成的物理地址0x1fc00000。接着地址窗口寄存器就派

上用场了。一个一个窗口去判断这个地址是否落在自己管辖的范围内（当然更有

可能这个动作是并行的）。假设首先cpu 窗口0 去判断，它拿自己的mask 寄存

器去mask 这个传入的地址，两个cpu 窗口的mask 都是0xffffffff_f0000000。

mask 后，0x1fc00000 就成了0x1000_0000，这个地址是cpu 地址窗口1 的基

地址，所以它就负责由cpu 窗口1 来路由。在传往下一个部件之前这个地址会

被cpu 窗口1 包装一下，下面的就认识了。这个转换公式我没怎么看懂，当然

也可能是作者文档没写清楚。有兴趣的可以看看。以上的地址转换在cpu 核内，

还每到本桥的层次。

7

下面结合代码解释pmon 二进制的地址问题。

在链接阶段，使用了ld.scripts 作为链接的规则。生成的gzrom 程序地址是从

0xffffffff81000000 开始。ld.script 的片段如下：

因此gzrom（包括用objcopy 生成的gzrom.bin）的程序地址是0xffffffff81000000

到其后的有限范围之内的。而在cpu 执行这段代码之初，pc 寄存器的值是

0xffffffffbfc00000，而程序自己认为这条指令的地址是0xffffffff81000000，在寻

址方式为pc 相对寻址或立即寻址时没有任何问题，在其他寻址方式时就会出现

问题。比如在pmon 拷贝到内存之后，现在要引用地址为0xffffffff82000000 这

个程序地址的内容，指令实质为ld t0,0(0xffffffff82000000),问题就出来了，

0xffffffff82000000这个程序地址对应的段会使用cache，而当前cache还没有初

始化，cache 不可用，唯一的解决方法就是将这个地址转换到0xffffffffa0000000

~0xffffffffc0000000 这段空间内，且能映射到同一物理位置的地址，其实只要在

原地址的基础上再加一个偏移值即可。L 223 的lacate 的目的主要就是算出这个

偏移值,具体计算如下：

这里有个很合理的疑问，为什么链接规则文件ld.script 中程序地址（start）要从

0xffffffff81000000 开始呢?直接搞成0xffffffffbfc00000 不更简单吗？

下面分析分析这个选择的原因.从传统的32 位地址空间的分布看，共有4 个段：

首先第一个段和第四个段首先被排除，因为这两个段内的程序地址转化需要页表

的辅助，现在连内存都不可用，不可能用页表。再要排除的是第三个段，用这个

段内的地址，可以免去上面这个偏移值的麻烦，但是处于rom 执行阶段在整个

bios 的执行过程中只占很少的一部分，99％以上的代码是要被载入内存执行的，

就没有这个偏移值了，且在内存执行时，当然要尽可能使用cache 加快执行速

度，第三个段的地址引用不使用cache。当然要提一句，如果不用cache，使用

第三个段作为程序地址也不是不可能的。

locate 除了计算以上说的那个偏移值到s0 外，接着重新初始化状态寄存器和原

8

因寄存器，这个代码应该是不必要的。

如果使用cpu自带的串口模块，则初始化这个模块。在显卡没有初始化的情形下，

调试最好的方式就是使用串口。initserial代码和普通的串口除了地址，没有区别，

具体可参看任何一本接口技术书籍，都有讲解这个NS16550 兼容芯片的。

龙芯cpu的串口地址COMMON_COM_BASE_ADDR 为0xbff003f8,这里要说一

句，其实这个0xbff003f8 就是0xffffffffbff003f8，因为龙芯2 号系列cpu 都是64

位的，而且mips 结构的64 位cpu 都是32 位兼容的，32 位的地址都默认被符

号扩展成64 位的，前头的0xbfc00000 其实和0xffffffffbfc00000 也是一样的。

L 452~L 512 的非定义语句都是作为初始化表，其实就是一些供特殊解释的数

据。解释部分在L 524~L 746。这部分和cpu 相关性非常大，由于有些对旧cpu

（比如2E）的支持代码仍然存在，部分代码对于龙芯2F 是不需要的。

下面是对北桥的pci 配置空间头部的初始化（大小为256 字节）。从这个意义上

说，北桥也是一个pci 设备。北桥的pci 配置空间头部首地址为0xbfe00000(龙

芯2f 手册P107 表11-1 有误，将pci header 和registers 的地址互换了)，2F 的

pci 控制器遵循pci2.3 规范。

一句一句分析吧，L472 first。

现在我们需要一个文档，pci2.3 的标准手册。看该文档P195 的图，结合代码，

可见这句在设置class code，结合P197 开头的解释，最高字节是base clase，

这里是PCI_CLASS_BRIDGE， 值为6， 次高字节为sub class， 这里是

PCI_SUBCLASS_BRIDGE_HOST ，值为0。看到P270 的解释：base class

为06h，sub-class 为00h 表示这个pci 设备为主桥（host bridge）。在pci 结构

中，主桥就是北桥，可见这句代码表示我们的北桥是主桥。

全是xxxx_CLR，初始化,pci command 和status 字段具体位的功能见规范P198

开始的解释。

设定这个pci 设备是一个单功能设备，配置空间头部使用pci 规范中表6-1 的布

局，设置cache L 大小为255，根据规范，这个值是无效的，等同0，所以以上

这句等同于BONITO_INIT(BONITO_PCILTIMER, 0)

初始化基地址为0，在BIOS 中这三个寄存器分别设置为访问系统内存、为ISA

设备DMA 访问和北桥BONITO 寄存器访问的PCI 基址。

中断的初始化。

bfe00000 到bfe00100 是北桥pci 配置空间的头部，这两句的作用地址在

bfe00100 到bfe00200 之间，是北桥的io 控制寄存器地址范围。

这两句的功能主要是设置DMA 的时候的地址掩码，这个设置非常的重要。

设置某些位，使能奇偶校验和对io 空间，mem 空间的访问并允许北桥作为pci

总线上的主设备。

使能视频加速，这个注释有问题。

在龙芯2F 的体系中，bfd00000 开始的1MB 空间是pci 的io 空间，这个空间兼

容传统的isa 总线的io 地址分布。传统的io 端口地址分布如下：

I/O 端口地址分配表

系统板上接口芯片的端口地址扩展槽上接口控制卡的端口地址

I/O芯片名称端口地址I/O接口名称端口地址

DMA控制器1

DMA控制器2

DMA页面寄存器

游戏控制卡200H~20FH

中断控制器1

中断控制器2

并行口控制卡1

并行口控制卡2

定时器

并行接口（键盘）

协处理器

串行口控制卡1

串行口控制卡2

原型插件板（用户可用） 300H~31FH

同步通信卡1

同步通信卡2

单显MDA

彩显CGA

彩显EGA/VGA

硬驱控制卡

软驱控制卡

PC网卡360H~36FH

以上就是8254 的初始化，初始化这个定时器的作用为无，试过了，呵呵。

L524~L746 为初始化表（reginit）的解释，代码比较显然。

L752~L 801 为cpu 串口的初始化（如果使用的话）。

配置空间的访问

福珑盒子和逸珑
笔记本都使用AMD CS5536 的南桥，接着执行superio_init。

由于下面的代码会涉及配置空间的访问，夹在南桥中间挺不爽的，就在这介绍吧。

访问嘛，肯定就有个地址的概念，所以先简要介绍PCI 总线配置空间的寻址方

式。配置空间地址有两种格式，如下：

由于迄今为止，在2F 使用到的pci 体系结构中都没有超过一个pci 总线的，所

以我们可以以上图中的第一个作为理解设备地址的格式，总线域总为0。

图中的device select 的编码都是由连线决定的，比如主板设计出来后，cs5536

南桥的设备号PCI_IDSEL_CS5536 就定下是14。

好，看看配置读写的函数的实现。先看读函数PCICONF_READW。

PCICONF_RWADW 这个宏的定义如下：

上述这个宏中CFGADDR 定义为：

就是根据上图的方式组合出32 位的地址，作为要访问的配置空间的地址。

PCI_CFG_SPACE 值为0x1fe80000，是pci 访问配置空间的地址区域。

什么意思呢？就是所有对pci总线上设备的配置空间的访问都映射到这块地址区

域。这块空间的大小为2KB。这2KB 大小够吗？看看上面那个图，device 以外

的都在地址的低部分，刚好是11 位，2KB 设计时就是按这个大小来的。

在龙芯2F 的pci 体系结构中，对pci 配置空间的读操作顺序是：

1．把目的地址的高16 位写入PCIMAP_CFG 寄存器

2．对1fe080000 开始的那2KB 内的空间做读/写操作

3．从目的地址的低16 位和bfe80000 相或后的地址读内容

2F 手册P108 的页尾描述介绍了这个过程。

BONITO_BASE+BONITO_PCIMAP_CFG 是0x1fe00118，

这句就是往这个0xbfe00118 写那个32 位地址的高16 位。

这句紧接这上一句，看得出来，load个东西到zero寄存器就是不关心内容本身，

这里只是要对1fe080000 开始的那2KB 内的空间做读/写操作而已，再紧接的lw

a0, (a1)是真正意义上的读，a1 寄存器放的是那个32 地址的低16 位。

这条指令执行完之后，我们要读的配置寄存器内容就在a0 寄存器中了。

配置的写类似，就不讲了。

superio_init 的代码在L1966~L2271,这个代码的理解需要结合AMD cs5536 手

册的寄存器说明。

由于在代码中会涉及到对msr 的访问，这里就先介绍一下，免得到时犯晕。

msr 可以认为是外界眼中5536 的寄存器的地址，实际上是一种特定格式的

packet。用于指定将要访问的目标设备。

有关msr 的地址先看Targets/Bonito/include/cs5536.h

有如下定义：

在南桥手册的60 页有如下的映射关系：

也就是有如下对应：

由于这个问题的特殊性，我们以0x5120xxxxh 到0x4000xxxx 为例，看看AMD

的cpu（不是龙芯cpu）是如何访问南桥msr 的。

先看到南桥手册60 页的Table 4-2 中对地址位的描述。

比如AMD 的南桥要访问USB 的msr，会发送0x5120xxxx 这种类型的地址，根

据Table 4-2中的对地址高9位的描述：These bits are shifted off to the left and

never enter the CS5536 companion device，也就是说，高9 位的地址是会被丢

弃的，不会传到5536 上。

这个表中对于bit[22:14]的描述为：These bits are shifted into posi-tions [31:23]

are always 0 after shifting，也就是说这9 位会被shift 到高9 位，原9 位为0。

现在看下0x5120xxxx 的变化。

1．丢掉高9 位后，成了0x0020xxxx

2．bit[22:13]左移，成了0x4000xxxx

也就是说，虽然AMDcpu 发出对南桥USB 模块访问的地址是0x5120xxxx，但

是这个地址进入南桥时就成了0x4000xxxx 了。

龙芯cpu 不会在传递的过程中做任何处理，所以我们要访问南桥的USB 模块的

时候，就是发送0x4000xxxx 的地址了。其它的地址处理类似。

msr 的介绍就先到这，以下为superio_init 的代码：

在2F 的定义中，0xbfd00000（1fd00000）开始的1MB 空间相当于传统PC 的

io 空间，往bfd00000 这个地址写不知道是干什么。

PCICONF_READW 从命名上看就是读取cs5536 的0 号设备配置空间的0 号寄

存器。这个配置空间的读操作要传入的参数有三个：dev，func，reg。

PCICONF_READW 执行完之后，要读的内容已经放在a0 寄存器上了。

事实上，南桥上功能号为0的就是南桥本身这个设备，pci配置空间的第一个word

（mips 中的字都是32 位的）就是厂商id 和设备id，读取后马上比较是否正确。

代码如下，0x208f 和0x1022 就是设备id 和厂商id，代码如下：

cs5536 的配置头部的详细介绍在AMD 南桥手册P234，msr enable 见P236。

PCI 配置空间写的宏和读基本一样，只是最后的操作为写操作。手册的解释是

不管如何，先看看CS5536_MSR_WRITE 的定义：

可见，这个宏的第一个参数是寄存器的地址，后两个参数组成一个64 位数值的

高低32 位。南桥配置空间的0xF4,0xF8,0xFC，分别是pci msr 地址，低32 位，

高32 位。具体解释见南桥手册P237，P238。

CS5536_GLIU_MSR_BASE 这个常量的定义如下：

所以这个msr的地址实际就是0x10000081，想当于文档中的地址0x51010081。

参考AMD P205，看到0x51010081 是port active enable reg，这个寄存器的初

始值是0x00000000_0000FFFF，后16 位是1 表示使能全部八个端口。这八个

端口从0 到7 分别是GLIU，GLPCI_SB，USB，IDE，DD，ACC，保留，GLCP。

跳过test 代码。

这个值是初始值0x44000030_00000003，后两位的3 表示mem/io 写使能，其

余的表示设置flush，read，timeout。具体解释见AMD 手册229 页。

上面的几行代码的性质相同，从参数的命名就可以看出来，是设置io space 的

起始地址(也就是说这个起始地址是我们主动写入的，这些地址会在pci设备的初

始化之后重新分配)。具体解释见AMD 手册P357，这些地址的定义如下：

后面那个0xf001，0xf 是io mask，1 表示enable LBAR。

南桥串口的代码跳过。

接下来是南桥的ide 部分，自带的中断控制器8259 和开机键的初始化。都是

GPIO 的设置，说重要吧也重要，不过太多了，跳过。

下面是SMBus 的初始化，这个是非常重要的。等会探测内存的spd，就是通过

SMB 总线。所以这个初始化是必须的。具体代码略过。

略过gpio，flash 和usb 部分的测试。

以上是南桥相关的初始化，接着看代码。

如果定义了TEST_CS5536_SMB,则执行L814~L845，默认不执行。但理解这

个代码对于了解smb（i2c）的访问机制是很有好处的。所以还是委屈各位方便

的话看看吧。

start.S 之内存

L855~L871 是些打印语句，也不知道有什么必要。

接下来要执行的是L929，L929~L940 实际上就是一下几句：

前21 位保留，bit9－10 使能pci 和cpu 写内存写到内存，bit8 禁用ddr2 配置

bfe00180 对应的是chip_config0，具体位功能定义见2F 手册P116。

这句没有作用，在L979 被重新初始化了，可以去除。

L944 调用ddr2_config ,初始化内存控制器

ddr2_config 的代码在start.S 文件的底部，是L2402~L2657

这个ddr2 的初始化表和前头的reginit 类似，但有一点明显不同，那就是这个地

址要加个偏移值（L2416）。原因是la t0, ddr2_reg_data 这条指令执行后，t0

的值是0xffffffff8100xxxx，不能直接使用这个地址，原因在前头已经讲述。所以

在L2416 要加上这个偏移值。

2F 手册P97 页有句话“具体的配置操作是对物理地址0x000000000FFFFE00 相

对应的29 个64 位寄存器写入相应的配置参数”，足以解释L2417 和L2418 代

码的作用。

以上代码是循环些写完29 个配置寄存器。

略过debug 代码，执行到L2500.

L2501的注释已经说明了以下代码的功能是读取spd信息初始化内存控制器了。

0xa0，0xa1 作为i2cread 的传入参数。

这里有一个问题，内存上的spd 的地址是多少？

从代码上看是0xa0 啦。网上搜了很久，有网友有这样的帖子：“memory SPD

EEPROM 是走SMBus 总线，SMBus 总线下的设备是通过SlaveAddress 来标

识，一般Slot 0 上的memory SPD EEPROM 的SlaveAddress 为0x0A0，Slot 1

上的memory SPD EEPROM 的SlaveAddress 为0x0A2，你可以向SMBus 控

制器发送命令来读取SPD 数据。读deviceID 要+1, 所以是0xa1,0xa3,0xa5，

如果是write 的话，就是0xa0,0xa2,0xa4”。

我看了几个内存的手册，都没有看到关于spd 的i2c 地址的约定。但是我曾经看

过一个华邦的时钟芯片手册，手册中就明确写了i2c 的地址。

实际上设备地址的最后一位为1表示读操作，为0表示写操作。下面看看i2cread

是如何使用这两个传入参数的，i2cread 的代码在L2311~L 2394,

开始将a0 和a1 转存到t2 和t3 上，之后：

开头的注释已经说明了这段的功能，就是启动smbus 工作。

这里要注意到v0 是作为IO_WRITE_BYTE 的传入参数使用的

发送命令的下一部分，这个是index，传入参数是t3，就是开始的a1。

重新初始化，这是smbus 的约定。

上一页提到的，读的话deviceID 要加一，就是ori v0, 0x01 起到了加一的作用。

IO_READ_BYTE 的定义如下：

可见是把读的结果放到v0 中，这样至此我们就通过smbus 的协议把要读的结果

读到了v0 寄存器中，随后返回。

具体的smbus 相关的约定参看smbus 总线定义。

回到我们调用的入口，就是要将smbus 总线上（相对）地址为a0，index 为3

的内容读到v0 寄存器中。spd 的相关信息可参看kingmax 内存的手册P18

~P21,先介绍一下内存控制器需要的几个参数的含义吧。

代码中读取的参数共有4 个，index 分别是3,4,5,11h（17）。以kingmax ddr

-667 512MB 内存为例解释读出的各参数的含义。(kingmax 手册P20)

index 为3读出的值为0Dh，表示row address 是13，index 为4读出的值为0Ah，

表示col address 是10，这两个读出的参数经过简单的转化，写入内存控制器的

一个寄存器（程序地址为0xaffffe50），具体见2F 手册P99对这个寄存器的解释。

index 为5 读出的值为60h，表示可选的内存chip 为1。这个寄存器解释见2F

手册P100。

下面是L2550 ~L 2562 的代码，其中bne 一句表示读出的bank 值为8 的话，就

重新设置affffe10 这个地址的寄存器，具体见2F 手册P98 对这个寄存器bit32

的定义。可见8bank 的情形可能是比较特殊的。

不管如何，内存的配置就这样完成了，下面发个信号告诉内存控制器配置完成。

内存控制器的初始化完成后， 打印个信息表示一下。代码回到L949,

L951~L962 是内存只读检测。

由于内存控制器的配置已经完成，L966~L972 代码设置从现在起禁用DDR2 配

置端口，以免意外。具体见2F 手册P116。

其实内存的工作还没有做完，前面ddr2_config只是做了内存颗粒的行列地址数，

bank 数，并没有得到具体的内存大小数据。

注释说设定默认内存大小是256MB，这样具体有什么作用呢？无论如何都在

L1009 被重新赋值。

L982 开始读取spd 上的index 为31 的内容， 还是前面kingmax DDR2-667

512MB 内存为例。读出值为80h。

tempsize 存储相应的预计内存大小的值，但正如我们的例子，读出的是80h，

左移22 位，就是128x4MB=512MB,参考文档中还有hynix512MB 的内存spd

表，也可参考之。这段代码之后tmpsize 为2^29.，就是512MB。其中：

这几句话的作用不详。

接着执行到L999，

这个内容先前已经探测过了，这个返回的数据如果小于60h，表示这个内存是

DDR 内存或者内存颗粒不存在。如果返回值是61h，表示有两边，内存容量加

倍。比如kingmax文档中所写的1G内存的spd，index31的数据为80h，与512MB

的数值相同，但index 为5 的数值1G 的为61h，512MB 的为60h，可见这两个

数据就可确定了一条内存的容量。至此，spd 就再没什么用了。

start.S 之cache

接着执行到L1033~L1039,功能就是把bfe00108 的bit5~bit2 设成00011b，设

定rom 数据读取延迟。L1041～L1046 设定io 数据读取延迟，具体见2F 手册

L1060~L1069 的代码通过对比2E 北桥文档和2F 文档及bonito.h 文件，基本确

定属于2E 的遗留代码。

ok，内存控制器的初始化算是完毕了。接下来是cache 的初始化。

由于在上电之后，cpu 的cache 处于不确定的状态。

cache 初始化后，速度会快很多，下面看看cache 是怎么初始化的吧。

cp0 的config 寄存器指明了cache 的基本情况，config 的位定义如下：

IC 表示一级指令cache

DC 表示一级数据cache

IB 表示一级指令cache 行大小

DB 表示一级数据cache 行大小

K0 确定cache 的一致性算法

具体见2F 手册P49。

龙芯2F 采用的是两级cache 的结构，其中一级cache 包括64KB 的指令cache

和64KB 的数据cache，二级cache 为512KB（不区分数据与指令）。

龙芯的一级数据和指令cache，二级cache 都是4 路组相连的，cache 的组织有

必要说明一下，对理解代码是必须的。

以一级指令cahce为例（指令cache和数据cache的tag有不同），示意图如下：

注：这个图是从龙芯手册粘贴的，其中的index 512 应为511。

22

其中每个set 大小为16KB，每个set 内部有512 个cache 行，每个cache 行的

大小为数据32 字节，指令cache 的tag 为29 位，其中1 位是有效位，物理地

址标记ptag 为28 位。数据cache 的组织基本与这相似，由于数据是不像指令

是只读的，所以tag 中多了个状态位，其定义如下：

其中1 位W 表示已经写回，2 位CS（cache state）指示cache 的状态，如下：

00 －－－ 无效

01 －－－ 共享

10 －－－ 独占

11 －－－ 脏

龙芯的cache 以及TLB 与x86 的不同，对系统程序员不是透明的，所以cache

的组织是需要软件人员处理的，用的武器就是cache 这条指令。cache 指令的详

细说明在2F 手册8.2.6。

指令和数据的cache 都是28 位的地址位，在龙芯2F 的体系中，物理地址实际

都是40 位的，tag 中的是高28 位，低12 位和虚拟地址相同。

接着看代码到L1125，对照2F 的手册，明显感到这个代码与手册有一定差别，

很怀疑L1125~L1129 的必要性。

再到L1131，接下是算IC 和DC 的大小，IC 计算公式为size＝2^（12＋IC），

DC 类似。龙芯2F 的一级指令和数据cache 均为64KB，IC/DC 值为100b，也

就是4，但看这个代码，意图是报指令cache 的大小存进s3，但是计算方法有

误。事实上，在pmon 后面的代码中又对这个cache 进行了测试，这里的探测

没有实际意义。一级指令cache 行大小的计算公式为IC 等于1，则为32Byte，

为0 则为16Byte，DB 计算类似。L1153 和L1154 的计算方式很巧妙。之后的

是数据cache 的计算。

无论如何，现在找到了cache，要去初始化这些cache 了，这个工作是通过调用

godson2_cache_init 实现的。代码在L1693。

L1694 到L1705 的功能是检测一级指令和数据cache 的大小到t5 和t6 寄存器

中，可是这段代码实在是比较烂。不说了，不过从中可看出，这里又检测了一次，

故前面的cache 大小的检测是没有意义的。

看代码到L1717~L1720，看代码的命名和注释目的是初始化一级数据cache：

这里有一个虚地址（VA）的概念，比如上面这条指令，当v0 为0x80000000 是，

这条指令的虚地址为0x80000000＋0x0，这个虚地址是有讲究的，地址的低两

位表示要操作的路（way，4 路组相连的那个’路’），代码中v0 都是每次加0x20，

所以前面代码中cache 指令中逗号之后的数字就是路号。之所以要加

0x80000000 是因为这个地址是uncache 的，否则会有异常产生。

Index_Store_Tag_D 这个命名很明显就是要把TAGHI 和TAGLO 中的数据按照

一定的方式填充cache。TAGHI 和TAGLO 的位定义2F 手册5.20。这里cache

指令目的就是设置这些cache 的内容无效。代码中每次cache 后都要重新设置

TAGLO，不知何故，约定？？？

有一点要提的是Index_Store_Tag_D 的定义为0x5（00101b），反汇编中也很

明显，但2F 手册的P89 中这个数值对于Index Load Tag Dcache 的操作码，

Index Store Tag Dcache 的操作码是0x9（01001b），查看了mips64 的cache

指令编码定义，如果2F 遵守mips64 的规范，则2F 手册的解释应该是对的。代

码的作者疏忽了。但居然还能用，奇怪了。

接下来初始化L2 cache，大小是代码中写死的，2F 手册中也没有讲哪个寄存器

是标志二级缓存大小的， 只能写死。每路128KB， 也是4 路。这个

Index_Store_Tag_S 的操作码和2F 手册是一致的。

接下来的代码将二级缓存和指令cache 每个cache 行当前内容置为无效。（为什

么没有数据cache 的无效设置）

至此，godson2_cache_init 这个过程执行完毕。

代码返回后，执行L1171。L1171 和L1172 功能不详，可能是2E 遗留代码。

L1174~L1177 功能是置config 寄存器bit1 为1，bit0 为0，bit12 为0。这些代

码设置的位可能也是有些问题，比如bit12 在2Fcpu 中是写死的，bit0，bit1，

bit2 这3 个位合在一块才能确定k0 的cache 一致性算法。这里只写两位，有点

不伦不类。估计是前些版本的遗留代码。

好了，cache 就算这么初始化了，看看下面要干些什么。

这里先缕缕思路。我们初始化内存的目的是使用内存，初始化cache 的目的是

用cache提高内存使用效率，现在基本设置都差不多了。该准备搬rom 中的bios

代码到内存上来了吧。

在搬到内存前可以测测内存的稳定性，方法就是往0xa0000000 开始的1M 空间

写后读，看前后内容有没有差异，这个地址也不是随便取的。

内存测时候，代码执行到了L1257，一句“Copy PMON to execute location”告诉

我们拷贝bios 到内存的行动已经万事俱备了。

跳过debug 部分，到了L1278。

以上的代码功能比较清楚，设置各个寄存器

A0 pmon 的起始程序地址

A1 pmon 的起始物理地址，对应程序地址a0

A2 pmon 末尾地址_edate

T1 pmon 的实际大小（以字为单位，拷贝的时候用的是lw 和sw 指令）

值得一说的是or ...，0xa0000000 这句的作用。此时，cache 仍不能使用，因为

TLB 还没有初始化，所以仍要避免使用cache的程序地址的使用，a0既是pmon

的起始程序地址，作者又将其作为在内存中的物理地址使用（or 指令之前的那

个地址值），这个使用方式是十分正确的。比如假设start 这个标号的地址是

0x81001234，那么作者希望它搬到内存物理地址为0x01001234 的位置，

后面的代码有点意思：

前面算好的t1 被覆盖掉了，呵呵。

至此，可以这么理解了，t0 表示复制的目的起始地址，t2 是复制的目的结束地

址，t1 是复制的源地址。

L1292~L1307 是复制的具体代码，是指就是一个循环，每次复制一个字，标号

1 到2 之间的代码是用于调试目的的。

之后清零bss 段所占的空间，之后又是一段test 代码，跳过。

程序此时执行到了L1368，看注释可以猜测，TLB 的初始化就要开始了。在TLB

初始化前我们只能使用的程序地址都是在0xa0000000～0xc0000000（64 表示

的话就符号扩展）之间。这个TLB 的初始化时机是有讲究的，不一定说什么时

候最好。但TLB 是很小的，如果在复制操作之前使能TLB，是不是有意义？？？

可能白白地看着TLB 被迅速填满又马上被替换。

回到TLB 初始化的具体代码。

L1373~L1374 是设置L3 大小，对于2F 无效，这两句代码当舍去。

接下的是设置a0,a1,a2 这三个寄存器。

A0 －－－ 内存大小（单位MB）

A1 －－－ tgt_putchar 函数的在rom 中地址

A2 －－－ stringserial 函数的在rom 中地址

至于a1 和a2 的地址为什么这样设置，我暂时没有想明白。

以上三句，是cpu 从rom 取指令到从内存取指令的转变，从此内存执行的时代

开始了。jalr v0 的操作是PC<--v0,不是bal 那样的PC＋offset。initmips 的地

址是0x8 开头的，并不使用TLB，是否使用cache 要看config 寄存器的低3 位，

前面说到了，程序只设置了低两位为1，0，（非常不严谨的做法），底3 位只有

3 种情况有效，111，011，010，所以就算第三位是010 了，设置不使用cache。

到这我们可以明白了，那个TLB 的注释是挂羊头卖狗肉，根本就没有什么初始

化，和程序开始的时候那个16 条指令的限制一样，都是玩笑。

真正的TLB 初始化在哪里呢？？？？？？？？？？？？？

从汇编到c

这个initmips 在哪里呢？看过一些文档都说是在tgt_machdep.c 中，我一开始也

是这么认为的，但看看前面的a0,a1,a2 显然都是作为参数列表使用的(去看看

o32 的参数传递规则吧)。那个文件中的initmips 只有一个参数呀，实际上这个

函数的定义在initmips.c 中，这个文件是在编译过程中产生的。在我写的《pmon

编译过程分析》中写到：“initmips.c 的生成规则对应compile-output 的line 710”，

看看compile-output 文件中的line710，看到了吧

genrom 是一个用perl 语言写的脚本，我不懂这个语言，但这个脚本很短，基本

的意思也很清楚。

initmips 函数定义在initmips.c 中L66，当初我是怎么发现这个函数的呢？在当

时这个函数的L72 和L78 的打印语句还没有被注释掉，我在通过串口（显卡初

始化前只能用串口输出）做pmon 的实验的时候发现中间的“Uncompressing

Bios”这一句在不知道什么时候打印出来的，根据大部分文档的解释，直接就跳

到tgt_machdep.c 中，就不可能有这一句的打印。就这样找到了这个initmips.c

中了。当然通过反汇编看跳转的地址其实一下就看出来了。

总算看initmips 的具体代码了，也总算是看c 代码了。

开始几句的地址值是在perl 脚本中得到的。

这个debug 的值正常情况下为0（因为msize 不为0），也就是enable_cache

函数要执行。但是有个问题，这个dctrl 是什么东西?这个只是通过形式参数传入

的，按照o32 的标准也就是a0 对应函数的第一个形参（从左往右数，）依此类

推。a2 对应的就是第三个参数。这个initmips 的函数定义是initmips(unsigned

int msize,int dmsize,int dctrl)，也就是a2 对应的就是dctrl，我们肯定还记得，

调用initmips 前给a0,a1,a2 这三个寄存器赋了值，a0 是内存大小（单位MB），

a1 是tgt_putchar 函数的在rom 中地址，a2 是stringserial 函数的在rom 中地

址，对照这个函数的定义，第一个参数肯定是对的，当后面的两个就牛头不对马

嘴了。我是又看不懂了。

用minicom 看使用串口的输出是比较简单的。有些想法也可以修改源码，通过

串口输出来验证。minicom 的简单使用如下：

插上串口线，

下面就通过minicom 看看这个dctrl 的值。在int debug=(msize==0)这一行之后

加上一行hexserial(dctrl);即可

红字加粗的部分就是了，可见的确是stringserial 函数的在rom 中地址.所以这个

命名和if(!debug||dctrl&1)enable_cache()这句的条件判断部分就挺怪的了。可能

只有作者能解释了这个dctrl 的作用了。

无论如何，要去执行enable_cahe 这个函数了。enable_cache 函数在同一个文

件中，采用的是内嵌汇编。这段代码就是简单的把config 寄存器（cp0 的16 号

寄存器）低3 位设成011（3），即cachable。从此kseg0 段（0x8，0x9 开头的）

开始使用cache 了。

接下来执行

从名字就可以看出来是在解压。biosdate 是一个数组， 内容在zloader

/pmon.bin.c 中。我第一次打开pmon.bin.c 文件是差点昏过去。pmon.bin.c 文件

的生成见compile-output 文件：

bin2c 也是个perl 脚本，就是把pmon.b in.gz 的内容转化成biosdata 这个数组，

否则不方便集成到代码中。

这个解压的代码就不深入了，要知道压缩软件工作方法的可以看看。这个函数的

作用就是把biosdata 的数组加压到0x8001000 开始的地址上去。当然这个

biosdata 的内容究竟是什么呢？ 我们是一定要探究的。biosdata 来自于

pmon.bin.gz，pmon.bin.gz 来自于pmon.bin ，那么pmon.bin 是哪儿来的呢?

由于gzrom.bin 是来自于objcopy 后的gzrom,这个pmon.bin 很可能是来自于名

为pmon 的elf 文件。而且./Targets/Bonito/compile/Bonito/下正好有个叫pmon

的elf 文件，无疑了。问题来了，这个pmon 文件哪儿冒出来的呢！

看compile-output L703

看到了吧，其实这个pmon 几乎把所有代码都编进去了。包括start.o（虽然个人

认为没有必要）， 不过这里的ld.script 不同而已， 是代码段地址从

0xffffffff80010000 开始分配。个人推断，这个pmon 用objcopy 后的pmon.bin

是可以直接使用的，只是没有压缩。有兴趣时试试。

实际上./Targets/Bonito/compile/目录只是一个中转站。回到initmips 这个函数。

接下是bss 段的初始化，就是清零。

接着调用flush_cache2()，就是把二级缓存都置为无效。如果记性好的话，前面

已经做了同样的工作了。

不过前面的那个512*1024 改成了128*1024 而已，哪个才是对的呢？个人认为

是前者。还有2F 的prid 手册标称是0x6302，与实际不附。唉。

initmips 函数最后调用realinitmips 这个函数，从名字看出，这个realinitmips 才

是大家都认为的initmips。genrom 脚本中获取了真实的initmips 的地址，这个

函数还初始化sp 寄存器，栈大小为16KB（0x4000），并把msize 作为参数传

递给那个initmips 函数，然后跳转到那个函数。

从现在开始执行的就是那个叫pmon.bin 的文件的内容了，看反汇编也要看

Targets/Bonito/compile/Bonito/下那个pmon 文件的反汇编了，从此程序地址都

不再用0x81 开头的了，都用0x8001 开始的了。

首先执行的函数是initmips，在tgt_machdep.c 文件中。

对于512MB 的内存，设置memorysize 为256，memorysize_high 为256，这

个memorysize 是pmon 中能使用的内存大小，pmon 是不需要那么多内存。

接下来执行tgt_cpufreq()函数。实际上是执行_probe_frequencies 函数探测cpu

的频率。这个函数也在同一个文件中。

SBD_DISPLAY 这个函数就是一个打印函数，并在代码中写死只打印4 个字符，

这个限制可以通过在那个函数中写个for 循环解除，后面的那个参数没有使用。

看到这有两个freq，一个是pipefreq，一个是cpufreq，暂时先不解释，看了代

码就清楚了。HAVE_TOD 在../conf/GENERIC_ALL 文件中定义。

接着调用init_legacy_rtc(),这个函数在tgt_machdep.c 中定义。

这个函数是对实时钟的操作。PC 中通过I/O 端口0x70 和0x71 来读写RTC 芯

片的寄存器。其中端口0x70是RTC的寄存器地址索引端口，0x71是数据端口。

这个函数的意图就是读取当前的时间（人理解的格式，年月日时分秒）。

接着执行一个for 循环

假如单看for 循环内部的话，这个代码的功能就是看1 秒钟cpu 的count 寄存器

变化的值。这里先介绍这个cpu 内部的count 寄存器。这是个32 位的一个计数

器，每两个cpu 时钟周期加一次，假设2F 频率为800MHz 的话,每10.74s,即（2

接着看，中间那个do-while循环目的是等待一秒，退出条件有两个，要么timeout

为0，要么读取的RTC 到了下一秒。这里有个有趣的问题是：timeout 变成0 要

多久。timeout 的初始值为一千万，timeout 要变成0，这个循环就要执行一千万

次，那么这个循环体每次执行要多少世界呢？可以确定的是这个循环体指令不

多，但有两处对io 接口的访问，这个是比较花时间的。作者的原意是比较明显

的，就是正常条件下，一千万次循环时间要远远大于一秒。假如一个循环的时间

是80个时钟周期，一千万次就是80x10^7个时钟周期，以2F 主频800MHz 计，

就是1s 钟。可见作者是认为一个循环的时间要远远大于80 个时钟周期。当然

以上的是比较理想的情况，实际上，TLB miss，Cache miss 都加大了这个时间

的不确定性，所以外边要套个for 循环，却保这段代码指令，和变量都在cache

中了。这是作者开头注释说的第一个原因，他还说了第二个原因，就是while

(timeout != 0 && cur == sec)这个条件为假的时候，实际上就是cur 开始不等于

sec 的时候，就是RTC上刚好更新到下一秒的时候。在第一次进入那个do-while

循环的时候，那个秒的含义是不确定的，可能是一妙的刚开始，也可能是一秒的

中键，也有可能是一秒的末尾了，这样到下一秒到来的时候，这个时间间隔在0

~1s 之间，不能确定是否足够接近一妙，而循环两次就可基本解决这个问题。虽

然不可能绝对精确，但是这个时间间隔是极为接近1s 的。这是作者注释的同步

（synched ）的意思吧，我认为。这里好有个问题，就是count 寄存器是会溢

出的，而且前面算了，每10 秒多一点就溢出一次，看看这个函数的定义：可见

这个返回值是无符号的。

但是_probe_frequencies()中的cnt 却是int 型的。用无符号的话可以处理溢出的

问题，但这用int 也可以用，不解。

接着就按这一秒钟内的count 寄存器变化的值要算出cpu 的主频(pipefreq),

这里的cpufreq 可能是外部总线的频率吧（66M）。前面算pipefreq 直接乘以2

不行吗，为什么这样？不管效率，反正cpu 的频率算出来了。

至此这个函数调用结束，返回initmips 函数。

这个函数的调用层次很深，这个函数返回后，几乎大部分工作都完成了。这个函

数在.../pmon/common/main.c 中，好，下面进入dbginit 函数。

首先调用__init()，这个__init 就是对__ctors 这个函数的调用的包装，__ctors 函

数的的定义如下：

看得出来，这个函数就是挨个执行初始化列表上的函数。.__CTOR_LIST__是在

/Targets/Bonito/conf/ld.script 这个文件中定义的，其中第一个字表示这个构造列

表的大小，这个列表的内容相当于c++中的构造函数。

ctors 的内容是c 代码中所有包含constructor 关键字属性的函数，constructor

是gcc 中对c 的扩展，我认为只要函数声明中有__attribute__ ((constructor))，

这个函数的地址就会被放在构造列表中，就会在main 函数开始前被调用。由于

这个东西我也不了解，暂时就先按自己的想法理解吧。

标有__attribute__ ((constructor))属性的函数有多少呢？readelf -S pmon 一把。

看到了吧，这个ctors 节区大小为f4,也就是61 个字，除了首位两个（首是个数，

尾是0 标记），真正的最多是59 个函数。实际上通过打印一共有53 个有效的函

数。其余是对齐用了???

这53 个函数从性质上可分为3 类：命令初始化，文件系统初始化，可执行文件

类型初始化。

通过cscope 的显示明显可以看出，命令初始化的数量最多。这些函数都在../

pmon/cmds/的文件中定义，几乎是一个命令一个文件。每个文件的结构基本一

致，找两个最熟悉的命令为例分析吧，load，g。

load 命令初始化在cmds 目录下的的load.c 文件中。

这个文件的基本是由这么几个部分(基于空间的原因，略作修改)：

g 命令在cmds 目录下的cmd_go.c 文件中。

这个文件的由以下几个部分组成：

下面就具体分析load 这个命令初始化的全过程。

首先执行init_cmd 这个函数，

这个__P 不知是什么原因，没有实际作用。

Cmds 是个Cmd 结构的数组，Cmd 数组的定义如下：

Load.c 中这个Cmds 定义如下：

上面的数组是这么理解的。第一项表示这个命令所属的组是”Boot and Load “，

第二项是主角，对照Cmd 的定义，分别表示这个命令是load，可选的参数有

哪些，可选参数的解释，对命令的解释，命令执行的函数，最少参数个数，最多

参数个数，这个命令的类型（flag 定义解释得比较清楚）。

现在来看看这个cmdlist_expand(Cmds,1)的作用。一看比较简单吧，就是把

Cmdlist 的当前未使用的元素地址指向传入的Cmds 这个数组的地址就行了。

由于Cmdlist 数组的大小为100，最多只能添加100 次（当然一个Cmds 中

可以包含多个命令）。g 这个命令的注册也类似，就是填充Cmdlist 这个数组。

再看文件系统的初始化。

pmon 基本集成了最常用的文件系统，包括ext2,fat，iso9660 等。这些文件系

统初始化都在../pmon/fs/的下的文件中定义。下面以我们最熟悉的ext2 为

例介绍文件系统的初始化。

这个ext2 文件系统实现了ext2 文件系统功能的一个子集，包含了十几个函

数。实现了ext2 文件系统的基本读写功能。

diskfs_init($diskfile)函数完成文件系统的注册，传入的参数diskfile如前面定义。

diskfs_init()函数在../pmon/fs/diskfs.c 文件中定义。

这个就是调用SLIST_INSERT_HEAD，其中DiskFileSystems 这个参数是链

表头，这个宏定义如下：

就是些链表的常见操作，不具体叙述。

还有一类的初始化是针对文件类型的，分别有bin,elf,txt 等。下面以最常见的

bin格式为例介绍初始化,这些文件格式的初始化代码在../pmon/loaders/目录下。

bin 格式的初始化在文件exec_bin.c 中，这个文件大致有这么三个部分：

具体的bin 文件格式注册如下，

其中bin_exec 定义为：

以上是三类主要的构造函数，除此之外还有两个函数，分别是

都在../sys/dev/usb/的目录下，先看第一个。在文件usb.c 中

就是初始化host_controller 而已。

Init_kdb_driver()在usb_kdb.c 中，定义如下：

这个usb_kbd_driver 是个结构体,只有两个成员，分别是probe 链表信息。

至此所有构造函数执行完毕。__init 函数返回，回到了../pmon/common/main.c

的dbginit 函数中。

envinit的作用是环境变量的初始化。涉及的东西比较独立，我们在后面专门讲述，

这里跳过。

环境变量设置完毕后回到dgbinit()。接着执行

如果autopower 定义了这个变量，返回这个变量的值，否则返回0。执行

suppress_auto_start()，suppress 有压制，制止的意思。可见就是不许自动启

动了，这里的自动启动指的是上电后就启动启动进入系统。

这个suppress_auto_start()有点意思，居然往实时钟写个什么东西。

好了，接着执行tgt_devinit();

这个函数首先执行cs5536_init()，看名字就知道是对南桥的初始化。

这个函数依次调用以下四个函数。

先看cs5536_vsm_init()，代码中的那3 个PCI_SPECIAL_*都是没有定义的，实

际cs5536_vsm_init()要执行的代码如下：

这里的vsm(Virtual Support Module)

这是pmon 执行过程中第二次正式接触南桥，第一次是在start.S 中。上面的代

码就是三次多寄存器的读写。功能分别是重置错误位，确定关机的信号，表示ide

引脚都连接ide 控制器。

接下来是cs5536_i8259_init();可以看出来是中断处理芯片的初始化。跳过不叙。

接下来是cs5536_ide_init()，实际执行代码如下：

作者健忘，上面刚做了一次。

这个代码指定主从两个IDE 控制器的地址，具体见AMD 手册229 页。

使能IDE 控制器，具体见AMD 手册P336

不同模式下（多种pio 和dma 模式）的有效脉冲宽度和最小恢复时间的设置，

具体见AMD 手册P337

特定模式下命令的有效脉冲宽度和最小恢复时间设置，具体见AMD 手册P338

具体见AMD 手册P219

GLIU_IOD_BM[0,1]具体位定义相同，见AMD 手册P219

接下是ohci 的初始化，代码很短，如下：

具体见AMD 手册P203

具体见amd 手册P266

ohci 也是usb 主控制器的三大标准之一。关于ohci 的内容，请参看相关规范。

至此，cs5536_init()执行完毕，函数返回tgt_devinit()。

跳过与龙芯无关的两个变量的查找。

接下来是CPU_ConfigCache();

这个函数配置程序中要使用的cache 相关参数，代码在../pmon/arch/mips/

cache.S 中。这个代码的许多工作其实在start.S 中已经做了，代码看似很长，

真正执行的却不多。一开始无非是数据/指令的一级缓存大小和cache 行大小之

类的探测和部分赋值，start.S 中这个工作都做了，只是没有保存这些值而已。

直接转到实际部分，在读prid 知道是龙芯2 号之后，跳到ConfGodson2，可以

看到ConfGodson2 开始的一些代码都被注释了，都是和三级缓存相关的代码，

实际上ConfGodson2 开始的那两句也是没有用的。到了ConfGodsonL2。设置

二级缓存大小后，就到了ConfResult，就是些变量的cache 相关设置了。

剩下来tgt_devinit()还剩下要执行两个函数： _pci_businit(1)， cs5536_

接下来执行_pci_businit(1)。从函数名上看功能是pci 总线的初始化，实际包括

pci 设备的探询并初始化为一个设备链表，分配相应的资源（io 和mem 请求）。

传入的参数1 表示要初始化。_pci_businit 这个函数按照枚举的方式扫描总线，

并初始化相应的结构，代码在../sys/dev/pci/pciconfi.c 中。

跳过打印相关的语句，下面执行：

重点是_pci_hwinit (init, &def_bus_iot, &def_bus_memt)，这个init 就是传入的

参数1，表示开始初始化，其余两个参数一个是io 的空间描述，一个是mem 的

空间描述， 都是tgt_bus_space 的结构体指针，不过在函数中都未使用。

bus_reverse 不知道是什么。下面进入_pci_hwinit()。这个的执行代码较长，但

基本都是赋值而已。执行语句如下：

这个值是0x8000 0000,就是说pci 的mem 地址分配从这个地址开始，前面都是

用户空间。

分配pci_device 和pci_bus 这两个结构体。可见分别描述了设备和总线内容。

实际上用来描述北桥(或者说是一个pci 设备的总抽象)和唯一的pci 总线。

这个值为0xbfd0 0000，所有io 端口都在bfd00000 开始的1MB 空间内。

以上代码都是对pci_device 中的pa 的成员赋值，pa 是一个pci_attach_args 结

构，描述pci 设备的一些附加属性。

表示这个设备所接的桥的下一级总线。pd->bridge之前没赋值,pmalloc 返回的内

容是清0 的

这个_pci_head 全局变量很重要，以后会多次用到。

接下来的代码根据是否按照新的pci 窗口布局执行不同的代码，旧的布局是3 个

64MB 的pci 窗口，新的是128，32，32。pci 窗口的目的就是把cpu 送出的地

址转化成总线地址。pmon默认代码中没有定义NEW_PCI_WINDOW。小技巧：

看条件编译的条件是否定义有个简单的方法，加条件编译的部分下一条要报错的

代码，如果报了，说明这段代码要被编译，条件为真。

以上是对北桥的概括描述，现在要描述PCI 总线了。执行的代码如下：

注释说前64M(0x04000000)的pci 窗口保留给vga。BONITO_PCILO_SIZE 为

192MB， PCI_MEM_SPACE_PCI_BASE 为0 ???

这个PCIMAP 寄存器设置了CPU-->PCI 的地址转换。以下引自《pci 设备初始

化.pdf》：为了让CPU 访问PCI 空间，需要将CPU 空间映射到PCI 空间。在内

存空间256M 上有三个连续的大小均为64M 的区间，分别称为PCI_Lo0,

PCI_Lo1,PCI_Lo2。这三个区间可以被北桥映射到PCI 以64M对齐的任意位置。

映射的关系通过设置Bonito 的PCIMAP 寄存器。该寄存器的格式如下图。

pci_lo0,pci_lo1,pci_lo2 分别是上面所说三个区间的高6 位地址(bit3126)，

而

Pci_map2 是说明映射到2G 以上的空间还是2G 以下的空间。因此上面给

BONITO_PCIMAP 赋值就将PCI_lo0,PCI_lo1,PCI_lo2 分别映射到了PCI 空间

的从0,64M,128M 开始的地址。

以上的说法中对于pci_map2 的描述部分在2F 中是不适用的，2F 的这个寄存器

的高14 位保留。低18 位定义相同。

传统的16 位地址的io 空间，大小是64KB

这两个base 很重要，前面的minpciioaddr 和nextpciioaddr 都要和base 联系。

这个_pci_bushead 全局变量很重要，以后会多次用到。在我们的龙芯pc 中，尚

未采用多pci 架构，所以pcibus 都是一个。

下面的pcibase 是指北桥PCI 配置头中的base

_pci_hwinit 执行完以后返回_pci_businit()，执行如下代码：

这里的_pci_head 就是刚才在_pci_hwinit 中赋值的。pci_roots 是1。也就是这

个for 循环的循环体实际上只执行一次。

_pci_scan_dev(pb, i, 0, init)中i 表示总线号(其实就是0)，0 表示device 号从0

开始查找。

_pci_scan_dev()的内容如下：

这个代码功能比较清楚，就是以枚举的方式探测相应的设备是否存在，传入参数

分别是北桥的设备指针，北桥所在的总线号0，要探测的设备号device(0～31)。

_pci_query_dev()代码如下：。

在pci 设备空间访问的时候，所使用的地址由四部分组成。总线号，设备号，功

能号，寄存器号。_pci_make_tag 的工作就是把这总线号，设备号，功能号三个

数合成一个总线配置空间地址的标识，其中的参数0 表示功能号。对于多功能设

备，不同功能的总线号和设备号是相同的，且0 号功能必定存在，就是说多功能

的设备功能号是从0 开始的。所以探测0 号功能是非常合理的。

bus=0 且device=0 的话_pc_canscan()会返回0,表示是北桥，是特殊的。

读PCI 配置空间中的厂商ID 看看这个设备是否存在。

检查是否是多功能设备

如果是多功能设备，所有功能都加到设备(确切的说是功能列表中去)列表中去。

添加到设备(功能)列表中

挂上设备列表并记下空间请求

}

_pci_query_dev 函数就是这些了。我们看看_pci_query_dev_func 的实现。

_pci_query_dev_func()的主要工作就是初始化这个探测到的pci 设备（功能），

加入到pci 设备（功能）链表，记录各个设备（功能）的资源请求主要是io 空间

和mem 空间的请求（满足请求不在这个函数中），并相应调整pci 总线的特征。

一开始是申请一个pci_device 的结构体并初始化它。值得注意的是，这个新设

备的父亲是dev，也就是北桥。

_pci_device_insert(dev, pd)将pd 插入dev->bridge->child 中。bus 上的所有设

备都在这个child 列表中，也就是说所有pci 设备（功能）都是总线的儿子（不

包括北桥）。接下来是进一步初始化设备和因这个设备调整总线的性质。

到了_pci_setupIntRouting(pd);

看名字是设置中断线有关，不懂，不予解释。

存器，准备使能

backtoback 就是背靠背，就是连续传送，有一个设备不支持，总线的就标志不

支持

一个设备不支持66MHz 就会导致整个总线不能使用66M 的频率。

这个见pci2.3 规范P200，x＝0 表示快速设备，1 表示中等速度设备，2 表示慢

速设备。

上面的和总线的性质有关， pb->bandwidth -= pd->min_gnt * 4000000 / (pd

->min_gnt + pd->max_lat);应该是根据设备的要求分配带宽。

表示设备要求的interrupe pin 连接到中>断控制器的哪个引脚上

接下来要判断这个设备（功能）的类型，分为三类：pci 桥，IDE 控制器，其它。

在2F 的盒子上，除了北桥外没有pci 桥，但北桥不调用_pci_query_dev_fun，

IDE 的控制器集成在南桥中了。也就是说，所有的设备（功能）都会从最后那条

路走。一开始是一个大循环，

读可能存在的6 个base 寄存器，看来要分配io 空间和mem 空间了。

上面的代码看起来有些怪，这是读这几个寄存器的特殊之处，具体的解释见

pci2.3 规范的P208。

如果要申请空间，判断是io 空间还是mem 空间，读出的mack 末位为1 表示要

i/o 空间，否则是mem 空间。

如果是io 空间的申请，则：

io 空间的大小是受限的，mask1 的位数表明申请空间的大小。

现在开始记下空间需求

让这个总线记下这个设备的io 空间需求。

下面是对于mem 空间需求的处理：

可见对于mem 空间的需求和io 空间有很大的不同。mem 空间是可以支持64

位地址的，而io 空间不行，64 位的时候就要占用两个base-address 寄存器。

skipnext 的作用就是标记是不是两个32 位地址合成64 位。

预取。接下来的代码和io 空间的申请相同。下面来看看_insertsort_window 到底

干了什么。

就是看按照申请空间的大小把这个pci_win 结构排序，从大到小排序。

我们已经记录了一个设备（功能）的io 和mem 请求，如果它还需要额外的扩展

rom，就再记录并提交申请。具体可见pci2.3 规范30h 寄存器的解释。

OK，至此，_pci_query_dev_func 函数执行完毕。也就是对一个检测到的设备

（功能）结构体的初始化，插入pci 设备链表并初步处理了这个设备（功能）提

出的需求。

在所有的设备（功能）都执行_pci_query_dev 以后，_pci_businit()要执行的只

有_setup_pcibuses(init)了。这个函数功能是分配带宽并处理空间申请。

一开始分配带宽。代码中有一句def_ltim = pb->bandwidth / pb->ndev，表示平

均主义的话每个设备多少带宽，但是我没有找到这个ndev 初始化后在哪儿被改

变了。然后处理空间的请求。

处理mem/io 空间请求，并反馈回请求的设备。io 和mem 空间的请求已经以

pci_win 结构体链表的形式记录下来了，mem 的请求记录在bridge.memspace

中，io 请求在bridge.iospace 中。先处理的是mem 的请求。主要就是

实现很显然，就是按顺序切割剩余的空间。

这个代码的功能应该是很清楚了。pm->address 在得到分配到的空间的基地址

后，还要写回那个基地址寄存器。下面的代码就是这个目的。

对于mem 空间的申请就是这样了。剩下的扩展空间和io 空间过程相似。

回到tgt_devinit()，只剩下一个cs5536_pci_fixup()了。

这个函数实际上执行两个函数cs5536_pci_otg_fixup() 和cs5536_lpc_fixup();

先看前一个。代码如下：

前头setup_pcibuses 函数已经完成了空间需求，这里的地址是实际分配到的。

使能mem space access,接下来的几条指令就要执行写操作

这个具体的作用要看南桥关于usb controller 部分的描述。

接下是cs5536_lpc_fixup 函数，代码如下：

使能键盘和二级IDE 中断,见amd 手册P384。

enable serial interrupt，见amd 手册P466。

好了，至此，tgt_devinit()就全部执行完毕了。返回dbginit()。

接下来要执行init_net (1)，这个函数极度混乱，绝不是初始化网络这么简单。我

在第一次看pmon 代码的时候，这个函数断断续续看了有半个月。

一开始是和loglevel 相关的，打印相关的，跳过。

接着执行paraminit();从调用前的注释看是初始化系统相关的全局参数。代码不

长，就以下7 行：

这里的TIMEZONE 和DST 在文件头都定义为0,就是0 时区，DST_NONE 了。

DST 的解释如下（摘自网络）：美国加拿大实行DST 的时间是3 月的第二个

星期天早晨两点开始到11 月的第一个星期日的早晨两点。三月第二个个星期日

早晨两点所有时钟向前回拨一个小时，到11 月DST 截止再拨回来。

这三个全局变量作用有限，用到的时候再分析，留个印象先。

从paraminit 返回。执行vminit();

谈到内存分配，前面我们在多个地方见到了动态分配函数pmalloc，下面先讲讲

这个函数是怎么个流程。pmalloc 代码如下：

可见这函数有分配和清零两部分。我们只关心的malloc 函数代码如下蓝色标记。

这里的HEADER 就是header，定义如下：

本质上就是一个指向本联合体的指针，和一块空间的大小。从上一句代码中可以

看出，每申请一块空间，要同时要带一个结构头。

这里是这样的，allocp 是全局变量，如果没有明确的初始化，全局变量就默认为

0，就是这里的NULL。上面对应的是第一次执行的时候的情形,allocp 的含义是

当前可被使用的空间的描述信息。

base 也是一个没有初始化的全局变量。这里算是初始化了一下。

这个if 对应的是当前拥有的空间就能满足申请的情形，

这个对应现有空间不足的情形，调用morecore 函数再申请，分配成功后再在for

循环内判断是否已经满足要求了。函数代码如下：

NALLOC 定义为128，表示每次申请的大小至少为128 个结构体的大小。

从命名上就看出了要动真格的了。sbrk 代码如下(绿色)：

allocbuf 指向一个大数组，为32KB 大小。sbrk 就是从开始位置切割而已。

根据现状更新这块分配到的空间头部的记录块。

看完了代码，这个代码就不觉得怪了。在pmalloc 能使用的32KB 空间内，每次

分配的空间其实包括header，申请的空间，对齐用的空间三部分。且这块空间

至少是NALLOC 个header 个结构体大小的空间。是否浪费？不。因为这块空间

还会被分割的。具体的可模拟不同情形把代码走一遍。

header 所需空间对齐用

pmalloc 就到这里了，回到流程上来，看vminit()函数。就一个if 语句，如下：

这里的memorysize 是个外部变量，就是initmips 中的那个，最大为256MB，

盒子上面内存为512MB，memorysize变量就为256*2^20。VM_KMEM_SIZE 大

小为512KB。

不足页的不可用,且空出一个vm,memorysize 单位是字节

这个判断没有理由不成立，还要执行的就一条了,就不管else 了。

事实上我认为kmem 的值是确定的，memorysize 是256MB－512KB，那么

kmem 就是0x8ff8 0000(uncached 前是0x0ff80000)。vminit()至此执行完毕。

函数设定的kmem 变量值指定了待会kmem_malloc 分配时使用的空间。

接着执行kmeminit()函数。实际就执行以下几句：

npg（number of page）计算一个VM_KMEM_SIZE 的页数，页大小为4KB。

我们又看到一个分配函数，kmem_alloc()，有两个传入参数。第一个参数

kernel_map,这个变量实际上是没用的，不去理睬。第二个是要申请的空间大小，

从这个大小就可猜出，每一个页都有一个控制结构kmemusage，下面看看这个

结构体的定义：

ku_indx 料想就是一个下标，ku_un 从注释中看出是对一块区域的描述。

kmem_alloc(map,size)实际上就是调用kmem_malloc(map,size,0)， 下面看

kmem_malloc 做了点什么。代码如下（蓝色标记）：

每次分配的是4KB 对齐。

这个分配的策略很简单，就是从kmem 开始分配。kmem_offs 表示当前可供分

配空间的起始地址。返回值赋值给kmemusage。

回到kmeminit()，只剩下一句了。

kmem_suballoc()代码如下：

经过这个调用以后，kmembase 就是kmem(一般就是0x8ff80000)，kmemlimit

表示可供分配空间的边界。kmem_alloc 和kmem_suballoc 到底是什么关系呢？

不管了，至此，kmeminit()执行完毕。

回到init_net()，接着执行：

先分配ncallout 个ncallout 结构体，ncallout 在paraminit 中已经赋值。为19。

感觉是一个函数调用的队列。具体的等用到时再说。

这里的malloc 函数有3 个参数，和前面的不同。malloc 执行代码如下（蓝色）：

这个malloc 分配的空间大小必须为2 的多少次幂，返回的indx 就是这个幂。对

应kmembuckets 数组的下标。kmembucket 结构体定义如下：

看得出来，这个和内核中的malloc 的用法几乎是一样的。大致如下图

数组

这个spl 是’set priority level’的缩写，在bsd 中曾经被用来保护一段代码不被中

断，就是产生临界区的功能。一个bsd 的开发者曾经写道：

pmon 此处的用法其实和这个开发者的例子很相似，if 这段后面就有splx(s)。顺

便提一下，pmon 中有很多来自于2000 年前后bsd 内核代码。

接着执行startrtclock()，和时钟相关。代码如下：

这个返回外部时钟频率。其实这个名字有点含糊，但tgt_cpufreq的注释很清楚，

Returns the external clock frequency, usually the bus clock，外部时钟频率。

tgt_pipefreq 的注释为Returns the CPU pipelie clock frequency，cpu 频率。

tgt_gettime()会读取时钟芯片上的时间并转化成秒数传回。

这里的get_count()恒返回0。_softcompare 就是clkpertick。以上执行之后，返

回init_net()，接着执行：

这里的MCLBYTES 是2^11，也就是2KB。

接下来执行mbinit()，代码如下：

就是调用一个m_clalloc()，其中的cl 是cluster 的缩写。代码如下：

从名字看出这个是计算占用多少页。

有必要对目前为止所有的分配函数，分配区

域和相关结构做一个总结。

Init_net 之tgt_devconfig

继续看init_net()，接着执行tgt_devconfig()，这个递归调用的代码量极大(蓝色)，

这一句作用是初始化pci 设备配置空间的一些参数，_pci_device 代码就是一个

for 循环，虽然这个for 的循环体也只执行一遍。代码如下：

这个_pci_head 我们早见过了。可以理解为北桥，也可以理解为对所有pci 设备

的一个抽象。所有已知的设备（功能）在_pci_head->bridge.child 下。

_pci_setup_devices 函数的代码如下（棕色）：

读取命令寄存器所在的四个字节。

如果以前总线探测后支持背靠背，则设置每个设备使能这个功能。

如果这个设备是个pci 桥，则递归调用_pci_setup_devices。这个函数实际上并

不调用。xiangy 待定

_pci_devinit 就到这里了。

tgt_devconfig 之显卡

下面回到tgt_devconfig()执行。现在要执行显卡相关的东西，到现在为止，龙芯

pc 使用过ATI（2E），SIS(2F 福珑)，SM（2F 逸珑）三款不同的显卡。特别是

sis 的显卡处理非常复杂，以后可能会解释这块的代码。不过这里我们以SM712

的显卡为例走流程。（可以偷点懒不是，^_^），代码如下：

rc 反正表示显卡有效，不知道什么的缩写。看注释，下面点灯。

代码中的高端口和低端口组成一个16 位的地址，看代码好像是先读出上次的亮

度值，再搞成最暗。由于rc 为1，接着执行：

在执行_pci_businit()函数的时候会调用_pci_setup_windows，如果是显示设备，

就会给vga_dev 这个全局变量赋值。这里就是显卡控制器（显卡）。fbaddress

和ioaddress 表示了显卡想要申请的空间资源。

处理对齐需求。

变成我们可分配的虚拟地址。下面开始就要和sm712 这个显卡打交道了。

sm712_init 代码如下：

这个函数很短，就两行代码：

阅读sm712 的数据手册，写入0x3c4 寄存器的值表示后续寄存器访问的index

值，比如这里的linux_outb(0x18, 0x3c4)表是下一句对0x3c5 写操作作用于

index 为0x18的0x3c5寄存器（0x3c5寄存器有上百个index，这个用法很特别）。

0x11 表示使用0x0A0000~0xBFFFF 的mem 空间。32 位地址模式，Externded

packed pixel graphics 模式。

hw 这个结构体全局变量是在sm712.h 中定义的，用于描述712 显卡的属性。上

面设置了一些地址。

设置分辨率为1024x600，16 位色，刷新率为60Hz。

这个index 为21 的寄存器基本就是使能。

设置显存与时钟相关的参数并默认使用显存（bit2）。

这两条是合在一块的，用于设置显存频率，计算公式为

MNR就是CR6a的值，MDR就是CR6b的值。这里我们的显存频率就是66MHz

左右。

表示显存大小为4MB。

上面的代码表示黑屏，但是循环次数我不理解，

使用先写后读的方式探测显存是否存在。如果不存在就修改CR62 的配置，改为

使用内存。

前面的hw赋值总算派上用场了。这个smi_set_timing会匹配设置的这种分辨率，

色深，刷新率并使用这个模式下预设的参数配置显卡。细节较多，不叙。

设置2d 相关的寄存器。

执行完sm712_init 后，回到tgt_devconfig，执行：

fb_init 的代码如下：

使用显示模式初始化pGD 全局变量。gdfIndex 为GDF_16BIT_565RGB

设置framebuffer 起始地址。

字符显示的配置。

这里的video_fb_address 就是pGD->frameAdes。

为什么多清空5 行？？？

这个画图的函数相当长，功能就是把从存放在BIGBMP_START_ADDR 这个地

址开始的图片内容显示到左上角坐标为（BIGBMP_X,BIGBMP_Y）的位置。

显示那个大图片下面的两个带有汉字的小图片。

回到tgt_devconfig 中，显卡相关的东西都基本完成了。现在液晶的背光都是关

闭的，现在要根据以前保存的亮度重新打开背光。

好了，和显示相关的基本到这里就完了。咱们接着看tgt_devconfig的其它内容。

tgt_devconfig 之config_init

上面初始化了四个链表，开始都为空链。

这个staticcftable 内容可不少，一下子都插入到allcftables 链表中

}

先看看看这个staticcftable 的内容。

就是对cfdata 的一个包装，cfdata 的内容如下：

cfdata 的结构体定义如下：

大致介绍一下这个结构体:

cf_attach 包含了设备的匹配，attach，detach 等，

cf_driver 表示这一类设备的驱动，

cf_unit 记录这种设备的个数

cf_fstate 表示搜寻的状态。共有四种状态

这些定义的值如下

cf_flags 反正定义的地方全是0

cf_parents 父亲的id，是个short，cf_parents 是id 数组的下标,等会详述。

cf_locnames 注释说是start of names，不过我没明白什么意思。

cf_starunit1 对于cf_flags 为STAR 的设备，这个参数表示第一个可用的次设

备号。

这个cfdata 数组是通过配置文件../Targers/Bonito2F7inch/conf/Bonito.2F7inch

产生的，配置文件中的部分内容如下。

实际上这里已经表明了这个pci 框架的层次结构。这个框架也可体现cf_parents

这个成员中。

cfdata 数组中wd 的cf_parents 为pv+2，就是pv[2]，pv 数组的定义如下：

pv[2]为6，这表示它的父亲在cfdata[6]被描述，cfdata[6]描述的是pciide控制器。

pciide 的cf_parents 为pv[0]，值为4，它的父亲就是cfdata[4]，cfdata[4]描述

的是pci0。

pci 的cf_parents 为pv [4]，值为1，它的父亲就是cfdata[1]，cfdata[1]描述pcibr。

pcibr 的cf_parents 为pv+6，pv[6]为0，可见它的父亲是cfdata[0]，cfdata 描

述mainbus。mainbus 的cf_parents 为pv[1]，值为-1，不在这个cfdata 数组中，

表明这个mainbus 是root，没有parents。

tgt_devconfig()之configure

在init_net 之前，我们也探测过pci 总线，不过那时探测的是设备（功能），并不

知道这个框架的拓扑结构。而已实际上那些探测的设备并不是我们平常理解的设

备，两者的关系比如IDE 控制器和硬盘，usb 控制器和u 盘。前面的探测相当于

只知道有了哪些控制器。

下面来看看这个configure，这个可是整个pci 初始化的核心。

这个函数很简单，实质代码只有如下两句：

也就是调用config_rootfound 这个函数，参数为两个mainbus 的字符串。看看：

struct device *config_rootfound(char *rootname, void *aux)

{

void *match;

if ((match = config_rootsearch((cfmatch_t)NULL, rootname, aux)) != NULL)

62

return (config_attach(ROOT, match, aux, (cfprint_t)NULL));

return (NULL);

}

就是两个函数，先看config_rootsearch((cfmatch_t)NULL, rootname, aux)，再

看config_attach(ROOT, match, aux, (cfprint_t)NULL)。

config_rootsearch 就是传入这个pci 架构的根的名字，找到根这个设备。我们传

入的参数是NULL 和两个“mainbus”字符串，config_rootsearch 函数代码如下：

这些参数等会都会用到。

cfroots 的第二项就是-1，表明这个pci 架构只有一个root。所以这个循环只执行

一次。第一项的值为0，也就是*p 为0。

这个就能匹配了，cf 就是cfdata[0]。

这个会改变m.match，config_rootsearch()就是要返回这个match。

mapply 这个函数后面会多次用到，这里我们就先按照config_rootsearch 中调用

的上下文，走一下执行流程。函数代码如下：

在config_rootsearch 中indirect 为0，所以这里match 就是cf(cfdata[0])。

cfdata 的match 函数就是返回1 而已，其余什么都不干。所以pri＝1。

在config_rootsearch 中m->pri 为0，比pri 小。这里把m->match 赋值为cfdata

[0]的地址，pri 赋值为1。这个match 就是我们最后要返回的值。

} else {

if (m->indirect)

free(match, M_DEVBUF);

}

}

好了，config_rootsearch 找到了叫mainbus 的设备，并且返回描述这个设备结

构体指针。下面看config_attach(ROOT, match, aux, (cfprint_t)NULL)。这里的

ROOT 为NULL，match 为cfdata[0]的指针，aux 为字符串”mainbus”，attach

嘛，就是找个依靠，免得一个人孤零零的。

没有父亲或者就父亲不给你开后门安排位置，那就自己去天下。

config_make_softc()主要作用是初始化这个我们所要attach 的设备，但也顺便

给cf 拉点赞助，更新数据。

如果这个cf 的config 是第一次被调用，它所扶持的设备一般都是从0 这个次设

备号开始，所以这个dev->dv_init 为0。

更新这个类型的设备数目。

找到了一个设备了，加入到alldevs 中，我们这个dev 就叫mainbus0。

把这个找到的设备加入到设备列表中，并更新ref 计数。

根据这个新插入的dev 看是否有必要改变某些cf 的属性。

现在用相关的attach 函数真正的把这个新配置的dev 依附到他的parent 上。这

里实际调用mainbus_attach()。这个函数会导致递归调用，这样一层层下去就建

立了一个总线框架的拓扑结构，为一个树状结构。

调用mainbus_attach 的传入参数是NULL，描述manbus0 的dev，“mainbus”。

mainbus_softc 的结构体包含两部分，前面是一个device 结构体（所以才敢如上

赋值），后面是一个bushook，描述了这个设备挂载的总线的信息，五个成员都

在下面被赋值。

上面表示传入的dev（self）挂在mainbus 上，，没有设置中断相关的映射关系。

我们在前面看cfdata 数组定义的时候知道mainbus 其实有两个下属设备，

localbus 和pcibr，下面就要手动建立联系了。

nca 是个confargs 结构体，在这里起临时变量的作用。在赋值nca 作为传入参

数后，调用config_found()。传入参数还是描述mainbus0 的那个dev。刚说了，

mainbus 有两个儿子，pcibr 和localbus，这个是静态定义的，代码中写死了。

但他们的儿子代码就不可能指定了，要考config_found 去探测。

下面的两块怀疑是没用的，逻辑上说不通(在只有一个pci 桥的情况下)，注释掉

也没有发现有副作用。

现在就看config_found 做了些什么，函数定义如下：

可见config_found 就是对config_found_sm 的包装，函数本质如下：

这个函数看着眼熟吧，和config_rootfound几乎是一模一样。但config_rootfound

是点到为止，不往下走，这个函数却会使用递归往下刨。以使用传入参数aux

代表pcibr 的调用为例。先看config_search，这个传入参数为NULL，代表

mainbus0 的dev，代表pcibr 的nca。

。。。变量定义。。。

上面的indirect 基本上都是0。

这里是我们唯一关心的。对于我们的输入，这里找到的cf 是pcibr (cfdata[1 ])的

描述。当然细心的你也许会发现，即使我们的输入的aux 参数表示的是pcibr，

但是这里的这里的cf 为localbus 也是有可能的。因为它的parents 的确也是

mainbus 呀。关键的东西是m.pri 和cf->fstate 参数，在mapply 中，pri 这个参

数有防止重入的功能，体现在mapply 中的if(pri > m->pri)这句代码中。这种设

计确保所有的儿子都被父亲探测到，不但有顺序，而且不重复。

}

}

return (m.match);

}

mapply 的代码前面已经看过，对于我们的输入，就是把m.match 置为cfdata

数组中描述pci 的结构体指针而已。返回这个m.match 后，config_search 函数

也返回了，返回值非NULL 表示search 到儿子了。

接着执行config_attach(parent, match, aux, print)。

绕了许久，缘何至此，曾记否？

皆因调config_rootfound 之config_attach 之故也。至此，竟成了轮回。

是的，递归了。不过现在还没有看到这个递归的关键环节。都只是例行公事一样

通过attach 插入些设备而已。这里也是是把pcibr 加入到alldevs 中罢了。在

config_attach 中有接着执行下一级的attach，对于pcibr，就是pcibrattach。

void pcibrattach(struct device * parent,struct device * self, void * aux)

{

struct pcibr_softc *sc = (struct pcibr_softc *)self;

struct pcibus_attach_args pba;

sc->sc_iobus_space = *_pci_bus[sc->sc_dev.dv_unit]->pa.pa_iot;

sc->sc_membus_space = *_pci_bus[sc->sc_dev.dv_unit]->pa.pa_memt;

sc->sc_dmatag = *_pci_bus[sc->sc_dev.dv_unit]->pa.pa_dmat;

pba.pba_busname = "pci";

pba.pba_iot = &sc->sc_iobus_space;

pba.pba_memt = &sc->sc_membus_space;

pba.pba_dmat = &sc->sc_dmatag;

pba.pba_pc = NULL;

pba.pba_bus = sc->sc_dev.dv_unit;

config_found(self, &pba, pcibrprint);

}

就不去看太细节的东西了，很明显有一点，bcibr 明确指定自己的儿子是pci，并

把自己的财产都给了他。接着执行config_found(self, &pba, pcibrprint)，由于

pcibr 只有一个儿子，返回的自然是pci 了。接着执行config_attach，把pci 插

入了。

接着递归在mapply 中调用pci 的attach 函数pciattach。这个pciattach 和前面

的那些attach 都不太一样，代码比较长。其中的aux 就是上面的＆pba。

pci 总线最多能挂32 个设备，实际上由于硬件特性的原因，一般到不了20 个。

bus 为0，callback 为NULL。下面依顺序探测pci 设备是否存在（这个工作我们

不是第一次做了）

看这个设备是否为多功能的。

。。。pa 结构的赋值。。。

好了，没个功能调用一次config_found_sm，self 为pci 的cfdata 描述，pa 为这

个功能的描述，pcisubmatch 是一个函数，等用到的时候再解释。

我们实际上知道pci 只有3 个儿子，pciide，ohci，rtl。作为功能他们会分别调用

config_found_sm，但和前面都不同的是，这里的pcisubmatch 非NULL。

我们并不关心print 相关的东西，下面我们以pciide 的功能识别为例，再来看这

个config_found_sm 函数。由于传入的submatch 为pcisubmatch，在mapply

中执行路径就和原来不太一样了。

我们这里要执行的就是pcisubmatch 了。还有这里的传入参数m->aux 就是用来

描述我们要注册的那3 个功能的， aux 在之前几乎是去没有去用的。这个

pcisubmatch 的返回值也是有讲究的，如果传入的match 和aux 描述的不是一

个东西，就返回0，这样pri 就是0，这样就保证了mapply 返回的match 就是

我们要它去匹配的那3 个设备。如果就是那个match 和aux 描述的是一个东西。

就调用这个设备的match 函数。对于pciide，就是调用pciide_match

除非和cfdata 中的那三个pci 的儿子匹配，否则pri 均为0，mapply 返回后

m.match 为NULL。pcisubmatch 的主要功能就是调用那3 个设备的match，下

面就说说pciide_match。

这个match 才叫做match，函数先判断这个设备是否是ide 控制器，如果是，调

用pp = pciide_lookup_product(pa->pa_id);这里的pa ->pa_id 还是我们在

pciattach 中那个循环中探测并保存。pa_id 表示厂商id。pciide_lookup_product

会匹配那个ide 控制器的列表，显然我们用的是CS5536 的南桥的ide 控制器，

厂商id 就是AMD，AMD 的IDE 控制器支持列表如下：

pciide_lookup_product 除了匹配厂商号， 还有设备号， 这里很清楚的就是

CS5535嘛。匹配好以后就返回描述CS5536的那个结构体描述符。pciide_match

探测好后，返回1。

这个对于pci 的儿子pciide 的config_search 会返回pciide 的cfdata 的描述，之

后执行config_attach，这个函数在插入pciide 到alldevs 的设备链表之后会调用

pciide 的attach 函数，下面看看，很重要哦！！！

这个函数我们在pciide 的match 函数中已经见识过了，就是查找pmon 支持的

ide 控制器列表，这里会返回描述CS5536 的ide 控制器的结构体描述符。内容

为：

这个东西等会就要用上了。

这个调用很重要哦。等会就看。

下面看名字貌似是DMA 相关的，就是一个使能。

这个pciide_attach 的最重要的功能当然是探测有没有（有的话，几个）硬盘挂

在硬盘控制器上，并把找到的硬盘以wd0，wd1 的名字插入alldevs 的链表中。

代码还是比较繁琐的，我也不大愿意再去看了。阿弥佗佛。指条明路吧。

amdcs5536_chip_map->pciide_mapchan->wdcattach->wdcprobe，每个ide 控

制器最多两个channal，amdcs5536_chip_map 会通过调用pciide_mapchan

->wdcattach 探测这两个channal 有没有挂载硬盘，真正探测是用过wdcattach

中的wdcprobe 函数，这个探测的方法是我们常用的，发命令看有没有回应。如

果等了很久还没有收到回应就认为硬盘没有安装。如果硬盘存在，在wdcattach

中会调用陌生的老朋友config_found 来插入到alldevs 中，这样alldevs 中就有

了wd0 了。

前面简单介绍了一下wd0 的识别，这里我们看一下usb。

首先声明，我之前对USB 的了解是一穷二白，这里特意弄这么一节，纯属自虐。

从pci 的attach 开始吧。pciattach 函数会扫描pci 总线上的所有设备/功能，然

后依次调用config_found_sm。对这个函数，顺着代码看的哥们都快背下了吧。

注意这个config_found_sm 的调用中match 函数为pcisubmatch，不是NULL，

这个对函数执行的流程会造成影响。具体的就是在调用mapply 的时候，m->fn

非NULL，这样就会执行pci 那些儿子的match，当然也包括ohci。前面提过的

pci的儿子有三个，ohci，rtl和pciide。如果真的是ohci的话，调用ohci的match

会返回1，赋值给pri，这样m->match就赋值上了，否则m->match就返回NULL。

在8089
笔记本上，有两个ohci 控制器，一个是NEC 的，一个是5536 内部集

成的。所以能从ohci 的match 函数返回1 的就只有两个设备/功能。下面看看

ohci 的match 函数：

可见判断的标准很明确的，base class 和sub class 为0xc 和0x3 表明这个设备

是串行总线，interface 为0x10 表明是ohci，这些都是在pci 规范的class code

中定义的，具体可查看pci2.3 规范的附录。

在match 上后，最终会在config_attach 中调用ohci 的attach 函数。

ohci_attach 一开始会做些常规的判断并根据硬件连线的情况做些屏蔽处理，比

如在pmon 下wifi 这个设备（接在usb 端口）就被屏蔽。接下的代码如下：

读取pci分配之后这个ohci控制器分配到的mem 地址和大小。具体的分配是在_

pci_businit 函数中完成的，这个我们前面已经讲解过了。

从命名上看，和映射有关。bus_space_map 的定义如下：

通过打印，这里的memt->bus_base 为0xb0000000，如果你理解龙芯的地址映

射过程的话，这种b 开头的虚拟地址大部分都是映射到pci 空间的。这里的size

都是4KB。

这个函数就不进去看了。其主要内容是ohci的结构体成员(hcca，gtd，ohci_dev，

control_buf，setup)的空间分配和部分成员(disabled，sleeping，irq，regs，

slot_name)的初始化，随后重启ohci 控制器，最后开启ohci 控制器。

三个ohci 操作函数指针的初始化。这些函数是会在后面大量调用。

把这个找到的ohci 控制器加入到usb 控制器链表中。

注册中断查询函数。

在usb_dev数组记录新的ohci设备，并把这个数组项的地址赋值给ohci的成员。

usb_alloc_new_device 函数非常简单，唯一要注意的是这个新的设备最终可能

是有小孩的。

从注释就看出来了，这个函数是枚举看是否有连接设备。

对于ohci 来说，这个函数是我们最后要看得一个函数了。不幸的是，这个函数

非常复杂。

开始的代码是对dev 的一些成员的初始化，这个现在也讲不清楚。跳过。

接下来执行一个非常重要的函数，

进入这个函数看看，定义如下：

代码非常的清楚，先看usb_rcvctrlpipe(dev, 0)这个参数。

从usb_control_msg 这个函数的定义中会看到，这个参数叫pipe。好，看这个

pipe是如何出来的。参看sys/dev/usb/usb.h中的L314行开始的注释就知道了。

这里的这个pipe 和我们说的EP 是一对一的关系，这里值是0x80000080，可见

解释为控制管道，全速，EP0，设备0，方向输入，maxsize 为8。注意ep0 是

个特殊的ep，必定是用于控制的。

再看usb_control_msg 的实现。

首先我们出入的timeout 为USB_CNTL_TIMEOUT 定义为100，表示100ms 内

这个get 操作要完成。

接着设置setup_packet 这个结构体。

命名都比较清楚了。requesttype 为get descriptor， request 为in。value 为

USB_DT_DEVICE<<8，index 为0，size 为0，表示8 个字节。

这个setup 的包我在ohci 的规范中没有找到，但是网上有些解释。就不说了。

下面会通过submit_control_msg(dev,pipe,data,size,&setup_packet)去发送这

个setup 包，要求设备返回设备描述符。

submit_control_msg 会原封不动的调用ohci_submit_control_msg。

这个函数很短，首先设置maxsize，由于pipe 为0，我们在usb_new_device

中定义了EP0 的进出包大小都是8 字节。这里的maxsize 就是8。

之后根据当前要操作的pipe 那头是不是root hub 调用ohci_submit_rh_msg 或

者submit_common_msg。由于当前连的是root hub，调用ohci_submit_rh_msg。

参数和ohci_submit_control_msg 都是一样的。下面看看这个setup 的msg 是

如何发到root hub 上的。注意这时setup_packet 的形参叫做cmd 了。

在接下来的大switch 中，case 匹配上RH_GET_DESCRIPTOR，在这个case

中的switch中，case 匹配0x01，代码会给date_buf 赋一个默认的虚拟root hub

的内容，并把len 置为这个结构的长度。

在这个大switch 之后，如果data_buf 和目标地址不一致，则这个结构体数据的

拷贝(注意长度)。这里stat 默认为0，表示正常，如果不正常的话，至于这个虚

拟结构的内容在代码中如何解释， 用到再说。这个函数返回之后， 回到

usb_control_msg 函数。

回去一看，根本就不判断返回值，可见对这个结果相当的自信，不会有事的。因

为和硬件没有接触。

usb_control_msg 这个函数最后看dev-<status，这个是在ohci_submit_rh_msg

中修改了值的。正常为0，返回读取的长度。

这里的dev->descriptor 就是我们传入那个缓冲区。用root_hub_dev_des 填充

的，这里注意，当前的dev->descriptor 就是root_hub_dev_des 的地址值。

接着赋值dev->devnum，这个值其实就是root_hub_dev_des 中赋值的那个值。

这里首先是1，接着递增，在8089
笔记本上就是1 和2。

接着执行usb_set_address(dev)。

这个函数直接调用usb_control_msg，这个函数我们见过了，参数不同。看参数。

usb_snddefctrl(dev)这个对应的pipe0，这个值为0x80000000，和前面的那个

差别就是IN 成了OUT。type 从名字上看就是设置什么地址而已。传入的data

就是dev->devnum，是1。表示要把这个ohci 连接的root hub 叫做设备1。接

着看。又回到ohci_submit_rh_msg，

这次要做的动作特别简单， 就是把dev->rh.devnum 赋值为传入的dev

->devnum，就是1。仅此。

所以返回应该也没有什么问题。

回到usb_new_device()，接着调用usb_get_descriptor(dev,

这个函数我们前面已经调用过了。不过这次的size 参数和上次有不同。到

usb_control_msg 的层面，pipe 的值和前次调用也不同，成了0x80000180，

devnum 不同了，EP 是相同的。

这次((pipe >> 8) & 0x7f) == gohci->rh.devnum，所以ohci_submit_control_msg

还是去调用ohci_submit_rh_msg。事实上，只有你在usb 口上插了什么东西，

才会调用submit_common_msg。因为那时才有除root hub 以外的usb device。

75

这次对于root bug 的操作又是get descriptor，实际上这次和上面一次的

get_descriptor 有任何差别吗？别说大小，其实那个不导致差别。

返回后再次回到usb_new_device()。

注意，由于到现在为止的get descriptor 都是直接使用默认的值，所以这里的厂

商号，产品号都是0。

接下来是这句，tmpbuf 是一个512 字节的缓冲区。

这个函数的定义如下：

这里的cfgno 就是0。和前面的usb_get_descriptor 最大的不同是，这里的type

域是USB_DT_CONFIG， 这导致在调用到ohci_submit_rh_msg 中case

RH_GET_DESCRIPTOR 中的case 为0x02，按照注释，这次的操作就是获得

configuratio descriptor， 操作的实现很简单， 就是把一个预定义的

root_hub_config_des 的结构体。

跳过一些错误处理，再执行下面一条，和前面的获得device descriptor 一样，这

种操作都是每次两遍。

实际上，很容易分析，这种两次的操作是没有意义的。但是如果这个get 操作是

去外部获得的，就不同了。看看ohci 的协议，就知道了。第一次会发送命令（8

字节），之后从设备响应，这时主设备再去真正获得那个描述符。

这里相当于模拟协议吧，maybe。

获得config 之后就是剖析它，执行usb_parse_config(dev,&tmpbuf[0],0)

这个函数非常重要，我们一句句解析。记住我们输入的参数。代码如下：

这个的值是0。

buffer 对应的就是root_hub_config_des，在文件usb-ohci,c 中。

错误处理，这里我们不看

填充dev->config.buffer 字段。

个别参数的微调。

这个len 是9。

现在要说的是这个root_hub_config_des 是由3 个部分组成的，有每个部分的第

一字段标记这部分的大小。前面处理的是第一个部分长度为9。第二部分是对

interface 的描述，长度为9，第三部分是对EP 的描述，长度为7。总长度在第

一部分的wTotalLength 中记录。如注释所说的，我们要处理其他的部分了。

上面可以看出，如果找到一个interface，要动作的几个参数就是config 的

no_of_if,if_desc 数组，其中if_desc 的no_of_ep 初始为0。

EP 和interface 的关系从这里可以一览无余。一个interface 包含了n 个EP。所

以上面的复制都是对于config.if_desc[ifno]的结构体的赋值。

好，这个函数就解释完了。

再回到usb_new_device。

接下的usb_set_maxpacket(dev)不过就是设置收发包的大小。注意这个双重循

环实际执行一次，因为当前只有一个interface 且那个interface 只有一个EP。

接下来还是重复昨天的故事，get 以后是set，这次set configuratio。

中间的过程都熟悉了，看点关键的（ohci_submit_rh_msg 中）。

这个宏的定义如下：

writel 的定义就是赋值而已。

这些代码都简单，问题是为什么要写这个status。一个更让我困惑的问题是，这

里的写为什么要或上0xa0000000？难道这个地址是硬件映射到物理地址空间

的？看上去应该是的。打印出这个地址我们会觉得比较眼熟。在USB 这一节的

开始，有个bus_space_map 的函数，这个函数是处理usb 的寄存器到mem 空

间的映射，而现在发现这个地址就在那段空间内，所以至少可以确定gohci

->regs->roothub.status 的地址就是usb 的寄存器映射过来的。打出gohci

->regs的地址，就是或上0xb0000000 的usb 的membase地址。至于这个status

为0x10000 是什么？也许是active 吧。

这个set configration 顺利返回之后，赋值dev->toggle 的前两个元素为0。

回到usb_new_device，清dev 的mf，prod，serial 三个成员。

接着执行usb_hub_probe(dev,0)，检测这个ohci 上的接口0 是不是root bug，

如果是，配置之。

检查比较简单，开始就是些参数的对比。从对比中可以产生这样的理解：

root hub 是一个interface，

这个interface 只有一个EP。

在这个probe 函数末尾有一个usb_hub_configure(dev)的调用。

这个用于hub 这个结构的注册。

这个代码首先占用hub_dev 数组的一项。之后调用

这个函数会调用老朋友ohci_summit_control_msg，这次会遇到的case 不同，

是case RH_GET_DESCRIPTOR | RH_CLASS，注意到buffer 返回后是作为

usb_hub_descriptor 的结构体指针使用的，在data_buf 数组赋值的时候就最好

对着usb_hub_descriptor 的定义看，就比较清楚了。

接着又非常传统的再来一遍，接着把读到的（代码写死的那些）赋给hub_dev

的desc 成员。

接着调整desc 中的部分成员，DeviceRemovable 和PortPowerCtrlMask 的初始

化。具体的功能不清楚。

status 那段跳过。接下来的函数usb_hub_power_on(hub)和供电有关，再接下

是每个port 的简单配置。这些都挺重要的，有时间可以看看。

这个usb_new_device总算快到头了，末尾有个老朋友，config_found。很简单，

要看看这个ohci 上有没有连接什么usb 设备。

配置的时候就确定了，ohci 的儿子就是usb。

config_found 我们都知道了，主要就是执行一个match 和attach，核心是设备

的这两个函数。对于usb 就是usb_match 和usb_attach。

usb_attach 主要代码如下：

从代码上看，这个过程是首先探测usb 存储设备是否存在，如果存在就填充

usb_stor 的一项， 之后初始化usb_dev_desc 的那一项， 最后调用

usb_stor_get_info 完成探测。

先看第一个函数usb_storage_probe，我们现在以没有外接任何usb 存储设备的

例子来看。很快的， 在开头的if 条件上就返回0 了， 因为的descriptor 的

bDeviceClass 值为9，不是0，所以返回0。整个过程也就结束了。

现在我们以在NEC 接出来的usb 口插了一个U 盘为例走流程。

首先要搞清楚插了U 盘，ohci 是如何知道的。前面我们跳过了，现在回头。

在usb_new_device 的末尾有一句usb_hub_probe，这个函数会判断当前设备

是不是usb 的hub，如果是，调用usb_hub_configure，在初始化完一个hub 结

构之后。hub 嘛，就是一个疙瘩上好几个洞。在给每个port 上电以后。探测每

个port 的状态。

如果某个usb 口接了usb 设备(除了被mask 掉的)，那么接着就执行

这个会从老路调用ohci_submit_control_msg()，不同的是匹配下面的case

其中的RD_RH_POSTSTAT 会读取root hub 中那个port 的状态，并返回。如

果有插个什么东西，这个返回值的portchange 为1，表示connection，有挂usb

设备。其实从这个status 的获取中我们可以确定，这个寄存器就是映射到dev

->reg 中的。从代码我们可以看到，这个portchange 的值表征的信息是非常丰富

的，具体见代码的不同条件分支。

由于发现了有usb 挂载，执行usb_hub_port_connect_change(dev, i)，初始化

挂载在root hub 上的那个设备，代码如下：

一开始重读status，代码中指出了如何区分低速和高速设备。代码略。

清状态寄存器，以免下次重复探测到。

某些端口的比较特殊，不允许连接。代码略。

没细看实现，相当于使能？？？

这里的初始化比较明显了，注册一个新的usb 设备，并和dev 连接上。dev 总算

有儿子了。并且usb 的hc_private 和其父是共享的。

看到了吧，又递归了。我们就调用usb_new_device来处理这个动态插入的家伙。

这个usb_new_device 和前面的那次调用有很大的不同，首先这个设备是接在

root hub 上的，是一个我们所无法预知的设备（U 盘？usb 鼠标？usb 键盘），在

代码上，这个设备的一切都要通过真正的探测，而不是像前头有时是走过场，用

预定义的数据敷衍了事。所以要重新走一遍usb_new_device 的流程。

首先看usb_get_descriptor 这个调用，前面ochi 调用这个函数的时候，就是给

ohci->descriptor 赋值为一个预设的结构体指针。看看这次有什么不同。

最大的不同是对ohci_submit_rh_msg的调用都变成了submit_common_msg.。

一看内容，这两个函数完全不同。代码虽长，一行行看吧。如下：

control 中的PLE 是periodic list enable 的缩写。在ohci 中，数据传输的类型可

分为四类：interrupt，isochronous，control，bulk。interrupt 和isochronous 是

周期性的。ohci 对于list 的管理还是比较详细的，这里的periodic list 就是指

interrupt 和isochronous 的任务list 吧。代码中是disable 的。

这个函数和ohci 的核心机制相关，极为重要。大致意思就是把这个job 化为一

个或者几个TD，链到ED 中，等待被执行。

bulk 的timeout 值明显要小一些。

这个函数基本功能是查询done list。

如果done list 非空，就看这些干完的TD 是什么，并把它从那个ED 的TD 链中

unlink 掉。并在dl_td_done_list 中修改那个td对应的dev 的status。上面的while

就是等这个dev 的status 改变。当然在这个dev 改变的同时（或者没改变时）

其它的dev 的status 也可能改变，只要在td done list 有它的事完了。

剩下的所有代码略过。

最后插入的usb 设备执行config_attach，基本是调用这个ohci_common_msg。

我们调用pci 设备树上的儿子usb 的match 和attach 函数去了。

有兴趣的可以接着看usb_storage.c 中的代码。我走了。

回到init_net

流水落花春去也，换了人间。

下面的代码不会那么让人头大了。当然我的头本来就挺大的。接着的代码如下：

pdevinit 定义如下：

pdevinit 的结构体定义如下：

可见上面按个for 循环其实就是调用loopattach(1)而已。loop 是最简单的网络收

发模型，在pmon 下没有什么意义，不看了。

接下来执行ifinit()。看得出来，是网络系统的初始化，if 就是interface的缩写吧。

这个ifnet 是个全局变量，功能是描述所有网卡的ifnet 结构体的链表头。实际上

大部分情况下我们都只有一个网卡。在pmon 下没有无线网卡的驱动，虽然会被

探测到，但并不会被加入到设备链表中。

实际上对于8089 的小本，在pmon 下唯一的网络设备就是8169。

init_net()总算执行完毕，回到dbginit()。

执行histinit()，初始化命令的历史记录，这个历史记录的功能还是很有用的。

这个函数就一句话： histno＝1；表示现在历史列表中有一个命令(实际上是0)。

接着执行syminit()，实际上就是一行代码：

执行的函数代码如下：

defsym()函数把这些变量注册在一个hash 数组中。至于这里的CLIENTPC，不

知道是干什么的。

接下来执行initial_sr |= tgt_enable (tgt_getmachtype ());

tgt_getmachtype ()就是调用md_cputype，定义在arch/mips/mips.S，如下：

就是返回prid 而已。

tgt_enable 也只有一句话：return(SR_COP_1_BIT|SR_FR_32|SR_EXL);

就是设置协处理器1 有效，可以使用32 个急存器，重新设置例外处理为启动模

式。现在又看不出调用tgt_getmachtype ()有什么用了。

接下来执行：

tgt_machprint()会调用md_cpuname()，判断打印出cpu 的类型，其实前面就算

出来了，没有使用。无语中。。。。。

tgt_machprint()打印些cache 的情况。

接下来执行md_clreg(NULL)，函数就一句： tf = cpuinfotab[whatcpu]，这个

cpuinfotag 数组在调用dbginit 前初始化cpuinfotab[0] = &DBGREG;其实

DBGREG 只是空的一段而已。

接着执行md_setpc(NULL, (int32_t) CLIENTPC)，就是把cpuinfotab[0]->pc 赋

值为CLINETPC。md_setsp(NULL, tgt_clienttos ())看名字是设置sp 寄存器，

sp 的值是256MB－64 字节的地方。别忘了栈是向下生长的。

接着调用DevicesInit();

函数功能很清楚，就是挨个查询已经注册的设备,所有已知设备都在alldevs 这个

链表中。如果是disk 设备，就分配一个DeviceDisk 结构体，填充名字后插入以

gDivice 为首的链表中。一般都是一个硬盘，名字就是wd0。DevicesInit()的重

头戏是_DevPartOpen(dev_disk, dev_disk->device_name)，代码如下：

对于只有一个硬盘的情形，现在path 的内容是/dev/disk/wd0。

open()函数定义在../lib/libc/open.c。暂时可以这么理解这个函数：open 就是看

看那文件是否存在，如果存在，就分配一个文件id，这个id 是一个结构题数组

的下标，那个结构体用来保存相关的信息。

现在开始读取disk 上的分区，dev->part 传入的目的是存放读取出的分区表

这个函数主要调用dev_part_read(),读取硬盘上的分区表。下面看看代码。

这个函数将会读取fd 代表的disk 上分区表写到table 这个地址去。

检测一下有没有扩展分区。

如果存在扩展分区，那么就把他加到分区表中

number 表示分区的个数（主分区+扩展分区）

读取主分区的函数read_primary_part_table()函数的主题如下：

现在硬盘上的第一个扇区被放到首地址为leadbuf的缓冲区中，关于这个首扇区，

有必要先解释一下：

MBR 中的分区信息在偏移地址01BEH--01FDH 的64 个字节，为4 个分区项内

容（分区信息表）。FDISK 对一个磁盘划分的主分区可少于4 个，但最多不超过

4 个。每个分区表的项目是16 个字节。

分区表的内容格式如下：

第0 字节是否为活动分区，是则为80H，否则为00H

第1 字节该分区起始磁头号

第2 字节该分区起始扇区号（低6 位）和起始柱面号（高2 位）

第3 字节该分区起始柱面号的低8 位

第4 字节文件系统的类型标志。0x83 表示ext2/ext3，0x5 表示扩展分区。

第5 字节该分区结束磁头号

第6 字节该分区结束扇区号（低6 位）和结束柱面号（高2 位）

第7 字节该分区结束柱面号的低8 位

第8~11 字节相对扇区号，该分区起始的相对逻辑扇区号，高位在后低位在前

第12~15 字节该分区所用扇区数，高位在后，低位在前。

以我自己的机子为例，120G 的硬盘。分区情况如下：

前面3 个是主分区，第四个是扩展分区，包含了两个逻辑分区。

在os 下读取mbf 的命令为dd if=/dev/sda of=part_table bs=1 count=512，在龙

芯上把sda 改为hda 就行了。

pmon 只使用这个首扇区中的第446～510 字节之间64 字节的内容，使用

hexdump 看到内容如下：

排版后我们关心的4 个主分区内容如下：

好，现在开始解析这个分区表吧。

首先看第4 个字节，前面3 个主分区都是83H，表明都是ext3 文件系统，第四

个主分区是0x5，表明是扩展分区，至于扩展分区如何处理，等会看了代码就知

道了。第8～11 个字节的内容是分区的起始扇区，比如第一个分区的起始扇区

为0x37，第二个分区的起始扇区为0x3c884af,所以第一个分区的大小就是

0x3c88470(0x3c884af-0x370)个扇区。我们看到fdisk -l的时候的sda1 描述为：

大小为31736376(0x1e44238)个块，在创建文件系统的时候，mkfs.ext3 允许指

定块大小，默认为1KB，也就是两个扇区的大小，所以这个分区就有63472752

(0x3c88470)个扇区，和分区信息中第12~15 个字节的表示是一致的。

差不多了，看代码吧。

下面开始填充分区的各种信息

对于扩展分区，sec_begin 这个成员是非常关键的。

把这个探测到的分区插入分区表中。

以上是主分区的探测，这个函数返回dev_part_raad()后，开始探测扩展分区并

注册逻辑分区，代码如下：

是否为扩展分区的判断如下，

可见不是只有0x5 才表明是扩展分区哦。

遇到了扩展分区，开始读取逻辑分区

dev_logical_read()函数的定义如下：

看到了吧，扩展分区的逻辑分区信息在base 扇区中存放着呢。

和注册主分区最多只有四个不同不同，扩展分区的逻辑分区还可以是扩展分区，

所以只能用while 了

这个read_logical_part_table 和读取主分区表的方法几乎一样，就不进去看了。

在pmon 中分区表中删除这个扩展分区，扩展分区和普通分区不用，实际上就是

个皮包公司，不行，你有本事mount 扩展分区试试。

插入这些探测到的新分区。

这些函数都返回后，pmon会把包含了所有分区表信息的描述disk 的DeviceDisk

结构体指针加入到gDivece 链表中。

好了，分区表就这么点事，算是讲完了。

open 函数

上面我们已经遇到了open 函数，不过当时没有进入代码，现在我们就以默认启

动时要执行的open(“(wd0,0)/boot/boot.cfg”,O_RDONLY | O_NONBLOCK)为例

分析这个函数。

open()函数定义在../lib/libc/open.c

首先是一些基本参数的处理

至此，lu 表示当前可用的文件描述符id。

ok，lu 有效。这个lu 可是非常重要。

接下来根据file 的开始符号作不同的处理。比如al 我们一般设置为/

形。我们的例子是(wd0,0)开始的，我们跳到那个地方去。

可见如果是’(’开头的。这时候调用的实际就是__try_open(‘”(wd0,0)

/boot/boot.cfg”,只读非阻塞，“fs”，文件描述符，0)。

可见open 函数本身是比较简单的，我们顺着调用路径到看看_try_open()。这个

函数调用合适的open 函数函数并修改File 结构体。代码如下：

首先要看欲打开文件的文件类型，我们的传入参数为“fs”，不是具体的文件系统，

表示打开硬盘。传入的fstype 为0，表示FS_NULL。FileSystems 在init()中的

文件系统注册时初始化为一个链表。

在../pmon/fs/diskfs.c的注册中我们能看到diskfs 的devname就是fs，就是它了。

这个open 是比较真正的open 了，当然最终的open 是硬盘驱动的open，稍后

就解析。

如果已经打开有效的文件，那么就占用这个文件资源吧

open()本身就是这些。我们顺着执行流到diskfs 的open 函数去吧。调用参数为

diskfs_open(disk_fs(文件描述符，”(wd0,0)/boot/boot.cfg”)，只读非阻塞，0)。

open 函数到现在为止，基本的调用是

函数调用基本返回后都没有什么动作了，只是些错误检测而已。

diskfs_open()函数代码在../pmon/fs/diskfs.c 中，如下：

这个GetDiskFile()用来解析这个fname，分离出3 个重要内容，稍后讲述

这个就是根据具体的文件系统的open 函数，去打开文件，我们这是ext2，

dfp->dfs 就是ext2 文件系统的描述指针，执行的打开函数就是ext2_open

diskfs_open主要调用两个函数，一个是GetDiskFile，另一个是文件系统的open

函数，先来看GetDiskFile。

我们进入的就是这个路径。

strchr 这个函数的功能是在devname 字符串中查找’/’，返回第一个’/’的位置。

现在filename 就是”boot/boot.cfg“了

查找逗号，当前dname 是“wd0,0)”，有逗号的。

在字符串中把逗号变成’\0’，现在devname 实际就是字符串”wd0”。

FindDevice 就是从gDevice 的链表中查找有没有这个名字的disk 设备，这个链

表是在DevicesInit 中建立的，一般就只有“wd0”这个设备。代码就不看了。

这个错误我们不少见吧，比如你不插硬盘就会见到这条语句。

现在fsname 就是字符串”0”

FindParttionFromID()第一个传入参数是那个设备的分区表，后一个参数是

第x 个分区，返回值是那个分区的描述符的指针。代码就不涉及了。

好了，到现在为止，原先的(wd0,0)/boot/boot.cfg 已经被完全拆分了。pdev

现在是存储介质的指针，是个DeviceDisk 结构体指针，part 是文件所在分

区的指针，是个DiskPartitionTable 结构体指针。这些拆分都被保留在dfp

的结构体中，如下：

dfp 是DiskFile 的结构体指针，描述了一个设备上文件的基本信息。这个结

构体最终是File 结构体的一个data 参数。

GetDiskFile 函数返回后回到disk_open(),执行如下代码：

好了，现在这个_file[fd]的描述基本都全了，File 结构体的定义如下：

其中的valid 和fs 是在__try_open()函数中就初始了，现在这个File 结构虽然填

满了，但是够不够呢？如果要读这个文件的内容，到哪儿去读呢？现在通过data

结构体只能知道那个文件所在硬盘、分区、分区文件系统而已。接下来是文件系

统层面的解析。最终我们是要知道那个文件到底在那个分区的哪个地方。由于在

龙芯上默认的文件系统都是ext3 的，ext2 和ext3 的结构是一样的，下面的文件

系统的打开函数就会调用ext2_read()。

现在看diskfs_open 最后一个调用的函数ext2_open()。文件系统相关的代码在..

/pmon/fs 下，ext2 的操作函数在../pmon/fs/ext2fs.c。ext2_open()代码如下：

以前面的打开boot.cfg 文件为例，这个path 是字符串”boot/boot.cfg”，(wd0,0)

是在GetDiskFile 中剥离的。

这个devio_open 会调用硬件的驱动wdopen,我们暂时不深入代码，暂时可以理

解为看看那个设备是否存在。稍后再解读。反正没判断返回值，不影响执行流。

ext2_load_linux()是非常功利的，首先就问是不是可以启动。动机相当不纯呀。

马上看看。

ext2_open()还有两个函数调用没解释，我们先看ext2_load_linux，再看和硬盘

驱动相关的devio_open()。这里我不准备进到文件系统的代码中去，因为ext2

文件系统在很多书中都有专门描述，比如《深入理解Linux 内核》。

ext2_load_linux()函数代码还是在ext2fs.c 中定义。

首先读取超级块。超级块保存了对一个文件系统的许多重要描述。这个读超

级块的调用会初始化许多重要的全局变量。

find_inode()函数会返回描述我们要找的那个文件的inode 编号。并填充

File_dirent 这个结构。

如果我们要引导的内容是目录，报错。也就是说我们open 的只能是一个具

体的文件，而能是一个目录。

根据inode 号，把我们要读的文件的inode 内容读到File_inode 中。

这里解释一点你可能的疑惑：Fiel_inode 和File_dirent 都是个全局变量，也就是

说打开哪个文件，这些个结构体就表示那个文件的相关内容，所以在pmon 下不

要在一个文件使用的过程中同时使用

如果一切正常，那么返回0，表示open 成功。

下面来讲述devio_open()，这个函数的后两个参数flags 和mode 在pmon 下都

没有使用。事实上，pmon 下通过文件系统访问的文件都是只读的。

下面看看devio_open 到底干了些什么。

对于我们一直使用的那个例子，open(wd0,0)/boot/boot.cfg，这里的name 为

“wd0”。这个返回值dev 是wd0的设备号，高8位是主设备号，低8位是次设备。

这个主设备号的来源非常有意思。这个name 返回后，正常情况下为空。

find_device()进一步没有调用函数，代码也很清楚，有兴趣的可以去看看。

opendevs 是对设备的一些描述，五个成员在下面都被初始化。

看到这里，不得不说pmon 作为一个bios，是个比较委屈的用场，它本来是一个

内核，所以有进程的概念，其实作为一个bios，是不必要把事情搞这么复杂的。

对于wd0，这里的open 就是调用wdopen()。等会再看。

可见devio_open()的函数主要就做两件事，一个是opendevs[fd]的初始化，另一

个就是调用主设备对应的open 函数，对于硬盘，就是wdopen()。

好，现在就来看wdopen(dev, 0, S_IFCHR,NULL)，代码在../sys/dev/ata/wd.c

得到次设备号

通过次设备号找到我们要打开的设备，由于是wdlookup，就不用主设备号了。

。。。。。错误处理。。。。。

注释说了，这个if 成立表示如果这个设备已经被打开了

如果这个设备是第一次被打开

这个wd_get_params()会硬盘发出具体的指令，驱动硬盘并获得作出相应的回

应。由于比较多细节，且那些结构体的成员较多，有兴趣的可以自行阅读。这里

这个命令的含义上获得硬盘的一些常用信息，填充wd->sc+params这个结构体。

标记那个分区被打开了

好了，wdopen 就算到这里了，由于对于这些细节大部分同志没有了解的必要，

就这样吧。当然最重要的原因是：我也不了解，

l oad 内核

龙芯论坛常有人问pmon 的引导原理，现在我们就看看引导到底是如何实现的。

首先既然引导内核，就首先有个内核所在位置的标识，早期的pmon 使用al 这

个环境变量表示欲引导的内核，典型的al 为/dev/fs/ext2@wd0/boot/vmlinux，

现在的pmon 在保留这个模式的同时，引入了类似grub 中的menu.lst 的形式。

就是把欲引导的内核和传给内核的参数以一定的格式放在boot.cfg的文件中，这

个boot.cfg 文件放在第一硬盘第一分区的根目录下或者boot 目录下。

先回顾一下执行的流程。在可恶的init_net 执行完以后，代码会调用一个重要的

函数DevicesInit()用于初始化分区，这个函数我们之前已经分析了。

pmon 的引导相关代码如下(基于8089
笔记本吧，删除了无关代码)：

get_boot_selection()函数会接收你的按键，根据按下的不同的键进入不同的分

支。这个函数中调用了ioctl()，这个函数非常重要，后面会列出专门一节讲述。

假如你没有任何的按键操作，get_boot_select()就返回NO_KEY。

如果没有设置bootdev 这个环境变量， load_menu_list()按照寻找(wd0,0)

/boot.cfg，(wd0,0)/boot/boot.cfg 的顺序寻找启动信息，如果找到合适的可启动

的内核，那么就会run 那个内核，这个函数就一去不复返。这个过程的代码和从

al读取启动内核位置的本质是一样的，我准备只分析从al环境变量读取的情形。

在没有boot.cfg 这种启动选择以前，一般都会设置al 这个环境变量用于选择要

启动的内核。同时会设置karg 这个变量作为g 的附带参数。

好，稍后就以s 等于/dev/fs/ext2@wd0/boot/vmlinux 为例来介绍这个autoload。

和那个load_boot_menu一样，如果不出意外的话，这个函数也是一去不复返的。

好，现在看看autoload()函数。

这个变量平时很少设置，initrd 在龙芯上也不常用，我只在一次网络安装debian

系统时使用过这个命令。

对于默认的al 来说，buf 就是字符串’load /dev/fs/ext2@wd0/boot/vmlinux“。

我们稍后会详细分析这个do_cmd。这里

获得karg 的设置。

正常的，我们这里的buf 是“g console=tty root=/dev/hda1 no_auto_cmd”

可见，autoload 实际上就是两个do_cmd 的函数调用，

简单的说，第一个调用会把那个vmlinux 文件放到内存上某个位置，g 会执行那

个文件。

do_cmd()函数的解析比较繁琐，最终会执行stat = (CmdTable[i].func) (ac, av)，

先看do_cmd(“load /dev/fs/ext2@wd0/boot/vmlinu’)

还记得否， init()函数的初始化分为4 类，其中的一类就是命令的初始化。

CmdTable[i].func 就是执行初始化时注册的那个命令的执行函数。这里就是

cmd_nload 函数。这个函数就是spawn 的一个包装。spawn 函数初始化了一个

“进程”，这些我都不关心，我关心就是spawn 倒数第二行的的exit1(sonproc,

(*func)(argc, argv) & 0xff),这关系到一个极为关键的地方，spawn 的返回值是什

么。在exit1 之后有句return(0); /* will not likely happen... */

如果每次都返回0，那这个返回值就一点价值都没有了，而且正常的你会发现边

上的注释。为什么不会执行这个return 呢？exit1 的作用。

在exit1 的末尾有一句longjmp(xx,xx)，可见程序的执行流就被改变了，其实在

spawn 中也有一个setjmp 来保证longjmp 返回到哪里，longjmp 和setjmp 其实

是个相反的过程，代码都在../lib/libc/arch/mips/longjmp.S 中。对于这个过程有

兴趣的可以细究这个过程，我这里只需要明白，返回值是由执行传给spawn 的

那个命令（第二个参数）返回值决定的就ok 了。在这里，spawn 的返回值就是

执行nload 命令的返回值。

现在看看这个nload 到底做了些什么。如果没明白我说什么，就再看一遍代码。

nload 这个函数很长，这里只来点关键的。

第一个关键函数，getopt()。比如我们在刷新pmon的时候会使用load -r -f xxx.bin

这样的命令，这个-r 和-f 就是由这个getopt 解析的。解析之后会设置flags 变量。

第二个关键函数，open()。

open 函数前面专门讲过，不陌生了吧。

后面我会专门讲解load pmon 的过程，现在不去管flash 相关的代码。

这样的话，剩下的代码就不多了，就列在下面：

这个函数重新初始化了符号表，就是ls 看到的东西。（试试看，load 前后ls 有差

别没有）。之后清除所有断点。

如果没有-r 的选项，执行这个exec(NULL, bootfd, buf, &n, flags)，记住对于我

们load /dev/fs/ext2@wd0/boot/vmlinux 的例子，这里的n 和flags 都是0。

exec 从函数名上看，就是执行这个具体的命令。代码如下：

可以看出id 表示这个要load 的文件的格式，如果为NULL 表示格式不确定，就

调用所有的格式执行函数试试，如果执行顺利，返回0 表示正确。否则继续尝试

下一个类型的文件loader 函数。这里我们执行的是elf 格式的内核，所以在执行

elf 的loader 函数后会返回ep （entry point），具体的loader 函数稍后再看。

在执行了elf 的loader 函数后，exec 函数退出，返回非负数表示load 成功。我

们回到nload 函数接着看剩下的扫尾工作。

先关闭这个文件close(bootfd)，接下来是错误处理，不看了，就。剩下就之后下

面几句了。我们的flags 是0，遇到’!’开头的都执行。

手动load 过的哥们都见过这句吧。

刷新一级cache(数据，指令)

至于这两个set 我都不大理解是做什么用的。

}

刚才我们跳过了最重要的elf 的loader 函数，现在可以一睹其芳容了。记得我们

给的见面礼吗？

ep = (*p->loader) (fd, buf, n, flags))，第一个参数fd 是文件描述符,buf 是一个大

小为DLREC(550)个字节的缓冲区的首地址，n 是值为0 的一个局部变量的地址

(表示了文件操作的起始字节)，flags 为0。

Load_elf()函数在../pmon/loaders/exec_elf.c 中，代码较长，我们就跳着讲吧。

这个函数和elf 的格式规范密切相关，如果要阅读这个文件，最好先了解点elf

的文件格式定义。我推荐滕启明写的《ELF 文件格式分析》，他讲了最基本的概

念。在写这个东西的时候，我使用khexedit 和hexdump 查看二进制的内容。

首先先读取开头的DLREC个字节，判断文件的开头是否是和elf 文件格式相符。

是就打印(elf)，否则出错，返回负数。现在龙芯使用的内核基本都是64 位的。

但是使用的时候一般都使用压缩过的内核，这内核是32 位的。编译后源码目录

的vmlinux 是64 位的，通过二进制的对比，他们的EI_CLASS 位是不同的，我

们这里的代码也是通过这个标志位判断当前的内核是64/32 位的。64 位的内核

会调用load_elf64(fd, buf, n, flags)去执行。这个代码的流程和load_elf 基本是一

样的。中间有个明显的疏忽，在从load_elf 复制代码后，有个地方的32 没有改

成64。呵呵。

在确定是32 位的elf 文件后，判断程序头部表（programme header table）是

否存在。存在并且合理的话就把这个程序头部表读到phtab 开始的区域中。之后

读取节区（section table）表。一个程序头部描述了一个段，一个段中包含了几

个节区，大致是这么个关系。在可执行的文件中，我们平时说的代码段，数据段，

bss 段都是段，而不是节区。

现在以8089 逸珑
笔记本自带的内核为例看看代码如何执行，我们这里要使用

readelf 这个工具。工欲善其事，必先利其器呀。

Section to Segment mapping: 节区到段的映射

可见内核的组织方式是非常简单的，.text .reginfo .data .sbss .bss 这些节区都拼

在一块，作为一个可装载的段。

好了，有了这些感性认识，读代码就清楚多了。

Load_elf 接下来的代码就是一个while 循环，看段类型是PT_LOAD 就想装载，

但代码中也说了，为了兼容旧版本的乱序（地址顺序）链接结果，把代码写的有

点不爽了。

最关键的就是bootread 了。这个直接把要引导的elf 文件按照它自己的意愿放到

内存中，它表达的窗口和是程序头部的p_vaddr 这里，通过上面的readelf 看到

内核的意愿是放到0x81000000。

在pmon 下load 上面的那个内核的输出为

其中的第二段以(z)结尾的表示要清零的部分，第三段表示符号表。

具体代码字节看，不说了。

正常情况下返回值是return (ep->e_entry + dl_offset);，这里的dl_offset 就是0，

不信打出来看看。

在这个函数返回ep 后，我们回到nload 那个函数看看。

当时我们不知道几个set 是干什么的，现在情况不一样了。setpc 就是在条件允

许的情况下，我们要调到的地址，setloadsysms，就是改变ls 看到的内容。

好了，nload 执行结束，返回成功标记，这样一个load 过程就算ok 了。也就是

do_cmd(“load /dev/fs/ext2@wd0/boot/vmlinu’)过程结束了。

load是好了，还有个g呢，回到autoload那个函数。假如我们的karg是”console

=tty root=/dev/hda1 no_auto_cmd’， 下面就瞅瞅do_cmd(“g console=tty root

=/dev/hda1 no_auto_cmd’)干什么，好，瞅瞅就瞅瞅。

g 的命令就是执行cmd_go，在../pmon/cmd/cmd_go.c 中。

由于要引导的内核已经在内存里了，g 要做的就是让cpu 到那里执行，这需要先

处理他撒手而去的一些事宜。

开始就是一些参数检查， 把clientcmd 设置为字符串“g console=tty root

设置新的sp，位置在内存的高端最后64 字节

解析这个clientcmd，每项都在clienttav 这个数组中。这里我们有6 项，clientac

为6。

这个initstack 是对栈的一些操作，还是非常重要的，在这个函数中还把所有的

pmon 的环境变量和g 的参数等放在栈里，用于内核使用。

打印当前的所有寄存器内容。

设置状态寄存器。

设置一些使能。

关闭一些usb 设备和网卡

先设置等会我们要执行的寄存器状态

goclient()最重要的就是最后调用_go()，把寄存器给填充为我们setjmp 时的值，

关键是epc 这个寄存器，执行eret 返回，就返回到eret 所指的地址去了。关键

的在这：

这个PC 就是我们load 命令最后set 的前面那个md_setpc()存的。这个goclient

()中的_go()之后，pmon 就把控制权交给内核了，阿弥陀佛，再见。

}

正常的话，下面的都不执行的

pmon 的代码有很多会涉及到termio 的函数，这里先介绍一些。

termio 相关的函数代码都在../pmon/fs/termio.c。首先看termio 在init()函数初始

化时执行的代码。

这个函数非常重要，会初始化描述串口和显卡设备的一些结构体，稍后详细解释。

往文件系统链表插入termio 这个文件系统，以备使用。

不同的下标代表了不同的设备，具体代表的设备如下面所示。

下面简要的介绍devinit 和term_open。先看devinit，定义如下：

ConfigTable 数组在tgt_machdep.c 中定义，对于逸珑8089，实际上就是：

很明显，第一个表示串口，第二个是显卡，第三个表示结束。

下面要使用ConfigTable 的内容填充DevTable 的结构体。

handler 函数比较重要，会在多个场合被调用到。

这里创建接收和发送队列的缓冲区，大小默认都是256 个字节。

这个函数执行完以后，DevTable 的前两个元素就表示串口和显卡了。下面看

term_open，这个函数在termio 的init_fs 函数中被连续5 次调用，分别用于初

始化前5 个文件结构，我们下面以term_open(4, "/dev/tty1", 0, 0); /* vgaout */

为例介绍，函数定义如下：

我们传入的是/dev/tty1 或者/dev/tty0，开头都是一样的。

我们的例子中dev 为1。

每个文件对应一个TermDev 结构。前面5 个文件是特定的。

对于显卡，他的OP_OPEN 实际上什么也不做。

如果是第一次打开，那么reset 一下这个设备的相关设置。

}

else {

return -1;

}

return fd;

}

printf 和write

我们最熟悉的函数就是用printf 在屏幕上打印字符串了。现在就看看吧。

printf 的解析是非常繁琐的。我们就用最简单的情况printf("hello ,pmon")分析。

printf 定义在lib/libc/printf.c 中。代码如下：

如果各位大侠看过内核的源码中的可变参数部分，对这几个va_start 和va_end

一定不会陌生。我基本上也忘的差不多了，挺不好讲的，不说了，好吧。

我们的例子中，可变参数的参数个数为1，printf("hello ,pmon")唯一的参数就是

这个字符串的首地址。这个ap 就不管了。我们要打印的就是fmt 开始的那个字

符串的内容。

stdout 的定义为#define stdout (vga_available?(&_iob[4]):(&_iob[1]))

在显卡初始化以后，vga_available 为1，stdout 就是_iob[4]

_iob[]的定义如下：

第一个参数表示fd，第二个参数都是1，表示文件有效。这些个fd 的fs 参数在..

/pmon/fs/termio.c 中定义。均定义为termfs，马上会用到。

Vfprint 代码如下，代码中的fp 就是传入的stdout：

vsprintf()会解析这个printf 传入的参数，解析后的结果放在以buf 为首地址的缓

冲区中。n 表示解析后的字符串长度。

fputs 就一句话，write (fp->fd, p, strlen (p));由于fp->fd 就是4，这个文件代表

以上的代码实际上就是调用write (4, p, strlen (p))，对于我们前面的printf(

“hello , pmon’)，这里的p 就是这个字符串的首地址。

我们曾经分析过open的操作，现在就以这个printf 的调用为例分析write操作吧。

代码在../lib/libc/write.c 中，如下：

如果这个文件（设备）所属的文件系统的write 函数存在，就执行之。fd 为4 代

表的vga 的fs 为termfs，其write 函数为term_write()。

传给term_write 的参数实际上是term_write(4,”hello, pmon’，长度)

term_write()代码如下：

这些fd 的data 在termio.c 中的init_fs 中的5 个term_open 调用的过程中初始

化。其中的dev 成员标志了这个到底是什么设备，0 就是串口，1 就是显卡。也

就是说被write 的设备是显卡。

tgt_smplock()这些用于互斥的操作在pmon下实际上是没有什么意义的。并没有

对什么资源的申请并占有。

判断发送队列还有多少空间。下面就一个一个发送。

查看termio 的规定，如果设置oflag 的OLCUC 位，在发送换行符（'\n'）前先

发送回车符（'\r'）。Qput 把要发送的字符保存在缓冲区中。

发送传入的那个字符。

如果顺利的话，现在要输出的字符都放到发送队列中去了。

如果有字符要打印，现在要调用scandevs()。看函数名，就是挨个问，有没有

要打印东西的，有就打印了。

scandev 这个函数在多个地方被调用，是非常关键的。

这个函数的流程可以分为三个部分，分别是检查输入缓冲区，输出缓冲区，按键。

我们暂时只看后面检查输出的代码，如下：

看看有没有要输出的，返回的是要输出的个数。

对于逸珑8089 的显卡，其handler 函数为fbterm()，在../pmon/dev/vgacon.c

中，其OP_TXRDY 恒返回1。表示随时都准备处理。

取出要打印的字符。

下面看看OP_TX 到底干了些什么。

如果要显示的话，就调用video_putc()在屏幕上打印那个东西。这个函数没有什

么东西了，现在就只看这个函数了吧。

Video_putc 函数代码如下：

其它的都不管了，我们只看最常见的情形，显示一个字符。

在BIOS 阶段，显示都是用的字符模式，每个字符的宽度为8 个像素，每个字符

的高度为16 个像素。video_putchar 的前面两个参数就是要显示的字符所在位

置的左上角的像素点的列位置，行位置。第三个参数是要显示的字符。

检测是否到头了。

就看video_putchar 这个函数了，定义如下：

VIDEO_LOGO_HEIGHT 在fb/cfb_console.c 中定义为0。这里的xx 为水平方

向的像素位置，yy 为垂直方向的像素位置。c 是要显示的符号，1表示显示1次。

函数定义如下：

这里的VIDEO_PIXEL_SIZE 为2，表示每个像素占2个字节，VIDEO_LINE_LEN

为1024*2，表示一行像素要占用的字节数。我怎么知道这个值是多少呢？printf

不行，会递归成死循环的。

小技巧，加如下两句。进入pmon 命令行后用m 命令看m -d 81000000 即可。

通过如上的方法， 读出这里的video_fb_address 值为0xb4000000， 可见

framebuffer 的首地址为0xb4000000。每个屏幕上的点都由framebuffer 上的两

个字节控制。0xb4000000 开始的两个字节对应屏幕左上角的像素点。

接下来是一个switch，VIDEO_DATA_FORMAT 定义如下：

pGD 在fb_init 中初始化，小本上这个是2，表示色深为16 位色。同理，同理如

果这个为3，表示24 位色。代码中设定了如果为16 位色，就使用565 的RGB

编码。这个值的switch 的代码为：

我们可以算出来了，一个字符的像素为16x8(所以字符都挺水蛇腰的)，每个像素

占两个字节。cdat 表示我们要显示的点阵的首地址。我们假设这里要显示'A'，

到底如何才能看到我们看到的符号呢？

vIdeo_fontdata 是一个点阵数组，字符A 的点阵如下，特地用红色标记了，差不

多吧，去看看pmon 命令行下的的A，是不是一样的。就是一样的。

现在都明白了，video_fontdata 就是字符的点阵数组了，如何显示呢？

这个字符A 的点阵为16 个字节，但实际上在framebuffer 上我们一个字符占用

256 个字节，或者说点阵中一行是一个字节，但在framebuffer 上是16 个字节，

这里就有一个索引，每两位索引四个字节。等会就看到了。

看这个for 的循环方式，可以看出是填充一行，一共16次，每行差2048个字节，

这个前面都说过的。

bits现在表示了点阵的第一个字节的内容，代码中的SHORTSWAP32没什么用，

去掉了，看得就清楚多了。

前面刚说了，每两位一个索引，看上面的代码就很明白了，>>6，>>4，>>2，

不就是剥离出那两位吗!索引的数组是video_font_draw_table16，定义如下：

可见索引对应关系如下：

这里要注意高低地址的关系，01 表示后面那个像素要点亮，但是后面的像素是

在高字节的，所以01 对应的是0xFFFF0000。

代码中的eorx 为0xa514a514，bgx 为0。0xa514 这个数有明显特征，就是和

它与后，RGB 都只保留了两位数。这就像是对565 的格式再进行采样，也许很

性能相关吧，不去关注了。

好了，再细节的东西列位自己看吧。printf 就到这里了。

键盘和键盘事件的响应

前面讲了printf 的输出，下面就介绍它的反方面，那就是键盘输入的响应。

在dbginit 的过程中，会执行tgt_devconfig()，对于
笔记本，这个函数会调用

kbd_initialize()初始化键盘控制器。8042 键盘控制器有两个端口，状态和控制寄

存器为64h 端口，60h 为数据寄存器端口。在开始看这个初始化代码前，我们先

看看接受输入的函数kbd_read_data()。

8042 键盘控制器文档对寄存器的说明非常清楚。状态寄存器描述如下：

如果按下了键但系统没有读取

那么从数据端口读取那个按键的扫描码。

kbd_initialize 代码较长，这里只讲主干。

这个kb3310_test 会读取xram 的第一（0）个字节，如果返回那个值为0xff，表

明出错。

这个函数会检查当前缓冲去中是否有内容，如果有，则抛弃掉。判断是否有内容

是用kbd_read_data()，如果返回非KBD_NO_DATA，就继续读。

向8042 的控制寄存器发送命令。在8042 的文档中对命令的解释也很清楚，有

兴趣的可以自行阅读。KBD_CCMD_SELF_TEST 是0xAA，AA 命令的解释为：

很符合文档的规范，返回0x55 表示正常。下面判断时钟和数据线是否有效

下面是正式的键盘接口使能。

发送这个命令后，键盘会回到上电后的默认状态，并分会一个ACK。

告诉键盘控制器，我的下一次操作是发命令了。

使能中断。下面设置键盘的扫描码

。。。IBM powerpc 的特殊处理部分。。。

}

下面使能键盘的输入扫描。前面的命令都不是扫描输入得到的。

设置扫描周期和延时，下一个命令传送具体的参数。

下面的0 是上面那个命令的参数，表示没有延时，每秒扫描30 次。

好，kbd_initialize 到此为止。usb 键盘和
笔记本自带的键盘的处理不同。我这只

关注自带键盘（因为这个简单*_*）。

由于在pmon中没有中断的功能，所以必须有个时机让cpu知道有按键的动作发

生。这个时机就是调用scandevs 函数的时候。

scandevs 这个函数函数可分为三部分，检查输入缓冲区(软件层面)，检查输出

缓冲区，检查有没有按键。前面我们看的是第二部分的代码，现在看第三部分。

我关心的就一句话，kbd_poll()。

这里检查键盘控制器的状态，看是否有未处理的按键。如果有，那么

这个函数会调用handle_kbd_event，代码如下：

status 表示了当前8042 键盘控制器的状态，work 表示尝试的次数。避免刚处理

了按键很快又有键按下，导致总在这个循环中的问题。其实概率非常非常小啦。

从8042 读出来的数据都是第一套的扫描码，前面键盘初始化的时候设置的。

处理键盘的输入，参数是扫描码的值。

判断现在还有没有未处理的按键，如果有则还在这个循环中。在第一套扫描码

中，大部分按键的码都是一个字节，部分特殊功能键是2 或3 个键码。

handle_keyboard_event 的定义如下

跳过处理重复发送键码（比如你一直按下一个键时）的处理，实际就是调用

handle_scancode(scancode, !(scancode & 0x80));这个scancode 为什么要与

上0x80 呢？因为在第一套扫描码的定义中，按下键和释放这个键的扫描码差

0x80,而且释放键的扫描码都是大于0x80 的。故可通过此判断是否为释放键。

handle_scancode 代码如下：

Up_flag 为0，表示是按下键，否则为释放键。

对于软件系统来说，处理的不是扫描码，而是键码，所以有个kbd_translate 函

数，这个有兴趣的自己看。

这里有有一层软件的抽象，前面的转换成keywork 是标准的，对于所有的键盘

都一样，但我们知道有美式键盘，荷兰语键盘，西班牙键盘等，也就是按了同一

个键表达的内容不一样，这个功能是通过kaymap 的映射实现的。

这个type 和key_map 相关联，不同类型的键type 不同，比如字符键，ctrl 键，

backspace 键等类型就明显不同。

表示输入是一个字符。

根据type 调用不同的按键处理函数，对于字符键，调用的就是key_handle

[0]，处理很简单，如果是释放键，直接返回，否则给kbd_code 这个全局变量赋

值。

函数基本上是原路返回，并没有什么动作了。返回到scandevs 中。

这里有个问题我不理解，返回到scandevs 后，只有非零kbd_code 表示按下了

一个键并且这个按键没有被处理，也就是执行了scandevs 后，我的输入不能马

上被放到输入缓冲区中，而是在下次scandevs 时被放到输入缓冲区中。也就是

说如果没有下次对scandevs 的调用，这次的输入就没有作用。因为代码中的确

没有在kbd_poll 后有任何的对输入缓冲区的操作呀！但是，我们明显知道，在

pmon 命令行下，我们按下一个字符键，就显示一个字符，可见是一旦输入就处

理了呀，并没有出现在下次按键后才显示前一个键的状况呀。怎么回事？怎么回

事？为什么？为什么？

是这样吗？

剪不断，理还乱，别有一番滋味在心头。

的确，世界上有很多事情是我难以精确解释的，不过这个问题不是。

首先做一个实验。

在pmon中，最先响应的输入是get_boot_selection。这个文件的开头部分如下：

也许一看就明白，这个ioctl 调用后返回的cnt 的值表示了输入的键值。因为如果

cnt 非0 的话，就认为按下键，就getchar()。

好，get_boot_selection就到这里。看ioctl (STDIN, FIONREAD, &cnt)的。如下：

scandevs 我们都很熟悉了（或者更陌生了）。老生我再谈一下吧：

这个函数分三部分：

1. 输入缓冲区的检查。

2. 输出缓冲区的检查

3. 有没有待处理的硬件（键盘按键，网络包处理等）

我一开始是这样理解这个ioctl 的，我们在开机后按下了del 键，但是一直没有被

处理，到这个ioctl (STDIN, FIONREAD, &cnt)执行的时候，会执行第三部分的

kbd_poll ，检查键盘控制器，看有未处理的按键，读出来，scancode 转keycode，

设置kbd_code，再往输入缓冲区中写。之后这个scandevs 执行完毕，马上接

着执行*(int *)argp = Qused (p->rxq)，啊，输入缓冲区不空。argp 记录下这个输

入缓冲区的内容数量。

这个想法很合理，但代码不是这么写的。问题在于在设置了kbd_code 后，

scandevs 没把键值送到缓冲区就拍屁股走了。所以实际上在执行Qused (p

->rxq)时，我这次的输入并没有加到这个输入缓冲区中（receive queue）。那么

这个返回的东西岂不就是0 吗？好，问题说好了。实验来了。

在代码中添加三句话(红色字体显示)

加入了这个修改的pmon 执行的效果如何，开机后长按del 键，结果出来了。

temp1 和temp2都是3。也就是说scandevs前后输入缓冲区的内容并没有变化。

为什么呢？当然为什么是3 这个问题更难回答。

其实在启动的时候（包括kbd 初始化后）我们执行了许多的printf 函数，有的打

到串口，有的打到屏幕上。前面的章节中有个细节，在printf 执行的过程中会调

用scandevs，不信回去看看，也就是说每个printf 函数都可能会调用kbd_poll，

从而接收了键盘控制器的输入。所以我有个猜想，如果在kbd 初始化完成后到

get_boot_selection 之间没有调用printf(或者其它会调用scandevs 的函数)，我

们在第一次get_boot_selection 调用ioctl (STDIN, FIONREAD, &cnt);的结果将

是cnt 为0，当然get_boot_selection 是个循环，第二次就会在scandevs 的输

入缓冲区的检查中检查到输入了。cnt 就不为0 了。

如果我上面的分析没有问题的话，就是当前的输入是下一个scandevs才能收到，

在pmon 命令行下即输即显又如何解释呢？说不过去呀？

看代码，不行也行。

上面的顺序就是pmon 命令行下接受输入的函数调用路径。这个路径写到

term_read 是因为我们看到了一个可以说明问题的代码了。代码如下：

这里的n 是1，表示我们要read 一个字节，这个for 循环有个特殊的地方发现没

有，没有i++，什么时候i++呢，在这个函数的末尾。也就是说如果没有读到就

一直scandevs。直到输从入缓冲区中读到一个才i++，都到这里了，剩下的自己

看吧。所以在pmon 命令行下即输即显是通过反复调用scandevs，直到得到一

个字节的方式实现的。要知道回显是如何实现的可以看get_line代码，很明显的。

这个流程合理吗？

scandevs 的流程是否合理呢？那三部分的顺序能否掉换呢？也就是第三部分的

代码放到第一部分前面。

呵呵。到这里吧。

代码中调用了多次ioctl，我们下面就看看这个函数。

ioctl 是一个和read，open 一样常见的文件操作函数。在pmon 中，主要用它来

和串口，显卡等字符设备交互。

又是对可变参数的处理。在pmon 代码中，一般都只有三个参数，argp 就是第

三个参数。

对于前5 个fd，上面调用的ioctl 就是调用term_ioctl，其余的文件一般就是普通

文件，ioctl 就是文件系统的ioctl。这里只看设备文件的ioctl 实现term_ioctl。

data成员在term_open时初始化，devp->dev 标记了这个文件是串口还是显卡。

fd 为0,1,2 时，表示为串口，为3,4 时，表示为显卡。

返回这个设备的termio 结构体指针。

清空接收队列。

用传入的参数给设备的termio 赋值并改变波特率。

返回有接收队列中还有多少个键值没有被处理。

设置中断处理函数？

重新初始化这个设备的控制方式。

返回但前的termio 设置设备并退出标准模式，不回显输入。在标准模式下，输

入字符存储在输入队列的缓冲区中，直到读入换行符或是EOT(^-d)字符后才将

所有数据一次输出；在原始模式下，字符一键入就立即输出，没有缓冲区。系统

默认的是标准模式。

和SETNCNE 的唯一差别是受到删除键允许删除前一个字符。

返回当前的term 的name。

这个好像没有任何作用。