Hi Alex,
yes, you are right -- seems interrupt 27 is the virtual timer based on
GIC 400 specification.
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0471b/DDI0471B_gic400_r0p1_trm.pdf
May I will try to loop through all interrupts > 31 (after the PPI's)..
Thanks!
- Wladi
2017-02-26 12:58 GMT+01:00 <alexander.k...@data61.csiro.au>:
> Hi Wladi,
>
> I am sorry to say that IRQ 27 might be the IRQ of the preemption timer
> that the kernel uses. If not, it should at least be the IRQ of the ARM
> private timers rather than a third-party peripheral.
>
> That being said, some vendors don't like to follow standards.
>
> Do you receive the 'Tick' even if you don't set the enable bit on your
> timer?
> Have you checked that the timer status bit is actually being asserted?
>
> - Alex
>
> On Sun, 2017-02-26 at 11:58 +0100, Wladislav Wiebe wrote:
>> Hi Alex,
>>
>> I've found the magic IRQ number -> 27.
>>
>> Starting test suite sel4test
>> Starting test 0: TEST_INTERRUPT0001
>> TEST_INTERRUPT0001
>> Running test INTERRUPT0001 (Test interrupts with timer)
>> Tick
>> Tick
>> Tick
>> Test INTERRUPT0001 passed
>> Starting test 1: TEST_INTERRUPT00012
>> TEST_INTERRUPT0001
>> Running test INTERRUPT0001 (Test interrupts with timer)
>> Tick
>> Tick
>> Tick
>> Test INTERRUPT0001 passed
>> Test suite passed. 2 tests passed.
>>
>> 2/2 tests passed.
>> All is well in the universe.
>>
>>
>> Special thanks again for the great support!
>>
>> - Wladi
>>
>>
>>
>>
>>
>> 2017-02-24 11:50 GMT+01:00 Wladislav Wiebe <wladislav...@gmail.com>:
>> > Hi Alex,
>> >
>> > really great catch! When I am disabling interrupt 27 and 57 in
>> > maskInterrupt
>> > and keeping everything else enabled, like:
>> > switch (irq) {
>> > case 27: dist_enable_clr(irq); break;
>> > case 57: dist_enable_clr(irq); break;
>> > default: dist_enable_set(irq); break;
>> > }
>> >
>> > I can see spurious interrupts from interrupt number 48
>> > each second (depends on timer_periodic(env->timer->timer, 1 *
>> > NS_IN_S);) setting.
>> >
>> > ..
>> > Starting test suite sel4test
>> > Starting test 0: TEST_INTERRUPT0001
>> > TEST_INTERRUPT0001
>> > Timer initialised
>> > Running test INTERRUPT0001 (Test interrupts with timer)
>> > <<seL4(CPU 0) [handleInterruptEntry/48 T0xffdfaf00 "" @e001086c]:
>> > Spurious interrupt!>>
>> > <<seL4(CPU 0) [handleInterruptEntry/48 T0xffdfaf00 "" @e001086c]:
>> > Spurious interrupt!>>
>> > <<seL4(CPU 0) [handleInterruptEntry/48 T0xffdfaf00 "" @e001086c]:
>> > Spurious interrupt!>>
>> > ..
>> >
>> > But for some reason, even when configuring the timer interrupt to nr. 48,
>> > (in the kernel machine.h and userspace timer)
>> > the interrupt handler doesn't get called and keeps firing spurious
>> > interrupts.
>> >
>> > Let me know if you have an idea for this as well :-)
>> >
>> > Thanks a lot!
>> > - Wladi
>> >
>> > 2017-02-24 0:21 GMT+01:00 <alexander.k...@data61.csiro.au>:
>> >> Hi Wladi,
>> >>
>> >> Another problem could be that you are using the wrong IRQ number. The
>> >> GIC handles two classes of IRQ: PPI and SPI. There are 32 PPIs. To
>> >> ensure that each IRQ number is unique we offset each SPI by 32.
>> >>
>> >> The reported SPI IRQ number in technical manuals is not always
>> >> consistent. Sometimes the SPI IRQ number is reported, sometimes this
>> >> offset in included, and sometimes both IRQ numbering systems are
>> >> reported.
>> >>
>> >> As a catch all, you could prevent seL4 from disabling some (or all) IRQs
>> >> by modifying this function:
>> >> https://github.com/seL4/seL4/blob/master/include/arch/arm/arch/machine/gic_pl390.h#L191
>> >>
>> >> The catch is that this might trigger other IRQs that you aren't
>> >> expecting, so watch out for false positives.
>> >>
>> >> - Alex
>> >>
>> >>
>> >> On Wed, 2017-02-22 at 16:13 +0100, Wladislav Wiebe wrote:
>> >>> Hi Anna and Alex,
>> >>>
>> >>> thanks a lot for your inputs --
>> >>>
>> >>> Anna,
>> >>> > you can put a printf in handleInterrupt in the kernel
>> >>> I added it there and it seems there no interrupt executed at all.
>> >>>
>> >>> Alex,
>> >>> > 1) ARM devices tend to only support 32bit read/write
>> >>> > 2) Check that the interrupt enable flag is set before returning from
>> >>> > your timer set up code.
>> >>>
>> >>> it's done here:
>> >>> https://github.com/wwladikw/devel/blob/master/timer.c#L87
>> >>> which is called in driver init, before timer gets configured:
>> >>> https://github.com/wwladikw/devel/blob/master/timer.c#L220
>> >>>
>> >>> > 3) The status bits must be written as 1 to clear. If interrupts are
>> >>> > edge
>> >>> > triggered, failing to clear this bit (by writing a 1 to it) will stop
>> >>> > interrupts from coming in.
>> >>>
>> >>> yes, the interrupts are edge triggered for my understanding.
>> >>>
>> >>> > 4) Check that your code that clears the interrupt status bit does not
>> >>> > clear the enable bit.
>> >>>
>> >>> it's done when configuring the timer
>> >>> https://github.com/wwladikw/devel/blob/master/timer.c#L138
>> >>> and in the IRQ handler
>> >>> https://github.com/wwladikw/devel/blob/master/timer.c#L173
>> >>> where INTCTLSTAT_ACK_MASK is 0x03 which keeps the interrupts enabled
>> >>> and clears the status bit.
>> >>>
>> >>> I've also extended the driver and the testcase with some debug prints to
>> >>> track the status info for the intctlstat register - like:
>> >>> ------
>> >>> timer_start(env->timer->timer);
>> >>> timer_periodic(env->timer->timer, 100 * NS_IN_MS);
>> >>> while (timeout > 0) {
>> >>> printf("tick .. %llu ns \n",
>> >>> timer_get_time(env->timer->timer));
>> >>> if (timeout == 45)
>> >>> sel4_timer_handle_single_irq(env->timer);
>> >>> timeout--;
>> >>> }
>> >>> for (int i = 0; i < 3; i++) {
>> >>> wait_for_timer_interrupt(env);
>> >>> printf("Tick\n");
>> >>> }
>> >>> ----
>> >>>
>> >>> output: (XXXX comes from the driver)
>> >>> -------
>> >>> Starting test suite sel4test
>> >>> Starting test 0: TEST_INTERRUPT0001
>> >>> TEST_INTERRUPT0001
>> >>> XXXX keystone_timer_reset: 73: kt->hw->intctlstat init 0x0
>> >>> XXXX keystone_timer_reset: 88: kt->hw->intctlstat done 0x1
>> >>> Running test INTERRUPT0001 (Test interrupts with timer)
>> >>> timer_start ..
>> >>> timer_start done ..
>> >>> set timer_periodic ..
>> >>> XXXX keystone_set_timeo: 138: kt->hw->intctlstat 0x3
>> >>> XXXX keystone_set_timeo: 141: kt->hw->intctlstat 0x1
>> >>> XXXX keystone_set_timeo: 142: enable timer
>> >>> set timer_periodic done ..
>> >>> XXXX keystone_get_time: 168: kt->hw->intctlstat 0x1
>> >>> tick .. 1367513 ns
>> >>> XXXX keystone_get_time: 168: kt->hw->intctlstat 0x1
>> >>> tick .. 743185 ns
>> >>> XXXX keystone_get_time: 168: kt->hw->intctlstat 0x3
>> >>> ..
>> >>> XXXX keystone_handle_irq: 177: kt->hw->intctlstat current status 0x3
>> >>> (called manually by sel4_timer_handle_single_irq)
>> >>> XXXX keystone_handle_irq: 179: kt->hw->intctlstat clear 0x1
>> >>> XXXX keystone_get_time: 168: kt->hw->intctlstat 0x1
>> >>> tick .. 17540752 ns
>> >>> XXXX keystone_get_time: 168: kt->hw->intctlstat 0x1
>> >>> ..
>> >>> XXXX keystone_get_time: 168: kt->hw->intctlstat 0x3
>> >>> tick .. 1056723 ns
>> >>> XXXX keystone_get_time: 168: kt->hw->intctlstat 0x3
>> >>> tick .. 2371025 ns
>> >>> XXXX keystone_get_time: 168: kt->hw->intctlstat 0x3
>> >>> tick .. 3685205 ns
>> >>> ----------
>> >>> and stays forever in wait_for_timer_interrupt.
>> >>>
>> >>> I also wonder about a short flood of messages before the testsuite
>> >>> starts:
>> >>> ---
>> >>> _allocman_utspace_alloc@allocman.c:301 Regular utspace alloc failed
>> >>> and not watermark for size 13 type 0
>> >>> vka_alloc_object_at@object.h:57 Failed to allocate object of size 8192,
>> >>> error 1
>> >>> ---
>> >>> But I guess this shouldn't have impact to the interrupts, right?
>> >>>
>> >>>
>> >>> Thanks in advance!
>> >>> - Wladi
>> >>>
>> >>> 2017-02-22 1:32 GMT+01:00 <alexander.k...@data61.csiro.au>:
>> >>> > Hi Wladi,
>> >>> >
>> >>> > If the problem is with your driver, the problem could be in your
>> >>> > management of the INTCTLSTAT register (Chapter 5.10).
>> >>> >
>> >>> > 1) ARM devices tend to only support 32bit read/write
>> >>> > 2) Check that the interrupt enable flag is set before returning from
>> >>> > your timer set up code.
>> >>> > 3) The status bits must be written as 1 to clear. If interrupts are
>> >>> > edge
>> >>> > triggered, failing to clear this bit (by writing a 1 to it) will stop
>> >>> > interrupts from coming in.
>> >>> > 4) Check that your code that clears the interrupt status bit does not
>> >>> > clear the enable bit.
>> >>> >
>> >>> > - Alex Kroh
>> >>> >
>> >>> >
>> >>> > On Tue, 2017-02-21 at 23:17 +0000, anna.ly...@data61.csiro.au wrote:
>> >>> >> Hey,
>> >>> >>
>> >>> >> First I'd check if the kernel is getting the interrupts in the kernel
>> >>> >> from this timer - you can put a printf in handleInterrupt in the
>> >>> >> kernel to see if this is the case and see if the correct interrupt
>> >>> >> number comes in.
>> >>> >>
>> >>> >> If so, then check if those irqs are being sent to the signal handler
>> >>> >> and not reserved (again by printing / asserting in handle interrupt).
>> >>> >>
>> >>> >> If not, this points to a problem with your driver.
>> >>> >>
>> >>> >> Hope this pushes you in the right direction,
>> >>> >> Anna.
>> >>> >>
>> >>> >> -----Original Message-----
>> >>> >> From: Devel [mailto:devel-bounces@sel4.systems] On Behalf Of
>> >>> >> Wladislav Wiebe
>> >>> >> Sent: Wednesday, 22 February 2017 10:05 AM
>> >>> >> To: devel@sel4.systems
>> >>> >> Subject: [seL4] ARM timer driver and interrupts
>> >>> >>
>> >>> >> Hello,
>> >>> >>
>> >>> >> I wrote a new timer driver for this timer device:
>> >>> >> http://www.ti.com/lit/ug/sprugv5a/sprugv5a.pdf
>> >>> >>
>> >>> >> I am already able to run the seL4 testsuite successfully, except the
>> >>> >> interrupt/timer tests.
>> >>> >> It waits forever @ wait_for_timer_interrupt(env);
>> >>> >>
>> >>> >> I've uploaded the driver temporary to:
>> >>> >> https://github.com/wwladikw/devel/blob/master/timer.c
>> >>> >>
>> >>> >> Any idea what could be wrong?
>> >>> >> I am able to run the timer periodically or as oneshot.
>> >>> >> The gic_390 interrupt driver in the kernel should also be compatible
>> >>> >> with the gic_400, for my understanding, right?
>> >>> >> The SoC I am using contains a Coretex A15.
>> >>> >>
>> >>> >> Thanks a lot in advance!
>> >>> >> Wladislav Wiebe
>> >>> >>
>> >>> >> _______________________________________________
>> >>> >> Devel mailing list
>> >>> >> Devel@sel4.systems
>> >>> >> https://sel4.systems/lists/listinfo/devel
>> >>> >>
>> >>> >> _______________________________________________
>> >>> >> Devel mailing list
>> >>> >> Devel@sel4.systems
>> >>> >> https://sel4.systems/lists/listinfo/devel
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>
>> >
>> >
>> >
>> > --
>> > WBR, Wladislav WIebe
>>
>>
>>
>
--
WBR, Wladislav WIebe
_______________________________________________
Devel mailing list
Devel@sel4.systems
https://sel4.systems/lists/listinfo/devel
