RPI2 Timers and interrupts

[timanu90]

Hi guys.

I am fighting timers and interrupts now. I have ARM timer running and interrupting at core 0, but I need one timer generate an interrupt for each core.
By the document QA7 this seems to be possible but, I don't understand how that timer works. I tried some things but it didn't work.

Anyone have any clue how that timers works that can enlighten me.

Cheers
Tiago

[Ultibo]

Hi Tiago,

By the document QA7 this seems to be possible but, I don't understand how that timer works

The other timers that the QA7 document refers to are the Generic Timers which are per core, you can find some information in this post viewtopic.php?t=135121&p=922616 about how to use them.

The most important thing to know (that isn't mentioned in QA7) is that you need the ARM Architecture Reference for the ARMv7-A to find the information about programming these timers.

[timanu90]

Hi ultibo thank you for the guide. I read that chapter but i think those timers do the purpose I need. My idea is to make system tymer or ARM timer and on this timer interrupt on core 0 write on mailboxes and interrupt other cores. I will try this approach when i get home.

Another thing if some1 know. I can't find a way to know wich interrupt fired. For example if I have uart and timer irq how i can know which one am I servicing?

Cheers
Tiago

[rst]

I can't find a way to know wich interrupt fired. For example if I have uart and timer irq how i can know which one am I servicing?

Have a look at this document (page 109). The base address of the interrupt controller on the RPi 2 is 0x3F00B000. You have to check the 3 pending registers to know, which interrupt(s) is/are pending.

The interrupt assignments are here. This is for the RPi 1 but should still be valid for the RPi 2 and 3.

[timanu90]

Hi rst.

The problem of read registers is i can't know the order in what the pending bits were set right? Imagine, I execute a small portion of code with IRQ disabled, in that time UART and Timer generate an interrupt, I don't have a away to know the order in which the interrupts were generated, or is something missing in thought?

The second link I didn't knew, thank you, it's very useful. Maybe I make a small function to schedule IRQS in irq_handler.

Cheers
Tiago

[rst]

The information, when an interrupt occurred, is normally not available.

You have to apply some priority scheme on the pending interrupts. This can be simple, e.g. take the first interrupt source by number which is pending, and then the next, and so on until all pending interrupt sources have been handled.

Or more sophisticated, with different priorities assigned to specific interrupt sources. It depends on your bare metal application, if the more sophisticated solution makes sense.

[timanu90]

This can be simple, e.g. take the first interrupt source by number which is pending, and then the next, and so on until all pending interrupt sources have been handled.

I was thinking on something similar to that. But i already tested and I have a problem. The IRQ pending registers on interrupt controller after the interrupt started seems to be cleared by hardware. First thing I am doing is read the 3 register (0x3f00b000, 0x3f00b004, 0x3f00b008) at the start of irq_handler all return 0. (checked twice for errors hope I am not wrong xD).

With this I need to check the pending bit on device register and not on interrupt controller. For that I have to do some kind of list of active interrupts and check the pending bit on the device register.

[rst]

First thing I am doing is read the 3 register (0x3f00b000, 0x3f00b004, 0x3f00b008) at the start of irq_handler all return 0. (checked twice for errors hope I am not wrong xD).

Oops. When I wrote the base address of the interrupt controller is 0x3F00B000, I had the register list on page 112 of that Peripherals document in mind, where is defined:

Offset Register
0x200 IRQ basic pending
0x204 IRQ pending 1
0x208 IRQ pending 2

So you have to add 0x200 to your register addresses. I hope it will work then.

[timanu90]

I had the 0x200 offset copied and paste here wrongly sorry.

Code: Select all

kprint("pend1 = %d\tpend2 = %d\tpendbase = %d\n\r", arch_get((T_UINT32*)0x3F00B208), arch_get((T_UINT32*)0x3F00B200), arch_get((T_UINT32*)0x3F00B204));

Thats the code i am using.

[rst]

OK, so the addresses were right. The pending bits in that pending registers will be reset automatically, when the interrupt condition is cleared on the relating device.

That means if you have enabled an IRQ for a device in one of the IRQ enable registers and you get that IRQ, the pending bit for that device is set, until you clear the condition on the device. Anything else is not normal.

[rst]

One thing to add: Interrupts, which are local to a specific core of the RPi 2, will not be reported in the pending registers of the interrupt controller, which was introduced with the BCM2835 (RPi 1) and about which I was talking.

Instead there are separate registers which are described in the QA7 document. This was mentioned earlier in this topic. Have a look at page 16 of this document.

[timanu90]

You are right, I recheck the code and indeed he ARM timer report on IRQ basic pending register from interrupt controller, but the mailboxes don't, which is a bit strange because there is one bit on IRQ basic pending register for mailboxes.

I am going to try enable the mini uart rx interrupt and see what it reports.

Tiago

[Gert van Loo]

I am going to try enable the mini uart rx interrupt and see what it reports.

The Pi system has two independent sets of interrupts.
The ones local to the QA7 and ones to the VC.
Important is the diagram on page 4 of the below mentioned document.
Thus your mini uart rx interrupt is normally not visible to the ARM core.
Looking at that document I realise that I have omitted a pointer to the old ARM local control document which
tells about the 64 interrupts from the GPU from which you can select two (IRQ and FIQ) to go to the Quad A7 interrupt controller.
(Originally these went to the A1176 IRQ and FIQ pins)
So you CAN see the mini uart rx interrupt if it is routed from the GPU to the ARM.
Having said that I would not be surprised if the GPU->ARM interrupts are already used by the OS guys for some interprocessor communication.
Sorry it is a long time since I wrote that code and I can't remember much of it any more.

[timanu90]

Update.

I managed to enable the mini uart interrupts and is like I said in last post. Only the mail boxes I can't get the status. It's quite a strange interrupt controller xD. But it is what we have.

Tiago

[Gert van Loo]

There is still some confusion which is not helped by the gaps in documentation.
There are two sets of logic.
There is the old logic pre-Pi2 with the A1176 core.
There is new logic from Pi2 with the Quad A7 cores.
Thus the old ARM logic has timers, mailboxes and doorbells.
Section 7 of the BCM2835 manual says:
The ARM specific interrupts are:
• One timer.
• One Mailbox.
• Two Doorbells.
• Two GPU halted interrupts.
• Two Address/access error interrupt
The Mailbox and Doorbell registers are not for general usage

The mailbox interrupt in the basic pending register is from THAT mailbox. Not from the mailboxes mentioned in the QA7 document. To see an interrupt from the QA7 mailboxes you have to look at bits 4-7 of the core interrupt source registers as specified in section 4.1 of the QA7 document.
The guy who wrote all those ARM QA7 etc.documents should have put on paper the combined old and new logic
but due to time pressure he did not. And he knew the system inside out so though it obvious how it all works.

[rst]

I managed to enable the mini uart interrupts and is like I said in last post. Only the mail boxes I can't get the status.

So it is working now. That's good. I wouldn't care about that mailbox interrupt status. I think nobody is using these BCM2835 mailboxes with interrupts in bare metal programming.

It's quite a strange interrupt controller xD. But it is what we have.

I don't find it "strange". I think its design is the logical consequence of the requirement to be compatible with the previous RPi models.

The good thing is, that you do not need to care about the extensions of the interrupt controller, which were introduced with the RPi 2, as long you only work on core 0. The "old" 64 interrupt sources which come from the GPU are routed to core 0 by default, so most bare metal applications from the RPi 1 can work with interrupts without changes.

Because you started using multi-core relatively early, you did "run" into the more complex interrupt controller of the RPi 2. I think the easier way is, to get familiar with interrupts on core 0 first and to "go multi-core" later.

[mm314]

Hi,

I am facing a similar problem, I want to use the local timer (section 4.11 at https://www.raspberrypi.org/documentati ... rev3.4.pdf ) however the request_irq is failing each time I request for the irq (maybe I am using the wrong irq number) and I always got the "unexpected IRQ trap at vector 00" message when the timer interrupt get fired.

Is it possible to use the local timer (and its interrupt) using the current interrupt controller driver? Any help will be really appreciated.

Regards

[timanu90]

Hi mm314. it is possible to use the timer. But for me I had to check if the timer fired the interrupt by checking the timer status register, instead of looking for the interrupt controller one.

Cheers
Tiago

[mm314]

Hi Tiago,

Thanks for the response, yes actually I tested it with devmem as an initial step and got it working, however it is becoming a little bit tricky to get the interrupt installed and working, all I get is the "unexpected IRQ trap at vector 00" message o likely I am installing the interrupt in the wrong way or it is not supported by the interrupt controller. I will keep trying it and keep you posted with any update.

Thanks all!