gt;>> tick .. 1367513 ns
>>> >>> keystone_get_time: 168: kt->hw->intctlstat 0x1
>>> >>> tick .. 743185 ns
>>> >>> keystone_get_time: 168: kt->hw->intctlstat 0x3
>>> >>> ..
>>> >>> keystone_handle_irq: 177: kt->hw->intctlstat current status 0x3
>>> >>> (called manually by sel4_timer_handle_single_irq)
>>> >>> keystone_handle_irq: 179: kt->hw->intctlstat clear 0x1
>>> >>> keystone_get_time: 168: kt->hw->intctlstat 0x1
>>> >>> tick .. 17540752 ns
>>> >>> keystone_get_time: 168: kt->hw->intctlstat 0x1
>>> >>> ..
>>> >>> keystone_get_time: 168: kt->hw->intctlstat 0x3
>>> >>> tick .. 1056723 ns
>>> >>> keystone_get_time: 168: kt->hw->intctlstat 0x3
>>> >>> tick .. 2371025 ns
>>> >>> 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 +, 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
--
WBR, Wladislav WIebe
___
Devel mailing list
Devel@sel4.systems
https://sel4.systems/lists/listinfo/devel
