in the name of zero

January 19, 2008

tying the 8259A pic to the ISRs

Filed under: hermetic studies

after i8259.c::init_IRQ() initializes the interrupt controller, it begins to
setup the interrupt descriptor table with it’s predefined ISR locations like so:

for (i = 0; i < (NR_VECTORS - FIRST_EXTERNAL_VECTOR); i++) {
	int vector = FIRST_EXTERNAL_VECTOR + i;
	if (i >= NR_IRQS)
		break;
	if (vector != SYSCALL_VECTOR)
		set_intr_gate(vector, interrupt[i]);
}

declared at hw_irq.h but defined and initialized via assembler constructs at entry.S, interrupt[] is an
array of ISR function pointers (to section irq_entries_start) that linux uses. i
removed the dwarf macros for clarity.

ENTRY(interrupt) interrupt[] address is in a .data section
.text
	
vector=0
ENTRY(irq_entries_start) // create a section called irq_entries_start in .text
.rept NR_IRQS
        ALIGN
1:      pushl $~(vector)	// save IRQ number, ~pt_regs->orig_eax
        jmp common_interrupt    // jump to common IRQ handling code
.data // now, back in our interrupt[] array at the .data section
        .long 1b		// place address of stub \"1\" in interrupt[i]
.text
vector=vector+1
.endr

then, common_interrupt is the one responsible for calling do_IRQ() which
will bring us back to the land of C. irq numbers are being passed in their two’s
complement form also.

putting it all together, the linux interrupt api

note: so this is basically intel 8259 pic specific.

in arch/i386/kernel/i8259.c, we could see a descriptor for the interrupt
controller being defined like so:

static struct irq_chip i8259A_chip = {
        .name           = "XT-PIC",		/* name used in /proc/interrupts */
        .mask           = disable_8259A_irq,	/* mask an interrupt source */
        .unmask         = enable_8259A_irq,	/* unmask an interrupt source */
        .mask_ack       = mask_and_ack_8259A, 	/* ack and mask an interrupt source */
};

struct irq_chip is defined at irq.h, there is a definitive explanation for each structure member there too. then, we also have the irq_desc structure which is a descriptor for each irq. it is also defined at irq.h. linux has a global array of irq_descriptor for the number of irqs defined by NR_IRQS. to get the descriptor for a specific irq is simply just a matter of adding an irqs interrupt number to get to the correct index in the irq_descriptor array.

disable_8259A() constructs a valid mask for the irq in question then checks to see if this irq is greater than 8. if it is, the mask is written to the slave pic, else, the mask is written to the master pic - remembering that irq 9-16 in the slave pic are cascaded to irq2 in the master pic.

enable_8259A() also follows the same pattern but it instead takes the one’s complement to turn on an interrupt bit.

mask_and_ack_8259A() sends a specific End Of Interrupt to the master PIC, or if irq > 8 to both the slave pic and the master pic in that order.

linux can tie a particular irq to the specific programmable interrupt controller with a specific interrupt code handler that would service the irq in question. in this writeup, linux assigns the first 16 interrupts to the i8529 pic with handle_level_irq() as the handler for them all.

we can see linux in action, setting the irq_descriptors and assigning the first 16 predefined irq to the intel 8259 pic in arch/i386/kernel/i8259.c::init_ISA_irqs(). specifically, in the following snippet:

for (i = 0; i < NR_IRQS; i++) {
	irq_desc[i].status = IRQ_DISABLED;
        irq_desc[i].action = NULL;
        irq_desc[i].depth = 1;
	
        if (i < 16) {
                 set_irq_chip_and_handler_name(i, &i8259A_chip,
                                               handle_level_irq, "XT");
	...
}

set_irq_chip_and_handler() is a wrapper to two functions, set_irq_chip() and __set_irq_handler(). the job of set_irq_chip() is to tie an irq descriptor to a specific interrupt chip and the job of __set_irq_handler() is simply to assign a handler to service the irq by assigning the handler address to the descriptor’s “handle_irq” member.

generic irq flow handlers:

handle_simple_irq
handle_level_irq
handle_edge_irq
handle_per_cpu_irq

they differ, primarly in how they handle an interrupt and successive interrupts
that happen at service time. all of the handlers eventually transfer control to
handle_IRQ_event() which will take
care of calling the list of irq action service routines.

[ installing irq action handlers ]

following irq/handle.c::handle_IRQ_event(), we could see it entering a
do-while() calling the handler of each action and then move to the next action
in the action list like so:

irqreturn_t handle_IRQ_event(unsigned int irq, struct irqaction *action)
{
        ...
	do {
        	ret = action->handler(irq, action->dev_id);
                if (ret == IRQ_HANDLED)
                        status |= action->flags;
                retval |= ret;
                action = action->next;
        } while (action);
	...
}

the function responsible for installing these irq actions is found at irq/manage.c::setup_irq(). this function also registers an irq entry in /proc for the irq and it’s associated handler.

	...
	
                /* add new interrupt at end of irq queue */
                do {
                        p = &old->next;
                        old = *p;
                } while (old);
                shared = 1;
        }
	
        *p = new;
	
	...

struct irqaction is defined in interrupt.h as:

typedef irqreturn_t (*irq_handler_t)(int, void *);

struct irqaction {
        irq_handler_t handler;
        unsigned long flags;
        cpumask_t mask;
        const char *name;
        void *dev_id;
        struct irqaction *next;
        int irq;
        struct proc_dir_entry *dir;
};

going back to my original goal which is to understand how linux generates clock
ticks to make the scheduler work, i come upon mach-default/setup.c::time_init_hook() where the kernel installs an irqaction handler for irq0 - the timer interrupt.

