qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] possible pic misbehaviour


From: Herbert Poetzl
Subject: [Qemu-devel] possible pic misbehaviour
Date: Mon, 22 May 2006 06:05:36 +0200
User-agent: Mutt/1.5.6i

Hi Folks!

I started to play around with installing
NEXT/OPENSTEP last week and despite some
postings stating that it works 'somewhat'
I encountered several issues so far ...

the good news (for me) is that I could
resolve all of them and have it running
quite fine. now to the topic ...

one thing I had to modify was the pic
(i8259) behaviour, in a way which isn't
really obvious from the docs, even worse
the implementation seems to match the 
intel documentation perfectly

nevertheless as both operating systems
NEXTSTEP and OPENSTEP seem to require
my (or a similar/better) modification to 
handle interrupts correctly, and both 
do run quite fine on real hardware, I
suspect a non-obvious deviation in the
implementation.

here is the 'hack' I did to make it work

--- hw/i8259.c  2006-05-22 03:54:47.000000000 +0200
+++ hw/i8259.c  2006-05-22 03:54:47.000000000 +0200
@@ -119,7 +119,7 @@ static int pic_get_irq(PicState *s)
        master, the IRQ coming from the slave is not taken into account
        for the priority computation. */
     mask = s->isr;
-    if (s->special_fully_nested_mode && s == &s->pics_state->pics[0])
+    if (/* s->special_fully_nested_mode && */ s == &s->pics_state->pics[0])
         mask &= ~(1 << 2);
     cur_priority = get_priority(s, mask);
     if (priority < cur_priority) {


here is the initialization sequence 
observed (debug output) on the pics:

init[0,ICW1] = 11
init[1,ICW1] = 11
init[0,ICW2] = 08
init[1,ICW2] = 70
init[0,ICW3] = 04
init[1,ICW3] = 02
init[0,ICW4] = 01
init[1,ICW4] = 01
              
init[0,ICW1] = 11
init[0,ICW2] = 40
init[0,ICW3] = 04
init[0,ICW4] = 01
              
init[1,ICW1] = 11
init[1,ICW2] = 48
init[1,ICW3] = 02
init[1,ICW4] = 01

according to the specs, the full featured
mode is 'initially' turned on unless it
is specified otherwise (which is not the
case in the current implementation), but 
the observed init sequence IMHO turns it 
off again (ICW4=1), but without this or
some other AEOI functionality the first
irq on the slave pic will basically hang
the OS as the interrupt is not cleared on
the master ...

probably I just missed the obvious, but
I thought I'd better report that here ...

best,
Herbert

PS: will send a few more changes shortly














reply via email to

[Prev in Thread] Current Thread [Next in Thread]