Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP
id AA365 ; Sun, 31 Jan 93 14:04:51 EST
Xref: sserve comp.unix.bsd:10657 comp.sys.ibm.pc.hardware:42837
Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!yale.edu!ira.uka.de!math.fu-berlin.de!news.netmbx.de!Germany.EU.net!mcsun!sun4nl!tuegate.tue.nl!eba!svin09!wzv.win.tue.nl!gvr.win.tue.nl!guido
From: guido@gvr.win.tue.nl (Guido van Rooij)
Newsgroups: comp.unix.bsd,comp.sys.ibm.pc.hardware
Subject: Re: Programming the 8259 (and a possible 386bsd bug)
Message-ID: <1kgljlINN94r@wzv.win.tue.nl>
Date: 31 Jan 93 13:52:53 GMT
References: <1993Jan26.170934.5461@zip.eecs.umich.edu>
Sender: news@eb.ele.tue.nl (The News system)
Organization: Eindhoven University of Technology, The Netherlands
Lines: 41
NNTP-Posting-Host: gvr.win.tue.nl
dmuntz@quip.eecs.umich.edu (Dan Muntz) writes:
>I'd like to know what people have found to be good (accurate/complete) sources
>of information about programming the 8259 as it is used in 386/486 machines.
>In isa.c in 386bsd the following sequence is used to initialize the "lower"
>8259:
> /* initialize 8259's */
> outb(IO_ICU1, 0x11); /* reset; program device, four bytes */
> outb(IO_ICU1+1, NRSVIDT); /* starting at this vector index */
> outb(IO_ICU1+1, 1<<2); /* slave on line 2 */
> outb(IO_ICU1+1, 1); /* 8086 mode */
> outb(IO_ICU1+1, 0xff); /* leave interrupts masked */
> outb(IO_ICU1, 2); /* default to ISR on read */
>According to the meager amount of information I've found, the last line
>should be outb(IO_ICU1, 3); to select ISR on read (or the comment should
>say IRR instead of ISR). From other points in the code, it appears that
>ISR is expected. If this line is wrong, the other 8259 is also being
>initialized incorrectly. Can anyone shed some light on this?
Though I don't have a manual on programming the 8259 in a 386 architecture,
I have the description of the 8259 here. It is obvious that in the last
outb, OCW3 is programmed. This is operation command word 3. The first
2 bits are described as follows:
bit0 : 0 | 1 | 0 | 1
| | |
bit1 : 0 | 0 | 1 | 1
| | |
action: no action. |read IR reg on | read IS reg on
next RD pulse next RD pulse
So according to me your observation is right and it should be 3, when
indeed ISR is meant. But then things shouldnt work very well. IS contains
the levels requesting an interrupt to be acknowledged, while IR contains
the levels that are being serviced...not quite the same thing..
I'll send a copy of this one to Bill and Lynne...I think they should know
what is really happening.
-Guido