出于某种原因,IRQ 6从未在我的Qemu,Bochs,VMWare或VirtualBox模拟器中出现。我需要某种类型的虚拟软盘驱动器吗?这是我的IRq6处理程序:
void i86_flpy_irq (struct regs *r) {
//! irq fired
_FloppyDiskIRQ = 1;
printf("IRQ 6 HIT");
}
它永远不会说" IRQ 6 HIT",不仅如此,在我的irq6的安装函数中,我在内核中调用:
void flpydsk_install (int irq) {
//! install irq handler
install_handler_irq (irq, i86_flpy_irq);
//! initialize the DMA for FDC
flpydsk_initialize_dma ();
//! reset the fdc
flpydsk_reset ();
//! set drive information
//flpydsk_drive_data (13, 1, 0xf, true);
}
如您所见,我调用了一个重置软盘驱动器控制器的功能。让我们来看看这个功能:
void flpydsk_reset () {
uint32_t st0, cyl;
_FloppyDiskIRQ = 0;
//! reset the controller
flpydsk_disable_controller ();
flpydsk_enable_controller ();
//flpydsk_wait_irq ();
printf("STARTED WAITING");
while(_FloppyDiskIRQ == 0);
_FloppyDiskIRQ = 0;
printf("ENDED WAITING FOR IRQ");
//! send CHECK_INT/SENSE INTERRUPT command to all drives
for (int i=0; i<4; i++)
flpydsk_check_int (&st0,&cyl);
//! transfer speed 500kb/s
flpydsk_write_ccr (0);
//! pass mechanical drive info. steprate=3ms, unload time=240ms, load time=16ms
flpydsk_drive_data (3,16,240,true);
//! calibrate the disk
flpydsk_calibrate ( _CurrentDrive );
}
你可以看到上面的内容,我等待IRQ完成,检查_FloppyDiskIRQ
是否为1,这是我设置的时间。我也注意到this常见错误。代码永远不会传递while()
循环,因为IRQ6永远不会触发。是否有一个原因?我如何修复它以便IRQ 6可以解雇?我想我必须向我的模拟器添加一些东西(就像我为我的ATA控制器添加了一个虚拟硬盘)。
我还通过打印IRQ来测试那个现在只有0,1,12的火灾(没有6)......
extern "C" void irq_handler(struct regs *r)
{
/* This is a blank function pointer */
regs_func handler;
/* Find out if we have a custom handler to run for this
* IRQ, and then finally, run it */
handler = irq_routines[r->int_no];
if (handler)
{
handler(r);
}
printf("%d,",r->int_no);
//irq_taskmanager->Schedule((CPUState*)r);
/* If the IDT entry that was invoked was greater than 40
* (meaning IRQ8 - 15), then we need to send an EOI to
* the slave controller */
if (r->int_no >= 8)
{
p8b_irq.out(0x20,0xA0);
}
/* In either case, we need to send an EOI to the master
* interrupt controller too */
p8b_irq.out(0x20, 0x20);
}
答案 0 :(得分:2)
该问题与您展示的代码无关。如果您使用 QEMU 和 GDB 调试或使用其内部调试器 BOCHS ,并允许您的代码运行,直到它进入无限循环,你可能会发现问题的根源是什么。
主要问题不是虚拟或真实硬件有问题。你的内核有一个bug。如果你已经为硬件设备(在这种情况下是软盘控制器)正确启用了IRQ,并且你没有得到预期的中断,那么有一些可能性:
调试器告诉您的关键信息是 EFLAGS 中的中断启用标志在到达flpydsk_reset
时已清除。这意味着CPU不接受外部中断。如果以某种方式无意中关闭了中断启用标志,或者您从未打开它们,则会发生这种情况。
其次,您是否注意到在等待软盘中断时您的鼠标指针没有移动且计时器没有更新?出于同样的原因,软盘中断(IRQ 6)没有被触发。
快速浏览一下kernel.c++
文件就会发现问题:
isr.install_isrs();
irq.install_irqs();
Timer timer;
timer.install_timer();
KBD kbd;
kbd.install_kbd_driver();
MOUSE mouse;
mouse.install_mouse_driver();
flpydsk_install(6);
__asm__ __volatile__ ("sti");
您安装了许多驱动程序(键盘/鼠标等),但是在达到此代码段之前,CPU处于发出 CLI 指令的状态。您的flpydisk_install
函数最终要求启用中断,但您发出 STI 指令 AFTER 对flpydisk_install
的调用。在flpydsk_reset
之前发出 STI 之前,您将保持无限循环,等待不会发生的中断。
一个快速的脏修复方法是在调用__asm__ __volatile__ ("sti");
之前执行flpydsk_install
。我可能会对8259A PIC上的中断进行编码,因为每个需要中断的设备都需要这些中断。
快速修复的修订代码如下所示:
isr.install_isrs();
irq.install_irqs();
Timer timer;
timer.install_timer();
KBD kbd;
kbd.install_kbd_driver();
MOUSE mouse;
mouse.install_mouse_driver();
__asm__ __volatile__ ("sti");
flpydsk_install(6);
现在 STI 启用CPU中断,应触发IRQ6及其中断处理程序,允许flpydsk_reset
退出其循环。
使用 STI 启用CPU中断后, VirtualBox 将要求您将软盘控制器添加到虚拟机。你不一定需要虚拟软盘,只需要软盘控制器。如果没有虚拟软盘控制器,则通过端口向不存在的硬件发送命令将不会启用IRQ6。
我相信默认情况下 BOCHS 和 QEMU 会模拟存在的软盘控制器,即使虚拟机中没有安装虚拟软盘。
由于您的文件BoneOS.bin
是作为ELF可执行文件构建的,并且因为您的代码不能在模式之间切换(实模式或64位长模式),因此设置调试相当容易。您的Makefile
有一个start-debug
QEMU食谱。我已将其修改为以下内容:
start-debug:
qemu-system-i386 -S -s -kernel BoneOS.bin -m 1G -serial file:qemu-serial.log \
-serial stdio -usb -device usb-host,hostbus=2,hostaddr=1 -no-reboot &
gdb BoneOS.bin \
-ex 'target remote localhost:1234' \
-ex 'break kernelMain' \
-ex 'layout src' \
-ex 'layout reg' \
-ex 'continue'
第一个 QEMU 命令将 QEMU 设置为在启动时暂停,并等待与 GDB 的远程连接。第二个命令将 GDB 连接到 QEMU ,中断kernelMain
(代码的主 C ++ 入口点),显示源代码代码和寄存器。用于调试的符号来自BoneOS.bin
。
从那时起,您可以查找实际使用 GDB 调试器的一般教程。
如果安装了 DDD 软件包,则可以使用图形调试器。它可以通过这种方式启动:
start-debug:
qemu-system-i386 -S -s -kernel BoneOS.bin -m 1G -serial file:qemu-serial.log \
-serial stdio -usb -device usb-host,hostbus=2,hostaddr=1 -no-reboot &
ddd BoneOS.bin \
--eval-command="target remote localhost:1234" \
--eval-command="break kernelMain"
通过调整 CodeBlocks 项目的调试器选项,可以使用 Codeblocks 进行远程 QEMU 调试。
答案 1 :(得分:0)
我遇到了同样的问题。我设法通过在执行每个中断服务后重新映射/重新初始化 PIC 来解决它。 我认为这是一个糟糕的解决方案,但目前它有效。 我的问题是我在键盘中断后调用了软盘读取例程,而没有向 PIC 发送 EOI(中断结束)命令。 所以在调用软盘读取例程之前发送EOI解决了这个问题。 你有没有找到更好的解决方案?