static struct irqaction irq0 = { timer_interrupt, IRQF_DISABLED, CPU_MASK_NONE, “timer”, NULL, NULL};

void __init time_init_hook(void)
{
        setup_irq(0, &irq0);
}

that’s it for now, it’s time for me to enjoy my weekend.

January 12, 2008

understanding how linux initializes the PIC

Filed under: hermetic studies

i started out trying to understand how the scheduler works, but had to get some
more details in check, the first of which is how linux generates frequent clock
ticks, which brought me to do a refresher to understand how linux programs the
intel 8259A PIC.

the defines being used are at:

arch/i386/mach-generic/io_ports.h
kernel/i8259.c :: void init_8259A(int auto_eoi)

the first piece of code i understood to be an OCW1 trying to mask all the interrupts in both the master and slave interrupt controller by setting all bits
to a ‘1′.

the weird thing is that these two OCWs are issued before any ICWs.. but i may still be missing something here.

outb(0xff, PIC_MASTER_IMR);
outb(0xff, PIC_SLAVE_IMR);

how does this work? well, at io_ports.h, the address of the master PIC is defined as PIC_MASTER_CMD 0x20 and the interrupt mask register
is defined as PIC_MASTER_IMR 0x21, the increment is used so that the A0 line will be a ‘1′ in order for certain ICWs or OCWs that require A0=1 to
work.

OCW1 looks like this:

a0 | d7 | d6 | d5 | d4 | d3 | d2 | d1 | d0
1  | m7 | m6 | m5 | m4 | m3 | m2 | m1 | m0

[ linux master pic init ]

1) outb_p(0x11, PIC_MASTER_CMD); /* ICW1: select 8259A-1 init */
2) outb_p(0x20 + 0, PIC_MASTER_IMR); /* ICW2: 8259A-1 IR0-7 mapped to 0x20-0x27 */
3) outb_p(1U << PIC_CASCADE_IR, PIC_MASTER_IMR); /* 8259A-1 (the master) has a slave on IR2 */

line 1, “outb_p(0x11, PIC_MASTER_CMD)”, sends the initialization command word one to the master pic.
PIC_MASTER_CMD is defined to be 0x20, making a0=0.

the format of the ICW1 looks like:

a0 | d7 | d6 | d5 | d4 | d3   | d2  | d1   | d0
0  | a7 | a6 | a5 | 1  | LTIM | ADI | SNGL | IC4

a7-a5: corresponds to the interrupt vector address if MCS 80/85 mode only
LTIM : 1 = level triggered mode, 0 = edge triggered mode (interrupt polarity)
ADI : 1 = call address interval is 4, 0 = call address interval is 8
SNGL : 1 = single PIC, 0 = cascaded mode (multiple pics, ICW3 will be issued?)
IC4 : 1 = ICW4 will be needed, 0 = otherwise

ICW1 is determined by a0=0 and d4=1 as specified in the above table.

the 0x11 in conjuction with PIC_MASTER_CMD means:
1) master pic operates in edge triggered mode (LTIM=0)
2) ADI is ignored on 8086 mode
3) master pic cascades with another pic (SNGL=0)
4) intialization control word 4 will be issued.

line 2, “outb_p(0x20 + 0, PIC_MASTER_IMR)”, remaps the vector table address to
0x20.

the format of the ICW2 looks like:

a0 | d7 | d6 | d5 | d4 | d3 | d2  | d1 | d0
1  | t7 | t6 | t5 | t4 | t3 | a10 | a9 | a8

and as further detail, the data sheet also presents the contents of the
interrupt vector byte for 8086 system mode.

    D7 D6 D5 D4 D3 D2 D1 D0
IR7 T7 T6 T5 T4 T3 1  1  1
IR6 T7 T6 T5 T4 T3 1  1  0
IR5 T7 T6 T5 T4 T3 1  0  1
IR4 T7 T6 T5 T4 T3 1  0  0
IR3 T7 T6 T5 T4 T3 0  1  1
IR2 T7 T6 T5 T4 T3 0  1  0
IR1 T7 T6 T5 T4 T3 0  0  1
IR0 T7 T6 T5 T4 T3 0  0  0

so if we map the new vector to 0x20, irq0 = 0x20, irq1 = 0x21 … irq7 = 0x27

line 3, “outb_p(1U > > PIC_CASCADE_IR, PIC_MASTER_IMR)”, initializes an interrupt
line to a slave device, specifically, irq2.

a0 | d7 | d6 | d5 | d4 | d3 | d2 | d1 | d0
1  | s7 | s6 | s5 | s4 | s3 | s2 | s1 | s0

PIC_CASCADE_IR is defined as 2, making (1U< d2=1, specifying that irq2 is connected to a slave device.

then, the kernel sets if master pic is auto end of interrupt or normal end of
interrupt via ICW4 thru:

if (auto_eoi) /* master does Auto EOI */
outb_p(MASTER_ICW4_DEFAULT | PIC_ICW4_AEOI, PIC_MASTER_IMR);
else /* master expects normal EOI */
outb_p(MASTER_ICW4_DEFAULT, PIC_MASTER_IMR);

after initializes the master pic, it then initializes the slave pic, the code
pretty much follows the same logic, except that setting ICW3 for the slave
device is simply just a matter of specifying the slave id connected to the
specific irq that was set in the ICW3 of the master pic. 0x2 in this case which
is actually the value of PIC_CASCADE_IR.

the next hurdle will be to study how linux registers the intel 8259A chip as an
interrupt source for each irq line. keywords include irq_desc and irq_chip.

references:
[1] intel 8259A programmable interrupt controller datasheet.

Get free blog up and running in minutes with Blogsome | Theme designs available here