SOLVED: ARM IRQ sent from timer, but not received by int-con

[cds84]

Hey guys!

I am targetting the beableboard xM (Corect A8 armv7a) ( mainly bcause it is well supported by the linaro port of Qemu ).
https://github.com/chris-stones/ShovelOS
And I have gotten stuck trying to enable IRQ's.

The ISR base address is correctly set.
Data-aborts, and SWI's are working correctly.

IRQ has been un-masked at the ARM cpu.

The timer has been configured to run in 1-shot mode, and raise an interrupt on overflow.
Reading the timer registers shows that an overflow has occurred, And an IRQ is pending.

The timers interrupt has been unmasked in the interrupt-controller.
The timers interrupt is set to the highest prrority IRQ ( not FIQ ).

However, the IRQ ISR is never executed, and the interrupt controller doesnt seem to be aware than an IRQ is pending.

Im using u-boot to load and run the kernel.

Is there an extra step im missing ??

Thanks for any pointers.

Chris.

[alexfru]

Did you execute the CPU instruction to actually enable external interrupt processing in the CPU? An equivalent of x86's sti?

[cds84]

Thanks for the reply... but i dont think there is such an instruction in ARMv7a??
You just need to un-mask it in the IRQ in the program status register ( unless im being really stupid!? )

which i handle in https://github.com/chris-stones/ShovelO ... register.h

[alexfru]

CPSIE I?

[jayjay]

I've had a quick look through your repo, but don't see where you're setting up the GIC. IRQs on ARM occur through the GIC which in turn signals the IRQ interrupt line. The GIC is responsible for collecting all sources of interrupts and signalling the processor that there is a pending IRQ. It also maintains the priority values of IRQs, and is used to acknowledge and reset IRQ lines.

Without initialising the GIC, IRQs should not fire even if the peripherals is signalling them. This is probably the source of your issues.

[cds84]

I've had a quick look through your repo, but don't see where you're setting up the GIC. IRQs on ARM occur through the GIC which in turn signals the IRQ interrupt line. The GIC is responsible for collecting all sources of interrupts and signalling the processor that there is a pending IRQ. It also maintains the priority values of IRQs, and is used to acknowledge and reset IRQ lines.

Without initialising the GIC, IRQs should not fire even if the peripherals is signalling them. This is probably the source of your issues.

Thanks jayjay.
Again, forgive me if im being stupid, but i dont think the Cortex-A8 implements the GIC.
Looking at the OMAP36XX TRM, there is no mention of the GIC ( which i beleive is optional in armv7a? )

Instead, it mentions an interrupt-controller ( Chapter 12 ).
The omap36xx interrupt controller is responible for masking interrupt lines, setting interrupt priority, and selecting IRQ / FIQ.
Basically, everything the GIC would normally do, minus the multi-core stuff. The beagleboard xM is single core.

The omap36xx interrupt controler driver lives in
https://github.com/chris-stones/ShovelO ... ntroller.c

EDIT:
AGHH! Found it.
I have been fighting this for days, and it turned out to be a stupid mistake!

Code: Select all

static int _unmask(interrupt_controller_itf itf, irq_t irq) {

	if(irq < INTERRUPTS_MAX) {

		struct context * ctx =
			STRUCT_BASE(struct context, interrupt_controller_interface, itf);

		ctx->regs->n[irq/32].INTCPS_MIR_CLEARn = irq % 32; // BUG HERE

		return 0;
	}
	return -1;
}

the 'BUG HERE' line should have been...

Code: Select all

ctx->regs->n[irq/32].INTCPS_MIR_CLEARn = 1<< ( irq % 32 );

Embarrasing.

Thanks again Jayjay... i didnt spot my bug until i tried to exaplin why my code was flawless.

[SpyderTL]

That's usually how my bugs are found as well. I'll be 90% of the way through typing a "Why is this not working" post, and I'll realize that I've completely missed some register or value setting.

Debugging code is an exercise in checking your assumptions, and then checking them again. (This includes checking that the code is ACTUALLY broken... I just spent 2 months trying to figure out why my working code was broken...)

If you are working alone, chances are always 99% that the problem is in your code, and not someone else's.