[Xenomai] Porting xenomai 2.6.3 and ipipe to 3.12 kernel

Gilles Chanteperdrix gilles.chanteperdrix at xenomai.org
Tue Apr 1 00:27:45 CEST 2014


On 04/01/2014 12:11 AM, Gilles Chanteperdrix wrote:
> On 04/01/2014 12:04 AM, Lennart Sorensen wrote:
>> On Mon, Mar 31, 2014 at 05:59:33PM -0400, Lennart Sorensen wrote:
>>> On Mon, Mar 31, 2014 at 05:53:48PM -0400, Lennart Sorensen wrote:
>>>> I am using the xenomai-2.6 git tree (current commit I see is as HEAD is
>>>> 4081e1b032329bf0cc9442f466233d5fc1083fc5).
>>>>
>>>> Doing a git pull I see I am 4 commits behind, and one does sound
>>>> interesting.  I will have to update that.
>>>
>>> Hmm, the interesting patch does the same thing I already did myself to
>>> get it to compile.  I guess that is OK then.
>>
>> Hmm, gdb is being not helpful at all:
>>
>> root at omap5:/mnt/xenomai-2.6.3# gdb /usr/lib/xenomai/testsuite/latency 
>> GNU gdb (GDB) 7.4.1-debian
>> Copyright (C) 2012 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "arm-linux-gnueabihf".
>> For bug reporting instructions, please see:
>> <http://www.gnu.org/software/gdb/bugs/>...
>> Reading symbols from /usr/lib/xenomai/testsuite/latency...done.
>> (gdb) run
>> Starting program: /usr/lib/xenomai/testsuite/latency 
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
>> == Sampling period: 1000 us
>> == Test mode: periodic user-mode task
>> == All results in microseconds
>> [New Thread 0xb6e15470 (LWP 32035)]
>> [New Thread 0xb6e0d470 (LWP 32036)]
>> warming up...
>>
>> Program received signal SIGILL, Illegal instruction.
>> [Switching to Thread 0xb6e0d470 (LWP 32036)]
>> 0xffff0f04 in ?? ()
>> (gdb) where
>> #0  0xffff0f04 in ?? ()
>> Cannot access memory at address 0x3e0
>> (gdb) list
>> Cannot access memory at address 0x3e0
>> (gdb) 
>>
> 
> 0xffff0f04 looks like one of the kuser helpers. It is the I-pipe tsc
> emulation address actually. You probably do not have access to the
> architected timers in user-space. There is a snippet in
> drivers/clocksource/arm_arch_timer.c to enable this access through the
> CNTKCTL register. Maybe this only enables access to physical counter
> whereas newer kernels use virtual counters?
> 
Ok, arch_counter_set_user_access disables user access to the 
architected timer counter. The following patch should avoid this:

diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index b605f04e..7aea949 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -374,7 +374,9 @@ static int arch_timer_setup(struct clock_event_device *clk)
 			enable_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI], 0);
 	}
 
+#ifndef CONFIG_IPIPE
 	arch_counter_set_user_access();
+#endif
 
 	return 0;
 }


-- 
                                                                Gilles.




More information about the Xenomai mailing list