TeamForge : Post

Forum Topic - MIPS BSP interrupt callout:

View: as

David Alessio(deleted)

10/23/2007 3:25 PM

post2234

Hello,

I'm writing the interrupt callout for a MIPS BSP.  I noticed that in most of the library examples the interrupt 
controller base address is located in kseg1.  For my platform, the base address is in kseg3 (0xff1f0000).

When I try to read the interrupt controller registers in the callout code, I get a data bus error exception (EC=7).

Is there some other info I have to initialize in startup to get access to registers located in kseg3?

Thanks,
David

Colin Burgess(deleted)

10/23/2007 3:42 PM

post2236

Re: MIPS BSP interrupt callout

It's probably not really KSEG3 - it's more likely a physical address 
that overlaps with the KSEG3 virtual address range (remember
that KSEG3 is a mapped range - ie it goes through the TLB)

So you will need to setup a TLB to access this controller - checkout the 
callout_*_map functions.  They will make a mapping
that persists after startup is completed.

David Alessio wrote:
>
> Hello,
>
> I'm writing the interrupt callout for a MIPS BSP.  I noticed that in 
> most of the library examples the interrupt controller base address is 
> located in kseg1.  For my platform, the base address is in kseg3 
> (0xff1f0000).
>
> When I try to read the interrupt controller registers in the callout 
> code, I get a data bus error exception (EC=7).
>
> Is there some other info I have to initialize in startup to get access 
> to registers located in kseg3?
>
> Thanks,
> David
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post2234
>

-- 
cburgess@qnx.com

David Alessio(deleted)

10/31/2007 10:00 PM

post2368

Re: MIPS BSP interrupt callout

Thanks for the reply.  I have another interrupt callout related question.

When implementing cascaded interrupts (NOT nested) I noticed that the first level completes an "ID/EOI" cycle before 
cascading to the next level.

For example, consider two interrupt controllers called "INTA" and "INTB". INTB is cascaded from one of INTA's external 
interrupts.

An interrupt sourced from INTB occurs.  Here's the order in which I expected the callouts to run:

1. INTA id
2. INTB id
... service interrupt ...
3. INTB eoi
4. INTA eoi

Here's the actual order I observed the callouts run:

1. INTA id
2. INTA eoi
3. INTB id
... service interrupt ...
4. INTB eoi

The problem is the real source of the interrupt (from INTB) is not cleared yet (in INTB's id callout) before INTA's eoi 
unmasks it's own interrupt.  So inbetween INTA's eoi and INTB's id callout, another interrupt is latched (but not 
triggered until INTB enters it's service routine).

1. INTA id 
2. INTA eoi
3. INTB id
... trigger another interrupt ...
4. INTA id
5. INTA eoi
6. INTB id
... trigger another interrupt ...


How do I avoid this problem when implementing cascaded interrupts?

Return