龙芯2E体系结构之异常、中断-CSDN博客

作者: comcat 发表日期: 2006-11-22 12:14 http://comcat.blog.openrays.org/blog.php?do=showone&tid=164

本文拟在宏观上对龙芯2E 的异常、中断系统作一个框架式的描述。

1. 概述

龙芯2E在高优先级异常出现时，在设置了某些寄存器后，会根据异常类型跳转到相应的固定地址处
（高优先级异常服务入口），操作系统会将相应的异常处理程序，置于这些地址处。
龙芯2E之高优先级异常有：冷启动、热重启、非屏蔽中断、cache错误、TLB重填（32位模式）、xTLB重填
（64位模式）、其他异常。

龙芯2E之高优先级异常入口地址有以下五个：

TLB 重填 BASE + 0x0
xTLB 重填 BASE + 0x80
cache 错误 BASE + 0X100
其他 BASE + 0X180

其中 BASE 是基地址，当龙芯正常运行时（STATUS 寄存器之BEV位为0 ），BASE 为
0xFFFF FFFF 8000 0000（该地址处龙芯不经TLB映射、但缓存）；当龙芯启动时
（STATUS 寄存器之BEV位为1 ）BASE 为0xFFFF FFFF BFC0 0200 （该地址处龙芯不
缓存、不经TLB映射），有关这两个地址空间的详细描述可以参看龙芯用户手册。

冷启动、热重启、非屏蔽中断异常的入口地址始终位于 0xFFFF FFFF BFC0 0000

由此可见龙芯2E启动时，执行的第一条指令是位于地址 0xFFFF FFFF BFC0 0000 处的，实际上龙芯
电脑上所用之BOOTLOADER(PMON)的代码就位于地址空间的0xFFFF FFFF BFC0 0000处。

与x86的中断系统相比较，x86有256个中断号，前32个保留给CPU使用，0x20开始的中断号用户可以
自定义使用，当中断发生时，CPU用中断号索引以IDTR寄存器的值为基地址的中断描述符表（IDT），
IDT的每个表项指向相应的中断处理程序。可以看到x86的中断系统结构清晰，很容易理解，初始化时只
要将中断处理程序的地址填入相应的IDT的表项中就可以了。可是到现在我们还没有看到中断控制器的影
子，来自硬件的中断，龙芯如何处理呢？

注意到上面的五个固定的异常入口地址，有一个其他异常类入口，当CPU内部异常或者中断发生时，CPU
硬件设置CAUSE寄存器的ExcCode位（该位段用来描述异常原因）后，跳转的该异常入口地址，位于该地
址处的是操作系统设置的一个简单的异常处理程序，它会取出CAUSE寄存器的ExcCode值，用之索引一个
异常处理表(exception_handlers)，并跳转到异常处理表项所指向的处理程序，异常处理表如下所示：

------------------------
| handle_int | ----------> 中断处理 ExcCode值为0
------------------------
| handle_tlbm | ----------> TLB修改异常 ExcCode值为1
------------------------
| handle_tlbl | ----------> TLB 读异常 ExcCode值为2
------------------------
| ....... |
| |
------------------------
| handle_sys | ----------> 系统调用 ExcCode值为8
------------------------
| ....... |

该异常处理表很像 x86 的IDT，只是他的每个表项没什么附加信息，就是一个相应异常处理程序的地址。

对于来自硬件的中断，CPU会自动将CAUSE寄存器的ExcCode位(6:2)设为0。
可以看到，当硬件中断出现时，CPU最终会执行中断处理程序 handle_int，可它又是如何来鉴别具体是来自
键盘还是来自IDE硬盘呢？

这个要借助于CAUSE寄存器的IP位(15:8, IP7-IP0)，硬件中断出现时，CPU会自动设置CAUSE之IP位，进入
处理程序handle_int后，handle_int会根据IP位的值跳转到对应的与硬件紧密相关的处理函数中，如IP5
(CAUSE第13位)置为1，说明当前硬件中断来自于8259A中断控制器，则读取8259A之In-Service Register
(ISR, 注意与x86的差异，x86是由8259A主动将中断号送上数据总线的)后，跳转到8259A中断控制器相关的
中断处理函数do_nb2005_8259中，因为ISR的值与具体的硬件中断相关，故而可以通过简单的计算得到中断
号，进而调用do_IRQ进入相应的中断处理程序。

