[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: device matching at mainbus
On Wed, 16 Jan 2013, Holm Tiffe wrote:
I'm simply don't undestand the relationship between the IPL, the vector
and the address of the service routine.
There is no fixed relationship.
Did you ment I can do an scb_vecalloc this way:
I mean nothing. As I have said, I have never done NetBSD kernel work; I
don't know how it works. I can, however, talk about how the hardware
works and how VMS does things. But remember that it's been several years
since I last did any VAX/VMS kernel work; I'm all about Alpha and
Itanium these days.
scb_vecalloc(0x2c0, (void (*)(void *)) scnintr, sc,
Beats me. Looks reasonable based on what you present below. I'm not
a NetBSD kernel person.
scb_vecalloc(int vecno, void (*func)(void *), void *arg,
int stack, struct evcnt *ev)
struct ivec_dsp *dsp = &scb_vec[vecno / 4];
Somewhere, there is a small piece of assembly code. This code is the
*real* interrupt service routine; it does the following:
- Saves some registers.
- Calls your device driver's interrupt routine
- Restores the registers it saved.
- Returns from interrupt.
This piece of code tells me that there is an array of these primitive
interrupt handlers named scb_vec.
dsp->hoppaddr = func;
dsp->pushlarg = arg;
These statements fill in the arguments to the assembly instructions in
the primitive interrupt service routines so that they call your
interrupt service routine, passing the argument you specify.
dsp->ev = ev;
Alright, the primitive interrupt service routine apparently also
increments a counter. This fills in the argument of the assembly
instruction that gives the address of the counter.
((intptr_t *) scb)[vecno/4] = (intptr_t)(dsp) | stack;
This puts the address of the primitive interrupt service routine into
the actual vector table; the | stack includes bits that tell the
processor which stack to use (the primitive interrupt service routine
must be aligned so that there are a couple of bits in the address that
are always zero; these are used to specify the stack).
..that would allocate an vector entry at offset 0x2c0 in that table... and
the CPU is reading this vector when its IRQ0 is triggered?
Kind of. The CPU is reading this vector because the console placed it on
the bus when it completed the IACK. Another device at the same IPL could
put a different vector on the bus.
But since there are more vectors at that IPL14 how distinguishes the cpu
which vector to use?
When a device asserts IRQ0, the processor:
- Raises IPL to 14.
- Issues an IACK transaction on the bus.
The devices attached to IRQ0 see the IACK and decide which of them is
the highest priority. Usually, there is a daisy chain so that the device
closest to the processor has priority (for IPL15, the daisy chain goes
through the SGEC before it gets off the rtVAX 300; the SGEC is the
highest priority IPL15 device because it is closest to the CPU).
Whichever device is the highest priority places its vector on the bus
and completes the IACK transaction. The processor uses the vector to
find the address of the primitive interrupt service routine in the
on the other side I've read that the VAX isn't doing this as
opposite to a PDP11..
I don't understand this sentence.
Main Index |
Thread Index |