可以看到龙芯的整个异常处理是个树状结构，如下图所示：

从图中可以看出，到中断这一层，都是与具体主板所用中断控制器相关的。

当前龙梦电脑所用主板上有2个中断控制器，其中一个为x86平台所常见的i8259A。因为龙芯平台不采用专有
的I/O 指令，各种设备的寄存器都是映射到地址空间的，龙梦主板所用2片i8259A分别映射到0xBFD00020，
0xBFD000A0对应于x86平台的20，A0端口。
故而对0xBFD00020的读取，就相当于x86平台的in data, 0x20操作，同样对0xBFD00020的写入，亦相当
于x86平台的out 0x20, data操作。

在Linux内核中2片i8259A的中断请求号映射到0-15 。

另一个中断控制器目前没有任何文档对其进行描述，从内核的代码来看这个应该是集成在北桥中的，考虑到
此前龙芯操作系统组使用开发板P6032学习MIPS Linux，再集合代码中有关该中断控制器的命名和头文件以
及有关PCI地址空间的代码和头文件，可以推测计算所自己设计的北桥参考了P6032的北桥。根据可用的内核
代码和有关中断控制器的背景知识分析如下(仅考虑32位时)：

以下分析称该中断控制器为bonito。

0xBFE00000+0x130 处映射为bonito之INTENSET寄存器，INTENSET为32位，
每位对应一个中断。如：将位0置1，则将bonito看来之0号中断打开。可读写

0xBFE00000+0x134 处映射为bonito之INTENCLR寄存器，INTENCLR亦为32位，
每位对应一个中断。如：将位5置1，则会将bonito看来之5号中断屏蔽。可读写

0xBFE00000+0x138 处映射为bonito之INTEN寄存器，INTEN亦为32位，每位对
应一个中断。这个应该是中断屏蔽寄存器，0表示禁止，1表示允许，应该是对以上2个
寄存器的操作会在这个寄存器的对应位上得到反应。只读。

0xBFE00000+0x13c 处映射为bonito之INTISR寄存器，INTISR类似于i8259A
的ISR (In Service Register)，每位对应一个中断。中断处理程序通过读取该寄
存器获取当前中断请求的内部中断号。只读。

尚有INTEDGE(映射到0xBFE00124)、INTSTEER(映射到0xBFE00128)、INTPOL(映射到0xBFE0012C)
详细用途不明，还望达人赐教(有P6032的用户手册这个问题应该很容易，可惜现在网上找不到)。内核中
只在初始化该中断控制器时用到：

BONITO_INTEDGE = BONITO_ICU_SYSTEMERR | BONITO_ICU_MASTERERR \
| BONITO_ICU_RETRYERR | BONITO_ICU_MBOXES;
BONITO_INTPOL |= (1 << (41-16)); /* nb serial */
BONITO_INTSTEER = 0;

其中ICU 全称应该是 Interrupt Controller Unit.
第一句的目的大概是设置Bonito，使其当system error, master error, retry error的系统致命错误
出现时，产生非屏蔽中断(NMI)吧。应该相当于一个触发器。

在Linux内核中bonito的中断请求号映射到16-47 。

实际系统中中断号分配如下所示：

GodSonSmall:/comcat/test# cat /proc/interrupts
CPU0
1: 2493 XT-PIC i8042
2: 0 XT-PIC cascade
8: 104277105 XT-PIC rtc
9: 1685 XT-PIC VIA686A
14: 433245 XT-PIC ide0
42: 747123 bonito_irq ohci_hcd:usb1, eth0
43: 0 bonito_irq ohci_hcd:usb2
44: 99857301 bonito_irq ehci_hcd:usb3
63: 620460423 MIPS timer